Re: [URN] Re: Relative URLs and URNs

"Ron Daniel Jr." <[email protected]>
Newsgroups gmane.ietf.url
Message-ID <[email protected]>
Thus spoke Daniel LaLiberte:
>Ron Daniel, Jr. writes:
> > This is the sort of problem I am running into now in our tests, where
> > we have a bunch of HTML pages we are retroactively assigning URNs to.

>First, identifiers (relative or not) may *reflect* a filesystem
>structure, but it is up to the server whether to look up an identifier
>in a filesystem, database, or pass it to a CGI program, for
>example.  So it is incorrect to assume filesystems specifically.

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

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.

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.


Ron Daniel Jr.              voice:+1 505 665 0597
Advanced Computing Lab        fax:+1 505 665 4939
MS B287                     email:[email protected]
Los Alamos National Lab      http://www.acl.lanl.gov/~rdaniel
Los Alamos, NM, USA, 87545
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.