- From: Xiaoshu Wang <wangxiao@musc.edu>
- Date: Fri, 08 Aug 2008 10:11:20 +0100
- To: Richard Cyganiak <richard@cyganiak.de>
- CC: Sebastien Lambla <seb@serialseb.com>, "T.V Raman" <raman@google.com>, john.kemp@nokia.com, www-tag@w3.org, kidehen@openlinksw.com, tthibodeau@openlinksw.com
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. Xiaoshu
Received on Friday, 8 August 2008 09:12:14 UTC