Discussion Topics

3/5/10 Transitional CLIO location

Core question: How should staff encode CLIO locations during ReCAP processing to effectively communicate current location to patron?

Decision made 7/6/2010 by group discussion: Bob Wolven, Misha Harnick, Ilona Bicsak, Zack Lane, Dave Motson and Bill Austin.  Details listed on ReCAP Alerts website.

Notes on transitional CLIO location:

  • Some department libraries stage processed materials to be retrievable by staff and patrons; other departments do not make in-process material accessible.
  • In the NOTIS environment xxx,anx2 was used to create smart barcodes. Following transfer the entire population had CLIO locations changed to off,xxx. Records with xxx,anx2 locations remained and most were suppressed. Clean up project was conducted in Spring 2009 to resolve mus,anx2 locations at Music Library (see Other goals).
  • MPS began using xxx4off for new acquisitions going directly to ReCAP in January 2007.
  • After accession items charged to MUS2OSS001 appear on the weekly Accession Report and are discharged by MRP staff.
  • After accession locations mus, mus,anx2 and mus4off and change to the same offsite location off,mus.

CLIO Location & Display in CLIO

  • mus
  • mus,anx2
  • mus4off
  • off,mus
  • mus/mus,anx2
    (charged to MUS2OSS001)

3/5/10 E-mail Notification of ReCAP Request

In October 2009 Francie Mrkich, Sarah Witte and Zack Lane began discussing an email alert system to confirm with patrons that a ReCAP request had been submitted. Proposal to create system similar to Borrow Direct. Desired elements in email: citation, patron info, barcode, staff contact info, ability to opt out, time/date of request and general information. ZL consulted with Breck Witte and submitted work order.

Notification implemented 4/9/2010 after group consensus: ASCC.  Details listed on ReCAP Alerts website.

In March 2010 a prototype was made available for testing. Test link: https://www1.columbia.edu/sec-cgi-bin/cul/offsite/vie2?key=200444&type=STAF&spec=SUPP

Test link does not submit a request or modify our tracking data (rus). It can be used over and over without worrying about generating a request. When implemented it will apply to all CUL request mechanisms: CLIO, mediated, restricted access and non-CLIO.

Two elements to consider while reviewing. 1) boilerplate information at top and bottom of message and 2) variable request data that loads from request form.

Zack's questions (addressed at ASCC, 3/30/2010)

  • Where will email go if nothing in Email field? [3/10 email is required in order to submit request]
  • Should patron's name display from Name field rather than UNI? [3/10 updated to display Name]
  • How will requester be identified if it is a Mediated request? [3/10 staff UNI not identified in notificaion to patron]
  • Can email also be sent to staff in mediated request? [3/10 not immediately feasible or desirable]
  • Where should Enum/Chron information be displayed? [3/10 agreement, after barcode)
EDD Request
Physical Delivery - Multiple Items
Physical Delivery - Single Item
Physical Delivery - Mediated Request

Current boilerplate text:

"You will be contacted by email (to [patronemail@xxx.xxx]) when the item is available, generally within two business days.
In order to best serve the Columbia community, please request 20 items or fewer per day.  Contact recap@library.columbia.edu with questions and comments. Thank you for using Offsite collections."

7/12/10 EDD Citation Requirement

Due to a change in the way reports are generated, ReCAP staff requested that CUL adjust the requirements for Start and End Page fields for EDD requests.  The changes cause negative numbers to appear in reports, affecting both page count and overall tallies.

The citation data must be able to:

  • subtract the start page from the end page and output a whole number (non-negative integer)
  • Start and End Page fields can not be blank
  • Start and End Page fields can not both be "0"
  • Non-numeric pagination (anything) can be entered in the Other Identifying Info field

Test link: https://www1.columbia.edu/sec-cgi-bin/cul/offsite/vie3?type=PUBL&key=779142

*** An entry must be present in at least one of the first four fields or the last field: 1) Volume#, 2) Issue#, Date, 3) Article Author, 4) Article Title or 5) or Other Identifying Info.  Any character(s) will suffice.

*** If data is entered in Other Identifying Info field and Start/End Page are left blank or "0", a value of "1" is automatically substituted.

The following screen shots are taken from citation entries that are invalid.  Please review the pop-up messages.  Alternatively, use the test link to experiment.


8/25/2010 Reaccession of Offsite Barcodes

Resolution: Columbia will not reaccession any barcodes.  Any withdrawn barcode will be returned by ReCAP staff to the ReCAP Coordinator. 

