Message-Id: <9310280018.AA20119@merit.edu>
To: uri@bunyip.com
From: "Fred Swartz" <fred.swartz@umich.edu>
Subject: URN -> (URN | URL)...
Date: Wed, 27 Oct 1993 20:18:52 -0400
Because of the lack of a specific protocol, it has been hard to
decide the meaning of some things, eg, the much talked about,
but never specified, URN->URL mapping.
I don't think the simple notion of a URN mapping into one or more
URLs is adequate. Specifically, I think that URNs must map into
either URLs or URNs.
If URNs are indeed the location independent pointers that everyone
expects them to be, then people will want to construct new URNs that
point to these too.
Let's say you have a URN defined by someone else and it points to
a resource (maps into one or more URLs). Now let's say that you
find/make/have another copy of that resource. The natural thing
would be to add the URL for your copy to that URN. But you don't
own that URN and you may not be able to negotiate the addition with
the URN owner (insert various scenarios).
Now since you run your own URN server, you can create a URN which has a
URL to your copy of the resource, plus all the other copies. If you
expand the other URN to its URLs and add them, then you will be plagued
by stale URLs since you will not necessarily be on the update list that
the original URN is. The more reliable way to do this would be to
define your URN as the URL to your copy of the resource along with the
URN to the other copies.
Since I imagine URNs will be the common way to identify things these
must then be elements from which you can build new URN structures since
basing a new URN on the current snapshot of another URN destroys
location independence.
I don't think this create too many problems. Simple rules like those
used for Unix symbolic links can be used to detect loops (no more than
n expansions).
Of course, if you always considered a URN to just be a case of a
URL, then everything was ok all the time. :-)
-- Fred (fred.swartz@merit.edu)