The W3C JSON-LD Community Group

Go Back

W3C Logo

JSON-LD WG

Minutes for 2025-04-09

Present
Anatoly Scherbakov, Gregg Kellogg, Pierre-Antoine Champin, Niklas Lindström, Ted Thibodeau Jr., David I. Lehn
Chair(s)
Gregg Kellogg
Scribe(s)
Benjamin Young, Gregg Kellogg
Agenda
https://www.w3.org/events/meetings/c7ab3fcd-4dc4-4444-ae8a-c91ca2131113/20250409T120000/
Topics
  1. Announcements and Introductions
  2. JSON-LD Issue Discussion
Benjamin Young is scribing.

Topic: Announcements and Introductions

Gregg Kellogg: PresentT+
Pierre-Antoine Champin: https://champin.net/2023/sowasm/
Pierre-Antoine Champin: I've created a playground
... I've added poor man's support for JSON-LD and YAML-LD
... it doesn't support the full capabilities...but it's better than nothing
Gregg Kellogg: I think we eliminated a lot of the special processing in YAML-LD
Pierre-Antoine Champin: I honestly didn't check the spec
Anatoly Scherbakov: We removed most...or maybe all of the YAML specific features and made it very bare bones
... pchampin is it correct that you build Sophia RS?
Pierre-Antoine Champin: Correct
Anatoly Scherbakov: And that's on crates.io?
... and supports JSON-LD?
Pierre-Antoine Champin: The latest version does not support YAML-LD out of the box
... the SoWasm playground is a hack around YAML-LD
... it's a simple conversion to JSON and then uses the JSON-LD parser in Sophia
... ultimately, I'd like to create a full implementation that goes straight from YAML to the internal representation
Gregg Kellogg: There is work around the document loader with logic for contexts and things
... but it should be an "onion skin" type of implementation, though.

Subtopic: CBOR-LD

Benjamin Young: Any thoughts on last time's call?
Gregg Kellogg: I've stayed out of it for some time
... the binary format has kept me away
... I do like where they're going where every context does not need be well known
... some things are still fuzzy, though.
Benjamin Young: Such as?
Gregg Kellogg: Things like the token space
... you don't just put a vanilla CBOR to JSON parser
... you have to understand the JSON-LD first
Gregg Kellogg is scribing.
Benjamin Young: It's progressive layers of compression; you can layer on more context understanding to get better compression.
... The biggest shock is that it isn't really Linked Data; it's about round-tripping to/from JSON-LD.
Gregg Kellogg: I think we laid out some requirements we wanted there
... such as similar interfaces like we have with YAML-LD
... and the compression becomes an option for the generic JSON-LD API
... at least that's how I thought about it
... it at least needs to be closer to YAML-LD
Benjamin Young: Agreed. At least if it keeps the `-LD` moniker
Gregg Kellogg: Agreed. For now it's not really a Linked Data format...per se
... anatoly-scherbakov any thoughts on CBOR-LD?
Anatoly Scherbakov: I've not tried it out. Just stuff we've discussed on the calls.
... my general thought would be that it would be probably logical to create Linked Data mappings for many other things
... Parquet, etc.
... so Linked Data could be used regardless of sub-straight format
Pierre-Antoine Champin: I agree with anatoly-scherbakov
... with one caveat maybe
... JSON-LD might be the most appropriate mapping language
... CSV on the Web might be closer
... but I do like that idea
... being able to map anything to Linked Data would be great
... I know there are CBOR competitors... Would it make sense to define the compression mechanism separately from the CBOR encoding?
... we could, for example, consider mapping that compression process onto BSON or other binary formats
Gregg Kellogg: Some of it is tied directly to the CBOR registry...but some things are not
... and those things are not necessarily tied to CBOR
... we could even consider a compact JSON form
... I guess you'd use a context to map the long names to highly compressed names, perhaps
... it's a little similar to the internal representation we did between 1.0 and 1.1
... My main concern is the work is happening outside of the CG or the WG...and it's just stuff being worked on
... and it's just something we're being expected to adopt
... and that's not how working groups are supposed to work
... That said, I'm not sure where we are as a working group
... we're under the maintenance charter
Pierre-Antoine Champin: That expires at the end of July
Benjamin Young: Oh heavens
Gregg Kellogg: Yeah, that should likely be a priority
Benjamin Young: I agree about the concern on CBOR-LD being developed almost exclusively outside of the WG/CG and the expectation that it is on our work list.
... Of course, the CG doesn't have a good track record of completing work (other than YAML-LD).
... But, I agree that it can't be a WG spec until enough of the WG members are more directly involved in the work.
... A WG consideration could be to abstract the work beyond CBOR, as the compression could be useful elsewhere.
... there are other formats which are also interesting for -LD.
... It's not LD per-se, but the compressibility is tied to how you compress the data.
... Jelly is based on protocol buffers; it would be nice to get some of these communities involved in the group.
... CBOR-LD is a way to do that that needs review and shaping.
... If the algorithms are more generic, they could then be applied to CBOR or something else.

