RE: URIs & Namespaces

The tag URI scheme <http://tools.ietf.org/html/rfc4151> accomplishes something similar.  A tag URI uses a domain name or email address as a namespace under which the owner of that domain name or email address is free to name whatever they choose.

-Dave

-----Original Message-----
From: uri-request@w3.org [mailto:uri-request@w3.org] On Behalf Of Erik Wilde
Sent: Thursday, December 06, 2007 11:53 PM
To: uri@w3.org
Subject: URIs & Namespaces


hello everybody.

at http://dret.typepad.com/dretblog/2007/12/uris-namespaces.html i have
published the following text, and i would be really glad to get some
opinions about this, in particular if anybody thinks that the whole idea
is not really a good one, and if so, why that would be so, and what else
would be the better way to go.

thanks and kind regards,

erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
        dret@berkeley.edu  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)

-----------------------------------------------------------------------

URIs & Namespaces

there's one thing about URIs and namespaces that i can't quite figure
out. it seems to me that URIs almost always require some kind of magic
resolution going on behind the scenes (such as the DNS), or they are
very specific about a well-known and well-defined name-to-address
resolution process, such as in URNs.

the problem i am looking at is to design a URI scheme for names which
should be well-defined in some namespace, but to not restrict or define
these namespaces themselves. in a way i want XML namespaces for URIs.

my use case is that of place names. i want to have a URI scheme that
identifies locations, and does so in a way which enables people to
define their own private vocabularies, if they want to do this. so the
idea is that i have a URI such as location:SouthHall, and this something
you can only understand if you know my location vocabulary, which has
additional information about UC berkeley's south hall. but even if you
don't know that vocabulary, you can still handle and compare URIs like this..

i think for locations, this concept makes sense, but regardless of that
question, how would you do it? the URI must somehow identify the name as
well as the namespace information. here are the possible options:

    1. context: we could just assume that there must be some context
that establishes the namespace binding. let's say there must be an XML
default namespace. this is bad because it makes URIs context-sensitive
and only works in environments which have some way of establishing
namespace bindings.
    2. prefix: to be a little more explicit, we could have a prefix in
the URI, turning it into location:placenamespace:SouthHall, which would
assume there is a namespace binding that associates the prefix with a
namespace URI. while this at least exposes the fact that some namespace
binding is involved, it is almost as bad as the first version, because
it makes URIs context-sensitive and only works in environments which
have some way of establishing namespace bindings.
    3. namespace name: we could remove the namespace binding problem
altogether by inserting the namespace name directly into the URI. but
then we would have to escape all URI reserved characters in the
namespace name, so something like
location:SouthHall;http%3A%2F%2Fberkeley.edu%2Fbuildings would be the
result (assuming that we use URIs as namespace names). not pretty at
all, and very likely to produce a lot of problems because of all the
escaping and un-escaping that needs to be done.
    4. URNs: if we do have namespaces and names, why not use URNs? the
problem with URNs is that they assume managed namespaces and
well-defined mechanisms to resolve names. The space of URN namespaces is
managed is one of the core assumptions of URN Namespace Definition
Mechanisms. so assuming an unmanaged set of location namespaces in the
same way as XML namespaces are unmanaged is not very URN-like.
urn:location:http%3A%2F%2Fberkeley.edu%2Fbuildings:SouthHall might work,
but it would not define some resolution process, it would simply define
a syntax structure. and again, there would be the URI-within-a-URI
problem, which results in a lot of ugly escaping and the associated risks.

i don't really like any of these alternatives. but are there any others?
is the whole idea a bad idea? i think that the basic use case makes
sense, but before discussing this, i would really like to find out
whether there is a better way of implementing URIs & namespaces than the
above four ways.

i think the basic premise of some URI scheme to identify things of a
certain nature (location), which sometimes may simply be used by simple
string-matching, but apart from that can be managed in user-defined
namespaces and have no hardwired mechanism for describing namespaces,
could be used in various scenarios. my location scenario simply is the
one that made me run into this problem...

Received on Friday, 7 December 2007 20:13:48 UTC