The W3C JSON-LD Community Group

Go Back

W3C Logo

JSON-LD WG

Minutes for 2024-04-03

Present
Pierre-Antoine Champin, Gregg Kellogg, Benjamin Young, Niklas Lindström, Ted Thibodeau Jr., Manu Sporny, David I. Lehn, Dave Longley
Chair(s)
Gregg Kellogg
Scribe(s)
Gregg Kellogg, Pierre-Antoine Champin, Manu Sporny
Agenda
https://www.w3.org/events/meetings/398465c7-3787-40df-856a-434a438d9f05/20240403T120000/
Topics
  1. Rechartering Process
  2. Specs to include in the new WG
  3. a. YAML-LD
  4. b. CBOR-LD
  5. c. JSON-LD 1.2
  6. Open Discussion
  7. Next call
Gregg Kellogg is scribing.
Pierre-Antoine Champin is scribing.
Manu Sporny is scribing.
Agendum 1 -- Announcements and Introductions -- taken up [from agendabot]
Benjamin Young: Most focus is on rechartering.
Manu Sporny: There is a discussion around suffixes and media types (for 5 years), which got kicked off with the JSON-LD media type.
Summary of Media Types discussion and Structured Suffixes: https://github.com/w3c/vc-data-model/issues/1462#issuecomment-2016609877
https://github.com/w3c/vc-data-model/issues/1462 -> Issue 1462 Revisit Verifiable Credential media types (by brentzundel) [normative] [CR1]
Manu Sporny: Suggestion was to use application/ld+json. It was picked up by other groups, which could lead to applcation/did+ld+json, but ran into problems when registering.
... At the last IEEF WG, it was suggested that suffixes were a bad idea, pointing to JSON-LD as bad example.
... This is pulled in some emails by TAG members, but that's not an official possition.
... It suggests getting rid of all suffixes. There's also a move to support a single '+' but no more.
... This group doesn't need to decide that, but we may not want to go forward with structured suffixes.
... There are other groups, e.g. image/xxx+gzip
... This could go on for a long time still, has been going on for 5+ years.
... Please engage in the discussion at IETF.
Dave Longley: https://github.com/ietf-wg-mediaman/suffixes/issues <-- github issue tracker for this
... For W3C, the polyglot issue is not being engaged properly.
... TAG needs input from outside groups.
Pierre-Antoine Champin: You say JSON-LD is cited as what to avoid, is that the ld+json, or the fact that that is used as a suffix.
Dave Longley: It seems "polyglot" is a new term for labeling things people don't like with a vague definition, and should perhaps just be avoided.
Manu Sporny: It's all of it, basically unilaterally claiming JSON-LD is bad.
... I disagree with that, as there are plenty of examples of polyglot (HTML + JS).
... That plays into the structured-suffix discussion, which are effectively polyglot. There are about 400 such media types.
Dave Longley: It seems this would need to be the advice: don't create a new media type for any particular expression of data in JSON or XML -- or else you'll also have to create and maintain your own editors to author it... just use "application/json" or "application/xml" instead.
... THere's arguments against JSON-LD, other media types, and the use of multiple + signs in JSON-LD related formats.
Pierre-Antoine Champin: I checked with Yves who is at the TAG meeting next week.
Benjamin Young: There were a few concrete things in polyglot and some of the suffix issues.
... One thing is ignoring polyglot, what are the iterative combinatorial values of multiple suffixes.
Pierre-Antoine Champin: +1 The term "polyglot" is itself ambiguous and therefore misleading
... With JSON-LD, application/json is rather meaningless. ld+json and schema+json point to there being an additional datamodel that comes with that particular instantiation of JSON.
... THe argument is that it should be stated inside the body, rather than in the media type.
... We should be pointing out why this is a good thing.
... There was pushback about the context URL being forgotten about. Some WGs have said that `@context` must be in the package to be JSON-LD.
... The big open question is the third tier with multiple suffixes, what value does that have?
... We need to make clear thoughts about the third layer.
Pierre-Antoine Champin: +1 To what you said about "polyglot" being confusing.
... The difference is that formats are interpreted differently in different environments.
... JSON-LD inverts this so that the formats are processed the same everywhere.
Manu Sporny: As a result of the discussion being portrayed as a TAG decision, the VCWG is at a point that it's not clear when it will be resolved, and we can't wait. We may use application/vc and be done with it.
... In the future, we could say either that or application/vc+ld+json.
... Then we can do the less technically valid solution first. I would expect a new JSON-LD WG to not try to register a structured suffix.
... We may want to consider application/json-ld with the structured suffix +json-ld.
... That throughs more options into the mix.

Topic: Rechartering Process

Benjamin Young: Everything on the agenda are possible items to put in the charter.
Pierre-Antoine Champin: Not much to report on updating the charter repo. I have a PR for updating it for CBOR and YAML.
Pierre-Antoine Champin: We're supposed to put a new charter in the charter drafts repo. I don't like having the discussion in that repo, but working on a fork makes it easier to integrate.
https://github.com/json-ld/json-ld-wg-charter/pull/1 -> Pull Request 1 add REC-track deliverables CBOR-LD and YAML-LD (by pchampin)
... I created the repo as a fork from charter-drafts to pick up all the boilerplate.
... Once we're done, we can do a PR into w3c/charter-drafts repo.
... I tweaked GH Pages to only show our charter on our fork.
... Please review the PR and make suggestions.

Topic: Specs to include in the new WG

Benjamin Young: We've discussed YAML-LD and varioud CBOR-LD specs

