The W3C JSON-LD Community Group

Go Back

W3C Logo

JSON-LD WG

Minutes for 2025-02-26

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

Topic: Announcements and Introductions

Topic: JSON-LD Issue Discussion

https://github.com/w3c/json-ld-syntax/pull/448 -> Pull Request 448 fix typo in index.html (by TallTed)

Subtopic: https://github.com/w3c/json-ld-syntax/issues/446

Gregg Kellogg: After discussion, this does not seem to be a bug, suggest closing.

Subtopic: w3c/json-ld-api#630

https://github.com/w3c/json-ld-api/issues/630 -> Issue 630 Inverse context creation, 4.3.2.3): what are the keys and values in active context? (by ZLghkA)

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] [wr:commenter-agreed-partial] [class-2]
Gregg Kellogg: Pchampin to comment and close this issue.
Gregg Kellogg is scribing.
Pierre-Antoine Champin: I'll comment, but I don't want to be too dismissive.
... There may be a solution to their problem; I'll investigate. I don't think there's a need for a spec change.
Niklas Lindström: Sounds like it should go in Best Practices.
... Generally, it might be clearer to explain that if you use someone else's context you should create your own.
David I. Lehn: A related issue with someone bumping into protected redefinitions: https://github.com/digitalbazaar/jsonld.js/issues/563 (and also confusion related to ordering based on type names)
https://github.com/digitalbazaar/jsonld.js/issues/563 -> Issue 563 Lint complains of redefinition when re-using term with context (by absoludity)

Subtopic: https://github.com/json-ld/json-ld-wg-charter/issues/2

https://github.com/json-ld/json-ld-wg-charter/issues/2 -> Issue 2 Update "Out of Scope" section. (by BigBlueHat)
Pierre-Antoine Champin: We could explicitly make out of scope any significant extension of JSON-LD (making it more complicated).
... This is a fine line between extending to RDF 1.2 and adding requested features.

Subtopic: https://github.com/json-ld/json-ld-wg-charter/issues/3

https://github.com/json-ld/json-ld-wg-charter/issues/3 -> Issue 3 New normative document proposal: Supporting Multiple Languages in JSON (by BigBlueHat)
Pierre-Antoine Champin: I like the idea of this, but I'm reluctant to add a normative deliverable. Is there incubation other than JSON-LD on this?
... Its a bit new to add normatively to the stack. We could say we'll start work on it, but not necessarily commit to publishing as a REC.
Benjamin Young: Since proposing this, the idea was that it would be a bridge into JSON-LD, but creating something like this could potentially have a negative value on JSON-LD.
... My greater hope is to get people to link into some section of the existing specs and provide code to parse it.
... I'd suggest we scrap this.
Gregg Kellogg: This could go in best practices.

Subtopic: w3c/json-ld-api#627

https://github.com/w3c/json-ld-api/issues/627 -> Issue 627 Recommend a way for dependent specs to call into this one, that's not WebIDL (by jyasskin) [ms:future-work] [needs discussion]
Benjamin Young: It was non-normative in the RDF WG days, but we worked it harder into 1.1.
... It comes down to who is going to take this on as an action. I don't think the TAG will continue to allow us to use WebIDL.
... It's not clear what the alternative is.
Benjamin Young: I agree that it's not really worth doing something different. WebIDL is typically about browsers, but the TAG told us to use it for 1.1 and changes were made to isolate the context from browsers.
... I'm not sure how big the ask was to switch to using INFRA terms, and it's hard to know the net benefit.
... I don't really see the benefit either. We already have places in the spec that use the WebIDL type system.
... It's a historic artifact, and we will continue to provide context to the data structures.
... He pointed to VC WG discussions about "calling into the JSON-LD spec".
... The concern is in the EDDSA spec (referenced in the issue).
... The conversation has similar confusion. If EDDSA had linked to WebIDL it may cause issues with the TAG.
Pierre-Antoine Champin: I delved into these discussions I think the commenter has conflated the JSON-LD API with some global configuration.
https://github.com/w3c/json-ld-api/issues/580 -> Issue 580 LoadDocumentCallback isn't passed into the algorithms that use it (by jyasskin) [spec:editorial] [ErratumRaised] [Editorial] [class-2]
... In the VC issue he was concerned about parameters about the documentLoader, defined via the API (WebIDL). But, you could abstract away the API and the fact that it is expressed in WebIDL.
... WebIDL is there for historical reasons. We can clarify that using the API doesn't necessarily mean using WebIDL.