Re: URIs & Namespaces

At 11:53 PM -0800 6 12 2007, Erik Wilde wrote:
>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.

For placenames, a URI namespace is a bad idea.

This is because a namespace among URIs presumes a partition in the
semantic domains.

The broad concepts like 'placenames' that one wants to schematize
with local vocabularies don't partition gracefully. If we, for
purposes of encoding force a partition, we underrepresent
relationships that cross namespaces that are of too much value.

This is what is right about RDF: it takes a graph.

The schema of schemas is a graph, and so it takes a graph-mungeing
calculus to manage metadata.

There is too much activity in the money-driven space around
location-aware applications for us to ignore that.

For placenames on Berkeley campus, therefore, I would seek something
that has an acceptable compromise of a) interoperates with the
for-pay domain and b) as open as we can get.

Pencil that is as Open GIS or GPS in a format that interoperates with Open GIS.

Then say that you are going to accept the discipline to document your
placenames with that sort of data that will interoperate with Garmin
etc. for-pay location-aware services.

Then use the concept variously termed

- localized name -- in desktop APIs
- label - in SKOS and ISO/IEC 24752-5

to link these interoperable data with the colloquial placenames.

The network-effect value-add of interoperable information is being
institutionalized through the marketplace for location-aware
services. Plug into it; the market forces will mean that your
alternate nomenclature through a URI namespace, without the same
facility of interoperation, will be unused.

Al

>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 Saturday, 8 December 2007 17:11:23 UTC