The W3C JSON-LD Community Group

Go Back

W3C Logo

JSON-LD CG

Minutes for 2025-05-07

Present
Benjamin Young, Pierre-Antoine Champin, Ivan Herman, Niklas Lindström, Gregg Kellogg, David I. Lehn, Ted Thibodeau Jr.
Chair(s)
Gregg Kellogg
Scribe(s)
Benjamin Young, Gregg Kellogg
Agenda
https://www.w3.org/events/meetings/c7ab3fcd-4dc4-4444-ae8a-c91ca2131113/20250507T120000/
Topics
  1. Announcements and Introductions
  2. JSON-LD Issue Discussion
Benjamin Young is scribing.

Topic: Announcements and Introductions

Benjamin Young: Wes Smith is here to say a few words about CBOR-LD during the announcements section
Pierre-Antoine Champin: There's a big hype currently around AI agents and protocols for them to communicate with each other
... this one, ANP, is such an AI agent protocol
... it uses DIDs and JSON-LD
... so it might be interesting to reach out to those people and have a talk with them
Gregg Kellogg: Is this affiliated with some standards group? or is it open source?
Pierre-Antoine Champin: It looks to be open source from China
... I found out about it from a Chinese contact at the W3C
... they are willing to get closer to the W3C and collaborate more
Gregg Kellogg: So, perhaps we can have them attend our next call and make that one a CG meeting
Pierre-Antoine Champin: I'll reach out!
Gregg Kellogg: Wes-smith did you have something to share?
Wesley Smith: I have a couple updates about CBOR tags related to CBOR-LD
... we use CBOR tags to denote that the CBOR is actually CBOR-LD
... the IETF folks felt that registering a range was not viable
... so we moved to using a single entry instead
... which they accepted!
Wesley Smith: Tag: 51997
Wesley Smith: (0Xcb1d)
... so that means we can more easily move forward
... we've started making changes to the CBOR-LD spec to match this
... and that means it's officially registered
Gregg Kellogg: That's great
... I do think there's more we need to do to make CBOR-LD work a bit more like YAML-LD
... so you can start with CBOR-LD rather than always going through JSON-LD
... I do need to look at the state of the document
... CBOR-LD seems to mostly be focused on compression
Gregg Kellogg is scribing.
Benjamin Young: I understand that CBOR-LD is not an LD format; it's just about compressing JSON-LD, you're supposed to round-trip through JSON-LD.
... We'll need to put something into the spec in this regard.
Wesley Smith: We currently use processing modes
... which is currently focused on compression
... but if we wanted it to have more LD processing, those could be additional modes
... so maybe we can talk about that more in the future
Gregg Kellogg: Speaking on my own here, but we do call it CBOR-LD which makes it sound like an LD format
... and the LD family of specs include a shared modeling
... and compression would in theory be laid on top of the JSON-LD compression algorithm
... maybe that's not how it works
... but I do wonder if it makes sense to be able to have CBOR-LD expanded forms and the like
... it was pretty simple to do this for YAML-LD, so perhaps we can explore it CBOR-LD
... so we can be sure we can really treat it and call it an LD
... and if not, perhaps we consider a different name if LD sends the wrong message
Wesley Smith: I agree. It's likely an open question
... so do we have CBOR for Linked Data or Linked Data in CBOR
... I'm not up to speed on the other processing modes, etc.
... I do think it's an interesting question
Gregg Kellogg: Perhaps we can make an issue for that
... the spec work is minimal, but the tests may be a pain
... so, the hard work is probably in everything around the spec
Wesley Smith: Sounds good
Gregg Kellogg: Anything else on this one?
Anatoly Scherbakov: I don't think we actually duplicated tests for YAML-LD
... since YAML is a superset of JSON, we didn't really have to convert anything
... we did add a few YAML-LD specific tests
Gregg Kellogg: Yeah, I don't think we can have the same expectation here
... but maybe the group decides it's not worth supporting all those processing modes
... and perhaps just clarify the naming
... k. moving on
Wesley Smith: Just a note on the naming
... even in it's compressed form, it's not loosing it's LD meaning
... CBOR-LD does maintain it's LD encoding even when compressed

Topic: JSON-LD Issue Discussion

Gregg Kellogg: Yeah, I think this is a meta discussion
Benjamin Young: Json-ld.org went down a couple of weeks ago, and we couldn't figure out why.
... Fortunately, we had a replacement waiting on approval. dlehn and I decided that this was the perfect time to launch that site.
... The 11ty site is now up, faster, and much easier to maintain.
... There's also a new playground in the works, with the objective to be able to include YAML-LD and CBOR-LD in the playground.
... The version of codemirror we were using was ancient.
... The old code was too hard to work with. We can then cascade the new design to other pages after that.
Gregg Kellogg: I'll put up a little plug in for or lobby a bit more for other RDF formats
... I'd like to see Turtle, NQuads, and the like to be able to be added to the Playground as input
... so one could convert to JSON-LD, YAML-LD, etc.
Benjamin Young: We need to get back to feature parity then add other RDF formats.
Benjamin Young: I've been converting discussion issues into GH discussions.
... Many are questions and answers, not really issues. There are some which are ideas for future development.
... GH closes and locks the issue, but points to the discussion.
Ted Thibodeau Jr.: I really don't like GitHub Discussions
... they're all single threaded commentary
... where there were threads of conversations, they now look very different
... I'm not going to fight you about it
... but I find them less than useful
... that's it
Gregg Kellogg: We do act as an information resource.
... ideally, they'll continue to reach out to us on json-ld.org
... and we need to do something with all that content
... I expect that the conversion is likely lossy
... but new conversations will better use that interface
... and if we don't do this conversion, we'll continue to drown in issues
... sadly we don't have a better feature to hang things on
Niklas Lindström: I wanted to bring this issue from 2022 to our attention
... this has the `erratum-raised` label
... but I couldn't find it
Gregg Kellogg: It should be in the errata column
Niklas Lindström: I looked, but didn't find it
Pierre-Antoine Champin: I think `erratum-raised` doesn't populate that list, only `errata`
Gregg Kellogg: It thought they'd be there...but maybe not. I don't see that on either
... maybe we can remove it and add it back manually?
Niklas Lindström: Maybe we can look at it a bit regardless
... I found this via another issue I filed 3 days ago or so
... I thought it was a bug in my implementation
... but I think maybe fixing these problems with node map generation may be enough
... I do have another PR I need to make for another issue
... and hopefully I can also make one for this
... at which point that may be a better time to discuss it
Gregg Kellogg: Do keep in mind we're needing to use <ins> and <del>
... it starts off annoying, but the more you do it the more satisfying it becomes
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: K. I'll try to remember to do that
... sadly, I don't think I can get ChatGPT to help me with the markup
Gregg Kellogg: So, now to climb out of the backlog...
... we still have a number of discuss-call issues
The first I see is 443

