Re: Mediatypes that map to application/ld+json with a profile

On 16 July 2016 at 06:21, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:

> Hi Sarven, Phil, Rob,
>
> > Are there mediatypes that map to application/ld+json with a profile?
>
> This begs the question why one would want to do that.
>

This was investigated by the WG.  Over a period of time the pros and cons
were collected, and the cons firmly outweighed the pros:

https://www.w3.org/wiki/Socialwg/Media_type_for_AS2

However, there is a small but vocal contingent in the WG hostile to Linked
Data.  For example, one comment from the chair on this topic that was
unqualified was "JSON-LD is a non starter".

Ultimately this bespoke mime type got voted through IMHO against general
consensus, and common sense, and without looking at the evidence collected,
which is something that I mentioned in the minutes.

So we're stuck with a CR at the moment this is "sort of" linked data, but
not quite.  It's a real pain.

>
>
> The problem with specific MIME types is
> that they are only one-dimensional.
> What if multiple dimensions have to be considered?
> What if I want an activity represented in RDF,
> but not in JSON-LD? Do we need things like
> application/activity+turtle or +xml? That doesn't scale…
>
> Why would we want to have such specific media types
> when we already have media types for RDF syntaxes?
> After all, the whole idea of RDF data is that it is self-descriptive;
> that a client can understand that a document contains
> an activity / person / building by interpreting it.
> application/activity+json should be totally unnecessary.
>
> Note that there is currently no official interpretation of the + token,
> so a client cannot even assume application/xxx+json is a JSON(-LD)
> document.
> Clients have to he hard-coded for application/activity+json.
> This defeats much of the purpose of RDF.
>
> >> Format/serialisation/Mime Type, whatever, is not enough. You need to
> >> know the profile. Erik Wilde has an internet draft on this [1] too.
>
> I definitely think profiles are the way to go.
>
> >> Should we also consider it as another dimension of content negotiation?
>
>
> Definitely. That's the only use case I see for
> application/activity+json-ish things,
> telling a server that you expect a certain vocabulary / profile.
> So I'd expect a client to say
>     Accept: text/turtle;profile="http://example.org/activity"
> instead.
>
> >>> The Web Annotation WG decided /not/ to do this, and to only use a
> profile.  So the media type for the JSON-LD annotation serialization is:
>  application/ld+json;profile="http://www.w3.org/ns/anno.jsonld"
>
> I love it; that's the most scalable way to do this,
> and it does justice to what RDF stands for:
> the interpretation is inside of the message.
>
> How is it actually implemented?
> It should be sufficient that the client does
>     Accept: application/ld+json;profile="http://www.w3.org/ns/anno.jsonld"
> and the server only says
>     Content-Type: application/ld+json
> since the rest would be in the message.
>
> Actually, the client should also be able to say
>     Accept: text/turtle;profile="http://www.w3.org/ns/anno.jsonld"
> to which the server would reply with
>     Content-Type: text/turtle
> but I guess the notion of "profile" (RFC 6906)
> here is to be interpreted more strictly as "JSON-LD profile".
> I would be interesting to consider
>     Accept: application/ld+json;profile="http://www.w3.org/ns/anno"
> without any extension, allowing content negotiation on the profile.
>
> Best,
>
> Ruben
>
> PS Wrote more about that here:
> – http://ruben.verborgh.org/phd/ruben-verborgh-phd.pdf#page=103
> – http://ruben.verborgh.org/blog/2015/10/06/turtles-all-the-way-down/
>