Panlibus Blog


Superpatron (Ed Vielmetti) posted ‘a note to self’ yesterday entitled Zed REST. I’ve probably got my national stereotypes wrong, but surely Ed should have called it Zee REST, leaving it to the British to call it Zed REST.

Anyway, Ed was musing as to the possibility of writing a Z39.50 adaptor so that research library catalogues could export a PatREST(pdf) interface for public use. In that way a simple client could be constructed to talk to a wide range of catalogues, without having to mess about with horribly binary encoded formats.

He then goes on to add:

A variant on this theme would be SRU REST, which would start from SRU/SRW and export PatREST on the user side.

The implicit message of this being, that as SRU is a RESTful interface that returns XML, it would be far easier to work with. This is most certainly true.

It is no accident that in the recent free upgrade (which I talked about earlier) to Talis’ own product range, we are providing open access to Z39.50, SRW & SRU by default. If you already have a Z39.50 client, by all means continue to use it. But if you are starting from scratch, don’t touch it with a barge-pole go for SRU if you have the option.

So Ed, as a footnote to your note, can I suggest you start with SRU, and then look at a way of getting Z39.50 targets visible via SRU. Then you only need to build one PatREST adaptor. Ah the joy of reuse, very Library 2.0!

Where do I get a Z39.50 to SRU adaptor from to make this possible? – You get Yaz Proxy.

Yaz Proxy from the Danish company Index Data, is a GPL licensed application which amongst other things provides “SRU/SRW server function, to allow any Z39.50 server to also support the ZiNG protocols“.

With its in-built XSLT capabilities this could be just the thing to to get Ed closer to his ambitions without having to mess with those with horribly binary encoded formats.

The only thing a would question, is why invent a PatREST search standard, when a perfectly serviceable RESTful search interface is, or can easily be, made available for the many visible Z39.50 catalogues? I’ve studied PatREST, which as a work in progress has a lot going for it and John Blyberg should be praised for his efforts in producing it, but looking at the searching elements of the standard I can’t help feeling that SRU has solved many of the issues that PatREST may have difficulty in solving. Things like the ability to request an Author + Title search, or a search limited by published date ranges.

Don’t get me wrong, as I have said before SRU/W is not perfect, but I think it addresses many of the search query issues that may come to haunt PatREST, OpenSearch, and other ‘simple’ search protocols. Maybe there should be some combining of standards going on in this area. I wonder what happened to this initiative?

Technorati Tags: , , , ,

2 Responses

  1. John Says:

    I agree with you that SRU is a much more sophisticated specification. I use it myself on a number of back-end processes that actually go into the implementation of AADL’s PatREST interface. PatREST is not trying to be like SRU at all, however. While designing it, I had simplicity and ease of use in mind–SRU can be a tricky beast to navigate, so I wanted to make a development interface available to amateur scripters who may not have a firm grasp on xpath. The idea is to make it “friendly” and so far, that has meant neglecting the ability to produce those types of refined searches you’re talking about. I’ve been toying with different ways of addressing that, but I’m not convinced it’s a major necessity since it’s just as easy to grab a result set and refine it in code anyway.

  2. DeWitt Clinton Says:

    You ask:

    I wonder what happened to this initiative?

    Fair question. I admit that I haven’t personally been focused much on OpenSearch/SRU interoperability lately. Though I do still think it a worthy goal.

    The positive news is that we’ve built out the beginnings of a community-oriented site for OpenSearch efforts over at:

    I hope that this site can be a place where, at least as far as OpenSearch is concerned, we can see the collaboration begin.

Leave a Reply