At the recent SummonCamp in New Orleans, there was a question about the local “Availability:” messages that appear in Summon for things like books, e.g.
Availability: available, Huddersfield (Loan Collection Floor 6 – 2 wk loan)
By default, Summon either scrapes your OPAC or makes use of an ILS/LMS API to get real time availability. If neither are available, or if the OPAC takes too long to respond, a “check availability” message appears instead (which typically links through to the item page on the OPAC).
Early on in our Summon implementation, we were concerned about the potential impact on our OPAC — SirsiDynix HIP — of screen scraping. In particular, HIP wasn’t designed to be scraped like this or to be indexed by search engines (many Horizon sites deliberately block Google et al from indexing their HIP) and it creates a new session ID for each request. As each new session takes up some of the OPAC server’s resources, there’s a theoretical limit to the number of concurrent sessions the OPAC can maintain before slowing down (or even crashing). Also, if you’ve done a search in Summon that delivers 25 book results, it takes time for the OPAC to respond to the 25 HTTP requests generated by Summon, and so you often end up getting the “check availability” message anyway.
So, working with Andrew Nagy at Serials Solutions, we implemented a very basic DLF XML web service (code and brief documentation available here) that bypasses our OPAC and pulls the live availability data straight from the Horizon database. Not only does it ensure the OPAC doesn’t take a performance hit, it’s also extremely fast (especially if you run it using mod_perl with a persistent database connection to Horizon) — you can see a typical response (for this book) here: library.hud.ac.uk/perl/summon/dlf.pl?497856
In his Code4Lib Journal article — “Hacking Summon” — Michael B. Klein talks about enhancing an availability API to include extra info and even embedded hyperlinks. This would also be a great way of including item level hold/request functionality into Summon.
At Huddersfield, we’ve done something similar to Michael for our e-resource/database level links, e.g.:
Availability: available, online resource (University network login required)
To help with known item searching, we’ve created some dummy MARC records on our library catalogue for most of the resources listed on our e-resources wiki and these get pushed out to Summon (in the same way that book MARC records do). If the user clicks on the result, they get passed through to the relevant wiki page. However, we also decided we wanted to try and save the user a mouse-click by embedding the actual URL to the resource into the availability message.
To do this, we extended the DLF script so that it detects when an incoming availability request from Summon is for one of the dummy MARC records (rather than a book). The script then does the following:
- as the link to the wiki page for that resource is part of the dummy MARC record (the 856 field), it extracts that URL up from the record in Horizon
- it then web scrapes that wiki page to extract the actual link to the e-resource (in this particular case, it’s an EZproxy’d link)
- the DLF XML is then generated, including the link: library.hud.ac.uk/perl/summon/dlf.pl?646531
One thing that we’ve not done yet, but plan to do, is to include an extra step that queries our E-Resources Blog to check if there are any known problems for that e-resource. If there were, then a link through to the relevant blog post would also be included.
Very timely, thanks.
I don’t use Summon, but I do have some Java code that does something similar to what your Perl code does (here: http://code.google.com/p/horizon-holding-info-servlet/). But I’ve been having some problems with the Java code lately — I think Java just isn’t the language for me to not screw things up in. I’m going to investigate your Perl code.
I haven’t looked at exactly what your response formats look like yet; but sadly, even though both your code and mine is a “DLF ils-di” response, I would be shocked if they were drop-in replaceable for each other, they probably make different choices about how to fill out that response, there are still a whole bunch of choices to be made in implementing a “dlf ils-di” response.
Ah, I see it is strictly limited to availability or not — you don’t include call number/location information in your perl web service response? How does Summon get call number/location information?
Yep, it’s a pretty bare bones DLF response — just enough to implement availability in Summon. Out of interest, the original DLF spec web site seemed to have vanished and I wasn’t able to find it elsewhere when I looked a few months back. Is the spec still available anywhere?
There’s no reason why we couldn’t include call number, although (for Summon) I’d probably include that in the “dlf:availabilitymsg” string to make it display to the user. At the moment, Summon displays the availability as:
For our Summon implementation, the call number is picked up from the MARC records we export, e.g.
Gidden’s Sociology