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

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.

We've been trying to work with the RDF WG for many, many months,
attempting to do what you outline above while not scaring off people
that don't have the time to learn the entire RDF stack.

We've made concessions on countless occasions in the name of compromise.
The most frustrating part about all of this is that after making these
numerous changes, that we're asked to do things like "move RDF to a
central role". As an editor, I have no idea how to translate that
statement into spec text that will make you happy.

Please be precise as to the types of changes that you would like to see
in the document. You, thankfully do so below, but I would appreciate a
move to very specific statements about changes instead of broad-brush
statements like that made above.

Since we now have 3 perma-threads combined under this "JSON-LD is not
RDF enough, put more RDF in there" theme, I'm going to start asking
commenters to start suggesting specific specification text and placement.

> The document redefines just about everything related to RDF and 
> Linked Data with minimal or no pointers to any other W3C documents 
> from the definitions.

Could you please outline every single one of those occurrences in the
specification, and what you'd like us to link to in that case? Keep in
mind that we're trying to balance not scaring off Web developers with
this specification, which is the reason why we don't mention RDF up front.

> The problem starts in the first paragraph of the document, where 
> Linked Data is defined without any references and without any mention
> of the central role RDF plays in Linked Data.

Have you been reading the perma-thread on public-rdf-comments and
public-lod on this? I would suggest that you read that thread thoroughly
before asserting that RDF plays a "central role" in Linked Data. I don't
think there is agreement on this at all. If the RDF WG would like to
agree on a definition for Linked Data, we'd be happy to put that in the
spec.

> The only mention of RDF in the introduction is to say that *if*
> developers need to serialize an RDF graph or dataset they "will find
> JSON-LD of interest."  The introduction goes on to further separate
> Linked Data and RDF by listing them separately.  The relationship
> between JSON-LD and RDF is specified in a non-normative section of
> the document.

Not true. We normatively define the relationship between JSON-LD and RDF
in Appendix C. We also specifically state this in a normative section:

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

> RDF serializations are mentioned as if they are divorced from RDF.

Could you please point out where this happens and suggest specific spec
text to remedy the situation?

> For JSON-LD to be a W3C recommendation, I believe that it must defer
>  to the W3C vision of Linked Data, including both the initial 
> definitions of Linked Data and the centrality of RDF in Linked Data.
> 
For that to happen, the RDF WG would have to declare a formal definition
of Linked Data. I'd be happy to put that in the spec if the RDF WG does
just that.

That said, I don't think it's the RDF WGs place to make that sort of
declaration.

> For JSON-LD to be a W3C recommendation from the W3C RDF working 
> group, I believe that it must be normatively based on RDF.

Could you then provide all of the normative text that you'd like to see
in the specification as well?

> For JSON-LD to be a recommendation from the W3C RDF working group, I
>  believe that it must become much closer to being a true RDF syntax.

No idea what "being a true RDF syntax" entails. You will have to be more
specific.

> For example, the discussion of IRIs does not mention RDF at all.

Why does mentioning an IRI need to also mention RDF?

> Indeed, there is no mention of RDF at all in the sections on basic 
> and advanced concepts.

We didn't need to mention it to get the basic and advanced concepts
across. We're trying to be as simple as possible with the specification.
We have successfully conveyed this information without talking about Web
Architecture, Turtle, SPARQL, RDF, Web Linking, HAL, and a variety of
other technologies.

If we can get the concepts across without pulling in a huge body of
work, that makes the spec simpler to understand for Web developers (who
are the primary audience for JSON-LD).

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

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

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

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

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.

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

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

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

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

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

> 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

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

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

> I am truely sorry that I did not do this level of analysis on the 
> document before the first last-call decision.  I only hope that there
> is no bar to putting forward these concerns at this late date.

There's no bar, but it is a bit 11th hour.

I feel that we have many of the statements that you wanted in the
specification already, in normative sections. I'm a very wary of doing a
big re-organization at this point since we've had so many reviewers at
this point that have approved of the document in its current form.

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

-- 
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, 18 June 2013 01:17:24 UTC