search

dret / I-D

Internet Drafts I've authored or contributed to.
16 stars 13 forks source link

JSON-LD serialization and media type #151

Closed philarcher closed 3 years ago

philarcher commented 3 years ago

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?

hvdsomp commented 3 years ago

Without having read the discussion following Amy’s proposal, wouldn’t an approach that leverages existing mechanisms be:

On Jan 5, 2021, at 18:18, Phil Archer notifications@github.com wrote:

 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?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

philarcher commented 3 years ago

That's the fallback if two + symbols aren't allowed, yes.

hvdsomp commented 3 years ago

Why is it a fallback when the means to implement it are readily available?

On Jan 5, 2021, at 19:03, Phil Archer notifications@github.com wrote:

 That's the fallback if two + symbols aren't allowed, yes.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

dret commented 3 years ago

On 2021-01-05 09:18, Phil Archer wrote:

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 https://github.com/rhiaro) has drafted https://rhiaro.github.io/draft-w3cdidwg-media-types-with-multiple-suffixes/ 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/ https://mailarchive.ietf.org/arch/msg/media-types/tXyxl2ZvKuZIArOAoZW5u43sOxA/.

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.

-- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret |

asbjornu commented 3 years ago

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

richsalz commented 3 years ago

Please use https://github.com/ietf-wg-httpapi/linkset/issues/1 now.