W3C home > Mailing lists > Public > www-rdf-interest@w3.org > September 2004

RE: web proper names

From: Benjamin Nowack <bnowack@appmosphere.com>
Date: Tue, 21 Sep 2004 17:49:04 +0200
To: "Hamish Harvey" <david.harvey@bristol.ac.uk>
Cc: www-rdf-interest@w3.org
Message-ID: <PM-EH.20040921174904.94518.1.1D@192.168.27.2>


Hi Hamish,

sorry, no flames ;) just three comments:

On 21.09.2004 14:24:19, Hamish Harvey wrote:
>...
>It follows then that no software is allowed to treat a (URI qua symbol)
>as it appears in an RDF graph as anything other than a totally opaque
>symbol. It is *only* if it is explicitly specified that a URI (or bnode)
>indicates some specific retrievable resource that it is valid to go
>beyond the "inaccessible indicated thing" level of interpretation.
For the SemWeb architecture I also think it would make sense to have a
"built-in"/agreed-on/recommended mechanism to retrieve information about
the resource identified by a URI ref. Candidates include URIQA's MGET,
HTTP headers (e.g. Metadata-Location), conneg, redirects, etc., which
have all been discussed many many times on this list (and I hope we're
not going to re-start that thread ;). These proposals
have in common that they go a bit beyond the "total opacity" of a URI
ref and try to use HTTP to (M)GET additional information. But I 
absolutely agree on what you said concerning the level of 
interpretation of the URI. It's just an identifier.

>When a (URI qua symbol) is to indicate a non-retrievable resource, such
>as the Eiffel Tower, it is then possible to place an eg HTML document to
>be retrieved using that URI as a (URI qua retrival path), and it is
>precisely the fact that humans can do this in order to get a hint as to
>what a (URI qua symbol) is supposed to identify that leads to the
>argument that one should always use http URIs. This document is of value
>only to humans.
I'd disagree on that. The moment you put a dereferencable document at
that location, people might want to start talking about it, and we end
up with an ambiguous URI. So I'd say, whenever you want to use a URI
for a non-web resource, don't put a web resource at (exactly) the same
place. This doesn't mean that we can't provide information, but we have
to make sure (via URIQA, redirects & Co.) that we don't lose the URI's
disambiguity.

>If a (URI qua symbol) is to indicate a document which is retrieved using
>that URI as a (URI qua retrieval path), then it is *not possible* to
>also place a document there explaining to a human what the (URI qua
>symbol) indicates. It is then *necessary* if any human or software is to
>ground this symbol -- which grounding must be possible for the symbol to
>be useful -- to state explicitly, in RDF, that the (URI qua symbol)
>indicates what the (URI qua retrieval path) provides a path to (modulo
>content negotiation complications). So it seems that what people might
>regard as the "natural" case is the one that must be explicitly handled.
*If* we are going to have that agreed-on mechanism mentioned above (and
I still hope the SWBPD WG is going to address this issue), I guess it is
not neccessary to explicitly state that a resource identified by a URI
is dereferencable, as the way to get metadata about the resource would
be the same for web and non-web resources.

hm, makes sense?

benjamin

--
Benjamin Nowack

Kruppstr. 100
45145 Essen, Germany
http://www.appmosphere.com/
Received on Tuesday, 21 September 2004 15:49:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:09 GMT