W3C home > Mailing lists > Public > www-tag@w3.org > April 2008

Re: Uniform access to descriptions

From: Pat Hayes <phayes@ihmc.us>
Date: Fri, 11 Apr 2008 13:57:22 -0500
Message-Id: <p06230905c42528c0f89c@[192.168.1.2]>
To: wangxiao@musc.edu
Cc: noah_mendelsohn@us.ibm.com, Jonathan Rees <jar@creativecommons.org>, Phil Archer <parcher@icra.org>, "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, "www-tag@w3.org WG" <www-tag@w3.org>
At 2:26 PM +0100 4/11/08, Xiaoshu Wang wrote:
>noah_mendelsohn@us.ibm.com wrote:
>>Xiaoshu Wang writes:
>>
>>
>>>HTTP protocol is a transportation protocol.
>>>Hence, the semantics of HTTP should be ALL about delivering 
>>>message and its parsing and it should have nothing to do with 
>>>judging its content.
>>
>>Hmm.  I would have said that HTTP is an application-level protocol. 
>>Otherwise, why distinguish PUT from POST or DELETE?  What they 
>>transport isn't much different, except that with delete there is 
>>seldom need for much information beyond the identifier of the 
>>resource.  If it were just a transportation protocol, then all we 
>>would need is well typed messages, and we could encode operations 
>>in those messages if we wished to.  I'm not sure I'd use your 
>>phrase "judging its content", but HTTP operations are applied to 
>>Web resources, and the status codes properly reflect information 
>>about that interaction.  The fact that certain operations cannot be 
>>successfully performed on certain classes of resources, and that 
>>the status codes therefore (if properly used) allow one at times to 
>>infer information about the nature of the resources, all seem fine 
>>to me.  If we were talking about TCP, I would for the most part 
>>agree with you.
>>
>I think this is the essential issue of all argument is.

I agree.

>  As Stuart warned me not to loop the concepts again and again. 
>Let's reformulate the argument into a multiple choice question.
>
>Question 1: Is there a difference between Representation and Resource?

Um... it depends what you mean. They are different concepts 
(categories, classes, properties), to be sure, since there are may 
resources that aren't representations (and IMO - though others may 
differ - there are also representations which aren't resources). But 
they need not be exclusive: something can be both a representation 
and a resource. In fact, it is exactly these cases which seem to give 
us the most trouble in this exchange. For example, a home page is a 
resource but it might also be reasonably called a representation of 
the person it describes. (I'm assuming here that 'representation' is 
being used in a broad sense, not as awww:representation.)

>(1a): Yes.  Representation -> Resource; (here let's name "->" as identify).

If we are using 'identify' in the TAG sense, then its usually URI's 
that are at the blunt end of the arrow, not representations. But 
perhaps you are using the word in a different sense, something more 
like 'represents' (?) In which case, I agree, a representation 
represents a resource.

>(1b): No.  Representation = Resource.

Well, a representation of resource A can itself be a resource, though 
maybe it can't be A itself. (Can we have a self-representing 
representation? There's no formal reason why not, eg an RDF plain 
literal could be described this way. On the other hand, some 
semiologists - notably Umberto Eco - insist that this is impossible. 
Interesting, if arcane, debate.)

>
>Question 2: Can one resource has multiple Representation?

Yes.

>(2a) Yes.  So Representation -> Resource but Representation != Resource.

See above.

>(2b) No.  (Then explain or drop Conneg)
>
>Question 3: What does a URI denote?

A thing. Or, if you prefer the older terminology, a resource.

>(3a): Resource.
>(3b): Representation
>(3c): Both.

I'd have to say both, since the categories aren't exclusive.

>
>Question 4: Is an HTTP-URI =  HTTP+URI?

I have no idea what this means.

>(4a): No.  (Hence, HTTP-URI = Resource, HTTP+URI = Representation.)
>(4b): Yes.
>
>My answer is all (a), which is consistent and without any ambiguity. 
>If someone propose any model other than (a), then find a model to 
>make them all consistent.  It is their burden to model it 
>consistently, not mime.

Well, here's my, er, model.

URIs are names, which denote things.

URIs also indicate resources, usually via http: that is, the URI when 
'bound to' the Web with a GET starts up a process which returns 
something via a byte stream. The thing which does the returning is 
called a 'resource' and the thing returned is called the 
awww:'representation' of that resource.

There are also representations (of various kinds, but not 
awww:representations) which represent (describe, picture, ...) the 
thing(s) they are representations of. One kind of representation is a 
formal description (typically an RDF graph) which uses URIs as names 
to refer to whatever they denote. Some resources are representations 
in this sense (not in the awww sense.)

All of the following are things which can be named by URIs: 
resources, descriptions, RDF graphs.

The content of http-range-14 can be summarized: when a URI indicates 
a resource, then it should be also understood to also denote that 
resource. The importance of the 200 code is then simply to indicate 
that it was indeed the first supplied URI in the http transaction 
that did the indicating of whatever produces the final result (and 
not, for example, some other URI it redirected to.)

Make sense?

Pat

>
>All other questions, such as what is the meaning of "description" 
>should be answered based on the answers of the above four questions. 
>I think they summarize different attitudes toward the architecture 
>of the web.
>
>Xiaoshu
>
>Let's settle this first and then with some terminology.
>
>Xiaoshu


-- 
---------------------------------------------------------------------
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
http://www.ihmc.us/users/phayes      phayesAT-SIGNihmc.us
http://www.flickr.com/pathayes/collections
Received on Friday, 11 April 2008 18:58:18 GMT

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