Re: [URN] Re: Relative URLs and URNs

On Fri, 31 Jan 1997, Daniel LaLiberte wrote:

> Relative URLs (which are relative URIs intended to be interpreted
> relative to an absolute URL)

This reminds me of an implicit problem here with URNs that I haven't
seen answered:

For URLs, it's very clear how relative URLs behave. But for URNs,
there is an additional step: Resolution from name to location.
The question now is: is a relative URI supposed to be applied
to the name (i.e. before resolution, URN) or the location
(i.e. after resolution, URL) of the document. We definitely
cannot and should not assume that names and locations are
equally structured.
The later alternative would help for things such as coordinating
between development and production version (there would be URNs
for the "entry points" of the production version, but the rest
would all be relative URLs).
The former alternative seems to be implied by all those that
see the need for hierarchical URN namespaces.
I don't see how we could have both unless we introduce additional
syntax (e.g. \ for URN hierarchy and / for URL hierarchy, or
maybe something with /// and //).
Daniel, maybe you can tell me which one you have in mind?


>  > The URNs
>  > we are assigning are very different from the URLs we currently use.
>  > For example, the document at
>  >   http://www.acl.lanl.gov/URN/index.html
>  > might get a FPI of
>  >   -//LANL ACL//199703014039//EN
>  > which results in the URN
>  >   urn:fpi:-%2F%2FLANL%20ACL%2F%2F199703014039%2F%2FEN
> 
> Is it true that the fpi URNs are non-hierarchical, or if they have
> hierarchical structure, you don't want to expose it?  (I'd recommend
> that the syntax of fpi URNs expose the structure and avoid reserved
> chars, something like urn:fpi:/LANL/ACL/1997/03/01/4039/EN)

What does exposing the structure help exactly? A resolver migh
very well use the last few digits of the long number for
distributed processing because it gives better distribution.


>  > Relative URNs only save you work if the next
>  > namespace you use is very similar to the one you currently use.
>  > If they are not similar, then you have to edit the documents, just
>  > as you would have to do if you had used absolute identifiers.
> 
> Or, another way of looking at it is that (absolute) URNs only save you
> work if the structure of the name space is similar to the one you
> currently use.  If a relative URI can be used with either an http URL
> base or a path URN base, you don't have to change anything but the base.

I don't think that such parallel structures are really useful or
important. You expose an awful lot of structure that, for the sake of
persistency, you might want to hide.


>  > This is not a damning indictment of relative URNs, it just points out
>  > that they are unlikely to save one a significant amount of work.
> 
> Relative URNs *are* likely to save one a significant amount of work *if*
> you use a name space that is hierarchical and that supports relative
> URNs.

Can you give more details on actual examples where this work is
saved?

Not that I am absolutely against relative URNs, as some of my
mail may have suggested. But I just try to figure things out,
and for some of the things, I don't have an answer yet.


Regards,	Martin.