(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 |
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?)
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 |
---|---|---|---|
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