Re: Links and graphs

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