The W3C JSON-LD Community Group
Go Back
JSON-LD CG Telecon
Minutes for 2025-08-13
- Present
- Pierre-Antoine Champin, erika, Ted Thibodeau Jr., Niklas Lindström, Anatoly Scherbakov, Gregg Kellogg, David I. Lehn
- Chair(s)
- Gregg Kellogg
- Scribe(s)
- Gregg Kellogg, Benjamin Young
- Agenda
- https://www.w3.org/events/meetings/04e937c0-e751-4c7e-9ba4-5782e0b3d272/20250813T120000/#agenda
- Topics
Gregg Kellogg is scribing.
Topic: Announcements and Introductions
Benjamin Young: Mostly focusing on charter update.
Topic: JSON-LD Rechartering
Benjamin Young: https://github.com/json-ld/json-ld-wg-charter/pull/10
https://github.com/json-ld/json-ld-wg-charter/pull/10 -> Pull Request 10 Rework as the Linked Data Formats WG (by BigBlueHat)
Benjamin Young: Many changes ready to push in the PR.
Gregg Kellogg: I suggest merging and using that as a basis for updates.
Benjamin Young: Consensus seems to be for keeping the name JSON-LD WG.
Ted Thibodeau Jr.: Many changes in last 24 hours or so... please give me a few hours to review this before merging
... Many changes done in the last couple of days are generally clerical in nature
... RDF-star => RDF 1.2. Reducing the In Scope section to remove overly specific references.
... Now point to project management page, and use language from RDF & SPARQL WG for allowing new features.
... No changes to Out of Scope yet.
... Added 1.0 versions to CBOR- and YAML-LD.
... Dropped the bit about supporting multiple languages in JSON.
... Changed the dates in the timeline.
Pierre-Antoine Champin: I noticed that CBOR- and YAML-LD are scheduled before JSON-LD 1.2.
Niklas Lindström: I agree.
Benjamin Young is scribing.
Gregg Kellogg: We could fairly rapidly do additional versions or updating CBOR-LD and YAML-LD once JSON-LD 1.2 comes out
... maybe we need to reparse what we mean by JSON-LD 1.2
... some of that is already in via <ins>/<del>
... so maybe JSON-LD 1.3 is the version that does the synchronization with RDF1.2
... I do think there's good reasons to push YAML-LD and CBOR-LD through first
Pierre-Antoine Champin: +1 To that. My initial reaction is that it would be a shame to be out of sync, but those two are closer to publication, but we don't want to overly delay things.
... SPARQL 1.1 is an example, as it preceeded RDF 1.1
... +1 to keep the timeline and figure out how to keep those specs future-proof.
Benjamin Young: It would be dangerous to log-jam behind JSON-LD.
Anatoly Scherbakov: I agree with the above.
... Where should I look if I want to get a better understanding of what JSON-LD 1.2 would be?
Benjamin Young: Based on what Gregg said, a lot of it is already in shape with the ins/del changes.
Gregg Kellogg: The <ins>/<del> stuff is not everything
... that doesn't take several RDF 1.2 things into account yet
... lexical ordering and unicode spaces are not covered
... along with initial text direction changes
... The bigger changes exist in the JSON-LD-star.
Gregg Kellogg: JSON-LD-star did add triple terms
... but RDF 1.2 is doing more than that
erika: I'm in the research faculty at Case Western Reserve University.
... We've transitioned to having all of our datasets in JSON-LD. My group works under Roger French.
... He was not able to join today, but asked me to join.
... If we have the chance we can show how we're using JSON-LD and RDF in general.
Benjamin Young: Back to JSON-LD 1.2/1.3. Do we think we need to group changes in the charter?
Gregg Kellogg: I don't think we need to be quite that specific
... maybe we keep it vague but point to a quick release for 1.2 for bringing in staged changes
Ted Thibodeau Jr.: "JSON LD 1.1 ++ bis (revised)"
... and then subsequently release another version that syncs up with RDF 1.2
Benjamin Young: The timeline for 1.2 FPWD is Q4 2026, but a patched version could come out sooner.
... If we just make 1.2 bigger or push things into 1.3 is open.
Pierre-Antoine Champin: My understanding of the process is that as long as we're working on things in the charter, such as aligning with RDF 1.2 and the errata, is up to us.
... If we decide to publish a REC before having everything in, is up to us.
... We need to keep the text vague enough to give us this leaway. We can have a lot in scope, and decide how to publish this later.
David I. Lehn: I'm not sure where the timeline dates come from (guessing?).
Benjamin Young: Dates should look reasonable, but commonly changed as the group continues.
David I. Lehn: If we want to formalize the smaller changes, it could happen quicker.
Benjamin Young: It's okay to set lower expectations and exceed them, rather than being overly ambitious in what we can do in a more limited amount of time.
... If we can ship a 1.2 with patches next April, we should do that.
... We need to be sensible in the charter.
David I. Lehn: The deliverables section ... is that a standard way to format it?
... It can be confusing.
Pierre-Antoine Champin: In the latest template, the version number is not required.
... An option would be to use another field for the latest publication date, and refers to the latest draft and not the current version.
Gregg Kellogg: We should publish what we can sooner
Gregg Kellogg: Publish what we can, wait for what we can't.
Anatoly Scherbakov: +1 To the above.
Gregg Kellogg: I do think CBOR-LD needs some finalization, etc.
... YAML-LD has sections for many of the JSON-LD API processes
... those sections are pretty sparse in YAML-LD, but are completely absent currently for CBOR-LD
... I think we determined there is no CBOR-LD version of a context file
... but a CBOR-LD processor would presumably need to support YAML-LD and JSON-LD contexts
Benjamin Young: CBOR-LD is a bit of a weird animal. In it's current form, it's really just a compression of JSON-LD.
... As a processor, the approach leans heavily on a registry, not dereferencing them off the web.
Gregg Kellogg: There are some things we want to do about context stability in JSON-LD also
Benjamin Young: CBOR-LD does not do any JSON-LD processing, you only ever do it by working in the JSON-LD domain.
... We need to get CBOR-LD to a final CG report.
Gregg Kellogg: Does the CBOR-LD final community group report make it an LD format? or is it only about compressing JSON-LD?
Benjamin Young: If we try to make CBOR-LD and actual -LD format, it won't make the cut.
Gregg Kellogg: I think we need to reconsider the CBOR-LD name if we do not make it a full LD
Pierre-Antoine Champin: +1
Niklas Lindström: +1
Gregg Kellogg: We need to decide what is the thing called CBOR-LD
... is it just compression?
... we need to be quite clear about what it is trying to do
... and we could be held to higher standards than the group is ready to do
Pierre-Antoine Champin: It was my impression that CBOR-LD could serialize anything, and compress what it can.
... +1 that we haven't had enough discussions on it.
Benjamin Young: You're correct about compression, it's compatible even if it can not compress.
Ted Thibodeau Jr.: I'm thinking that CBOR-LD is not what it is or should be called. It seems that it should probably be a section within the JSON-LD documents that describes using CBOR to compress JSON-LD documents.
... JSON-LD is too big to put in a QR code.
... All things considered, it may not be something that needs its own spec, as it's really just an application of CBOR.
... It's primary focus indicates that it could just be a chapter.
Benjamin Young: The spec itself is already quite massive; it has mappings, URL registration, and other ways to take known strings and compress them, where plain CBOR won't do that.
... But, what people expect from a -LD parser, such as expansion and re-compaction, is not currently described.
... It's really CBOR plus the context plumbing from JSON-LD, as it layers on top of existing formats.
... We list two input documents (PA's and DB's).
... It is something unique and makes use of the context plumbing.
... People will be confused if they think they can work just in CBOR.
Pierre-Antoine Champin: JSON-LD processing is not done on JSON anyway, it is done on the internal representation
Gregg Kellogg: Framing isn't part of the JSON-LD API document
... it would've made the API document so much bigger
... similarly trying to get CBOR compression into any of the JSON-LD documents would make them huge
... the brand is out there
... and I continue to be annoyed that the CBOR-LD editors remain absent here
... and no contribution here
... they need to show up and be part of the process
Benjamin Young: I agree, they need to be more involved with this WG.
Niklas Lindström: +1
... The new playground does have a CBOR-LD tab.
... It does not yet take CBOR-LD as an input.
Anatoly Scherbakov: +1 To that definition of YAML-LD :)
... CBOR-LD is similar-ish, in that it will be to just parse CBOR, and feed that into expansion/compaction.
Benjamin Young: The expectation is that most formats round-trip through JSON-LD. So, in that sense, they're not that different.
... I expect that the YAML-LD spec tells me how to write compatible YAML, and CBOR-LD should do the same.
Benjamin Young: We should come back to this next week, and try to drag in the CBOR-LD editors.
... This is a prerequisite for finishing the charter.
... It needs to get to a final CB report before we can use it.
... The PR has approvals, so I plan to merge it.
Anatoly Scherbakov: Good bye everyone, thanks!
... We'll be back next week, keep the suggestions coming.