Skip to main content
OCLC Support

OCLC Expert Cataloging Community Sharing Session minutes, June 2017

Minutes of the OCLC Enhance and Expert Community Sharing Session
ALA Annual Conference
Friday, 2017 June 23
10:30 a.m.-12:00 p.m.
Hyatt Regency McCormick Place, Chicago, Illinois


The ALA Annual 2017 edition of Breaking Through: What’s New and Next from OCLC and the compilation of News from OCLC were distributed. Two items from the latter were mentioned: (1) Attendees were encouraged to apply or refer candidates for an open position as an OCLC Consulting Database Specialist (, “responsible for complex evaluation, modification, and maintenance of data throughout its lifecycle, following appropriate standards and policies;” and, (2) the upcoming installation of the OCLC-MARC Update 2017, which includes the MARC 21 Updates No. 23 (November 2016) and No. 24 (May 2017), scheduled for some time between July and September 2017; an upcoming OCLC Technical Bulletin will announce details.

The floor was then opened for questions, answered by Robert Bremer (Senior Consulting Database Specialist, WorldCat Quality); Shanna Griffith (Database Specialist II); Charlene Morrison (Database Specialist II); Laura Ramsey (Section Manager, Quality Control); Robin Six (Database Specialist II); Jay Weitz (Senior Consulting Database Specialist, WorldCat Quality); and Cynthia Whitacre (Manager, WorldCat Quality).

What are the implications of the decision of Library and Archives Canada (LAC) to use OCLC World Share Management Services as its library services platform and move its National Union Catalogue to WorldCat?

US catalogers consult LAC for Canadian names; Canada will now participate in NACO directly LC/PCC NAF files will have to be reconciled. Canadian French authority records will become a separate file that will eventually become available via OCLC.

What is happening with the request of the FAST Project for the implementation of the X47 fields in authority records?

OCLC must wait for LC and the other NACO participants to coordinate these changes. OCLC will be ready to implement these changes but the NACO nodes must also be ready. The Bibliographic 647 field is part of the 2017 OCLC-MARC Update, so it will be available to the FAST Project much sooner than the set of authority fields.

We downloaded a record with URIs in the LC subject headings but then they disappeared. Does OCLC intend to use them? What is happening here?

We don’t retain the subfield $0 after the heading has been controlled. Once the heading is controlled, the subfield $0 drops off.

Many personal names that could be controlled are not. Could OCLC use a program to control them? 

OCLC does use a program to control them. However, only qualified personal names (that is, those with dates or other distinguishing elements) can be safely controlled on an automated basis. Unqualified personal names are not safe to automatically control without human intervention.

Have you done any research to determine how many would be controllable? If 90% were controllable would that make using a program worthwhile?

No, we haven’t researched this specifically, but even if 90% were controllable, it would still not be a prudent or wise idea. Unqualified personal name headings must be controlled only by a human being conscientiously considering other possible headings.

How is it that headings with dates are not controlled?

When working online, catalogers are encouraged to control any controllable headings. Headings with dates should control automatically after the bibliographic record is available in WorldCat.

In the 776 field, there should be 2 spaces before the subfield $w. The fact that many records have only one space causes problems with searching and retrieval. Can you force catalogers to validate this subfield to assure that both spaces are present?

Records with one space were probably batch loaded and so are not validated.

Could a program be written to insert the second space?

We have been trying to automate as much of the validation as we can, but it is very hard to do. Possibly macros could be written to fix common errors like this.

When I clone an NAF record, the derive still comes up as AACR2. Can it be changed to RDA?

We can add this to our list of things to fix.

We input a 13-digit ISBN and automatically get the 10-digit one also. Why do we still need the 10-digit form? Can’t we get rid of it?

No, some local systems continue to need both.

Could you stop updating “Lawyers $v Fiction” to “Legal stories”? Some stories about lawyers are not legal fiction.

Authority record sh85075764 for “Legal stories” includes a 450 field for “Lawyers $v Fiction,” which means that an access point for the latter will change to the former when controlled. You can make a case for separating these headings and submit the request to the Subject Authority Cooperative (SACO) by following the instructions “Making a New SACO Subject Proposal in Minaret” at

Can LC let us fix typos and other small errors without going through the bib change process?

Many fields in both LC and PCC bibliographic records may be added and/or corrected under Database Enrichment and the Expert Community. Details may be found in Chapter 5 “Quality Assurance” ( in BFAS. Allowing non-PCC participants to edit or add authorized access points, however, would jeopardize the very definition of a PCC record, which is that headings must be backed by authority records.

But my headings are controlled and I’m still not allowed to add them. Can’t you make the validation such that all fields must be controlled?

Not every heading backed by authority records can actually be controlled. Some subject headings, for instance, are backed by pattern headings rather than specific records. And of course, there is always a time interval between the creation of a new heading by a PCC participant and the distribution of the record for that heading to the authority file.

Is there any way to permanently uncontrol a heading that should not be controlled?

Not that we are aware of. The recently-defined Bibliographic and Authority 885 fields, which are part of the OCLC-MARC Update 2017, might offer some assistance in this, however. We’ll have to see what sorts of guidelines are established on the proper use of these fields, but they might provide some options.

I always use the 667 field “Do not confuse with…”; wouldn’t that take care it?

Field 667 can be informative and useful in Authority records, but the field isn’t valid in Bibliographic records.

We find lots of duplicate 520 and 505 fields. Do you keep duplicate 520 and 505 fields when you merge records?

The rules that govern data transfer when records are merged do not allow the transfer of either 505 or 520 when the retained record already has one. In most cases, you have the ability to delete these duplicate fields under Database Enrichment and the Expert Community.

Do we have to report each duplicate separately?

You may report an entire set of duplicate records that should be merged into one record with a single message to or through Action/Report Error. They don’t need to be reported separately.

We are finding FAST headings now that are interfiled with the other subject headings rather than clustered at the end and this is creating confusion.

This has been reported and we are working on a fix.

We are finding vendor records now with UBI subfield $0 in 33X fields. Will OCLC use these fields?

If we did, they would be based on the code in the subfield $b.

There are many duplicate German records in OCLC. Is there any way to merge them?

Report them and we will deal with them as you would any other duplicates you come across. Automated Duplicate Detection and Resolution (DDR) does try to resolve duplicates among records cataloged in the same language according to field 040 subfield $b. There is great variation in German cataloging practices, which may contribute to this problem.

In serials records the first indicators in the 7XX fields are not working properly; the notes they are supposed to generate go away. Is this an OCLC or a local problem?

This sounds like a local issue.

GLIMIR clustering seems useless. Should we get rid of it?

GLIMIR works behind the scenes for improving displays in OCLC discovery systems but in retrospect it may not have been a useful idea for cataloging interfaces. We aren’t able to remove the GLIMIR choice from the Connexion search box because there are not supposed to be any new versions of the Connexion client. At some still undefined point in the future, Record Manager will replace Connexion and it makes little sense to expend time or effort on fiddling with an interface that will be going away eventually.

The GLIMIR box does not work correctly and checks and unchecks itself all the time.

It is certainly an annoyance. When you receive search results that seem to make no sense, making sure that the GLIMIR button isn’t checked should be the first thing you do.

Is there a timeline for the replacement of Connexion?

No. The official word is that “The end-of-life for Connexion has not yet been defined.” We promise that you will be given ample warning ahead of time.

The EBSCO 856 field does not indicate if it is for a specific record.

Please report such records to OCLC at

I know that members are not allowed to correct bibliographic records cataloged in languages other than English, but can we ask OCLC Quality Control to correct them?

If you have the time and the language expertise to make such corrections, you may do so, but please feel free to report them to and we’ll take care of them.

Can you get to Connexion without a PC?

One can use the Connexion browser via any web browser, whether using a PC, a MAC, or other device. Connexion client is available only for the PC.


Announcement: The member merge project is expanding, with four more members. There are now nine participating institutions.

Respectfully submitted by
Doris Seely
University of Minnesota
2017 June 29

With edits by Cynthia Whitacre and Jay Weitz.

2017 July 5