Cataloging Maintenance Priority ON10. Correct MFHDs that contain multiple 852 tags.

Back to Suggested Priorities
Back to Projects to Do Once
Back to Pre-Migration Database Maintenance

Priority for Alma Migration: High Importance. In the migration to Alma, the MFHD will be copied over as is. The presence of additional 852 data will be concatenated into a combined display of the information, which may be confusing for users.

Priority ON10 Record Counts as of February 6, 2020; as of this date, 26 I-Share libraries had one or more MFHDs with more than on 852 tag.

While the MARC21 MFHD format allows the 852 field to be repeatable, in Voyager, only the first instance of an 852 is indexed and presented in public interfaces. Any data found in successive instances of 852$b will not be visible to end users. Additionally, the presence of multiple instances of 852 could be regarded as a data formatting issue in any future migration.

File contents

Libraries will receive an Excel file with data as of February 6, 2020. If your library had no records with this condition, the spreadsheet will state “No records with this problem!” in the first row of data.

Libraries with records will find columns for the MFHD_ID, MFHD Suppression status, and each 852 tag found in the holding record.

Types of problems and suggestions for correction:

Typographical errors

In many cases, the extra 852 appears to have been entered by error in place of another holding record field, such as 853, 856, and 863. Usually, the field contents, and sometimes the indicator values, will suggest what the tag should have been. For example:

852:40:$uhttp://www.archive.org/details/theapocalypseexp00sliguoft/ should be an 856 tag.

852:30:$81$i(yr) appears to be an 853 tag.

852:40:$80$av.1 appears to be an 863 tag.

Review the data and the resource as necessary. Update the tag to its correct value, or consider revising the holding record according to your current practices.

Repeated 852 tags for notes information.

In some records, the added 852 contains only a note subfield, sometimes a public $z note, sometimes a non-public $x note. For example:

852:0 :$bars$kPER.$hHN79.A2$iN4$t1$zSHELVED ALPHABETICALLY BY TITLE
852:0 :$zCEASED PUBLICATION 1973


852:20:$bPHS RES$hWI700$iL7829 1999
852:20:$zCheck out locally only.
852:20:$zLocated in study room.


852:1 :$bstacks$h940.5318 L276h$t1
852:1 :$zThe Irmgard Wessel Holocaust Collection
852:1 :$xDonated December 1944

It appears that Primo VE will concatenate notes together, but not necessarily in the order they are found in the MFHD. Since the 852$z and 852$x are both repeatable subfields, we believe these notes should be moved into the first 852 found in the MFHD.

Repeated 852 tags for multiple copies

In some holding records, libraries have recorded details for different copies of the same title in each 852. Some cases have only different copies of the same location and call number. For example:

852:0 :$bdvd$kDVD$hTD345$i.R8 2006$t1
852:0 :$bdvd$t2
852:0 :$bdvd$t3

In Alma, when multiple copies are described by the same holdings record, the MFHD should have a single 852, with all copies enumerated under subfield t. Voyager also supports this approach, though CARLI has typically recommended a single MFHD for each physical copy.

852:0 :$bdvd$kDVD$hTD345$i.R82006$t1-3​

Another case involves MFHDs that describe copies in different locations and/or call numbers.

852:1 :$bstos$h891.709$iH86IEJ$t3
852:1 :$bspx$h891.709$iH86IEJ$t4

In the above case, the holding describes copies in two different location codes. For copies held in separate locations, create a new holding record for the bib. Relink the appropriate item to the new holding, making sure that the MFHD location and the item permanent location agree with one another.

852:0 :$bref$hL11$i.D54$t1
852:3 :$binternet$hED 1.326:$t1

This case shows a holding in different locations and different call numbers. Additionally, the internet location is likely to be of interest for p2e conversion, but as the second 852 in the mfhd, this record would be skipped if “ref” were not marked as an electronic location. Again, for holdings describing copies in different collections, create separate MFHDs. Relink any item records as needed.

Likely questions:

MARC21 lists the 852 tag as being repeatable. Why isn’t this valid?

Voyager ignores any data outside of the first 852 field. So far, Alma appears to ignore some of the data, but it may also concatenate 852 data into single display, possibly leading to confusing results for staff in Alma, and for patrons in Primo VE.

Is this important for migration?

The Voyager to Alma migration program will only use the first 852 found in the MFHD to determine how holdings and attached items should be migrated. If the additional 852 tags describe multiple physical copies, the details of these copies will be retained in the record, and they will display as part of a single call number.

What happens if these aren’t cleaned up before migration?

During the Vanguard Test load, CARLI staff found that the holding records were migrated to Alma as is, with the added 852 tags and their contents intact. No data will be lost. During the Test Migration, libraries will have the opportunity to review how the data migrates and see the effects in Alma and Primo VE. You may then make decisions about how to correct the records in Voyager before the Cutover or correct in Alma after we Go Live.

Is there a way to fix these records in batch?

Most libraries have few enough problem records that they should be able to correct them without batch processing. Some corrections will also be easier to make directly in the Voyager cataloging client. It should be possible to edit existing records in MarcEdit or to have CARLI staff perform the clean-up. For instance, to compress multiple 852 notes subfields into a single 852.

It is not possible to create multiple MFHDs from a single mfhd in batch.

Alma does include functionality in normalization rules to modify MFHDs in batches. CARLI staff will explore this option after migration concludes.

If a MFHD is suppressed, do I need to correct the record?

For suppressed records, you may want to consider whether you need to retain the record at all. However, you should not need to make corrections at this time. Keep the list of these records and examine them in Alma after the Test Migration; you may find that the data in the added 852 tags should be moved to other fields or subfields.