Merging duplicate books records: A field-by-field comparison

Rare Materials (pre-1830)

 Note: Catalogers unfamiliar with rare books and rare book cataloging rules should not merge bibliographic records for either original rare materials or their electronic reproductions. When considering the merging of records for electronic reproductions of rare materials, take into account the additional electronic resource guidelines in Appendix A.

Books that are published prior to 1830 are by default considered rare. However, rare book cataloging rules can be applied to books regardless of date of publication, and any book cataloged according to such rules should be considered rare. Rare book cataloging rules are coded in the 040 subfield $e (e.g., bdrb). The full list of descriptive conventions is: amin, amremm, appm, bdrb, cgcrb, cco, dacs, dcarlisnaaf, dcgpm, dcrb, dcrmb, dcrmc, dcrmg, dcrmm, dcrmmss, dcrms, dcrmr, dmbsb, enol, estc, fiafcm, gihc, hmstcn, iosr, kam, nmxcmdf, ohcm, rad, rna, rnab, vd16, vd17.

Records may be considered duplicates regardless of the absence or presence of the 040 $e. Determine the record to be retained based on the following guidelines, taking into account the Merge Field Transfer and Merge Matrix document:

• If one of the records is coded as rare in the 040 $e and the potential duplicates are not, but it is evident from all fields (including note fields) that they represent the same manifestation, merge and retain the record coded as rare in the 040 $e
• If the records are encoded using the same rare cataloging rules in the 040 $e, compare all records (including note fields) to determine whether or not they are duplicates and, if appropriate, merge, retaining the most complete record (based on content, not holdings)
• If the records are encoded  using different rare cataloging rules, and are of equal fullness, retain the record coded for the most recent cataloging rules (that is, prefer dcrmb over dcrb, and dcrb over bdrb)
• If the records are encoded using different rare cataloging rules, and are not of equal fullness, transfer information from the more complete record(s) to the one with the most recent cataloging rules
• If none of the records are coded as rare, compare all records (including note fields) to determine whether or not they are duplicates and, if appropriate, merge, retaining the most complete record (based on content, not holdings)

In all cases, be aware of fields that will not auto-transfer during the merge process and manually transfer these as appropriate, such as unique 510 fields, or fields containing copy-specific information, which include subfield $5.

Specific exceptions for rare books are noted throughout this document.

2.1. 010

• Records may be merged regardless of the absence or presence of a 010 field. Records with a difference in control numbers issued by the same agency may be potential duplicate records. Compare fields 245 through 5xx to justify a merge.
• Do not merge two DLC records with different LCCNs if neither is ELvl "J", report these to AskQC. Otherwise, add the LCCN from the ELvl "J" record in a subfield $z to the 010 field of the retained record.

2.2. 006 and 007

• Records may be considered duplicates for merge even with the absence or presence of field 006 or 007. Compare fields 300, 500, and 533 to justify a merge.
• Specific differences in the physical format of the item may justify leaving the records separate.

2.3. 020

• Make sure they match. But be aware that multiple ISBNs may apply to the same item. A different ISBN alone does not justify separate records. The records could still be potential duplicates to be merged. Conversely, the same ISBN in different records does not necessarily justify a merge. Publishers sometimes assign the same ISBN to different manifestations. Compare fields 245 through 5xx to justify a merge.

2.4. 1XX

• Records may be considered duplicates for merge even with the absence, presence, or difference in choice or form of the 1xx field. However, be careful of reversed order of names (see AACR2 21.6C1 and RDA 6.27.1.3).
  
  Example:
  100 1  Rosenbaum, Michael, $d 1972-24510 Working on the set of Smallville / $c by Michael Rosenbaum and Tom Welling.700 1  Welling, Tom, $d 1977-
  
  DOES NOT MATCH
  
  100 1  Welling, Tom, $d 1977-24510 Working on the set of Smallville / $c by Tom Welling and Michael Rosenbaum.700 1  Rosenbaum, Michael, $d 1972-
   
• These records would not be considered candidates for merging because we do not have the items in hand and therefore cannot be sure what the title page of each item looks like.
• If an author changed his or her name it is okay to merge. Retain the authorized form of name.
• Always consult the authority file for the authorized form of the name.

2.5. 245

• Transcribed information in subfield $a and subfield $b should match exactly. Subfield $n and subfield $p are cataloger's interpretation - *use judgment.
• It is usually okay if one has subfield $b and the other does not. Different cataloger decisions regarding where the title proper ends do not disqualify records from being merged.
• Subfield $c, if present, should have same name(s).
• Two records can be merged if there is an error in the transcription of the title and it is clearly a typo as opposed to an alternate spelling (e.g., color vs. colour) on the source.
  
  Rare books: In some cases, subfield $a will not match exactly due to cataloger's judgment, language skills, and transcription rules. Differences in transcription of the letters I/J/U/V, ligatures, and expanded vs. unexpanded brevigraphs do not disqualify records from merging. Early printed materials often contain misprints. Catalogers should confirm that typos are truly errors in transcription through consulting reference sources, contacting other owning libraries, and/or other means, as appropriate, prior to merging. If in doubt, do not merge.

