Lorcan Dempsey's weblog: A palindromic ILS service layer

A palindromic ILS service layer

January 20, 2006 • Categories: Libraries - distributed environments

Maybe we need an ILSSLI. That's ILS Service Layer Interfaces, or maybe ILS Service Layer Initiative.

Lots of things have come over my horizon recently where interesting interfaces are talking to the integrated library system in the background. Here are some:

There is the much lauded NCSU catalog which needs to communicate with ILS data and services. It is likely that other configurations of this pattern will emerge, where libraries source discovery functionality separately from the ILS.
There is the very nice Greasemonkey experiments of Dave Pattern, surfacing catalog information in the Amazon interface. Richard Wallis also shows some Greasemonkey scripts in action where library functionality is presented in Amazon.
OpenWorldCat and RedLightGreen interact with library systems.
Close by, Thom has been working to bring up the Phoenix Public Library catalog data in his classified/frbrized livesearch interface. He needs to drop into the Phoenix catalog at various stages if he is to provide a fully featured experience.
John Blyberg has described a REST interface to his system (see the interesting discussion in the comments to this post). He has also intriguingly suggested that he plans to build APIs to which his patrons might write applications.

We are seeing a growing need to be able to interact with the ILS in various ways, so that some functionality can be placed in another interface - to show status of an item, to place a hold, to do lots of things. Interestingly, many of these are examples of the need to interact between a backend system and a loosely coupled discovery engine. Now, we have some existing protocol-based approaches which are variably implemented. And we have a range of local fixes, proprietary deep-linking syntaxes, brittle scraping, and so on.

Maybe it is time to think about defining a service layer to the ILS that would allow some of these things to be done in more routine ways, and which increases the portability and scope of current solutions.

Clearly there is much that could be contributed to this exercise. And many organizations, including OCLC, have requirements in this area. In the long term there would be benefits in some consistent lightweight approaches, potentially alongide the existing B2B style approaches that rely on our well established protocols. Maybe this is something that might be moved forward in the VIEWS intiative? Given that various ILS suppliers and others come toghether there.

Discover, locate .... vertical and horizontal integration

Bookmark:

6 comments so far

Posted by Dorothea Salo on January 20, 2006

It's not just ILSes. I need to be able to swap data around among DSpace and Open Journal Systems and you-name-it, and the interfaces just aren't there. (OAI-PMH is no good if what you need is to link to the actual file...)

Not that I think the ILS puzzle-piece isn't vital. I just hope for a wider perspective.

Posted by Lorcan Dempsey on January 20, 2006

Sure - there are lots of places where we lack a sense of which services would be useful and how we should implement them.

I think that it is dangerous trying to do to much in any single context. The ILS environment is unified by having a small number of vendors, and by having mature well-understood functionality. It would be nice to think that you could make some progress quickly under these circumstances.

Posted by Jeremy Frumkin on January 20, 2006

A quick note on VIEWS - that initiative has evolved into the NISO Web Services and Practices Working Group (http://www.niso.org/committees/Services/Services_comm.html). As a member of that group, I like your suggestion, but I think the initial scope of work this group is addressing won't quite reach that far, unfortunately.

Posted by Edward Vielmetti on January 23, 2006

I'm building some interfaces - a mini-opac of my own, in some sense - on top of the REST interfaces that John Blyberg is creating at the Ann Arbor District Library. So far I have it generating pages that look suspiciously like card catalog cards, and today I added support for COINS.

I think but I'm not sure that the work would be readily adaptable to any library that has a SRU interface with a Dublin Core profile. Alas, I don't have borrowing privileges at any library like that.

Posted by Dorothea Salo on January 24, 2006

A use-case came up today at a consortium meeting that you may be interested in. One of the institutions hosting ETDs in a consortial DSpace repository wants to grab ETD metadata out of DSpace into Connexion (specifically, but obviously other ILS cataloguing modules are implicated too) for further enrichment and OPAC searchability.

Ideally, the metadata would flow two ways -- the submission metadata into Connexion, and the enriched metadata back into DSpace.

As things stand now, this can't be done without a lot of plumbing -- an OAI harvester to get the metadata, then a crosswalk, then an import.

Posted by MacKenzie Smith on February 5, 2006

To Dorothea and all you others who want DSpace to interoperate with other systems,
check out the lightweight network interfact that's just about ready to go... http://wiki.dspace.org/LightweightNetworkInterface
It's Web Services (both flavors) via WebDAV for your basic put/get operations. If you need this sort of functionality, don't be shy to offer your help with testing, debugging, and extending it!