When a bibliographic record is added, modified, or deleted on a local catalog, the record is also transmitted to the OhioLINK Central Catalog in real time. The system uses the following procedure to match and integrate bibliographic records.
In January 2012, OhioLINK contracted with Innovative Interfaces to install an enhanced matching algorithm. The matching process consists of three components:
Matchpoints
Site/record number search: To determine whether this record has been previously transmitted from this library, the system looks for a combination of the library site code and the bib record "B" number from the local system.
New record: If this record is new from this library, then the sytem proceeds to additional matchpoints. This list is processed in order until a candidate match is found:
- 001 — record control number, such as OCLC number
- 919 — SkyRiver number
- 010 — LC card number
- 020 — ISBN
- 022 — ISSN
- 024 — other standard number
- INN-Reach 110character matchkey (for details, see INN-Reach manual, page # 106379)
If a match is found, the software proceeds to the validity check.
If no match is found, the incoming record is added to the Central Catalog as a new bibliographic record, and the contributing library becomes owner of the record.
Validity Check
Once two records are identified as candidates that belong together, a series of checks is used to determine if the match is valid. If any one test fails, the records are kept apart. As each test is successful, the system proceeds to the next test. All checks must pass successfully in order for the records to be put together.
| Type of match that has been made |
Type of validity check |
|---|---|
| any |
001: if both records have an 001 field (such as an OCLC number), but the numbers do not match, the records will not merge. Records can merge if one record has an 001 and the other does not. (Records with no 001 display a "z" number in the 001 field, such as "zci3ug b2340950".) |
| any | Large print: if one record has the word "large" in MARC 245 |h, 250, or 300, the other must also be "large" |
| 001, 010, 020, 022, 024 | Title: first 4 letters of the first 3 words in 245 |a |b must match |
| 001, 010, 020, 022, 024 | Imprint: first word in either 260 |a or 260|b must match. Then the first non-bracketed date in 260|c must match. |
| 110matchkey | Imprint: both 260 |a and 260|b must match; the first date in 260|c must match, whether bracketed or not |
| 110matchkey | Author: characters from 100 |a|q|b|c, 110 |a|b|c|d, or 111 |a|q|d|c must match |
If all validity checks pass, the records are considered a successful match.
If any validity check fails, the incoming record is added to the Central Catalog as a new bibliographic record, and the contributing library becomes owner of the record.
ORIGINALLY: We wanted to merge new and old OCLC records (001 in one record matches 019 in another record). Also, we wanted to merge OCLC and non-OCLC records for the same item. For this, we had to allow records merge, even if the 001 fields did not match.
However, because of invalid overlays, we had to turn OFF this feature. That is, we had a return to the requirement that if 001’s do not match, the records are unique.
Record Ownership
When two records have a valid match, the system determines which record will become the master record in the Central Catalog. The goal of the ownership test is to determine when a record contains fuller information.
The tests are applied in the order specified below. If both records meet the criteria or if neither record meets the criteria, the test is successful and proceeds to next test.
As soon as any one test determines a preferred record, that record becomes the master record. The tests do not continue further for the two records in question. If all tests determine that the records are equal, the existing record in the database is retained as the master. Holdings of libraries attached to the non-chosen record transfer automatically to the chosen master record.
The system checks whether the following fields exist in each record:
- 001 — record control number
- 019 — former OCLC number
- 008 — fixed fields
- 6xx — subjects
- 4xx — series
- 8xx — series
- 505 — contents note
- 520 — summary note
- 655 — genre
- 007 — media fixed fields
- 880 — vernacular language fields
If these fields exist in both records, then the system checks Library Load Priority.
| Priority 1 | Libraries that maintain authority control on both LC and MeSH headings |
| Priority 2 | Other OhioLINK libraries that use OCLC for cataloging |
| Priority 3 | Center for Research Libraries records |
| Priority 4 | OhioLINK libraries that do not use OCLC for cataloging |
If load priorities are the same, then the system checks Encoding Level.
| Encoding Group | Encoding Level |
|---|---|
| 10 | blank — Full level (by authorized national bibliographic agencies and libraries) |
| 9 | I — Full level input by an OCLC library 4 — Core level |
| 8 | 1 — Full level, material not examined |
| 7 | L — Non-LC & non-NLM loaded from tape |
| 6 | K — Less than full input by an OCLC library J — Record deleted by LC from MARC file 2 — Less than full level M — Less than full level, tape loaded |
| 5 | 8 — CIP prepublication data |
| 4 | 5 — Partial level 7 — Minimal level |
| 3 | E — System-identified error in LC MARC record W — Warning possible error in LC MARC record 3 — Abbreviated level |
| 2 | U — Unknown Z — Not applicable |
Encoding Level "blank" is sometimes found in non-MARC records, which previously caused some brief records to become master records. The new ownership tests prevent brief records from overlaying full records.
The original matching specifications can be found on the DIAD Policy Team page (login necessary)*.
October 2012
Updated December 2014