Subtopic: https://github.com/w3c/json-ld-syntax/issues/443

https://github.com/w3c/json-ld-syntax/issues/443 -> Issue 443 `@protected` creates unresolvable conflicts when conforming to multiple normative contexts (by trwnh) [spec:editorial] [propose closing] [wr:commenter-agreed-partial] [class-2]
Gregg Kellogg: I suggested we close this issue in February
... there's a resolution from last November on it
We'll close the issue.
... so, if there are no objections, I think we can close this one and move on
Niklas Lindström: +1
Benjamin Young: +1

Subtopic: w3c/json-ld-api#558

Issue 558 not found
Gregg Kellogg: Anyone want to discuss this one?
Niklas Lindström: I just need to make this PR
We'll work on a PR for this.
... if anyone has some time to look at it, that'd be helpful
Gregg Kellogg: Is there an existing PR?
Niklas Lindström: No, I'm transcribing back from Python into human language
Gregg Kellogg: So that one PR should close both issues?
Niklas Lindström: No, this will be another PR
Gregg Kellogg: Any one have specific issues they want to discuss?
... looking for a way to prioritize these
... I do wonder if we need a CBOR-LD column
... pchampin what would it take to do that
Gregg Kellogg: We could setup some automation related to labels also
Pierre-Antoine Champin: Yeah, I'll look into that
Niklas Lindström:
Niklas Lindström: I have a similarly orthogonal issue
... I've been tinkering on what we will likely no longer call JSON-LD-star
... I know pchampin and gkellogg have done a good bit of work in that other repo
... but I do wonder about timing and the like
... I do think we've said that JSON-LD 1.2 will support RDF 1.2
Gregg Kellogg: Indeed. One of the goals of JSON-LD 1.2 is to track with RDF 1.2
... now the RDF and SPARQL 1.2 group...is that our name now?
Pierre-Antoine Champin: Yes, almost, but no version number
Gregg Kellogg: Right. So the RDF and SPARQL WG is already working on v1.2 of both of those
... that said, we do have a JSON-LD-star repo that is now way out of date
... so I think my thought is that since this will all be new in 1.2
... this is a big task we need to address
... such as changing the algorithms, etc.
... the hope is to make all this easier for when we can finally work on JSON-LD 1.2 proper
... I do think there are issues in there around how to do most of those things
... things such as triple terms, reification triples, and annotations
... I believe it's all there, but we need implementations and spec text
Gregg Kellogg: ...Yes, and tests
... we do tend to duplicate tests for every different processing moment
... which makes it a combinatorial problem
... and folks have asked for more linear testing
... the algorithms should be clear
... but we have taken some license with some of our internal terms that we're still trying to clean out

Subtopic: https://github.com/json-ld/yaml-ld/issues/158

https://github.com/json-ld/yaml-ld/issues/158 -> Issue 158 YAML-LD tools (by VladimirAlexiev)
Gregg Kellogg: K. looking at YAML-LD 158
Anatoly Scherbakov: Maybe this should actually be a discussion
Gregg Kellogg: If this is about highlighting tooling, then perhaps this goes on the json-ld.org site
... with more LD formats, we likely need more sections for tools
... and we can test out how easy the new site works
Anatoly Scherbakov: I don't know how the new 11ty site works, but I would like to help
... I believe both pchampin and gkellogg have implementations
Benjamin Young: Now the developers link goes to a section on the homepage; we could create a developers page that does this.
... The site is 11ty based, but is mostly just markdown.
... The current index.yaml file encodes the implementations and is, itself, a YAML-LD file.
... We can expand that to include YAML-LD implementations.

Subtopic: https://github.com/w3c/json-ld-api/issues/651

https://github.com/w3c/json-ld-api/issues/651 -> Issue 651 scoped context does not work for aliases of `@type` (by pchampin) [class-3]
Gregg Kellogg: Pchampin you raised this one?
Pierre-Antoine Champin: Yeah...I found this counter intuitive, but having the intuitive change would require serious changes
Gregg Kellogg: K. I moved it to future work
... looks like we're out of time this week
... we'll work to get the WG and CG calls in sync again
... and see if we can get the folks from https://agent-network-protocol.com/ to join us for a call
... thanks all, good bye