The W3C JSON-LD Community Group

Go Back

W3C Logo

JSON-LD WG

Minutes for 2025-06-04

Present
Gregg Kellogg, Pierre-Antoine Champin, Anatoly Scherbakov, Niklas Lindström, Ivan Herman, Ted Thibodeau Jr., David I. Lehn
Chair(s)
Gregg Kellogg, Benjamin Young
Scribe(s)
Gregg Kellogg, Benjamin Young
Agenda
https://www.w3.org/events/meetings/de8e5953-703c-45c4-b0ad-fc02d6804a4d/20250604T120000/
Topics
  1. Announcements and Introductions
  2. JSON-LD Issue Discussion
  3. Charter
Resolutions
  1. Close w3c/json-ld-api#659 with no change, as the ability to get the native form out of the API gets around the duplication.
Gregg Kellogg is scribing.

Topic: Announcements and Introductions

Benjamin Young: We've just merged the new playground onto the website.
... I need to implement hash fragment/query string parsing.
... After that, we can move out the old one and switch to this as the primary.
... It's missing the visualization bits; wanted to see how important people thought it was.
Benjamin Young is scribing.
Gregg Kellogg: It's great to see evolution
Pierre-Antoine Champin: +1 I have tested it a bit, and it is a very nice improvement
Benjamin Young: This can be a foundation for the future.
... Probably still some bugs.
... I'll make issues for YAML-LD/CBOR-LD inputs.
Gregg Kellogg: We likely will meet.
... we usually do
... might be a good way to get folks updated and pin down some of these issues
... likely it's related how we do on rechartering by then

Topic: JSON-LD Issue Discussion

Subtopic: w3c/json-ld-api#650

https://github.com/w3c/json-ld-api/pull/650 -> Pull Request 650 #648 `0027-out.jsonld`: `@graph` and value objects (by anatoly-scherbakov) [test:missing-coverage]
Anatoly Scherbakov: Someone said that `@graph` is not required, but it is in the test.
... Changes pchampin proposed have been taken care of.
Pierre-Antoine Champin: It doesn't seem that my suggestions were merged.
... This touches two files, and the changes seem unrelated.
... The HTML manifest has been changed.
Anatoly Scherbakov: I don't know why the manifest changes are here.
Gregg Kellogg: The technology hasn't changed much, so this could be a bug in the manifest
... I'm going to try removing the changes to the HTML manifest.
Pierre-Antoine Champin: I was looking at the individual commits; I suspect that the change to the HTML manifest was not done by anatoly-scherbakov,
Anatoly Scherbakov: Changes are done by the bot.
Pierre-Antoine Champin: The issue is that I don't see why there's a change.

Subtopic: w3c/json-ld-api#655

https://github.com/w3c/json-ld-api/pull/655 -> Pull Request 655 Tests t0112 and t0113 use 1.1-specific features (by gkellogg) [test:missing-coverage]
Gregg Kellogg: This one was based upon an inbound issue
... whether or not `@graph` is necessary at some point
... these are related to 1.1 features which are meant to be tested against 1.0 and 1.1 implementations
... this change prevents them running against 1.0 implementations
Benjamin Young: And look! there's that change again
Pierre-Antoine Champin: Yeah. that's it.
Gregg Kellogg: It changed the `fromRDF-manifest.html`
... there must have been a change to the turtle manifest
... the issue is because the bot is not able to push commits to external repositories
... the purpose of the bot is to update all the things related to changes to the turtle manifest
... but if a change is made outside a branch, then the bot will not do it's work
... it should be a self correcting issue
... if we wanted to be clever, we could have a bot check all the manifests for consistency
... but the system will eventually stabalize
Benjamin Young: If we merge 655 cold lead to a conflict
https://github.com/w3c/json-ld-api/pull/655 -> Pull Request 655 Tests t0112 and t0113 use 1.1-specific features (by gkellogg) [test:missing-coverage]
Gregg Kellogg: Shouldn't.
... Generally don't like to use merge commits.

Subtopic: json-ld/json-ld-star#61

https://github.com/json-ld/json-ld-star/pull/61 -> Pull Request 61 Updated test results for JSON-LD-star (by gkellogg)
Gregg Kellogg: This is another call for review of this one
... I do see some feedback from pchampin and he's done a partial review
... the goal is to update JSON-LD-star to catch-up with where RDF 1.2 is
... so, rather than updating the spec, I've updated the tests
... and put in an abbreviated summary of what the changes would be
... so once that's approved, we can work on spec text changes
Benjamin Young: These will need to be <ins>/<del> denoted changes?
Gregg Kellogg: No, this is on json-ld-star which is a CG report
... so this doesn't disrupt that
... there will, however, be needed work to merge the json-ld-star stuff into the main json-ld-syntax
David I. Lehn: ...There are a lot of test files...
Gregg Kellogg: Yeah...we're heavy on files
... and maybe a rework would take a different approach
... but as monumental a task as that would be, we're likely better off sticking with what we have now
... I would, however, like to annotate our spec pointing back to the tests
... I've done it elsewhere, but it'd be great here
... YAML-LD does that
... thanks to a push by ivan who did that for publishing WG
Ted Thibodeau Jr.: *Cheers* for the gradual annotating / crosslinking
Niklas Lindström: I prefer to work like this than update the algorithms; it's easier for me.
... It would be catagorize tests with those that are more useful.
David I. Lehn: Ordering would be nice, but tagging might be appropriate.
Gregg Kellogg: Ideally every normative statemen links back to their tests
... but it can be challenging
Ivan Herman: We did it for ePub and it turned out to be extremely useful.
... When we had to report back on the PR, we could easily prove that we had a proper test suite.
... It's a heavy setup; The WebAPI people did it well, but I had to add some scripts to address assumptions in ReSpec.
Gregg Kellogg: I've been copying pasting from what you've been doing
... there's now a script that does much of the work for me
... it can identify the tests and make links back
... and it can be done asynchronously
... a test repo can iterate separately from the spec
... we have at least 3 specs here and each have their own test suites
... but maybe we could merge them

