Graph::createNode() should allow reusage of blank-nodes about jsonld HOT 5 CLOSED

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?

from jsonld.

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 :)

from jsonld.

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?

from jsonld.

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

from jsonld.

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!

from jsonld.