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

On Thu, 2007-09-27 at 15:13 -0500, Pat Hayes wrote:
[...]
> >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.

The long history of the httpRange-14 issue suggests the
answers are anything _but_ obvious.

>  Integer, set (of 
> anything), class, property, namespace, language: all obviously, 
> necessarily, not, as these aren't physical entities.

That wasn't obvious to the dublin core nor FOAF designers;
they chose hash-less http URIs for dc:title and foaf:name and such,
and they used to give 200 responses to GET requests there for years,
despite TimBL's protests. They're migrating to 303 redirections
since the httpRange-14 decision, I gather; and TimBL is now
recommending that people make FOAF files and the his tabulator
code is reasonably happy about dc:title and such.

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

The one thing that's clear from the webarch definition of
information resource is that physical entities do _not_
have webarch:representations .

Robot is a case that Tim Berners-Lee and Roy Fielding took opposite
sides on for quite some time. Roy is officially party to the
decision that robots are not information resources and can't
be represented by HTTP 200 responses, but I'm not sure he's
really convinced. I gather Noah feels similarly to Roy.

I think Roy and Noah see the httpRange-14 decision as mostly
harmless, and somewhat helpful if it lets TimBL's tabulator
code interoperate with the FOAF/dublin-core parts of the
web.

That's why working out this tutorial in collaboration
with projects like dbpedia seems important, to me: the
scale of the data set is large enough to be very, very useful
and widely imitated, but there's some room to experiment with
the details of how it's deployed. I'm pleased to see Kingsley
and company experimenting with the doc#term approach after seeing
some pain around the 303 redirect approach.


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

Hmm... it's news to me that this is the key distinction;
I thought the key distinction was very much about what
sorts of things can be webarch:represented.

Your message of Wed, 5 Sep 2007 13:48:30 -0500 seemed
to use the "what can be have a representation" distinction.
http://lists.w3.org/Archives/Public/www-tag/2007Sep/0017.html

Do you no longer think that train of thought is useful?

[...]

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

Received on Friday, 28 September 2007 18:51:28 UTC