The document discusses improving back-of-house processes at Nottingham Trent University Library through richer integrations between their library management system Aspire and other systems. It describes developing an API for Aspire to share data with other applications to help automate acquisitions decisions. This could include integrating Aspire data with the library's reading list system, student enrollment data, circulation history, usage statistics, and supplier catalogues to determine acquisition needs based on factors like student enrollment and usage. The goal would be to route acquisition decisions through formulas using this additional data to make the process more automated and informed. It asks for comments on the feasibility and responsibility for developing such integrations.

1. 26 June 2013
1
Enhancing life-long learning, teaching and research through
information resources and services

2. 26 June 2013
2
Library review: improving back-of-house
processes through richer integrations
Richard Cross, Resource Discovery and Innovation Team Manager
Nottingham Trent University Library
Talis Aspire User Group | Nottingham Conference Centre | June 2013

3. 26 June 2013
3
Agenda
• Aspire and the acquisitions process
• Issue of Talis’ role and local role in integrations and data-sharing
• First pass with the Aspire API – what works and what’s missing
• What might an improved service deliver?

4. Aspire not an acquisitions engine
• Issue is integration, connectivity and
data sharing between Aspire and other
applications which support and inform
acquisitions
• Talis needs to develop Aspire APIs and
basic connectivity
• Unlikely that Talis can (or will want to)
develop integrations for all available
LMS, VLEs and other systems
• So where does responsibility for richer
customised interconnectivity reside?

5. 26 June 2013
5
Assumptions and progress to
date

6. Working assumptions
• Aspire needs to provide helpful APIs, making available data on
– Modules
– Lists
– Temporal associations
– Stages
– Items (by ISBN, ISSN, LCN, DOI)
– Type
– Importance
• Aspire needs to support inclusion of customer link outs (primarily at
the item level) using identifiers
– http://myresourcelistscript.university.ac.uk/script?ibsn=<aspire_isbn>
– http://myresourcelistscript.university.ac.uk/script?lcn=<aspire_lcn>
– http://myresourcelistscript.university.ac.uk/script?doi=<aspire_doi>

7. Take that data from Aspire and run queries
through other systems
26 June 2013
7

8. 26 June 2013
8
First pass: enter Relic

9. Relic
• http://urko.org.uk/library/rlms/relic/index.php

10. 26 June 2013
10
Relic only goes part way…

11. Relic
• Functioning integrations
– Item linking Aspire API
– LMS inventory
– CrossRef
– OpenURL full-text and provider integration
• Restrictions with Aspire API
– No ability to filter by temporal association
– No ability to return item importance
• Only basic integrations with:
– Vendors and agents web sites
– Related ISBN service
• No integrations with:
– Student enrolment system
– Circulation or usage data

12. What if?
• To better support acquisitions processing, the NTU library has been
thinking about what a richer integration would offer
• Visited Loughborough University library to discuss the local back-of-
house developments they have produce to support the open source
LORLS (Loughborough Online Reading List System)
26 June 2013
12

13. 26 June 2013
13
Relic 2.0?

14. 26 June 2013
14
Key drivers for NTU Acquisitions process
• e-Preference model
• Purchase to total cohort requirement
• Formula for purchase decisions: leverages importance and cohort
• Item level discretion minimized; decision processes automated as
for as possible

15. 26 June 2013
15
Enrolment
Need to
• Use Aspire API to retrieve all current module matches for an item
• Establish a snapshot authority source of student enrolment (pulled
from the VLE; possibly previous day’s data)
• Run a real-time query against source to return cumulative
enrolment count
• Display and make available to Relic script the enrolment counts

16. 26 June 2013
16
Circulation
For loanable items in library inventory
• Establish a snapshot database containing the circulation history of
all items
• Run a real-time query against this source to return specified loan
and renewal history for this item
• Display and make available to Relic script the circulation history
(probably mapped temporarily)
• Calculate ‘loan density’ for all copies – potentially to influence
formula calculations

17. 26 June 2013
17
Electronic usage *
For electronic items already held
• Authority sources for COUNTER (JR1, BR1 and more) data are
already maintained
• Run query on usage using ISBN to return usage data and turnaways
(useful where simultaneous user restrictions exist)
• For ISSN, in combination with SFX/OpenURL API check on usage
and on whether access is direct or part of aggregator package
* most speculative…

18. 26 June 2013
18
Suppliers
For purchasable items
• Run a real-time query against provider catalogues (or preferably
matching meta-catalogues) to return XML, JSON et al response
• Get access to rich metadata, including price, format, concurrent
access levels, license, etc.,
• Display and make this data available to Relic (running it through
some pre-set indicators to calculate preferred provider)

19. 26 June 2013
19
And so?
With this enriched and extended set of data, Relic would know
• which current resource lists an item appeared on
• the importance values of each occurrence of the item
• the total student cohort will a call on the item
• the use history of an item already ‘in stock’
• vendor availability (type, format, price), and preferred supplier

20. 26 June 2013
20
And then?
Using a range of variables, Relic could then
• route the potential acquisition decision (using a range of variables)
through different formula
• formula could fork based on range of options (subject area,
resource type, preferred supplier)
• produce a simple acquisition decision
• [later, could potentially integrate with EDI workflows to populate an
order]

21. 26 June 2013
21
Issues and questions?
• Does this sound plausible and appropriate or unnecessarily over-
engineered?
• Are other Aspire customers thinking along broadly similar lines?
• How much work should customers expect Talis to deliver?
• What about customer sites who do not have local technical
expertise?

22. 26 June 2013
22
Comments?
NTU Resource Lists
http://resourcelists.ntu.ac.uk
Richard Cross
Resource Discovery and Innovation Team Manager
Nottingham Trent University Library
richard.cross@ntu.ac.uk