ReCAP Summary
• Opened in 2002 with 3 modules• 5 modules now complete, housing more
than 8 million books • CUL: 3.6, NYPL: 2.8, PU: 1.6• Module 8 begins construction FY13,
completed FY15 (projected)• http://recap.princeton.edu/• Quotas outline space use and staffing
needs
What is the purpose of ReCAP?
1. Provide quick, accurate access to low-use materials (shelving)
2. Accommodate under-processed archive and print collections (storage)
3. Alleviate over-crowding of onsite collections (shelving/storage)
ReCAP Systems
• CUL and ReCAP computer systems do not dynamically interact
• CUL systems are designed to keep in sync with ReCAP systems
• Requests placed through regular mechanisms or directly via ReCAP staff
Terms: Customer Code
• How ReCAP systems controls access• Customer codes are two- or three-letter codes
assigned to library collections • Used to control access permissions• Critical to the ongoing transfer, management
and access to off-site collections• Customer codes represent one of three things:
1) Delivery location, 2) Collection or 3) Delivery location and Collection.
• Processing (Staff involved: CUL)– Barcode attached to wrong volume (see 7a)
• Wrong bib record (bad recon)• Smart barcode switch• Mismatch of serial/set issues
– Item prepared but never sent– Item with smart bc not found, not charged to missing– Item with smart bc found but not transferred, data not purged from record– Wrong customer code/CLIO location match (e.g. CM barcode/off,glx
location)– Item transferred to ReCAP with barcode not in Voyager (“Orphan Offsite
Barcode”)• Barcode miskeyed• Barcode not entered
• Transfer (Staff involved: CUL/Clancy-Cullen/ReCAP)– CLIO displays onsite location when in process for transfer– Onsite staging may not be accessible to patron– Delay in accessioning (normal timing is 2-4 weeks after transfer)– Single vol of set isn’t accessioned (sometimes CLIO location flips,
sometimes not)• Accession (Staff involved: ReCAP)
– Barcode not entered/deleted from Voyager– Barcode scans incorrectly– Accession report never received– CLIO location doesn’t change after accession (charged at time of
accession?) Ex: BIBL# 3879176– Barcode scanned under wrong customer code. Sol: Identify using
Accessions data, sorting by customer code, barcode prefix and CLIO location
• Request (Staff involved: CUL/ReCAP)– Request button doesn’t appear
• Misapplied off,xxx location. Problem during early stages of transfer; mostly eliminated by batch suppression.
• Short time delay between location flip and button appearance• Presence of non-offsite Temp. Loc. during processing. Ex. BIBL# 3393111 (Lehman)
– Error message displays when button clicked– Request fails unbeknownst to patron– Bad citation– Bad email address
• Maintenance (Staff involved: CUL)– Holdings record with RECAP LOAD in history is deleted and replaced with
new holdings. Ex. BIBL# 6622249– OPAC message discourages patron, e.g. “ON
– ORDER /IN PROCESS”– MFHD/Item has “off,xxx” location but has no offsite barcode. [12/09, not yet systematically
addressed]– CLIO locations changed from “off,xxx” to “xxx” Ex. BIBL#106440
• Retrieval (Staff involved: ReCAP)– Book not filed “OUT” from ReCAP; ReCAP database thinks book is “IN” (Google Project
specific?)• Delivery (Staff involved: ReCAP/Bohrens/CUL)
– S&R delivery delayed– S&R deliver to wrong library– ReCAP staff puts book in wrong delivery tote
• Circulation (Staff involved: CUL/Patron)– Barcode does not correspond to correct bib record/enum/chron– Book not charged to patron (who may not return)– Items languish in processing departments; charged or not charged– Claim returns with offsite locations
• Not returned• At bindery• Slow return to ReCAP
– Temp Loc and Type not removed• E.g. Reserve books. Solution: Request report of off,xxx locations with Temp Loc.
• Return (Staff involved: Patron/CUL)– Mis-shelved onsite at returning library– Mis-shelved onsite at owning library (after routing)– Book is not discharged– In transit status is not removed (Can batch file be run for all off,xxx location with In
transit?)– Overdue/Lost—System Applied is returned. Discharged but Lost status not removed. Still
requestable in CLIO; not resolved by weekly reconciliation.• Refiling (Staff involved: ReCAP)
– Books are slow to be reshelved• ILL (Staff involved: CUL/ReCAP)
– Request does not go through normal mechanism, item may be requested twice resulting in failure notice
– Book never returned from loan (How to track?)• EDD
– Articles isn’t scanned• Condition/binding• Copyright• Not found• Insufficient information
– Patron can’t access files• Pop up blocker• Problem with browser• Unfamiliarity with technology
– ReCAP Problems• Files removed from server
– re-installation of scanner (9/21/09)
Scale
Givens:• ReCAP is large and involves many staff• ReCAP systems are quick and efficient• Economics of scaleQuestions:• Have we made effective decisions?• Have we made efficient decisions?• How do we know?
Answers to Basic Questions
• How many books transferred?
• What is retrieval rate?
• Where are EA collections delivered?
• EA in overall picture of ReCAP?
• What titles are high use?
• Who is using EA off-site collections?
• What data are available to look at?
Delivery Destination of Off-site EA Collections
East Asian33,24684%
Butler2,6017%
ILL1,4234%
Tech Services6552%
Standing Meetings
• Began October 2009 at Lea Osborne’s suggestion
• Weekly
• Addressed delivery locations, tracking and oversight
Outcomes
• Shipping & Receiving delivery point (CS)• Implementation of Voyager Circulation Module• Dynamic tracking mechanism:
https://www1.columbia.edu/sec/cu/libraries/inside/clio/statistics/offsite/
• Packing (preservation) documentation• RBML/ReCAP website:
https://www1.columbia.edu/sec/cu/libraries/bts/recap/rbml.html
Burke ReCAP Website
• Project details from Nov. 2006-Aug. 2008
• Website includes goals, summary and documentation
• Zack will update to contain more detail about transfer history and encoding
Deliveries to Burke Circulation
Deliveries to Burke Circulation: FY05-Present
0
20
40
60
80
100
120
140
160
180
200
Collections Delivered to Burke
Deliveries of Off-site Collections to Burke: FY05-Present
-20
0
20
40
60
80
100
120
140
Burke Butler General Other Departments
Destination of Burke Requests
Destination of Burke Requests: FY05-Present
3304, 34%
4164, 42%
1597, 16%
380, 4%
291, 3%
94, 1%
Burke Butler Other Circ Desks ILL EDD Tech Services
Retrieval of General Collections
Retrieval of Burke Circulating Collections: FY05-Present
0
50
100
150
200
250
Feb
-04
Apr
-04
Jun-
04
Aug
-04
Oct
-04
Dec
-04
Feb
-05
Apr
-05
Jun-
05
Aug
-05
Oct
-05
Dec
-05
Feb
-06
Apr
-06
Jun-
06
Aug
-06
Oct
-06
Dec
-06
Feb
-07
Apr
-07
Jun-
07
Aug
-07
Oct
-07
Dec
-07
Feb
-08
Apr
-08
Jun-
08
Aug
-08
Oct
-08
Dec
-08
Feb
-09
Apr
-09
Jun-
09
Aug
-09
Oct
-09
Dec
-09
Feb
-10
off,utn off,uts
Retrieval of Special Collections
Retrieval of Burke Special Collections: FY07-Present
0
10
20
30
40
50
60
70
Feb
-04
Apr
-04
Jun-
04
Aug
-04
Oct
-04
Dec
-04
Feb
-05
Apr
-05
Jun-
05
Aug
-05
Oct
-05
Dec
-05
Feb
-06
Apr
-06
Jun-
06
Aug
-06
Oct
-06
Dec
-06
Feb
-07
Apr
-07
Jun-
07
Aug
-07
Oct
-07
Dec
-07
Feb
-08
Apr
-08
Jun-
08
Aug
-08
Oct
-08
Dec
-08
Feb
-09
Apr
-09
Jun-
09
Aug
-09
Oct
-09
Dec
-09
Feb
-10
off,utmrl off,utp
The Issue
• Growing concern about the retrieval rate of ReCAP collections
• Retrieval volume constantly, consistently grows
• Retrieval rate has also grown
• Billing model at ReCAP now based on “activity units”
• More retrieval = more cost
Core of Today’s DiscussionRetrieval Rate by Publication Date and Language
0.00%
5.00%
10.00%
15.00%
20.00%
25.00%
30.00%
35.00%
40.00%
1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009
spa rus por pol ita hin ger fre eng ara
What This Illustrates
• Retrieval rate for recent publications in English (and French) is high
• English language monographs published since 1990 all have retrieval rate higher than target
• New retrieved more than old
Top Related