Moves datatype definitions to an appendix and adds rdf:JSON datatype #62

hartig · 2023-09-13T07:57:50Z

As agreed during the FSF meeting at TPAC, this PR

adds a new appendix,
moves the sections that define the rdf:HTML and rdf:XMLLiteral datatypes into that appendix, and
copies the definition of the rdf:JSON datatype from Section 10.2 of [JSON_LD11] into this new appendix as well.

Regarding the latter, I have indeed just copied the definition of the rdf:JSON datatype. When doing so, there were two things that I was wondering:

The sentence that defines the lexical space contains two different links for "JSON Grammar". The first one points to Sec.2 of RFC4627, and the second one points to Sec.2 of RFC8259. I was wondering, why these two different links?
There is an issue box about the JSON Canonicalization Scheme (JCS) which I also copied (note, in this copy I had to make a slight change because JSON-LD11 explicitly defines JSON Literal, which we don't have in RDF Concepts). However, I have to admit that I do not fully understand the last sentence in this issue box ("Users are cautioned from depending on the JSON literal lexical representation as an RDF literal, as the specifics of serialization may change in a future revision of this document."). In particular, I wonder:
1. What "serialization" does the last part of his sentence refer to?
2. What is meant by "this document"? (the JSON-LD11 spec or the JCS spec?)
3. Also, is this whole comment something specific to JSON-LD?

(GitHack preview)

Preview | Diff

…about rdf:HTML and rdf:XMLLiteral into this appendix, as per #14 (comment)

…of this section is copied directly from Sec.10.2 of JSON-LD11

domel · 2023-09-13T08:18:06Z

The sentence that defines the lexical space contains two different links for "JSON Grammar". The first one points to Sec.2 of RFC4627, and the second one points to Sec.2 of RFC8259. I was wondering, why these two different links?

I think that's an oversight. RFC8259 obsoleted RFC7159 obsoleted RFC4627. So I see no reason to refer to the old document when the new one is valid.

spec/index.html

hartig · 2023-09-15T19:46:24Z

Looking at @TallTed's change suggestions, I see only now that the diff of this PR contains the complete Section 6 (Fragment Identifiers) and Section 7 (Generalized RDF Triples, Graphs, and Datasets) as new text, and then, later, as removed text snippets. I have not touched these sections at all. It seems that the Github diff functionality did not correctly recognize the actual changes. This is strange in particular because, when I did git diff locally before committing the changes, the diff looked correct. Hence, the diff functionality of git recognized the changes correctly, in contrast to the one of Github.

Long story short, at least half of @TallTed's change suggestion in this PR now are for text that was not supposed to be changed at all by this PR. Therefore, I am a bit unsure what to do with these suggestions. My idea is the following. I will merge right away the suggestions for the parts of the text that this PR was meant to change. Regarding the suggestions for the other parts (i.e., in Sections 6 and 7), I will keep them open for a few days and, unless I hear otherwise from any of the other editors, will then merge them later (mid next week).

Co-authored-by: Ted Thibodeau Jr <[email protected]>

gkellogg

Numerous small things; I'll follow on with a direct commit giving some of the rdf:HTML elements identifiers.

@TallTed's comments should not be lost, but probably belong in their own PR.

The suggested update to the rdf:JSON value space is a suggestion. It could be based directly on INFRA and ECMAScript (for number), but why repeat the work done in JSON-LD? I can push a more concrete update if agreed.

spec/index.html

…df:JSON to another list of datatypes.

spec/index.html

TallTed · 2023-09-18T15:50:13Z

[@hartig] at least half of @TallTed's change suggestion in this PR now are for text that was not supposed to be changed at all by this PR

[@gkellogg] @TallTed's comments should not be lost, but probably belong in their own PR.

I have no objection to those comments being moved to a different PR (with or without an issue, as I don't think those comments are controversial). It would be super if you could create that PR, as I'm not certain which comments you mean, and I don't want to lose any.

…e value space of rdf:JSON is updated from the original JSON-LD version

Co-authored-by: Ted Thibodeau Jr <[email protected]>

hartig · 2023-09-19T18:47:13Z

[@hartig] at least half of @TallTed's change suggestion in this PR now are for text that was not supposed to be changed at all by this PR

[@gkellogg] @TallTed's comments should not be lost, but probably belong in their own PR.

[@TallTed] I have no objection to those comments being moved to a different PR (with or without an issue, as I don't think those comments are controversial). It would be super if you could create that PR, as I'm not certain which comments you mean, and I don't want to lose any.

Since all of these small changes have been minor (mostly missing commas, correct use of plural vs singular, etc), I don't think it is worth the effort creating a separate PR and copying them all over. Therefore, I have merged them into this PR now.

pfps · 2023-09-19T19:09:09Z

The rdf:JSON datatype being added here appears to be very different from the rdf:JSON datatype in https://www.w3.org/TR/json-ld/#the-rdf-json-datatype

hartig · 2023-09-19T19:50:15Z

The rdf:JSON datatype being added here appears to be very different from the rdf:JSON datatype in https://www.w3.org/TR/json-ld/#the-rdf-json-datatype

I see that too now. Just to clarify: my original changes regarding the rdf:JSON datatype in this PR were only to insert an almost verbatim copy of the text of https://www.w3.org/TR/json-ld/#the-rdf-json-datatype into the rdf:JSON section in this document (rdf-concepts). Yet, it seems that @gkellogg's commits to this PR have edited the section quite a bit.

spec/index.html

pfps · 2023-09-19T20:35:04Z

There is no section 24.5 in the current ECMASCRIPT document.

spec/index.html

afs · 2023-09-19T20:59:21Z

it seems that @gkellogg's commits to this PR have edited the section quite a bit.

For reference - commit 8b5d09c and later commits.
The <a>string</a> reference changes meaning.

That also makes other changes e.g. i18n - probably inconsequential but mixed in.

afs · 2023-09-19T21:00:00Z

Why is the value space not the RFC8785 canonical mapping?

gkellogg · 2023-09-20T00:00:40Z

We discussed at TPAC that the value space of rdf:JSON being the canonical string representation was ill-considered by the JSON-LD WG and the value space really should be a JSON value (

Whose "we" because the RDF-star minutes don't reflect that.

I recall the discussion, both at TPAC, and from @pfps comments before. I had suggested that we "correct" the value space based on this notion. Of course, we can revert these changes and go back to the JSON-LD wording if there's not consensus. However, it was my understanding that using the JSON Canonicalization Scheme as the value space was wrong.

Don't we then deviate from the canonical form algorithm? (is there variance in the RFC canonical form for the same JSON structure?)

We don't deviate (intentionally) from the canonical form defined by JCS/RFC8785.

afs · 2023-09-20T07:41:13Z

from @pfps comments before

Links please. I don't see anything on #14.

Let's execute on this PR as originally given - which is editorial because the adoption of text from JSON-LD11 was already signallled.

That's "editorial". It can have all the non-rdf:JSON items thet have also been added.

Then a second PR which is "substantive", "needs discussion".

I am finding it very hard to get a detailed understanding of the substantive change on a fragmented PR.

While I'm not that enthusiastic about defining the a datatype value space based on canonical forms generally, it does work, uses the JSON community RFC 8785, and, for rdf:JSON, has been published.

I think that a new data model in RDF concepts for JSON has long term risks of differences to definitions elsewhere. I would like to see evidence that it does match the RFC 8785 canonicalization.

RFC 8259 (defn of JSON) does define an abstract syntax (parse tree) for JSON which could be considered a data model.

spec/index.html

Co-authored-by: Ted Thibodeau Jr <[email protected]>

…efined by JSON-LD 1.1. Note: this could be simplified by simply saying that the value space is an RDF string representing the lexical value using the JSON Canonicalization Scheme

gkellogg · 2023-09-20T21:43:43Z

@afs said:

I think that a new data model in RDF concepts for JSON has long term risks of differences to definitions elsewhere. I would like to see evidence that it does match the RFC 8785 canonicalization.

I reverted the changes to the rdf:JSON value space (although it does need to be updated to address the issue on using JCS, at least), and preserved the original commits for another PR. See 39cdf49.

As I said in the commit, the value space could be re-defined (without going to an INFRA representation) by being an RDF string representation conforming to the formatting requirements of the JSON Canonicalization Scheme [RFC8785].

Given differences in recollection of discussions, and likely more pressing matters, the WG should consider next steps. See #65.

TallTed · 2023-09-20T21:58:09Z

spec/index.html

-            <a data-cite="INFRA#map-value">values</a>, which may be any of the above
-            <a data-cite="RFC4627#section-2.1">JSON values</a>.</li>
+          <li>They MUST NOT contain any unnecessary whitespace.</li>
+          <li>Keys in objects MUST be ordered lexicographically.</li>


uh-oh. lexicographically, again?

The section can still be improved, but I was trying to just go back to the JSON-LD 1.1 definition. We can either improve that, or go in the native value-space suggested previously and in #65. At this point, the fewer moving parts the better.

Fewer moving parts is generally better, yes.

Still, we now know that lexicographical ordering is ambiguous at best, so I think we should replace that with the ordering we believe to be most unambiguous and closest to the original intent, which I think now means Unicode code point order (or something close to that).

pfps · 2023-09-20T23:30:50Z

Some minor comments on rdf:JSON datatype (definition mostly copied from JSON-LD). This is not an endorsement of the value space, as opposed to either having the value space just be the lexical space or having the value space being some sort of JSON values.

The value space should not have SHOULD. The value space is what it is.

The value space is defined as a set of RDF strings and then later claimed to be distinct from the value space of xsd:string. It would be better to state at the beginning that the value space is separate from the value space of xsd:string. In any case, JSON texts can include surrogate code points so the value space cannot be just RDF strings (assuming that surrogate code points stay out of RDF strings).

Lexicographic order needs to be very carefully defined. What is the underlying ordering?

What happens if there are duplicate keys in an array?

The lexical-to-value mapping uses ECMASCRIPT and thus coerces JSON numbers to ECMASCRIPT floating point. Why impose this limitation?

JSON has its own string escapes so it is possible to have double escaping in RDF serializations, as in '"\xDEAD"'. I think this is going to cause problems.

Co-authored-by: Ted Thibodeau Jr <[email protected]>

hartig · 2023-09-21T06:56:02Z

Just for the record I am happy with his PR now (I mention this because, as creator of it, I cannot mark it as approved). After merging it, there can be another PR to edit the section about the rdf:JSON datatype.

RFC4627 -> RFC8259

domel · 2023-09-16T19:48:18Z

spec/index.html

-    generalization of RDF triples.</p>
+      <dt id="JSON-lexical-space">The <a>lexical space</a></dt>
+      <dd>is the set of all <a>strings</a> that conform to the
+        <a data-cite="RFC4627#section-2">JSON Grammar</a> as described in


A link <a data-cite="RFC4627#section-2">JSON Grammar</a> duplicates the next lines. BTW, current version of JSON is defined in RFC8259

domel · 2023-09-16T19:50:10Z

spec/index.html

+      <dd>
+        is the space defined by
+        the <a data-cite="JSON-LD11#dfn-internal-representation">JSON-LD internal representation</a> [[JSON-LD11]],
+        being the <a data-cite="RFC4627#section-3">JSON values</a> <a data-lt="list">array</a>,


<a data-cite="RFC4627#section-3"> -> <a data-cite="RFC7159#section-3">

domel · 2023-09-16T19:50:53Z

spec/index.html

+            <a data-cite="INFRA#nulls">null</a>.</li>
+          <li><a>Map</a> <a data-cite="INFRA#map-key">keys</a> are <a>strings</a> with
+            <a data-cite="INFRA#map-value">values</a> may be any of the above
+            <a data-cite="RFC4627#section-3">JSON values</a>.</li>


<a data-cite="RFC4627#section-3"> -> <a data-cite="RFC7159#section-3">

domel · 2023-09-16T19:51:02Z

spec/index.html


+        Two <a data-cite="RFC4627#section-3">JSON values</a> are considered equal


<a data-cite="RFC4627#section-3"> -> <a data-cite="RFC7159#section-3">

domel · 2023-09-16T19:59:12Z

spec/index.html

+        <a>boolean</a>, or
+        <a data-cite="INFRA#nulls">null</a>,
+        if they are both an <a data-lt="list">array</a> with equal <a data-cite="INFRA#list-item">entries</a>, or
+        if they are both a <a>map</a> with equal <a data-cite="INFRA#map-entry">map entries</a>.


Why to mix ECMAScript spec, INFRA, and RFC4627/7159? Maybe it will be more consistent to refer only to one source (e.g. RFC7159)?

spec/index.html

hartig · 2023-09-21T14:33:08Z

@domel I think all (or almost all) of your recent comments are for an outdated version of this PR. In particular, they are for changes that @gkellogg had made in this PR which were later reverted (to be proposed in a new PR after this one here is merged).

domel · 2023-09-21T14:39:31Z

@domel I think all (or almost all) of your recent comments are for an outdated version of this PR. In particular, they are for changes that @gkellogg had made in this PR which were later reverted (to be proposed in a new PR after this one here is merged).

Yes, the last two I removed in the last commit.

spec/index.html

Co-authored-by: Ted Thibodeau Jr <[email protected]>

hartig · 2023-09-22T22:13:21Z

I will merge this one now to make way for @gkellogg to create the follow-up PR with his proposed changes to the section about the rdf:JSON datatype.

hartig added 2 commits September 13, 2023 08:53

adds an appendix for the additional datatypes and moves the sections …

d062a58

…about rdf:HTML and rdf:XMLLiteral into this appendix, as per #14 (comment)

adds a section that defines the rdf:JSON datatype, where the content …

a49b8d1

…of this section is copied directly from Sec.10.2 of JSON-LD11

hartig requested review from gkellogg and pchampin September 13, 2023 07:57

hartig mentioned this pull request Sep 13, 2023

Add the rdf:JSON datatype #14

Closed

TallTed suggested changes Sep 15, 2023

View reviewed changes

Minor edits to improve the text. Thanks @TallTed

99ca29f

Co-authored-by: Ted Thibodeau Jr <[email protected]>

gkellogg requested changes Sep 15, 2023

View reviewed changes

gkellogg added 2 commits September 15, 2023 16:22

Fix some duplicate identifiers, and add some that are missing. Adds r…

d38881a

…df:JSON to another list of datatypes.

HTML id for JSON lexical-to-value mapping

7ad84e6

gkellogg added the spec:editorial Minor change in the specification (markup, typo, informative text; class 1 or 2) label Sep 15, 2023

domel mentioned this pull request Sep 16, 2023

added rdf:JSON datatype w3c/rdf-schema#27

Merged

gkellogg added 2 commits September 16, 2023 09:31

Fix HTML syntax error.

8a256b4

Update value space of rdf:JSON.

8b5d09c

gkellogg reviewed Sep 17, 2023

View reviewed changes

spec/index.html Outdated Show resolved Hide resolved

Remove reference to JSON-LD internal representation, and note that th…

8eb80fd

…e value space of rdf:JSON is updated from the original JSON-LD version

gkellogg approved these changes Sep 18, 2023

View reviewed changes

Minor edits to improve the text in Sections 6 and 7

92767bb

Co-authored-by: Ted Thibodeau Jr <[email protected]>

afs reviewed Sep 19, 2023

View reviewed changes

spec/index.html Outdated Show resolved Hide resolved

spec/index.html Outdated Show resolved Hide resolved

afs reviewed Sep 19, 2023

View reviewed changes

spec/index.html Outdated Show resolved Hide resolved

afs reviewed Sep 19, 2023

View reviewed changes

spec/index.html Outdated Show resolved Hide resolved

Fixes to rdf:JSON datatype definition.

f767ad6

TallTed reviewed Sep 20, 2023

View reviewed changes

spec/index.html Outdated Show resolved Hide resolved

TallTed reviewed Sep 20, 2023

View reviewed changes

spec/index.html Outdated Show resolved Hide resolved

TallTed reviewed Sep 20, 2023

View reviewed changes

spec/index.html Outdated Show resolved Hide resolved

TallTed reviewed Sep 20, 2023

View reviewed changes

spec/index.html Outdated Show resolved Hide resolved

TallTed reviewed Sep 20, 2023

View reviewed changes

spec/index.html Outdated Show resolved Hide resolved

TallTed reviewed Sep 20, 2023

View reviewed changes

spec/index.html Outdated Show resolved Hide resolved

gkellogg and others added 2 commits September 20, 2023 14:11

rdf:JSON suggestions

3ebc9d5

Co-authored-by: Ted Thibodeau Jr <[email protected]>

Generally revert the definition of the rdf:JSON value space to that d…

39cdf49

…efined by JSON-LD 1.1. Note: this could be simplified by simply saying that the value space is an RDF string representing the lexical value using the JSON Canonicalization Scheme

gkellogg mentioned this pull request Sep 20, 2023

Value space of rdf:JSON datatype #65

Closed

TallTed reviewed Sep 20, 2023

View reviewed changes

A few small edits that improve how things are phrased.

2861559

Co-authored-by: Ted Thibodeau Jr <[email protected]>

remove orphan RFC4627

2d9a0bd

RFC4627 -> RFC8259

domel approved these changes Sep 21, 2023

View reviewed changes

TallTed reviewed Sep 21, 2023

View reviewed changes

spec/index.html Outdated Show resolved Hide resolved

TallTed reviewed Sep 21, 2023

View reviewed changes

spec/index.html Outdated Show resolved Hide resolved

TallTed reviewed Sep 21, 2023

View reviewed changes

spec/index.html Outdated Show resolved Hide resolved

TallTed reviewed Sep 21, 2023

View reviewed changes

spec/index.html Outdated Show resolved Hide resolved

More minor edits

40c1c01

Co-authored-by: Ted Thibodeau Jr <[email protected]>

afs approved these changes Sep 22, 2023

View reviewed changes

hartig merged commit 727d362 into main Sep 22, 2023

hartig deleted the Issue14 branch September 22, 2023 22:14

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Moves datatype definitions to an appendix and adds rdf:JSON datatype #62

Moves datatype definitions to an appendix and adds rdf:JSON datatype #62

hartig commented Sep 13, 2023 •

edited by pr-preview bot

Loading

domel commented Sep 13, 2023

hartig commented Sep 15, 2023

gkellogg left a comment

TallTed commented Sep 18, 2023

hartig commented Sep 19, 2023

pfps commented Sep 19, 2023

hartig commented Sep 19, 2023

pfps commented Sep 19, 2023

afs commented Sep 19, 2023 •

edited

Loading

afs commented Sep 19, 2023

gkellogg commented Sep 20, 2023

afs commented Sep 20, 2023 •

edited

Loading

gkellogg commented Sep 20, 2023

TallTed Sep 20, 2023

gkellogg Sep 20, 2023

TallTed Sep 21, 2023

pfps commented Sep 20, 2023

hartig commented Sep 21, 2023

domel Sep 16, 2023

domel Sep 16, 2023

domel Sep 16, 2023

domel Sep 16, 2023

domel Sep 16, 2023

hartig commented Sep 21, 2023

domel commented Sep 21, 2023

hartig commented Sep 22, 2023


		Two <a data-cite="RFC4627#section-3">JSON values</a> are considered equal

Moves datatype definitions to an appendix and adds rdf:JSON datatype #62

Moves datatype definitions to an appendix and adds rdf:JSON datatype #62

Conversation

hartig commented Sep 13, 2023 • edited by pr-preview bot Loading

domel commented Sep 13, 2023

hartig commented Sep 15, 2023

gkellogg left a comment

Choose a reason for hiding this comment

TallTed commented Sep 18, 2023

hartig commented Sep 19, 2023

pfps commented Sep 19, 2023

hartig commented Sep 19, 2023

pfps commented Sep 19, 2023

afs commented Sep 19, 2023 • edited Loading

afs commented Sep 19, 2023

gkellogg commented Sep 20, 2023

afs commented Sep 20, 2023 • edited Loading

gkellogg commented Sep 20, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pfps commented Sep 20, 2023

hartig commented Sep 21, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hartig commented Sep 21, 2023

domel commented Sep 21, 2023

hartig commented Sep 22, 2023

hartig commented Sep 13, 2023 •

edited by pr-preview bot

Loading

afs commented Sep 19, 2023 •

edited

Loading

afs commented Sep 20, 2023 •

edited

Loading