The W3C JSON-LD Community Group

Go Back

W3C Logo

JSON-LD WG

Minutes for 2025-07-16

Present
Gregg Kellogg, Victor Lu, Pierre-Antoine Champin, David I. Lehn, Ted Thibodeau Jr.
Chair(s)
Gregg Kellogg
Scribe(s)
Benjamin Young, Gregg Kellogg
Agenda
https://www.w3.org/events/meetings/04e937c0-e751-4c7e-9ba4-5782e0b3d272/20250702T120000/
Topics
  1. Announcements and Introductions
  2. Rechartering

Topic: Announcements and Introductions

Benjamin Young is scribing.
Gregg Kellogg: Anything new to announce?
... this is a WG call
Benjamin Young: Victor's here as an observer
... and may eventually be an Invited Expert

Topic: Rechartering

Gregg Kellogg: Sounds good, as long as we keep voting to members, that should be fine
Gregg Kellogg: K. Let's talk about the charter
... bigbluehat is your new PR in yet?
Benjamin Young: No, it's still in draft
https://github.com/json-ld/json-ld-wg-charter/pull/10 -> Pull Request 10 Rework as the Linked Data Formats WG (by BigBlueHat)
Gregg Kellogg: So, here's bigbluehat's PR
... a good bit of change in the motivation section
... pchampin the structure of this doc is different than other newer groups use
... does that matter?
Pierre-Antoine Champin: Yes. it matters
... the template is a living document...
... so we're likely not using the latest
... and we should likely update
... especially if there are significant changes
... so, yes, I'll make a pass on it
... but usually we do that close to the end of the process
Gregg Kellogg: Basically, it looks like our current motivation and background section just becomes part of the intro/header section
... but beyond that, I think bigbluehat's wording is a useful improvement
... any other thoughts on that?

Subtopic: Group Name

Pierre-Antoine Champin: I do have some concerns from the name
... removing "JSON-LD" from the name breaks continuity
... and we also may not want to change short names of docs, IRC channels, etc.
... I know it's bike shedding
... and I agree we're broadening the scope of the group
... but if we can maintain continuity, that would be better
Gregg Kellogg: Maybe "JSON-LD Data Formats"?
Pierre-Antoine Champin: I like that
Gregg Kellogg: We may have to respin JSON-LD as an INFRA-based tree structure for Linked Data
Pierre-Antoine Champin:
... if folks were looking for YAML-LD, I'm not sure they'd think to look at a "JSON-LD Data Formats" group...
... something to consider
... what else is in here...
... ivan has raised concerns that trying to tackle both YAML-LD and CBOR-LD may be too ambitions
Benjamin Young: I hear Ivan's concern, but I really don't see how more groups will solve that
Anatoly Scherbakov: I agree with bigbluehat
... that would add too much bureaucracy and overhead
... and without any real benefits
... big teams do sub-groups or other WGs because they're too big
... we don't have that problem
... perhaps in the future, if we decide there's too many things to accomplish, we could do more with other CGs
... maybe one per-format in that case
... but they could all exist under the umbrella of the JSON-LD WG
Pierre-Antoine Champin: Ivan raised the possibility of other groups
... his idea to put CBOR-LD into it's own group was about scope and clarity
... we want to broaden the focus of the group
... but as a small group, the list of deliverables is quite big
... so I have mixed feelings about this
... and as ready as YAML-LD seems to be
... other people may chime in
... and those discussions could slow down the whole process
... but, I also have the feeling that we are close enough
... things may be slower than how they look right now
... but maybe not so much that we should give up on a single group
Gregg Kellogg: 2 Things
... coming out of the RDF-star task force, we felt great and that we were done...3 years ago now
... of course RDF-star was introducing fundamental changes into the data model
... whereas YAML-LD was about better generalization
... and still feels like low-hanging fruit
... I also think task forces are a good option
... the RDF and SPARQL group had task forces for semantics
... which ran its course and created value
... now there's a SPARQL one
... we could do the same
... have a core meeting and a CBOR-LD task force
... and folks could focus where they need/want to
... we could even be entirely task force based
... until such time as coordination is needed
... if that's the way we want to go, then we'll need to explain all that in the charter
... any thoughts on that?
Gregg Kellogg: Pchampin are you aware of any precedent for calling out task forces in a charter?
Pierre-Antoine Champin: I don't think so
... I vaguely remember discussing the approach
... but I remember the team saying task forces are a chair/group decision
... so it doesn't make sense to put it in the charter
... but I don't think it would be forbidden
... it's unusual because task forces are usually needs based
... and we may find they aren't needed
... planning on this to tackle the problems
... that's one thing
... but it's probably premature to list the task forces
Gregg Kellogg: Task forces can have their own calendars, setup their own meetings, etc.
... so a qualification would also be to be a member of the WG
... and not everyone is a member of all task forces
.... they'd be open to any task force, but not immediately obliged to join
Gregg Kellogg is scribing.
Benjamin Young: We need to remember that the charter is a sales document to motivate the need for the group.
... If we highlight something, it raise interest, but it might look like we have too much to do.
... We would have a lot of deliverables, and may not have enough contributors to manage it.
... We can focus on the documents we need to deliver.
... For example WG participation by CBOR-LD contributors.
... I think we need to lead with what the group wants to do, and deal with feedback when it comes.
... We should ask for what we want to have happen.
... Best thing is to note that LD has evolved, and there is more going on than just patching holes in JSON-LD.
... Not just a maintenance group, but we're going on to related formats.
... There are a number of groups that depend on our work, which shows the need in moving the formats forward.

