Searching Without a Net: Revisiting Primo Normalization Rules in the Context of Aleph to Alma Migration

Primo at Minnesota 2007: Primo Development Partner and initial rollout 2008-12: Discoverability projects 2013: Primo Central implementation and migration to Alma Primo development partner -- good in that we influenced early development of the product, bad in that as some of the first implementers, a lot of our early choices (especially in normalization rules) were not revisited, even when Primo added features that would have improved discovery. Discoverability projects: phased, multi-year project to evaluate discovery needs for library resources. Resulted in baseline study, recommendations for data gathering, blue-sky list of desired discovery system features, and RFP for discovery layer. Selection of Primo Central and migration to Alma: near-simultaneous implementations. Decommissioning of Aleph OPAC. Many questions about Alma functionality and how it will function differently from Aleph/SFX as a backend for Primo.

Normalization Rules Refresher Normalization rules transform MARC records (or records in other metadata formats) to Primo Normalized XML records (PNX) They control searching, display, facets, deduping, and FRBRization

Revision: Now is the Time! Thorough revision of Primo MARC normalization rules not done since initial implementation Upgrade to Primo 4 Primo Central implementation and blended search Alma implementation: complete re-normalization and reindexing; end of Aleph OPAC RDA implementation and RDA enhancement of existing records Wanted to do a thorough revision of Primo norm rules for some years, but institutional will to do it wasn’t there. Primo Central Implementation coupled with Alma migration was the “perfect” time. Urgent because of loss of Aleph OPAC -- public relations issue. Needed to make improvements wherever we can to soften the blow for dedicated Aleph OPAC users. RDA implementation plays in, as well...revisions to bib and authority data would have suggested revisiting norm rules even without system implementation.

Understanding the Rules Presentation of normalization rules within Primo Back Office is less than intuitive. Alternate view by MARC tag very helpful, especially for catalogers. Working back and forth between the rules in the back office and the MARC view was often very helpful.

View by MARC Tag

Process Review customizations made to Aleph MARC normalization rules Address problems/concerns with current implementation of Primo Review MNCAT Classic (Aleph OPAC) use cases and search data

Process Accommodate Alma data where it differs from Aleph Review new RDA elements and determine where they might aid users in search or identification Review Aleph OPAC search indexes and limits Alma data: one project we did in preparation for Alma migration was to clean up local notes and local added entries on bib records. Most of these were for special collections materials. We created an “associated name” index specifically for these local added entries, since it’s important to Archives and Special Collections staff to be able to search them directly. Although the default Primo MARC normalization rules include RDA fields more than they used to, there were a few additions we made of fields not included by default.

Process Write rules, publish a set of relevant records from Alma, and test changes. Make big changes cautiously; watch for unintended consequences We were cautious about some changes, because we couldn’t easily test on a large enough scale to see the unintended consequences. Especially true for FRBR, Dedup, and Browse changes, which we put off until after Alma go-live.

Tracking Changes with Trello We used the free online tool Trello to track changes from initial proposal to testing and implementation.

Existing Customizations Which to carry forward? Were all still needed? Examples: facet for geographic area; splitting “Audiovisual” resource type into “Audio” and “Video.” As it turned out, we kept many of the customizations we had previously made

Aleph/Primo Issues Failed searches or poor search results in current Aleph/Primo implementation Sometimes normalization could help, but not always Example: adding a “government document” resource type to allow better filtering of result sets.

Aleph/Primo Issues Causes of failed searches: Not always normalization Flawed source data Ranking issues for individual records Failed publication processes. Many staff had developed the attitude over time that Primo failures were mysterious and usually unfixable, and so were not in the habit of reporting them. We’ve tried to demystify how catalog data makes it to Primo and to strongly encourage problem reporting.

Aleph/Primo Issues Ongoing effort to communicate to staff that they should report failed Primo searches so problems could be identified and fixed.