2.6. 250

• Transcribed information should match but allow that practices regarding abbreviation have changed over time. Statements supplied by the cataloger under provisions of RDA 2.5.1.4 (or AACR2 1.2B4) may vary because they are supplied, but if their essence is the same, they are considered matches.
• You may merge if one says 1st edition and other says nothing. However, do not merge if one says 2^nd edition, or 3^rd edition, etc. and the other has no edition statement.
• Compare 245 through 5xx for other differences to justify a merge.

2.7. 260 and 264

2.8. 300

2.9. 490

• Guidelines regarding series retention can be found in the Record Merge Field Transfers document.
• Records may be considered duplicates for merge even with the absence or presence of the 490 field.
• Examples of situations that may justify a merge. Use judgment.
  • Variation in form of series statement
  • Variation in tracing decision or form (e.g., 490 vs. 490 with 830)
  • Absence, presence, or difference in series statement of responsibility
  • Change of series among issues or parts of a serial or multipart item. Do not merge if the item is issued in a different series.

2.10. 5XX

• 5XX fields do not automatically transfer when merging records. Take care to copy all relevant notes into the record being retained before merging.

2.11. 501

The use of field 501 implies that there must be separate bibliographic record(s) for the resource(s) described following "With:" and that when all of those records are considered together, they describe the complete resource. If cataloged correctly, each of those records would describe only part of the complete resource, a fact that would be reflected in the 300 field.

• Records may be merged regardless of the presence or absence of fields 501 only if they represent the same complete resource, with fields 300 matching (according to the field 300 criteria) and all constituent parts of the resource being accounted for in fields 245, 505, and or 1XX/7XX
• In current cataloging, field 501 is primarily for rare, historical, and other special materials
• Field 501 would not properly be used to show local binding practice and does not justify a separate record in such cases

2.12. 510

• Do not merge records with conflicting citation entry numbers.
  
  Example:
  
  100 1  Shakespeare, William, $d 1564-1616.
  
  245 14 The most excellent and lamentable tragedie, of Romeo and Iuliet. $b As it hath beene sundrie times publikely acted, by the Kings Maiesties Seruants at the Globe.
  
  260    London : $b Printed [by William Stansby] for Iohn Smethwicke, and are to bee sold at his shop in Saint Dunstanes Church-yard, in Fleetestreete vnder Dyall, $c [1622]
  
  300    [88] pages ; $c (4to)
  
  510 4  English short title catalogue, $c 111191
  
  DOES NOT MATCH
  
  100 1  Shakespeare, William, $d 1564-1616.
  
  245 14 The most excellent and lamentable tragedie, of Romeo and Iuliet. $b As it hath beene sundrie times publikely acted, by the Kings Maiesties Seruants at the Globe.
  
  260    London : $b Printed [by William Stansby] for Iohn Smethwicke, and are to bee sold at his shop in Saint Dunstanes Church-yard, in Fleetestreete vnder Dyall, $c [1622]
  
  300    [88] pages ; $c (4to)
  
  510 4  English short title catalogue, $c 111193

2.13. 533

• Do not merge if one record has a 533 field and other does not, unless the records represent electronic resources or print-on-demand and photocopies.
• Some older records have 533 information in a 500 field.
• Do not merge if the series differ.
• Make sure type, place, and agency of reproduction matches.

2.14. 6xx

• Records may be considered duplicates for merge even with the absence, presence, or difference in 6xx fields.
• Consider all 6xx field, including 655, in duplicate records, and determine which will need to be retained by transferring manually.

2.15. 7xx

• Records may be considered duplicates for merge even with the absence, presence, or difference in 7xx fields.

Merging WorldCat Collection Set (formerly Major Microform) Records in Connexion Client

WorldCat Collection Sets (formerly Major Microform, MMF) are collected bibliographic records created by either OCLC catalogers, OCLC member libraries, or vendors for sets of microform, non-microform, or electronic content.

• If you are merging a Collection Set record to a Collection Set record and they represent the same item, from the same set, filmed in the same place on the reels, REPORT THOSE TO ROBERT BREMER at bremerr@oclc.org. If unsure whether the record is part of a collection set, do not merge and report to Robert Bremer.

Merging Major Microform Records (MMF) in Connexion Client

• Two MMF records can be merged even when the polarity differs, i.e., one is positive and the other is negative.
  • Normally, retain the master negative version and remove the word negative from the 533 field. There will probably be a 500 note stating that the master copy is held by institution XXX.
  • Transfer the 007 field from the merged record. You will then have two 007 fields. The first one will be coded positive (007 $d a) for the service copy and the second one will be coded negative (007 $d b) for the master
