W3C home > Mailing lists > Public > www-tag@w3.org > September 2007

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

From: Booth, David (HP Software - Boston) <dbooth@hp.com>
Date: Tue, 25 Sep 2007 12:53:45 -0400
Message-ID: <EBBD956B8A9002479B0C9CE9FE14A6C2033877F5@tayexc19.americas.cpqcorp.net>
To: "Pat Hayes" <phayes@ihmc.us>, "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>

> From: Pat Hayes
> [ . . . ]
> OK, fair enough. But now, lets cut out all this 
> gabble about 'information resource'. 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.

I agree 100%.  I think the key question to ask is: *Why* is it
architecturally significant to distinguish between "information
resources" and non-"information resources"?  Why doesn't the Web
architecture distinguish between other interesting classes of things,
such as mammals and non-mammals?  

AFAICT the answer is that some things are HTTP endpoints (i.e., can
return a 200 response) and some are not, and this distinction is
relevant to the Web architecture because when something is an HTTP
endpoint a lot more architectural rules apply, such as content
negotiation, media types, etc.  AFAICT, whether something's "essential
characteristics can be conveyed in a message"[1] is quite irrelevant.

1. http://www.w3.org/TR/webarch/#def-information-resource


David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Opinions expressed herein are those of the author and do not represent
the official views of HP unless explicitly stated otherwise.
  
Received on Tuesday, 25 September 2007 16:54:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:18 UTC