Re: comments on JSON-LD 1.0, A JSON-based Serialization for Linked Data

A response about my comments on Appendix A, the JSON-LD data model.


On 06/17/2013 06:16 PM, Manu Sporny wrote:
> On 06/17/2013 02:02 PM, Peter Patel-Schneider wrote:
>> This document, http://json-ld.org/spec/latest/json-ld/, dated 13 June
>> 2013, is supposed to be an output of the W3C RDF working group, but
>> RDF is only a bit player in the document.  Without moving RDF to a
>> central role in the document, I do not see why this document should
>> become a W3C recommedation of this working group.

>> The data model of JSON-LD in Appendix A is defined without any
>> reference to RDF, the only mention of RDF (which is after the
>> definitions) is that the definitions correspond closely to RDF graphs
>> and datasets.
> We have this in the spec:
>
> """
> These definitions correspond closely, both in terminology and in general
> structure, to the abstract syntax of RDF datasets and RDF graphs.
> Complete details of how JSON-LD relates to RDF can be found in section
> C. Relationship to RDF.
> """
>
> Why is that not good enough? Please offer some replacement text.

I did, in the message that I sent out, and which you have already replied to.
>
>> For JSON-LD to be a recommendation from the W3C RDF working group, I
>>   believe that the data model of JSON-LD must be defined in terms of
>> the data model of RDF.
> This seems like an arbitrary requirement, mainly because the technology
> has been adopted in a very broad way without anyone asking for this
> until this point in time.

Well, maybe not in so many words, but i was certainly under the impression 
that a major request from the RDF working group was to move JSON-LD closer to RDF.
>
>> This is not just a matter of referring back to the RDF definitions,
>> but instead is a reworking of the currently loose JSON-LD data model
>> which, among other things, would relate untyped values to typed
>> values (so that, e.g, true is the same as "true"^^xsd:boolean),
>> expand out lists (so that lists are no longer nodes), and make graph
>> names and edge labels not be blank node identifiers (but instead be
>> blank nodes).  In the end, the JSON-LD data model would be RDF
>> graphs, possibly with the sole additions that edge labels and graph
>> names can be blank nodes.
> I think there might be a technical disconnect here. Are you very
> familiar with JSON?
Reasonably familiar, in the sense that I know its syntax enough to use it, and 
the data model, such as it is.  I've even delved intoECMA-262 3rd Edition. 
<http://www.ecma-international.org/publications/files/ecma-st/ECMA-262.pdf>
>
> The JSON-LD data model is based on JSON, not RDF. We can't just will
> that away, it makes no technical sense. The underlying syntax is
> JavaScript Object Notation, which has its own data model. We're not
> starting from scratch here (like Turtle, N3, etc.)

If the JSON-LD data model is the JSON data model, then what are graphs doing 
there?  If you can add and remove things from the JSON data model then what's 
the problem with taking the last steps towards the RDF data model?
>
> What we have there right now is basically the RDF Dataset model plus the
> JSON model. We can't remove the JSON model because doing so would be
> pretending that there are no differences between the JSON model and the
> RDF model.
>
>> I would be happy with something like the following (plus additions to
>> fill in the missing bits indicated below, and probably some that I
>> have missed):
> Thank you for offering some specific spec text, that is helpful.
>
>> JSON-LD is a serialization format for Linked Data [ref to some W3C
>> document] based on JSON.
> There is no such normative document. The RDF WG would have to create one
> or make this the normative definition of Linked Data.

I'm not saying that there is a normative document.  This pointer could be to 
the design document for Linked Data.
>> It is therefore important to distinguish between the syntax of
>> JSON-LD, which is defined by JSON [...] and the underlying data
>> model.
> We can't make this statement since it's not true. There is a data model
> underpinning JSON, not just a syntax.

My wording is only a minor variation on the wording that is already in Appendix A.
>
>> The data model underlying JSON-LD is RDF datasets as defined in RDF
>> 1.1 Concepts and Abstract Syntax [...], with the following
>> additions: 1/ JSON-LD allows blank nodes as the predicate of triples,
>> and 2/ JSON-LD allows blank nodes as names of graphs in the dataset.
>>
> This is inaccurate. There are more than just those two additions. We
> list all of them in Appendix C.

I'm showing how this could be made to be true, with only minor changes to the 
data model, and changes that the vast majority of users would never even notice.
>
>> The use of either of these extensions can cause interoperability
>> problems with other producers and consumers of Linked Data and thus
>> are not recommended when publishing Linked Data using JSON-LD.
> We already state this in Appendix C:

