Panlibus Blog

Which API – yours, mine, everyone’s?

Remember me? I used to occasionally post on this blog 😉  – Jet-lag, an excellent conference, and an in-box to die for seems to have been keeping me away lately.  Sometimes a period of ‘just letting the news wash by’ can be helpful in picking up on the themes of the moment as against the day to day hot topics. [That’s my story and I am sticking to it 😉 ]  By the way thanks to Rob Styles on this blog and Owen Stevens on Overdue Ideas for their coverage of the Talis Insight 07 Conference.

The theme that has floated to the top lately has been that old favourite the Library System API.  I have been banging on about APIs for Library Systems for what seems forever – well at least since summer 2005.

Whilst rushing around the USA recently, I met with Patricia Martin, at the California Digital Library, and John Ockerbloom at the ICUDL 2007 meeting.  Both Patricia and Mark are involved with the DLF ILS DS initiative to ‘analyze the issues involved in integrating “integrated library systems” and discovery systems, and create a technical proposal for how such integration should be accomplished’‘ This is at an early stage at the moment in defining generic functions that ILSs will need to support to allow integration with discovery and other systems.

In Roy Tennant’s recent presentation at CODI 2007, he proposed a Library Software Manifesto in an attempt to rationalize the relationship between libraries and library systems vendors in which one of the consumer rights is:

I have a right to the API if I’ve bought the product. — An application program interface (API) is simply a structured way for one application to communicate with another. In other words, the ability of a software program to send a structured query to another application and receive a structured response. Using the API for a product I’ve bought should not incur an additional charge.

Brushing the dust off my ‘traditional’ library system vendor hat, I can see how that might ruffle a few feathers.  If your system already has APIs, you should be able to get at them; any new systems produced without APIs would be a case of architectural suicide by the vendor; which leaves the systems that need APIs grafting on to them, which is not an insignificant or low cost task.  As to any costs of supporting a library depending on the APIs they supply – that of course will be up to a vendor to justify.

Peter Brantley [Taliking with Talis Podcast interviewee], over on O’Reily Radar, reports on a presentation at the Digital Library Federation’s Fall Forum in Philadelphia, by NCSU Library’s Tito Sierra, Markus Wust, and Emily Lynema who presented their “CatalogWS” which is a web service that runs against a derivative of their library catalog, provided by Endeca, to provide a suite of really nice new-generation library interfaces.  – Yet another RESTful API set providing search and availability from their catalogue.

Just like the plethora of library APIs that have been offered to the world over the last few months in including John Blyberg’s PatREST, they are all excellent and useful when wishing to integrate with a specific library, or possibly library system.

We have to be realistic, if we want people to go to the trouble of integrating library systems in to other services, student portals, e-learning systems, library web sites, browser plug-ins, gadgets & widgets of all sorts, and the like, we need to make it easy for them otherwise they will go off and do something else interesting.  So for instance John Blyberg added PatRESTwww to the AADL system and used it create his go-go-google-gadgetSuperPatron also used it to build a LibraryLookup style browser plug-in to show Ann Arbour held books in Google book search.  But that is where it stopped.

No doubt a few people interested in what NSU holds will utilise CatalogWS to do some cool stuff, but that will probably also stop there.

What we need is easy to understand [by the non-library tech-geeks] consistent ways to integrate with a library system, regardless of the vendor, or open source project team, that produced it.  Sounds like a standard you might say.  The library world are good at standards you also might say.  – Pop the documentation for Z39.50 or NCIP under the nose of the average web developer to soon see that that is an over optimistic theory.

There are some standards that have taken off over recent years, OpenURL [well until they tried to improve it] OpenSearch, and to a lesser extent SRU.  These are understandable to non-library folks, and, mostly, are not coloured by any of that library or vendor specific profile stuff which make other standards so horrid and unworkable.

I am looking forward to the results of the deliberations of the DLF ILS DS initiative in the hope that they come up with something we can all follow, but even then we need a, preferably Open Source, reference implementation of these APIs that everyone can develop against.  In the same way that Apache Tomcat, as the reference implementation for servelets, drove the development of the many other open & closed source products that were measured against it; we need an open source reference implementation of ILS APIs.

We at Talis have a great deal of experience [Talis Keystone] integrating library systems using RESTful APIs, with other systems including student portals, e-Payment systems, and finance systems.  We are more than willing to share some of this with the right Open Source project to benefit the whole library community – if you have any thoughts on this or want to discuss it further drop me a line – richard.wallis@talis.com.

Technorati Tags: , , , , , , , ,
Photo published by tsmyther on flickr

Leave a Reply