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

Re: URIs & Namespaces

From: Erik Wilde <dret@berkeley.edu>
Date: Mon, 10 Dec 2007 14:10:10 -0800
Message-ID: <475DB942.1070004@berkeley.edu>
To: uri@w3.org
CC: noah_mendelsohn@us.ibm.com, Al Gilman <Alfred.S.Gilman@IEEE.org>

hello noah.

thanks for the feedback!

noah_mendelsohn@us.ibm.com wrote:
> What's wrong with using a base URI and relative URIs?  For example:
> Base URI for the namespace: 
> http://ErikWildesLocationNamespace.org/placenames/
> Name for Berkeley: 
> http://ErikWildesLocationNamespace.org/placenames/Berkeley
> Presuming you register ErikWildesLocationNamespace.org (not surprisingly 
> it's available just now), you get to decide how to allocate URIs 
> associated with that DNS name.  You can publish a document, perhaps at 
> that base URI, and have it say:
> "URIs of the form http://ErikWildesLocationNamespace.org/placenames/XXXXXX 
> are names of places.  Permission to allocate new XXXX names is given to 
> (specify your rules here).  The owner of these URIs warrants that they 
> will remain so associated in perpetuity (at least insofar as he is in a 
> position to guarantee that).  Accordingly, while it is >possible< to use 
> HTTP to dereference any of the resources identified by these URIs, such 
> dereference is not required to establish the association between some XXXX 
> and the corresponding place.  See (pointer to your documentation) for how 
> such associations are maintained."

that somehow only works for pretty heavyweight place namespaces, where 
somebody (such as me) would bother registering a dns name and set up the 
appropriate server. to me, that looks like piggybacking something onto 
http that should not be there. i do have read the tag finding about 
avoiding new uri schemes and trying to fit things into http, but i think 
that if new forms of interaction are involved, then new uri schemes 
still might be appropriate.

for example, the tel: and mailto: schemes make sense (i think), because 
not only do they identify things, they also clearly define how to 
interact with them. the same is true for ftp: and, i guess, most other 
uri schemes that are viewed to be well-justified.

by having a uri scheme for locations, one would know the possible 
interactions with these resources, such as stating "this is where i am 
right now" or "find me a route how to get there". that might not work 
well for all locations, but at least it should.

or to put it differently: how in the current web architecture can i make 
a statement about my location, and a user can then decide which mapping 
service to use to find that location? http: in that case forces me to 
send people to google maps or yahoo maps or some other specific service, 
whereas all i want to do is to identify my current location, so that 
others can use that information.

or let me ask something different: there is an internet draft for a uri 
scheme for wgs84 coordinates. is that something that should be done or 
should it be folded into some http prefix? i believe that location is an 
important enough concept to be represented on the web, so i think there 
should be the concept of location as a web concept. and btw, i am really 
looking forward to the www2008 locweb workshop, which will exactly 
discuss this question.

now, if location is a web concept (which is open to discussion), should 
non-gps locations be expressed in that conceptual space, or should they 
be mapped to http prefixes? i think the former is better than the 
latter, but i am still not sure and generally agree with al gilman that 
any uri scheme requiring escaped uris within uris is rather ugly. but 
apart from that syntactic ugliness, i think conceptually this is what i 
am looking for. of course, one could make namespace names in the 
location uri scheme something else than uris, avoiding reserved uri 
characters, but i kind of like the xml namespace approach (even though 
it is thoroughly confusing for all people learning it).

cheers,

dret.
Received on Monday, 10 December 2007 22:11:37 UTC

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