Comments on rdf11-json

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

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.

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 ?



Specific comments:

1/ title: the spelling of serialisation is inconsistent with the rest of
the document, spelling it serialization

2/ Abstract, 2nd paragraph : I would add at the end something like "and
alternative to the one recommended in [JSON-LD]".

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.

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.

5/ 4. Serialization, step 3.3.3.2, second item : "the value begin S" ->
"the value being the lexical form of s"

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

7/ 5. Examples : it would be good to have the corresponding Turtle for each
example

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"


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