Closed richsalz closed 3 years ago
hvdsomp
commented
3 years ago Just felt like mentioning that other work is being done in the realm of this discussion that leverages the approach of using a "profile" attribute to clarify the nature of a JSON-LD serialization beyond its media type, see the I-D Indicating, Discovering, Negotiating, and Writing Profiled Representations.
hvdsomp
commented
3 years ago hi @richsalz @philarcher, I wonder whether this issue can be closed as it seems to go quite beyond the scope of the linkset I-D.
philarcher
commented
3 years ago Whilst I was disappointed at the reaction, it's obvious this group doesn't want to take this up so, yes, please close the issue. Thanks for asking.
Copied from https://github.com/dret/I-D/issues/151; here's the comments
@philarcher: In our (GS1's) implementation of linkset (not yet complete but coming along nicely), we're using conneg to go between linkset and linkset+json. Actually, whether you ask for application/linkset+json or just application/json won't matter as we only have one JSON format and it's linkset.
But we're Linked Data people so we'll also include the HTTP Link Header pointing to a JSON-LD context file (ours is currently at https://www.gs1.org/gs1-digital-link/artifacts/dl-resolver-context.jsonld but might move). You'll get that HTTP link header whether you ask for it or not.
What we'd really like though is to be able to request the linkset as JSON-LD with the context file in the file itself. That suggests we'd need a media type of application/linkset+ld+json.
If others agree that this is a desired feature then you'll notice the two + symbols. Which is a problem. The good news is that others have the same issue. Amy Guy (@rhiaro) has drafted https://rhiaro.github.io/draft-w3cdidwg-media-types-with-multiple-suffixes/ on this topic and it's being discussed over at https://mailarchive.ietf.org/arch/msg/media-types/tXyxl2ZvKuZIArOAoZW5u43sOxA/.
Do others want to see application/linkset+ld+json as a media type?
From @hvdsomp Without having read the discussion following Amy’s proposal, wouldn’t an approach that leverages existing mechanisms be:
From @philarcher That's the fallback if two + symbols aren't allowed, yes.
From @dret without wanting to start a debate here, but this has been going on for well over a decade now: how to resolve the conflict between generic media types and the desire to be more specific at the media type level.
personally, since generic types (and the RDF-ish ones specifically targeted) can be composed out of any number of schemas, it's hard to imagine this working out in the simple world of the structured syntax of media types. Do others want to see |application/linkset+ld+json| as a media type? i am curious to hear opinions. if we're going down the route of "any schema combo based on RDF-ish generic types will get translated into a registered media type", then we will get to a point where media type registration as we have it today doesn't scale anymore.
for these reasons, my approach would be to go a more scalable route and pick whatever pattern is most popular in the JSON-LD community now.
From @asbornju
That looks very unorthodox to me. I'm not a JSON-LD expert, but I haven't seen any other media type than application/ld+json used for it. The "profile" of a JSON-LD document is specified in its @context, either inline or via the HTTP Link header. I suppose adding a profile URI to further clarify the flavour of JSON-LD we're dealing with is fine as a hint for those that won't parse the content as linked data (RDF).