Comments on: A Catalog for the “Next Generation” or the Current Generation?

By: the Jester

the Jester — Wed, 02 Jul 2008 15:12:56 +0000

Ian –

REST-based (or any API) access to read-only bibliographic data is one thing. It is, unfortunately, quite another to have API access to the internals of the item status information, being able to post transaction requests, and the like.

Although I haven’t tried it, my gut tells me that a Z39.50-to-SRU bridge isn’t exactly light-weight, either. One has the overhead of building two TCP connections (one into the bridge and one out) plus any Z39.50 connection overhead. Z39.50 servers are sometimes licensed “products” that have to be purchased, but I don’t think that is the main problem with their non-use.

By: Ian Ibbotson

Ian Ibbotson — Tue, 01 Jul 2008 12:37:56 +0000

There are certainly a couple of Z3950 -> SRU bridges out there that can be used to easily expose Z3950 databases as restful web services. AFAIK Index Data have an open source (C based) bridge and JZKit also has an open source (Java) bridge. Is the Z3950 problem to do with the semantics of the search mechanism, licensing issues with the host systems, or just that these bridges need more exposure?

By: the Jester

the Jester — Tue, 24 Jun 2008 18:43:48 +0000

Dan -- very possible. It is arguably easier to create an HTTP REST API with vendors other than Innovative, but that doesn't necessarily mean that the REST API is provided by the vendor. Still, I hope that excerpting that comment from the document as a whole doesn't detract from the fact that we need extensible APIs from ILS vendors to do "current generation" and "next generation" stuff on our own without relying on said vendors...

By: Dan Scott

Dan Scott — Tue, 24 Jun 2008 04:36:35 +0000

I agree in principle with the discussion of “current” versus “next” generation catalogs, and most of the conclusions that you’ve highlighted from the report – but the following quote made me chuckle ruefully:

“All major ILS vendors but III provide their customers a web services or HTTP REST API access to their systems, allowing for continued development around the catalog.”

What? It certainly comes as news to me that Unicorn offers either a web services or HTTP REST API access to my system. From discussions with other library world developers, it doesn’t sound like many other “major ILS vendors” offer Web services or HTTP REST API access either (except, perhaps, in the broadest, most generous definition of “Web service” where “you GET or POST to a URL and some mass of poorly formed HTML is returned). Methinks the report authors were fed a steady diet of salespeople to talk to…

I don’t think the traditional ILS vendors could point to something like Evergreen’s SuperCat RESTful interface: http://open-ils.org/dokuwiki/doku.php?id=backend-devel:supercat:examples – and that’s barely scratching the surface of what Evergreen offers today.