W3C home > Mailing lists > Public > public-rdf-wg@w3.org > June 2013

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

From: Peter Patel-Schneider <pfpschneider@gmail.com>
Date: Mon, 17 Jun 2013 11:02:45 -0700
Message-ID: <CAMpDgVzajHcb-Tg7zJoyYCLLDdo+LfoOz-nE_dmFYGm+PZ4T8w@mail.gmail.com>
To: RDF WG <public-rdf-wg@w3.org>
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 document redefines just about everything related to RDF and Linked Data
with minimal or no pointers to any other W3C documents from the definitions.
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.  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.  RDF serializations are mentioned as if they are divorced from
RDF.  All RDF references are informative.

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 JSON-LD to be a W3C
recommendation from the W3C RDF working group, I believe that it must be
normatively based on RDF.

The Design Goals and Rationale for JSON-LD states that there is no need to
understand RDF to use JSON-LD, but that JSON-LD can be viewed "like any
other RDF syntax."  However, JSON-LD is different from every RDF syntax in
several fundamental ways (including not being defined in terms of the RDF
data model).

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.

There are very few mentions of RDF in the document overall.  For example,
the discussion of IRIs does not mention RDF at all.  Indeed, there is no
mention of RDF at all in the sections on basic and advanced concepts.

For JSON-LD to be a recommendation from the W3C RDF working group, I believe
that it must refer back to RDF definitions whereever notions related to RDF
are discussed.

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.

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

  JSON-LD is a serialization format for Linked Data [ref to some W3C
  document] based on JSON.  It is therefore important to distinguish between
  the syntax of JSON-LD, which is defined by JSON [...] and the underlying
  data model.

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

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

  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

  JSON-LD includes syntax for lists, which are to be transformed into
  triples via ....

  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.

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

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.

Peter F. Patel-Schneider
Nuance Communications
Received on Monday, 17 June 2013 18:03:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:14 UTC