The W3C JSON-LD Community Group

Go Back

W3C Logo

JSON-LD CG

Minutes for 2024-12-11

Present
Gregg Kellogg, Niklas Lindström, Anatoly Scherbakov, Benjamin Young, Pierre-Antoine Champin, Ted Thibodeau Jr., Bob Way, Ivan Herman, David I. Lehn, Herbert Van de Sompel, antoine isaac
Chair(s)
Gregg Kellogg
Scribe(s)
Benjamin Young, Gregg Kellogg
Agenda
https://www.w3.org/events/meetings/3509d178-04b3-43ae-9bb2-79fb946a91c1/20241211T120000/
Topics
  1. Announcements and Introductions
  2. Profile Negotiation
  3. Issue Discussion
  4. Next Meeting

Topic: Announcements and Introductions

Bob Way: Present
Benjamin Young is scribing.
Gregg Kellogg: Welcome back everyone
... this is our last meeting of the year
... our next meeting will be Jan 8
... no other announcements...anyone have anything else
... should we do some intros?
... Herbert?
Herbert Van de Sompel: I'm a research fellow from Austria
... I've done standards for 20+ years
... and profile negotiation is probably the worst [laughs]
Bob Way: I work with Dutch Heritage Network
... with Rob Sanderson and others
... and profile negotiation comes up often
Gregg Kellogg: We did make this a CG meeting
... to make it easier for guests to participate
... if we have time later we may look at some issues

Topic: Profile Negotiation

