- From: Erik Wilde <dret@berkeley.edu>
- Date: Mon, 10 Dec 2012 14:13:53 -0800
- To: Graham Klyne <GK@ninebynine.org>
- CC: LDP <public-ldp@w3.org>, W3C provenance WG <public-prov-wg@w3.org>
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