Re: JSON-LD should be an RDF syntax

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.

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

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

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.

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.

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.

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

> 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:

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?

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

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
President/CEO - Digital Bazaar, Inc.
blog: Aaron Swartz, PaySwarm, and Academic Journals
http://manu.sporny.org/2013/payswarm-journals/

Received on Tuesday, 26 March 2013 17:29:18 UTC