Dereferencability was: URIs as namespaces

-----Original Message-----
From: Paul Prescod <paul@prescod.net>
To: xml-uri@w3.org <xml-uri@w3.org>
Date: Monday, May 15, 2000 4:57 PM
Subject: URIs as namespaces


>Something which has always seemed obvious to me is that it should be
>intrinsically obvious on the "client side" whether a name refers to
>something which can be explicitly retrieved or whether it rather refers
>to something imaginary that has no internal representation in a
>computer.

To a certian extent this is true, in that the differet URI schemes have some
fundamentally different overal properties. So for example, if a namespace
were identified using a uuid: then the expectation would be that there would
be no global lookup service but tere might be a local broker on the
computer.

Using http: does indeed indicate there is a way that you can ask the holder
of the name (the DNS owner) but there is no expectatoin that you will
find aything - you might not even find a server serving that DNS space.
Names in the http space have properties largely define by their owners,
and so you have to have an agrement with the publisher before you
assume anything.  For example, W3C has an internal policy that any
namespace name mentoined in a technical report will have a corresponding
doument pointing to that report, if not more machine-readable information.
We also have a persistence policy about publications especially those in
our dated URI space (http://www.w3.org/2000/ etc)


> This becomes obvious in a variety of contexts:
>
> * students in any XML class ask about whether you must be connected to
>the Internet when you use namespaces -- no matter how many times you
>tell them no, they do not believe you because it is so non-intuitive.


You will have to exaplain to them then again :)  If they have only seen URIs
used
in HTML links then maybe they do have this model of what they are. But URIs
are much more than that.  That said, your students will probably apreciate
W3C's
policy of allowing you to follow up on W3C namespace names in http: space,
for the purposes of their study.

> * email clients automatically "highlight" namespaces because they have
>the same syntax as URL-retrievable information


What? A namespace name normally is defined by an attribute in XML so it
would
only show up normally when you view the source of explicitly discuss the
namespace
name in plain text - so these are cases where we are looking under the hood
anyway.

> * XML language lawyers have huge flamewars about what XML vocabulary
>should be the "referent" of the namespace link (XML Schema? DTD? Some
>meta-schema document? Stylesheet?)


One of the reasons for simply using a URI is that it bypasses those
flamewars which
have been had about URIs in general. We should teach students about generic
URIs (http://www.w3.org/DesignIssues/Generic ) and the difference between a
abstract resource and a particular representation in a language negotiated
between
client and server. And how that difference is defined by the URI spec and
its
schemes and protocols.

> * If there is such a referent, then it becomes ambiguous whether RDF
>properties, etc. apply to the retrievable referent or to the abstract
>"namespace."


I would not say it is ambigious. You need to be clear about what you mean.
This is a good point. I have discussed it in
http://www.w3.org/DesignIssues/Identity.html
It is a question for RDF if it wants to be able to refer separately to the
document tree
and the RDF graph of a document, for example.

For HTTP URIs, the HTP headers get to say a lot about the relasionship
between the
abstract thing you asked for and what you have been given. But there could
be much
more - lots of RDF metadata about related variants of the documents for
example.

>I see the benefit in treating retrievable and irretrievable resources
>"the same" in some contexts but I see no benefit in providing no
>syntactic signal of whether they fall into the former or latter
>category.


The URI system provides great richness, by providng some simple and some
complex
schemes which have evolved over much time.  However,  to try to divide
resources
into "retrievable" and "irretrievable" is a little simplistic.  For example,
I could
happen to have a local broker which will find me documents by mid: or uuid:
while I might be off-line and not be able to get documents with http: names.
In general, these issues of retrievability and persistence are dealt with by
URIs
and languages should IMHO use URIs rather than try to reinvent them.

> Paul Prescod


Tim

Received on Tuesday, 16 May 2000 19:11:25 UTC