4. Columbia’s Problem
Some background:
• Columbia Libraries = big, federation of many libraries
• Electronic subscription resources = lots, expensive
• Assessment of subscription e-resources is hard
The problem:
• Assessment of electronic subscription resources was great in some libraries, less
great in others
• There wasn’t much guidance for assessors who wanted it
• Data is available for assessors, but they must proactively get it themselves
The solution:
• Some push technology that enforced a 5- and 3-month pre-renewal assessment
schedule.
5. Wait. Why push?
Push (instead of “pull”) means the data goes to the people,
instead of people needing to go to the data. Fantastic!
Email, pop-ups, etc, are examples of push technology. Oh.
Note that push technology can backfire
because it can be very annoying, in which
case people will block/ignore it.
It works best when it fits into existing
workflow, and when users get exactly
what they want.
6. Columbia’s Pick
• The Libraries had just completed a transition to Google
Calendar.
• Available to all staff
• Staff were already using heavily to manage schedules
• This made ninja-push possible
• Staff had been recently trained
• IT Staff were (somewhat) experienced with the API
• Cheap! (free)
7. ! gCal Caveats
• Reminders at most 4 weeks in advance
• The http API is slow
• The API is limited
• http requests can be interrupted
• Google is “in the cloud”, man
• Data privacy!
Understand: Columbia is using “Google Apps for your
Domain”, Education edition, which is different from a
consumer Google account, especially in terms of privacy.
Is gCal the best choice for you? Maybe.
8. Our App in GCal
• Each fund code is its own calendar
• These are secondary calendars under the “_backup”
service account, so they must be added to the global
address book
• Any Columbia Libraries staff can view any fund calendar
• A user begins typing “Fund Code …” and the calendar pops
up
• A user can subscribe themselves to receive email or pop-up
reminders for a code/calendar or a resource/event
• Assessment working group members receive a monthly
emailed report on who is subscribing to what
9. Expenditure = 3 events
• Each fund may have hundreds of expenditures!
• Each expenditure is entered once, on the day it happened
• 5-month and 3-month renewal reminders (for non-negative expenditures)
• (There is no expiration event.)
Sample calendar event:
On 10/27/2011:
Title: renew Asian philosophy $XXX by 01/26/2012
Event data:
(three months reminder) 2035E 1AEM2727 20110126 Asian philosophy.
1 Abingdon, Oxfordshire : enk expenditure $XXX
9123215 ags1 EBS29 USD $XXX CUL 11 EBSCO
[1: 20(01/11)-21(12/11) - PRINT + ONLINE] [Start Date:
2011-01-01] [End Date: 2011-12-31]
13. Subscriber Report…
Subject: Fundcode Calendar Subscribers (30 total)
From: nco2104@columbia.edu
Here's the latest list of people subscribed to at least one fund calendar. This is an
automated message.
1. Xxxxx Xxxxxx
(2038E, 4317E)
2. Xxxxx Xxxxxx
(2235E, 2235EO, 2242E, 2248E, 2248EO, 2464E)
3. Xxxxxx Xxxxxx
(2011E, 2029EO, 2462E, 2462EO, 2464E, 2465E, 2564E)
4. Xxxxxx Xxxxxx
(2040E, 2462E, 2462EO, 2463E, 2465E, 6255E)
5. […]
14. Data into Google
• Choice of python somewhat arbitrary: Google has good,
well-supported APIs for:
• python
• .NET
• Java
• And other APIs for:
• php
• javascript
• ruby
• See http://code.google.com/apis/calendar/
15. Data from Voyager
• I opted to keep the current perl scripts that were producing
“Excel” reports from Voyager’s Oracle backend, and to
extract the data from those.
$sql = "SELECT DISTINCT FUND_TRANSACTION.TRANS_TYPE,
FUND_TRANSACTION.AMOUNT, TO_CHAR(FUND_TRANSACTION.TRANS_DATE,'yyyymmdd'),
FUND_TRANSACTION.TRANS_DATE,
FUND_TRANSACTION.OPERATOR_ID,
FUND_TRANSACTION.REFERENCE_NO,FUND_TRANSACTION.NOTE,
FUND.INSTITUTION_FUND_ID, FUND.FUND_NAME, FUND.FUND_CODE,
FUND.FUND_ID, FUND.EXPENDITURES,
LEDGER.LEDGER_NAME
FROM $database.FUND_TRANSACTION, $database.FUND ,$database.LEDGER
WHERE FUND.FUND_CODE = '$fundcode' AND
FUND.FUND_ID = FUND_TRANSACTION.FUND_ID AND
( FUND.LEDGER_ID = '29' OR FUND.LEDGER_ID = '30') AND
FUND.LEDGER_ID = FUND_TRANSACTION.LEDGER_ID
AND FUND_TRANSACTION.LEDGER_ID = LEDGER.LEDGER_ID
ORDER BY FUND.FUND_CODE,TO_CHAR(FUND_TRANSACTION.TRANS_DATE,'yyyymmddhhmiss')";
16. Why not?
• customer service, support, history
• http API verses monolithic DB-to-xls dump
17. Script Structure
• Find all current Fund Codes
• Create any new Fund Code calendars
• Add any new calendars to global address book
• Take new list of fund code calendars
• For each calendar,
• download list of this fiscal year’s events
• compare to current cumulative file of transactions
• add any missing events and any missing reminders
… everything but the first item is an API call. The script is
designed to expect to fail, and to be able to be run over and
over.
18. Helper Scripts
• For the times your script has made bad entries/duplicates:
• Address book cleaner
• Something to delete calendars matching criteria
• For when the business logic changes:
• Something to empty calendars or selectively empty
calendars
• Something to list users subscribed to calendars
19. Other Resources
• Email me at nco2104@columbia.edu!
Google Calendar as manual reminder app:
• http://www.libraryinnovation.org/article/view/23
Google APIs: http://code.google.com/apis/
Columbia’s renewal reminder application:
• See poster about renewal app at http://hdl.handle.net/
10022/AC:P:9978 (includes link to code)
• Article will be available in JERL Volume 24, Issue 2
