The W3C JSON-LD Community Group

Go Back

W3C Logo

JSON-LD WG

Minutes for 2025-07-02

Present
Gregg Kellogg, Victor Lu, Niklas Lindström, Ted Thibodeau Jr., Dave Longley, Benjamin Young, Anatoly Scherbakov
Chair(s)
Benjamin Young
Scribe(s)
Gregg Kellogg, Benjamin Young
Agenda
https://www.w3.org/events/meetings/04e937c0-e751-4c7e-9ba4-5782e0b3d272/20250702T120000/
Topics
  1. Announcements and Introductions
  2. Rechartering
Gregg Kellogg is scribing.

Topic: Announcements and Introductions

Benjamin Young: Call is mostly about chartering.
Manu Sporny: VC 2.0 is now a standard, which uses JSON-LD.
... We have some large production deployments going out.
... Yesterday, there was a presentation in the VC CG around using the VC supply chain. The UN has UNIEC, and the idea is to publish JSON-LD as linked data.
... This makes JSON-LD and RDF central underpinning technology for a fair amount of world trade.
... The current feature set works well.
... Secondly, the data integrity group using looking at quantum cryptography, and looking to use zero-knowledge in graphs.
... We need to do that in a post-quantum world, as elliptic curve can be broken by quantum.
... The use case would be to query RDF graphs to query for a proof of some fact, such as age or license.
... You'd run a sparql query on a graph you download and be able to prove locally.
... There is other RDF/crypto work going on as well.
Victor Lu: JSON-LD has become huge in our community.
Manu Sporny: SPDX
Benjamin Young: SPDX using JSON-LD is great!
... Is there a place for us to watch progress on some of the things manu mentioned?
Manu Sporny: There is a summary every week in the data integrity CG.
... RDF-star may help in some cases, but it's not clear exactly how.
... Note that this is leading-edge research right now, and it could be a couple of years before something concrete emerges.
... Using SPARQL and ZKP is just emerging.
Benjamin Young: We can make data integrity a topic of a future CG call.
... I believe victor_lu is in the CG, but not the WG right now.
Ted Thibodeau Jr.: Chair's desecration for observers.
Victor Lu: Love to join the WG.
Benjamin Young: Decisions need to be made by WG members.

Topic: Rechartering