Subtopic: Scope

Pierre-Antoine Champin: +1 To what bigbluehat said
... a few things in this line
... I agree, the main role of this charter is to broaden the scope
... to point out that we're moving out of maintenance mode
... that we have new things to work on
... we should probably be modest
... I don't know if there's a pattern for "we want to start on these, but know we may not deliver on them"
... not sure that's been done
... 2 year charters are short
... so maybe other groups have done this
... we are allowed by the policy to add new documents if they are in scope
Ted Thibodeau Jr.: Main goals and stretch goals...
... and that may be why ivan suggested the removal of some deliverables
... so, we could work on TOML-LD or whatever
... if there were enough interest
... so, we need the correct wording that doesn't sound too ambitious, but does give us room to accomplish what we need
Gregg Kellogg: I think ivan mentioned limiting the list to JSON-LD 1.2 and CBOR-LD and then adding YAML-LD "if time"
... but as you've said pchampin that may already be implied
... or, we could have a "Other Linked Data Formats" section where we add CBOR-LD and YAML-LD there
... the big thing we need to avoid is rat holing on the generic model
... but we do also need to address dealing with remote contexts
... that issue in particular needs to be highlighted
... our current list of "in scope" things is far too long and incomplete
... but we do have some specific things we want to do
... synchronizing with RDF 1.2
... we want to address these high interest issues like retrieving contexts
... which may be handled through some sort of hash delivery mechanism
... and the definition of how document loaders would do that
... and then I think we probably need to highlight our open issues
... in the case of the RDF and SPARQL group
... there's wording that says the group may add new features
... and this group's been pretty judicious about doing
... but that's where most of the new SPARQL features are happening
... with the expectation that work will continue based on interest from the group for more recommendations based on that work
... but with ins/del's show what's coming
... that, afaik, is how we hope to continue work even after the core recommendations are done
Pierre-Antoine Champin: I didn't quite follow
Gregg Kellogg: So, there are some things the RDF & SPARQL group has already accomplished
... but then there are even more features from the SPARQL CG that need to go to Rec
... and the group seems to be intending to release a SPARQL 1.3 document later
... based on that CG work
... and there's verbiage in that charter to allow the group to continue to do that
Pierre-Antoine Champin: Correct
Gregg Kellogg: We have already marked a few areas where we can do that
Pierre-Antoine Champin: Correct
Gregg Kellogg: A number of things we have on our list now fall into errata
... and we flagged many issues with "consider later"
... at some point we need to decide which things are not specifically errata, but that we do want to get to
... so the next part of scope is what's out of scope
... the 2 things there now aren't really needed there any more
... the canonicalization group is done
... and the signatures work is complete
... so I'm not sure we even thing we need this section
Pierre-Antoine Champin: If we expand the group, we may need to point out which Linked Data formats are not in scope
... our focus would only be on things that depend on the JSON-LD processing algorithms
... so, not RDF/XML or Turtle, for example
... not just because those are in other groups
... but because they use a different processing model
Gregg Kellogg: Maybe we could say JSON-like formats?
... that said, there are features beyond what JSON can do such as number formats that could be added to the core processing model
... or the internal representation
... so, internally, we could support other native types
... earlier, I'd pondered making an RDF literal an atomic data type
... with mappings into it from JSON, YAML, and CBOR, for example
... that seems in scope for us to do

