JSON-LD serialization and media type

[richsalz]

Copied from dret/I-D#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:

• Use the application/ld+json media type
• Use the “profile” attribute defined for that media type to express that the serialization is a linkset as per the linkset I-D

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

Do others want to see application/linkset+ld+json as a media type?

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).

[hvdsomp]

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]

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]

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.