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

Legend: not started IN PROGRESS STALLED decided

Status

decided

Scope

Test load

Description

Any data in the 5XX-7XX range that is local (that is not part of the OCLC master record) needs to be moved to a protected local field. In addition, 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

Oct 27, 2020

Recommendation

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

Local 5XX data:

590

Local public note (all local 5XX data can be migrated here if a campus wishes to use 1 field)

591-599

Other local 5XX data (optional)

Local 6XX data:

690

Local Subject Added Entry--Topical Term

691

Local Subject Added Entry--Geographic Name

692

Reserved for future use

693

Reserved for future use

694

Local Index Term--Genre/Form

695

Added Class Number

696

Local Subject Added Entry--Personal Name

697

Local Subject Added Entry--Corporate Name

698

Local Subject Added Entry--Meeting Name

699

Local Subject Added Entry--Uniform Title

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

908

Shared NZ processing note (ex. RMFG MARCIVE test)

956

Copied 856 data (see (Test load) Local 856 bibliographic data )

969

Course reserved field

970

Local Added Entry--Personal Name

971

Local Added Entry--Corporate Name

972

Local Added Entry--Meeting Name

973

Local Added Entry--Uniform Title

992

System IDs that pre-date the current migration (i.e. not your current system ID) (optional for campuses that want to use 1 field for their current ID and one for other IDs from previous migrations)

996

System IDs (both current IDs and previous IDs if only 1 field is desired)

***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: Non-9XX local data for the Vanguard 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:

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

Consulting group feedback

10/21/20

 

Finished

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

10/27/20

 

In progress

Send final choices to ILSDC (Resource Management FG)

10/30/20

 

 

The SILS mission is to transform library services and operations through innovation and collaboration. The future is shared!

Question? Contact AskSILS-L@ucop.edu