Benjamin Young: Main thing to focus on today is the charter. This draft has been a work in progress, and we've been working on the scope.
... In discussions, we've discussed where CBOR-LD and YAML-LD fit.
... iherman raised the idea of their being multiple WGs.
... If we're doing multiple formats, we want to rename to something like "Linked Data Formats WG".
Manu Sporny: Generally, we'd rather not have multiple working groups. It's helpful for all the formats to feed off of each other.
... There are lessons from YAML-LD that inform JSON-LD and CBOR-LD.
... Smaller groups would split attention and create a bigger demand on time.
... We're -1 on separate WGs, from an availability prespective.
... +1 to broadening the scope of the group to consider related formats.
Dave Longley: +1 To what manu is saying ... we should preventing setting up barriers between the format designs/discussion and avoid duplicating overhead with multiple groups that likely have very similar members
... It would also reduce staff effort. If it's getting out of hand, we look back to the charter.
... Right now, the charter is arguably too narrow. It will be a lot of work, but the specs feel pretty mature.
... YAML-LD is mature, and CBOR-LD is getting there.
... There are LD-adjacent things to think about.
... Maybe not data integrity, or canonicalization.
... There are things that W3C needs to think about on how we're going to maintain these work items.
Dave Longley: +1 To Linked Data Formats WG approach
Benjamin Young: I'm in favor of the LD formats approach, vs chopping the group down to multiple pieces.
... related to a LD formats WG, it would be worth considering what other specs might be worth considering.
... A perenial request is a hash-based context.
Benjamin Young is scribing.
Dave Longley: +1 To producing a solution to the hash-based context problem in this iteration
Gregg Kellogg: Some of ivan's thoughts seemed to be around CBOR-LD being mostly by Digital Bazaar with periodic check-ins
... vs. work being done by the Community Group per se
... so he was presenting that CBOR-LD already was a bit like a separate group alreayd
... but it would be far simpler if it were just one group
... especially around interrelated dependencies
Dave Longley: +1 To avoid the dependency overhead (and there is other overhead) Gregg is warning against and +1 to task forces within the same WG
... it may also be better to explore task forces instead
Niklas Lindström: +1 For task forces
... as long as those sub groups bring their work to the larger group
Benjamin Young: The task force works well in other groups, and could be pragmatic for us.
Manu Sporny: +1 To Task Forces if necessary... the reason we want a WG is broader/wider review before moving forward.
Manu Sporny: I agree that we don't want the dependency overhead. We'd really like more WG input on CBOR-LD. Breaking the group up would go against that.
... We're seeking broader review, and don't want to be in a group that limits review.
Gregg Kellogg: We should also consider potential headwinds from the TAG or others
Manu Sporny: I haven't heard anything about concerns about our anticipated charter.
... There are some people that have positions that are not fully on board, that that ship has sailed given the extremely broad use of JSON-LD.
... Hard to imagine that any possible objections that could overcome that.
... Until we hear something more concrete, we should proceed with our direction.
... It's easier to make a strong argument for the work today, than it was 10 years ago.
... It would be strange for the W3C to not participate in something that affects so large a part of the human population.
Niklas Lindström: I agree with the discussion so far. I was thinking what the data formats we work on have in common.
... The first formulation was a bit ambitious. One of the selling points of JSON-LD, without gettin into semantics, is that it has a semantics-preserving property.
... That is lacking in virtually any other data format.
... The closest thing would be resolving links to the same IRI.
Manu Sporny: +1 To what niklasl said... agree that is one of the things that's at the core of it.
Benjamin Young: The distinction between CBOR-LD and the others came up.
... YAML-LD is very directly linked to JSON-LD.
Dave Longley: (Side note: one of the key features of JSON-LD/Linked Data to me has been the capability to scale to parties you don't know (because it is self-describing) ... which is really important for use cases like the VC use cases with the "three party model")
... CBOR-LD is more of a compression format, so you don't have the "LD" portion of it.
... We should focus on the specifics of what the WG will do.
Manu Sporny: On the compression format thing, we should not explain it that way. It is an LD-format, it just happens to be quite compact.
... You can take that format and expand to JSON-LD or YAML-LD directly, which says it's not purely about JSON-LD.
... The algorithms, while normative, don't need to be implemented as described in the spec.
... We're looking at a binary LD format, which happens to be compatible with JSON-LD and YAML-LD.
... We might want to think about messaging.
... Based on that, I wouldn't say that using a different WG is the right way to go.
Benjamin Young: +1 For this framing
...heh
... We're using the benefit of existing specs to reduce the amount of normative language we use.
Dave Longley: I don't know how much we need to defend this work.
... WRT CBOR-LD, people think about the functional definition.
... The purpose is to express in a compressed format, but you're preserving the semantic information.
... A consequence of being self-describing, is that JSON-LD has the ability to scale to parties you don't know.
... A credential can be issued and handed off with one not knowing anything about the other.
... That kind of scale only happens because that information is preserved.
... A 2-party model works well at a small scale, where you might communicate out of band.
... To scale beyond, you can't do that in a decentralized way without the semantics-preserving property.
Gregg Kellogg: JSON-LD's core representation based largely on INFRA
... is what separates us from "just JSON"
... and it's allowed us to do what we're doing
... and as long as we preserve that layer in CBOR-LD
Niklas Lindström: +1
... then the spec can largely focus on compression
Manu Sporny: We may want to consider other things in the charter.
Benjamin Young: +1 On removing the big list....we've already been headed that way fwiw
... There's an in-scope section that lays out what we want to address, and I think we need to remove this.
Manu Sporny: I haven't seen that done in other WG charters, and the direction is to make them succinct.
... The big list looks out of place to me.
... secondly, it says "Linked Data Signatures", it's now "Data Integrity".
... It's a different group, so we don't need to list it specifically.
... There are two other specs in the new VC group around barcodes and wireless transmission, that are dependent on CBOR-LD.
... Not getting CBOR-LD done in a timely manner could be a problem.
Gregg Kellogg: On that list of changes
... certainly we can address that on a timeline
... and it does show that the first things we might do is FPWD for YAML-LD and CBOR-LD
... and that could happen shortly after the group's established
Benjamin Young: We should discuss rechartering timeline. We could come back in two weeks with staff contacts.
... The chairs can work on this in the interim, and look to rename.
... TPAC is on the horizon, and we need to know if we're going to try to re-charter first.
Manu Sporny: Please try to recharter before TPAC.
... We also want to recharter other groups at the same time, but that could be a problem.
... We have systems going into production before we're in a standards-track, which is not great.
... Don't want the timeline to create roadblocks to adoption.
Benjamin Young: Agreed...
... This is doable, and the charter shouldn't be too controversial.
Benjamin Young: We have four months, that's 8-10 calls at the rate we have meetings
... The next call should have staff contacts so we can see how feasible that is.
... bigbluehat, gkellogg, and pchampin should talk ahead of time to get things in shape.
... We also need to discuss any other specs or notes.
Gregg Kellogg: Not sure how much more there is to do to this, actually
... just bringing it up to date
... so hopefully not much back and forth
... and that should likely happen on GitHub
Manu Sporny: +1 To what Gregg said, doesn't feel like there's a lot to do before charter is ready for a vote.
... so, let's work to get a meeting in the next week or so with the staff contacts
... and then see what's left to do
... so the sooner we're able to move forward on this, the better
... if we're not planning on active work until after September, then maybe that will help
... and getting the charter done and out of the way shouldn't be a problem
Gregg Kellogg: The next meeting and future meetings will be WG meetings
... as focus will be on the charter
Benjamin Young: Victor_lu, we'll check on your observer status for WG calls
Gregg Kellogg: We'd love to have you as a member of the WG
... so we should sort out what might prevent that
Victor Lu: I'm independent
Gregg Kellogg: Great, so we should see about getting you on as an Invited Expert