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. 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?
That's the whole point of the httpRange-14 decision:
to advise the community to stay away from certain
sorts of pun.

> 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. 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.


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Thursday, 27 September 2007 16:58:18 UTC