Re: non-http uris

hello ray.

thanks a lot for you email.

>   I would suggest looking at the info: URI scheme,
> and consider registering 'geoloc' (please
> don't call it 'loc') as an 'info:' namespace.   (An 'info:' namespace is
> analagous to a URN namespace.)   It seems to me that this geo-location
> sub-scheme is appropriate for use with 'info' though that would be something
> for the 'info URI Board (or whatever it's called) to decide, and if so,
> approval/registration is a fairly lightweight process (I can personally
> attest to that).  This approach would render the issue of a new URI scheme
> moot.

in a way, the whole discussion revolves around prefixes:

- i am thinking about a geoloc: prefix, thereby making locations a 
first-class web citizen.

- others are suggesting a prefix, pointing out that 
it would be better to have http for everything, so that web pages can be 

- urn: would also be a possibility, but they are more of a legacy 
concept from the old url vs. urn days and the only real advantage would 
be a more lightweight registration process.

- info: seems to be the new urn:; i am not an info expert, but to me it 
looks as if the only real benefit is the easier registration process. 
other minor differences to urns seems to be that info: does not as 
strongly recommend that a info: uri should be mapped to a http: uri by 
some mapping process. and info: uris have structure, urn: uris are flat. 
and info: allows fragment identifiers.

info: to me looks better than urn:, but i still think that choosing a 
uri scheme for the ease of registration is kind of a weird way of 
deciding how to represent resource identifiers. and finally, 
looks very much as if the library community just wanted to create their 
own registry for having an easier way of creating and managing 
sub-namespaces (is there a single non-library entry in there?). that is 
fine, but does not necessarily mean that this namespace should be used 
for everything non-http.



Received on Thursday, 10 January 2008 14:23:41 UTC