Re: [apps-discuss] Links and graphs

[Resending - bounced from public-ldp-wg]

[Switching discussion to LDP, trimming IETF-APPs]

Eric,

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.

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

...

For information, I was involved in some work several years ago that was intended 
to convey document information that wasn't easily conveyed in the MIME media type:
   http://www.ietf.org/rfc/rfc2506.txt
   http://tools.ietf.org/html/rfc2912

I'm not promoting this as a solution, just mentioning it so you're aware of 
previous work.

...

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)

(I don't favour this approach)


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


(c) use a new link relation; e.g.

   Link: <api-home-document>; rel="rdf:type"

or similar.

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.

I'd be interested to hear of other developers' preferred approaches.

#g
--


On 15/11/2012 17:36, Erik Wilde wrote:
> hello graham.
>
> On 2012-11-15 5:02 , Graham Klyne wrote:
>> I don't follow what you're saying here.  I don't disagree (as someone
>> involved with RDF) that RDF has made its life hard in several ways, but
>> if what you have and want to pass around is a graph, how does one *not*
>> push it down into the data?
>
> the big problem with RDF on the level we're discussing here is that RDF pushes
> everything into vocabularies, and thus renders media types almost meaningless
> (apart from distinguishing RDF serializations). that's a problem for home
> documents or similar web-oriented approaches that rely on the media type being a
> crucial signal for understanding the interaction semantics of resources.
>
>> (Personally, I'd like to see json-home be something that has a clear
>> mapping to RDF, but that's a different discussion.)
>
> fwiw, https://github.com/dret/I-D-1/tree/master/json-home is where i have
> started creating a mapping to XML, and i'd be more than happy to collaborate
> with others to do the same for an RDF schema. but like i said above, the whole
> concept of home documents hinges around the assumption that a media type signals
> interaction semantics, so that clients can decide what resources to engage with.
> in RDF, this is not how the world works (yet, i still hope that we'll see this
> tackled at some point in time), so maybe there's a little less utility in the
> whole approach. regardless of that, we have discovered in our current work in
> the "Linked Data Platform" W3C WG that we probably need some concept of a
> "service document" or a "home document", and thus it might be interesting to
> look at how the current json-home approach could be mapped to RDF and would give
> us some useful foundation.
>
> cheers,
>
> dret.
>

Received on Saturday, 17 November 2012 10:39:47 UTC