Re: Comments on rdf11-json

On Aug 12, 2013, at 3:12 PM, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Bonjour Pierre-Antoine, 
> I've now gone through all your comments and updated the draft accordingly. See below for further details. 
> 
> pierre.antoine.champin@gmail.com wrote on 07/02/2013 04:21:38 PM:
> 
> > NOTE TO JSON-LD PEOPLE: there is a question for you at the very end 
> > of this message; you might want to read the last part "Meta-remark" 
> > /NOTE
> 
> I haven't seen any response from our JSON-LD experts. 
> 
> > Hi all, 
> > 
> > last week I volunteered to review the document rdf11-json.
> 
> > General comments: 
> > 
> > 1/ I think it should be made clearer in the title that this document
> > is not the recommended syntax for encoding RDF in JSON. Maybe 
> > something like "JSON simple serialization" (but seems to imply that 
> > JSON-LD is more complex, which is not really the point) or "JSON 
> > alterative serialization" ? See also my meta-comment below. 
> 
> I went with Alternate Serialization.
> 
> > 2/ It is strange to define this syntax exclusively in terms of the 
> > serialization process. Would a serializer producing the same output,
> > but with a different algorithm, be compliant ? How would I know if a
> > parser is compliant -- or does the notion of compliant parser even 
> > makes sense for this note ?
> > 
> 
> Good question. The JSON-LD folks ended up with two documents one that describes the syntax and the another that describes the transformation. Given that this is just a note we should try and keep it simple. 
> Section 4 states that "an RDF/JSON document may be constructed using the following algorithm " so this would  possibly allow for a different algorithm to be used. Yet, we somehow need to ensure the same mapping if we want to achieve any kind of interoperability.

The reason for the two documents was not to separate processing from syntax, but to separate API from syntax. As JSON-LD has an extensive API we felt that it should not complicate the syntax spec, and RDF serialization/parsing depends on other aspects of the API. For a format that does not include other API methods, i believe it's appropriate for them to be included in a single document. Note that most RDF formats only describe parsing, and leave serialization issues as an exercise for the reader.

Gregg

> > Specific comments:
> 
> > 1/ title: the spelling of serialisation is inconsistent with the 
> > rest of the document, spelling it serialization 
> 
> Fixed. 
> 
> > 
> > 2/ Abstract, 2nd paragraph : I would add at the end something like 
> > "and alternative to the one recommended in [JSON-LD]".
> 
> Done. 
> 
> > 3/ 1. Intro, 1st paragraph : "in JavaScript Object Notation (JSON) 
> > ([RFC4627])." I think that this part should be at the end of the 
> > sentence. In any case, there is a spurious colon after the ref to RFC4627.
> 
> Done. 
> 
> > 4/ 3. Overview, description of "type": it is not clear whether this 
> > is the key "type" or its values that must be lowercase. May be it 
> > should be stated somewhere that all keywords defined by the note are
> > case sensitive, and so should be used lowercase. 
> 
> Added a sentence to that end.
> 
> > 5/ 4. Serialization, step 3.3.3.2, second item : "the value begin S"
> > -> "the value being the lexical form of s"
> 
> Done. 
> 
> > 6/ 4. Serialiation, step 3.3.3.2, items 2 to 4 : those three steps 
> > are not mutually exclusive in their condition; they should probably 
> > be restructured, the last two being sub-items of the first one
> 
> Agreed. Fixed. 
> 
> > 7/ 5. Examples : it would be good to have the corresponding Turtle 
> > for each example
> 
> Per Andy's request I added the N-Triples equivalent. 
> 
> > 8/ A. Internet media type, type name: should be "application" and not "text"
> 
> > 9/ A. Internet media type, encoding considerations : apparently, 
> > copy-paste from the SPARQL document... "SPARQL Query Result" should 
> > be replaced by "RDF/JSON"
> 
> > 10/ A. Internet media type, security consideration : apparently 
> > copy-paste from the Turtle document... "Turtle" should be replaced 
> > by "RDF/JSON" 
> > 
> > 11/ A. Internet media type, last paragraph: "specificationis" -> 
> > "specification is"
> > 
> 
> Per Andy's suggestion, I got rid of most of that section and replaced it with a much simpler tex.
> 
> > Meta-remark:
> 
> > It would be nice if, instead of proposing an alterative format to 
> > JSON-LD we could propose a controlled subset of JSON-LD that meets 
> > the requirements that this format addresses. 
> > 
> > I understand that this format 1) has some advantages over JSON-LD 
> > (less variability, easy access to a given triple...), and 2) is 
> > already deployed in some applications. I'm not sure which one, of 1 
> > or 2, is the strongest argument for publishing this note. 
> 
> 1 is definitely what motivates the use of RDF/JSON by some of my colleagues. 
> 
> > If this is
> > 1, why not propose something with the same advantages, by compatible
> > with JSON-LD?
> 
> > For exemple, instead of
> 
> > { "http://example.org/S": { 
> >     "http://example.org/P": [ 
> >       { "type": "uri", 
> >         "value": "http://example.org/O"
> >       }, 
> >       { "type": "bnode", 
> >         "value": "_:b1"
> >       }, 
> >       { "type": "literal", 
> >         "value": "a literal"
> >         "lang": "a literal"
> >       }, 
> >       { "type": "literal", 
> >         "value": "a literal"
> >         "datatype": http://example.org/DT"
> >       } 
> >     ] 
> >   }
> > }
> 
> > one could write
> > 
> > { "http://example.org/S": {
> >     "@id": "http://example.org/S",
> >     "http://example.org/P": [
> >       { "@id": "http://example.org/O"
> >       },
> >       { "@id": "_:b1"
> >       },
> >       { "@value": "a literal",
> >         "@language": "en"
> >       },
> >       { "@value": "a literal",
> >         "@datatype": "http://example.org/DT"
> >         }
> >     ]
> >   }
> > }
> 
> > As far as I can tell, this is valid JSON-LD, provided with the 
> > appropriate @context -- I would require a confirmation form JSON-LD 
> > experts, though... 
> 
> I'd like to hear it too.
> 
> > I even think that the JSON-LD subset could be made to look even 
> > closer to the original format, for example by stating in the 
> > implicit context that "lang" is equivalent to "@language", and 
> > "datatype" to "@datatype" (but "value is a problem, sometimes 
> > meaning "@id"; and sometimes "@value"). 
> > 
> >   pa 
> 
> Thanks for your careful review and input.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>