REST output from Huddersfield's catalogue

Inspiried by John Blyberg’s middleware which provides REST output from the Ann Arbor catalogue, I’ve put together something similar for ours:

http://webcat.hud.ac.uk/rest/info.html

Here are some sample results:

http://161.112.232.203:4128/rest/keyword/author/tolkien
http://161.112.232.203:4128/rest/keyword/subject/yorkshire railways
http://161.112.232.203:4128/rest/record/id/411760
http://161.112.232.203:4128/rest/record/isbn/1904633048

I’ve decided to include more information in the output than John did — primarily because I want to use the REST output to power a staff OPAC.  Amongst other things, the output includes:

The output is littered with xlink links, which can be used to issue further REST requests.

For those of you who like gory techie details, the REST output is generated by approx 1,000 lines of Perl coded as a single mod_perl handle.  The code works by fetching the XML output from HIP and then parsing it to strip out anything that’s not required in the REST output.  At the same time, extra information is pulled in from other sources (e.g. direct from the Horizon database, and from the xISBN service).

Unfortunately, looking at the XML output from other HIP servers, I doubt the code can quickly be used by other Horizon sites.  Also, not everyone has their own mod_perl server to the the code on.  However, if anyone wants to play around with the code then please send me an email (d.c.pattern [at] hud.ac.uk).  There’s also a cloud on the Horizon (pun itended) relating to getting XML output out of HIP 4 — it seems Dynix have chosen to make it harder (not easier) to do this with the latest version of their OPAC (boo! hiss!).

I’ve already said that I’m planning to use the REST output to power a staff OPAC, but what I’m really keen on is letting our students loose on the data for use in final year projects, etc.  I’m also planning to use the output for a revised version of the Amazon Greasemonkey script.

The University is gradually moving towards a portal environment and I’m hoping the REST output will come in handy for dropping live catalogue content into other systems.

There’s still quite a bit of work to do, especially with adding information for journals.  We’ve already got live journal information from our SFX OpenURL server appearing in our OPAC, so I might as well include that in the REST output too:

Have fun!


 

20 thoughts on “REST output from Huddersfield's catalogue”

  1. It looks like there might be a bug in the code, so I’ve put a fix in to force a timeout error in the event that a request takes more than 20 seconds to process. In the meantime, I’ll bash the code around with my mighty debugging hammer :-)

  2. Pingback: panlibus
  3. Seeing your post makes me wonder just how far someone outside any library catalogue can go if they have access to urlrewriitng on their own server?
    For example, i created some shortcuts into a couple of our library systems using rewrites that provide me with an easy way of making a call into the cataloge from the address line: http://ouseful.open.ac.uk/redirects.php

    Here’s another way i found of ‘command lining’ search boxes: Firefox smart keywords:http://www.mozilla.org/products/firefox/smart-keywords.html

    tony

  4. Hi Tony

    One of the features most OPACs are missing is the ability to have a simple permanent link to an item in the catalogue.

    Many will let you bookmark a page, but the URL often contains sessions IDs and many other fields that superfluous. Not only that, but you run the danger than any future upgrades to the OPAC will introduce a new URL structure that ruins your old bookmarks!

    Personally, I like the idea of URL rewriting – we use something similar to resolve the permalinks on our catalogue, although it’s basically just a bit of JavaScript that redirects to the correct page. The huge advantages is that it’s a quick tweak if an OPAC upgrade changes the URL structure.

  5. Pingback: panlibus
  6. on panlibus you said “I’m not convinced that OpenSearch meets the goals that I was trying to achieve with the REST interface” – I’d be very interested hearing what goals there are that OpenSearch cannot meet.

  7. Hi Michael

    For browsing and discovery, having to code everything into a single <description> tag just seems too limiting.

    If we were able to implement some of the browsing functionality that the answer.com sites have within A9, then I could see more possibilities. However, that would seem to imply that the output from our OpenSearch code would only be suitable for use within A9?

    Having said all that, I see OpenSearch as being a very useful tool: http://webcat.hud.ac.uk/OpenSearch.xml – the ability to search a reference site and also bring up relevant catalogue items is (IMHO) a direction that OPACs should be moving towards.

    I think what both John and myself are trying to achieve here is to create something that the majority of OPACs are sorely missing – an API layer.

    Once you’re able to easily pull content out of your ILS/LMS, then it’s (relatively) simple to reformat it as SimpleDC, OpenURL, etc. Unfortunately most of us have systems that require you to jump through programming hoops just to do that.

    At the end of the day, I’m happy to code and recode the output into whatever formats are useful. If a student can do cool things with our OpenSearch output then who am I to stop them? At the moment, my gut feeling says that a REST type output will let them do even cooler stuff!

  8. Having OpenSearch output from my school’s library is exactly what I want, actually; I hope to provide a better interface for their search, eventually.

    Anyhow, if you’re talking about the [description] within individual [item]s, then you don’t have to shove everything there. Indeed, the XML you’re already generating is virtually OpenSearch… just change [Record] to [item] and you’re most of the way there. I’m not talking about the core RSS/Atom elements, it’s extensible just as any other XML is.

  9. Hi Michael

    Many thanks for that – I think I need to take a deeper look at OpenSearch :-)

    I’ve been doing some more coding that (I hope) will allow many of the other Dynix/Horizon sites out there to take advantage of OpenSearch.

    The key (for me anyway) is getting to a stage where I can easily repurpose the data from our ILS/LMS into whatever format I want.

    With Dynix, we’re fairly lucky as most versions of their OPAC can output any page as XML — it’s not pretty XML, but it’s usable! Once you combine that with direct SQL access to your LMS database (to enrich the XML from the OPAC), and data from third party web services (e.g. xISBN), you can start doing really cool stuff.

    Cheers!
    Dave

  10. Pingback: panlibus

Leave a Reply