Retrieval Data: Executive Summary
The terms request and retrieval are used interchangeably in most ReCAP documentation. There is an important difference between the two: CUL tracks requests , ReCAP tracks retrievals. There is not a one-to-one correspondence between requests and retrievals. An item may be retrieved without a request on record in CUL systems. Likewise, a request may go unfilled, without a retrieval.
Request: A request occurs when CUL staff or patron submits a barcode for physical or electronic delivery. CUL staff may use one of several request mechanisms.
Retrieval: A retrieval occurs when ReCAP staff has taken it from the shelf and charges it Out on Return.
ReCAP posts retrieval volume on their statistics website. It records totals per month by customer code, separating physical deliveries from EDDs.
CUL staff and patrons submit online requests via CLIO. These requests are tracked separately from ReCAP’s retrievals. The CUL request data set is based on archived copies of the request files sent to ReCAP. Data from the requests is supplemented by lookups in the Voyager database. Voyager lookups collect important granular data that can is used for detailed analysis. More parameters are added separately by the ReCAP Coordinator.
Validity:
CUL Systems staff does not think there are any significant gaps in the CUL data set.
Requests are tracked by CUL regardless if they succeed or fail. Request failures are not distinguished in the data set. A study of request failures concluded that the population of failures is extremely small and has no significant impact on analysis.
Related Documentation:
Several webpages and documents exist online for assistance.
Several primary sources are the staff-side website under the heading Documentation of ReCAP-Related Systems :
https://library.columbia.edu/bts/recap.html
Data Center:
https://library.columbia.edu/bts/recap/data.html#retrieval
Microsoft Excel details:
ReCAP Coordinator now uses Excel 2010 to compile and analyze request data.
BARCODE : barcode number of requested item
DEL_LOC : delivery location chosen by the user
DEFAULT_DEL_LOC : automatically-set default location in case of EDD failure
DATE : calendar date, not formatted as “Date” in Excel
TIME : hour, minute and second of request
TYPE : indicates if request was physical delivery or EDD
PATRON_GROUP : patron group category assigned to user
BIB_ID : Voyager identifier of corresponding bibliographic record
FORMAT : denotes format of the item from OCLC fixed fields
PUB_DATE : date of publication
LANGUAGE : primary language of work
PLACE_PUB : OCLC code for place of publication
TITLE : title of work
MFHD_ID : Voyager identifier of corresponding holding record
CALL_NUM_TYPE : identifies LC-classification from MFHD 852 i1
CALL_NUM : full call number
ENUM/CHRON : enumeration and chronology from item record
ITEM_ID : Voyager identifier of corresponding item record
CLIO_LOC : CLIO Location code assigned to item
UNI_HASH : encrypted scramble to de-personalize UNI
UNI : unique patron identifier
CALL_NUM_SUBJ1 : first line of call number
CALL_NUM_SUBJ2 : second line of call number
YR_REQ : year of request
MO_REQ : month of request
DA_REQ : day of request
HR_REQ : hour of request
MI_REQ : minute of request
FISCAL_YEAR : fiscal year of request
CAL_DATE : calendar date, formatted as “Date” in Excel
MONTH : month, formatted as “Date” in Excel
MONTH_NAME : name of calendar month
STAFF? : binary, determination if submitted by high-use staff member
PROB_USER? : binary, determination if submitted by single, problem user
USA? : binary
COUNTRY : proper name of place of publication
LANG_NAME : proper name of language
DEPT_NAME : owning department library
MULTIPLE : binary, determination if item has been requested more than once
TIME_STAMP : designation for identifying simultaneous (HV) requests
HV? : binary, determination if request was part of a high-volume request
VOL_LVL : Classification of HV requests (S, L1, L2, M1, M2, HV)
July 2013