Re: Links and graphs

Hi all,

It seems to me that this conversation can benefit from a dose of pragmatism. We know, for example, that RDF Content-Types are not generally shipped by default in common Web server configuration files and many people (and organizations) use service providers to host Web content. Therefore we cannot presume that (individual or corporate) Web server providers can provide correct Content-Type headers *even if they are knowledgeable and wish to*. 

On the other hand, providers of Web content can and do often provide link tags to Linked Data within human-readable HTML pages.

The discussion at [1] provides a recent example at Manning, a publisher using Yahoo! Small Business Web Hosting services. 

Regards,
Dave

[1] http://lists.w3.org/Archives/Public/public-lod/2012Dec/0035.html


On Dec 10, 2012, at 13:22, mike amundsen <mamund@yahoo.com> wrote:

> Graham:
> 
> <snip>
> 1. It is overloading the notion of media type to have it be the sole determinant of interaction;
> </snip>
> "the sole determinant of interaction" intrigues me. tell me about some other "determinant[s] of interaction" that are/can be used in Web interactions.
> 
> <snip>
> 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
> </snip>
> "unsuitable as a dogmatic basis " - would it be suitable for a non-dogmatic basis? 
> As to "choosing format over link relation for driving an interaction", what are possible reasons to choose one *over* the other and is choosing just one required?
> 
> <snip>
> 3. Link relations appear in content as well as in link headers (and other protocol-level structures)
> </snip>
> what are the "other protocol-level structures" you refer to here?
> 
> <snip>
> 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.</snip>
> </snip>
> It would seem that HTML runs counter to your claim here. Am I missing something?
> 
> Cheers.
> 
> mamund
> +1.859.757.1449
> skype: mca.amundsen
> http://amundsen.com/blog/
> http://twitter.com/mamund
> https://github.com/mamund
> http://www.linkedin.com/in/mikeamundsen
> 
> 
> 
> On Mon, Dec 10, 2012 at 12:01 PM, Graham Klyne <GK@ninebynine.org> wrote:
>> 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
>