5 Quality Assurance
Chapter contents
5.1 OCLC Member Quality Assurance
5.2 Member Capabilities
5.2.1 General Guidelines
5.2.2 Editing capabilities for non-PCC records
5.2.3 Editing capabilities for PCC records
5.3 National Cooperative Programs
5.4 WorldCat Metadata Quality Activities
5.5 Requesting Changes to Records
5.1 OCLC Member Quality Assurance
Enhance
In 1983, OCLC established the Enhance function in an effort to decentralize quality control responsibility for WorldCat. Until that time, most quality control activity was centered in what is now known as WorldCat Metadata Quality at OCLC. The sole exception to this had been the CONSER Program, the mechanism for updating and correcting serial records.
Until the implementation of Enhance, the only mechanism for changes to non-serial records was reporting by paper change requests or submitting a change request to OCLC via any of the available electronic means so that OCLC staff could make corrections. The initial group of 20 libraries was invited to join the Enhance program in May 1984.
Late in 1985, responsibility for WorldCat quality control was further decentralized with the implementation of the Minimal-Level Upgrade capability. This allowed cataloging full mode authorizations and higher to lock, edit, and replace Encoding Levels K, 7, and (in 1987) M records. In the early years of Enhance, libraries were chosen through a series of application rounds or as special projects. In September 1989, the Regular Enhance application process was opened year-round, regardless of bibliographic format. At the same time, OCLC ceased face-to-face training of Enhance libraries in favor of using the Enhance Training Outline as the major instructional tool.
In 1991, the Database Enrichment capability was implemented, allowing full mode and higher authorizations to add subject headings and call numbers to records. The ability to add 505 contents notes became part of Database Enrichment in August 1992. Also in 1992, it became possible for full and higher authorizations to add 300 physical description fields to CIP records. Allowing Enhance participants to upgrade any CIP record, except for its Encoding level value of 8, was introduced in 1993.
National Level Enhance became a reality in September 1994. This allowed selected Library of Congress (LC) cataloging staff and Program for Cooperative Cataloging (PCC) participants to lock, edit, and replace any record with an Encoding Level of blank, 1, or 8. National Level Enhance authorizations were granted by invitation only, in consultation with the Library of Congress.
Database Enrichment was further expanded in March 1996 when fields 006 and 007 were added, and yet again in August 2002 with the addition of over two dozen 0xx, 5xx, and 6xx fields.
Expert Community
The Expert Community is an expansion of WorldCat record editing capabilities to all full level cataloging users. It was tested as the Expert Community Experiment in 2009. The Experiment resulted in more corrections and additions to WorldCat records and more timely actions to correct record problems. The Experiment was inspired by longstanding requests from members of the OCLC cooperative to be able to do more—and more immediate—upgrading of bibliographic records in WorldCat. The Experiment allowed us to test a "social cataloging" model involving the existing community of cataloging experts who have built WorldCat record-by-record. Interest in such a model grew especially with the launch of WorldCat Local and with the popularity of such other socially cooperative ventures as Wikipedia.
At the end of the experiment later in 2009, the expanded capabilities were permanently added to the full level authorization. OCLC's Expert Community provides Connexion users who have a full level authorization or higher more flexibility in making changes to WorldCat records. Maintenance of WorldCat is shared more equally between OCLC staff and member libraries. The additional capabilities provided are a powerful expansion of those that have been available especially through Database Enrichment since 1991.
Program for Cooperative Cataloging (PCC)
The Library of Congress along with bibliographic utilities and other national library cooperative programs created the Cooperative Cataloging Council in November 1992. This Council created the Program for Cooperative Cataloging in February 1995. The following programs are components of the PCC:
BIBCO for bibliographic record input
BIBCO participants contribute bibliographic records to international databases, meeting or exceeding the elements of the BIBCO Standard Record. BIBCO records include headings backed by complete authority work, both descriptive and subject. The BIBCO core level record standard is provided for reference, but has been retired as a standard for PCC BIBCO records. In 2010, the BIBCO program replaced its “full” and “core” record standards by the single encoding level: BIBCO Standard Record (BSR). The BSR for Textual monographs was implemented on January 1, 2010, and BSRs for other types of materials were implemented October 1, 2010.
CONSER for serial records
CONSER began in the early 1970s as a project to convert manual serial cataloging into machine-readable records and has evolved into an ongoing program to create and maintain high quality bibliographic records for serials. In keeping with its evolution, the name was changed in 1986 from the CONSER (CONversion of SERials) Project to the CONSER (Cooperative ONline SERials) Program. In October 1997, CONSER became a bibliographic component of the Program for Cooperative Cataloging. The CONSER database resides within WorldCat. CONSER members input, authenticate, and modify serial cataloging records in WorldCat. Authentication is the process of approving the bibliographic elements in the record and providing for the record's availability through distribution services and bibliographic products.
NACO for name authority input
The Name Authority Cooperative Project (NACO) was established in 1977 as a result of an agreement between the Library of Congress (LC) and the U.S. Government Printing Office (GPO) to use and maintain a common authority file. With the success of this initial project, LC entered into additional cooperative cataloging projects with many other institutions. The partners in cooperative cataloging efforts eventually developed the Program for Cooperative Cataloging (PCC) to administer these projects, including the Subject Authority Cooperative Program (SACO), the Bibliographic Cooperative Program (BIBCO), and the Cooperative Online Serials Program (CONSER).
SACO for subject authority input
SACO was established to provide a means for libraries to propose new Library of Congress Subject Headings (LCSH) and LC Classification (LCC) numbers. It also allows libraries to submit change proposals for existing subject headings and classification. In 2010, SACO became an institutional membership-based program of the PCC. At that time, current members of any of the other PCC programs were automatically considered to be SACO members. Since 2010, new PCC members interested in participating in the SACO Program are required to submit a SACO application.
For information about the goals of the PCC and/or participating, see the Program for Cooperative Cataloging (PCC).
Duplicate Detection and Resolution (DDR)
OCLC first developed the capability to merge bibliographic records manually in 1983. During the late 1980s and early 1990s, OCLC developed automated Duplicate Detection and Resolution (DDR) software. The original DDR dealt with books format records only. Between 1991 and 2005, DDR merged 1,592,586 book records.
OCLC began working on a replacement to the old DDR software in 2005, when the transition from the PRISM system to the Connexion system meant that the old DDR would no longer be usable. After four years of rigorous planning, careful development, and extensive testing, OCLC put the new software into limited production in May 2009, processing small targeted subsets of WorldCat. Between May 2009 and January 2010, OCLC processed about 500,000 records in this way. The result was the merge of roughly 15,000 duplicates, every one of which was examined individually. Something was learned from every incorrect merge. Records were pulled apart, and the software fine-tuned so that a particular problem would not occur again. One significant difference between the old and new versions of DDR is that the new one works on records in all bibliographic formats, not just books.
Between May 2009 and September 2011, the DDR software made one complete cycle through all of WorldCat, processing over 166 million bibliographic records, resulting in the deletion of 5,126,132 duplicates. DDR has been running since then on a daily basis, processing new and specially selected records that have been updated. For the most up-to-date statistics of the number of duplicates being deleted by DDR, visit OCLC delivers quality .
5.2 Member Capabilities
This section contains general guidelines on member capabilities, including member editing capabilities for both PCC and non-PCC records.
5.2.1 General Guidelines
Types of modifications
Responsibility for metadata quality in WorldCat bibliographic database is decentralized allowing members to modify existing WorldCat records. Members can correct or revise a working copy of a WorldCat record and then replace the record with the edited version.
If you notice errors or omissions after you create a WorldCat record, you can correct them and replace the record, provided it has not been edited to become a BIBCO or CONSER record.
In addition to replacing records created by your own institution, you can also replace non-BIBCO records and non-CONSER records. Program for Cooperative Cataloging (PCC) BIBCO records in WorldCat can be enriched by Non-PCC Catalogers with replace capabilities by adding or editing the fields in the table in section 5.2.3, Editing capabilities for PCC records. Non-PCC Catalogers with replace capabilities cannot enrich Program for Cooperative Cataloging (PCC) CONSER records in WorldCat.
Cataloging instructions
Just as you follow applicable cataloging instructions when adding records to the WorldCat bibliographic database, follow the same standards when modifying data in WorldCat records, whether created by your institution or by other members.
Use the following guidelines:
- Verify that appropriate data elements are present for the encoding level specified for the record. Check tagging, subfield indicators, and coding.
- Verify name access points in the authority file appropriate for the language of cataloging. Name access points must be in the appropriate form.
- You may replace a record after controlling the access points even if no text has changed. Verify that access points were controlled as expected before replacing the record.
- Use current subject terminology whether the record is original cataloging or is being upgraded. Verify subject access points in the authority file appropriate for the scheme or thesaurus.
- You are not required to verify call numbers or subject access points in a scheme that your library does not use
However, do not:
- Change the cataloging source code.
- Alter a record to represent a different bibliographic entity even if the record has no holdings or only your holdings attached. If you are in doubt about whether your item matches the record, do not upgrade the record. Edit it for local use, or, if appropriate, create a new record.
- Assume that your information is correct and the existing record is incorrect if your cataloging differs. If in doubt, report errors. For information on reporting errors see section 5.5, Requesting Changes to Records.
- Change records from one language of cataloging to another. See section 2.6, Language of Cataloging.
- Add descriptive elements in your language of cataloging to a record cataloged in a different language (e.g., do not add English descriptive elements to a record cataloged in French).
- Replace a record solely to change elements that are a result of judgment (e.g., a choice of entry or call numbers).
- Delete data entered by another library unless it is incorrect in substance. For example, you may delete a subject access point that does not apply.
- Delete call numbers or subject access points not used in your library
- Add local information to a WorldCat record
Certain classification choices are recognized to be local decisions. Multiple call numbers in the same classification scheme in the WorldCat record may be appropriate under certain circumstances. See 050-099 Introduction to Call Numbers for more information.
System capabilities
Depending on the level of authorization or role used, you can lock, edit, save, and replace WorldCat records. For more information including the different authorization level capabilities for the Connexion client interface, see OCLC Cataloging Authorization Levels for Record Actions and Upgrades . For more information about Record Manager account roles, see Record Manager account roles .
Locked records
When you lock a record, other users can display it and use it for cataloging, but no one else can lock or replace it. If you attempt to lock a record that is already locked, the system responds with a message that the record is locked by another user. To increase efficiency, OCLC recommends that you edit and replace locked records as quickly as possible.
The system automatically releases locked records in the following cases:
- System or communications failure while a locked record is displayed. Such records remain locked until your session has timed out.
- Inactivity log off while a locked record is displayed
- A locked record in the online save file more than 14 days
- A locked record is deleted from the online save file
Authorization levels or account roles
This table shows the different authorization levels and their relationship to adding and replacing bibliographic records using Connexion.
Authorization level | Lock | Edit | Save | Add Non-PCC records | Replace Non-PCC records | Add BIBCO records | Replace BIBCO records * | Add CONSER records | Replace CONSER records |
Search | ✓ | ||||||||
Limited | ✓ | ✓ | ✓ | ||||||
Full | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |||
Agent | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |||
NACO | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |||
National Enhance | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ||
CONSER | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
* For detailed information on editing BIBCO records, see Enriching BIBCO records.
This table shows the WorldShare Record Manager account roles, which are similar to Connexion's authorizations, and their relationship to adding and replacing bibliographic records.
Account role | Lock | Edit | Save | Add Non-PCC records | Replace Non-PCC records | Add BIBCO records | Replace BIBCO records * | Add CONSER records | Replace CONSER records |
Cataloging Bulk Edit ** | |||||||||
Cataloging Export | ✓ | ||||||||
Cataloging Limited | ✓ | ✓ | ✓ | ||||||
Cataloging Full | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |||
Cataloging National | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |||
Cataloging BIBCO | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ||
Cataloging CONSER | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
Cataloging Admin | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
* For detailed information on editing BIBCO records, see Enriching BIBCO records.
** Used for LBD and LHR processing.
5.2.2 Editing capabilities for non-PCC records
Correcting and enhancing records
With the exceptions noted below, you may add, edit, or delete any field in a non-PCC record, when appropriate.
Type and BLvl changes
In all records, you can locally edit Type and BLvl.
Full-level authorizations (Full, National Enhance, CONSER, NACO) or full-level roles (Cataloging Full, Cataloging National, Cataloging BIBCO, Cataloging CONSER):
- You can change Type and BLvl in less than full records (ELvl coded 2, 3, 4 (without field 042 pcc), 5, 7, K, M)
- You can change Type and BLvl in full-level records you input where your holding symbol is set and there are no other holdings
- You cannot change Type and BLvl in full-level records (ELvl coded blank, 1, 4 (with field 042 pcc), I) or CONSER records, unless the bibliographic format remains the same (e.g., Type : i can be changed to Type : j)
Upgrading records
With full-level or higher cataloging authorizations or roles, you can upgrade records to become full-level records, or you may upgrade abbreviated and partial level records to minimal-level or full-level records. Prefer use of MARC encoding level codes.
Exceptions for editing encoding level with MARC encoding level codes include BIBCO records (i.e., with field 042 pcc) and CONSER records (i.e., with a CONSER code in field 042).
Encoding Level |
Definition | Action | Edit Encoding Level to |
M | Added from a batch process | Upgrade to full level | blank |
blank | Full level | Edit as needed | blank |
1 | Full level, material not examined | Upgrade to full level | blank |
2 | Less-than-full level, material not examined | Upgrade to minimal level or full level | 7 or blank |
3 | Abbreviated level | Upgrade to minimal level or full level | 7 or blank |
4 | Core level | Upgrade to full level | blank |
5 | Partial (preliminary) level | Upgrade to minimal level or full level | 7 or blank |
7 | Minimal level | Upgrade to full level | blank |
Encoding level 8. Prepublication monograph level records, including Cataloging-in-Publication (CIP) program records. With cataloging full-level authorization (Connexion) or full role (Record Manager), you may add or edit any field in these records, but you cannot change the encoding level value itself. Do not edit fields 010, 040, national call number fields (except to modify date of publication if necessary), or field 263 in CIP records. Catalogers with National Level enhance authorization or the Cataloging BIBCO role may change the encoding level and remove field 263.
Non-Latin script fields
Full-level users can add or change non-Latin script fields in full-level WorldCat records. There can be more than one non-Latin script in a single field and/or a single record. Most 1xx-8xx fields and some 0xx fields can have non-Latin script equivalent 880 fields. For a list of fields which can contain non-Latin script data see Control Subfields, subfield ǂ6. For more information, see section 2.7, Character Set.
Replacing records with local information
You can add local information (defined in the table below) as part of the editing that you do before replacing the record. The local information is not added to the WorldCat record as part of the replace transaction, but it is retained in your working copy of the record. If you complete editing before replacing the record you can add your holdings immediately after completing the replace transaction.
Tag | Name |
049 | Local Holdings |
059 | Local Processing Information |
090 | Locally Assigned LC-type Call Number Special condition: For all except continuing resources, 090 is retained if record contains no 050. For continuing resources, 090 is retained if record contains no 050, or if 050 contains a word or phrase instead of a call number. |
092 | Locally Assigned Dewey Call Number Special condition: 092 is retained if record contains no 082. |
096 | Locally Assigned NLM-type Call Number Special condition: 096 is retained if record contains no 060. |
098 | Other Classification Schemes |
099 | Local Free-Text Call Number |
590 | Local Note |
599 | Differentiable Local Note |
690 | Local Subject Added Entry--Topical Term |
691 | Local Subject Added Entry--Geographic Name |
695 | Added Class Number |
696 | Local Subject Added Entry--Personal Name |
697 | Local Subject Added Entry--Corporate Name |
698 | Local Subject Added Entry--Meeting Name |
699 | Local Subject Added Entry--Uniform Title |
790 | Local Added Entry--Personal Name |
791 | Local Added Entry--Corporate Name |
792 | Local Added Entry--Meeting Name |
793 | Local Added Entry--Uniform Title |
796 | Local Added Entry--Personal Name |
797 | Local Added Entry--Corporate Name |
798 | Local Added Entry--Meeting Name |
799 | Local Added Entry--Uniform Title |
84x-87x | Holdings Data Embedded in Bibliographic Records |
896 | Local Series Added Entry--Personal Name |
897 | Local Series Added Entry--Corporate Name |
898 | Local Series Added Entry--Meeting Name |
899 | Local Series Added Entry--Uniform Title |
901-907 | Local Data |
910 | Local Data |
945-949 | Local Data |
956 | Local Electronic Location and Access |
Continuing resource maintenance
With full-level cataloging authorization or higher, you can close-out, link, edit, and/or correct full-level non-CONSER continuing resource records. You cannot enhance or maintain continuing resource records authenticated by CONSER.
CONSER-authenticated records have one of the following codes in field 042:
isds/c | ISSN Canada |
lcac | Library of Congress Children's and Young Adults' Cataloging Program |
lccopycat | LC Copy Cataloging |
msc | CONSER minimal authority application |
nlc | Library and Archives Canada |
nsdp | National Serials Data Program |
nst | New Serial Titles |
pcc | Program for Cooperative Cataloging |
premarc | LC PreMARC Retrospective Conversion Project |
See section 5.3, National Cooperative Programs for more information.
5.2.3 Editing capabilities for PCC records
Enriching BIBCO records
Non-PCC catalogers with replace capabilities can enrich Program for Cooperative Cataloging (PCC) BIBCO records in WorldCat, except CONSER records, by adding or editing the fields in the table below. A BIBCO record has field 042 coded pcc and and encoding level ( ELvl ) coded blank, 1, 4, or 8. The various conditions for adding these fields are given after the table below. For more details on ELvl 8 records, see Upgrading records.
Generally, make all edits needed to PCC records as part of a single replace transaction.
Fields you can add or edit on PCC BIBCO records:
Tag | Add field if not present |
Add another field if already present | Edit if present |
006 | ✓ | ✓ | ✓ |
007 | ✓ | ✓ | ✓ |
008 | ✓ | ||
020 | ✓ | ✓ | ✓ |
024 | ✓ | ✓ if the field has a different value in subfield ǂ2 |
|
027 | ✓ | ✓ | ✓ |
028 | ✓ | ✓ | ✓ |
031 | ✓ | ✓ | ✓ |
033 | ✓ | ✓ | ✓ |
034 | ✓ | ✓ | ✓ |
037 | ✓ | ||
041 | ✓ | ✓ | ✓ |
042 | ✓ if authorized |
✓ if authorized |
|
043 | ✓ | ✓ | |
045 | ✓ | ✓ | |
046 | ✓ | ✓ | ✓ |
048 | ✓ | ✓ | ✓ |
050 | ✓ | ✓ if field 050 already exists, then the added field must have a 2nd indicator coded 4, and all existing 050 fields must have a 2nd indicator coded blank or 0 |
|
052 | ✓ | ✓ | |
055 | ✓ | ||
060 | ✓ | ✓ if field 060 is present, then the added field must have a 2nd indicator coded 4, and all existing 060 fields must have a 2nd indicator coded blank or 0 |
|
070 | ✓ | ||
072 | ✓ | ||
074 | ✓ | ||
080 | ✓ | ||
082 | ✓ | ✓ if field 082 is present, then the added field must have a 2nd indicator coded 4, and all existing 082 fields must have a 2nd indicator coded blank or 0 |
|
084 | ✓ | ✓ if the field has a different value in subfield ǂ2 |
✓ |
086 | ✓ | ||
088 | ✓ | ✓ | |
090 | ✓ if field 050 does not already exist |
||
092 | ✓ if field 082 does not already exist |
||
096 | ✓ if field 060 does not already exist |
||
246 | ✓ | ✓ | ✓ |
300 | ✓ | ✓ | ✓ |
336 | ✓ | ✓ | ✓ |
337 | ✓ | ✓ | ✓ |
338 | ✓ | ✓ | ✓ |
344 | ✓ | ✓ | ✓ |
345 | ✓ | ✓ | ✓ |
346 | ✓ | ✓ | ✓ |
347 | ✓ | ✓ | ✓ |
348 | ✓ | ✓ | ✓ |
370 | ✓ | ✓ | ✓ |
380 | ✓ | ✓ | ✓ |
381 | ✓ | ✓ | ✓ |
382 | ✓ | ✓ | ✓ |
383 | ✓ | ✓ | ✓ |
384 | ✓ | ✓ | ✓ |
385 | ✓ | ✓ | ✓ |
386 | ✓ | ✓ | ✓ |
388 | ✓ | ✓ | ✓ |
490 | ✓ | ✓ | ✓ |
504 | ✓ | ✓ | ✓ |
505 | ✓ | ✓ | ✓ |
506 | ✓ | ✓ | ✓ |
508 | ✓ | ✓ | ✓ |
510 | ✓ | ✓ | ✓ |
511 | ✓ | ✓ | ✓ |
518 | ✓ | ✓ | ✓ |
520 | ✓ | ✓ | ✓ |
521 | ✓ | ✓ | ✓ |
526 | ✓ | ✓ | ✓ |
530 | ✓ | ✓ | ✓ |
538 | ✓ | ✓ | |
546 | ✓ | ✓ | ✓ |
583 | ✓ | ✓ | ✓ |
586 | ✓ | ✓ | ✓ |
600 | ✓ | ✓ if the field added is in a scheme not already present in the record |
|
610 | ✓ | ✓ if the field added is in a scheme not already present in the record |
|
611 | ✓ | ✓ if the field added is in a scheme not already present in the record |
|
630 | ✓ | ✓ if the field added is in a scheme not already present in the record |
|
647 | ✓ | ✓ if the field added is in a scheme not already present in the record |
|
648 | ✓ | ✓ if the field added is in a scheme not already present in the record |
|
650 | ✓ | ✓ if the field added is in a scheme not already present in the record |
|
651 | ✓ | ✓ if the field added is in a scheme not already present in the record |
|
654 | ✓ | ✓ if the field added is in a scheme not already present in the record |
|
655 | ✓ | ✓ if the field added is in a scheme not already present in the record |
|
656 | ✓ | ✓ if the field added is in a scheme not already present in the record |
|
657 | ✓ | ✓ if the field added is in a scheme not already present in the record |
|
658 | ✓ | ✓ if the field added is in a scheme not already present in the record |
|
662 | ✓ | ✓ if the field added is in a scheme not already present in the record |
|
740 | ✓ | ✓ | ✓ |
758 | ✓ | ✓ | ✓ |
765 | ✓ | ✓ | ✓ |
767 | ✓ | ✓ | ✓ |
773 | ✓ | ✓ | ✓ |
775 | ✓ | ✓ | ✓ |
776 | ✓ | ✓ | ✓ |
800 | ✓ | ✓ | ✓ |
810 | ✓ | ✓ | ✓ |
811 | ✓ | ✓ | ✓ |
830 | ✓ | ✓ | ✓ |
856 | ✓ | ✓ | ✓ |
5.3 National Cooperative Programs
Overview
The Program for Cooperative Cataloging (PCC) seeks to increase participation in national programs by lowering participants' cost without lowering cataloging standards and quality. You may be eligible to participate in cooperative programs to improve the quality of WorldCat through the PCC. OCLC provides authorizations (Connexion) and Cataloging or Authorities account roles (Record Manager) to participate in PCC programs. For information about the goals of the PCC, see the PCC website.
BIBCO
The Bibliographic Record Cooperative (BIBCO) program provides for the upgrade and replacement of WorldCat records. OCLC provides authorizations and/or the Cataloging BIBCO account role to participate in BIBCO. Users that have BIBCO capabilities can edit records with PCC coded in field 042 and can also change the Encoding Level for 8 (Prepublication-level CIP) Books format records; however, BIBCO participants cannot edit CONSER authenticated continuing resource records. If you are interested in BIBCO participation, see the BIBCO website.
CONSER
The Cooperative Online Serials (CONSER) program provides for the upgrade and replacement of WorldCat records for continuing resources. OCLC provides authorizations and/or the Cataloging CONSER account role to participate in CONSER. Users that have CONSER capabilities can edit continuing resources records with one of the CONSER codes in field 042. If you are interested in CONSER participation, see the CONSER website.
NACO/SACO
The Name Authority Cooperative (NACO) program allows participants to contribute authority records for agents, places, works, and expressions to the LC/NACO Authority File. OCLC provides authorizations and/or the Authorities LC NACO Name Authority File account role to participate in NACO. Users who have NACO capabilities may add and edit name authority records (NARs) and series authority records (SARs) in the LC/NACO Authority File, may participate in the Subject Authority Cooperative (SACO) program, and may edit BIBCO records. OCLC does not provide authorizations to participate in SACO but NACO libraries are able to submit proposals for additions to the Library of Congress Subject Headings (LCSH), LC Genre/Form Terms (LCGFT), LC Demographic Group Terms (LCDGT), LC Medium of Performance Thesaurus for Music (LCMPT), and LC Classification (LCC) schedules. If you are interested in NACO participation, see the NACO website. If you are interested in SACO participation, see the SACO website.
Edit capabilities
BIBCO and CONSER participants have the following capabilities:
- National enhance (BIBCO) authorization or Cataloging BIBCO account role: You can change Type and BLvl in the formats for which you are authorized as long as the bibliographic format stays the same.
- CONSER authorization or Cataloging CONSER account role: You can change Type as long as BLvl is already coded i or s. You can edit records in any format where BLvl i or s is valid. For more information on CONSER editing capabilities, see the CONSER Editing Guide .
BIBCO and CONSER participants cannot:
- Add, change, or delete field 019
- Add, change, or delete field 029
- Add, change, or delete field 938
- Change field 040 subfield ǂc and subfield ǂd
- Delete a WorldCat record
5.4 WorldCat Metadata Quality Activities
Overview
Metadata Quality at OCLC is responsible for data quality within the WorldCat bibliographic database, knowledge base, and registry. Staff responsible for quality within the WorldCat bibliographic database works with bibliographic and authority records, and merges duplicate bibliographic records. The staff also provides feedback and analysis to OCLC data programs and services. For more information, see OCLC delivers quality .
NACO Activities
As NACO participants, staff creates or modifies name authority records in the LC/NACO name authority file. Staff manually resolves name authority conflicts and revises authorized access points in accordance with RDA. Requests to change name authority records from other authority files will be forwarded to the agency that manages those files.
Automated changes and updates
In addition to DDR, large sets of bibliographic records may be modified to reflect current policy through the use of automated tools. Changes or updates are done on large sets of records through the use of automated tools. OCLC has updated records in WorldCat to incorporate RDA elements such as adding 33x fields, spelling out non-transcribed abbreviations, converting Latin abbreviations to English equivalents, converting dissertation notes in field 502 to multiple subfields, and removing the general material designation (GMD).
Symbols used in automated processing
OCLC adds various symbols when updating, changing, or generating bibliographic records:
Symbol | Name | Definition |
BATCH | OCLC Batch Services | Test symbol used in data sync and previous batchload projects |
OCL | OCLC Inc. | Manual or automated process done by OCLC staff |
OCLCA | OCLC Cascade | Automated process where a controlled authorized access point in a bibliographic record is updated to match changes to the authority record |
OCLCE | OCLC Econtent Synchronization Program |
Automated process where a bibliographic record for an electronic resource is generated from a print resource |
OCLCF | OCLC FAST Project | Automated process where FAST headings are added |
OCLCG | OCLC Quality Control Section 2 | Discontinued project to control personal names with dates |
OCLCL | OCLC LinkedData | Automated process where WorldCat Entities URIs are being added to WorldCat bibliographic records |
OCLCO | OCLC Heading Control Service | Automated process where an access point in a bibliographic record is controlled to match an authority record |
OCLCQ | OCLC Quality Control Section | Manual or automated process done by WorldCat Metadata Quality staff |
OCLCR | OCLC Research | Records created or modified OCLC Research |
OCLCS | OCLC Licensed Content Services | Discontinued project to generate serial records |
Duplicate records
Duplicate Detection and Resolution (DDR) software processes bibliographic WorldCat records to identify and merge duplicates. WorldCat Metadata Quality staff also identifies and manually merges duplicate records. Staff is trained to merge in specialized formats.
To learn more about how to determine whether an existing record matches the resource you are cataloging or whether you should create a new record, see chapter 4, When to Input a New Record.
You can report bibliographic duplicate records to the WorldCat Metadata Quality staff. For more information, see section 5.5, Requesting changes to records for more information.
Field Transfer
Field transfer is complex and takes many MARC elements into consideration. There are several standard sets of transfer rules. Some fields, however, have their own specific rules and/or exceptions. Although records that are candidates for deduplication may be within a set of any size, in practice, they are compared in a succession of pairs. Within the set of records, one is considered the retained record and the others will be merged and deleted.
With that in mind, the terms appearing in the table below are defined as follows:
- First occurrence: the initial instance of the field in a set of records
- All occurrences: every instance of the field in a set of records
- All unique occurrences: every distinct instance of the field in a set of records that meets the specific criteria for that field
- If not present: the field does not exist in the retained record
Below are some conditions that may have an impact on field transfer:
- Type codes (Leader/06 and in some cases 006/00) in both the retained and deleted records
- Bibliographic level (Leader/07) in both the retained and deleted records
- Language of cataloging (field 040 subfield ǂb) in both the retained and deleted records
- Identification as CONSER in field 042 in either the retained or deleted records
- Presence of code dlr in field 042 in either the retained or deleted records
- Identification as being from the National Library of Medicine (NLM) in either the retained or deleted records
- Repeatability status of the field in question
- Presence of that field tag in the retained record
- Number of occurrences of that field tag exist in both the retained and deleted records
- Values of certain field indicators in both the retained and deleted records
- Uniqueness tests that compare the presence, coding, and/or contents of certain subfields in the field
Non-Latin script fields transfer only in a limited set of circumstances:
- The retained record does not contain field 066
- The retained record contains field 041
- The retained record does not contain field 041, but does contain either field 008/35-37 or field 040 subfield ǂb with a MARC language code other than any of the following: baq, cat, dan, dut, eng, fre, fry, ger, ice, ita, nob, nor, por, spa, or swe
- The field meets the criteria for the field referenced in subfield ǂ6 for transferring non-Latin script data
Fields | Transfers | Transfers to CONSER |
006 | all occurrences when the first byte does not match Type fixed field, or first byte of an existing field 006 | no |
007 | all occurrences of this field from the record with the most occurrences, if not present in the retained record | no |
010 | if not present in the retained record | no |
015 | all unique occurrences | yes |
016 | all unique occurrences | yes |
019 | all unique occurrences of field 019 subfield ǂa from all records and the OCLC control number (field 001) from the deleted record are combined into a single field 019 in the retained record | yes |
020 | all unique occurrences; uniqueness is determined by comparing both subfield ǂa and subfield ǂz | no |
022 | the first occurrence, if not present in the retained record | yes |
024 | all unique occurrences; uniqueness is determined by comparing both subfield ǂa and subfield ǂz | yes |
027 | all occurrences, including subfield ǂq, from the record with the most occurrences | yes |
028 | all occurrences | yes |
029 | all unique occurrences; uniqueness is determined by comparing both subfield ǂa and subfield ǂb | yes |
030 | all unique occurrences; uniqueness is determined by comparing both subfield ǂa and subfield ǂz | yes |
031 | all occurrences, if not present in the retained record | no |
033 | all unique occurrences from the record with the most occurrences; uniqueness is determined by the combination of the 1st and 2nd indicators | no |
037 | all occurrences, if not present in the retained record | no |
040 | all unique institution symbols in subfield ǂc and ǂd, which become subfields ǂd in the retained record, when another field transfers; does not transfer if only field 019 and/or field(s) 029 transfer; symbols OCL, OCLCA, OCLCG, OCLCO, or OCLCQ will not transfer | yes |
041 | all unique occurrences from the record with the most occurrences; uniqueness is determined by the 2nd indicator and, if present, subfield ǂ2 | no |
042 | only code dlr; will transfer if not already present and if any of the following fields with subfield ǂ5 transfers: fields 506, 533, 538, or 583 | no |
043 | the first occurrence; if not present in the retained record | no |
045 | the first occurrence, if not present in the retained record | no |
046 | all occurrences, if not present in the retained record | no |
047 | all unique occurrences from the record with the most occurrences; uniquess is determined by the 2nd indicator and, if present, subfield ǂ2 | no |
048 | all occurrences from the record with the most occurrences, if not present in the retained record | no |
050 | the first occurrence of field 050 or field 090, if no field 050 or 090 is present in the retained record; fields 050 and 090 are not permitted in the same record; field 090 is changed to field 050 | no |
052 | all unique occurrences from the record with the most occurrences; uniqueness is determined by the 1st indicator and, if present, subfield ǂ2 | no |
055 | all occurrences, if not present in the retained record | no |
060 | all occurrences of field 060 or field 096 with preference given to numbers assigned by NLM, if not present in the retained record; fields 060 and 096 are not permitted in the same record; field 096 is changed to field 060 | no |
070 | all occurrences, if not present in the retained record | no |
072 | all unique occurrences; uniqueness is determined by the 2nd indicator and, if present, subfield ǂ2 | no |
074 | all occurrences, if not present in the retained record | no |
080 | all unique occurrences; uniqueness is determined by subfield ǂ2 | no |
082 | the first occurrence of field 082 or field 092, if not present in the retained record; fields 082 and 092 are not permitted in the same record; field 092 is changed to field 082 | no |
083 | all unique occurrences, if not present in the retained record; uniqueness is determined by subfield ǂ2 | no |
084 | all unique occurrences; uniqueness is determined by subfield ǂ2 | no |
085 | all occurrences, if not present in the retained record | no |
086 | the first occurrence, if not present in the retained record | no |
088 | see 027 for transfer rules | yes |
090 | see 050 for transfer rules | no |
092 | see 082 for transfer rules | no |
096 | see 060 for transfer rules | no |
257 | all occurrences, if not present in the retained record | no |
258 | all occurrences, if not present in the retained record | no |
300 | the first occurrence, if not present in the retained record | no |
306 | the first occurrence, if not present in the retained record | no |
336 | all occurrences, if not present in the retained record | no |
337 | all occurrences, if not present in the retained record | no |
338 | all occurrences, if not present in the retained record | no |
340 | all occurrences, if not present in the retained record | no |
341 | all occurrences, if not present in the retained record | yes |
344 | all occurrences, if not present in the retained record | no |
345 | all occurrences, if not present in the retained record | no |
346 | all occurrences, if not present in the retained record | no |
347 | all occurrences, if not present in the retained record | no |
365 | all unique occurrences; uniqueness is determined by the text | no |
366 | all unique occurrences; uniqueness is determined by the text | no |
370 | all occurrences, if not present in the retained record | no |
377 | all occurrences, if not present in the retained record | no |
380 | all occurrences, if not present in the retained record | no |
381 | all occurrences, if not present in the retained record | no |
382 | all occurrences, if not present in the retained record | no |
383 | all occurrences, if not present in the retained record | no |
384 | the first occurrence, if not present in the retained record | no |
385 | all occurrences, if not present in the retained record | no |
386 | all occurrences, if not present in the retained record | no |
490 | see 800, 810, 811, 830 for transfer rules | no |
504 | all occurrences, if not present in the retained record | no |
505 | all occurrences from any record with a lower 1st indicator value than the retained record; if the lowest 1st indicator value of the retained record is higher than that of the deleted record, all 505 fields are replaced in the retained record | no |
506 | all unique occurrences; uniqueness is determined by subfield ǂ5; if there is no field 506 in the retained record without a subfield ǂ5, one such field will also transfer | no |
508 | all occurrences, if not present in the retained record | no |
510 | all occurrences of this field with 1st indicator 3 and/or 4 from the record with the most occurrences, if not present in the retained record | no |
511 | all occurrences, if not present in the retained record | no |
520 | all occurrences, if not present in the retained record | no |
526 | all unique occurrences; uniqueness is determined by subfield ǂa and, if present, subfield ǂ5 | no |
532 | all occurrences, if not present in the retained record | yes |
533 | all unique occurrences; uniqueness is determined by subfield ǂ5; fields without subfield ǂ5 will not transfer | no |
538 | all unique occurrences; uniqueness is determined by subfield ǂ5; fields without subfield ǂ5 will not transfer unless the retained record has no field 538 and the Leader/06 position is coded as m | no |
540 | all occurrences, if not present in the retained record | no |
542 | all unique occurrences; uniqueness is determined by subfield ǂa and, if present, subfield ǂ5 | no |
546 | all occurrences, if not present in the retained record | no |
567 | all occurrences, if not present in the retained record | no |
583 | all unique occurrences; uniqueness is determined by subfield ǂ5 | no |
586 | all unique occurrences; uniqueness is determined by subfield ǂ5 | no |
all unique occurrences; uniqueness is determined by 2nd indicator value and, if present, subfield ǂ2 occurrences with 2nd indicator value 4 transfer only when no other fields 600-651 are present in the retained record. If an NLM record is the delete record, any fields 600-651 with 2nd indicator value 2 will replace any similarly coded fields in the retained record. |
yes | |
653 | all occurrences, if not present in the retained record | yes |
654 | all unique occurrences; uniqueness is determined by subfield ǂ2 | yes |
655 | all unique occurrences; uniqueness is determined by 2nd indicator value and, if present, subfield ǂ2 | yes |
656 | all unique occurrences; uniqueness is determined by 2nd indicator value and, if present, subfield ǂ2 | yes |
657 | all unique occurrences; uniqueness is determined by 2nd indicator value and, if present, subfield ǂ2 | yes |
658 | all unique occurrences; uniqueness is determined by subfield ǂ2 | yes |
662 | all unique occurrences; uniqueness is determined by subfield ǂ2 | yes |
751 | all unique occurrences; uniqueness is determined by subfield ǂ2 | no |
752 | all occurrences, if not present in the retained record | no |
753 | all occurrences, if not present in the retained record | no |
758 | all occurrences, if not present in the retained record | yes |
773 | all occurrences from the record with the most occurrences of this field, if not present in the retained record | no |
776 | all occurrences from the record with the most occurrences of this field, if not present in the retained record | no |
788 | all unique occurrences; uniqueness is determined by the subfield ǂe, with the following exception:
fields without subfield ǂe will not transfer |
no |
all occurrences of traced series, if traced series are not present in the retained record; all occurrences of untraced series, if neither traced nor untraced series are present in the retained record; untraced series are replaced by traced series |
no | |
856 | all unique occurrences; uniqueness is determined by the subfield ǂ3 or, if not present, by subfield ǂu; field 856 does not transfer to a CONSER record, with the following exceptions:
|
no |
880 | See non-Latin script field transfer information above this table. | yes |
891 | all occurrences, if not present in the retained record | yes |
938 | all unique occurrences; uniqueness is defined by the combination of subfields ǂb and ǂn | yes |
5.5 Requesting Changes to Records
Overview
You may find a WorldCat record that does not comply with cataloging instructions or OCLC standards. In most cases, you can replace the record to enrich it, upgrade it, or correct errors. In all other cases, you should report errors or omissions to OCLC. See section 5.2, Member Capabilities for more information on replacing records.
You can also correct and modify a retrieved WorldCat record for local use and export the record. Do not replace the WorldCat record if your changes are the result of cataloger judgment or local policy. Do not report such changes as errors. Alternatively, you may create local bibliographic data records to accomodate local information.
If you are unable to replace the WorldCat record, OCLC encourages you to report:
- Duplicate records and incorrect merges
- Type and BLvl code changes
- Non-filing indicator changes
- Correction of name access points
- Inappropriate subject access points
- Other changes, corrections, and additions to bibliographic records that the system will not allow you to change
Non-NACO libraries can submit corrections to existing authority records and request the creation of an authority record. Send authority record requests to authfile@oclc.org.
Requests for bibliographic file maintenance can be submitted to Metadata Quality staff at bibchange@oclc.org.
Final disposition of reports is at OCLC's discretion. OCLC may return reports to the reporting library for clarification or forward the reports to the inputting library or other holding libraries for verification.
Reporting errors
Libraries that are unable to replace WorldCat records can report them to OCLC for correction.
Proof is essential for changes unless there are obvious MARC coding errors, such as subfield codes missing from field 245, tags for fields 260 and 300 are reversed, or a personal name tagged as a corporate body. Title page and publication information, including typographical idiosyncrasies, are taken directly from the item. OCLC often refers questions to the creator of the record and is conservative when evaluating change requests.
The justification for changing a record is the same as that needed to catalog the item originally. In some cases, the justification for a requested change may be any standard classification, descriptive, or subject cataloging manual. When necessary, provide the appropriate guideline or instruction number.
Proving a change is valid includes verifying that the item in hand is the exact item described in the bibliographic record. If proof from the item is required, send clearly labeled images and any pertinent URLs with the error report. Label the pages as:
- Title page
- Title page verso
- Cover, spine, etc., if change involves these areas
- Publication information pages
- Other pages from the item depending on the request, e.g., bibliography pages differ on the item from what is on the bibliographic record
Proof not required:
Report the following | Notes/Examples |
Inappropriately merged records | OCLC may be able to recover inappropriately merged records |
Incorrect Type and BLvl codes | |
Incorrectly coded fixed-field elements | |
Incorrectly formatted call numbers | |
Incorrect forms of access points | Includes those established in the LC/NACO authority file or other appropriate authority file |
Incorrect field tag | |
Incorrect use of a field | |
Incorrectly coded indicators | Includes incorrect nonfiling indicators |
Incorrect or missing subfield codes |
Proof may be required:
Report the following | Notes/Examples |
Duplicate records | Report duplicates for records in all formats |
Incorrect access points associated with a record | A work attributed to the wrong author |
Missing authorized access points | Fields 1xx, 240, 6xx, 7xx, and 8xx |
Missing variable fields and subfields specified as Mandatory or Required if Applicable | |
Bibliographic information missing from records | |
Errors in transcription of bibliographic data | Missing or transposed letters, numbers, words, or punctuation affecting indexing |
Corrections to CIP records that affect retrieval | Titles, authorized access points, subject access points |
Consolidation or separation of records for serials | |
Updating records for serials to reflect the first or latest issue | Ceasing a serial |
Changes to publisher, frequency, numbering, etc., in serial records | |
Missing linking entry fields | Fields 76x-78x |
Data incorrectly modified by automated processes | Patterns of error in records |
Incorrect assignment of subject access points or class numbers |
OCLC encourages members to replace the WorldCat record to enrich it, upgrade it, or correct errors. See section 5.2, Member Capabilities for more information on replacing WorldCat records.
Do not report the following:
- Changes that would, in effect, recatalog the entire record to different cataloging instructions (adding ISBD punctuation to a non-ISBD record or changing the choice of access points)
- Changes to classification numbers caused by revision of classification schedules
- Information needed only to complete field 300 in CIP records
- Insignificant variations in punctuation, capitalization, and abbreviation, including final punctuation in any field or spacing in field 300
- Use of "Basic" coding option or "Enhanced" coding option in field 505
Deleting records
In Record Manager, you can delete a WorldCat bibliographic record created by your institution if you have the Cataloging Full role and the record is not held by your own or other institutions. In Connexion, you cannot delete any bibliographic record. When using either interface, you may request the deletion of bibliographic records in the following categories:
- Locally produced materials such as video recordings
- Records with no holdings (usually requested by the contributing library)
- Special projects/special circumstances, e.g., member library submits vendor records they purchased but did not have the rights to share the records with WorldCat
- Records involving legal matters
- Request indicating the resource was never published
OCLC may remove records with zero holdings from WorldCat from time to time.
Requesting the consolidation of a serial
To determine whether two or more serial records should be represented by one record, apply LC-PCC PSs for RDA 1.6.2 and the LCRIs for AACR2 21.2-21.3.
Request the consolidation of serials by reporting these records to OCLC. OCLC may forward the request involving CONSER-authenticated records to LC. OCLC uses the following criteria when considering requests:
- At least one record must be an RDA or AACR2 record
- Proof must be sent so that variations can be clearly identified (e.g., title, frequency, publisher, and place of publication)
- OCLC normally chooses the record with the earliest coverage dates as the single record to represent the entire run
- When requesting a consolidation, give details of the changes necessary to make the record represent the entire run
- Linked CONSER records and linked records with different ISSNs may reflect valid past practice for treatment of changes in titles and are often not candidates for consolidation
Reporting methods available
You may use the following reporting methods:
- Report errors online:
-
- Connexion client: Take Actions on Bibliographic Records
- Record Manager: OCLC WorldShare Metadata Record Manager User Guide
- Email bibliographic record requests to: bibchange@oclc.org
- Email authority record requests to: authfile@oclc.org
- Complete the WorldCat and Authority Record Quality Control Request form and then:
-
- Submit the form online or
- Mail paper change requests to:
- OCLC
WorldCat Metadata Quality MC 139
6565 Kilgour Place
Dublin, OH 43017-3395
More esoteric questions or requests for advice on cataloging policies, standards, and practices should be sent to askqc@oclc.org.