Re: Relative URLs and URNs

> If all URNs are syntactically opaque URLs, are we not imposing a
> restriction on all URNs that they cannot use the relative URL mechanism?

Yes, but this is a feature.  Relative URLs wire relationships between
resources into the resource name itself, which hurts long-term persistence.

> Long term, support for some name
> spaces will eventually fade out completely, so moving to a new name
> space is not only a possibility, it seems to be a certainty.

Yes, for newly-created names.  But there's no reason why resolution
services cannot continue to exist for old namespaces, even though
they may use new resolution methods and protocols.

> How is a location within a resource really different from a relative
> URN?

The answer depends on whether the relationship between locations within
a resource can change over time.  But you're right - the ability to
reference different portions of a resource opens up a very similar
can of worms as the ability to reference one resource relative to another.

If you want persistent references for portions of a resource, you need 
similar rules for assignment as you would for persistent identifiers 
for resources themselves -- e.g. don't use section numbers (they'll change)
or human-meaningful section names (because the document will be 
reorganized into sections that don't correspond to the original one).

Even then, I'm not sure what it means to talk about references 
relative to a "Base URN" ...because this assumes that the "Base URN"
will need to change while the intra-resource reference names 
need to stay the same.  

> Another advantage of relative identifiers is that they are shorter
> than their equivalent full identifiers.  

It's not necessarily true that a URN is shorter than a relative URL.
Since URNs don't need to be human-meaningful, they can be allocated
from a denser space than is typical for URLs.

Keith