1999 November 15-16

Barbara Shuh wrote:

There appears to be a hole in the reasoning of using the register of implementors to carry the identifiers of name authorities.

I've had an question from a colleague at NLC working in the ILL Division asking why NUC (also known as the USMARC codes for organizations) is not on the list of namespace codes that has been registered in the Register of Identifiers Assigned to ILL Protocol Implementors.

My response was that LC was not on the list because they haven't implemented the protocol, and I suspect that LC wouldn't register their namespace as "NUC". I do not feel that it is my place as Registration Authority for the standard to just stick something on the list for LC, but to wait for a request from LC to be registered.

However, in practice we seem to be using an institution's Internet domain name. Should we add an amendment to the IPIG Profile (Clause 7.1 Note) that in the absence of a namespace registered for a protocol implementor, one could default to the domain name?

For LC, that would be "loc"

----------------------------------------------------

I was just about to raise this issue. We would like to add NUC symbols to our alias strings. However, we would prefer to use NUC as the name authority. The goal of the "name authority" was to ensure that library symbols were unique. NUC, in this case, would be the well-known name authority.

----------------------------------------------------

Mark Wilson:

Using NUC, or any other well-know authority device, seems to be a no-contest. However, institution names as name authorities does not seem quite as resilient to error. You get into the "i waz there first: problem.

----------------------------------------------------

I think that you have just shown that each 'name-space' does not really belong to an ILL implementor but to an authority that assigns and maintains the entries within their 'name-space'.The authority may implement the ILL protocol - but there again they may not.

So perhaps the 'name-spaces' should be in a separate list from that of the ILL implementors?

Then we (you) can list all those we know without omitting them because they have not or may never implement the ILL protocol.

And the listed 'name-space' could then match that already in common use (like "NUC") on all sorts of catalogues and printed lists, etc.

Aliases may be deemed appropriate in some cases...

My other concern is that this "loc" is only guaranteed to be unique within the domain "gov". And although in this specific instance "loc" may be globally unique (is it?) I don't think it is wise to adopt that approach in general. Perhaps it would be wiser to adopt the fuller path-name ie "loc.gov"

----------------------------------------------------

I agree that USMARC Codes for Organizations need to be made available for library identification. And this will require a recognized name authority for those codes - 'LC', 'LOC', 'NUC', or something. It doesn't really matter what form the 'namespace' takes. But it is important to maintain the system-id identification structure described in the (no-longer draft) IPIG Profile: that there is a registry of system-id domains that associates a unique numeric identifier with each domain.

I really hope there isn't a movement to amend the Profile in this regard. We'll never get this effort off the ground if we can't settle on standards and stick to them. We're on the verge of widespread, cross-system interoperability. The last thing we need is a change in the way systems identify each other in cross-system interoperation.

-------------------------------------------------------

I agree with Barb's suggestion that we wait for the Library of Congress to register and I do think that the use of the NUC codes is almost entirely now limited to the printed reference sources. I could argue that many U.S. libraries would prefer to use their OCLC symbol rather than their domain name. What is the advantage of using the domain name over OCLC??

-------------------------------------------------------

I can give you one example where being able to treat the NUC code as an alias symbol would be useful.

Let's say I have a patron-initiated request web form that includes a place for the NUC symbol (in case the user happened to use the printed reference source). If we had stored the NUC symbol as an "alias symbol" in our application's supplier list, then we could correctly match the NUC alias to the appropriate supplier and automatically prompt the correct supplier code in the ResponderSymbol of the ILL-Request. E.g. If the alias symbol is NUC:PaU, then prompt RLG:PAUG as the ResponderSymbol.

We wouldn't use NUC:PaU as a supplier symbol. However, since the NUC symbol is treated as an alias for internal purposes, it could end up being sent out in the recipient aliases unless we explicitly filtered it out (which we will do, if necessary). But as far as I can see, making NUC the legitimate name authority for NUC symbols is useful and doesn't hurt anything, so why not do it?

----------------------------------------------------------

Linda makes a good argument for including the NUC symbols, but I do wonder if it would make better sense to include the aliases in either the library directory (with the whole range of symbols that are not used by Protocol implementations) or simply in the local application? There may be other symbols by which libraries are known and they all would need to be registered! You never know when Mary's super-symbols might come into use! I very much agree that knowing the identify of a specific library is useful, I am only questioning if the Implementors Register is the right locations for storing that info.

----------------------------------------------------------

I'm afraid I don't like NUC as a naming authority, because in Australia the National Library also has "NUC" symbols and this will be potentially confusing. The NUC symbols here have a naming authority of "NLA", so I guess US NUC symbols ought to have a naming authority of LOC or LC.

----------------------------------------------------------

My argument was to be able to use the NUC symbols; if LC is better than NUC as the name authority, that's fine, but I think LOC would *not* be a good choice.

----------------------------------------------------------

Sorry, I'm all for that too, we're just discussing what to call the naming authority and we've both put in our bids for what NOT to call it 8-)

----------------------------------------------------------

Just to say, after digesting all the comments on this issue that Michael (having resurfaced after so long silently lurking (:-)) has probably pin-pointed my problem - and suggested the solution,

that the 'name-spaces' should be in a separate list from that of the ILL implementors.

So I'll have to figure out how to do it.

And we must be careful not to confuse the identifier of a name authority with the library symbols which the name authority has defined. There's only a small number of these name authorities...but thousands of

Being a purist, I would prefer to indicate the agency responsible for the list (i.e. Library of Congress) rather than the list itself (NUC), but I'm not all that pure... But before we make a decision on this, we also have to remember, as Ed reminded us, that LC's NUC is not the only NUC in the world...

_______________________________________

I think that we also need to be a bit cautious here. Those who register a namespace are implicitly taking on two obligations:

1. to manage the namespace and assure that all identifiers are globally unique, and

2. to (someday) manage a name resolution service for the namespace

It's all well and good for a library to want its own namespace but, ultimately, the system ID is "only" an arbitrary string of characters.

_______________________________________