Re: Comments on rdf11-json

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.

> 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