rdf:JSON lexical-to-value updates

[gkellogg]

Limit the value space for rdf:JSON to be the "smallest set containing ...".

Updates rdf:JSON L2V mapping.

Fixes #87.Fixes #88. Fixes #89. Fixes #90. Fixes #91.

---

Preview | Diff

[TallTed]

Please retitle from rdf:JSON L2V to rdf:JSON lexical-to-value or similar.

[pfps]

Looks good. It may even actually satisfy the requirements of an RDF datatype. (I need to see whether there are problems with unordered ordered maps and how identity is defined. It looks so far as if there is a problem here.)

I note that the wording is clear that +0.0 and -0.0 are separate elements of the value space.

In any case, this is much better and should be merged.

[pfps]

A problem with the proposed wording is that

maps (mapping strings to values in the value space where the order of map entries is not significant),

is not very well defined. And worse, equality is defined with

They are both maps with equal entries – meaning that both a and b have the same size, and for each entry ea in a there is an entry eb in b such that the key in ea equals the key in eb, and the value in ea equals the value in eb.

which looks as if elements of the value space are ordered maps and equality is defined over this notion of identity. This is not suitable for an RDF value space.

Instead it would be much better to start with unordered maps, defined as

finite maps from strings to values in the value space

without introducing any notion of order. If a referent for "map" is needed point to some mathematical definition of maps.

Then make the NOTE be something like

NOTE
The lexical-to-value mapping the JSON lexical values { "a": 1, "b": 2 } and { "b": 2, "a": 1 } is the same map, as the order in the lexical values is not significant.

[gkellogg]

maps (mapping strings to values in the value space where the order of map entries is not significant),

We could just drop the "order of map entries is not significant" as it has no operational effect. In INFRA, a map is defined as "a finite ordered sequence of tuples, each consisting of a key and a value, with no key appearing twice. Each such tuple is called an entry." In RFC8259, a JSON object is defined as "zero or more name/value pairs (or members)". We could instead say:

maps (mapping JSON Object members to map entries in a map).

They are both maps with equal entries – meaning that both a and b have the same size, and for each entry ea in a there is an entry eb in b such that the key in ea equals the key in eb, and the value in ea equals the value in eb.

which looks as if elements of the value space are ordered maps and equality is defined over this notion of identity. This is not suitable for an RDF value space.

I don't read it that way, but we could adopt some of the wording for lists:

They are both maps with equal entries – meaning that for each entry e_a in a there exists an entry e_b in b such that the key in e_a equals the key in e_b, and the value in e_a equals the value in e_b, and both a and b have the same size.

While I don't think it's useful to define another kind of map, we already have such a note in place.

[pfps]

The point is that the value space has to be defined carefully and correctly, so that elements of the value space are just maps, not ordered maps. The best way to do that is to not start with ordered maps.

[gkellogg]

The point is that the value space has to be defined carefully and correctly, so that elements of the value space are just maps, not ordered maps. The best way to do that is to not start with ordered maps.

If the mapping from JSON to INFRA was unique to RDF then there might be an argument to do something different, but INFRA is largely there, in large part, to create a data model for JSON, and is used widely in W3C specs. Both EPub and DID Core use it specifically for representing JSON-LD. If we were to go on our own here, we would be going counter to established patterns at W3C, which could cause problems during Horizontal Review.

The DID Core Data Model specifically calls out the fact that INFRA orders things, even though order is not significant:

As a result of the data model being defined using terminology from [INFRA], property values which can contain more than one item, such as lists, maps and sets, are explicitly ordered. All list-like value structures in [INFRA] are ordered, whether or not that order is significant. For the purposes of this specification, unless otherwise stated, map and set ordering is not important and implementations are not expected to produce or consume deterministically ordered values.

In any case, the fact that the definition of a map defines order none of our use is dependent on that. Perhaps adding some language to the value space note on maps based on what DID described would help further clarify this.