At 05:21 PM 7/5/2005, Stephen Hearn wrote:
>I'd also like to raise an implementation issue which needs to be addressed
>before the proposal can be adequately evaluated. How will the original
>undated or partially dated form be preserved on the authority? Or will it?
>For some systems, having the original form as a 400 reference would make
>automated updating easier; for others, ensuring a continuous identity
>between the person and the LCCN would suffice. Even for systems that could
>use a 400, though, the thought of letting one's system or one's authority
>vendor change less specific undated bib name headings to more specific
>dated headings might give one pause, especially if the proposed updating
>practice is allowed for all personal names. I really doubt that we'll want
>to trust automated processes to handle all the authority issues that will
>result from the proposed change.
Stephen: Thanks for bringing this up. As you are aware, there have been
task forces and committees studying the issue of links for former headings,
whose recommendations I think have yet to be put into effect.
In my own work, I've found great value in preserving the old heading
somewhere, somehow. Instead of describing my current scheme, which works
well enough for many things, I'd like to mention what my next authority
loader will do. (To be put into production within a month, should
everything including our move to Voyager with Unicode (TM) go to plan. To
be made available to other Voyager customers after sufficient
testing.) When reading this description, it may be good to bear in mind
that at NUL we load the entire LC/NACO authority file, not to mention LCSH
and MeSH, into our local authority file, and we do not use an external
authority vendor. When the authority loader notes that any part of a
heading has changed (including tag and indicators), it adds a 688 field to
the local copy of the authority record showing the time and date of the
change, and sometimes the nature of the change as well. (The new authority
loader will initiate heading change requests on its own, in certain
carefully-defined and operator-selectable cases, and pass the remainder
along for review.) Because the 688 field only has subfield $a (well, it
has $5, $6 and $8, but you know what I mean) I've had to come up with my
own conventions for subfield codes.
Here are models of the various types of 688 fields; in these examples,
"<date>" represents the year, month and day from the 005 field of the
Heading changed <date> from: <1XX from previous version of this
record> $5 <local institution code>
Heading coded 'unique' until <date> $5 <local institution code>
Heading coded 'non-unique' until <date> $5 <local institution code>
Heading split <date> from non-unique name: <heading from
pre-overlay version of record identified via LCCN in incoming record's 667
field> $5 <local institution code>
We add subfield $5 to these fields--as we do to all variable fields we add
to an LC/NACO authority record--so they can be carried forward
automatically (unless duplicated) when we receive an update to the record.
Here is a typical example of a changed heading from the 2005/25 names file,
following the first model:
Heading changed 20050614 from: 100:1#: _$a Warwick, Frances Evelyn
Maynard Greville, _$c Countess of, _$d 1861-1933 $5 IEN
Programs such as the cataloger's toolkit for Voyager, when presented with
an authority record bearing such a field, can reverse the translation of
subfield codes and treat this 688 as if it were a reference tracing for the
purposes of identifying candidate bibliographic records to be changed.
This isn't the most elegant solution, and it relies on local programming
for fullest effect; but it allows us to carry on with our work while we
wait for an "official" way to achieve the same end.
Gary L. Strawn, Authorities Librarian, etc.
Northwestern University, 1970 Campus Drive, Evanston IL 60208-2300
e-mail: [log in to unmask] voice: 847/491-2788 fax: 847/491-8306
Forsan et haec olim meminisse iuvabit.