So we all agree, it would be better for everyone if all ILSs had an API – well most of us anyway.
The road to this enlightened agreement has been a long one. Back in 2005 John Blyberg, then at AADL put forward his ILS Customer Bill-of-Rights containing demands such as “Open, read-only, direct access to the database” and “A full-blown, W3C standards-based API to all read-write functions“. John soon followed this up by producing PatREST an API on top of Ann Arbour’s Innovative Millennium system.
Winding the clock, and lots of blog posts, forward a couple of years and there is enough momentum for the DLF to set up it’s ILS Discovery API Task Force. This group following a survey, have come up with a Draft Recommendation for the functionally of an ILS API.
Wind on again to March 6th 2008 – the recommendations are discussed in a meeting in San Francisco attended by many of the library system vendors, open source projects and other interested parties (Serials Solutions, Proquest, Ex Libris, CDL, Endeca, III, NLM, LoC, University of Maryland, UCLA, OCLC, Vanderbilt University, Oregon State University, XC, Bibliocommons, VuFind).
The word from the meeting is that the vendors appeared to be luke-warm to say the least about the proposals – pushing for any circulation functionality, holds etc., to be removed from the spec. I understand that one vendor claimed that it would not be possible to harvest MARC records from their system.
Wind back a tiny bit to a breakout session at Code4lib 2008, hosted by Emily Lynema (previous Talking with Talis guest). This was a very positive meeting with discussion about the way we could all come together to turn the recommendations in to a reality. There was consensus that the Open Source community could have a significant part to play in this. A common theme in this session was that there could be little help for this expected from the established ILS vendors – as appears to have been confirmed in San Francisco.
A suggestion was made that an open community could share ways to access both Open Source and commercial ILSs. This would then help others build ILS specific connectors for implementations of the DLF standard API. Then came the jaw-dropping question – “could such contributions to the community be made anonymously, so that the person making it would not bring retribution down on them, and their employer, from their vendor?“.
Have we really come to such a sorry state in parts of our industry that efforts to open up access, to data in University and Public Libraries for the benefit of all library users, can only be done by subverting normal openness and cooperation. It’s their data after all!
Those that staff the vendors, which some of the library technologists at Code4lib are afeard of, have obviously never read the Cluetrain Manifesto – or at least if they did, they didn’t get it.
Markets are conversations!