W3C home > Mailing lists > Public > public-linked-json@w3.org > October 2013

RE: Bug with @reverse and blank nodes?

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Sun, 20 Oct 2013 23:31:32 +0200
To: "'Gregg Kellogg'" <gregg@greggkellogg.com>
Cc: "'Pierre-Antoine Champin'" <pierre-antoine.champin@liris.cnrs.fr>, <public-linked-json@w3.org>, "'Dave Longley'" <dlongley@digitalbazaar.com>
Message-ID: <010b01cecddb$c180aad0$44820070$@lanthaler@gmx.net>
On Sunday, October 20, 2013 10:11 PM, Gregg Kellogg wrote:
> I've long been uncomfortable with the need of the algorithm to
> absolutely re-create the same blank node identifiers, as this seems to
> ignore the whole concept of a blank node, and imposes extremely strict
> processing rules that prohibit, for example, parallel processing of
> large nodes. In the long run, it might be worth describing a bnode
> bijection algorithm for JSON-LD, similar to that used for graph
> isomorphism. However, that's probably best left for another day.
> A way I could address this in my implementation would be to have
> Generate Blank Node Identifier return an object rather than a string,
> such than when the object is serialized (when transforming from the
> native Ruby representation to a JSON character-sequence) the label is
> rendered. In this way, the Generate Blank Node Identifier algorithm
> could accept either a string or a previously generated object
> representation. We could then insert between steps one and two for the
> Generate Blank Node Identifier algorithm the following:
> The approach would avoid wholesale re-numbering of existing test cases
> and I think is a better solution in general. Thoughts?

I discussed this alternative approach already offline with Gregg so I'm not
spending a lot of time to explain my position again (because I have another
more elegant proposal). While I like the proposal, I think it is a major
algorithmic change because we have no separate serialization step at the

Anyway.. the problem is that the blank node created for "the outer node" is
injected in the inner node and then relabeled when the algorithm is invoked
recursively. We already have to parameters which we could use to pass all
the necessary information to the recursively called algorithm *instead* of
injecting the data directly. So here's my updated proposal:

Remove step
And change step as follows: Recursively invoke this algorithm
passing value for element, node map, active graph, *referenced node active
subject, and property as active property.*

So, for reverse properties active subject will be an object, otherwise it
will either be null or a string. We could also introduce a separate
parameter if people would prefer that.

Finally, move step 6.5 before 6.4 (so that we have node) and change 6.4 so
that it checks whether active subject is an object or not. If it is

If node does not have an active property member, create one and initialize
its value to an array containing active subject.
Otherwise, compare active subject against every item in the array associated
with the active property member of node. If there is no item equivalent to
reference, append reference to the array. Two JSON objects are considered
equal if they have equivalent key-value pairs.

Perhaps reading code is simpler, so here's the link to the diff I made in my


Markus Lanthaler
Received on Sunday, 20 October 2013 21:32:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:39 UTC