rdf:JSON equality simplification?

[iherman]

A question: in other specifications, we use the RFC 8785 (JSON Canonicalization Scheme (JCS)) reference for normative text. Wouldn't it be possible to make the value space description on the equality simply say that two JSON strings are equal iff their Canonical versions should be identical? (There might be some issues with datatypes, I am not sure.)

B.t.w., minor editorial glitch: In A.3 The rdf:JSON Datatype the note on the value space has the "and" rendered as a code. It probably should not.

[gkellogg]

There have been some discussions on if JCS is appropriate for this purpose. Given that the value space is now objects, and not strings, going to a JCS string representation would require the objects to be converted back to a string, and would not be as useful when comparing native JSON values, such as numbers and booleans.

I note your markup concern, which I'll handle along with other editorial note you've made. (Thanks!)

[iherman]

Given that the value space is now objects, and not strings, going to a JCS string representation would require the objects to be converted back to a string, and would not be as useful when comparing native JSON values, such as numbers and booleans.

Just for the sake of arguments: actually, at least in JavaScript, doing a

jcs(JSON.stringify(a)) === jcs(JSON.stringify(b))

is a widely used idiom to compare two objects. (In fact, the JCS implementations usually accept an object argument and produce a canonical JSON string representation of the object).

But, if this was discussed, I have no reason to object the WG's resolution, so it is all right to close the issue.

[afs]

jcs(JSON.stringify(a)) === jcs(JSON.stringify(b))

That would work as an implementation.

[iherman]

jcs(JSON.stringify(a)) === jcs(JSON.stringify(b))

That would work as an implementation.

Yes, and that is indeed a Javascript implementation, may not be valid for other languages; the mapping from a, say, RUST object to JSON may be more complicated. Although... the RDF spec refers to the INFRA standard, whose mapping to JSON is standardized, so that definition may also work for rdf:JSON's specification as well after all.

However. The whole issue comes from the definition of the rdf:JSON datatype. Why not making it simpler and say that the value space of the datatype is the set of canonical JSON strings? The lexical-to-value space mapping is JCS itself, and equality is simple. RDF does not need to standardize the object equivalent of a JSON string; i.e., from an RDF point of view strings as value space could work all right.

JCS is an IETF RFC (RFC 8785), has been used in other Rec-track documents at W3C (e.g., ECDSA cryptosuite) and it saves us the time and energy it takes to complicate the RDF 1.2 specification.) Why reinvent the wheel?

(I know I am late in the game...)

[gkellogg]

The original proposal was to use the JCS version of the JSON Literal as the value space, as was done in JSON-LD. But, this met with resistance, and having the value space be based on INFRA datatypes, along with xsd:double, is useful for those that actually want the value to be useful as native components.

We also considered using JCS for equality, vs. the current description of equality which is recursive on maps and arrays and leans on XSD notions of equality for numbers. I'm not opposed to this, and it would also be useful for ordering purposes.

[afs]

Yes, and that is indeed a Javascript implementation, may not be valid for other languages

In Java, structures like map and list define "equals" to be structural equality - "same elements".

[pfps]

JCS only handles JSON that maps into non-infinite IEEE floating point numbers as far as I can tell, i.e., it does not handle 1E400, which is currently allowed in rdf:JSON. 1E400 is also allowed in xsd:double and maps to +INF.

[gkellogg]

The group discussed this on today's call and there is no support for changing the current definition of the rdf:JSON datatype to use JCS.