• If you are merging a MMF record to a MMF record and they represent the same item, from the same set, filmed in the same place on the reels, report those to Robert Bremer.
• You can merge a member record to a MMF record. You don't need to report it.
  • Duplicate MMF records can be merged if they represent the same item from the same set, and are filmed in different places on the reels (i.e., the 533 $f number and the 830 $v will differ). Add a subfield $n to the 533 field that says subfield $n also filmed as [different reel and number] and add a subsequent 830 to match.
    
    Example:
    
    MMF record #1 contains:
    533    $f (American architectural books ; reel 27, no. 374)
    830    American architectural books ; $v reel 27, no. 374.
    
    MMF record #2 contains:
    533    $f (American architectural books ; reel 27, no. 376)
    
    After Merge:
    533    $f (American architectural books ; reel 27, no. 374). $n Also filmed as no. 376.
    830    American architectural books ; $v reel 27, no. 374.
    830    American architectural books ; $v reel 27, no. 376.

Merging SCIPIO Records in Connexion Client

SCIPIO: Arts and Rare Book Sales Catalogs is the online union catalog of auction catalog records.

SCIPIO records describe art auction and rare book catalogs for sales from the late sixteenth century to scheduled auctions not yet held, and are the result of incorporating the SCIPIO database, formerly available from RLG (Research Libraries Group), into WorldCat during the integration of RLG into OCLC in August, 2007.

• These records can be identified by the authentication code 'scipio' in field 042 subfield $a in the WorldCat and institution record(s)
• Retain the SCIPIO record when merging duplicate records and one is NOT a SCIPIO record
  • EXCEPTION: If one of the records is PCC, retain the PCC record. Add $a scipio to the 042 field of the retain PCC record and manually transfer all SCIPIO-specific data.
• Retain the most complete, based on content NOT number of fields, when all records involved are SCIPIO records

Firefly Books and Annick Press

Firefly Books and Annick Press publish items in both Canada (usually Toronto) and New York (usually Buffalo). Due to Canadian copyright depository library reasons, the Library and Archives Canada (symbol NLC) list the Canadian place of publication but not the New York place of publication, which consistently appears first on the title page verso.

Library and Archives Canada (symbol NLC) is following a local practice for these WorldCat records, and they may be merged if all other criteria match.

     Examples:

     260    Buffalo, N.Y. : $b Firefly Books, $c 2000.

     MATCHES

     260    Toronto : $b Firefly Books, $c 2000.

     260    Buffalo, N.Y. : $b Annick Press, $c 1995.

     MATCHES

     260    Toronto : $b Annick Press, $c 1995.

Guidelines for Comparing LC PCC and Member PCC Records

• Both records will have 042 field 'pcc'
• If the records are determined to be duplicates, retain the most complete record based on content, NOT the number of fields

UKM CIP (Cataloging-in-Publication) Guidelines

UKM CIP records are either encoding level 8 pre-publication records, or encoding level M records with symbol UKMGB, created by the British Library. UKMGB are newer records. Consider UKMGB as equivalent to encoding level 8 if they have "p. cm" or "pages cm" in the 300 and have a 263 field.

There are looser criteria for merging UKM CIP records with other records. These records usually contain variations in fields 245, 260 subfield $a and subfield $c, 300, and the 4xx fields.

• The 300 fields, if present in encoding level 8 records, are pre-publication estimates and should not be interpreted as actual paginations and sizes. This field is often incomplete or still blank, i.e. 300 p. cm.
• The 260 or 264 subfield $a, place of publication, is another field that will usually differ. In most instances, this is not a factor and the records can be merged.
  
  Example: UKM CIP and UKM full level records each contain a place of publication with the difference being the country of publication and they both clearly represent the same item (same ISBN for example); these can be merged with no question.

Vendor Records

There are looser criteria for merging records from vendors that are less-than-full level (encoding level 3, M, K, etc.). They are very brief in content; usually consisting of a title, publisher, date, and ISBN.

These records are candidates for potential merging with other records.

Please refer to the Vendor List for Merging document for a list of the vendors and additional guidelines for merging.  

WorldCat Digital Collection Gateway Records

Digital Gateway records provide access to a library's unique, open-access digital content collections. These records will have a 042 field 'dc' (Dublin Core) and a 029 field with subfield $t DGCNT.

These records are not considered candidates for merging.

Hybrid Print/Online Records

Sometimes minimal level or batch level records will have elements of a print monograph and elements of an online resource. Carefully examine the hybrid version record to determine whether to merge it into the print version or the online version record. To resolve this situation, take the following steps:

