The W3C JSON-LD Community Group
Go Back
JSON-LD WG
Minutes for 2024-06-26
- Present
- Ted Thibodeau Jr., Gregg Kellogg, Benjamin Young, David I. Lehn, Niklas Lindström, Anatoly Scherbakov
- Chair(s)
- Benjamin Young
- Scribe(s)
- Gregg Kellogg, Benjamin Young
- Agenda
- https://www.w3.org/events/meetings/08563546-30fd-497a-ac16-77f96e96e8c0/20240626T120000/
- Topics
- Resolutions
Topic: Announcements and Introductions
Gregg Kellogg is scribing.
Benjamin Young: TPAC coming up in 3 months
Topic: rdf:JSON
Benjamin Young: Zakin, next item
Benjamin Young is scribing.
Benjamin Young: RDF 1.2 defining the rdf:JSON datatype https://github.com/w3c/rdf-concepts/pull/66
https://github.com/w3c/rdf-concepts/pull/66 -> Pull Request 66 Updates rdf:JSON value space. (by gkellogg) [spec:substantive]
Gregg Kellogg: There's a link to RDF concepts for defining the rdf:JSON datatype which was originally defined in JSON-LD 1.1
... this PR brings it formally into RDF
... the earlier JSON-LD 1.1 edition brought it into being, this PR improves upon the definition by clarifying various aspects
... one of the things being done is to change the value space to be based on INFRA datatypes
... as well as clarifying the number datatype as xsd:double
... the discussion has been going on for sometime, but there's now a formal request for the JSON-LD WG to weigh in
... and to point to this newer definition in JSON-LD 1.2 (when that comes into being)
... canonicalization is not usually part of a datatype
... but there is a push for using JCS
... however, there's a mismatch in number datatypes
... because xsd:double could hold values which are not representable in a JCS canonicalized JSON document (such as positive and negative zero).
... but my hope is that this will still be what we reference in JSON-LD 1.2
Ted Thibodeau Jr.: +1 Gkellogg
Niklas Lindström: Nothing to add. I think this hardens things. So +1.
PROPOSAL: the JSON-LD will adopt the rdf
Niklas Lindström: +1
Anatoly Scherbakov: +1
Benjamin Young: +1
Gregg Kellogg: +1
Ted Thibodeau Jr.: +1
David I. Lehn: +1
David I. Lehn: Does this break anything?
RESOLUTION: the JSON-LD will adopt the rdf:JSON datatype as defined in https://github.com/w3c/rdf-concepts/pull/66 as the basis for work on JSON-LD 1.2.
Gregg Kellogg: JSON-LD 1.1 is already pretty much I-JSON...just not formally
https://github.com/w3c/rdf-concepts/pull/66 -> Pull Request 66 Updates rdf:JSON value space. (by gkellogg) [spec:substantive]
... essentially nothing outside of I-JSON can meaningfully be referenced in JSON and round tripped
... so really this is about clarifying things
Gregg Kellogg: One thing that isn't defined is sort order for SPARQL results
... in 1.1 sort order was easier because we had a canonicalized string
... when we switch to INFRA that gets harder
... using JCS would simplify that
... or use a recursive ordering
... but that could create an incompatibility...but not in JSON-LD because we never specified anything about sort order.
Benjamin Young: Is the definition in 1.1 close enough to IJSON that we could say that IJSON is an erratum?
Gregg Kellogg: Don't think it's an erratum.
Gregg Kellogg: Not something we'd change in 1.1. We'd focus on 1.2
Ted Thibodeau Jr.: It may be useful to point people trying to make regorous definitions in RDF to bring those concerns to the documents we're based on (e.g. I-JSON)
... It's unclear to me where these issues should be raised.
Gregg Kellogg: Getting an erratum to I-JSON shouldn't be difficult.
Ted Thibodeau Jr.: Also see I-JSON Errata - https://www.rfc-editor.org/errata/rfc7493
> I-JSON messages SHOULD NOT include numbers that express greater magnitude or precision than an IEEE 754 double precision number provides, for example, 1E400 or 3.141592653589793238462643383279.
Gregg Kellogg: We would need to raise an error when canonicalizing values with infinites.
Gregg Kellogg: JSON canonicalization does not effect RDF dataset canonicalization
... if we are canonicalizing, the question is if we canonicalize values
... XSD defines these, but RDF does not
... so for JSON literals, the JSON may be written differently and result in identical values
Benjamin Young: So this is mostly in our API, correct?
https://github.com/w3c/rdf-concepts/pull/66 -> Pull Request 66 Updates rdf:JSON value space. (by gkellogg) [spec:substantive]
Gregg Kellogg: Yes, with some syntax doc leftovers
Topic: TPAC
Benjamin Young: Who's coming?
Ted Thibodeau Jr.: I probably won't be there in person, but will be remotely.
Gregg Kellogg: I'll be there in person.
David I. Lehn: Probably not in person, but remote
Niklas Lindström: I'll attend remotely.
Anatoly Scherbakov: I'll try to connect remotely.
Benjamin Young: Shares TPAC schedule.
... We have a joint meeting Monday afternoon with the Spacial Data on the Web WG.
... Other meetings are Thursday and Friday, which have some conflicts.
... Not sure its feasible to move afternoon meetings to the morning.
... The times are not great for east coast and europe.
... gkellogg & I can work with chairs of other groups to come up with agendas
... The WoT group doesn't usually have any big issues.
... We can start to work up agenda items for our meetings and see if that helps in figuring out scheduling.
... Might see of WoT could go Friday morning instead of Thursday afternoon.
Topic: YAML-LD
Anatoly Scherbakov: Noting particular to discuss. I'm working on some tests.
... I approved a PR that fixes some tests.
... I think there may be an API contradiction, though. It says that expand() should export a JSON serialization, but practically, this is typically not done.
... There's a JSON-LD Record type which indicates that it is values.
Gregg Kellogg: Need an erratum on serializing JSON-LD API to actually serialize
... Serialization often happens later based on the Content-Type.
Gregg Kellogg: I'm not sure. In so much as those use JSON-LD, you want the data structure
... yet when using those API endpoints, you expect back JSON...or maybe you don't?...
... maybe that's not strictly part of the API
... which would push things into JSON and then JSON-LD
Anatoly Scherbakov: Does the API then need to return JSON?
... In some contexts it's useful to post-process the results before serializing.
... This applies even more to YAML-LD, as you have more choices in how to serialize lists, for example.
Gregg Kellogg: We need an issue to track and discuss
https://github.com/w3c/json-ld-api/issues/603 -> Issue 603 toRdf() and flatten() API require extractAllScripts to default to true (by gkellogg) [spec:enhancement] [needs discussion] [ErratumRaised]
Gregg Kellogg: I noticed when running some YAML-LD tests, that I was getting unexpected results
... there is text in the syntax document that when using `extractAllScripts()` should use `true` when running `toRDF()`
... there's a mismatch with YAML-LD's parsing
... and it's unclear about wrapping things into an `@graph` container
... we should consider the output of `flatten()` to use `extractAllScripts()` to use `false`...which would break all the implementations
Gregg Kellogg: Basically, we're inconsistent with our use of `extractAllScripts()`
... the expectation is that all the scripts would be combined and then handled
... but how things merge (or don't) into a top-level `@graph` causes the confusion
... we should instead move to `@included` which avoids the confusion
Gregg Kellogg: Can we break tests to fix behavior?
Anatoly Scherbakov: Can we do this? Or, only in JSON-LD 1.2?
Gregg Kellogg: I think we need to determine if it's OK to make normative changes that break tests
Benjamin Young: In 1.2?
Gregg Kellogg: Yes...can we cause incompatibility
Anatoly Scherbakov: I was going to suggest changing to use default false in all cases.
Anatoly Scherbakov: I was going to suggest we augment the YAML-LD spec to handle it on it's own and state that we expect JSON-LD v1.2 to handle it better in the future
Gregg Kellogg: Currently, 1.1 `extractAllScripts()` is true, but the test results go the other way
... to preserve compatibility, we'd have flatten and toRDF switch to true
Ted Thibodeau Jr.: Let's not fret about test results
... if we're causing BC breaks, though...then we're going to need a 2.0...
... the default has to remain the same
Ted Thibodeau Jr.: We shouldn't focus on test results. If we make a change normative language that would break existing implementations, that needs to be 2.0.
... We can say that it produces the wrong results; that won't break backwards compatibility.
Anatoly Scherbakov: The extractAllScripts options bugs me because the interface is not sound in terms of the type system.
... What if we split expand into two functions: expandOne and expandAll?
Benjamin Young: We'll need to confront choices of the past eventually.
Zakin, next item
Topic: JSON-LD
Topic: Open Discussion
Benjamin Young: There's a minor thing: classic GitHub Projects are going away.
Gregg Kellogg: We should switch to the new one.
Benjamin Young: I think we should have another WG call in July and August, and CG calls as well.
... Next call will be a CG call on July 10th.