Define JSON literal and the rdf:JSON datatype.

[gkellogg]

For #4.

---

Preview | Diff

[rubensworks]

Two minor typos.

[iherman]

One major and one minor comment, both on the RDF Datatype definition section:

• lexical-to-value mapping: I am not sure about referring to the RFC for the parser. That does not define how the ECMAScript representation is really mapped. On the other hand, the following reference: https://tc39.github.io/ecma262/#sec-json-object looks like a good match: it defines (normatively) not only the JSON grammar but, more importantly, the JSON object of ECMAScript that includes the parse() method that does the parsing. I would propose to use that as a reference.
• value space: I am a bit bothered by the fact that the specification does not define when two objects in the value space are considered to be equal (although this is not required by the RDF spec). Alas!, however, at the moment there is no standard ways of doing that in the ECMAScript land (afaik). There are some libraries that have such functions (e.g., underscore or lodash, both widely used) but, of course, we cannot refer to these normatively. (Maybe @dlongley or @davidlehn have more information.)
  We could add a note about equality and refer to, e.g., the isEqual function of these two libraries (they share the same function name), but I am not sure whether that is useful or necessary. Other languages may have similar methods, and JSON-LD is not bound to ECMAScript...

B.t.w., as soon as this is merged, we should notify the swig mailing list about this, emphasizing the intention to add this to the rdf namespace (I presume we would formally do that when the Rec is published).

[pchampin]

This is good, apart from a few minor problems.

Shouldn't we also add a note about not abusing the JSON datatype, as suggested by @BigBlueHat during the last telco? By pointing out that such JSON literals might be considered as opaque by other Linked Data consumers, and hence hinder interoperability?

[gkellogg]

the following reference: https://tc39.github.io/ecma262/#sec-json-object looks like a good match

@iherman that's a good match, although the value space includes arrays, numbers, boolean, and null, as well as object.

I am a bit bothered by the fact that the specification does not define when two objects in the value space are considered to be equal.

Yes, indeed. We have some text in the test README that could suffice:

• JSON objects are compared member by member without regard to the ordering of members within the object. Each member must have a corresponding member in the object being compared to. Values are compared recursively.
• JSON arrays are generally compared in order; each item within the array must be equivalent to the corresponding item in the array being compared to by using the comparison algorithm recursively.
• JSON values are compared using strict equality.

[iherman]

@gkellogg the test Readme text if fine, but do you intend to make this normative?

[gkellogg]

That is what I was suggesting for a normative description of value equality. I’m certainly open to alternatives.

[iherman]

@gkellogg I am fine putting that into the doc normatively. We will see what the review will give.