Gregg Kellogg: We did have an open issue on this
... and now we have a good bit of feedback
... Herbert, Bob would you like to kick off the discussion?
Herbert Van de Sompel: I did send a link to provide an overview
... this discussion has been going on forever and has yet to have a resolution
... my hope is to sort out how to proceed
... we have a W3C route, and IETF route, etc.
... is there interest in pursuing this work? and if so where? and whom?
... as a sample of how hard this is, my two co-authors have both been radio silent in response to this recent interest
... it needs solving at the process level as much as technical
Gregg Kellogg: My concern is what issues exist for JSON-LD and what can we do about them
... one issue is the emergent problem of using URIs as profile values
... that is now recently undermined by other groups
... so an alternative to that may be using a `Link` header
... so our general question is how can we apply best practices here?
Herbert Van de Sompel: The two existing drafts overlap a good bit
... and the IETF work got copied into the W3C work
Niklas Lindström: I think we should say what we mean by "profile" here
... one is something like data shapes--which is not what I mean
... and the data shapes WG is talking about those in a sense more like application profiles from Dublin Core
... those are a preferred selection of terms from vocabularies
... I wouldn't say that's an emerging concern
... we are hoping that profile negotiation gets attention to help with this need
... but I'm not clear on what we mean by `profile` in the JSON-LD specs
Herbert Van de Sompel: If you look at the I-D, both of the things you've described are covered
... one is representation related
... and the other is application/vocabulary related which is independent...though interdependent of the representation
Pierre-Antoine Champin: I'm the team contact for JSON-LD and other groups
... like Data Set Exchange
... I'd like to see this work progress
... despite the growing list of issues
... what we talk about as profile negotiation in JSON-LD seems to differ a bit
... it doesn't really require content negotiation
... if someone sends me a document with `profile` that uses an IRI in the value, fetch will fail due to CORS
... I think it's great that this issue triggered a larger discussion
... there has also been some activity around the profile recommendation...which sadly stopped about 6 months ago
Niklas Lindström: For reference, at the Nat. library of Sweden, we experiment with prof-neg to allow consumers to select one of some (currently predefined) sets of "selection of vocabularies": https://github.com/libris/librisxl/blob/develop/rest/API.md#profile-negotiation *orthogonal to serialization format (all within the bounds of RDF)
... part of the reason it stalled is the ambiguity between the current drafts
... are there plans to take either of these further?
Herbert Van de Sompel: There was an attempt to talk to IETF dispatch about this work
... they decide where it fits within the IETF
... and pointed us to the HTTP API
... I've worked there and did the Link Set spec
... but that group came back and said "the industry" wasn't interested
... however, one is not required to go that route, but could publish a personal informational spec--which is what I did for Memento
... and Memento has been used by Web Archives
... a W3C route would be another route forward
... any of these have scoping concerns
... the I-D would be singularly about the negotiation
Pierre-Antoine Champin: Maybe we can dig into some of this offline
... and try to focus a bit on what JSON-LD is dealing with specifically
Gregg Kellogg: 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]
Herbert Van de Sompel: That issue you mention with CORS and content-type is purely HTTP related
... there was some solution that Rob was happy with--preflight
Gregg Kellogg is scribing.
Benjamin Young: In JSON-LD, the profile is used as a parameter on a media-type; it's been surfaced in sub-groups, such as web annotation.
... We went that way to avoid registration issues, but CORS is creating problems
... Since then, the IETF has encouraged more top-level media types.
... The verifiable credentials group is using a new top-level media-type.
... We thought that using a parameter to express a preference would be the right way to go.
... Now, we need advice on other ways to handle this.
Herbert Van de Sompel: Thanks for those details, bigbluehat
... one of our issues talk about that specifically
... I did not know that using a `profile` parameter didn't work
Benjamin Young: Neither did we
Herbert Van de Sompel: I think it's actually good news
... one could use the `Accept-Profile` approach instead...since normal content negotiation no longer works
... so, we could instead use the `Profile` header instead
... what if a client expresses a `profile` attribute and an `Accept-Profile` header
... but now if `profile` no longer works, then that ambiguity is cleared up
Gregg Kellogg: The `Link` header is the other option
Herbert Van de Sompel: There's a problem with that also?
Gregg Kellogg: The `Link` header can be used for both request and response, correct?
Herbert Van de Sompel: The `Accept-Profile` is for requests, `Profile` is for responses
... the `Link` header could be used. I've never seen a problem with it
... but I do see an issue with using it alongside `Accept`
... you could also use URIs there...even multiples
Gregg Kellogg: And JSON-LD's existing use of `profile` show use of multiple URIs
... we even showed how to use `profile` to specify the frame to use
... probably some security concerns with that one...but perhaps some allow listing for those could help
... but those would likely be application specific
... probably where JSON-LD wants to go
... is to move away from `profile`
... and instead look to using the `Link` header or `Accept-Profile`/`Profile` to specify that
... not every application is hampered by CORS as the browsers are
... but we may want to deprecate that use
... so for the purpose of this group, that's what we're hoping to focus on
Herbert Van de Sompel: So, you could continue to use `profile` as a parameter
... and you can use them in `Accept` and `Content-Type`
... but as soon as you start doing profile negotiation, you use `Accept-Profile` instead
Pierre-Antoine Champin: So, if we went the individual specification route at the IETF, can a W3C spec depend on it?
Ivan Herman: No
Pierre-Antoine Champin: If we go that route, we need to have a normative reference
... we would end up relying on that
... so we'd need them to be full specifications to move forward
... we have had these conversations with the IETF
... and they said it needed to be there...but then no one will let it be developed there
... so we are at an impasse
... I will reach out again to see if there's a path forward there
... or to say we will do it in the Data Set Exchange WG to move it forward
... so this group can reference the work
Herbert Van de Sompel: Iirc the conversations from 2021, that if the W3C would express "real interest" that the IETF Dispatch could be moved
... Darrell Miller would be someone to contact there
... even if someone goes non-standard track
... someone can officially register HTTP headers
... I did this with Memento
... so, non-standard track documents can register headers
Ted Thibodeau Jr.: I'm a little concerned that these documents are only consumable via a web server
... if that profile is only expressed in the content type, how do I know what the profile is elsewhere
Gregg Kellogg: There are other places where HTTP headers are used
Ted Thibodeau Jr.: This means that I cannot have a local copy of that document
Pierre-Antoine Champin: TallTed you could make the same remark about content-types....
Herbert Van de Sompel: You can download it
Ted Thibodeau Jr.: Where's the profile info go?
Benjamin Young: The profile is typically in the context; profile negotiation is to specify the format, which isn't needed to consume the document.
... If the document is self-contained, you don't need the profile. It's used when requesting a particular form of a document with the same semantic information.
... If you need a file extension, you MUST use a top-level media-type.
Herbert Van de Sompel: That does raise questions around self-contained-ness of the representation
... that doesn't hold for all media types
Ivan Herman: Coming back to what can be done or not done
... I reacted to the individual submission
... but there are actually not rules against them per se
... but the question is really about stability
... if you get a specification that meets certain requirements
... then if it is stable enough than it can be referenced
... for example (though perhaps controversial), we have a green light to reference schema.org
... there is little probability that that will disappear in the coming years
... the other thing, if it's on the IETF turf, can we standardize it?
... there are examples. One recently.
... in the VC WG, there were issues with multikey and multibase
... the standing of the group had been that it should be done at the IETF
... it never happened there for reasons I do not know
... but we had to move on
... so now we have parts of those specifications in our VC specifications to solve for lack of progress at the IETF
Herbert Van de Sompel: If you go the IETF route, even with a personal spec, you do get an RFC which is stable
Ivan Herman: Yes, and we can always go to the management to get permission
Benjamin Young: I think we've centered around where to specify things; can we circle back to what the JSON-LD community needs?
... We have Accept-Profile and Profile headers to consider, as well as the Link header.
... Does the JSON-LD group feel that there is a way forward using these?
Herbert Van de Sompel: You could decide to step away from classic content negotiation
... and totally move to `Accept-Profile` and `Link`
... which would actually solve a problem with the I-D
Gregg Kellogg: That seems like the way forward for us
... and I don't think we'd have a problem linking to those
... with some wording that indicates some non-normative description around the issues with CORS
... and how to handle conflicting info like `profile` in `Accept` or `Content-Type` as well as `Accept-Profile` and `Profile`
Herbert Van de Sompel: In case you get in touch with folks at the IETF, please copy me
... I am willing to put cycles to get this draft done
... and I'll find my co-authors...hopefully
Pierre-Antoine Champin: I'm happy to help you move this forward
Niklas Lindström: Thank you for moving this forward!
Antoine Isaac: +1
... in the JSON-LD situation, we would probably need to consider...
... can you negotiate for two combinable profiles?
... we currently have asking for the frame and the specific vocab/context for that same JSON-LD
Herbert Van de Sompel: You can provide space delimited URIs in `Profile`
... I'd need to check on `Accept-Profile`
... if you would have the notion of combined profiles, you would have to give that combination another URI
... you'd need a "super URI"
... that points at the other three
... I think that's how it would work
... but it's been years...so I'd have to look again
Herbert Van de Sompel: There is a profile URI for framed now, correct?
Niklas Lindström: Yes
Herbert Van de Sompel: Does it fit with this notion of profile? ... it feels a bit different
Gregg Kellogg: It was a similar notion
... to define how you would like to get a document back
... we expected client to get JSON-LD with the context they wanted
... so we used these to be more explicit
... and you might still have a vocabulary profiling happen
... and maybe these are too many concepts into one vehicle
Antoine Isaac: Reacting with some history
... we discussed making the framing profile and the more semantic profile
... in the end, we had concluded that how we did it was fine
... but that's just a memory from Lyon

Topic: Issue Discussion

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]
Anatoly Scherbakov: No real progress yet
... thank you for the detailed reply gkellogg
Gregg Kellogg: Any other issues?

Topic: Next Meeting

Gregg Kellogg: Next meeting is January 8th
... enjoy the end of your years
... and talk soon!
Anatoly Scherbakov: Merry Christmas and a great 2025 to all!