Refactor model to rdf-js spec

[pietercolpaert]

See https://github.com/rdfjs/representation-task-force/blob/master/interface-spec.md

[k00ni]

Hi @pietercolpaert! We are also try to establish a stable low level RDF "specification" to enable interoperability between all existing (and future) PHP RDF frameworks, therefore a proposal for the PHP Framework Interoperability Group. Our current working draft can be found here. As i can see, we already use the same terms (blank node, named node,...) as in the specification.

What you think of working here together? We are open for input and can discuss changes in our proposal. It would be very cool, if hardf could support it too.

[pietercolpaert]

Hi @k00ni! Thanks for reaching out and yes, I would be interested in making sure all PHP RDF frameworks use the same php-fig standard. If someone starts a pull request to comply to the php-fig standard, I would merge it after testing whether there are no regressions in performance.

Regarding the standard itself: are you considering to copy the work by the RDF-js W3C community group? I think that would be a great start in each case!

[k00ni]

Hi, if i understand the spec of the RDF-js W3C community group right, it uses a very "public"-like approach. Properties of classes like Literal are all publicly available, which means, no getter or setter functions. We would like to encapsulate such information and make it only available through methods. Using this, allows a more clear way implementing different backends (e.g. Redland). Using magic methods to catch getter-calls may lead to more spaghetti and hard-to-understand code.

I try to outline all differences between our spec and the one of the RDF-js W3C community group. Maybe we can work together to find some common ground.

Differences

Class from Saft spec	Class from RDF-js community group
Node	Term
Statement	Triple + Quad
AnyPattern	Variable

Node (equals to Term)

We don't allow a Node to be created directly, but through a more specific class like Literal. Node is an interface which forces certain functions.

Methods Saft spec	Methods RDF-js community group
isBlank	-
isLiteral	-
isNamed	-
isConcrete	-
isPattern (means AnyPattern)	-
toNQuads	-
equals	equals 👍
matches	-

NamedNode

Bold methods are unique to this class, the rest comes from the Node.

Methods Saft spec	Methods RDF-js community group
getUri	-
isBlank	-
isLiteral	-
isNamed	-
isConcrete	-
isPattern (means AnyPattern)	-
toNQuads	-
equals	equals 👍
matches	-

BlankNode

Bold methods are unique to this class, the rest comes from the Node.

Methods Saft spec	Methods RDF-js community group
getBlankId	-
isBlank	-
isLiteral	-
isNamed	-
isConcrete	-
isPattern (means AnyPattern)	-
toNQuads	-
equals	equals 👍
matches	-

NamedNode

Bold methods are unique to this class, the rest comes from the Node.

Methods Saft spec	Methods RDF-js community group
getUri	-
isBlank	-
isLiteral	-
isNamed	-
isConcrete	-
isPattern (means AnyPattern)	-
toNQuads	-
equals	equals 👍
matches	-

Statement (equals to Triple or Quad)

Bold methods are unique to this class, the rest comes from the Node.

Methods Saft spec	Methods RDF-js community group
getSubject	(accessible by property)
getPredicate	(accessible by property)
getObject	(accessible by property)
getGraph	(accessible by property)
isTriple	-
isQuad	-
isConcrete	-
isPattern	-
equals	equals
matches	-
toNQuads	-
__toString	-

Conclusion

I guess, class internals like property naming aren't important to discuss here. To "match" our proposal, you only have to add a couple of methods. Most of the names are already equal, so there is not much work either.

If someone starts a pull request to comply to the php-fig standard, I would merge it after testing whether there are no regressions in performance.

We experienced a performance boost using array-only structures instead of class-based. So i guess providing data using all these classes may lead to a "worse" performance. Therefore, i propose, that hardf should keep its current internal model, but provide a way to transform or export its data based on the specification we discuss here. Using specific methods like exportAsStatementList or by providing a custom node factory.

What you think?

[pietercolpaert]

Great idea! Will merge if pull requested!

Cannot allocate time for this myself on short notice though.

[k00ni]

Nice to hear. Ok, let me see what i can do here.

[k00ni]

I just wanted to let you know about my public proposal at Google Groups: https://groups.google.com/forum/#!topic/php-fig/Z1dds-mBRrE

You are welcome to post feedback there or via Github.

After the proposal is accepted, i would help creating a pull request to add support to hardf.

[pietercolpaert]

The N3.js library has now switched to the RDF.js specification. The urgency to update this library grows as well.

[k00ni]

The urgency to update this library grows as well.

What does that mean exactly?

[pietercolpaert]

That from the moment I do some PHP work again I should look into refactoring to the RDFPHP spec you’ve built ;-) Or maybe someone wants to do a pull request

[k00ni]

That from the moment I do some PHP work again I should look into refactoring to the RDFPHP spec you’ve built ;-) Or maybe someone wants to do a pull request

If i understand you correctly, you will implement the RDF specification referenced by me (ref)? If that's the case, be aware that this change may "bloat" the software, because you will have to handle way more objects than before. Right now, using just arrays, is very clean, lean and effective.

Anyway, to get going, you could have a look into our Saft Parser based on hardf: https://github.com/SaftIng/Saft/blob/master/src/Saft/Addition/hardf/Data/ParserHardf.php

And there are some tests related to this: https://github.com/SaftIng/Saft/tree/master/src/Saft/Addition/hardf/Test

[pietercolpaert]

Aha! So in the end, it’s better to just close this issue and leave as is?

[k00ni]

The N3.js library has now switched to the RDF.js specification. The urgency to update this library grows as well.

I may lack some background information. Could you explain why this change affects hardf?

Aha! So in the end, it’s better to just close this issue and leave as is?

For performance reasons i would suggest keep using the current data model. But we should provide a way to interchange data. This intermediate format could be the PHP RDF specification i was talking about.

At the moment no change is required, because one could use my implementation, for instance. It is based on the PHP RDF specification to 99%.

[k00ni]

Hi @pietercolpaert, what is the status here?

[pietercolpaert]

I will follow your recommendation and not change anything here! I’ll close the issue!

[k00ni]

Hi @pietercolpaert, i dont know if you got a notice, a while ago i started working on an implementation of the RDF.js spec: rdfjs/data-model-spec#130. IMHO its a vital successor of Saft and all the other PHP libraries, with the benefit of being compatible to the whole JS ecosystem. I implemented the basic Term related interfaces/classes, but am busy currently. Maybe you are interested in this?