Print

Print


I also recommend to our cataloguers that they wait a day or two. Otherwise we run the risk that data that we have added to the record to be kept (046, 3XX, 400, 667, 670) will be overwritten, when the LC cataloguer adds an 010 $z to that record before our changes have arrived.


Regards
Richard

________________________
Richard Moore
Authority Control Team Manager
The British Library

Tel.: +44 (0)1937 546104
E-mail: [log in to unmask]<mailto:[log in to unmask]>



From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Hostage, John
Sent: 09 January 2018 22:03
To: [log in to unmask]
Subject: Re: [PCCLIST] 667 to indicate report for complex correction or cancellation

Even though I haven’t been routinely adding a 667 to the record to be deleted, I still wait a couple of days before reporting it so the person at LC can see that I added the necessary 670s and references to the record to be kept.  That prevents the kind of overlap described here, not that I’ve ever seen such quick response time that it would be a problem.

------------------------------------------
John Hostage
Senior Continuing Resources Cataloger
Harvard Library--Information and Technical Services
Langdell Hall 194
Harvard Law School Library
Cambridge, MA 02138
[log in to unmask]<mailto:[log in to unmask]>
+(1)(617) 495-3974 (voice)
+(1)(617) 496-4409 (fax)
ISNI 0000 0000 4028 0917

From: Program for Cooperative Cataloging [mailto:[log in to unmask]]<mailto:[mailto:[log in to unmask]]> On Behalf Of Bremer,Robert
Sent: Tuesday, January 09, 2018 16:21
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [PCCLIST] 667 to indicate report for complex correction or cancellation

Here’s what I wrote back in Nov. 2014:

“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.”

Back to 2018—the current discussion is based on indications that LC’s work on getting the reported records deleted now takes significantly longer than my past characterization of a “quick turnaround” in 2014.  If so, that lessens the possibility of clashes between records modified to add the 667 with actual deletions of the same records being distributed to all the NACO nodes on the same day.  But, the addition of the 667 by a NACO participant and the deletion of the duplicate by LC on the same day remains a possibility that requires a manual follow-up to determine why the contributed record was rejected.

So, just in my opinion only, I am not convinced that it is worth the effort to add the 667, but I don’t necessarily have strong objections at this point.

Robert Bremer
Senior Consulting Database Specialist
OCLC
[log in to unmask]<mailto:[log in to unmask]>

From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Cuneo, Mary Jane
Sent: Tuesday, January 09, 2018 8:32 AM
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: [External] Re: [PCCLIST] 667 to indicate report for complex correction or cancellation

This was discussed on the PCCList (November 2014, and maybe in 2015).  Most seemed to like the idea, but Robert Bremer indicated that marking the records in this way would cause significant problems related to record distribution and the controlling of headings.  As John points out, PCC policy for fixing undifferentiated personal name records now requires the same kind of 667 that we’re contemplating for general use in duplicate reporting.  I would be interested to know what Robert’s latest thinking is on this, based on what he is seeing.  (Robert, are you reading?)

Mary Jane Cuneo
Serials cataloging and NACO
Information and Technical Services
Harvard Library

From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Hostage, John
Sent: Monday, January 08, 2018 8:46 PM
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: 667 to indicate report for complex correction or cancellation


I think this is a good idea.  We already have procedures for breaking up undifferentiated names (DCM Z1, 008/32),  so I would suggest building on that and using a note like

"Reported for deletion in favor of [LCCN of NAR]."


------------------------------------------
John Hostage
Senior Continuing Resources Cataloger
Harvard Library--Information and Technical Services
Langdell Hall 194
Harvard Law School Library
Cambridge, MA 02138
[log in to unmask]<../../owa/redir.aspx?C=fff0248a4daa423caadeb2f835259a11&URL=mailto%3ahostage%40law.harvard.edu>
+(1)(617) 495-3974 (voice)
+(1)(617) 496-4409 (fax)
ISNI 0000 0000 4028 0917

________________________________
From: Program for Cooperative Cataloging <[log in to unmask]<mailto:[log in to unmask]>> on behalf of Robert M. TALBOTT <[log in to unmask]<mailto:[log in to unmask]>>
Sent: Monday, January 8, 2018 15:52
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: [PCCLIST] 667 to indicate report for complex correction or cancellation

Folks:

One of the duties that fell into my court oh so many years ago was the reportage of duplicates in the authority file, where it has remained.  I've consequently seen the ebb and flow of response times, and up until recently the deletions always occurred within a reasonable time frame.

"Until recently." Yes, the delay between the time a duplicate or error is reported and the moment the dupe is cancelled/ error corrected has moved from days to months.  A casual glance in my  "pending" file shows unfilled requests for cancellation dating back at least to August 2017.

I am sure that there is a perfectly reasonable explanation  for the delay, and truth be told, even without knowing the exact causes, LC has my sympathies.  No doubt the volume is high and the work thankless. I doubt too that there is an end in sight.

How then do we prevent (or at least alert) others from using the duplicate or from aggravating the identified complex error while we are waiting for a cancellation or remedy?

The whole point of this email:  I think including a 667 within the affected records  would be an obvious choice, something like:

667  Duplicate heading: [actual heading & maybe the LCCN] reported for cancellation [date].

or

667  Record reported for cancellation; it duplicates  [heading & maybe LCCN].  The latter heading should be used.

or

667 Literary number PH3328.21 (range is actually PH3382.21) assigned in error, reported [date].

I don't think this is breaking any new ground.  In fact, I seem to recall that I've seen these sorts of notes once or twice over the years, but who knows?  Maybe I just dreamed it. Still, it seems reasonable to ask before starting to track these things.

So: Is there any reason to not track these sorts of things in a 667?  Perhaps there's a better way to track than a 667?

Any and all responses are welcome.

Thanks & Cheers

Bob

--
Bob Talbott

Principal cataloger/Hebraica cataloger

UC Berkeley

250 Moffitt

Berkeley, CA 94720

I'm just mad about Saffron


******************************************************************************************************************
Experience the British Library online at www.bl.uk<http://www.bl.uk/>
The British Library’s latest Annual Report and Accounts : www.bl.uk/aboutus/annrep/index.html<http://www.bl.uk/aboutus/annrep/index.html>
Help the British Library conserve the world's knowledge. Adopt a Book. www.bl.uk/adoptabook<http://www.bl.uk/adoptabook>
The Library's St Pancras site is WiFi - enabled
*****************************************************************************************************************
The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the [log in to unmask]<mailto:[log in to unmask]> : The contents of this e-mail must not be disclosed or copied without the sender's consent.
The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author.
*****************************************************************************************************************
Think before you print