RMFG Bibliographic records 9xx fields mapping for Vanguard

Legend: not started IN PROGRESS STALLED decided

Status

decided

Description

Ex Libris recommends that institution-specific data be moved out of fields 900-949 and that only consortial data stay in those fields for the Network Zone. All campus-specific data in these fields needs to be relocated or deleted

Decision

See below

Owning group

Resources Management FG + emiraglia@ucsd.edu

Approver

PPC

Stakeholders

R = Resource Management
A = ILSDC
C = Acq/ERM, Discovery FG
I = PPC; ILSDC

Decision-making process

 

Due date

Jun 23, 2020

Recommendation

For current/previous system IDs Vanguard campuses have 3 options:

Option 1:

  • For campuses who need to save current/previous system IDs and don’t have a field in the 950-999 range where their system will put that data automatically:

    • current and previous system IDs can reside in 996 $a using repeated subfield $a as needed

Option 2:

  • For campuses who need to save current/previous system IDs and don’t have a field in the 950-999 range where their system will put that data automatically, but want to use 2 fields:

    • current system IDs should reside in 996 $a

    • previous system IDs should reside in 992 $a using repeated subfield $a for multiple system IDs

Option 3:

  • Campuses who either don’t need to save that data or who otherwise have an automated process or preference to add it to another 950-999 field don’t need to exercise either option above.

There are no other 9XX fields with prescribed changes other than the general rule that all non-CDL campuses must move or copy their data out of 900-949 or risk having it lost in the Vanguard data. It will not be removed from their current system.

For Vanguard campuses with 793 data: some campuses are opting to move this to a 973 field to mirror what some existing Alma campuses have done with 793 data coming in from SCP (among other uses). There is no mandate to do this for the Vanguard campuses since the 793 fields have been used for a wide variety of purposes and types of data and the Vanguard will be a good place to test them out.

Campuses will document where they have moved data.

Reasoning:

While Ex Libris has recommended that some fields be standardized for shared system-wide searching, it is unclear exactly what that will look like in Alma and Primo and so choosing one field to test and leaving the others up to individual campuses allows more time for local data cleanup and assessment in the Vanguard. 9XX data is highly localized and for many campuses has significant impacts on existing workflows so it is not easy to standardize at this time without disrupting daily operations significantly. In addition, the FG would like input from other groups, including the Discovery, Acquistions/ERM, and Special Collections groups before making final decisions for go-live and it will be easier to gather that input once the Vanguard environment is set up.

Assessment for Vanguard:

The FG will identify potential shared search opportunities in consultation with various other FGs and CKGs. Data will be tested in both Alma and Primo to inform decisions for go-live.

The 793/973 question should be explored in more detail, especially with regard to SCP data and other campus collections information.

Cataloging statistics were also identified as a potential area for harmonization in the future.

Background

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:

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

Summary: we can only search whole fields.

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

Up to 10 local fields can be added to Analytics. It’s unclear whether that means 10 per campus or consortium.

 

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

Action/Point Person

Expected Completion Date

Notes

Status

Action/Point Person

Expected Completion Date

Notes

Status

Complete first suggested field changes (All FG members with data in fields 900-949)

 

 

Finished

Vanguard campuses will check on draft recommendation and see whether 1 or 2 fields for system IDs is preferable

 

 

Finished

Finalize field choices and report to PPC for approval(Resource Management FG)

 

 

Finished

Send final choices to ILSDC (via PPC?) (Resource Management FG)

 

 

Finished

The SILS mission is to transform library services and operations through innovation and collaboration. The future is shared!
Question? Contact AskSILS-L@ucop.edu