It deserves to be said here, not elsewhere.
>
> """
> Summarized, these differences mean that JSON-LD is capable of
> serializing any RDF graph or dataset and most, but not all, JSON-LD
> documents can be directly interpreted as RDF. It is possible to work
> around this restriction, when interpreting JSON-LD as RDF, by
> transforming blank nodes used as graph names or properties to IRIs,
> minting new "Skolem IRIs" as per Replacing Blank Nodes with IRIs of
> [RDF11-CONCEPTS]. The normative algorithms for interpreting JSON-LD as
> RDF and serializing RDF as JSON-LD are specified in the JSON-LD
> Processing Algorithms and API specification [JSON-LD-API].

But this is different from disrecommending JSON-LD constructs that go beyond RDF.
> """
>
>> JSON-LD allows untyped literals for strings, numbers, booleans, and
>> language-typed strings.  In each case, the untyped literal must be
>> transformed into an RDF literal as follows ....
> We outline this algorithm in the JSON-LD API spec:
>
> http://www.w3.org/TR/json-ld-api/#rdf-conversion-algorithms
>
>> The datatypes above and their restrictions in XML Schema Datatypes
>> [...] are to be considered to be recognized datatypes [RDF 1.1
>> Concepts] in JSON-LD and applications that produce or consume
>> JSON-LD.  This means in essence that JSON-LD applications have some
>> notion of the underlying datatype involved.  JSON-LD applications
>> *may* convert between different literals that have the same literal
>> value (for example, by removing leading "0"s from numbers, or even by
>> changing the datatype of a literal) with the understanding that this
>> might introduce some minor compatability issues.  JSON-LD
>> applications may use internal JSON values for these datatypes with
>> the understanding that they may not be able to represent all literals
>> in a datatype and thus may not be able to process all JSON-LD
>> documents.
> You are glossing over a number of very important details. We specify the
> exact algorithms here:
>
> http://www.w3.org/TR/json-ld-api/#data-round-tripping
>
> and here
>
> http://www.w3.org/TR/json-ld-api/#rdf-conversion-algorithms
>
> Please review those algorithms before specifying any spec text.

Why? Sure there are lots of details in round-tripping.  However, they can all 
be handled by reference to existing specifications. For example, one could say 
that RDF numbers are to be converted to their canonical form according to XML 
Schema datatypes and this canonical form is the JSON number.  This keeps 
everything straight for all the datatypes derived from decimal and double, and 
precisely defines what is going on for these datatypes.  Float can be 
disallowed in this conversion process.  Any further changes caused by 
implementations are then implementation specific.
>> JSON-LD includes syntax for lists, which are to be transformed into
>> triples via ....
> This is specified here:
>
> http://www.w3.org/TR/json-ld-api/#list-to-rdf-conversion

Yes, but my point is that specifying it in the data model removes an 
unnecessarily division between JSON-LD and RDF (and, for that matter, between 
JSON-LD and Linked Data).
>
>> In a JSON-LD document, graph names and predicates *should* be IRIs.
>> In keeping with the basis of Linked Data, IRIs in JSON-LD documents
>> should be derefenceable and should dereference to a document that is
>>   in a Linked Data format.
> We state that normatively here:
>
> http://www.w3.org/TR/json-ld/#data-model
>
> """
> Each named graph is a pair consisting of an IRI or blank node identifier
> (the graph name) and a JSON-LD graph. Whenever practical, the graph name
> should be an IRI.
> """

> """
> IRIs used within a JSON-LD graph should return a Linked Data document
> describing the resource denoted by that IRI when being dereferenced.
> """
Yes, and I'm just reiterating that, plus providing a rationale.
>> JSON-LD documents *may* contain data that cannot be represented in an
>> RDF dataset.  Such data is to be ignored when a JSON-LD document is
>> being processed, except so far as this data may modify the data that
>> is being represented in the RDF dataset.  This means, e.g.,
> We effectively state that here:
>
> http://www.w3.org/TR/json-ld/#data-model
>
> """
> JSON-LD documents may contain data that cannot be represented by the
> data model defined above. Unless otherwise specified, such data is
> ignored when a JSON-LD document is being processed. This means, e.g.,
> that properties which are not mapped to an IRI or blank node will be
> ignored.
> """
Perhaps you are missing the point that I'm trying to provide a better 
definition for the JSON-LD data model, so I need to include many of the same 
points that are already in Appendix A?

[...]
> That said, if you keep proposing concrete spec text (and the location that 
> it should go into the spec), we can put that in front of the group and get a 
> decision on it. That will be the fastest way to make some headway on your 
> concerns. -- manu 

That's what I just did for Appendix A.   Please consider this a an explicit 
request then.

Peter F. Patel-Schneider
Nuance Communications

Received on Tuesday, 18 June 2013 03:46:06 UTC