Evaluating the creation of PHP classes and interfaces based on the RDF.js specification

[k00ni]

I am one of the maintainers/supporters of RDF libraries such as hardf, ARC2 and Saft, written in PHP. And i am currently evaluating, if its worth working on a (basic) PHP class set, which reflects the latest state of your standard/specification. It would be great if you could answer some of my questions:

1. Is this the latest version of the specification? http://rdf.js.org/
2. Where can i get further details about the usage/meaning of certain interfaces/classes? What i found so far, the wiki here does not contain sufficient information about that topic.
3. Is there any activity in this task force recently? Whats the plan for 2019?

Thanks in advance!

Internal references:

• #81
• #124
• #131
• #132
• #133
• #134 (pull request)

External references:

• Providing a draft to create a new RDF specification for PHP libraries (https://github.com/php-fig/fig-standards/pull/958)

[k00ni]

ping @BigBlueHat

[bergos]

1. Yes, that's the latest version
2. There are some up-to-date packages in this org and rdf-ext which mention the used interface (e.g. https://github.com/rdfjs/serializer-ntriples, https://github.com/rdf-ext/rdf-store-sparql). Also we are working on the documentation of rdfjs/rdf-ext. It's still work in progress: https://github.com/rdf-ext/documentation. Does this help? Otherwise, please ask more detailed questions. This would also help to shape the spec and documentation.
3. There was not much activity around the spec itself, but more implementations are using it. We didn't discuss a schedule, but I think beginning of next year would be a good time to finalize the spec.

[elf-pavlik]

#67 also have list of known implementations, as well as work in progress.

[k00ni]

If someone is interested in the current state, here is the repository:

https://github.com/rdfphp/baseline

Feel free to send me feedback.

[elf-pavlik]

Very cool :exclamation:

If possible, constructors are used to set the value of the instance. For instance $node = new NamedNode('foo:bar');

I think in low level interfaces we defined so far we require absolute IRIs. How does your interface handle CURIEs

[bergos]

We don't define any IRI validation. This allows also relative paths and CURIEs. That's on purpose, so libraries can implement features like resolving CURIEs. In general, some definitions are very open to allow libraries to add new features and still be valid according to the spec.

[k00ni]

@elf-pavlik wrote:

I think in low level interfaces we defined so far we require absolute IRIs. How does your interface handle CURIEs

My current implementation doesn't care if a given string is really an IRI to be honest. I support the approach @bergos mentioned. I plan to add a library on top of the current one, which contains common tools and provides utilities to check for valid IRIs, for instance.

But to be more clear about IRI validation and usage of CURIEs, IRI, URI etc. we should add a sentence to §1 about that. EDIT: I added a proposal here: #134

[k00ni]

I noticed the updates you guys are working on. Is it possible, to later make an announcement (or ping me), if you "finished" your next major version of this specification/these specifications? I am currently very busy, but will wait until the specs are stable.