Re: Question about the On Linking Alternative Representations TAG Finding

Note that I did not assert that Resources and Representations are
the same --- I followed up saying that Resource Identifiers were
important for using as identifiers. 

Where I said "dont look too hard at the distinction" is in many
usages on the Web where the resource acts as an alias for the
most used representation. Phrased alternatively -- you said:

A) A resource is anything that has a URI
B) A representation is a tuple (bitstream, mimetype)

In Web usage you usually work with the triple 
(resource, bitstream, mimetype) --- and rarely with just the
(bitstream,mimetype) --

Richard Cyganiak writes:
 > Xiaoshu,
 > 
 > On 8 Aug 2008, at 10:11, Xiaoshu Wang wrote:
 > > The problem is there is no objective criteria that tells a  
 > > *resource* from *representation*.
 > 
 > A resource is anything named by a URI.
 > 
 > A representation is a <bitstream, MIME type> tuple.
 > 
 > That's a simple and objective distinction. The interesting and  
 > subjective question is how to best model an application using those  
 > two modelling primitives.
 > 
 > There are two schools of thought on this. One school maintains a  
 > distinction between “documents” and “things described in the  
 > documents” in their modelling; the other school says that this  
 > distinction is unnecessary.
 > 
 > The former modelling has been elevated to an axiom of Web architecture  
 > by the httpRange-14 decision. It has many advantages over the latter  
 > (cleaner handling of metadata, enables grouping of many descriptions  
 > in a single document, ...), and it has some disadvantages (more  
 > complex, ...). These have been discussed endlessly and I have no  
 > interest in resurrecting that debate.
 > 
 > > There are only two choices.  (1) As T.V Raman said, don't make any  
 > > distinction between them.
 > 
 > The distinction is made in the specs; and it's made by a large and  
 > significant part of the Web community (see REST). Raman might not  
 > consider it important, and that worries me a bit, but it doesn't  
 > diminish the importance of the distinction.
 > 
 > > (2) As I have always proposed, to make an absolute distinction.   
 > > That is: to think every URI denotes a *resource*
 > 
 > No one disagrees with this.
 > 
 > > and what is dereferenced from the URI is the *representation* of  
 > > that resource.
 > 
 > Not quite. A representation is what you get back when you do a GET on  
 > the resource, or what you send when you do a POST/PUT. Dereferencing  
 > is the process of “reaching through the network” in order to perform  
 > one of the supported operations on a 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.
 > 
 > What do you mean when you say “something is in a document”? I can  
 > understand the phrase “something is described in a document”.  
 > Obviously a document can describe itself. I don't see the contradiction.
 > 
 > [snip]
 > >>    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.
 > 
 > Those who use the approach described here simply make a modelling  
 > distinction between documents and the things described in the  
 > documents. That distinction *is* unambiguous. (But it is subjective.)  
 > The described approach is “clean” in the sense of HTTP interactions.  
 > And it is “clean” in that it enables the modelling style described  
 > above.
 > 
 > > 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.
 > 
 > That's why I keep insisting that you should use hash URIs, which do  
 > not exhibit this downside, instead of the 303 approach. The solutions  
 > mentioned above are for those who have decided to use 303s anyway,  
 > despite the well-known downsides.
 > 
 > Best,
 > Richard
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > >
 > >
 > > Xiaoshu
 > >

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

Received on Friday, 8 August 2008 15:03:22 UTC