The End of Nostradamus: Killing Predictive Checkin Without Feeling Guilty


Published on

In the 1980s and 1990s, ILS software took the next step forward in serial checkin: fully-predictive checkin systems, that told you exactly what you were going to receive when. The idea was that checkin would take only seconds per issue, and the software would do almost all the work for you. Predictive data would be shared universally, eliminating duplicative work at each library. Standards work and new MARC tags would facilitate data interchange. In the 2010s, the next generation of ILSes is emerging, and predictive checkin isn't being included in most of them. What happened to dim the promise of prediction? What sort of systems are being developed to replace it?

Published in: Education
1 Like
  • Be the first to comment

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

No notes for slide

The End of Nostradamus: Killing Predictive Checkin Without Feeling Guilty

  1. 1. The End of NostradamusKilling Predictive Checkinwithout Feeling GuiltyYoung Joo Moon, Boston CollegeBob Persing, Univ. of PennsylvaniaNASIG 2013 conferenceJune 7, 2013
  2. 2. Our namesake• 16th-century French mystic• Best known for making many grand,specific, and inaccurate predictions aboutfuture history• (nice beard, though)
  3. 3. History of predictive checkin systems• 1940s: the Kardex
  4. 4. History of predictive checkin systems• 1950s, 1960s: computers! (sort of)– Not so much for checkin as for creatingprinted lists of serials
  5. 5. History of predictive checkin systems• 1970s: a time of beginnings– OCLC• Advisory Committee on Serials• Serial bib. records start appearing• Serials Control System (SCS)– ISSN standard (1971, 1975)– CONSER founded (1976)
  6. 6. History of predictive checkin systems• 1980s: change happens quickly• Major systems reach market:– NOTIS– Innovacq– VTLS– OCLC SC350– Many others• Faxon: Linx, SC-10
  7. 7. History of predictive checkin systems• 1980s: some foundational standards– ANSI/NISO Z39.42 (summary holdings)– MARC Format For Holdings Data– Z39.44 (serial holdings – supersededZ39.42)– Z39.57 (nonserial holdings)– ASC X12
  8. 8. History of predictive checkin systems• 1990s: true prediction arrives– Innovative– NOTIS– VTLS• Many other systems try prediction– LC builds in-house system, but then migratesto Voyager
  9. 9. History of predictive checkin systems• 1990s: important standards work– Separate ISSN for each format– EDIFACT data transmission standard– Initial CONSER work on sharing publicationpatterns (early 1990s)– Z39.71 supersedes both Z39.44 and Z39.57– SICI (serial item & contribution identifier)– DOI (digital object identifier)
  10. 10. History of predictive checkin systems• Late 1990s: some players drop out– OCLC SC350– NOTIS• Ameritech manages to kill them both!– Faxon• Others jump in– Endeavor
  11. 11. History of predictive checkin systems• 2000s: more standards work– CONSER Publication Patterns Project /OCLC 891 field– DLF ERMI• Much serials-related ILS work, but morefocused on ERM, knowledgebases
  12. 12. • 2010s: next generation of systems• Two case studies:– Alma– Kuali OLEHistory of predictive checkin systems
  13. 13. Living without Predictive CheckinBoston College‘s Experiencewith Alma
  14. 14. Boston College• Founded in1863• Private, Jesuits• 11 schools/colleges• Students 14,000undergrad 9,000graduate 5,000Faculty 725• 3 campusesMain campus-Chestnut Hill
  15. 15. Boston College University Libraries• ARL member• 8 libraries• Collectionsprint 3 millionebook 400,000• Materials Budget$9,536,496(FY12 excluding Law)
  16. 16. BC and Alma• Migrated from Aleph to Alma in June2012 (1st institution to migrate to Alma)• Development partner since 2009• Deeply involved in design anddevelopment
  17. 17. What is Alma?• URM (Unified Resource Management)• Supports the entire suite of library operations—selection, acquisition, metadata management,digitization, and fulfillment—for the fullspectrum of library materials, regardless offormat or location• Focuses on unified management of all of alibrary‘s resources• Workflow-driven
  18. 18. What is Alma?• Cloud environment• Replaces individual data silos: Aleph, ERM,SFX• Primo (Holmes) sits on top: Discovery layer• Browser based: Firefox6+, Chrome3+, IE8+• Can be accessed from any computer or internetdevice• Can take multiple metadata formats: MARC,Dublin Core and MODS
  19. 19. Alma DevelopmentFive Partner Releasesfrom June 2010 to October 2011URM Conceptualdesign withdevelopmentpartners completed 2nd PartnerReleasedeliveredNovember2010GeneralReleaseBC Live (7/2)20121st PartnerReleasedeliveredJune2010 Partners testing PR2 – PR 5 in SaaSCloud with owndata migratedDec ’10- Jan ‘12Jan ‘08-June ‘10
  20. 20. Periodical collections in BC• Periodical Collectionprint – 6,340ejournal – 34,919 (including aggregators)• Periodical Budget$4,917,173 (FY12)ejournal: $4,037,484print journal: $879,689
  21. 21. Print Periodical Checkin in Alma• Checkin function linked to orders withspecific order typesPhysical – SubscriptionPhysical – Standing Order Non-monograph• Alma does not support predictive patternfunctionality• Alma considers ―serials check-in‖ as ―receivingphysical items‖
  22. 22. Print Periodical Checkin in Alma
  23. 23. Print Periodical Checkin in Alma
  24. 24. Print Periodical Checkin in Alma
  25. 25. Print Periodical Checkin in Alma
  26. 26. Print Periodical Checkin in Alma
  27. 27. Standing Order Checkin in Alma• S.O. Order TypesPhysical – Standing Order MonographPhysical – Standing Order Non-monograph• Standing Order Non-monographMultiple items can be associated with a singleholding (acts like a periodical)
  28. 28. Standing Order Checkin in Alma• Standing Order MonographApplied to analytical series (acts like amonograph)• Cannot be received using periodicals receiving(different workflow is applied)Individual record created for each vol.Umbrella order is created – linked to holdings ofindividual vol.
  29. 29. Print Periodical Claims in Alma• Order record has Expected Receipt Date,Claiming Grace Period and SubscriptionInterval• When the Expected Receipt Date + ClaimingGrace period arrives and if no issue wasreceived, Alma sends the PO line to the claimstask list• When an issue arrives, Expected Receipt Dateis updated by Receipt Date + SubscriptionInterval
  30. 30. Print Periodical Claims in Alma
  31. 31. Print Periodical Claims in Alma• Vendor record has Expected Receipt afterOrdering (days) and Claim Grace Period(days) that are used as default values whencreating a new order
  32. 32. Print Periodical Claims in Alma• Claims Task ListFor getting a list of titles to be claimedFor adding communicationsFor manually updating Expected Receipt Date
  33. 33. Print Periodical Claims in Alma
  34. 34. Print Periodical Claims in Alma
  35. 35. Print Periodical Claims in Alma
  36. 36. Periodical Binding in Alma• Alma supports binding functionality. Fromthe Items screen, the items to be boundcan be selected, and then clicks on theoption ‗Bind Items‘
  37. 37. Periodical Binding in Alma
  38. 38. Overall Experience• Saves a lot of staff time – enablesrestructuring/refocusing• Expects the number of print periodicalscontinue to decrease (e-only is preferred)• Satisfaction/fulfillment level remainsabout the same
  39. 39. Kuali OLE partnership
  40. 40. Kuali OLE Precis• Open-source ILS• Fully web-based (no clients)• Data format-neutral (not just MARC)• Intended to handle all formats equally– No preference for tangible or electronic• No OPAC• Sister project: GOKb (open-sourcecommunity-supported knowledgebase)
  41. 41. Kuali OLE timeline• 2008-2010: initial designdiscussions, partner recruitment– Project started out independent, but joined KualiFoundation, an umbrella organization of higher-edopen source software projects, in 2009• 2011: release 0.3• 2012: release 0.6• 2013: releases 0.8, 1.0• 2014: releases 1.5, 2.0
  42. 42. Kuali OLE Serials Development• 2011 survey of partners• Some partners have fully-predictive systemscurrently, some don‘t• All partners still checking in print serials, to onedegree or another• All partners reported steep decreases in printserial subscriptions in last 15 years• All partners doing some claiming, though lessthan in past
  43. 43. Kuali OLE Serials Development2011: OLE Select & Acquire Team wrotewhite paper, laying out three options:1) passive receipt2) action-date-based receipt3) full prediction, with patterns
  44. 44. Kuali OLE Serials Development• S&A Team and OLE Functional Councilcame to consensus on option #2– ―don‘t fight the last war‖
  45. 45. Kuali OLE Serials Development2012: Serials team formed to write specs• Discussed needs at their institutions• Read user stories submitted by partnerlibrary staffs• Wrote functional specifications,describing how the functionality shouldwork
  46. 46. Kuali OLE Serials Development• Consensus on team: full prediction notworth it for the number of titles we still get• Still need some trigger forclaiming, though• Only real resistance came from lawlibraries– Still heavily print-based
  47. 47. Kuali OLE Serials Development• Wrote specifications for free-standingserials receiving record• Designed mockups of receiving andreceipt history screens– In Excel!– Serials receiving not fully coded yet, butmockup is at:
  48. 48. Kuali OLE Serials mockup
  49. 49. Thank you!Questions?Bob Persing ( Joo Moon (