Re: Official response to RDF-ISSUE-132: JSON-LD/RDF Alignment

On 22 May 2013 04:19, Manu Sporny <msporny@digitalbazaar.com> wrote:

> Hi David,
>
> This is an official response to RDF-ISSUE-132: JSON-LD/RDF Alignment,
> which is being tracked here:
>
> https://www.w3.org/2011/rdf-wg/track/issues/132
>
> The group apologizes for missing your specific change requests until you
> prompted us to respond to them on May 21st, 2013. It was a fairly long
> thread, and we thought we had addressed all of your issues before you
> prompted us to respond to the specific change requests that you had
> outlined previously.
>
> Your general concerns revolve around the confusion that may result if
> JSON-LD does not more closely aligning itself with RDF. You had 5 major
> points that you raised. The JSON-LD group spent the majority of the call
> today discussing each of these points in detail:
>
> http://json-ld.org/minutes/2013-05-21/#topic-1
>
> Please read the entire conversation linked to above before going on to
> read the following responses, which are the official position of the group:
>
> > 1. Insert "based on RDF" to the definition of Linked Data, as
> > explained above.
>
> There was a very long series of conversations about whether or not RDF
> should be mentioned in the definition of Linked Data. There were a
> number of people arguing both for and against. These discussions
> happened over the course of 3 years, with the group deciding against
> including references to RDF in the Linked Data definition. Here are just
> a few of the discussions:
>
> http://json-ld.org/minutes/2011-07-04/#topic-3
> http://json-ld.org/minutes/2011-07-26/#topic-2
> http://json-ld.org/minutes/2012-11-20/#resolution-6
> http://json-ld.org/minutes/2012-11-20/#resolution-5
> http://json-ld.org/minutes/2012-12-04/#resolution-3
> http://json-ld.org/minutes/2012-12-11/#resolution-2
>
> Hopefully it is clear that the decision to leave "based on RDF" out of
> the Linked Data definition was thoroughly and carefully considered. In
> the end, the group decided not to tie RDF and Linked Data together
> because it would be conflating a data publishing concept (Linked Data)
> with an abstract data model (RDF).
>
> In the end, the group decided against tightly coupling Linked Data and
> RDF because:
>
> 1. It would conflate two different concepts.
> 2. It is the groups experience that Web developers have an aversion to
> RDF as a complex technology due to RDF/XML and other technologies that
> do not represent the current RDF world. It doesn't matter if these
> aversions are based on reality - the aversion exists, so we try to
> downplay RDF as much as possible in the JSON-LD spec.
> 3. There is no technical problem that is solved by referencing RDF in
> the definition of Linked Data.
> 4. If we were to add RDF to the definition of Linked Data, there would
> just be another set of objections to the inclusion of RDF in the
> definition of Linked Data.
>
> > 2. Define a *normative* bi-directional mapping of a JSON profile to
> > and from the RDF abstract syntax, so that the JSON profile *is* a
> > serialization of RDF, and is fully grounded in the RDF data model and
> > semantics.
>
> We already do this here:
>
> http://www.w3.org/TR/json-ld/#transformation-from-json-ld-to-rdf
>
> and here:
>
> http://www.w3.org/TR/json-ld/#relationship-to-rdf
>
> There have been arguments in the past to specify an additional subset of
> JSON-LD that is a direct mapping to the RDF Abstract Syntax, but no one
> has provided a compelling technical reason to do so.
>
> Additionally, creating two profiles of JSON-LD could have worse
> consequences than the ones you outline in your e-mails. For example,
> some implementers may only implement the subset and not the full version
> of JSON-LD, which would create a really bad interoperability problem.
>
> The extra features in JSON-LD, such as blank nodes as graph names, are a
> requirement for the Web Payments work as well as the RDF digital
> signatures work. So, we can't remove them without causing damage to
> those initiatives.
>
>
Personally, I see that as a "want" and not a "need". It may be defined as a
"need" based on a concept of "bad URIs if they are not HTTP or, they are
HTTP and they don't always resolve directly to something useful", but that
is not part of the RDF specification. There are still plenty of ways to
support unique, designed-not-to-be-resolvable, URIs, and people use one of
them, UUIDs, all the time in various databases. Is it worth supporting
these initiatives which seems to have been designed to only be
interoperable with JSON-LD instead of supporting the larger RDF community
by recognising the anomaly and changing it now before the damage is
widespread?


> If an author wants to use a version of JSON-LD that is fully grounded in
> the RDF data model, they should not use the JSON-LD features listed in
> those bullet points, or they should convert their non-RDF data to
> something that RDF can understand (more on this below).
>
>
The issue will of course come when, users implicitly expect that, as the
RDF working group has chosen the JSON-LD specification as its "JSON
serialisation of RDF", per its charter, and the RDF working group has
published the final specification, that they will be able to process all
valid JSON-LD documents losslessly to the RDF-1.1 abstract model.

As you mention, there will be a large ecosystem of documents that will be
defined to only be able to be roundtripped losslessly if they are processed
solely using the JSON-LD format and its internal memory model, based on the
JSON abstract model. If you take an arbitrary JSON-LD document and expect
to be able to round-trip it through other RDF serialisations, or even a
strict RDF-1.1 abstract model in-memory implementation, then you are not
supported at all by the JSON-LD community who only support that view of
RDF, and not even RDF as stating that JSON-LD is an RDF syntax would be an
immediate turnoff.

