After arguing with Dan for hours on how to implement unAPI, I decided to take him up on his request and implement an unAPI service for our OPAC. This way I would have some real world experience to back up my bitching.
So, here you go. This script takes our SRU to OpenSearch services for the OPAC and the Universal Catalog. I’ve modified the OpenSearch CGI to include the unAPI identifier.
The unAPI service is written in PHP and calls the SRU service and presents the results accordingly.
So, my reactions:
- The JSON requirement doesn’t really bother me. Whatever is chosen is rather arbitrary, so I’m ok with JSON. I’d be just as ok with XML or text delimited. I see no real difference.
- I am not entirely convinced that just exposing the metadata (with no wrapper) is scaleable. I’m not saying I can’t be convinced, I’m just saying I’m not currently.
- I see no point in sending the status along with the response.
- This is, indeed, much simpler than making an OAI-PMH server in PHP over Voyager.
- I would really prefer parameters to paths. I think there are too many assumptions about the implementor (and the future) to use paths.
What I am still not entirely sure about fundamentally, however, is why we need another sharing protocol. Dan claims it’s because OAI-PMH and ATOM are still too complicated for stupid people and the less technically inclined to pick up and he wants something simpler.
What I don’t understand is why we don’t just make a “simpler” API to one of those protocols. Choose a particular syndication protocol (after all, that’s really what OAI-PMH is) and then just make an API to “Gather/Create/Share” with it.
Personally, I am much more interested in making our OAI-PMH archives and our SRW/U servers available via ATOM, much like we made SRU available to OpenSearch. That way we pick up on the wide variety of tools already out there.
This interests me on other levels, since I’m really starting to picture the Communicat as a sort of ATOM store.
I see a lot of potential with unAPI (a whole hell of a lot of potential), but I would rather utilize an existing protocol (especially one that promises to have a lot of users, read: ATOM) than build another library system that is largely ignored outside our community.
On a related note, I want to point out what I see as two wastes of library developers’ time:
- Walt is right: DON’T MAKE LIBRARY TOOLBARS (it’s in there, trust me). It’s asking too much to expect people to install and use something that has such a limited scope.
- The OPAC jabberbot follows the same line of thinking. In #code4lib, our resident bot (Panizzi) employs an OpenSearch client. Honestly, this makes tons more sense since it’s easy (honest!) to make your OPAC speak OpenSearch and there are going to be a lot more useful things available via OpenSearch than a handful of library catalogs.
No, I think we’re better served making our data work contextually in a user’s information sphere. Push our data out to common aggregators rather than replicate the services to handle our arcane practices.