- From: Xiaoshu Wang <wangxiao@musc.edu>
- Date: Sat, 12 Apr 2008 00:57:47 +0100
- To: Pat Hayes <phayes@ihmc.us>
- 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>
Pat Hayes wrote: > 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.) The definition of /representation/ is very precise and clear. It is whatever the stuff (within the web, it is a byte-stream) that eventually reaches to the client. I think you perhaps have though it as something-else? Is this the case, because otherwise I cannot follow your answer. > >> (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 23:58:37 UTC