1 of 37

100 1_ |a Jun, Marcus, |e presenter.

245 10 |a Network Zone management

: |b enhancing and maintaining

the shared database of

MARC bibliographic records.

264 _1 |a Spokane, Wash. : |b Eluna, |c �2018.

710 2_ |a California State University, |e sponsoring body.

The California State University (CSU) system migrated as a consortium to Alma in June 2017. Our university system shares a database of MARC bibliographic records in the Network Zone (NZ). The purpose of this presentation is to share how the CSU performs general database maintenance and enhancement of the NZ. Topics include import profiles for automated loading of new and updated OCLC Worldcat records into the NZ, troubleshooting and resolving multi-matches (when an incoming record matches two or more existing records) and strategies to deal with duplicate records.

The presenter also seeks to raise the fundamental question of "What is the Network Zone?" which will influence how a consortium manages its NZ. Is it an exact, mirrored subset of the Worldcat database or a Worldcat-sourced, but consortium-mediated database?

Although the presentation is geared toward consortia using Alma with an NZ, standalone Alma institutions with an Institution Zone (IZ) may benefit from common strategies in maintaining and enhancing bibliographic databases.

2 of 37

Background

California State University (CSU) migrated as consortium to Alma/Primo June 2017

23 campuses

8.2+ million bibliographic records in NZ

OCLC Worldcat: primary source of bib records

2

3 of 37

Institution, Network, Community Zone

�

Institution (IZ): local data (local fields, inventory) � IZ bib records linked to NZ bib records

Network (NZ): shared database of bib records

Community (CZ): e-resource knowledge base (KB)

3

4 of 37

CSU Network Zone and Worldcat

Worldcat & mini-Worldcat

4

Worldcat

CSU

Network Zone

5 of 37

Daily OCLC Load

5

6 of 37

Daily OCLC Load

Imports Worldcat master records into the NZ

Based on collective holdings of the CSU

New: recently “held” by any campus

Updates: Worldcat records updated recently

Benefits

Automated, up-to-date, centralized

6

7 of 37

Daily OCLC Load Settings

Two Alma import profiles: new and updates

MARC files via ftp thru Worldshare Collect Mngr

Match by OCLC number, overlays NZ record

�Upon no match: import? or do not import?

“What should Alma do if an incoming record �does not match any existing records?”

7

8 of 37

Multi-matches

8

9 of 37

Multi-matches

When an incoming record matches �two or more existing records

�Causes:

Duplicate NZ records with same oclc number

OCLC dedupe and merge

(035 $z invalid/cancelled OCLC numbers)

9

10 of 37

035 $a match

Incoming OCLC record

035 $a (OCoLC) 1234

Existing NZ record #1

035 $a (OCoLC) 1234

Existing NZ record #2

035 $a (OCoLC) 1234

10

11 of 37

035 $a and/or $z match

Incoming OCLC record

035 $a (OCoLC) 1234 � $z (OCoLC) 5678

Existing NZ record #1

035 $a (OCoLC) 1234

Existing NZ record #2

035 $a (OCoLC) 5678

11

12 of 37

Daily Statistics snapshot (Updates)

62,000 bib records imported, range [3k - 457k]

� 405 (0.7%) - disregard invalid/cancelled (035 $z)

� 28 (0.04%) - duplicates in NZ (035 $a match)

� 3951 (6.3%) - upon no match, do not import

12

13 of 37

Why are multi-matches bad?

Multi-matches impede record imports/Alma work� Prevent updates from daily OCLC load� Require manual resolution� Can’t link IZ records to NZ records

Consortial collection analysis� Difficult to assess who owns what?

Primo dedup/merge and discovery display issues

13

14 of 37

Mitigation methods

Ignore 035 $z in incoming record for matching

Reduces manual handling �but ignores OCLC deduping and merging

14

15 of 37

035 $a $z match

Incoming OCLC record

035 $a (OCoLC) 1234 � $z (OCoLC) 5678

Existing NZ record #1

035 $a (OCoLC) 1234

Existing NZ record #2

035 $a (OCoLC) 5678

15

