Re: Generic-Resources-53: URIs for representations

>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. 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. 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.

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.

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:19:01 UTC