Re: "On the Web" vs "On the Semantic Web" (was Re: resources and URIs)

> Sandro Hawke wrote:
> 
> > All I'm saying is: when it comes to building the Semantic Web, it
> > seems useful to know or be able to find out easily which URIs denote
> > response points.  For the others it's nice to be able to find an
> > associated response point which is in some sense authoritative.
> 
> Whether or not a URI identifies a response point is something that 
> varies temporally and perhaps along other axes; the basic Web 
> architecture just has to be able to deal with this fact, so we can't 
> write that distinction into webarch.  Put another way, the Web has no 
> way to know whether or not a URI is intended to be a response point; all 
> it can do is (assuming the scheme defines retrieval protocols) is ask 
> for a representation and get one (or not).

I was thinking more about observable behavior than intent.  If you get
back a representation (with a "200 OK" response, or the corresponding
signal in non-HTTP protocols) then clearly you're dealing with a
response point.  If you have an HTTP URI-Reference, then it MAY denote
a response point, but you can't use RFC 2616 to figure out that it
does and how to talk to it.  

My glimmer of hope in all this is "303 See Other" redirects.  It seems
reasonable to say that if you get a 303 response during a dereference
attempt then the URI *does*not*denote*a*response*point*.   This gives
us a coherent universe of response points and other things (like
chairs), without resorting to using hash marks.   

For anyone about to send me an argument that one can denote a chair
with an HTTP URI from which one can obtain "200 OK" respresentation of
the chair, ... please be sure to explain how my user agent is supposed
to store data about the transaction in which it obtained that
respresentation.  Specifically, I want triples giving dc:creator
information (or some suitable replacement predicate) about the chair
and about the RDF/XML data about the chair which I obtained as a
respresentation.

I mean, the basic problem here is that we want to give names to lots
of things, we want those names to be attached to information
providers, and we also want to be able to give names to information
providers.  If we had a compound syntax like (providername, localname)
for our names-for-lots-of-things, we'd be fine.  But we don't.  We
have URIs and URI-References, and certain backward-compatibility
requirements (or desires, at least).  TimBL likes using
providername#localname because that's roughly backward compatible and
roughly works.  I moonlight as an apologist for folks like Dublin
Core, FOAF, RSS, and CreativeCommons who don't use hash marks in their
RDF URIs, so I come up with things like 303-See-Other as a way out.

     -- sandro

Received on Thursday, 17 July 2003 17:02:06 UTC