Topic: a. YAML-LD

Benjamin Young: We have a nearly ready CG report on YAML-LD, which would go into the WG as an initial version of the spec.
Gregg Kellogg: What to do about ongoing work on YAML-LD?
Pierre-Antoine Champin: The WG hasn't taken it up yet, so CG can continue, can't it?
Gregg Kellogg: Maybe WG takes up the CG drafts, whatever the state of those happen to be at the time?
Pierre-Antoine Champin: Working Group adopts final CG report or latest Editor's Draft the CG might have?
Pierre-Antoine Champin: I think we might tweak the text to allow the group to adopt the final report or something newer. Then, we could continue CG work on YAML-LD.
Benjamin Young: We can continue to work on this in the CG.
Manu Sporny: I know the charter includes work on best practices. There are a number of things that have come up in VCWG about static context files. In the VC case, there are security concerns where we provide hashes of the contents.
... Should we provide update to the BP doc in the charter?
Gregg Kellogg: The WG has a number of non-REC-track documents. Group should be chartered to advance those documents.
Gregg Kellogg: There is a vocabulary repo, we don't want to be in a position where we can't do those because we didn't call them out explicitly.
Benjamin Young: Not a concern that we can't do it, but by listing it it can get WG focus.

Topic: b. CBOR-LD

Benjamin Young: There are a couple of specs in flight that aim towards a new WG publication.
... The CG doesn't have final reports for CBOR-LD.
... We can point to the two different notes for prior art.
Manu Sporny: +1 To what bigbluehat said
Gregg Kellogg: Both CBOR-LD and YAML-LD have polyglot considerations.
Manu Sporny: The CBOR-LD spec is in bad shape. Should we also include implementations?
Dave Longley: It seems to me that anyone who tries to use JSON or XML for anything other than drawing curly braces or angled brackets has a "polyglot" problem...
... Do charters require an explainer? We could put links to implementations in the explainer. Otherwise, the spec might not look mature enough
... The experience on the deployed implementations is relevant.
Benjamin Young: This is technically a re-charter, so an explainer might not be necessary.
... as a Maintenance Group we're not chartered to do new work, but a new charter can allow that.
... There was a discussion in a previous group about renaming to something broader, but we should probably avoid that.
... JSON-LD has good brand value.
Pierre-Antoine Champin: I agree that we don't need to explain what JSON-LD is, however, we know the concept of YAML-LD raises some questions, so it wouldn't hurt to have some form of explainer.
... This is not strictly-speaking JSON-LD, so we might need to explain why this is useful.
Benjamin Young: Agreed. We need to explain why it is still the JSON-LD working group even while we're taking on new formats.
... This is not the "Linked Data" WG, there are other efforts which are quite a bit different.
Gregg Kellogg: Interestingly, this is another subhierarchy of polyglots
... in a way, JSON, YAML, CBOR share a common meta-model
... We want to share these commonalities and explore these design patterns.
Gregg Kellogg: The RDF-star WG is doing general updates to the RDF data models,
... and extending it to ease the support of property graphs use cases.
... Based on syntactic sugar (not unlike lists) which generate a bunch of statements.
... pchampin, and I, and to some extend niklasl, have done some work on extending JSON-LD to support triple-terms.
... This document should be adopted for being integrating in a future JSON-LD 1.2.
Benjamin Young: Is JSON-LD-star a discrete work-item, or is it just JSON-LD 1.2
Gregg Kellogg: We need to liaise with the RDF-star WG, and do something based on RDF 1.2.

Topic: c. JSON-LD 1.2

Benjamin Young: We have errata, open issues and PRs, and synchronization with RDF-core when it is updated.
... There are other issues which were previously deferred?
Gregg Kellogg: Also issues from json-ld.org repo.

Topic: Open Discussion

David I. Lehn: Can we add items later?
Benjamin Young: This is not a final repo, but the charter repo would be a good place to list items.
Benjamin Young: Add "to consider" items to https://github.com/json-ld/json-ld-wg-charter/issues
David I. Lehn: There are other ideas that have come up over time that we may want to consider.
Gregg Kellogg: Maybe the recent issue on a simplified JSON-LD profile.
Benjamin Young: We'll be labeling existing issues where we find them, and may need a new project to track them.
Niklas Lindström: +1 For a possible note on a "turtle-like" profile
Benjamin Young: If you have an expanded JSON-LD already, you might not need the support for compaction.

Topic: Next call

Benjamin Young: Next call in two weeks is a CG call.
... For the foreseeable future, we'll target both CG and WG work at rechartering.
Pierre-Antoine Champin: I have an example context for the GitHub API to interpret the API output as JSON-LD.
Benjamin Young: Wants `application/github+ld+json` ;)
Niklas Lindström: Also have one, done for DCMI; would love to compare!
Benjamin Young: Related to this, in the absence of multiple suffixes, the WebAnnotaton WG used application/ld ...
Benjamin Young: Web Annotation used `application/ld+json;profile={context_url}`
Dave Longley: I would not be surprised to see media type "profiles" to suffer the same fate as suffixes
They're polyglots as well! :)
Niklas Lindström: Always looking for ways to "un-API" data on the web...
... We wanted a suffix to register '.anno', which you can't do with profile media types.
Dave Longley: First they came for my suffixes and i said nothing ... then they came for my profiles ...
... Thanks to manu for championing this.
Dave Longley: It turns out everything is polyglots :) ... application/json should just be application/octet-stream after all :)