Re: [apps-discuss] Links and graphs

hello graham.

On 2012-11-17 2:39 , Graham Klyne wrote:
> Yes, I see your point about interaction semantics.  I've run into that
> myself in other work I'm involved with.  In some cases, we're
> experimenting with new content types (vnd. tree), that happen to carry
> RDF, but that's not a pretty solution, particularly as it usurps the
> possibility of content negotiation over RDF formats.

from the web/http level, content types are the way to go, that's how the 
conversational context is set. it would be interesting to see whether 
profiles could be a way out of the hole RDF has dug itself into, and i 
think that this might actually work.

> As it happens, I've a pending action to contact LDP for thoughts about
> recommendations or thoughts for a preferred "service home document" for
> aspects of the W3C PROV group work.  Currently, RDF/XML is specified,
> mainly because that's the easiest to specify (just a new link type to
> describe in our case).

http://tools.ietf.org/html/draft-nottingham-json-home-02 might be 
interesting to look at. it's JSONy at the moment, but in the end, it's 
all about representing the concepts defined in there, and we're already 
using JSON and XML variants of this internally, because it's useful.

> If RDF is to be used for a service/home document, other options that
> occur to me are:
> (a) use a media type parameter on the base RDF MIME type; e.g.
>    Content-type: application/rdf+xml;type=(api-home-document)

this could be based on the profile concept (which recommends that media 
types with an extension model might want do allow profile parameters).

> (b) use a different media type linked to RDF (like the +xml family of
> media types?)
>    Content-type: application/api-home-document+rdf
> (This doesn't handle alternative RDF serializations so cleanly)

that would be what the current draft does, it defines the 
application/json-home media type.

> My reading of REST/HATEOS principles is that it's OK to use a link
> relation to guide interaction as well as a media type, but I've never
> really had any opportunity to discuss this with experts in this area.

while this may be a bit fuzzy, typically link rels and media types serve 
different needs:

- a link rel allows a client to understand why it might want to follow 
some link from a resource ("get a picture of the product here").

- a media type then governs the actual interaction, where client and 
server need to agree on how to interact when the client has made the 
choice to engage in the interaction ("here's an image/gif, because you 
told me you know how to handle this media type").

cheers,

dret.

Received on Sunday, 18 November 2012 21:17:34 UTC