Subject: Re: Informal NID registration for Harvard University Library

From: Rob Cameron <[email-masked]>
Date: Wed, 7 Mar 2001 12:01:07 -0800

Stephen,

Your document addresses a very important point that may be of
general interest to list members and is certainly of interest to us.

> Process of identifier assignment:
>
>   The administrative system is decentralized to allow individual
>   naming authorities to create and maintain independently the URNs
>   that fall within the scope of those authorities.
>
>   Administrative units or agents wishing to assign URNs must be
>   granted the appropriate privilege to do so from the administrator of
>   the naming authority in the scope of which the URNs are to be
>   created.  Similarly, units or agents wishing to administer a new
>   delegated naming authority must negotiate directly with the
>   administrator of the potential parent authority, who, if
>   acquiescent, will create the delegated authority.

Dealing with rules for delegated authority of namespace management
is an interesting topic.   I think it deserves considerable
discussion.

In the general context, there may be very tight top-level control of
a namespace.  But once a namespace has been delegated, the next level
of control may be very loose.   In the area of DNS names, the result
has been cybersquatting and other practices.   I'm not sure, but
this may also become a problem with respect to URN namespace management.

I think that a requirement for negotiated control at each level of
the hierarchy, as in your document, makes sense.

In the area of bibliographic identification, at least, I think there
is reason to go further.   Here are three general concerns that I have
and possible statements to address them.

  (1) Conflicts with historical (non-URN) identifying codes.
      For example, suppose that the naming authority HUL.ULC
      (University Library Council) creates a new subauthority
      HUL.ULC.PSC for a "Preservation Standards Committee".
      This may be allowed because there is no pre-existing URN
      that would conflict.  But there may be historical ULC
      documents that use "PSC" for "Public Services Committee".
      When URNs for those documents are created, a conflict may
      arise.

      I don't doubt that you've thought of this, but it would be
      good to have model wording that attempts to address the
      problem.   Here's a possibility.

      "A naming authority must make best efforts to ensure that
       codes assigned for subauthorities or resources do not
       conflict with previous uses of those codes within the
       scope of the authority."

  (2) Unnecessarily distinct syntax.

      I can't quickly come up with an example for your domain, so
      I'll give one from our work with USIN journal article syntax.
      We allow individual authorities to create their own identifier
      syntaxes (as your flexible resourcename syntax does).  But we
      also have syntactic conventions that apply to things like
      serial resources.   For example, for print journals
      we define the ":" operator to introduce principal enumeration
      (volumes), the "()" notation for secondary enumeration (issues)
      and the "@" notation to specify the starting page number of
      an article.   This applies to all namespaces with the USIN
      framework and should be respected by all naming authorities.

      "A naming authority must respect syntactic conventions
       established by parent authorities.  No conflicting use of
       such conventions is permitted.  Where applicable, the
       conventions should be used."

  (3) Registration level problems.
      Suppose that the Digital Acquistions Committee of your
      University Library Council wants to start issuing URNs,
      before ULC is ready to start managing its namespace.
      In this case, I think the HUL authority should negotiate
      on behalf of ULC to register the HUL.ULC.DAC.

      "Naming authorities may act for subauthorities as required.
       For example, a naming authority may authorize a
       sub-subauthority even though the relevant subauthority is
       inactive."

These are not meant to be criticisms, just points for discussion,
if you or others are so inclined.

Robert D. Cameron, Professor                     [email-masked]
School of Computing Science                      FAX: (604) 291-3045
Simon Fraser University                          Phone: (604) 291-3241
Burnaby, B.C., Canada  V5A 1S6
Bibliographic Protocol/Universal Serial Item Names Project
http://usin.org/

---

From: Stephen Abrams <[email-masked]>
Date: Thu, 8 Mar 2001 09:25:12 -0500

Hi Robert:

Thanks for responding to our recent namespace registration
template.

 > Dealing with rules for delegated authority of namespace managmenet
 > is an interesting topic.  I think it deserves considerable discussion.

