Re: Links and graphs

hello graham.

i am afraid i can do little here other than pointing to mike and say 
"just what he said".

> 1. It is overloading the notion of media type to have it be the sole
> determinant of interaction;

media types determine the conversation you're engaging in on the web. i 
really don't know anything else, so like mike said, if you think we 
should put it somewhere else, i'd be curious to know where that would be.

> 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

"not clear cut" and "unsuitable as a basis" are very different things. 
again, the interesting here are media types. a link relation is 
something you find in the context of one conversation, and if you choose 
to follow it, you're doing it because you want to accomplish some goal. 
if accessing the link results in you now using a different media type, 
then you've just switched conversational contexts, and for starting a 
conversation in that new context it shouldn't matter how you got there. 
so distinguishing link relations and subsequent interactions with the 
link target is a very useful thing, because it allows us to evolve 
conversations and add new pieces into the conversations, without having 
to change anything about the existing machinery.

> 3. Link relations appear in content as well as in link headers (and
> other protocol-level structures)

that's correct. it's up to media type to choose how to manage that, so 
that clients can engage in meaningful conversations. HTML never uses 
link headers. HTTP services serving blobs may critically depend on using 
link headers. a future hyperRDF will have the freedom to choose how it 
expects clients to engage in conversations. for now, since RDF has no 
links, it doesn't really matter.

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

that very much depends on you scenario. it can be pretty much 
impractical for pretty much every hypermedia document format i know of, 
and it can be really nice to avoid the madness that is adobe's strategy 
of placing metadata in 37 different places in a PDF.

> This all leads me to to see plenty of upside and no downside in liberal
> use of link relations to guide interactions.

100% agreed, but i don't think we ever disagreed on that one.

> I also think we lack a common or self-describing way for link relations
> to guide interactions.

- common way: RFC 5988
- self-describing way: without knowing the media type, you don't know 
its rules.

cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

Received on Monday, 10 December 2012 22:14:21 UTC