Library Answers: Los Rios Common Questions

We have encountered a number of cases where a bibliographic record in our system no longer matches the physical item or electronic resource it is linked to. This situation can result from various scenarios.

For the first few years of our Alma implementation, users were able to edit most fields of Network Zone bib records directly in the Metadata Editor (MDE). So there were cases where users changed fields, including OCLC numbers, in ways that made the bib record no longer correct for our holdings. It is no longer possible to edit many critical fields directly, but we still may find cases where these corruptions exist from previous edits.

Even though fields are now locked down from direct editing in the MDE, it is still possible for institutions to change NZ bib record data via import profiles. When an import profile is set to match records in the NZ, if the import profile has an incorrect match method and/or merge rule, it can change the NZ record by, for instance by replacing all fields in the old record with those in the incoming record. In this way even the OCLC number (035) can be replaced.

Detecting problems

We have a few reports that help detect some of these issues. In our Catalog Error-checking Dashboard, one tab labeled "Physical/Electronic Mismatch" contains a report that list records with a physical resource type that are linked to electronic portfolios, and another that lists records with an electronic resource type that are linked to physical items. In most cases this will happen because a bib record got changed; for instance, the match method was ISBN-based and the merge rule overlayed the old record with the incoming record's fields setting resource type (008, 035 etc.). In a few cases there is nothing to fix. If a print book comes with accompanying media (e.g. DVD-ROM), the resource type may show as electronic in Analytics.

Another tab in the report shows NZ-linked records that lack OCLC numbers. This report helps us find records that have had their OCLC numbers stripped out by badly configured import profiles. In some cases, records might turn up in this list because we ordered them recently but GOBI's bib record did not include an OCLC number. When we receive the item, we will need to properly link it to a WorldCat-sourced record, or create one if it doesn't yet exist.

Unfortunately it is not practical to detect more subtle changes via reports; we don't have a way to, for instance, know that an OCLC number changed in a bib record. But we might come across them in the course of normal technical services work.

Analyzing problems

We need to check the bib record's history. To do so, locate the record in a repository search and click Edit Record to open it in the MDE. In the top menu, select View Related Data > View Versions. Every time the record is saved, whether via edited directly in the MDE, changed via an import profile, or overlaid via our WorldCat integration, the old record is still retrievable via this interface.

The View all versions list shows the versions in descending chronological order, i.e. the most recent versions are shown first. You can browse through this list to locate the version that shows a substantial change. Normally it will not be necessary to display the full record to see this, since we are often looking for changes in OCLC numbers.

As an example, I came across a record in our repository where the year of publication did not match the year shown on the call number.

Of course this could have been a cataloging error on our part, but it was also possible the record had been changed, so I looked at the history.

The record's 035 and 264 had been changed on 12/7/2021 by "System", likely indicating an import profile. The import would have matched on something other than OCLC number and then the merge method was set to overlay the existing fields.

Responding to problems

What action we take depends a bit on how recent the changes were. In the example above, we are seeing a problem caused by a record that was changed more than three years ago. So in this case it would make sense to clean up our inventory by making sure it is attached to the correct bib record. If all inventory linked to this bib needs to be attached to a different bib, the best method is to merge the records—that way any PO lines, reading lists etc. will be taken care of. Otherwise it is a matter of relinking holdings / portfolios to a new bib and also making sure PO line links are reset.

We should also report the problem to the NZ administrator, in case he wants to take additional action such as notifying other institutions that they may have similar problems.

If the change has been recent, then we can use the Restore Metadata button on the most recent version before the change to revert the bib record to its previous state. We should then also notify the NZ administrator, providing at minimum the network MMS ID (ends in 5261) and date of the incorrect change. Screenshots may also be helpful, though the NZ administrator can easily research the situation independently. The NZ administrator would then presumably identify the institution responsible for the change and reach out to them about our consortium's policies, correct import profile configuration etc.