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

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.

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

> 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?
2) Having two profiles may make implementers only want to implement one
profile or the other, which would open the door to interoperability
problems.
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.

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/

Received on Tuesday, 21 May 2013 18:19:42 UTC