W3C home > Mailing lists > Public > uri@w3.org > December 2007

URIs & Namespaces

From: Erik Wilde <dret@berkeley.edu>
Date: Thu, 06 Dec 2007 23:53:03 -0800
Message-ID: <4758FBDF.9000905@berkeley.edu>
To: uri@w3.org

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 07:53:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:11 UTC