• Look at the encoding level of the record.
• Look at the coding of Form in the fixed field.
• Look at the GMD if present or the 33x fields.
• Look at the second indicator in the 856 field.
• Look at the inputting library's or a few holding libraries' local records.

Note that some print records reflecting the single record approach will have a 007 field and a 856 field with a second indicator 1. This type of record is not considered a hybrid; it represents a print resource.

After analyzing a hybrid version record with a 019 field, if you think that a bad merge could have occurred, email your reviewer.  

Guidelines for Google Books and HathiTrust Records

These are records that represent digitized books from the Google Books Library Project and HathiTrust Digital Library.

• Both have input symbols of OCLCE.
• The HathiTrust record will have 042 field 'dlr' (Digital Library Registry)

In general, follow the instructions in the Record Merge Field Transfers and Merge Matrix document when deciding which record to retain.

• If a HathiTrust record and a Google record are determined to be duplicates, always keep the HathiTrust record with the 533 field.
• If two "dlr" records (i.e. HathiTrust and Biodiversity Heritage Library) are determined to be duplicated, retain the most complete and make sure that fields with unique subfields $5 transfer. Also adjust the OCLC control number in the 776 field of the print record so that it points to the electronic record that is retained if needed.
• If a HathiTrust and a member-input record are determined to be duplicates, retain the most complete and make sure that fields with unique subfields $5 transfer. If HathiTrust and other digital preservation records are merged into another record, then be sure that the following fields transfer to the retained record: 042, 506, 533, 538, 583, and 856. Also, if needed, adjust the OCLC control number in the 776 field of the print record so that it points to the electronic record that is retained.
• If a HathiTrust and a member-input record are determined to be duplicates and otherwise seem equivalent, retain the HathiTrust record. 

Fields 506, 533, 538, and 583 with subfield $5 will transfer when $5 is unique. Field 042 dlr will transfer if one of the 5xx fields with $5 transfers.

For all non-preservation records, delete the 533 field if it appears in the retained record.

Note that most preservation 533 fields contain subfield $5. However, some older preservation records contain 533 fields that lack subfield $5.

4.1. 006

• For online resources, Form is coded "o".
  
  Example:
  
  Type: m     Audn:     Form:o     File: d     GPub:

4.2. 007

• Accept as is if the required subfield $a and subfield $b are coded correctly.
  
  Example:
  
  007  c $b r

4.3.  020

• If other version ISBNs exist in subfield $a, then move them to subfield $z.
  
  Example:
  
  020  $z 9781423181736

4.4. 300

• Delete subfield $c, if it exists in the record.
• For records cataloged in English (e.g., 040 $b is coded eng) add "1 online resource" to the subfield $a if absent from the record, placing the existing subfield $a in parenthesis.
  
  Examples:
  
  300  1 online resource (xv, 223 pages) : $b illustrations
  300  1 online resource : $b illustrations

4.5. 588

• If two "Description based on" notes appear in the retained record, delete the one likely carried over from the print version record in favor of the one indicating that the print record was used as the basis of the description. Note that RDA uses the phrase "Identification of the resource based on" contrary to LC/PCC practice.
  
  Examples:
  
  588    Identification of the resource based on print version record.
  588    Description based on online resource; title from pdf information screen (Ebsco, viewed November 19, 2013).

4.6. 776

• Retain only one 776 link to one print version record. If there is more than one on a record delete the 776 representing the duplicate print version record. 
• If the 776 is incomplete, fill in the needed information by using the "Insert from cited record" command. To use this command, make sure that the OCLC# to the correct print version record is the only information in the 776 subfield $a and right click on the field.
  
  Example:
  
  776 08 ǂc Original ǂz 9780199657803 ǂz 0199657807
  
  Edit to: 776 08 835969170
  
  Then use the "Insert from cited record" function
  
  

4.7. 856

Please also see MARC Standards Office: Guidelines for the use of field 856² for more information about this field.

• Make sure that the second indicator is 0 if the URL links directly to the resource in records describing online items
• Make sure that the URLs in the retained and the duplicate link to the same resource
• Move all URLs that link to other resources to the appropriate record if available. If an online version record is not available, add that link to the corresponding print version record using second indicator 1.
• Delete all institution specific URLs that require a logon. These can be identified because the URL to the main resource is often hidden in the institution specific link.
  
  Example: http://encompass.library.cornell.edu/cgi-bin/checkIP.cgi?access=gateway_standard%26url=http://dx.doi.org/10.1787/9789264061453-en

While you are not required to check all URLs when merging, if you discover a broken URL please use the following guidelines:

• Correct the URL if possible
• If the URL cannot be corrected and other URLs exist on the record, delete the URL. If you cannot access the URL and cannot tell if it is broken, then do not delete the URL.
• If the URL cannot be corrected and no other URL exists on the record, add the broken link to $h
  
  Example:
  
  856 40 $h [broken URL]