Re: [URN] Re: Relative URLs and URNs

Ron Daniel, Jr. writes:
 > The point I was trying to make is that the presence of the relative
 > URLs is not helping us as we make the transition to URNs.

Relative URLs (which are relative URIs intended to be interpreted
relative to an absolute URL) would not interfere with a transition
to URNs if you keep the same absolute URL base.  But if you want
each and every one of your documents to have a URN, and you can't use
relative URNs then you have to use absolute URNs.  That much is clear.

 > 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)

 > 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.

 > 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.

dan