Re: Question about the On Linking Alternative Representations TAG Finding

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
>

Received on Friday, 8 August 2008 11:36:32 UTC