W3C home > Mailing lists > Public > www-tag@w3.org > October 2004

RE: referendum on httpRange-14 (was RE: "information resource")

From: Bullard, Claude L (Len) <len.bullard@intergraph.com>
Date: Wed, 27 Oct 2004 08:49:18 -0500
Message-ID: <15725CF6AFE2F34DB8A5B4770B7334EE07206891@hq1.pcmail.ingr.com>
To: "'Patrick.Stickler@nokia.com'" <Patrick.Stickler@nokia.com>
Cc: www-tag@w3.org

I'm not sure it's useful either.  It's just that when one 
factors the definitions, URIs are the only solid bits.  
Everything else is 'turtles all the way up'. 

That means the web isn't an information space.  
It's a name space of opaque identities.


From: Patrick.Stickler@nokia.com [mailto:Patrick.Stickler@nokia.com]

It's an odd thing to do, but I don't see why you can't have e.g.

   <http://example.com/blargh> owl:sameAs
"http://example.com/foo"^^xsd:anyURI .

Thus, <http://example.com/blargh> identifies the specific
URI "http://example.com.foo". Note that the above statement is not
the same as

   <http://example.com/blargh> owl:sameAs <http://example.com/foo> .

I.e. in the first case, <http://example.com/blargh> is identifying the
URI, the string conforming to the lexical constraints for URIs, and
is not (necessarily) identifying what the URI "http://example.com/foo"
itself identifies.


How having one URI identify another URI would be useful is unclear to me.

But in principle, a URI is a thing, and if a URI can identify anything,
then one URI can certainly identify another URI.

And having an RDF description of <http://example.com/blargh> available
allows one to clarify that it identifies a URI, which is quite clear
from the first RDF statement above.


> From: ext Bullard, Claude L (Len) [mailto:len.bullard@intergraph.com]
> Sent: 26 October, 2004 22:49 
> A mad thought:  if URIs identify resources (not representations), 
> and resources are abstract, do URIs only (put verb here) 
> other URIs?
Received on Wednesday, 27 October 2004 13:49:50 UTC

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