Library review: improving back-of-house processes through richer integrations (Richard Cross, Nottingham Trent University)

1,014 views

Published on

Library review: improving back-of-house processes through richer integrations (Richard Cross, Nottingham Trent University)
How far can Talis develop back-of-house integrations joining Aspire to other local library and information systems, and how much integration will customers need to develop for themselves? This session presents an outline of the technical developments being planned at Nottingham Trent University to integrate Review data in Aspire with other sources of library data and intelligence, to improve informed, process-driven acquisitions decision-making. Does our thinking make sense? Does it sound technically feasible? Is this work that customers should expect Talis to deliver for us, or will customised acquisitions' integrations be something for customers to self-manage?

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,014
On SlideShare
0
From Embeds
0
Number of Embeds
22
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Library review: improving back-of-house processes through richer integrations (Richard Cross, Nottingham Trent University)

  1. 1. 26 June 20131Enhancing life-long learning, teaching and research throughinformation resources and services
  2. 2. 26 June 20132Library review: improving back-of-houseprocesses through richer integrationsRichard Cross, Resource Discovery and Innovation Team ManagerNottingham Trent University LibraryTalis Aspire User Group | Nottingham Conference Centre | June 2013
  3. 3. 26 June 20133Agenda• 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. 4. Aspire not an acquisitions engine• Issue is integration, connectivity anddata sharing between Aspire and otherapplications which support and informacquisitions• Talis needs to develop Aspire APIs andbasic connectivity• Unlikely that Talis can (or will want to)develop integrations for all availableLMS, VLEs and other systems• So where does responsibility for richercustomised interconnectivity reside?
  5. 5. 26 June 20135Assumptions and progress todate
  6. 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 atthe 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. 7. Take that data from Aspire and run queriesthrough other systems26 June 20137
  8. 8. 26 June 20138First pass: enter Relic
  9. 9. Relic• http://urko.org.uk/library/rlms/relic/index.php
  10. 10. 26 June 201310Relic only goes part way…
  11. 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. 12. What if?• To better support acquisitions processing, the NTU library has beenthinking 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 sourceLORLS (Loughborough Online Reading List System)26 June 201312
  13. 13. 26 June 201313Relic 2.0?
  14. 14. 26 June 201314Key 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 asfor as possible
  15. 15. 26 June 201315EnrolmentNeed to• Use Aspire API to retrieve all current module matches for an item• Establish a snapshot authority source of student enrolment (pulledfrom the VLE; possibly previous day’s data)• Run a real-time query against source to return cumulativeenrolment count• Display and make available to Relic script the enrolment counts
  16. 16. 26 June 201316CirculationFor loanable items in library inventory• Establish a snapshot database containing the circulation history ofall items• Run a real-time query against this source to return specified loanand 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 influenceformula calculations
  17. 17. 26 June 201317Electronic usage *For electronic items already held• Authority sources for COUNTER (JR1, BR1 and more) data arealready 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 usageand on whether access is direct or part of aggregator package* most speculative…
  18. 18. 26 June 201318SuppliersFor purchasable items• Run a real-time query against provider catalogues (or preferablymatching meta-catalogues) to return XML, JSON et al response• Get access to rich metadata, including price, format, concurrentaccess levels, license, etc.,• Display and make this data available to Relic (running it throughsome pre-set indicators to calculate preferred provider)
  19. 19. 26 June 201319And 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. 20. 26 June 201320And 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 anorder]
  21. 21. 26 June 201321Issues 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 technicalexpertise?
  22. 22. 26 June 201322Comments?NTU Resource Listshttp://resourcelists.ntu.ac.ukRichard CrossResource Discovery and Innovation Team ManagerNottingham Trent University Libraryrichard.cross@ntu.ac.uk

×