W3C home > Mailing lists > Public > www-tag@w3.org > October 2006

Re: Generic-Resources-53: URIs for representations

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Mon, 9 Oct 2006 11:39:47 -0500
Message-Id: <B02D76BC-1F22-478C-BE49-1EEBD2F6C594@nokia.com>
Cc: noah_mendelsohn@us.ibm.com, "Dan Connolly" <connolly@w3.org>, "ext Booth, David (HP Software - Boston)" <dbooth@hp.com>, raman@google.com, "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, www-tag@w3.org
To: ext Pat Hayes <phayes@ihmc.us>


On Oct 9, 2006, at 11:18, ext Pat Hayes wrote:

>> Patrick Stickler writes:
>>
>>>  (b) if is known (by extra-web means) that a given URI denotes a
>>>  representation, then the agent is licensed to expect that every  
>>> time
>>>  it dereferences that URI it will get the same exact byte sequence
>>
>> Yes, if you really mean "that" representation, but I think we're  
>> glossing
>> over an ambiguity.
>>
>> Consider one of my favorite examples, which is a clock resource.  The
>> clock updates in real time, and representations of it change  
>> accordingly.
>> For this example, assume that the clock resource at
>> http://example.org/clock supports content negotiation.  It returns  
>> the
>> representation of the clock as your choice of text/plain, in which  
>> case
>> you get back the date and time as text, or image/jpeg, in which  
>> case you
>> get the image of a round analog clock showing the current time.
>>
>> Your analysis seems to apply to the case where we want a URI for the
>> particular resource returned at, say 3PM, and I think your  
>> analysis is
>> coherent for that case.  I don't think it's the main case of  
>> interest.
>> What I think we're mostly considering is more along the lines of two
>> additional resources which might be named:
>>
>>         http://example.org/clock?rep=text
>>         http://example.org/clock?rep=image
>>
>> These would not in fact return the same representation on successive
>> accesses, but would invariably return representations using the  
>> particular
>> media types.  I also think this is an appropriate use of URIs for
>> representations.  So, I don't think that in all useful cases "URI  
>> denotes
>> representation" implies "denoted representation octet stream is
>> invariant".  I think the two URIs above denote representations of the
>> original clock resource if the authority at example.org says they do.
>>
>> Also, I think I'm right that the term "representation" is  
>> appropriately
>> applied not just to the octet sequence returned, but to some of the
>> associated control data such as Content-type that's typically  
>> carried in
>> some of the returned HTTP headers.
>
> While all the examples in the above make sense, this discussion  
> makes me even more worried than I already was about what exactly  
> the word "representation" is supposed to mean.
>
> I have been assuming that when the TAG use this word, what they  
> mean is that a representation of a resource is a particular chunk  
> of information emitted by the resource, usually in response to a  
> GET request, which is thought of as an encoding of the state of the  
> resource at the instant the GET was processed. Or, put more  
> mathematically, the resource *is* a function from times (of  
> processing GET requests) to representations. Either way, these  
> representations are things that can be sent over optic fiber.
>
> Applied to the clock example, this suggests that the clock is a  
> resource, and so are the non-negotiating versions of it, and that  
> *none* of these are representations, but that they all emit  
> representations when GOT.

Right. That's also my understanding. The representation is just that  
octet stream
that the server returns. A web client can never "touch" a resource,  
only a
representation.

Even when the request URI denotes a particular representation (octet  
stream)
the client never actually gets back that resource, just a replication  
of it.

I.e. the representation of a representation is a bit-equal copy of  
itself.

> If the authority at example.org says that one of its clocks is a  
> representation of another clock, then it wrong, and appears to be  
> confused about what "representation" means, since a clock can't  
> possibly be a representation, by definition.

Right. At least as far as web Representations are concerned (I've  
tried to
capitalize Representation whenever talking about the class of atomic
elements of the web, i.e. octet streams returned by a server in response
to a GET request). There are of course other kinds of "representations"
which are not members of that class of resource.


> But a jpg image of the clockface at 3pm, archived with the URI
> http://example.org/clock/1500/image
> might be said, speaking slightly loosely, to be a representation of  
> the clock, one that has its own representations which are merely  
> copies of it.

Yes. One could look at it that way.

Though it's probably best to always maintain the view that even when the
resource in question is a data object encoded consistently as an
octet stream and its natural representation is a perfect replication
of that octet stream, what is being returned by the server is still
just a representation and not the resource itself.


>
> I note in passing that this entire discussion uses "representation"  
> differently from the way that this word is used almost everywhere  
> else, but that isn't directly relevant to the current thread.

;-)

Patrick

>
> Pat Hayes
>
>> Noah
>>
>> --------------------------------------
>> Noah Mendelsohn
>> IBM Corporation
>> One Rogers Street
>> Cambridge, MA 02142
>> 1-617-693-4036
>> --------------------------------------
>
>
> -- 
> ---------------------------------------------------------------------
> IHMC		(850)434 8903 or (650)494 3973   home
> 40 South Alcaniz St.	(850)202 4416   office
> Pensacola			(850)202 4440   fax
> FL 32502			(850)291 0667    cell
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
Received on Monday, 9 October 2006 16:40:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:42 GMT