The W3C JSON-LD Community Group

Go Back


W3C Logo

JSON-LD CG & WG

Minutes for 2025-03-26

Gregg Kellogg is scribing.

Topic: Announcements and Introductions

Piotr Sowiński: From Neverlink in Poland. Work on CBOR-related issues.
Ted Thibodeau Jr.: https://jelly-rdf.github.io/ "Jelly is a high-performance binary serialization format and streaming protocol for RDF. It is based on Protocol Buffers and gRPC, and has a JVM implementation that works with Apache Jena and RDF4J."
Piotr Sowiński: Yup, this one
Piotr Sowiński: Jelly focuses on high ser/des perf, not necessarily very small size, like CBOR-LD

Topic: CBOR-LD

Wesley Smith: Dlongley will do Q&A.
... Here talking about CBOR-LD from Digital Bazaar.
... Talked about this previously at TPAC.
... Goal is to work with applications which are space constrained.
... Also leverages existing JSON-LD Context mechanism for "semantic compression".
... Make payloads self-describing.
... Should integrate easily with JSON-LD.
... Semantic Compression reuses existing data structures to create invariant data structures.
... This results in very good compression.
... You can go beyond semantic compression using a registry entry.
... Or, you can use CBOR-LD without semantic compression.
... Terms are assigned integer values used for compression.
... Size of compressed terms is not a function of the size of the uncompressed term due to information content of data structures.
... You may need to compress context values themselves.
... This requires the CBOR-LD Registry, with a header which points to that data to allow decompression.
... Also allows compression beyond semantic compression.
... There is a range of CBOR tags which are associated with CBOR-LD, which allows a specific registry entry to be targeted.
... The consumer looks up the registry using the tag.
... (goes through example of a VC)
... Next steps: details of CBOR-LD Registry.
... Algorithm correctness.
... Alternative compression techniques.
... There exist multiple independent implementations, but no comprehensive interop testing.
Ivan Herman: We don't have good experience with setting up and maintaining registries at W3C.
... Setting it up and managing it over time could be a problem.
Wesley Smith: Look forward to getting into this.
Ivan Herman: Not just a group issue, it's a W3C organizational issue.
... The group goes away and there is no one to maintain the registry.
Dave Longley: Agree with concerns. We've tried other models (e.g., DID).
... There are people who have signed up to help maintain that registry.
... The Credentials group could maybe be leveraged.
Anatoly Scherbakov: There's also w3id.org, which has some support from different organizations.
David I. Lehn: That's just a redirect service that needs little maintenance.
Dave Longley: One of the strengths of w3id.org is that it's simple. First come first serve.
... The CBOR-LD registry could be set up that way.
... It could depend on GitHub.
Benjamin Young: Primary need is to keep people from stepping on each other.
Dave Longley: Key is to be sure that applications don't interfere with each other.
Pierre-Antoine Champin: Pchampin departs
Ivan Herman: I'd like to get a feeling for a value of the registry. wes-smith showed an example, but he used both semantic compression and registry compression. What would be the result if only semantic compression happened?
Dave Longley: If you look at the registry entry, wherever there is a string also in the payload, you can replace those strings with the corresponding registry mapping.
... You can get about 50% compression without a registry; the registry can get to 90%.
... The registry is necessary to get something small enough that can be put into a barcode.
... We designed CBOR-LD so that the spec/WG only needs to register with IETF to get a small range of CBOR tags; from that, we can get to a secondary set of tags.
Daniel Osakue: Can application specific registries be used?
... The core CBOR tags have some fixed meaning that is generally useful.
... The secondary map can be arbitrarily large, at the expense of going to larger numbers, which won't offer as much protection.
... There are concerns about squatting, and we will need some additional governance considerations.
... But, we won't need to involve the IETF for managing our own registrires.
Benjamin Young: The "lookup" bit is more development-time, where you map strings to numbers and using that to encode the CBOR.
... Or, do CBOR-LD need to build in the registries.
Dave Longley: The expectation is that you'll reuse existing registries and build that into the code. This allows local lookup.
... The expectation is that you won't do this at runtime.
Benjamin Young is scribing.
... You could build a generalized piece of software, but don't know the use case.
Gregg Kellogg: So, when I build something for this--as I plan to do--and if I use helper libraries to internalize the registry entries
Dave Longley: +1 Very similar to "internalizing JSON-LD contexts"
... as I do with schema.org's context and many others--to avoid looking it up often
Dave Longley: +1 Yes, same patterns used.
... storing contexts locally and these registry entries locally, sound like very similar problems/uses
Dave Longley: +1 Does not scale arbitrarily, is use case specific.
... but if I stop maintaining that library than it would still work with the older/earlier entries, but not the new ones
... and it may not have the ability to easily add new ones
... we will need to face the runtime look up of external resources
Ivan Herman: In the JSON-LD Context world, it was an important consideration that the content of a context does not change.
... In the case of VC, we publish the hash of the context file.
... We need something similar with the registry items, or we're open to a attack.
Piotr Sowiński: From a different area, there is precedent for baking in such registries into software.
... Web applications might parse data they find on the web. Is this a use-case?
Dave Longley: You might not get the benefits of the registry by dynamic lookup, and they might use an uncompressed or semantic form.
... One of the things that comes up is the need to express a hash of a context within the URL for that context.
... A document-loader can then check the hash of the content with the hash in the URL.
... Immutability can be expressed in the registry itself.
Daniel Osakue: Daniel osakue
Daniel Osakue: I'm interested in this to adapt to a different use-case for JSON RPC messaging.
... Is there any pre-existing exploration of building up a registry with constants for a specific application?
Dave Longley: I thought you were going to talk about the CBOR-LD registry and how it could be modified with timestamps.
... Could there be a messaging protocol to do this with any number of different kinds of registries?
Daniel Osakue: I thought the CBOR example reflects general needs of other messaging applications.
... I can see use in IoT contexts.
Benjamin Young: The WoT group are big consumers of JSON-LD and could use this.
Dave Longley: +1 A great use case / space to explore
... The JSON-LD CG mailing list is a good place to discuss.
... I've been thinking about this, and this looks like a solution to a long-standing problem.
Piotr Sowiński: I'm working on something that might be relevant.
Benjamin Young: Also, a good place to discuss is the CG mailing list.
Benjamin Young: Thanks to everyone!