The W3C JSON-LD Community Group

Go Back

W3C Logo

JSON-LD WG

Minutes for 2024-11-13

Present
Ted Thibodeau Jr., Gregg Kellogg, Pierre-Antoine Champin, Niklas Lindström, Anatoly Scherbakov, David I. Lehn
Chair(s)
Gregg Kellogg, Benjamin Young
Scribe(s)
Gregg Kellogg
Agenda
https://www.w3.org/events/meetings/3509d178-04b3-43ae-9bb2-79fb946a91c1/20241113T120000/
Topics
  1. Announcements and Introductions
  2. Issue Discussion
Resolutions
  1. Address the concerns around when to use `@protected` (which were raised in https://github.com/w3c/json-ld-syntax/issues/443) through new content in the JSON-LD Best Practices document.
Gregg Kellogg is scribing.

Topic: Announcements and Introductions

Topic: Issue Discussion

Benjamin Young: We're working through the project list.
Gregg Kellogg: Added issues that are class 1-3.
Subtopic w3c/json-ld-syntax#436
https://github.com/w3c/json-ld-syntax/issues/436 -> Issue 436 URI in Profile triggers CORS Unsafe Request Header Byte rule (by azaroth42) [spec:w3c] [needs discussion] [tag-needs-resolution]
Gregg Kellogg: Might just create "tokens" for profile paraemters.
Gregg Kellogg: Tokens not being namespaced is mitigated by the fact that the media-type is the namespace.
Benjamin Young: So, it treats the media-type as the namespace.
... Profile parameters not having a colon is wide-reaching
Gregg Kellogg: Not sure how we update guidance for using profile parameters.
Benjamin Young: This would be a breaking change for web annotations.
... That would mean web annotations needs their own media type.
Niklas Lindström: Dlehn's reply may mean this isn't as horrible as it seems.
... I think the datasets working group has done something with this.
Pierre-Antoine Champin: This doesn't seem to be a problem where things can't work, but making them work is tricky, due to pre-flight requests.
... If we expect a server to support profile-based content-negotiation, it doesn't come automatically.
... If you want to support this, you'll also need to support pre-flight requests.
Benjamin Young: Q|
... This is difficult to configure and easily forgotten.
https://github.com/w3c/json-ld-syntax/issues/436 -> Issue 436 URI in Profile triggers CORS Unsafe Request Header Byte rule (by azaroth42) [spec:w3c] [needs discussion] [tag-needs-resolution]
Benjamin Young: There were some suggestions for defining enumerated values (tokens).
Pierre-Antoine Champin: I think it wouldn't hurt to define "short names" for the profiles in addition to the currently defined IRIs
... The key is to not make it a breaking change.
... This would affect the media-type registration.
Niklas Lindström: Aren't link headers defined similarly, where there are pre-defined tokens and IRIs may also be used.
Benjamin Young: Browsers have made decisions which are affecting what we can do.
Benjamin Young: > When processing the "profile" media type parameter, it is important to note that its value contains one or more URIs and not IRIs. In some cases it might therefore be necessary to convert between IRIs and URIs as specified in section 3 Relationship between IRIs and URIs of [RFC3987].
Niklas Lindström: Application/ld+json;profile="http://iiif.io/api/presentation/3/context.json"
Niklas Lindström: I think it would be good to add tokens. Rob's specific problem are more about the other uses of profiles.
... I wonder if our solution would be considered a solution for the issue; maybe parts of the issue can't be solved in the JSON-LD spec. Might recommend IIIF to use profile negotiation.
... But, using pre-flight does work, so that would be on their end.
... It's more that we put forward the design pattern and it has become more tricky.
Benjamin Young: The ramifications of this are not just expand/compact/... Rob's point is for other specifications that used the same pattern.
... No we know to avoid it.
Niklas Lindström: See also: https://www.w3.org/TR/dx-prof-conneg/ (and https://profilenegotiation.github.io/I-D-Profile-Negotiation/I-D-Profile-Negotiation.html )
... There's reason to document this in the best-practices document. How this affects other specs would mean that they cannot treat profile as being extensible, and will need a new media type.
Gregg Kellogg: We might create a registry to allow other specifications to add their profile parameters without needing a new media-type.
Benjamin Young: Niklasl shared a document on using the profile parameter for content negotiation.
Pierre-Antoine Champin: Reaching out the that TAG would be a good idea, as other specs rely on this, and they would be impacted.
... I'd like to see their thoughts and how much we should make the effort to try to change this.
... Regarding the spec, note that this is a working draft which has been inactive for a while. This might not be the strongest argument to take before the TAG. (The dataset exchange WG)
... Part of the reason that spec is stalled is that there are contentious discussions with IETF on where it belongs.
Niklas Lindström: From the dx-prof-conneg draft: During 2018, DXWG members had a longer discussion with the JSON-LD WG at the annual forum TPAC in Lyon, France and it was concluded that the "profile” parameter in the Accept and Content-Type headers should be seen to convey profiles that are specific to the Media Type [such as JSON-LD's expanded .... ]
... But, is there enough interest in IETF to continue the work?
Niklas Lindström: There are aspects of the draft that goes into the profile parameter of the media type is the right way to go.
... The design of IIIF and Activity Streams I appreciate more when not looking at it from an RDF perspective.
... These are more useful at the intersection of JSON and RDF, which makes it easier to create specifications in a distributed way.
... If I believed (from RDF perspective) that format is irrelevant, general content negotiation works well.
... I can see how the TAG might argue from one of these perspectives. Maybe we shouldn't invent media-types on the fly.
Pierre-Antoine Champin: Regarding the value of using JSON-LD media-type with parameter vs a new media-type, VC has had to rely on this for a while.
... The current solution is to have a dedicated media-type with additional language to explain the relationship between the two media types.
... We might point other specs to that solution.
Niklas Lindström: +1 To mentioning that "third" point of view (very pertinent IMHO)
Benjamin Young: I think we need to move on and come back to this issue.
... It would be great to write some of these things up on the issue so that we have something coherent to bring to the TAG.
... IETF has shifted their approach, and we're stuck in the middle. In the mean time, if we can collect thoughts in the issue.
... I don't think we know enough to lay out the preferred solution.
... If we go the short-name route, we run the risk of turning into a registry.
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]

