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.

Well, but wait. Did they do this because they thought these WERE 
information resources or HTTP endpoints, or because (contra or pre- 
http-range-14) they thought it was fine to give a 200 code back from 
a URI denoting a non-information resource? I suspect the latter. I 
felt this way myself until quite recently (cf 
http://www.ihmc.us/users/phayes/PatHayes.html) and I still get the 
occasional referential quiver.

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

I think something got lost in the above. As I'd like to know what the 
appropriate thing to actually do is, can you elaborate a little about 
'tabulator code'? (OR a pointer?)

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

Yes, that is a tricky one. "Robot" is rather underdefined in any 
case. (I wonder why Im reminded of the interminable debates about 
whether robots can really think or not...)

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

Well, Im coming round to that. You might have noticed that Im not 
attacking the decision any more, just the way it is worded.

>  and somewhat helpful if it lets TimBL's tabulator
>code interoperate with the FOAF/dublin-core parts of the
web.

I don't know anything about that tabulator code.

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

Sure seems better all round to use # where possible. I liked your
http://ex.thingie.whatever/foodle#it convention for #-referring to 
the thing itself. Though as 'it' is also a language tag, and since 
most of this philosophizing can be traced back to Germany, how about
http://ex.thingie.whatever/foodle#dingansich ?  (Joke, joke...)

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

Ive been suggesting otherwise recently.

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

No, that still stands. But I'd prefer to say that what makes 
something an 'information resource' is not how it can be 
xx:represented - which is a can of worms - but just that it is the 
kind of thing that emits 200 codes alongside bitstrings (which we can 
call 'representations' if you like, but its really not important what 
we call them, or what they are supposed to be representations OF). In 
other words, the notion of 'information resource' is defined 
architecturally/functionally rather than metaphysically ("essential 
nature" etc.) See
http://lists.w3.org/Archives/Public/www-tag/2007Sep/0197.html
Harry Halpin also recently expressed the point very well:
http://lists.w3.org/Archives/Public/www-tag/2007Sep/0193.html

So for example, consider

http://www.flickr.com/photos/pathayes/sets/72157600146829157/show/

which is a slide show. The information resource here is... what? The 
actual slide show? Or a linear series of images? Or maybe the source 
of the code which makes it run in the browser? We could go on arguing 
about this for ever, but it really doesn't matter a damn. Whatever it 
IS, it emits stuff which causes a slideshow to appear in your 
browser, without indirection, etc.. Isnt that all we need to say?

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 Friday, 28 September 2007 19:50:20 UTC