Re: Links and graphs

On 10/12/2012 21:07, David Wood wrote:
> 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.

I'm all for a dose pragmatism here (if it doesn't drive a coach and horses 
through architectural principles) - that's what's driving my engagement here.

With respect to your specific comment, I'm considering a scenario where there's 
no HTML involved: just pure application-to-application interactions.

#g
--

>
> 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
> <mailto: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
>> <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:17 UTC