Re: JSON-LD should be an RDF syntax

Hi Manu,

Thanks very much for your response.  My replies . . .

On 03/26/2013 01:28 PM, Manu Sporny wrote:
> David this is a response to your comments on JSON-LD 1.0. We have been
> tracking your issue here:
>
> https://github.com/json-ld/json-ld.org/issues/222
>
> We also discussed your issue in depth here:
>
> http://json-ld.org/minutes/2013-03-19/#topic-2
>
> It has also been the topic of debate for a long while:
>
> https://github.com/json-ld/json-ld.org/issues/174
> https://github.com/json-ld/json-ld.org/issues/47#issuecomment-8050318
>
> On 02/26/2013 11:38 PM, David Booth wrote:
>> These are comments on
>> https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld-syntax/index.html#relationship-to-rdf
>>
>> 1. JSON-LD should be an RDF syntax, just as Turtle is an RDF syntax.
>> This means: (a) it should define the *same* data model as RDF -- not
>> a superset; and (b) it should have the same semantics as RDF
>> serialized in any other syntax.
>
> JSON-LD deviates from the RDF data model in the following ways:
>
> In JSON-LD graph names can be IRIs or blank nodes whereas in RDF graph
> names have to be IRIs.

Blank nodes already cause more grief than any other RDF feature.  I do 
not think it makes sense to promote or condone the expansion of their 
use.  Where are the compelling use cases for this?

>
> In JSON-LD properties can be IRIs or blank nodes whereas in RDF
> properties (predicates) have to be IRIs.

Ditto.  Blank nodes already cause more grief than any other RDF feature. 
  I do not think it makes sense to promote or condone the expansion of 
their use.  Where are the compelling use cases for this?

>
> In JSON-LD lists are part of the data model whereas in RDF they are part
> of a vocabulary, namely [RDF-SCHEMA].

That would make JSON-LD *not* be a superset of RDF.  While I agree with 
the goal of making lists easier to use in RDF -- I think that would be 
great -- I think it is important not to deviate from the RDF model.

>
> RDF values are either typed literals (typed values) or language-tagged
> strings (language-tagged strings) whereas JSON-LD also supports JSON's
> native data types, i.e., number, strings, and the boolean values true
> and false. The JSON-LD Processing Algorithms and API specification
> [JSON-LD-API] defines the conversion rules between JSON's native data
> types and RDF's counterparts to allow full round-tripping.
>
> We tried to make some of these changes in the RDF core specifications,
> but there just wasn't enough time due to the colorful variety of
> opinions on the matter in the RDF WG and limitations imposed on the
> group by the charter. The JSON-LD CG felt that these features were
> compelling enough to keep them in the specification in the hopes that
> RDF will eventually align with the data model. We tried to do this in a
> way that was acceptable to the RDF community.

But failed "due to the colorful variety of opinions on the matter"?  How 
can you have it both ways, except by acknowledging that this splinters 
the community?

>
> The other reason that we define a data model in JSON-LD is to make it
> easier for developers to pick up on Linked Data concepts without having
> to climb the very steep learning curve brought about by having to read
> the myriad of RDF specifications.

That sounds fine and useful *provided* that JSON-LD is consistent with 
RDF.  At present it isn't.

>
> These decisions have been debated for quite some time and the state of
> the specification today is a result of careful deliberation on the
> points you raise in this e-mail. While the group spent a great deal of
> effort aligning the JSON-LD data model with the RDF data model, it
> believes that the proper balance has been struck.
>
>> It does not make sense for the W3C to define splinter the RDF market
>> by defining a competing data model that is so similar to RDF and
>> fills the same needs.  Section C 'Relationship to RDF' makes clear
>> that JSON-LD defines a *different* graph model than RDF: "The RDF
>> data model, as outlined in [RDF-CONCEPTS], is an abstract syntax for
>> representing a directed graph of information. It is a subset of
>> JSON-LD's data model".
>
> It makes sense as a test to see if the future RDF 2.0 work may build off
> of the concepts laid down by JSON-LD 1.0. This will give us some field
> experience as to whether or not these extensions to RDF 2.0 should be
> made without making a big change to RDF 1.0 first.
>
>> If the long-term plan for RDF is that it will eventually embrace the
>>   additional features of JSON-LD (such as blank nodes as graph names,
>>   blank nodes as properties) then the RDF specification itself (and
>> the SPARQL specification?) should be changed NOW to be consistent
>> with JSON-LD,.
>
> We tried to do that. The RDF WG failed to find any sort of consensus
> around whether or not RDF 1.0 should be extended to support these
> concepts. Additionally, even if the group found consensus, the charter
> prevents us from making these sorts of changes.
>
> What we did find consensus around was to allow JSON-LD to deviate in
> very specific ways in an attempt to gain some implementation insight as
> to whether or not these extensions to RDF were worth pursuing in RDF 2.0.

