RMFG (Go-live) Local bibliographic data (5XX-9XX)

Legend: not started IN PROGRESS STALLED decided

Recommendation

Updated 8/13/2021

Fields 900-949 are reserved for the Network Zone. Campuses must move all data out of this range prior to migration, regardless of whether the data is purely local or not. This includes, but is not limited to, data generated during OCLC exports. The sole exception is 936 fields with both indicators blank (936##) and those can only be left as-is if the campus is sure that they have never included local data of any kind. If there is any doubt about the existence of local data in a 936## field, campuses should move their 936 data into another field and RMFG can re-visit which data to add back to the NZ range post-migration. The rest of the mapping can be adopted by the end of Phase 4.

Campuses need to move local data into the following mapping by the end of Phase 4 (ideally before go-live):

Local 5XX data:

Local 6XX data:

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

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

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. The test load pilot only identified one additional area of concern: how 9XX fields are used in CZ records. RMFG agreed that campuses could still adopt the standards above since CZ 9XX fields tend to use the existing 900-949 NZ range. 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 changing so many fields means a substantial workload at many campuses and so instead of requiring that all data be moved before go-live, asks that campuses move it before the end of Phase 4.

RMFG has also designated 2 system-wide “local params” for Alma analytics. The group would like to view any shared reports and assess their value before standardizing any additional parameters. This minimizes disruption for current Alma campuses and non-Alma campuses that have already begun setting them up for their data review.

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.

*Regarding 973 data: campuses use 793s differently across the system. Some use 793 fields for e-resource package information only while others also use it for other types of local collection names. In order to avoid asking campuses to split up their 793s and needing to define another local system-wide field for go-live, RMFG is asking campuses to map all 793 data into the 973 field. If a campus has a separate field that they use for local collections (i.e. not a 793), they can map that to any of the “Local use” tags above.

**Shared Local params in Analytics will be set up and tested during the remainder of test load to assess their utility and need for go-live. This page will be updated before cutover to reflect those results.

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

Background

Test Load page: (Test load) Local bibliographic data (5XX-9XX)

Vanguard decision pages: RMFG Non-9XX local data for the Vanguard RMFG Bibliographic records 9xx fields mapping for Vanguard

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

Action Log