Subtopic: w3c/json-ld-api#558

https://github.com/w3c/json-ld-api/issues/558 -> Issue 558 Compaction cannot round-trip terms using `@container: @list` and `@type: @vocab` (by niklasl) [spec:enhancement] [spec:substantive] [ErratumRaised] [class-3]
Niklas Lindström: I started a PR for this, but am not quite ready for it yet.

Subtopic: w3c/json-ld-api#638

https://github.com/w3c/json-ld-api/pull/638 -> Pull Request 638 address #630 (by pchampin) [needs discussion] [class-2]
Pierre-Antoine Champin: This is about inverse context creation.
... I thought it was ambiguous in the definition of the active context.
... I tried to improve it without restructuring the document, which meant changing something in the terminology section.
... The end result is not 100% satisfying, as change to terminology is big.
... It's also inherited in other documents, so we need to mark changes in other documents, even though it's only in JSON-LD API.
Benjamin Young: Thoughts? especially on the size of the change?
Benjamin Young: Looks like some validation errors.
Gregg Kellogg: I think it's good to go
... and I plan to make similar ones in the other specs
... so once we get the validation error fixed, we can merge this and make the others
Benjamin Young: Do we need to synchronize those changes across the specs?
Gregg Kellogg: The json-ld-commons repository is where the term changes would happen
... and then that would be copied back out to the individual spec repos
... and if we don't, then the github action will complain
... pchampin can you look at the markup issues?
Pierre-Antoine Champin: Yep

Subtopic: w3c/json-ld-api#648

https://github.com/w3c/json-ld-api/issues/648 -> CLOSED Issue 648 Error in fromRdf/0027-out.jsonld (by marcelotto)

Subtopic: w3c/json-ld-api#659

https://github.com/w3c/json-ld-api/issues/659 -> Issue 659 Compacted form for the "Serialize RDF as JSON-LD Algorithm" (by multimeric)
Gregg Kellogg: This was a request related to flattening and framing
... that implies that maybe we could add some options to flattening
... my response was that recent changes should make it easier to get the original representation
... so stringing these algorithms together is still possible, but can now be shortened
... so I'd suggest we close this with no change
PROPOSAL: Close w3c/json-ld-api#659 with no change, as the ability to get the native form out of the API gets around the duplication.
Pierre-Antoine Champin: +1
Gregg Kellogg: Since this is really on the RDF side, my code handles it there
... it makes use of the JSON-LD algorithm
Niklas Lindström: +1
... for instance, I can pass in prefix mapping and use it later with contexts and frames
... I think trying to be a swiss army knife in the spec is not helpul
Gregg Kellogg: +1
Ivan Herman: +1
... and this should be left to implementations
Benjamin Young: +1
Anatoly Scherbakov: +1
RESOLUTION: Close w3c/json-ld-api#659 with no change, as the ability to get the native form out of the API gets around the duplication.
https://github.com/w3c/json-ld-api/issues/659 -> Issue 659 Compacted form for the "Serialize RDF as JSON-LD Algorithm" (by multimeric)
Gregg Kellogg: Shall we look at a few more?
... anything specific someone wants to discuss?

Topic: Charter

Pierre-Antoine Champin:
Pierre-Antoine Champin: It might be useful to discuss rechartering.
... Talking with Ivan, CBOR-LD is going to become a dependency.
Ivan Herman: It's necessary for VCs.
Pierre-Antoine Champin: I haven't been too efficient on rechartering, I'll see what might be keeping us from moving forward.
Benjamin Young: The CBOR-LD registry repo has been moved in the JSON-LD CG org. There's now an IANA registration.
Pierre-Antoine Champin: I/pchampin: It might be useful to discuss rechartering./Topic: rechartering
... manu explained the vision for it and someone will be coming on in an upcoming meeting to discuss.
... I think the VC related (VPQR) is CBOR-LD turned into a QR code with some text.
Ivan Herman: We need to discuss how we do that as a working group. I'm a bit worried if we have a working group that does JSON- YAML- and CBOR-LD which can be complex.
... We'll also have a problem with cross registering.
... An alternative would be to create separate working groups, and charter it tightly, then it won't become a bottleneck for other groups.
Benjamin Young: The cross-referencing concern is in between specs in the same WG.
Ivan Herman: We have a problem for this now.
... If we get into some VC issues that depend on CBOR-LD, it could lead to a problem.
... The counter argument is that if we have small WGs the community could be spread thin.
Benjamin Young: I thought we were solving the cross-team problems by having them in one group.
Ivan Herman: I'm worried about dragging on.
Gregg Kellogg: I think specifically with CBOR-LD work has really been done by folks who are not working on JSON-LD or YAML-LD
... so in that sense, it has already been a separate group
... so we could formalize that
... but it would very much need liaison requirements
... and that we should focus on cross-compatibility and not just compression
... I would be in support, then, for a CBOR-LD group with liaison
Benjamin Young: I think you're right that CBOR-LD has already been separated from this group.
... I think prior to that, we're going to need to have a conversation about what CBOR-LD is, is it an -LD format, or just a compression format?
... If it's its own working group, we're going to need to justify that.
... Generally, you need JSON-LD.
... I've reached out to more active CBOR-LD contributors for discussion.
... if it's its own charter, it may generate interest, but not result in good coordination.