Re: [URN] Re: Relative URLs and URNs

Martin J. Duerst writes:
 > For URLs, it's very clear how relative URLs behave. But for URNs,
 > there is an additional step: Resolution from name to location.

There isn't necessarily any additional step.  Names *can* be resolved
"directly" to resources.  Or perhaps you will get a URC or set of URLs
back.  "Directly" is in quotes because there is necessarily some
indirection in the resolution process, but that may not involve
getting a URL.

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

Given the above, this question doesn't necessarily make sense.  But
more below.

But there is an easy answer to the question of how a relative URI is
resolved relative to a base URN.  The rules for relative URLs
described in RFC 1808 (http://ds.internic.net/rfc/rfc1808.txt) should
work exactly the same for URNs, with possibly one clarification
described below.

 > We definitely cannot and should not assume that names and locations
 > are equally structured.

Correct, we cannot.  But you don't need to worry about that, if you
follow the rules.

RFC 1808 describes a seven step process for constructing the absolute
URL from the relative URL and the context.  We can just substitute URI
(and therefore include URN) wherever it says URL.  The first step of
the seven concerns finding the base URI, which I give here in brief
since that is where the clarification is needed.

Use the first one that succeeds:

1. Use the explicit base URI from the document content, if any.
2. Use the explicit base URI from the encapsulating entity, if any.
   (e.g. http response message, another document, etc)
3. Use the URI used to retrieve the entity, if any.
4. Otherwise the base URI is undefined.

Step 3 should be clarified: If there is no explicit base URI
found by step 1 and 2, we should use the *last* URI used
to retrieve the entity, not the first or some intermediate.  This
applies both for a chain of URL redirections or for a URN that is
resolved into a URL.  Roy Fielding pointed this out to me when I
thought it should be the first URI used, or perhaps the last
permanent redirect.

So this clarification is an answer to your question above; whether
the relative URI is applied to the name or the location depends on
what the document and server say should be done.

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

Exposing the hierarchical structure *allows* use of relative URNs, but
even with that structure, you wouldn't have to use relative URNs if
you did not want to.

Moreover, exposing the structure permits more scalable resolution.
Information obtained at intermediate levels can be cached so the
client can use that information in subsequent similar requests rather
than requesting it again.  

As you say, instead of an explicit structuring of the name space
(e.g. using '/' delimiter), an alternative is to use the characters in
the identifier itself.  The handle scheme would have clients hash the
whole id and from that lookup one of several global handle servers.
Either way, we have an essentially random distribution of servers -
but this randomness defeats locality of reference.  Locality of
reference means, in this application, that you (or members of your
local group) are likely to reference related material, so if the
related material is colocated, you can remember the location (or other
metadata) one time and use it again next time.  But if you distribute
randomly, the relationship between the material does not help.
I've written (long ago - rough draft) some more on this scaling issue at:

  http://union.ncsa.uiuc.edu/~liberte/scalability.html

In order of preference we have:
1. No distribution - one server
2. Random distribution
3. Organized distribution

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

The flexibility to change name spaces and keep the same substructure
is useful.  If, as a result, you get *more* persistence, not less,
that is important.

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

If you mean examples where I have actually saved work, no I have not
done this yet.  But Ron has described his experience which argues
*against* the value of relative URIs in the case of moving the
document to a *non*-hierarchical name space.

A path URN is hierarchical, and looks just like an http URL except
for the scheme and host part.  The relative URIs in a document can
remain exactly the same when moving to a path URN for the base.
Not changing things saves time, obviously.

dan