- From: mike amundsen <mamund@yahoo.com>
- Date: Sun, 16 Dec 2012 12:21:04 -0500
- To: Graham Klyne <graham.klyne@zoo.ox.ac.uk>
- Cc: Erik Wilde <dret@berkeley.edu>, LDP <public-ldp@w3.org>, W3C provenance WG <public-prov-wg@w3.org>
- Message-ID: <CAPW_8m4WD31yQ0-RDHdHt+7saAGFfv8UgVHn9x4+TfgVXFyf=g@mail.gmail.com>
<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>
are you planning on using link relation values to "identify" state
transitions (<link href="..." rel="users" />)?
or are you planning on using link relation values to "describe" state
transitions (<link href="..." rel="add-new-user" />)?
<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).
</snip>
by "content type" i guess you mean "media type", right?
show me how you would express this choice between SPARQL endpoint and REST
service in a message in a way a machine could operate on it - make a choice
- successfully.
<snip>
> 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>
I'm not yet seeing how one is "simpler client logic" over the other. Are
you suggesting machines must either make a choice either based on
selecting media type?
<link href="..." rel="customers" type="app/atom+xml" />
<link href="..." rel="customers" type="app/rdf+xml" />
or a choice based on link relations?
<link href="..." rel="rest-customers" />
<link href="..." rel="sparql-cutomrrs" />
<snip>
> . 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>
what other protocols are you considering right now?
<snip>
> <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.
</snip>
yes, if you are focused on M2M, link rel values are much more succint in
expressing options than wide-open text. but this is not a problem unique to
HTML. in fact, HTML is one of the few hypermedia types that already has
support for link relation values built-in to the defintion of the type.
Atom, HAL, Siren, and Collection+JSON all come to mind, too.
FWIW, I often use HTML for M2M work. HTML is a very compact and forgiving
format. I have a small set of hypermedia controls (link, img, a,
form+input, frame) and canignore almost all the other control elements if i
wish (although i often rely on UL, and DL when doing M2M work). for added
robustness, i promise clients to only output valid XML from my servers,
too. the limit of GET and POST is a bummer, but acceptable in many cases.
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 Sun, Dec 16, 2012 at 6:07 AM, Graham Klyne <graham.klyne@zoo.ox.ac.uk>wrote:
> 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<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>
>>
>> <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>
>>
>> <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>
>> <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>
>> <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>
>> <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><
>> 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><
>> 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>
>>
>> <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>
>>
>> <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 17:21:54 UTC