Graph::createNode() should allow reusage of blank-nodes
indeyets opened this issue · comments
Currently, createNode() creates new blank node each time it gets _:something. The problem is, that, sometimes, it is desirable to reference the same blank node several times (node itself, then some other nodes, which point to it)
The solution is, to keep some kind of cache for blank-nodes, just as there is a cache for "regular" nodes
That was a deliberate design decision. Blank node identifiers are a serialization fragment.. they are not stable identifiers and as such you shouldn’t use them. You have to keep a reference to a blank node (or navigate to it via some other nodes) if you need it. What problem are you trying to solve that requires this?
Well, that's what I do right now.
I implemented json-ld serialisation for EasyRDF. see https://github.com/njh/easyrdf/blob/master/lib/EasyRdf/Serialiser/JsonLd.php#L66
I iterate over EasyRDF nodes, create corresponding JsonLd nodes and then export the document. Blank nodes needs to be consistent, so I do manual tracking right now, but I hoped to move the burden to the library :)
I understand. Nevertheless I‘m a bit reluctant to make that change as it easily yields to wrong results if you, e.g., merge two graphs. It also makes it difficult to rely on the consistency of the graph if it is used in different places (code written by different people). If by coincidence the same bnode ID is used twice, the properties are merged on a single node instead of creating two nodes.
Wouldn't subclassing Graph and overriding the createNode method solve your problem in quite an elegant way?
Wouldn't subclassing Graph and overriding the createNode method solve your problem in quite an elegant way?
It would have solved for a one-shot application, but I don't think that would be a good choice for a framework code, as it will start to ignore any changes that you implement in this method in newer versions. Current solution with external caching is more robust, as it relies only on interface.
I understand your reasons. So I'll close the issue. thanks
It would have solved for a one-shot application, but I don't think that
would be a good choice for a framework code, as it will start to ignore
any changes that you implement in this method in newer versions.
You are of course completely right.
Current solution with external caching is more robust, as it relies only
on interface.
I understand your reasons. So I'll close the issue. Thanks
Thank you for integrating this into EasyRDF!