Re: [URN] Re: Relative URLs and URNs

Thus spoke Omar Syed:

> The rest of what I say is predicated on the following:
> 
> 1. urn:<NID>:<NSS>
> 2. clients must treat <NSS> as an opaque string (i.e. do not interperet)
> 3. the details of interpereting a <NSS> are know only to
>    coresponding <NID> resolvers
> 4. clients must use appropriate resolvers to map the <NSS> to 
>    a location or resource

I think assumption 2 is in error. Clients that know the structure of
a name in a particular namespace are likely to manipulate it. Further,
the rules in RFC1630 about only using '/' to denote hierarchy and
mandating a particular order for the elements in the hierarchy are
intended (I assume) to provide enough commonality across namespaces
that clients will be able to process identifiers from novel namespaces.

> But the client is not allowed to
> interperet the <NSS> so it cannot replace the "Res1"
> from the previous absolute URN with "Res2" to create a new
> URN.

Yes, it could do that.

> Now for the serious concerns:
> 
> Lets say that another valid reference for resouce r1 is:
>   urn:nid2:X:Y:resource1
> 
> Suppose a client uses this absolute URN to get r1 and then
> comes across the relative URN: "Res2".
> 
> The first concern is that the client won't even know that
> the author of resource r1 had intended the relative URN
> to be retrieved using the "urn:nid1" scheme.  Is there a
> way for an author to specify the intended scheme along
> with the relative URN?

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.
Since those pages have lots of relative links in them, we can either:
  1) Make sure our new URNs reflect the same filesystem arrangement
     as the pages do.
  2) Modify the pages to make all the references absolute.
Alternative 1 certainly is unattractive, since a major point of URNs is
to provide independence from the filesystem organization du jour.

But, to answer your question, there are two appraoches the author of
an HTML page can use to say that the references are relative to BASE-URN-1
instead of BASE-URN-2. One is just to use absolute references. The second
is to use the BASE tag of HTML.


> Also will authors have to maintain multiple relative URN
> references (for each <NID> that can be used to reference it)?  
> For example:
>   <a href="urn:nid1:/Res2" href="urn:nid2:/resource2">
> Will HTML specs be modified to allow this?


> Finally, the most serious concern:
> 
> It is quite possible for there to be multiple ways
> to reach a reference even within the same name space.
> For example:
>   urn:nid1:A:B:Res1
> and
>   urn:nid1:A:res1
> may both be valid.  However, the URN:
>   urn:nid1:A:Res2
> may not be defined.  So a client could request the URN:
>   urn:nid1:A:res1/urn:nid1:/Res2
> How would the resolver know to remap 'A:res1' to 'A:B:Res1'
> since the first is already a valid reference in its name space.

It wouldn't.


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