- From: Pat Hayes <phayes@ihmc.us>
- Date: Thu, 27 Sep 2007 15:13:20 -0500
- To: Dan Connolly <connolly@w3.org>
- Cc: Tim Berners-Lee <timbl@w3.org>, Technical Architecture Group WG <www-tag@w3.org>, Susie Stephens <susie.stephens@gmail.com>
>On Mon, 2007-09-24 at 18:05 -0500, Pat Hayes wrote: >[...] >> >Now you could continue this argument and say >> >that there are similarly two conflicting >> >theories about http://www.ihmc.us/users/phayes/PatHayes , one >> >that says it's a web page and one that says it's a person, but >> >for many purposes, there's no need to look at things that closely. >> >The TAG decision on httpRange-14 is that if you look at >> >things closely enough to get a 200 response, then it's an >> >information resource, and hence not a person. I continue to >> >think that's good advice, though I'm fully aware that it's >> >not the only coherent rational position to take. >> >> OK, fair enough. But now, lets cut out all this >> gabble about 'information resource'. > >I don't think anyone is particularly fond of >that term nor the definition, but... > >> As I have >> always suspected, this is ALL about HTTP codes. >> If you do a GET with a URI and you get a 200 >> response, then the URI is understood to denote >> the resource that sent you that response, a >> (REST-)representation of which you now have. >> Otherwise, you know nothing at all about that the >> URI denotes: it might denote anything. >> >> That is the entire content of the http-range-14 >> decision. It's not about "kinds of resource" >> (whatever the hell that can possibly mean) at >> all: it doesn't need the concept of an >> information- or non-information resource to be >> explained, or even for any kind of resource to be >> described, other than the kind that can emit http >> codes and the kind that can't. > >But crucially, the content of the httpRange-14 >decision is that people (among other things) >can't emit http 200 codes. That is simply a fact: http-range-14 doesn't need to legislate that. (Though I wonder... Couldn't we imagine an HTTP endpoint which consists of a human being looking at the incoming URI on a screen and keying in an HTTP response code? That is *possible*, surely (?) and then would that person be the HTTP endpoint? Perhaps not: perhaps it would be the thing he was typing on. I really don't know how to answer a question like this.) >You say as much later >in the very same message... > >> So why not just >> say this? Its clear, simple, accurate (AFAIKS), >> free of jargon, and avoids all this interminable >> discussion about how to recognize a >> non-information resource when you meet it in the >> street, and damn silly decisions to give a name >> to a dustbin category. We already have a name for >> the only category we need: they are HTTP >> endpoints. > >HTTP endpoints are disjoint with people, yes? Yes (though see above.) But that doesn't need to be legislated by the TAG, surely. >That's the whole point of the httpRange-14 decision: >to advise the community to stay away from certain >sorts of pun. No, it doesn't do that. It is a pun ONLY if we assume that the URI denotes what it accesses in the case of a 200 code response. THAT is NOT obvious, and needs to be said explicitly, which is what http-range-14 conspicuously fails to do as it is currently stated. (BTW, argument why its not obvious: its false when the URI accesses something that emits a 303 or a 400 code.) > > OK, I won't push the ambiguity point for the >> people/web-pages case any more. So as for people, >> we can reasonably assert that people aren't this >> kind of thing: a person can't be an http >> endpoint, so if you get a 200 code back then the >> URI doesn't denote a person. (Though I wonder... >> could we set up a Turing-test/Chinese-Room type >> thought experiment for http? Is there any way one >> could distinguish a human from a machine by >> sending them http? But lets not go there.) > >Well, where shall we go? > >Can a city be an HTTP endpoint? >How about a physical book? >a robot? >an integer? >a set of integers? >an RDF Class? >an RDF property? >an XML namespace? >a language (such as XML Schema)? > >Those are the practical questions that I see the community >working on. Surely most of these answers are blindingly obvious. Integer, set (of anything), class, property, namespace, language: all obviously, necessarily, not, as these aren't physical entities. City, book: not for the forseeable future, as these aren't computational entities (yet). Robot: maybe. Person suitably equipped with android technology attachments: maybe. Taxi with a webserver: maybe, though its probably got the real endpoint inside it somewhere. > I stipulate that "essential >characteristics can be conveyed in a message" is less >than wonderful, but I don't think changing "information >resource" to "HTTP endpoint" addresses the practical >questions, without some definition. Well, Im not entirely sure about HTTP endpoint either, because Im not savvy enough with the Web-architecture details to know if this is really appropriate: maybe its something just the other side of the http endpoint, if that latter is more like the server. But the key point is that the distinction has to do with whether it can be *accessed* by transfer protocols, rather than with the way it can be encoded or represented. The essential characteristics of a billboard can be conveyed in an image, but if the image has never been digitized then its not an information resource (yet). And why could there not be an information resource whose essential characteristics could NOT be conveyed in a message? Some kind of analog computer, perhaps, which delivers a digital answer when queried but always one that is merely an approximation to its real, analog value. Or, arguably (?) the view seen through a webcam, which is only approximately represented by the webcam's CCD. Perhaps in these cases we wouldn't want to regard the real analog value or the actual view as information resources; but I don't really see the point in basing anything on this kind of debate. Im happy to say that the view through a webcam is 'accessible' on the Web. Pat > > >-- >Dan Connolly, W3C http://www.w3.org/People/Connolly/ -- --------------------------------------------------------------------- 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 Thursday, 27 September 2007 20:13:37 UTC