16 of 37

Merge records & combine inventory

For multi-matches, �merge incoming and existing NZ bib records, �links any IZ inventory to consolidated NZ record, and �preserves IZ local fields (59x, 9xx).

�Can be used when manually resolving multi-matches after record import.

Alt.: manual merge/combine in Metadata Editor

16

17 of 37

CSU approach

Use Daily OCLC load’s multi-matches as opportunity for piecemeal database maintenance

Since March 2018, merge 600 groups per day

1 group = incoming record, 2+ NZ records

17

18 of 37

How not to manage your NZ

18

19 of 37

Identify records not used in NZ

No inventory (physical or electronic)

Not associated with a collection or a PO line

No resource sharing requests

No reading list citations

Not part of a bound-with relationship

19

20 of 37

Boundwith records (IZ ↔ NZ)

NZ bib record #1 NZ bib record #2�

IZ bib record #1 IZ bib record #2�

Host bibliographic record

MARC holdings record

Item record

20

21 of 37

CSU NZ Cleanup (Fall 2017)

Before: 8.4m bib records in NZ, � 1.06m identified as unused

After: 7.4m bib records in NZ� 1.03m bib records deleted� 24k identified as unused but not deleted

21

22 of 37

Unintended Consequences

Bibliographic records in boundwith relationships and linked to host bibliographic records were deleted.

Northridge: 2987 of 6923 boundwith bib records were deleted. 43%

22

23 of 37

Restoration through Exlibris support

Oct 2017-Apr 2018: back-and-forth, ongoing process

584k + 10k = approx 594k NZ bib records restored

To verify restoration in each IZ, need to use� sets, MarcEdit and Analytics

Some IZ records: corresponding NZ record had not � been restored so not discoverable in Primo

23

24 of 37

Lesson learned the hard way

24

25 of 37

Identify job: task parameters

25

26 of 37

Exlibris documentation says:

Records that are part of a boundwith relation �- Clear this checkbox to exclude records that are bound with other records

Actual meaning:�“Check this box to consider records �that are bound with other records as in use”

26

27 of 37

Use with caution

In small-scale testing, the identify job correctly identifies boundwiths as in use when all six boxes in the task parameters are selected.

However, based on our experience we are hesitant to use the identify job as a basis to delete unused records from our Network Zone.

Alternative: Suppress unused NZ records.

27

28 of 37

Conclusion: NZ management goals

In a consortial library management system:

Centralization, systemwide efficiencies

Less work for each campus

Support consortial collection development

Enhance MARC records for Primo discovery

28

29 of 37

Special Thanks to

CSU library community

Orbis Cascade Alliance

mjun@calstate.edu

Slides: goo.gl/fj73bD

29

30 of 37

Bonus Slides

30

31 of 37

Marcive

Documents w/o Shelves

(consortial subscription)

31

32 of 37

Marcive Import profiles

Centralized loading in NZ

Fetch files automatically by ftp

Two sets: New and Changed MARC records

Then split by bib level: mono, ser, integ. res

Import profiles by eportfolio material type: �book, journal, website

Resulting in 6 import profiles in NZ

32

33 of 37

Misc. notes

Daily OCLC load: weekdays, sometimes skip a day, a few times on Saturday, delay of 1-2 days between holdings update in OCLC and record download

NZ bib record updated then can take a few hours for changes to trickle down to IZ view of same record

33

34 of 37

Live demo links

https://csu-network.alma.exlibrisgroup.com/mng/login

https://na03.alma.exlibrisgroup.com/mng/login?institute=01CALS_UNO

34

35 of 37

35

36 of 37

Radical solution (just brainstorming)

Unlink all IZ boundwith records from the NZ� Protect and isolate IZ records from NZ cleanup

Drawbacks:� Updates to NZ won’t trickle down to IZ� Add. config for local fields to display in Primo� Unintended consequences? Campus opposition?

36

37 of 37

IZ boundwiths severed from NZ

NZ bib record #1 NZ bib record #2�

IZ bib record #1 IZ bib record #2�

Host bibliographic record

MARC holdings record

Item record

37