search

pietercolpaert / hardf

Low level PHP library for RDF1.1 based on N3.js
https://packagist.org/packages/pietercolpaert/hardf
MIT License
36 stars 7 forks source link

Refactor model to rdf-js spec #14

Closed pietercolpaert closed 6 years ago

pietercolpaert commented 7 years ago

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

k00ni commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 :+1:
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 :+1:
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 :+1:
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 :+1:
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 commented 7 years ago

Great idea! Will merge if pull requested!

Cannot allocate time for this myself on short notice though.

k00ni commented 7 years ago

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

k00ni commented 7 years ago

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 commented 6 years ago

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

k00ni commented 6 years ago

The urgency to update this library grows as well.

What does that mean exactly?

pietercolpaert commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

k00ni commented 6 years ago

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 commented 6 years ago

Hi @pietercolpaert, what is the status here?

pietercolpaert commented 6 years ago

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

k00ni commented 5 years ago

Hi @pietercolpaert, i dont know if you got a notice, a while ago i started working on an implementation of the RDF.js spec: https://github.com/rdfjs/representation-task-force/issues/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?