Re: Question about the On Linking Alternative Representations TAG Finding

Richard Cyganiak wrote:
> There was a lot of fighting about the best way to assign those URIs in 
> a way that doesn't jeopardize the existing Web. In the end, some 
> influential people insisted on a rule that has become the axiom now 
> known as the “httpRange-14 decision”:
>    If a resource has a representation, then it is a document. If it 
> doesn't have a representation, it could be anything.
The problem is there is no objective criteria that tells a *resource* 
from *representation*.  There are only two choices.  (1) As T.V Raman 
said, don't make any distinction between them.  (2) As I have always 
proposed, to make an absolute distinction.  That is: to think every URI 
denotes a *resource* and what is dereferenced from the URI is the 
*representation* of that resource. 

To think whether something is *in* a document or not is just a form of 
self-contradiction because the goal is to make the web 
*self-descriptive*.  Hence, a document (or resource) is both in and not 
in itself.
> From this axiom comes the requirement to have URIs that do not resolve 
> to representations. In traditional, WWW-style Web architecture, that 
> would be a weird idea; it's all about exchanging representations. But 
> RDF people want it.
> So, we proposed two approaches to fulfill this requirement: the 
> practice of using hash URIs (if </foaf.rdf> talks about a person, then 
> that person could have the URI </foaf.rdf#me>); and 303 redirects (if 
> </about/Berlin> is a document that talks about a city, then that city 
> could have the URI </resource/Berlin> and 303-redirect to the document).
> Let's ignore the hash URIs for a moment. The key to the 303 approach 
> is this: It allows us to have resources that does not have a 
> representation, but still continue the HTTP conversation to get to a 
> document that describes the resource. So the idea is:
>     some_resource
>        |
>        +--303--> description_of_some_resource
> Now, <description_of_some_resource> could be just an RDF document; as 
> you see, in its basic form, the 303 approach doesn't involve any 
> content negotiation or different formats.
> But then, <description_of_some_resource> is a perfectly normal Web 
> document, and as such it can be available in different formats, 
> languages, and so on. A fairly common scenario is to have an HTML 
> variant for Web browsers and an RDF variant for data browsers. If we 
> follow the advice from Raman's TAG Finding, we would simply make 
> <description_of_some_resource> a generic resource; and the two 
> variants might be called <description_of_some_resource.rdf> and 
> <description_of_some_resource.html>. If <description_of_some_resource> 
> is requested, the appropriate variant is 200-returned to the client:
>     some_resource
>        |
>        +--303--> description_of_some_resource
>                     |
>                     +--Content-Location--> 
> description_of_some_resource.{html|rdf}
> That's the clean and proper way of combining the 303 approach with 
> content negotiation!
It is *clean* only when the distinction of *resource* vs. 
*representation/description* is unambiguous, which hardly is.  In either 
case, i.e., the (1) and (2) solution mentioned above, 303 is 
unnecessary.  Sure, it does no harm.  But it does slow down the web and 
our goal should be to make the web more efficient but less.


Received on Friday, 8 August 2008 09:12:14 UTC