Re: uri, urn and info

On Wed, 2003-10-15 at 11:18, Ray Denenberg, Library of Congress wrote:
> From: "Michael Mealling" <michael@neonym.net>
> > In other words: urn:info:lccn IS NOT EQUIVALENT to urn:lccn and never
> > should be.
> 
> I don't follow you. Nobody is suggesting that lccn be registered as  both a
> urn namespace and an info namespace.

So the authors of the 'info' scheme are telling the LOC that once it has
registered the 'lccn' scheme below 'info' that it cannot then register
it as its own top level URN NID? What value does that get you other than
an alternate registry of what should be top level NIDs.

>From the 'info' draft:

     "Namespaces declared under the "info" URI scheme are regulated by 
     an "info" Registry mechanism.  The "info" Registry allows a public 
     namespace that is not part of the URI allocation to be declared in 
     a registration process by the organization that manages it (the 
     Namespace Authority).  The "info" Registry supports the 
     declaration of public namespaces that are not part of the URI 
     allocation in a manner that facilitates the construction of URIs 
     for information assets without imposing the necessity of URI 
     maintenance on the Namespace Authority. Information assets 
     identified within a registered namespace SHALL be added or deleted 
     according to the business processes of the Namespace Authority, 
     and yet MAY be referenced within network applications via the 
     "info" URI in an open, standardized way without additional action 
     on the part of the Namespace Authority. "


Given your statement above and this paragraph, the only function that I can 
see that 'info' has when compared with the 'urn' scheme is that the registration
process is run by NISO instead of the IANA. URNs have no dereferencing semantic
and every single one of the suggested namespaces in the 'info' document adhere
to the URN persistence requirements as defined.

If the entire point of this is that someone thinks that the URN NID process
is to slow then we could've all saved ourselves a lot time and effort by simply
suggesting changes to RFC 3406 to speed it up. 

The original discussions I had with respect to 'info' suggested something 
that was clearly bounded and probably safely usable. But comments such as those
above still suggest that the unstated intent is simply an end run around the
existing registration mechanisms....

-MM

Received on Wednesday, 15 October 2003 11:41:05 UTC