- From: Pat Hayes <phayes@ihmc.us>
- Date: Wed, 15 Jul 2009 09:24:06 -0500
- To: Xiaoshu Wang <xiao@renci.org>
- Cc: Richard Cyganiak <richard@cyganiak.de>, "Roy T. Fielding" <fielding@gbiv.com>, Jonathan Rees <jar@creativecommons.org>, Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>, www-tag@w3.org
On Jul 14, 2009, at 10:20 AM, Xiaoshu Wang wrote: > Pat Hayes wrote: >> >> On Jul 14, 2009, at 9:01 AM, Xiaoshu Wang wrote: >> >>> Pat Hayes wrote: >>> >>> <snip> >>>>> on these two counts, you end up ranting against a POV that I do >>>>> not hold. >>>>> >>>>> I especially continue to maintain that any talk about denotation >>>>> is out of place on the HTTP protocol level. There is no such >>>>> thing as denotation in the universe of the Hypertext Transfer >>>>> Protocol. Yes, people obviously use HTTP URIs to denote all >>>>> sorts of things, and a lot can be said about how one should >>>>> model resources and representations based on the things one >>>>> wants to denote, and what one can or cannot infer about the >>>>> denotation of a URI based on HTTP interactions, but none of this >>>>> matters one bit for the actual operations of the protocol. >>>> >>>> Seems to me that this may have been true before http-range-14, >>>> but it is not a stance that can possibly be maintained in the >>>> face of that decision. And your final sentence above is, surely >>>> you can yourself see, tendentious. If the HTTP 'layer' really >>>> were completely unconcerned with denotation, how could one >>>> *possibly* infer anything about what a URI denotes from >>>> *anything* about HTTP interactions? >>> The assumption here is that httpRange-14 is the right direction. >>> But that is a big *if*. If anything, this debate only shows how >>> *bad* that this whole idea of httpRange-14 and information >>> resource thing is. >> >> As I said in another post, I think http-range-14 is terrible, but >> all the alternatives are worse. > Of course there is no better alternative because there is *not* a > problem at the first place. The problem is created by pushing IR > into the Web architecture. But just like the web architecture > should not deal with hamburgers, it should not deal with IR as well. > >>>>> The protocol is just about pushing representations around. >>>> >>>> Well, I would be delighted if this were true. But then the HTTP >>>> specs should not claim or even hint at the idea that URIs can >>>> "identify" non-computational things, or that such things can have >>>> "representations" in its specialized sense. (It would be very >>>> good manners, in fact, to clarify just what that highly >>>> specialized sense of "representation" is, and state explicitly >>>> that it is not intended to cover any wider sense of >>>> representation, for example the sense in which it it used in such >>>> phrases as "knowledge representation".) And you should be quite >>>> open and clear about the fact that this view of HTTP is not >>>> compatible with the http-range-14 decision. >>> The HTTP protocol should be about pushing representation around. >>> And it shouldn't careless about if its URI denotes or identifies >>> anything. The latter is up to the one who implements that >>> particular URI. Let's not ignore the existence of such entities >>> because it is those who expressed their denotation semantics. >>> >>> Also, let's us not play linguistic tricks. If the owner of "http://example.com/a.hamburger >>> " makes it to denote a hamburger. Then HTTP-GET "http://example.com/a.hamburger >>> " means "get me an awww:representation" of the hamburger. But it >>> does NOT mean the "get" like in "get me that hamburger" as what we >>> would say in front of a grill. >> >> Of course not. But it also does not mean, "get me an >> awww:representation" of the hamburger. Or at least, it had better >> not mean that, since hamburgers don't have awww:representations. >> Web pages about hamburgers can represent (not awww:represent) a >> hamburger, and they of course have awww:representations. But an >> awww:repreresentation of a representation of X is not an >> awww:representation of X. > I mentioned that let us not ignore *the existence of an agent* -- > the one who implements the URI. I do not know if a hamburger *can > or cannot* have an awww:representation because I am not a > hamburger. But I do know that *I can* give a hamburger an > awww:representation. You don't have to believe me, that is none of > my business. True, I don't have to, but I would like to know a little more about HOW you would create an awww:representation - or, which I believe to be synonymous, a representation in the sense used in Roy's REST thesis - of a hamburger. I will take mine without tomatoes, well done and dressed with mayo and mustard. So, to check our understanding, this must be a representation, encoded in a byte stream, which stands in the same relation to a hamburger that the html which I get back from, say, the Amazon website stands in to that web page. Maybe we should take this offline if it is annoying others, but I actually think it might be quite informative about our various clashing intuitions here. Pat > But to say that no one should believe me, you cross the line for > being either ignorant (of being me) or arrogant (of being you). >>> To think otherwise is to hallucinate. >> >> Quite. >> >>> >>> httpRange-14 was at first designed to prevent people from episodes >>> of this kind of hallucination. But at the end, it ends up with >>> its own one -- the hallucination of the information resource. >> >> I don't like the terminology (and I don't think we need it, and >> especially do not need to be debating its exact meaning), but the >> general idea is clear enough: its the thing that HTTP returns the >> awww:representation of. That is certainly not a hallucination, >> because you just made HTTP contact with it. > Then, it is fine with me. You can call an HTTP server, FTP server, > Mailto server or any kind of information server -- an "information > resource". That is denotation semantics of that word's use. It is > fine with me because we might just call it "xyz" -- for the sake of > avoiding confusion. But this denotation semantics should not affect > how *I* implement *my* URI. Most of all, it should not affect how > *I* use the Web. > > Xiaoshu > > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Wednesday, 15 July 2009 14:25:43 UTC