Way back I wrote a piece about the changing model for library catalogues, you can see it here. The main premise was that trying to maintain records in a Library Management System (LMS/ILS) for all the items you want your users to discover is no longer feasible. This is especially true in this here digital age, trying to maintain records for all the e-journals a University has access to is an almost impossible task, and LMS were not designed for thousands of MARC records to be dropped and then re-imported (i.e. sync’d) with another source. And what about all the free stuff, is an e-book not worth being discovered by users because it is free?

So let the LMS be a record of what your library physically holds, and your discovery service a place where users can find (and see how to access) resources that are of interest to their research and work. The former being just one element (albeit a major one) of the latter. Meanwhile your LMS physically holdings can be shared with other discovery systems (such as union catalogues) to show what your library physically contains.

The blog post included a diagram. Some said it was rather crude, badly drawn and basic. Its critics weren’t so kind.

But I want to focus on the bit near the bottom, a line and ‘Endnote search’ with not even a box around it. And the point has nothing to do with Endnote. (well a little bit but who’s counting).

Story 1

I had a phone call from a trainer here at Sussex. Their problem went a bit like this: When showing postgrads Endnote and reference management, a common query arose, they wanted to import multiple records from the Library catalogue in to Endnote. This seemed reasonable. She had discovered a number of ways to import records: (a) from our discovery service – Aquabrowser (b) from our traditional library catalogue that comes with our LMS – Talis Prism (c) from within Endnote.

Aquabrowser has a nice ‘export to Endnote’ button on each record, we’d set that up. But there was no way to export multiple records. Talis Prism was no better. Endnote has a feature for connecting directly to a database (in this case our catalogue) via Z39.50. (This feature can be a real bane for libraries as it looks like a real time saver to researchers but often database vendors and ‘platform’ middle men don’t support this type of connection for institutional subscribers.) This connects directly in to our catalogue and uses the stupidly complex and aging Z39.50 to retrieve results. And from within Endnote you can then easily add them to your Endnote library.

But the problem was these search results in no way reflected the results they had when using our normal catalogue, in fact they just seemed  to be of no real order. So they had to either use the web catalogue to download one record at a time, or use Endnote but with a strange set of search results which does not reflect what they found (and what they wanted to save) on the catalogue

Story 2

Sussex is about to launch an iphone app using CampusM. Very exciting. One of the developers was chatting to me and asked if our catalogue had an API which they could perhaps use in the future to search the catalogue from within the app. Now we Library geeks love standards and apis but the only one I could think of was Z39.50.

Problem: aside from Z39.50 being the most difficult thing to get your head around and use – is that, like Endnote above, the results would be not ordered, with no relevance ranking.

The issues here are the same. Neither Endnote, nor a University iphone app is trying to be a fully fledged catalogue. Even if they did have the resources to develop search relevance and rank, it would be reinventing the wheel (which can only be bad) and ultimately would differ from the results seen within our main catalogue (Aquabrowser).

What’s more, in the model described at the top, the resource discovery layer (e.g. Aquabrowser) may hold records for items not on the catalogue (e.g. if we were starting again, our e-journal records would not be in our LMS, but indexed straight in to Aquabrowser).

So these ‘thin clients’ really just want to connect to a catalogue and get back some results in XML or similar which they just have to transform in to HTML (or display in an iphone app). They don’t want to implement a full bodied search interface, and nor should they have to.

The answer is, of course, that these clients need to an API provided by the Resource Discovery system.

The good news is that I think this is already happening, a number provide XML interfaces which developers can use. Aquabrowser for example has a SRU interface (you may need to ‘browse source’ to see this) and its own XML interface, though this is not very well documented at all (thanks to Ed Chamberlain for the help in finding the url for it).

Until our front end discovery systems provide a way to allow other systems to search and retrieve results – preferably via a common standard such as SRU – we can’t expect third parties to develop new interfaces to our catalogues. Which is a shame and frankly an embarrassment. When next look at a resource discovery or web catalogue system, the ability for other systems to connect to its API and bring back ordered results will be an requirement.