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

JSON-LD Algorithms

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Thu, 3 Jan 2013 19:23:54 -0500
To: "public-linked-json@w3.org JSON" <public-linked-json@w3.org>
Message-ID: <5E429D74-0CA1-400F-9B2C-2781929EA049@greggkellogg.net>
I've spent some time going over the updated algorithms and updating my parser. I have to say, that I'm distressed at how much the core algorithms have changed. In some cases (e.g., Inverse Context) it seems that the motivation was for performance, at the expense of being able to walk through the algorithms; I really think this is the wrong idea, and pretty much requires that an implementation exactly implement the algorithms to have a chance at conforming. This is also quite de-stabilizing, as we are trying to get to LC soon. IMO, the purpose of algorithm definitions in W3C specs is to allow them to be unambiguously understood by an implementor as to what the intent of the algorithms is, rather than the specific way in which they must be implemented.

Looking at the record [1], the group decided to adopt the algorithm I had specified (with some modifications) as an update to the current compaction algorithm, however the new compaction algorithm bears little resemblance to the old algorithm.

Looking at IRI compaction, the sense of the group definitely seemed to be to stick as close as we can to the current algorithms [2]. However, the IRI compaction algorithm is also substantially different than before.

My current implementation sticks closely to the original algorithms, with relatively minor updates to Term Rank, Expansion and Compaction to support language maps, annotations and property generators. I haven't completed my property generator compaction implementation, but I'm confident that the modification I specified relative to the previous algorithm can work (with some minor tweaks, no doubt).

I recommend that we go back to the previous algorithms and look for the minimal changes that are necessary to specify the desired behavior. I can certainly do this based on the work I've done to bring my implementation up-to-date.

Modifications to those algorithms should try to make the meaning of them clear when reading, rather than relying on emergent behavior. For example, knowing what term to choose when compaction should be something you can determine by walking through the IRI Compaction and Term Rank algorithms given specific input.

Lastly, I'm concerned that the tests depend too much on specifics of Blank Node naming. I can see why this is desirable, but it again limits implementations. One way to do this would be to transform the resulting JSON-LD into RDF and use well-understood graph isomorphism. To allow us to continue to use JSON object equivalence as the result test, we could add a "preserve blank node identifiers" flag to be used for the bulk of operations that involve expansion. It's only in the case that blank nodes are renamed that we run into problems, and some graph isomorphism might be necessary.

Gregg Kellogg
gregg@greggkellogg.net<mailto:gregg@greggkellogg.net>

[1] http://json-ld.org/minutes/2012-10-09/#resolution-2
[2] https://github.com/json-ld/json-ld.org/issues/113#issuecomment-10538485
Received on Friday, 4 January 2013 00:24:38 UTC

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