RE: URx Questions

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Mon, 21 Jan 2002 16:06:03 +0200
To: "ext Daniel R. Tobias" <dan@dantobias.com>
Subject: Re: URx Questions

On 2002-01-21 15:38, "ext Daniel R. Tobias" <dan@dantobias.com> wrote:

>> Having both 'xxx:foo' and 'urn:xxx:foo' is sure to result in
>> alot of needless overhead.
> 
> True... I've noticed a current trend in Internet drafts to try to get
> both forms of each new scheme... this is rather confusing, and leaves
> me wondering which I'm supposed to use if I decide I want to use one
> of those new schemes to give unique names to things.  Do I use the
> "urn:" prefix if I want them to ultimately resolve to some Web
> resource, and leave it out if I don't expect such resolution to ever
> happen?  But what if I change my mind later?  Does that mean I end up
> with two different URIs for the same thing?

Exactly. It should be clearly stated that there should either be
a URI scheme or a 'urn:' Namespace, but not both, otherwise one
must equate all pairs of URIs from either.

> But even if I want them
> to resolve, how wold they... none of these new schemes seem to be
> giving the slightest clue as to how they would actually be resolved
> as URNs.
> 
> Actually, in general, that seems to be the biggest problem with URNs;
> they're a good concept in theory, but in practice even after years of
> discussion nobody seems to really know how they're going to be made
> resolvable.  

Well, resolution of URNs has always been contextual. Work is finally
reaching maturity on a global, distributed mapping table that would
bind URNs to URLs and would allow any client, anywhere to retrieve
resources by URN as easily as URLs using a system similar (actually
based on) the DNS system. But one can always provide localized
resolution solutions.

Nokia uses URNs to identify all managed digital resources, and
retrieval is based on configuration for a given site or client, as
to which registry or archive the resource is accesable. This system
has been in use now for a couple of years, and so when folks say
that all URNs must be urn:s, I have to laugh.

C.f. http://www-nrc.nokia.com/sw/Metia.zip

> Some of these new proposed schemes offer namespaces
> whereby anybody can create names at will, but in the absence of any
> registration system that puts them all in a big database, and with
> explicit definitions to the effect that the use of domain names to
> identify the minting authority does not imply that this authority is
> actually reachable currently at that address, there simply does not
> seem to be any reasonable mechanism by which a user agent might try
> to resolve them into a resource.
> 
> By those standards, URPs may make more sense, since they are
> explicitly defined not to resolve into anything.

We still need URNs. We need a way to name things without having
to worry about where those things might be stored or managed.
Such as the name of a book or image or soundtrack, which may
in fact get stored in many locations for various reasons, but
is still the very same "thing".

I see three parts to URN usage:

1. Minting of the URN, which must be globally and temporally unique.
2. Describing the resource in terms of the URN (optional really) such
   as ownership, encoding, language, etc.
3. Mapping the URN to a URL or other means of retrieval, for a given
   environment (which may be global)

Most URN schemes (ISBN, DOI, etc.) force you to pay for all three
services, when one may not need all of them -- and most such schemes
put a focus on high persistence, security, and quality which, while
very important for large publishers, are not as critical for most
folks and also price such services way beyond the reach of most
folks (just price a few DOIs and ISBNs, very expensive).

So my goals with the 'hrn:' URN scheme is to provide a reliable and
cheap way for folks to mint URNs and then address the description
and mapping issues seperately.

There already are several description solutions available, including
open source such as the Open Archives Initiative. And since it is
not too hard or expensive to get Web or FTP space, the mapping
and retrieval is also easy to arrange -- especially if the description
solution is used to define the mapping, by simply including a
property such as 'location' which is a URL.

So, whether or not the global resolution solutions planned for URNs
happen or not, we can still use URNs very effectively and they are
very much needed.

Cheers,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Monday, 21 January 2002 09:42:48 UTC