Re: Resources and representations

Richard Cyganiak wrote:
> Alan,
> On 22 Oct 2007, at 22:22, Alan Ruttenberg wrote:
>> On Oct 22, 2007, at 12:53 PM, Richard Cyganiak wrote:
>>> The point is that it partitions resources into two kinds: 
>>> message-conveyable resources, and other resources. And it 
>>> establishes an axiom, that a 200 response means we have a 
>>> message-conveyable resource.
>> Yes, but we don't convey the resource. We only convey a 
>> representation. To rephrase what you have said, my interpretation is 
>> that a 200 response means that we have denoted a resource, 
>> representations of which can be conveyed. However, there is nothing 
>> that I see that would indicate that the message receiver is  supposed 
>> to be able to reconstitute the "resource" from the message that is 
>> received.
> A representation is thought to encapsulate the current state of the 
> resource, as presented by the URI owner, and thus communicates the 
> state to the receiver. Subject to some possible loss of fidelity, if 
> the URI owner choses to publish in lower-quality formats.
> (That's why REST is called REST -- REpresentational State Transfer.)
I think this is wrong.  When dereferencing a URI, such as, we capture the representation state of the 
machine located at "", but not the representation state of 
"".  In principle, I, the person, can be a proxy 
server sitting at "" and answer all the request.  Then, you 
are asking the representation state of "" in my 
brain.  This is where all the trouble starts.  If TAG no long wants the 
concept of URL, then there is nothing located at anywhere in the 
network.  "" might be the "birthplace" of 
"", but it is not the "home" of the resource.
> Note: If we can convey the current state of a resource, then by 
> definition the resource is conveyable. (Though we'd need the ability 
> of time travel to reconstitute it completely.)
>> In fact, I would say we'd be pretty lucky in many cases if we are 
>> able to infer what resource is being denoted,
> Finding out what is being identified just by GETting representations 
> is impossible, mostly because we can't look into the future. The only 
> way to find out what is being denoted is to interpret some statement 
> -- in logical or natural language -- made by the URI owner. (A very 
> good place for such a statement would be in a representation retrieved 
> from the URI.)
This is exactly the point - to find out from statement, but NOT from how 
the statement is returned! 303 should NOT mean a thing when the purpose 
is to interpret what the resource is.
> I have seen people in the wild assume it's OK to use homepage URIs to 
> identify homepages.
> I have seen people in the wild assume it's OK to use homepage URIs to 
> identify people.
But you just said in the above, what a URI denotes should be interpreted 
from statements. Why is it not O.K now?
> httpRange-14 removes a conflict between two reasonable yet 
> incompatible interpretations that do occur in the real world. I don't 
> care too much if it has funny side effects on possible interpretations 
> that my or your bored imagination can potentially dream up.
The truth is, it creates more conceptual difficulties and funny side 
> Just one thing on the side: In the real world, very few web page URIs 
> are subject to content negotiation.
A server does not offer a variant of a URI, does not means that URI does 
not have a variant.  Again, when dereference a URI with HTTP, you are 
not asking the resource for its representation, you are asking a machine 
for that. 
> You can denote a resource that is defined as "the resource having only 
> one particular representation, which has a checksum of 1234."
Sure, but where to get this information?  Say if the resource is located 
at "", so someone passes me this URI, how do I 
know there is only this one particular representation?  You can say that 
if you get a representation with a checksum of 1234, then you get the 
right representation.  But you cannot say that the 
"" has a checksum.
> You mint a URI and declare it to identify "the resource that has only 
> one single fixed representation XYZ".
Where do you want to put the declaration? Packed under same URI with 
content negotiation? Or split it with 303?  Then, what if people is only 
given the split URI, they will not know the assertion.  To cater this 
possibility, you need to 303 split again, and again, .... it is a trap 
that never ends.  I hope we can stop it, once for all, just say no to 303!


Received on Tuesday, 23 October 2007 10:07:51 UTC