[DCRM-L] FW: OCLC "Error Correction" problem?

[Deborah J. Leslie]

Dear Colleagues,

The frightening issue came up in Orlando of OCLC's automatic
abbreviating of field 250, even for records coded dcrb. Appended is the
reply from OCLC on that issue, and on faulty OCLC merging. 

_________________________________
Deborah J. Leslie, M.A., M.L.S.
Head of Cataloging
Folger Shakespeare Library
djleslie at folger.edu
http://www.folger.edu
 


-----Original Message-----
From: Beth Russell [mailto:russell.363 at osu.edu] 
Sent: Tuesday, August 17, 2004 9:30 AM
To: Deborah J. Leslie
Subject: Fwd: RE: OCLC "Error Correction" problem?


Deborah,

FYI. Don't know if you're still interested in OCLC challenges, but these
microform sets for early printed books will continue to be a problem for
OCLC users, I suspect.

Beth



Date: Wed, 11 Aug 2004 13:02:31 -0400
From: "Bremer,Robert" <bremerr at oclc.org>
Subject: RE: OCLC "Error Correction" problem?
To: 'Beth Russell' <russell.363 at osu.edu>
Cc: vanpulis.1 at osu.edu, Patrick Anton Fix <fix.2 at osu.edu>,
 "Westberg,Susan" <westbers at oclc.org>, "Block,Brenda" <blockb at oclc.org>
Original-recipient: rfc822;russell.363 at osu.edu

Hello,
 
These two records were most likely merged via the Duplicate Detection
and Resolution program perhaps as long ago as 1991 when that processing
began.  The problem is that the "microform" record does not have Form
(008/23) coded for a microform, there is no microform GMD in 245, there
is no indication of microform in 300, and no 533.  In addition, the
LCCNs were the same and the other match points used in automated
matching happen to coincide.
 
The fact there was another record input in the 38 million range and
again in the 40 million range that have also been merged may indicate
that someone else realized the same problem and re-input the record for
the original print version, but the coding problems on the "microform"
record lead to the same problem again.
 
Since you brought this one to our attention, I will fix the coding on
the "microform" record to actually represent a microform which would
prevent the problem from happening again in this particular case.
Unfortunately, there is no way at this point to undo a merge that
occurred in the distant past.  Since some other records in the same
microform series have similar coding problems, I will look for those to
fix them as well.
 
Thanks.
 
Robert Bremer
bremerr at oclc.org 




From: "Bremer,Robert" <bremerr at oclc.org>
To: "'overholt at mail.utexas.edu'" <overholt at mail.utexas.edu>
Cc: "Weitz,Jay" <weitzj at oclc.org>
Subject: RE: DCRB and database quality control
Date: Mon, 12 Jul 2004 15:08:10 -0400

Hello,

The QC macro often run on many OCLC records has had restrictions built
in
regarding DCRB and BDRB records from the outset due to differences in
the
rules between AACR2 and those used for rare books. However, field 250
was
overlooked and earlier this year another library brought the problem to
our
attention. That macro has since been adjusted so that it should not
change
field 250 to abbreviate terms that DCRB would have the cataloger
transcribe
as they appear.

The double punctuation issue was one of the initial reasons for adding
DCRB/BDRB restrictions to the macro. If you have a couple of examples
where
we made inappropriate changes related to punctuation, please share them
so
that we can run down the specific cause. When testing, the current
version
of the macro retains the doubled punctuation I have experimented with
when
040 $e is present with either codes "dcrb" or "bdrb".

For edition statements in field 250 that you notice that were
incorrectly
changed, you can report them to us or enhance the record as needed.
Also,
if you notice a more recent DCRB input where we still managed to
incorrectly
deal with field 250 through some means, let us know.

If you have any additional questions or concerns, be sure to let us
know.

Many thanks.

Robert Bremer
bremerr at oclc.org

I wrote back as follows:

"Robert--
Thank you for your reply. In looking at older original or enhanced 
records I have input, through the end of last year, records with a comma
or 
colon of item punctuation preceding the prescribed punctuation in 245 $b

and $c, and 260 $b, have had the item punctuation removed. I don't see
any 
evidence of this in records entered in the last few months, but I wasn't

sure whether this meant that the problem had been fixed or that the
macro 
simply hadn't been run recently. If the macro has been run within the
last 
few months then it would seem that the double punctuation problem has
been 
solved as well.
--John Overholt"