Peer council 2013_presentation


Published on

Cataloging Workflow with SkyRiver

Published in: Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Peer council 2013_presentation

  1. 1. An AutomatedCataloging Workflowwith SkyRiverJim Novy and Steve OhsLakeshores Library System1
  2. 2. The presenters…Jim Novy• System Services Technician• Primary IT expertise at LLS• Automation Coordinator of SHARE ConsortiumSteve Ohs• Library Development Coordinator at LLS• Supports Jim in IT & ILS administration• Partial cataloging background2
  3. 3. Outline for this session…1. Challenges we face in our consortium2. Background of our choice to move to SkyRiver3. Our old work flow4. Our new work flow (and the benefits as we seethem)5. Some code examples**Please feel free to ask questions as we movethrough the presentation!** 3
  4. 4. Our Challenges…• Lots of libraries (50 Public & K-12s). Hugevariance in onsite cataloging expertise• Historically a free-for-all. No formal agreementto govern cataloging practices or quality• Ongoing duplicate problem & lots of codinginconsistencies• Staffers lost through attrition not being replaced• 2 original catalogers in the entire consortium4
  5. 5. Our choice to move toSkyRiver…• SHARE was an OCLC customer since its inceptionuntil 2010• Utilized a working group of catalogers to “testdrive” the SkyRiver database• Record quality acceptable• Database coverage acceptable• Main motivation was cost savings• An additional bonus (for us): responsiveness toour needs5
  6. 6. SkyRiver isn’t perfect…• We tend to find more records of a less-than-fullnature. We find more oddball Elvl records thanwe’re used to• A few publishers weren’t initially well-represented• Fewer “individual disc” or “split” records forcertain video and sound recordings (though inour case we’re trying to move away from that)• Longer wait times for a record to appear6
  7. 7. Our *OLD* work flow…7
  8. 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 beingincorrectly imported into the ILS• Generally longer wait times until a full level recordbecame available…translated into longer periods of time for itemsto get into the hands of patrons. This was a problem(for us) 8
  9. 9. So there we were…• Pressure was mounting to come up with some sortof a solution• Implementing an effective program of staff training& uniform application of learned standards was notan option.• It was at this point we remembered we had directz39.50 access to SkyRiver’s server 9
  10. 10. Snapping the pieces together…We cobbled together a new, automated, work flowusing a few different parts:1. SirsiDynix Symphony ILS API tools2. The Perl programming language & some extra Perlcode libraries3. An algorithm that Jim previously designed to rank,select and overlay records based on quality4. A “brief record” model we gleaned from SAILSconsortium (CT)5. Our existing model of using the two originalcatalogers to mediate the original catalogingsituation 10
  11. 11. Our *NEW* work flow…11
  12. 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 intoexisting record.2. Initiate z39.50 connection. Search for & extract amatching record set. Process records through rankingalgorithm. Winning record overlays onto MARC-BRIEF.If no matching records retrieved, automaticallyconstructs & emails SkySearchPlus record request forthe title.3. If MARC-BRIEF record is not overlaid within 4 weeks, ahold is created on that item for the nearest OriginalCataloger. Patron holds prioritized. Item then followsnormal intra-system transit flow, is originally cataloged,and returned to owning library.12
  13. 13. RankingAlgorithm (Detail)…What determines the best record score of a givenset? 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 formsubdivisions13
  14. 14. Local Record ImprovementsFor each record added in a day, we process it through thefollowing improvements:• Convert 440 to 490• Add 007 if not present or invalid• Add local GMD• Fix subfield v values in 49014
  15. 15. Additionalprojects(Detail)…• Weekly “Brief Record Update” scripts to upgradenon MARC-BRIEF records brought in.• Daily scripts to collect possible duplicates &present to catalogers.• Developing agnostic vendor record loader. Soany library that wants to can load vendor recordsdirectly as MARC-BRIEF, including pre-processinginformation (holdings codes, call numbers,barcodes, prices)15
  16. 16. Analysis…Benefits• It’s a much simpler copycataloging work flow• Extra duplicate checks arebuilt-in• We leverage the ‘perks’ ofz39.50 and SkySearchPlus• Items can circulateimmediately• Items in need of OC’ingintegrate seamlessly intothe normal ‘hold picking’processDrawbacks• Reliant on ISBNmatching, so older itemsor split dvd’sare stillsometimes a pain• Significant up-frontdevelopment &debugging time• Initially made some stafffearful16
  17. 17. Code & Questions…Thanks!!Jim  jnovy@lakeshores.lib.wi.usSteve  sohs@lakeshores.lib.wi.us17