As part of the orphan barcode project at the East Asian Library it was discovered that permanently withdrawn barcodes had been reaccessioned at ReCAP**.  It had long been assumed by most processing staff that there was a safeguard at ReCAP to prevent barcodes from being reaccessioned.  Barcodes had in fact been reaccessioned at ReCAP since 2002.

**Many of these items also had other, unrelated database maintenance problems.


Case in hand, barcode CU01248782

This is the first volume of a two-volume set (CUL only has v.1).  Barcode is present when scanned into CLIO.  Primary criteria for orphan barcodes are that they are not in CLIO.


HLDG record indicates that the item was accessioned at ReCAP the week ending 7/24/2009.


There is no request button present in the OPAC.


Item status in LAS is OUT.  This is expected; staff requested the orphan barcode in order to process.


Full Item View in LAS indicates that CU01248782 was:

Accessioned on 09/27/2004

Retrieved on 08/25/2005

PermW'd on 6/17/2009

Reaccessioned on 04/09/2010

Retrieved on 07/14/2010

ReCAP staff can reaccession items.  It allows them to reinstate items that were withdrawn in error or if a partner changes their mind.  ReCAP cannot change customer codes, but can add items back into the system with the same shelf location and customer code.  76 items from Columbia have been reaccessioned starting in 2002.

First short term agreement in late September 2010 was that moving forward no barcodes will be reaccessioned until CUL professional staff have an opportunity to discuss and consider the effects on existing documentation.


Second short term fix (9/24/2010) was to generate the GET FROM OFFSITE button for all reaccessioned barcodes.

CUL ReCAP Processing Procedures meeting discussed matter on 12/7/2010.  Desire to know more details about 1) how the request button is added back to CLIO, 2) how we can be alerted of reaccessions moving forward (since they may be suppressed/withdrawn and 3) what changes need to be made to in-house documentation.

ReCAP staff estimates they regularly see on 1-2 withdrawn items per month, a very low volume.

9/16/2010 Advance Notification of Circulation Status

In December 2010 ASCC meeting, staff agreed that preferred language is "In Library use only" instead of "Non-Circulating."  ReCAP Coordinator was asked to adjust language and bring examples to January meeting.

On January 6, 2010 unintentional implementation of change for all items with FRGL Item Note.

Conversation with Kitty:

  • "In Library use only" would preferably go in the CLIO location display as well
  • Keep language consistent on request page, submission email and delivery email
  • "In Library use only" may suggest that patron can only place "Item to Library" delivery (not EDD)
  • Circ staff may or may not declare something fragile.  Staff handling deliveries do not see encoding in record.  Items in Tyvek may *not* be fragile.
  • If item belongs to a restricted collection (BIBL#4730083)
  • If item has FRGL in the Item Note field (BIBL#4623586)
  • If item belongs to a restricted collection and has FRGL in the Item Note field (BIBL#4644704)

In response to user feedback, staff are looking for ways to better indicate the circulation status of an item at ReCAP.  Patrons are sometimes surprised to find the item they requested is In library use only (non-circulating).  Staff are sometimes confused about which items do and do not circulate.

Circulation status of a ReCAP item depends on encoding in CLIO (Item Type "noncirc" or "same") and physical condition.  Some ReCAP collections are entirely non-circulating.  Others collections vary book to book. 

Discussion at July 2010 ReCAP meeting focused on how communication could be improved.  Options included linking display messages to customer code, Item Type or Note field content.  Customer code was agreed to be unfeasible.  The physical condition of an item changes over time, leading to complications for staff assigning and re-assigning barcodes (customer codes).

Current modes of communication about circulation status


ReCAP collections that are entirely non-circulating have a note in the CLIO Location display

Location display is assigned according to CLIO location. 

  • Avery Library example (off,ave)
  • Burke Library (off,utn)

There is nothing in the Request It from Offsite web form to indicate that an item is In library use only or non-circulating.


There is nothing in the initial e-mail alert sent at time of request.


The e-mail notification sent once the item arrives contains a note about circulation restrictions. 


The note is located at the bottom of the e-mail.

Potential changes


Use the Note column on the Request It from Offsite web form to indicate that an item is In library use only or non-circulating.


Currently, if an ITEM record Note field has content DO NOT REMOVE: FRGL the column displays "Item to Library" request only.

The message is intended to discourage the user from placing an EDD request for the damaged item.

  • Can a message about circulation be displayed based on Item Type or Note field content?
  • Can something be added to the initial e-mail alert sent at time of request?


ReCAP User Inquiry Alias: recap@library.columbia.edu

Supervisor, ReCAP Access Services: Jennifer Loubriel

Phone: (212) 854-3542

E-mail: jll2223@columbia.edu