Our system was designed explicitly to allow decentralized
naming operations, so we spent quite a bit of time thinking about the
devolution of policy and administrative control.  Our general approach
is to let individual naming authorities do whatever they want, subject
to the minimal rules imposed by the namespace syntax and general
system policy.  However, the scope of administrative privilege
accumulates downward as sub-authorities are delegated, so a higher,
and presumably, more responsible authority can always override an
action taken at a lower delegation level.

 > this may also become a problem with respect to URN namespace

We avoid any potential problems along these lines in the following
manner: Our delegation model provides parent naming authorities with
control their children, as stated in the registration template:

     "The administrator of a naming authority, regardless of its
     position within the delegation tree, has full oversight and
     operational control over all aspects of URN administration of all
     delegated authorities that derive from the common parent."

For any operational privilege explicitly granted to a naming authority
(e.g., create URN, update resolved URL, etc.), that authority
implicitly holds the same privilege relative to all of its children
and their derivatives.  During sub-authority delegation, the parent
authority administrator cannot grant to the delegated administrator
privileges that the parent does not possess.  So any potentially
unacceptable action taken by a delegated authority can be overridden
by its parent, or some authority further up the tree.  (This takes the
form of being able to repair or undo some action; there is no
provision in our administrative system for actions to be be vetted by
some higher authoritiy before being performed.)

 > "A naming authority must make best efforts to ensure that codes
 > assigned for subauthorities or resources do not conflict with previous
 > uses of those codes within the scope of the authority."

In our namespace the NSS is subdivided into two components, an
<authoritpath> to identify the naming authority under which scope the
URN is issued, and a <resourcename> to identify the resource:

     nss = authoritypath ":" resourcename

with the colon being a reserved character in <authorititypath>.  The two
identifiers:

     HUL.ULC.PSC:xyz
     HUL.ULC:PSC.xyz

(for resource "xyz" issued by the "PSC" authority; and "PSC.xyz"
issued by the "ULC" authority) remain unambiguous for identification
purposes.  If ULC has both a Public Services Committee and a
Preservation Standards Committee, the first one to use the PSC acronym
gets it.  As a best practice we encourage the creation of delegated
authority identifiers (and <resourcename>s) that are not semantically
loaded to avoid potential ambiguities.  We encourage the notion that
URNs are opaque identifiers and not additional descriptive metadata.
Whether these recommendations will be accepted in practice remains
problematic.

 > "A naming authority must respect syntactic conventions established by
 > parent authorities.  No conflicting use of such conventions is
 > permitted.  Where applicable, the conventions should be used."

Our registration system does not have the facility for allowing
authorities to define extensions to the namespace syntax, or for
enforcing any such extensions.  Any such rules would have to be
implemented as part of the workflow for an authority and its
delegates.  There is nothing to stop an authority for doing this:

     "Naming authorities may independently propose and enforce local
     policies and administrative procedures relative to names created
     within their scope."

Again, we are trying to encourage the notion that names
are opaque identifiers.  Descriptive metadata properly belong in
catalogs or other resource discovery systems.

 > "Naming authorities may act for subauthorities as required.  For
 > example, a naming authority may authorize a sub-subauthority even
 > though the relevant subauthority is inactive."

This is already allowed, and was meant to be declared by the
statement:

     "The administrator of a naming authority, regardless of its
     position within the delegation tree, has full oversight and
     operational control over all aspects of URN administration of all
     delegated authorities that derive from the common parent."

Each naming authority has complete control over the subset of the full
namespace specified by that authority's <authoritypath>.

In short, I agree with your various proposals, but I think that we
have already addressed this concerns in our template, although perhaps
our language was more implicit than explicit.

__________________________________________________________
Stephen L. Abrams                       [email-masked]
Digital Library Software Engineer       Tel: (617) 495-3724
Office for Information Systems          Fax: (617) 495-0491
Harvard University Library