[DCRM-L] OCLC proposal

Manon Theroux manon.theroux at gmail.com
Mon Feb 7 10:43:25 MST 2011


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



More information about the DCRM-L mailing list