Topic: JSON-LD Issue Discussion

Gregg Kellogg: Anything else for this intro topic?
... are there any issues in the project system that anyone would like to discuss?
... anatoly-scherbakov I think there's a PR or two?
Anatoly Scherbakov: Yes, a couple have been merged
... they add a few small things to the spec
... metadata and examples
... I'll repeat my question from earlier. Does anyone have ORCID or other public Linked Data data available that we could use as examples?
Ted Thibodeau Jr.: I don't have ORCID, but I do have other stuff out there
Gregg Kellogg: We typically use FoaF
... dlehn do you have anything like that?
David I. Lehn: For myself...I don't think so
Gregg Kellogg: Constructing a basic profile isn't very hard
... there's nominally a URI
... but blank nodes happen
Anatoly Scherbakov: Ok. It's just that as I visualize this information, I have human readable names for gkellogg, he, and pchampin
... but things like GitHub URLs don't resolve because they don't distribute linked data
Gregg Kellogg: Yeah...if that information isn't publicly exposed, then we'll have to fabricate
Benjamin Young: Is there a YAML-LD section you'd like contributions to?
... I might be able to add something to my site which would help.
Benjamin Young: Is this data visualized in the spec?
... There's also an underutilized discussions space.
Gregg Kellogg: Any issues we'd like to discuss?
Anatoly Scherbakov: There's an issue about use native flags
... but my earlier contribution was apparently incorrect...

Subtopic: w3c/json-ld-api#648

https://github.com/w3c/json-ld-api/issues/648 -> Issue 648 Error in fromRdf/0027-out.jsonld (by marcelotto)
Anatoly Scherbakov: When I was converting literals into JSON-LD
... when they used native types, I was converting them to Value Objects
... but that's not what the spec is going for
... the spec says to use native JSON types
... and I made a PR to address that
https://github.com/w3c/json-ld-api/pull/650 -> Pull Request 650 #648 `0027-out.jsonld`: `@graph` and value objects (by anatoly-scherbakov)
Gregg Kellogg: The first sentence was about `@graph`
... it was always used in 1.0
... but generally eliminated in 1.1
... except for certain use cases
... if JSON-LD is a single object, then you would not expect to see an `@graph` containing it
... so I think there are two things in here
... the specifics of `@graph` and what types of JSON values are emitted vs. expanded values
... you basically want more review, correct?
Anatoly Scherbakov: Yes. exactly
... some re-review would also be appreciated
Gregg Kellogg: So the linked issue is 648
Anatoly Scherbakov: And the PR is 650
Gregg Kellogg: Thanks
... we do also have some things marked as propose close

Subtopic: w3c/json-ld-syntax#443

https://github.com/w3c/json-ld-syntax/issues/443 -> Issue 443 `@protected` creates unresolvable conflicts when the same term is defined in two contexts top-level (by trwnh) [spec:editorial] [propose closing] [wr:commenter-agreed-partial] [class-2]
Gregg Kellogg: This came in through some confusion and discussion
... and any remaining concerns have been moved to another issue
... anyone object to closing this one?
We'll close the issue pending further input.

Subtopic: w3c/json-ld-syntax#447

https://github.com/w3c/json-ld-syntax/issues/447 -> Issue 447 Should `@id` of parent objects be used as a base IRI for relative IRI references? (by trwnh) [propose closing]
Gregg Kellogg: It's pretty clear this is not how the system was intended to work
... I suggest we close this without further action
Niklas Lindström: +1 To close
We'll close without further action.
Anatoly Scherbakov: +1

Subtopic: w3c/json-ld-api#641

https://github.com/w3c/json-ld-api/issues/641 -> Issue 641 Expansion Section 5.2.1, step 7: need clarification (by daenney) [propose closing]
Benjamin Young: Mostly, I'm just happy with the engagement. But it does highlight "tree-based" thinking leaking into interpreting JSON-LD
Gregg Kellogg: Thoughts on this one?
Benjamin Young: Related to the Jelly folk contributions, we should also try to get ActivityPub folks involed.
... Many commenters have done their homework, which is great.
... It's good to have an engaged audience.
Anatoly Scherbakov: Discussion about visualizing stuff: https://github.com/orgs/json-ld/discussions/857
Issue 857 not found
Gregg Kellogg: Any closing issues? or shall we close?
... k. we'll adjourn for the next couple weeks
... please send in topics!
Next meeting in two weeks.
Niklas Lindström: Just a mention, I'm closer to make a PR on https://github.com/w3c/json-ld-api/issues/558
https://github.com/w3c/json-ld-api/issues/558 -> Issue 558 Compaction cannot round-trip terms using `@container: @list` and `@type: @vocab` (by niklasl) [spec:enhancement] [spec:substantive] [ErratumRaised] [class-3]
Gregg Kellogg: K. let's adjourn then