Message-Id: <9410061314.AA04832@plato.ansa.co.uk>
To: uri@bunyip.com
Subject: Re: Why URN is a subset of URL
In-Reply-To: Message from J.P.Knight@lut.ac.uk of Thu, 06 Oct 1994 08:50:51
<Pine.3.05.9410060850.A8508-b100000@suna>
Date: Thu, 06 Oct 1994 14:14:39 BST
From: Owen Rees <rtor@ansa.co.uk>
"Jon P. Knight" <J.P.Knight@lut.ac.uk> writes:
> On Wed, 5 Oct 1994, Roy T. Fielding wrote:
> > Peter Deutsch wrote:
> > > Still, the point is that at its heart, a URN is not
> > > intended to allow access but location independent naming.
> > > Just as ISBNs and library call numbers are different
> > > things and serve different purposes, I submit that URNs
> > > and URLs are different things and will serve different
> > > purposes.
> >
> > That is an implementation detail.
>
> Hmm, I'm not so sure. I think that the fact that URLs and URNs may have
> similar syntax _is_ an implementation detail, but the semantics are
> _defined_ to be different and its the semantics that are really the
> important thing (I think its also what Peter was probably getting at).
Yes, the difference is in how URNs and URLs are intended to be used, not what
they look like. One of the problems is that we can, and do, sometimes use URLs
as if they were URNs, and until there are ubiquitous URN mechanisms, this will
continue to happen.
A current example of why we want URNs is that the Tcl/Tk contributed archives
moved yesterday, thus making the reference in Ousterhout's book obsolete - and
there is no way to fix the reference in the books that have been sold. It was
already a problem that the book mentioned only the "master" site, and not the
many mirror sites; but now the mirror sites have remained, but the old master
has gone. We could use the string that used to be the URL for the master
archive as a URN - set up a service where you can look it up to get a URC and
so on, but this is not a good long term solution to this kind of problem. Note
also that "the Tcl/Tk archives", "the latest FAQ", etc. are resources that we
want to be able to name, which exist at many locations, and for which a
checksum cannot serve this purpose.
My informal distinction is that a URN is the name of a resource, but a URL is
the name of a location at which the resource exists. (Replace "location" with
"means to retrieve a resource from a specified location" if you want to go
into that aspect of URLs.) The "news:" scheme falls into the grey area between
URNs and URLs, but that just shows that there are useful things that do not
fit neatly into this taxonomy.
There are times when the distinction between the resource and the location is
important, and times when it is unhelpful. For example, consider the
difference between:
Fetch the resource that is at URL
Fetch the resource from URL
In the first case, any instance of the resource will do, I will be satisfied
with the copy that is in the local cache. This is a case where current
implementations of caches use URLs as if they were URNs. The second case
emphasizes the location, and I have to run a browser that does not use the
cache to get this effect.
The distinction between URNs and URLs is like the distinction between
"attributive names" and "invocation names" in the ANSA naming model (another
plug :-), the former are used to indicate a third party, the latter to
interact with the named entity. Some names are intended to be used in both
ways, but this does not make all names suitable for both purposes.
Regards,
Owen Rees <rtor@ansa.co.uk>
Information about ANSA is at <URL:http://www.ansa.co.uk/>.