Aleph OPAC review Use cases gathered via online form and staff input Aleph OPAC search data reviewed from recent years Based on that information, attempted to identify changes to norm rules or indexes that might address needs

Aleph OPAC use cases

Aleph OPAC use cases Warning to public users and FAQ on the retirement of MNCAT Classic, and a link for users to provide comments and suggestions. Known item searching specifically addressed.

Aleph OPAC use cases Staff-facing form to collect specific situations where the Aleph OPAC succeeded and Primo either failed, or provided insufficient or irrelevant results.

Aleph OPAC data This is just one example of OPAC data we reviewed. Some surprises here, and the data required some thoughtful interpretation. Still, this provided a very useful window into the kinds of searches users do in the Aleph OPAC and helped us decide where we should make the effort to establish specific, dedicated indexes in Primo.

Aleph OPAC data Because known item searching is an especially large concern, we used OPAC data to develop lists of titles for testing Primo vs. the Aleph OPAC. Although the primary purpose of this was not for normalization rule changes, it helped identify a few issues that could be corrected via changes to norm rules. We used known-item search testing to tweak the Primo Central/local catalog blended search, which became the default search on the Libraries home page and in Primo.

Aleph OPAC review Review of search and display options available in Aleph OPAC Goal: offer similar options in Primo where possible and justified by past usage Examples: expanded “Details” display, more index choices in Advanced search. We had extensively customized indexes in Aleph, many of which were presented as options to the public (technically all were available via command line search). We wanted to offer similar options to the Aleph OPAC in Primo when it was practical to do so.

Accommodating Alma Changes to local data on bibliographic records made in preparation for Alma migration Especially important for special collections: search and display of holdings-level public notes. Most holdings-level public notes display by default in Alma/Primo – this had been an ongoing issue with Aleph/Primo. However, we are not currently able to make them searchable in Primo because Alma does not publish holdings note data (852 $$z and 866 $$z) to Primo.

MARC Holdings Notes Display Search 852 $$z and 866 $$z notes display but cannot be made searchable!

RDA University of Minnesota full RDA implementation Summer 2013 Backstage Library Works RDA enhancement of full database planned for 2014

RDA Examples Ensuring no rules relied on GMD (245 $h) Added 338 field and technical details fields (34X) to Details display. Stripped relationship designators (1XX/7XX $e or $j) from creator; displayed in custom field instead.

Post Alma Go-Live To Do Browse indexes Dedup and FRBR (if necessary) Minor tweaks to details display Current plan is for blended search to be the default, so we want to make sure that known item searching doesn’t suffer. Browse is important to us, because title browse has been the Twin Cities Aleph OPAC default search for many years. Idea is to make Primo’s title browse contain the same MARC fields/subfields that Aleph title browse contains.

Browse Went live with OTB browse rules Intent to align browse indexes with Aleph browse indexes where possible. Problems detected with Author Browse and Call Number Browses

Title Browse

Author Browse 800 $$v included, but without 800$$t. We will either add $$t or remove $$v to fix.

Call Number Browse Form/size designators indexing as part of call number browse string. Dewey browse not working well; needs analysis.

FRBR and Dedup Tweaks FRBR clustering of all formats problematic for music materials Dedup failing for some maps These problems existed in Primo/Aleph, but were not detected because users fell back on Aleph OPAC.

Dedup Failures: Maps Our quick-and-dirty temporary solution until we can do some better testing: exempt all maps from dedup.

Dedup Failures: Journals Cataloging differences between print and e-journal records causing no dedup (and sometimes no FRBRization) E-journal metadata from Alma Community Zone not locally controlled, so source data tweaks are not possible.

“blood” “blood journal”

Resource Type Refinement Exclude state university press publications from Government Document type Investigate adding others: Thesis/Dissertation, Database Interaction with Primo Central resource types

Stacie Traill trail001@umn.edu Thank You Stacie Traill trail001@umn.edu