Re: Relative URLs and URNs

 > > Thus spoke Tim Berners-Lee:
 > > >The URN scheme should be mapped onto
 > > >urn1://authority/nameissuedbyauthority

Martin J. Duerst writes:
 > As far as I understand, the first part after the "urn" prefix is
 > not an authority (work is going on on mechanisms to actually
 > find such authorities or resolvers), but more akin to a scheme
 > in the URL case. So the use of ":" instead of "//" has some
 > merit.

That is one way to look at it.  I like to think of the <authority> as
a scheme name because it determines how the rest of the identifier is
interpreted, just as for other identifiers.  But this nested notation
does not fit in the current generic URI notation.  We could probably
change the generic URI notation to allow this nesting, but there are
some other considerations.  For one thing, there was some discussion
about whether the <authority> itself should be hierarchical to allow
subauthorities.  Scheme names are not (currently) hierarchical.

But if the <authority> in the identifier is used to find or look up an
authority or resolver, then the <authority> is at least the *name* of
the authority or resolver.

 > I beg to disagree. URNs are designed to be syntactically equivalent to
 > opaque URLs.

Whether URNs are syntactically opaque URLs is still open for discussion.

If all URNs are syntactically opaque URLs, are we not imposing a
restriction on all URNs that they cannot use the relative URL mechanism?

 > Ron Daniels said:
 > > At this time we have not defined any relative URN specification.

True, but we wouldn't need to define a new relative URN specification
if we simply inherited the relative URL specification so that it applies
to URNs also.

 > Because URNs are persistent, the main advantage of relative URNs,
 > namely invariance on coordinated movements to other locations,
 > is irrelevant.

Not true, for several reasons.  One reason is that, although URNs are
*intended* to be persistent, there will be multiple names for things,
each possibly providing different associated services or different
reliability or speed of resolution.  Long term, support for some name
spaces will eventually fade out completely, so moving to a new name
space is not only a possibility, it seems to be a certainty.
Therefore, making the identifiers within a document relative to the
base identifier is a good idea.  This is not really different from
what you suggest next:

 > What could be more relevant is the possibility to address parts of
 > resources, or 'locations' within resources, together with URNs.

How is a location within a resource really different from a relative
URN?

What makes an identifier be relative is that part of the context for
interpreting it is missing from the identifier itself.  That context
is the base URL of a document, but it could just as well be a base URN
of the document.

So both relative URNs and relative URLs are better thought of as
relative identifiers of some kind.  What kind of identifier they are
depends on the context, the base URI.  The very same relative
identifier could be both a relative URL (e.g. http) and a relative URN
(e.g. path), if the URN supported hierarchy at that level.

Another advantage of relative identifiers is that they are shorter
than their equivalent full identifiers.  This becomes a significant
issue when there are large numbers of identifiers in a document.
(This is analogous to the flyweight pattern, if you are familiar with
OO design patterns.)

 > I have sent some considerations about this to Leslie as a
 > response to her request on the URN mailing list; I can make
 > this available if somebody is interested.

If Leslie includes that in her summary, I can wait.

--
Daniel LaLiberte ([email protected])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/