(Test load) Local bibliographic data (5XX-9XX)

Legend: not started IN PROGRESS STALLED decided

Recommendation

To the extent possible, campuses should move their data for test load in the following ways.

Local 5XX data:

Local 6XX data:

Local 9XX data (includes some 7XX mappings)***

***Campuses can map other 9XX data however they like but should keep in mind that long-term RMFG will be asking campuses to adopt the 9XX standardization found here: https://www.carli.illinois.edu/products-services/i-share/physical-res-man/local_extensions. The fields above represent an initial pilot project. ILSDC will be providing comments on when/if campuses can adopt the rest of the mappings before go-live or in the months following.

The 900-949 range is reserved for SCP and other Network Zone work.

For go-live we will want to call out some Acquisitions-specific fields.

Reasoning:

All of the campuses will have to move some degree of local data in order to migrate and so RMFG agreed that this was a good time to look more holistically at what could be gained by more sweeping standardization. CARLI had done a lot of that work already and there were a lot of fields that matched how both VG and non-VG campuses were using data in Alma. The group agreed that there will be significant workload implications in trying to adopt such a large scale standardization project and so agreed to pilot a few fields in order to avoid demanding too much of the ILSDC group and to allow time for testing. In addition, the group noted that moving fields around in Alma is easy enough that if campuses have some straggling data for go-live that would be fine but that the long-term goal is to get all of the data into the mapping linked above. Standardization will allow the campuses to take better advantage of Alma and to share some of the more complicated aspects like normalization and merge rules along with import profiles. It will allow us to create shared documentation and to better help one another with workflows. It also helps other groups that rely on the bibliographic data (Discovery, Acquisitions, Fulfillment) to standardize their own practices and to create more unified user experiences.

The group also acknowledges that for some campuses changes have to be live in local systems in order to be migrated for test load. So, in order to minimize the disruption to day-to-day work, campuses are asked to move data “to the extent possible.” Since there will be database freezes in place before go-live, those changes will hopefully be easier to implement then.

There is already a mixed practice around what data is in the 59X fields and rather than try to parse that out for test load it seems better poised as a long-term project likely involving the Special Collections Metadata CKG.

This page also combines 2 Vanguard pages since it made more sense to address local data as a whole.

Lastly, the 9XX ranges do not apply to SCP data since they will be using the 900-949 NZ range.

Assessment:

For test load the group would like to test intentionally “mis-using” a field to see what the impacts are.

RMFG will ask ILSDC for input on whether there are any system-breaking issues in adopting the rest of the CARLI mapping with an aim at implementing the mapping by the end of 2021.

Background

Vanguard decision pages: https://uc-sils.atlassian.net/wiki/spaces/RMF/pages/521437842 https://uc-sils.atlassian.net/wiki/spaces/RMF/pages/510132580

From SILS Phase 3: The process for mapping of fields from non-Alma systems must be collaborative and comprehensive. Mapping must take into account local existing system customizations and different campuses. Concern over potential loss of essential data should be acknowledged and addressed before the change-over as this information may not be able to be re-created if lost. For example, Millennium is an ILS which, due to its structure, necessitated a reliance on variable fields to record information---will this information be kept if its not immediately clear as codeable to an existing Ex Libris field? Related: to what extent is indexing configurable, both at the campus and network-zone level?)

From ExLibris: https://knowledge.exlibrisgroup.com/Alma/Implementation_and_Migration/Migration_Guides_and_Tutorials/010Alma_Migration_Considerations_for_Consortia

For local fields in NZ or IZ: if local fields are used, Ex Libris recommends that the NZ use fields 900-949 and the IZ uses 950-999. This way the local NZ fields (900-949) are those that are local to the entire consortium where every institutional member uses them, and the local IZ fields (950-999) are those that are local only to the single institution

Response from ExLibris on harmonizing 950-999:

RE: So you mean that beyond saving 900-949 for the NZ, we should also have at least some fields in 950-999 that we define consortially?

Yes, that is correct.

RE: With regard to Primo VE shared search: how would we utilize those local fields in a shared way if they're designated as local? They wouldn't be in the NZ copy of the record so I'd be interested in how we'd be able to make use of the shared facets and all that. Maybe I'm just over thinking it?

Good question.  In Primo VE, the union view is similar to any view that is created for an institution, but it allows a consortium to manage a "neutral view" and also provide institution-specific delivery options for signed-in users, who will see their home institution preferences such as display field normalization rules and local field contents.

When creating local fields and customizing normalization rules for display fields in the union view, parallel changes should be made to each institution to maintain consistency after users sign in to specific institutions with the union view. For example, if the union view has mapped the MARC 950 field to local field 2, each member institution should also map the 950 field to local field 2.

More information is available here:
https://knowledge.exlibrisgroup.com/Primo/Product_Documentation/020Primo_VE/004Getting_Started_with_Primo_VE/015Overview_of_Collaborative_Networks_with_Primo_VE#Consortia_Union_View

All 9XX fields can be indexed in Alma

Example of 9XX fields in the NZ/IZ:

Open

Searching subfields in Alma indexes: https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/040Resource_Management/080Configuring_Resource_Management/020Configuring_Search#Configuring_Search_Index_Labels

Adding local fields to Alma Analytics: https://knowledge.exlibrisgroup.com/Alma/Knowledge_Articles/Add_bibliographic_fields_to_Alma_Analytics

Questions to consider

Should we try to leave SCP data where it is and just focus on individual campuses?

Should we worry about harmonizing for the Vanguard at all?

Which fields need standardization vs. localization?

For localized fields, do we still need some shared best practices like adding campus ID?

Action Log