RFC 2396 URI-References: A Problem

Status

No official status. Just some thoughts. Revision history in CVS. See related writings.

RFC 2396

RFC 2396 (currently a draft standard internet protocol) defines several identification languages related to "Uniform Resource Identifiers (URI)". The subtitle is "Generic Syntax" but the text clearly defines characteristics of the mapping from URIs to the "resources" they identify and uses the word "semantics" in doing so.

First, look at the syntax:

      URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
      absoluteURI   = scheme ":" ( hier_part | opaque_part )
      relativeURI   = ( net_path | abs_path | rel_path ) [ "?" query ]

Note that URI-References (not URIs) best match the popular notion of a web address: something you can type into your web browser, or bookmark, or link to.

URI-Reference do not denote resources, they "denote the common usage of [URIs]", namely as a web address. More specifically, it is to retreive some data and process it according to its media-type [RFC2046] and an optional parameter, the "fragment identifier":

   The semantics of a fragment identifier is a property of the data
   resulting from a retrieval action, regardless of the type of URI used
   in the reference.  Therefore, the format and interpretation of
   fragment identifiers is dependent on the media type [RFC2046] of the
   retrieval result. 

   ...
   A fragment identifier is only meaningful when a URI reference is
   intended for retrieval and the result of that retrieval is a document
   for which the identified fragment is consistently defined.

I humbly suggest that the RDF community has been using strings conforming to the URI-Reference syntax but with different semantics. RDF does not mandate retreival of the URI portion of the identifier, and yet it does condider the the identifier "meaningful".

One way to resolve this contradiction is to require RDF identifier's URI-parts to always lead to documents with a media-type (text/rdf+xml perhaps) which has some helpful specification. But I think that would be wrong.

Rather, we should recognize that XML Namespaces present a different "common usage" of URIs than browsers. This usage, like URI-Referencing, overrides the semantics of the scheme (leveraging it with a compound function about authority). The danger is in using URI-Reference syntax with different semantics. Some XML application (like xsv) use a syntax like "{URI}name" which is in practice disjoint from URIs and URI-References and prevents this problem.

http://foo.com	is a web address
{http://foo.com}x	is an opaque name created by the entity which provides the browser experience at the web address
http://foo.com#x	according to RFC 2396: a web address, denoting an experience based on retreival
http://foo.com#x	according to RDF practice: an opaque logical constant term which is probably used in a document at the URI and which you should not use without appropriate indication of its denotation from browser experience provider. (That is, it's bad practice to make up URIs in other people's namespace.)

What this means is that can't "believe" what RFC 2396 says without risking unnecessary contradiction. Defining the right mime-type gets you a bit closer, but I don't think it closes the gap.

Sandro Hawke
$Date: 2001/03/23 19:17:21 $