Field experience can and should be obtained by *vendor* *extensions* -- 
not by standardizing N competing RDF-like languages (even if N==2) and 
letting those standards fight it out in the marketplace.  I do not 
believe that it would be in the best interest of the RDF community or 
the W3C to fracture the market by standardizing multiple competing 
RDF-like languages.

>
>> 2. A JSON serialization of RDF should not require IRIs to be
>> dereferenceable -- even with a "SHOULD" requirement as currently
>> stated: [[ IRIs used within a JSON-LD graph should return a Linked
>> Data document describing the resource denoted by that IRI when being
>> dereferenced. ]]
>
> We agree that a JSON serialization of RDF should not /require/ IRIs to
> be dereferenceable. This is why we use the /SHOULD/ vs. /MUST/ language.
>
> JSON-LD is about a JSON serialization for Linked Data. Linked Data
> typically asks that IRIs are dereferenceable so that more information
> can be gleaned from the identifiers. The spec doesn't, however, require
> that all IRIs used in JSON-LD are dereferencable.

Apologies, I was not clear.  The reason I said that a JSON serialization 
of RDF should not require IRIs to be dereferenceable -- even as a 
"SHOULD" requirement -- is because I am distinguishing between a 
serialization of RDF *in* *general* -- not specifically for Linked Data 
-- and a serialization of RDF that is intended specifically for Linked 
Data.  As my original comment goes on to say, I think it is important to 
cleanly layer one spec on another, and there are *many* non-LD RDF uses 
that would benefit from a JSON serialization of RDF.

>
>> Fundamentally this specification should be defining JSON-RDF -- not
>> JSON-LD.  There are many RDF applications that are not Linked Data
>> applications but would nonetheless benefit from a JSON serialization
>> of RDF.
>
> We couldn't use JSON-RDF because a variation on the name was already taken:

Sorry for being unclear.  My point was not so much about the name, but 
about the concept of defining a JSON serialization of RDF *in* *general* 
-- not just for Linked Data -- and then defining an LD version on top of 
that.

>
> https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-json/index.html
>
> Re-using a different variation on the name was causing confusion at the
> time, which is why we ended up going with JSON-LD.
>
>> There are many RDF applications that are not Linked Data applications
>> but would nonetheless benefit from a JSON serialization of RDF.
>
> What prevents these applications from using JSON-LD?

If I have an RDF application, and I want it to accept a JSON 
serialization of RDF, what must I tell my customers?  "It accepts 
JSON-LD *except* that it does not support the following non-standard-RDF 
features, ... blah blah blah ... and furthermore the application does 
*not* expect all of your IRIs to be dereferenceable, because this is 
merely an RDF application -- not a Linked Data application -- but the 
W3C did not define a JSON serialization of RDF, so we had to use JSON-LD 
instead."   Fail.

It would be far better if I could simply say: "the app accepts JSON-RDF" 
(where I'm using the term JSON-RDF to mean a JSON serialization of RDF, 
but I don't really care if it is called "JSON-RDF").  And it would be so 
easy for the working group to instead simply define a JSON serialization 
*of* *RDF*, and then define a Linked Data serialization on *top* of 
that.  This would provide a clean layering, a clean separation of 
concerns: plenty of upside, and almost no downside.

>
>> However, it would be good to define JSON-LD on *top* of JSON-RDF,
>> once JSON-RDF is defined.
>
> We had explored this idea very early in the JSON-LD days and came to the
> conclusion that JSON developers don't work with their data in this way.
> That is, for the vast majority of the in-the-wild JSON markup we looked
> at, JSON developers did not use any sort of triple-based mechanism to
> work with their data. Rather, they used JSON objects - simple key-value
> pairs to work with their data. This design paradigm was the one that was
> used for JSON-LD because it was the one that developers were (and still
> are) using when they use JSON.

The fact that developers don't use triples is completely irrelevant. 
Developers are free to use any internal data representation they want 
when they use RDF -- including hash tables, objects, whatever.

The LDP working group can perfectly well define JSON-LD **in terms of** 
a JSON serialization of RDF.  The difference between the two: The JSON 
serialization of RDF would be just that -- a serialization of RDF, just 
as Turtle or NTriples are serializations of RDF.  Whereas JSON-LD would 
place further restrictions on that serialization to specifically support 
the needs of the Linked Data Platform, such as saying that every IRI 
SHOULD be de-referenceable to information about the identified resource.

David Booth

Received on Tuesday, 26 March 2013 20:23:28 UTC