[DCRM-L] OCLC proposal

Tue Feb 8 08:29:24 MST 2011

Me too. A very sensible request. -Ryan

-----Original Message-----
From: dcrm-l-bounces at lib.byu.edu [mailto:dcrm-l-bounces at lib.byu.edu] On
Behalf Of Barrett, Marcia
Sent: Tuesday, February 08, 2011 9:11 AM
To: DCRM Revision Group List
Subject: Re: [DCRM-L] OCLC proposal

I agree.

Marcia

-----Original Message-----
From: dcrm-l-bounces at lib.byu.edu [mailto:dcrm-l-bounces at lib.byu.edu] On
Behalf Of Stephen A Skuce
Sent: Tuesday, February 08, 2011 5:50 AM
To: DCRM Revision Group List
Subject: Re: [DCRM-L] OCLC proposal

I like Erin's suggested change, and I also think we should make the silent
correction to Glenn's message. We all know what he meant, and it's
completely uncontroversial. It's just a typo.

Many thanks to Annie for preparing this! 

Stephen

________________________________________
From: dcrm-l-bounces at lib.byu.edu [dcrm-l-bounces at lib.byu.edu] On Behalf Of
Randal Brandt [rbrandt at library.berkeley.edu]
Sent: Monday, February 07, 2011 7:41 PM
To: dcrm-l at lib.byu.edu
Subject: Re: [DCRM-L] OCLC proposal

And, would it be OK to silently correct Glenn Patton's original email to
read "... 'dcrm[x]' code and its predecessor codes"? He did write "dcrb[x],"
but he *meant* "dcrm[x]".

Randy

On 2/7/2011 11:02 AM, Erin Blake wrote:
Thanks, Annie and Manon! My only suggestion would be to replace “dcrm-“ with
“dcrm[x]” in the title and body (so it more closely matches Glenn Patton’s
quoted message) and spell out what is meant by “these letters” in the
parenthetical remark.

In other words:  . . . “bdrb" or "dcrb" or "dcrm[x]“ (ie., any $e code
beginning with the letters “dcrm”) . . .
   EB.

From: dcrm-l-bounces at lib.byu.edu<mailto:dcrm-l-bounces at lib.byu.edu>
[mailto:dcrm-l-bounces at lib.byu.edu] On Behalf Of Ann W. Copeland
Sent: Monday, February 07, 2011 1:56 PM
To: DCRM Revision Group List
Subject: Re: [DCRM-L] OCLC proposal

Thanks for you suggestions. We are now working with the following draft:

Request to OCLC to protect records coded 040 $e "bdrb" or "dcrb" or "dcrm-"
from all machine mergers.
The RBMS Bibliographic Standards Committee officially requests that OCLC
protect all items cataloged according to 040 $e "bdrb" or "dcrb" or "dcrm-“
(ie., any $e code beginning with these letters) from all automated mergers.
Because the DCRM suite of cataloging rules has been written to include
materials from all periods, not just pre 1801 items, OCLC's current
protection of pre-1801 records offers insufficient protection to the range
of materials likely to be cataloged according to DCRM.
Background information:
In Jan. 2010, OCLC began running duplicate detection software which allows
for machine matches and mergers. OCLC’s Cataloging Defensively Webinar,
"When to Input a New Record in the Age of DDR," encouraged catalogers to
supply edition statements in square brackets when there are true differences
between bibliographic entities that would be matched and merged in the
absence of the MARC 250.

DCRM(B) and DCRM(S) rules, however, do not allow catalogers to supply an
edition statement. The area is a transcription area only. In addition,
trying to devise an edition statement when one is not there is extremely
problematic, especially in the case of concealed editions - closely similar
editions printed from substantially different settings of type - which are
not distinguished as such by the printer and/or publisher but require
separate records.

In a message from Glenn Patton forwarded to the dcrm-l email list by Jackie
Dooley on May 20, 2010, he assured us that :

