Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Legend: NOT STARTED IN PROGRESS STALLED DECIDED

Status

DECIDED

Scope

Go-live

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

Recommendation

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

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)***

Field/Range

Definition

Analytics

Notes

908

Shared NZ processing note (ex. RMFG MARCIVE test)

Local param 08**

950-955

Local Use

956

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

957-968

Local Use

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

Use for 793 data and (if desired) other local collection titles*

974

Local Added Entry--Uncontrolled Related/Analytical Title

975

Local Resource Identifier

976

Local Series Added Entry--Personal Name

977

Local Series Added Entry--Corporate Name

978

Local Series Added Entry--Meeting Name

979

Local Series Added Entry--Uniform Title

980-991

Local Use

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)

993-995

Local Use

996

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

Local param 09**

997-999

Local Use

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: https://uc-sils.atlassian.net/wiki/pages/resumedraft.action?draftId=858554619

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.

Action Log

Action/Point Person

Expected Completion Date

Notes

Status

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

03/12/21

Done

Send final choices to ILSDC (Resource Management FG)

03/12/21

Done

  • No labels