Subtopic: w3c/json-ld-syntax#443

Benjamin Young: This dove-tails with the profile-parameter conversation for other communities
... If a media type expects a context to exist, they would inject one if not provided.
... We could make other discussion issues from comments in this issue.
Niklas Lindström: IIRC, Activity Streams says you should put their context last because of this issue.
... If you use short names that have meaning, you must lock them down.
David I. Lehn: I need to re-review the issue.
... In the case of the controller, it would be to change the activity streams URL, but that's kind of strange. People expect terms to be gathered in one place.
Niklas Lindström: Maybe what is asked for is how to use this design pattern to have partial extensibility, extensions which are always subordinate to the "hardcoded" context (that may evolve)?
... This would conflict with other things where JWT is also used.
Pierre-Antoine Champin: The comment at the end is interesting as it resonates with TPAC discussions.
... There are two types of JSON-LD, one which is more about the RDF semantics, the other is about general representation of knowledge.
... I sympathize that we should make this more clear, but don't think it's a bug in the spec.
Benjamin Young: There's a tension between generic JSON-LD which is endlessly pluggable, which confuses people.
... In this view, JSON-LD isn't the end product, but adding in @protected you constrain it into a use case, as you are using very specific terminology and limiting the extension points.
... At TPAC there was a discussion about other things, such as schema.org, or are we going to specific content formats with self-defined semantics.
... Maybe this is not a syntax change, but a best practices note. If you're in ld+json land you can do what you want, but if you're in something that provides more constraints, you may need different solutions.
Niklas Lindström: +1 For best practice
Anatoly Scherbakov: +1
Gregg Kellogg: +1
David I. Lehn: It seems to be a bit more than best-practices as you need to tell people how to get around the rules.
David I. Lehn: It's nice when things live together.
Benjamin Young: In the future, maybe there would be a way to link from the spec to BP.
PROPOSAL: Address the concerns around when to use `@protected` (which were raised in https
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]
Benjamin Young: +1
Niklas Lindström: +1
Pierre-Antoine Champin: +1
Gregg Kellogg: +1
Anatoly Scherbakov: +1
Ted Thibodeau Jr.: +1
David I. Lehn: +1
David I. Lehn: Is it more "when" or "how" to use @protected?
RESOLUTION: Address the concerns around when to use `@protected` (which were raised in https://github.com/w3c/json-ld-syntax/issues/443) through new content in the JSON-LD Best Practices document.
Benjamin Young: We can make it as "best practice" and notify the commenter.
Niklas Lindström: ... And *why* to...
... @protected needs more content.
David I. Lehn: "... When, how, and why to use ..."
Anatoly Scherbakov: That's the one: https://github.com/json-ld/yaml-ld/pull/157
https://github.com/json-ld/yaml-ld/pull/157 -> Pull Request 157 Fix: #156. Update media type registration information. (by ioggstream)

Subtopic: w3c/json-ld-api#608

https://github.com/w3c/json-ld-api/pull/608 -> Pull Request 608 Resolve the questions about "JSON Serialization" term (by anatoly-scherbakov) [spec:substantive] [ErratumRaised] [class-3]
Gregg Kellogg: Once we have approvals, we can merge.
Benjamin Young: There are more issues to discuss, but we'll continue to just move through the list. Cleaning house before worrying about the charter makes sense.
Benjamin Young: The project manager should include YAML-LD, CBOR-LD, JSON-LD-star and other things the WG is working on.