Subtopic: Support for Streaming Parsers

Gregg Kellogg: What else is here....other deliverables
... streaming parsers?
... we do have a note on that
Gregg Kellogg is scribing.
Benjamin Young: The profile for streaming parsers has been around for a long tim
... It can include big JSON files, or line-delimited JSON.
Benjamin Young: That was Ruben Taelman's work
Niklas Lindström: I don't think this was about JSONL or JSON-ND, but it would be good to work on that
... the streaming one is about processing one JSON object as a stream
Gregg Kellogg: Anatoly-scherbakov YAML has support for multiple embedded documents, correct?
... I think we handle that in a similar way to HTML data blocks
Anatoly Scherbakov: Yes, that's correct
... we use the same flag for those scenarios
... I don't recall the name of the flag, though
... it's either process first object only
... or process them all--which gets put into an array
... afaik they're each expanded separately
Gregg Kellogg: So unless you feed a context in, each of these "sub documents" need to have their own context expressed in their data
Anatoly Scherbakov: Yes, that's correct
Gregg Kellogg: So, we do have this specification
... about streaming
... the approach differs from the multiple document approach
... maybe we can point to an issues outlining the situation

Subtopic: Test Suite

Gregg Kellogg: Next, test suites an implementations reports
... our test suite is our biggest asset and biggest liability
... one might imagine we could simplify it
... so we don't repeat one thing over and over
... but the way we test differs by scenario
... similarly, some way to relate the tests connected to the specification information would be helpful
... it's sort of like pushing a bubble around--you fix one thing and it shows up somewhere else
... simplifying it might provide an easier way in for more implementers
... but the amount of work to do that is daunting
David I. Lehn: I was thinking about this recently
... one thing we could do is to reorder things in the suite
... even though the numbers would be off
... essentially make new manifests
... could even be a separate project
... that may be useful for people starting with a new implementation
... vs. running everything all at once
... we could even split them into smaller manifests and then link between them
... any volunteers?
Gregg Kellogg: Do we have to maintain the 1.1 test suite as it exists?
... do we need to maintain things for older versions of the spec?
... we could completely reorganize it to focus only on 1.2
... and perhaps as demanded continue to include things that should be handled by all 1.x processors
... the kicker, as ever, will be who signs up to reorganize it
David I. Lehn: Do we know of anyone writing a new implementation?
... it's pretty hard to come in after the fact--once you have an implementation
... new comers probably have an easier time knowing what they want to run when
Gregg Kellogg: We'll expect to see new implementations for YAML-LD and CBOR-LD
... YAML-LD already has a test suite iirc
... mostly copied from JSON-LD's
... and then there are cross-products
... like JSON-LD loading a YAML-LD context
... or CBOR-LD using a JSON-LD frame
... so, certainly just copying tests around just compounds the problem
... do we expect to have a single test suite for the WG?
... that would include all 3 formats?
... along with overlaps between them?
Anatoly Scherbakov: I don't believe we copied any tests from JSON-LD
... I think we're actually running the test suite directly
... but running it on YAML-LD
... since YAML is a superset of JSON
... there should be verbiage about that
Gregg Kellogg: There are specific YAML-LD tests also, though
Anatoly Scherbakov: Correct.
... it's the JSON-LD tests + YAML-LD specific tests
... so anything valid for both is not copied over
... it's advised to use the JSON-LD test suite to check anything core
Benjamin Young: I'll continue on the PR for the charter
Gregg Kellogg: Sounds great
Niklas Lindström: I did a recent basic implementation recently
... I could run the test suite and see how it goes
Gregg Kellogg: That would be great
... talk again soon!