Is it a goal to specifically attract developers who have no knowledge or
interaction with the RDF-1.1 abstract model and have them rely on JSON-LD
(both as a format and in-memory) as the only lossless way of transferring
and interacting with Linked Data? If so, it seems like Linked Data is being
conflated with JSON-LD, and the same arguments against Linked Data being
conflated with RDF would apply to that. Future "cool" developers may see
JSON-LD as being "ugly" in the future and refuse to work with Linked Data
at all based on that preconception, as they do right now with RDF/XML.

> 3. Use skolemized URIs in the normative mapping to prevent mapping
> > JSON syntax to illegal RDF.
>
> This is already stated as an option in a normative section:
>
> http://www.w3.org/TR/json-ld/#relationship-to-rdf
>
> We do not make this mandatory because there are several other legitimate
> ways to convert blank nodes to something that RDF can interpret. For
> example: 1) normalizing and getting a hash identifier for the subgraph
> attached to the blank node property or blank graph, 2) creating a
> counter-based solution for blank node naming, 3) minting a new global
> IRI for the blank node, 4) transforming to a data model that allows
> blank node properties and blank graphs, etc. There is no single correct
> approach.
>
> Additionally, skolemization will not work unless all systems exchanging
> the skolem IRIs do so in a standard way, and there is currently no
> standard way of skolemizing. We do have an RDF Graph normalization
> specification, and it does seem to work:
>
> http://json-ld.org/spec/latest/rdf-graph-normalization/
>
> However, that spec isn't a REC and it would take quite a bit of work to
> get it there.
>
> So, the group believes that the spec does as much as it can to implement
> what you suggest above, while understanding that there are caveats to
> the approach you propose above.
>
> > 4. Make editorial changes to avoid implying that JSON-LD is not RDF.
> >  For example, change "Convert to RDF" to "Convert to Turtle" or
> > perhaps "Convert to RDF Abstract Syntax".
>
> The group agrees with changing the title of the section to "Convert to
> RDF Abstract Syntax".
>
> > 5. Define normative names for, and clearly differentiate between, the
> > JSON serialization of RDF and JSON-LD, such that JSON-LD *is* a JSON
> > serialization of RDF, with additional constraints for Linked Data
> > (such as URIs use "http:" prefix, etc.). They do not necessarily have
> > to be defined in two separate documents. They could be defined in a
> > single document called "JSON-RDF and JSON-LD", for example.
>
> The group had discussed this a long time ago and re-hashed the
> discussion today during the call. We do not believe that having two
> different serializations of JSON-LD will help interoperability. Rather,
> the group believes that this is not the correct approach because:
>
> 1) Having two profiles will confuse developers, especially since the
> delta between the two profiles boils down to four bullet points. Why
> have two profiles where one of the profiles differ by around 4-5 sentences?
>

Is it worth splitting the RDF community over those 4-5 sentences, as the
current version of the specification does?


> 2) Having two profiles may make implementers only want to implement one
> profile or the other, which would open the door to interoperability
> problems.
>

See above for the existing interoperability/round-tripping problems with
JSON-LD and the RDF-1.1 abstract model.


> 3) There is no technical issue that is resolved by having two different
> serializations named JSON-RDF and JSON-LD.
>
> > 6. Some small editorial fixes:
> >
> > "Since JSON-LD is 100% compatible with JSON" would be better phrased
> > as "Since JSON-LD is a restricted form of JSON", because saying that
> > JSON-LD is compatible with JSON wrongly suggests that JSON-LD is
> > *not* JSON, when in fact it is.
>
> We agree with your assessment, but would like to avoid the use of
> "restricted form of JSON". What we would like to convey is something to
> this effect:
>
> JSON-LD enables you to express portions of your JSON documents as Linked
> Data.
>
>
It may be best to use that language and avoid referring to RDF at all in
the base JSON-LD specification. Then have a separate JSON-LD-to-RDF mapping
specification (or include it in the JSON-LD-API specification) with a
prologue that clearly identifies the places where JSON-LD diverts from the
RDF model. The current non-normative RDF mapping section seems to rely on
the JSON-LD-API specification already, so it is a little unclear about why
the RDF mapping is not defined in the API specification, where it could be
a normative section.


> We'll leave it up to the editors to select the proper language, but do
> agree with your general point.
>
> > s/secrete agents/secret agents/
>
> Fixed:
>
>
> https://github.com/json-ld/json-ld.org/commit/0e5d5d122e702fa217c734cbe4a82a5b03401f5b
>
> The group understands that several of these responses are probably not
> what you would prefer. However, I hope that we've made it clear that we
> did discuss your concerns in depth, have previously discussed most of
> the issues that you raised, and our position has not changed due to more
> effective counter-points to the arguments that you made.
>
> Please respond to this e-mail and let us know if this response is
> acceptable to you. If the responses are not acceptable and you want to
> pursue the issues further, please make specific suggestions about the
> types of changes that you would like to see made to the specs.
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Meritora - Web payments commercial launch
> http://blog.meritora.com/launch/
>
>