Re: Some TAG review of "Cool URIs for the Semantic Web"

>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