Re: URIs quack like a duck

John Cowan wrote:

> RDF is only capable of making statements about things that are identified
> by a URI, and requires knowledge of that URI.  In other words, an RDF statement
> can't be about me unless I have a URI such as
> "mailto:jcowan@reutershealth.com" or "urn:x-us-ssi:135-50-censored".
>
> >  The name in that context, even within RDF, would be viewed as it is within the
> > namespace spec itself: as an uninterpreted string that merely serves to label
> > something unambiguously.
>
> RDF does not make statements about names, but about resources (which must have
> associated URIs).

OK.  Perhaps there's a way through the issue that's been
troubling me: in some
contexts (namespace spec, XPath as it should be and probably
will be fixed), the
literal treatment of namespaces names works and is
appropriate; in other contexts
(RDF at least) it's inappropriate because you're talking
about a resource, not just
the identifier of that resource.  How are the two kinds of
requirements to be
reconciled?

The two contexts where namespaces are best viewed as
uninterpreted character strings
are comparisons (attribute uniqueness in the namespace spec,
attribute matching test
in XPath) where retrieval is neither necessary nor useful. 
The question we're asking is, "Are these two namespaces the
same?". What "same" means has been the subject of much
discussion and little agreement here; but literal string
comparison is simple, appropriate, and well understood.

The other contexts involve retrieval, not comparison.  We
aren't asking if URI1 is
the same as URI2; we're asking what lies at the business end
of URI1.    As far as I
know, the specs that are concerned with comparison aren't
concerned with retrieval
and vice versa, except for contexts such as inclusion that
one can treat entirely
separately.

So URIs are like books, which can serve either as
information sources or as
paperweights.  Many books can serve as both, but a
lightweight book won't work as a
paperweight and a blank book won't work as an information
source.  You judge a book's
suitability for the purpose according to the context: are
you looking for knowledge
or for a paperweight?   In some contexts URIs serve as
meaningless unique strings; in
other contexts we attach meaning to them as identifiers of
resources.

> For a name (= character string) to be a resource, some
> convention must exist such as:
>
>         1) the resource is a data resource containing the name, or
>         2) the resource is whatever resource is identified by the name,
>                 treating the name as a URI reference.
>
> The advantage of the "data:," prefix trick is that it gives a resource for
> every name, while keeping the string-equality rule for equating names.

There's something here that boggles my mind.  What is the
difference between the
following namespace names:

     http://www.sushi.edu/octopi
    data:,http://www.sushi.edu/octopi
    data:,data,http://www.sushi.edu/octopi

if there's any kind of implicit dereferencing going on?  
It's kind of like the LISP expressions

      SUSHI
      (QUOTE SUSHI)
      (QUOTE(QUOTE SUSHI))

If we treat "data:," as a benediction that we place on URIs
to make them kosher for
use as namespace names and discourage the use of all others,
then the sets of
potential names in either case are equivalent.   The one
advantage of this approach
is the one that led to the title of this thread: "data:,"
URIs won't be mistaken for
a duck because they don't quack like a duck.

Paul Abrahams

Received on Friday, 2 June 2000 18:48:12 UTC