Re: Links and graphs

Eric,

Thanks for your earlier response.  I've been sitting on this for a while, to try 
and better understand where I stand on the points you raise.  I've just read 
through highlights of the thread at 
http://lists.w3.org/Archives/Public/public-ldp/2012Nov/0007.html ("LDP would 
benefit from being RESTful"), so this may be the time to continue discussion.

TL;DR:
1. It is overloading the notion of media type to have it be the sole determinant 
of interaction;
2. The distinction between "why a client might use a resource" and "how a client 
might interact with a resource" is not (as you also indicate) entirely clear 
cut, making it unsuitable as a dogmatic basis for choosing format over link 
relation for driving an interaction
3. Link relations appear in content as well as in link headers (and other 
protocol-level structures)
4. Client implementation is much easier if they can use Link headers (or 
equivalent) to choose between available resources, where such choice may depend 
on the client's interaction capabilities.

This all leads me to to see plenty of upside and no downside in liberal use of 
link relations to guide interactions.

I also think we lack a common or self-describing way for link relations to guide 
interactions.

...

For reference:
[1] http://lists.w3.org/Archives/Public/public-ldp/2012Nov/0030.html
     (full message to which I'm responding)
[2] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07893.html
[3] http://lists.w3.org/Archives/Public/public-ldp/2012Nov/0024.html
[4] http://lists.w3.org/Archives/Public/public-ldp/2012Nov/0007.html (et seq.)
[5] http://tools.ietf.org/html/rfc5988

On 18/11/2012 21:17, Erik Wilde wrote:
 > 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.

[...]

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

I originally indicated that I don't favour this, but I might be persuaded.  Part 
of my concern is that once you start adding parameters to media types, they 
become more difficult to process, and some client libraries might make it harder 
or impossible to access the information they convey.

 >> (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/HATEOAS 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").

This is interesting, and what gave me grounds for thought.
But in the end, I think it's not entirely helpful, especially when dealing with RDF.

I have two difficulties:


1. Overloading of media type

(For what follows, I'm assuming that interaction is linked to document semantics.)

Depending on media type to define interaction/semantics is overloading the 
original notion of media type, which was:
[[
A Content-Type header field [...]
which can be used to specify the media type and subtype
of data in the body of a message and to fully specify
the native representation (canonical form) of such
data.
]]
-- http://tools.ietf.org/html/rfc2045 (section 1)

Note here the purpose of specifying *representation*, not *interaction* (or 
semantics).

This was fine in the days when data formats tended to correspond 1:1 with their 
semantics.  Even with XML, despite there being a common underlying lexical and 
syntactic structure, each document type is really a distinct syntax, and it can 
make sense to treat each as a distinct MIME type (hence the +xml convention).

But RDF changes the game quite fundamentally by being an "open world" format 
(or, as Dan Brickley once put it, "missing isn't broken"): there is a truly 
common syntax that carries any or all kinds of data semantics.  In particular, a 
document following RDF syntax can combine different semantics, by design.  So in 
some cases, one can't claim that a document supports or specifies a single 
interaction, as it may depend on what parts of the document one chooses to follow.

So I think that attempting to use a single media type to indicate interaction 
semantics with an RDF document is doomed to be problematic: a single document 
may serve for multiple independent kinds of interaction.


2. "why?" and "how?"

Your description suggests (to me) that:
- link relations indicate why an application might wish to interact with a document
- the media type covers the "how"

I think this is a useful starting point, but falls short as the whole story 
(partly for reasons above about overloading the media type), but also the 
distinction between why? and how? can be indistinct - client capabilities may 
drive the choice of one resource over another.

A particular problem I'm facing is accessing information for which there is a 
simple REST API and/or a SPARQL endpoint.  I think it's reasonable (and much 
easier on the client) to have different link relations for these, and then 
provide supplementary detail in a service description.  But your response 
suggests this isn't the right thing to do.  If the only reason for this is the 
"why?" and "how?" distinction, then I think that's not a good enough reason, 
especially if it leads to more complex client code or delayed detection of 
inability to interact (which I think it may).

...

Where does this lead?  The starting point for this discussion was a question 
about using RDF or something else for describing a service endpoint.  Reading 
the thread about LDP and REST, I find that I disagree with your position about 
RDF not being a suitable form of hypertext for driving interactions.  More 
precisely, I do agree with Kingsley Idehen's position:
[[
RDF isn't RESTFul at all. It's just a webby entity relationship model
endowed with explicit entity relationship semantics. Thus, an RDF
serialization isn't implicitly RESTful.

RDF based Linked Data is RESTful, in the basic sense.
]]
-- http://lists.w3.org/Archives/Public/public-ldp/2012Nov/0019.html

That is, as I see it, RDF alone isn't sufficient to be RESTful (after all, it's 
just a format), but it makes a pretty good basis for hypermedia that can drive 
RESTful application state.  What it needs is some vocabulary to describe the 
desired interactions.

And here, I come back to Link relations:  as far as I see them, Link: headers 
are (or can be) just another syntax, carried at HTTP protocol level, for RDF 
relations.  I would expect a link relation URI to convey the same information 
when used as an RDF property or a Link: header relation with the same 
(subject,object) or (context,target) values respectively.  Why would anyone 
choose to do otherwise?

Which all leads me to think that separating link relations from content isn't 
entirely helpful.  RFC 5988 may not mention RDF explicitly, but it does say:
[[
The Link entity-header field provides a means for serialising one or
    more links in HTTP headers.  It is semantically equivalent to the
    <LINK> element in HTML, as well as the atom:link feed-level element
    in Atom [RFC4287].
]]
-- http://tools.ietf.org/html/rfc5988#section-5

This establishes the idea that Link: headers are just another way of expressing 
links that are otherwise expressible in content.  It seems to me to be a small 
step to include RDF alongside HTML and Atom.

I am seeing here a duality between formats and interactions:  formats can 
describe interactions and interactions can process formats.  Isn't the point of 
HATEOAS to push as much as possible of interaction description into the format? 
  Then, it seems to me, to exclude link relations from a role in describing 
interactions isn't helping.

I offer an alternative perspective on your "Why?"/"How?" separation:
- Link headers (and other protocol-level link relations) help an application to 
make a choice or selection from available resources to access
- Media types, along with an understanding of how to interpret the media content 
presented (including any vocabularies used, where applicable), tell an 
application how to interact with a resource.

Typed links (identified by link relation URIs) can appear in both, and may 
variously be used to guide selection and/or direct interactions.

What's missing, it seems, is a self-describing way to associate link relations 
with interactions.

#g

Received on Monday, 10 December 2012 17:34:50 UTC