Marking records as duplicates in field 667 or any other field is highly problematic. The reason is that we do not work in one common file, but rather in copies where changed records are transmitted and added or replaced in the master copy at LC with a built-in time delay. A cataloger working in OCLC at 10 in the morning, adds 667 to a record to be deleted and reports that record to LC at the same time. At 2 in the afternoon, an LC staff member deletes the duplicate in the master file. Quick turnaround time on lots of reported duplicates by LC staff is not uncommon. Now a delete record is in queue to be distributed to all the NACO nodes, but a revised version of the very same record is in the OCLC contribution queue. When that updated record arrives at LC the updated record is rejected. Every rejected record requires manual follow-up on the part of OCLC staff to determine if the rejected record needs to be re-contributed or if it contains information that needs to be added to another authority record. I presume the same is true for other NACO nodes.
If bibliographic access points are controlled to the record to be deleted in WorldCat, then changing coding in the corresponding to-be-deleted authority record plays havoc with the access point in the bibliographic record potentially causing it to be uncontrolled. Currently, access points controlled to a deleted authority record are automatically re-controlled to the form of the authorized access point in the retained authority record when the LCCN of the deleted authority record is cross-referenced in 010 $z of the retained authority record. Change the status of the to-be-deleted authority record ahead of its deletion and that automated updating potentially breaks.
The reasons for not doing all of this now are the same as outlined in this old message that Ryan Finnerty pointed out:
http://listserv.loc.gov/cgi-bin/wa?A2=ind0710&L=pcclist&T=0&P=3013
Robert Bremer
[log in to unmask]
-----Original Message-----
From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Frank, Paul
Sent: Friday, November 21, 2014 7:46 AM
To: [log in to unmask]
Subject: Re: [PCCLIST] 667 for deletes
Adam,
These are the types of issues I will discuss with colleagues in the Policy and Standards Division, and I will take your suggestions as well for PSD's consideration. For now, though, please just let the 667 note serve as the delete notification-- your wording is fine, but as long as the field indicates that the record is being reported for deletion, other wording is ok, too. We will definitely add an example with suggested wording to the 667 instruction in DCM Z1 once the issue has been discussed and finalized.
Paul
Paul Frank
Acting Coordinator, NACO and SACO Programs Cooperative Programs Section Cooperative and Instructional Programs Division Library of Congress
101 Independence Ave., SE
Washington, DC 20540-4230
202-707-1570
[log in to unmask]
-----Original Message-----
From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Adam L. Schiff
Sent: Thursday, November 20, 2014 8:03 PM
To: [log in to unmask]
Subject: [PCCLIST] 667 for deletes
I've informed our staff that I will start using the 667 for records to be deleted, and that they may see them on other records as well. I think it might be nice to have some kind of standardized wording. Something like this perhaps?:
667 Record reported for deletion. Use instead: <LCCN of record to use>
The one other thing that I would like to raise is whether there is some place else in the record where we can code the fact that the NAR is not to be used, so that catalogers using OCLC's control headings feature would not be able to control an access point that linked to the NAR about to be deleted? There are undoubtedly many catalogers that simply control headings without actually viewing a name authority record. If they don't view it, they won't see the 667 note. Is there some code we can add (heck, we're already adding the 667 note now) that would prevent that NAR from being used by the control software? Maybe changing 008/14 (Name use) from "a" to "b"? Or 008/33 (Auth status) to "n"?
I realize that all of this would be optional, but if a cataloger wanted to code the record as invalid in addition to the 667, may they?
Adam Schiff
**************************************
* Adam L. Schiff *
* Principal Cataloger *
* University of Washington Libraries *
* Box 352900 *
* Seattle, WA 98195-2900 *
* (206) 543-8409 *
* (206) 685-8782 fax *
* [log in to unmask] *
**************************************
|