“OCLC’s Duplicate Detection and Resolution software (DDR) does not merge
records if one of the imprint dates is pre-1800, nor would OCLC staff merge
records in this situation unless it were absolutely clear that the records
represented the same item (but we would be willing to work with someone who
had gone through the effort of working out which were true duplicates and
which weren’t). While the matching software used to load records prepared in
external systems into WorldCat is very similar to that used in DDR, it does
not include the pre-1800 exclusion.  We could consider some more complex
exclusions that would be based on the 040 $e coding (e.g., exclude all with
a ‘dcrb[x]’ code and  its predecessor codes) if the rare book community felt
this would be desirable…  It would be useful to carry forward this
discussion with the rare book community.  Nobody wants to play “fast and
loose” with record merging, but, on the other hand, I don’t think people
really want a situation where there’s no attempt to match at all."
Discussion at the Bibliographic Standards Committee meeting in San Diego in
January included accounts of catalogers reporting duplicate records for
deletion. The rare book cataloging community will continue to report
duplicates in this way.

On 2/7/2011 12:43 PM, Manon Theroux wrote:

Here are my suggestions, Annie:

-- make it clear in the Title that you're only talking about machine

mergers (not "any and all mergers")

-- make it clear what is meant by "dcrm-" (maybe by adding a

parenthetical such as "i.e., any subfield $e code beginning with the

letters dcrm"). Glenn probably knows what you mean but whoever he

hands it off to (the programmers) might not

-- put what the BSC is asking for in the *first* paragraph instead of

the last one; use language that actually does the asking rather than

saying the BSC "decided to ask"; label it as "Proposal" or

"Recommendation" or "Request" or some such thing

-- label the remaining paragraphs "Background Information" or something
similar

Thanks for doing this!

Manon

On Mon, Feb 7, 2011 at 11:57 AM, Ann W. Copeland
<auc1 at psu.edu><mailto:auc1 at psu.edu> wrote:

At the Bibliographic Standards Committee meeting in San Diego, I offered to

draft a proposal to OCLC to omit all dcrm, dcrb and bdrb records from

automatic deduping.  Here is a draft - please send comments. Thank you,

Annie

Request to OCLC to protect records coded 040 $e "bdrb" or "dcrb" or "dcrm-"

from any and all mergers.

In Jan. 2010, OCLC began running duplicate detection software which allows

for machine matches and mergers. OCLC’s Cataloging Defensively Webinar,

"When to Input a New Record in the Age of DDR," encouraged catalogers to

supply edition statements in square brackets when there are true differences

between bibliographic entities that would be matched and merged in the

absence of the MARC 250.

DCRM(B) and DCRM(S) rules, however, do not allow catalogers to supply an

edition statement. The area is a transcription area only. In addition,

trying to devise an edition statement when one is not there is also

extremely problematic, especially in the case of concealed editions -

closely similar editions printed from substantially different settings of

type - which are not distinguished as such by the printer and/or publisher

but require separate records.

In a message from Glenn Patton forwarded to the dcrm-l email list by Jackie

Dooley on May 20, 2010, he assured us that :

“OCLC’s Duplicate Detection and Resolution software (DDR) does not merge

records if one of the imprint dates is pre-1800, nor would OCLC staff merge

records in this situation unless it were absolutely clear that the records

represented the same item (but we would be willing to work with someone who

had gone through the effort of working out which were true duplicates and

which weren’t). While the matching software used to load records prepared in

external systems into WorldCat is very similar to that used in DDR, it does

not include the pre-1800 exclusion.  We could consider some more complex

exclusions that would be based on the 040 $e coding (e.g., exclude all with

a ‘dcrb[x]’ code and  its predecessor codes) if the rare book community felt

this would be desirable…  It would be useful to carry forward this

discussion with the rare book community.  Nobody wants to play “fast and

loose” with record merging, but, on the other hand, I don’t think people

really want a situation where there’s no attempt to match at all."

At ALA Midwinter 2011, the RBMS Bibliographic Standards Committee decided to

ask OCLC to protect all items cataloged according to 040 ‡e "bdrb" or "dcrb"

or "dcrm-“ from machine mergers. Because the DCRM suite of cataloging rules

has been written to include materials from all periods, not just pre 1801

items, OCLC's protection of pre-1801 records offers insufficient protection

to the range of materials likely to be cataloged according to DCRM.

--
__________________________
Randal Brandt
Principal Cataloger
The Bancroft Library
(510) 643-2275
rbrandt at library.berkeley.edu<mailto:rbrandt at library.berkeley.edu>
http://bancroft.berkeley.edu
"It's hard enough to remember my opinions without
remembering my reasons for them"--The Streets.