This document describes an automated cataloging workflow developed by Lakeshores Library System to address challenges with cataloging materials from their consortium of 50 public and K-12 libraries. Their old workflow involved manual cataloging of individual items which led to duplicates and inconsistencies. Their new workflow utilizes a "brief record" model and nightly APIs to automatically search SkyRiver records, apply a ranking algorithm to select the best match, and overlay it or request an original catalog if no match. This streamlined the copy cataloging process while still ensuring items needing original cataloging were routed to catalogers. The new workflow provided benefits like reduced duplicates and quicker access for patrons, though some manual cleanup and older items still required more work.

1. An Automated
Cataloging Workflow
with SkyRiver
Jim Novy and Steve Ohs
Lakeshores Library System
1

2. The presenters…
Jim Novy
• System Services Technician
• Primary IT expertise at LLS
• Automation Coordinator of SHARE Consortium
Steve Ohs
• Library Development Coordinator at LLS
• Supports Jim in IT & ILS administration
• Partial cataloging background
2

3. Outline for this session…
1. Challenges we face in our consortium
2. Background of our choice to move to SkyRiver
3. Our old work flow
4. Our new work flow (and the benefits as we see
them)
5. Some code examples
**Please feel free to ask questions as we move
through the presentation!** 3

4. Our Challenges…
• Lots of libraries (50 Public & K-12s). Huge
variance in onsite cataloging expertise
• Historically a free-for-all. No formal agreement
to govern cataloging practices or quality
• Ongoing duplicate problem & lots of coding
inconsistencies
• Staffers lost through attrition not being replaced
• 2 original catalogers in the entire consortium
4

5. Our choice to move to
SkyRiver…
• SHARE was an OCLC customer since its inception
until 2010
• Utilized a working group of catalogers to “test
drive” the SkyRiver database
• Record quality acceptable
• Database coverage acceptable
• Main motivation was cost savings
• An additional bonus (for us): responsiveness to
our needs
5

6. SkyRiver isn’t perfect…
• We tend to find more records of a less-than-full
nature. We find more oddball Elvl records than
we’re used to
• A few publishers weren’t initially well-
represented
• Fewer “individual disc” or “split” records for
certain video and sound recordings (though in
our case we’re trying to move away from that)
• Longer wait times for a record to appear
6

7. Our *OLD* work flow…
7

8. That work flow didn’t cut it…
The imperfections of SkyRiver…
• Certain materials harder to find
• Certain publishers not initially well-represented
• More records of less-than-full quality being
incorrectly imported into the ILS
• Generally longer wait times until a full level record
became available
…translated into longer periods of time for items
to get into the hands of patrons.
 This was a problem(for us) 8

9. So there we were…
• Pressure was mounting to come up with some sort
of a solution
• Implementing an effective program of staff training
& uniform application of learned standards was not
an option.
• It was at this point we remembered we had direct
z39.50 access to SkyRiver’s server 9

10. Snapping the pieces together…
We cobbled together a new, automated, work flow
using a few different parts:
1. SirsiDynix Symphony ILS API tools
2. The Perl programming language & some extra Perl
code libraries
3. An algorithm that Jim previously designed to rank,
select and overlay records based on quality
4. A “brief record” model we gleaned from SAILS
consortium (CT)
5. Our existing model of using the two original
catalogers to mediate the original cataloging
situation 10

11. Our *NEW* work flow…
11

12. MARC-BRIEFNightly Processing(Detail)…
For each MARC-BRIEF record:
1. Duplicate check against our catalog. If duplicate found,
the MARC-BRIEF holdings & items are merged into
existing record.
2. Initiate z39.50 connection. Search for & extract a
matching record set. Process records through ranking
algorithm. Winning record overlays onto MARC-BRIEF.
If no matching records retrieved, automatically
constructs & emails SkySearchPlus record request for
the title.
3. If MARC-BRIEF record is not overlaid within 4 weeks, a
hold is created on that item for the nearest Original
Cataloger. Patron holds prioritized. Item then follows
normal intra-system transit flow, is originally cataloged,
and returned to owning library.
12

13. RankingAlgorithm (Detail)…
What determines the best record score of a given
set? Some elements are:
• Elvl leader byte
• Contents of 040
• Number of 5XX notes
• Number of 6XX headings with 1st indicator 0 or 1
• Presence of 6XX headings with juvenile form
subdivisions
13

14. Local Record Improvements
For each record added in a day, we process it through the
following improvements:
• Convert 440 to 490
• Add 007 if not present or invalid
• Add local GMD
• Fix subfield v values in 490
14

15. Additionalprojects(Detail)…
• Weekly “Brief Record Update” scripts to upgrade
non MARC-BRIEF records brought in.
• Daily scripts to collect possible duplicates &
present to catalogers.
• Developing agnostic vendor record loader. So
any library that wants to can load vendor records
directly as MARC-BRIEF, including pre-processing
information (holdings codes, call numbers,
barcodes, prices)
15

16. Analysis…
Benefits
• It’s a much simpler copy
cataloging work flow
• Extra duplicate checks are
built-in
• We leverage the ‘perks’ of
z39.50 and SkySearchPlus
• Items can circulate
immediately
• Items in need of OC’ing
integrate seamlessly into
the normal ‘hold picking’
process
Drawbacks
• Reliant on ISBN
matching, so older items
or split dvd’sare still
sometimes a pain
• Significant up-front
development &
debugging time
• Initially made some staff
fearful
16

17. Code & Questions…
Thanks!!
Jim  jnovy@lakeshores.lib.wi.us
Steve  sohs@lakeshores.lib.wi.us
17