Re: Links and graphs

On 10/12/2012 18:22, mike amundsen 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.

Well, I'm proposing that the link relation may also be.

(I'm referring here to application interactions, not browser.)

> <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?

I think so.  I was reacting against the (maybe incorrectly perceived on my part) 
idea that content type was the only basis for indicating the kind of interaction 
mechanism to follow.

Specifically, I'm thinking about choosing between a SPARQL endpoint and a REST 
service:  it seems to me that a link relation would be useful for making this 
distinction.  Eric's response seemed to me to indicate otherwise (but maybe I 
misunderstood).

> 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?

In the scenarios I envisage and am working with, using the link relation results 
in simpler client logic and code paths.

> <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?

This was a "get-out" clause to avoid tying the discussion specifically to HTTP. 
  Though in practice it's HTTP link headers I'm thinking of.

> <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?

It's difficult for me to say, but I'm thinking of client application 
interactions not directly involving a (human) user.  HTML is primarily about 
providing a presentation to a user, and the text surrounding a link can provide 
context for helping a user in deciding whether or not to follow a link.  That's 
not readily available to applications;  but I perceive that link relations can 
serve a similar purpose.

Cheers,

#g
--

> 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
> <mailto: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
>     <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
>     <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
>     <http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07893.html>
>     [3] http://lists.w3.org/Archives/__Public/public-ldp/2012Nov/__0024.html
>     <http://lists.w3.org/Archives/Public/public-ldp/2012Nov/0024.html>
>     [4] http://lists.w3.org/Archives/__Public/public-ldp/2012Nov/__0007.html
>     <http://lists.w3.org/Archives/Public/public-ldp/2012Nov/0007.html> (et seq.)
>     [5] http://tools.ietf.org/html/__rfc5988 <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 <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
>     <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
>     <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 Sunday, 16 December 2012 13:14:34 UTC