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:
- 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.
- 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. - 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. - 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...
[[ PS: this post has been posted to the W3C's URI mailing list as well, here is the starting point of the thread. ]]
Comments
You can follow this conversation by subscribing to the comment feed for this post.