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