Alma: To Have and To Hold Cecilia Genereux University of Minnesota Libraries gener002@umn.edu

Generally our holdings data transferred smoothly and correctly There were two main areas of concern with moving to Alma: Aleph LKR fields Publication patterns and predictive check-in

Aleph LKR, aka “Linker” LKR field is a non-MARC field Used to link bibliographic records bound withs analyzed serials and series that are classed together each record has its own holdings record; analyzed record referred to the serial/series record with volume number to indicate the item represented Aleph bibliographic records and the LKR field

Series: Advances in Biochemical Engineering/Biotechnology Analytic title: Biotechnology of Hairy Root Systems (no. 134) Series: Special Papers in Paleontology Analytic title: Devonian spore assemblages from northwestern Gondwana: taxonomy and biostratigraphy (no. 89) Series: Patrologia Orientalis Analytic title: Vie et miracles de Samuel de Waldebba (t. 53, fasc. 1=no. 235)

Analyzed Title $$a = type of LKR field $$b = ADM number $$v = enum. a $$i = enum. b

Aleph Host Record Holdings Subfield x code indicating this is an analyzed set/series. Here’s how it was tracked in Host holdings

Analyzed Volume Holdings Subfield x code indicating this is an analyzed vol.

LKR Fields Added Retrospectively We added LKRs to records in prominent series, specifically identified analytic-dense class ranges, and to currently received series. With nearly 4800 host records, the addition of LKRs to their analyzed components was a significant investment of time and effort for the benefit of our users. Long-term projects discussed here!

Losing that in migration wasn’t an option. Migrating LKRs to Alma LKRs in Aleph served an important purpose – providing real-time item availability for analyzed titles. Users and public services staff relied on that service. Losing that in migration wasn’t an option.

Migrating LKRs to Alma: Questions How would nonstandard LKR fields migrate? How would they work in the Alma/Primo environment, without a traditional web OPAC?

Test Migration: It works! (mostly) Real-time availability in Alma/Primo happens via direct query of Alma Get It tab in Primo is a “window into Alma.”

Holdings for series record LKR converted to 773 field

Holdings info for series Item availability for analyzed title

Holdings for series record LKR converted to 773 field

Series and volume numbering prominently displayed Item availability filtered only by 1st level of enumeration

Workflow Changes Aleph: Could check results of LKR immediately in Aleph OPAC Alma: Must wait for a scheduled job and Primo publishing to run before seeing whether the 773 is working (overnight, best case scenario). Student staff could add/verify LKR as part of record preparation; in Alma not currently a comfortable option. As we’re testing out the 773 out, we have had a couple catalogers track the analytics they are cataloging, noting the system numbers and dates cataloged.

We’re Live! University of Minnesota went live on Alma Dec. 26, 2013. What we discovered after we went live…

Problems Identified after Go-Live “We have <title>. Why does Primo say we don’t own it?” Holdings and item for another location on the analytic record cause the 773 link to fail 773 links are not always generated dispite having a correctly formatted 773

Alma View Holdings 1: Non-analytic copy Holdings 2: analytic copy (no item) Properly constructed 773, but failed

Primo Display

Problems Identified after Go-Live, cont’d 773 fields pointing to items in suppressed locations displayed in Primo Migrated 773 fields dependent on retention of Aleph ID in 035 field of record for series

Publication Patterns Quicker arrival of materials Reduced training needs for serials check-in students and new serials acquisitions staff Allowed for predictive claiming uniformity of item description / fewer errors

Aleph: Fields Used LDR, 008 940 to indicate cataloged, updated, deleted & LHR sent to OCLC S63 used to indicate where to start semi-automatic generation of summary statements, 852 853/85X 866-868 Holdings: Used 866/867/868 fields to indicate holdings Pattern data lived in holdings used paired fields: 853/853X items rolled out for a year Displayed in the Aleph catalog as Not yet published

Alma Implementation Ex Libris not intending to add predictive check-in to Alma Month before our go-live learned that Predictive check-in would be added in 1-2 years Decision: migrate our pattern data and implement predictive check-in when available Pushed hard for it to be added, but ultimately not on our list of requirements

Publication Pattern Fields Alma holdings allow for use of paired fields (853/863, 854/864, 855/865) How they work: Turn on a normalization process Code the paired fields, save the record Use the drop down menu, select the rule to invoke, Alma adds the corresponding 86X field For Semi-Automatic Updating of 86X Statements in the Holdings Record This Alma feature was added right before or soon after we went live. The feature has nothing to do with any item records you may have in the system. You need to code every line you want the system to create

Predictive Check-In Jan. 2015 release - predictive check-in available in Alma Requires use of 85X fields & a form (invoked from a menu option). Items can be viewed and rolled out We have not implemented this feature yet. In Feb. a small group will evaluate how it functions, test it out, and make a recommendation to implement or not Roughly 13,600 open serial orders on the Twin Cities campus, including the Law Library Depending on the number of regularly received titles, I imagine we will implement this unless a significant flaw is found while testing

Setting Up Predicted Items

Predicted Items in Primo “Item not in place” --- text can be changed which is great because it sounds like the items are here, but not on the shelf Requests have been made to make it possible to suppress expected items from publishing to Primo, in order to reduce user confusion

Thank you for your attention!