Dilettante's Ball

On unAPI

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:

  1. 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.
  2. 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.
  3. I see no point in sending the status along with the response.
  4. This is, indeed, much simpler than making an OAI-PMH server in PHP over Voyager.
  5. 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.

Posted

in

, ,

by

Ross

Tags:

Comments

4 responses to “On unAPI”

  1. dchud Avatar
    dchud

    First off, you kick ass for being the first to implement this.

    But… don’t you see that to ask “why do we need another sharing protocol?” and then say “why don’t we just make a simpler API” contradicts yourself? unAPI *is* the simpler API, but instead of just speaking to one of them, it lets you speak to any of those protocols. It’s just barely enough to get the basic stuff you need out of any of them, and drops the barrier for supporting clipboard-copy out of arbitrary webapps to practically nothing.

    And my point wasn’t that those other ones are too complicated for stupid
    people… it’s that if it’s not *insanely* easy for anybody to implement in no time flat, nothing like this will ever take off as a standard. Anybody who knows a tiny bit of php and can read the apache docs can set up a combo of rewrites and json responses for unapi layered over wordpress, for instance. Oh, and that *nobody* cares about our wacky library jargon. The mountain ain’t movin’.

    Much love, -dchud

  2. Ross Avatar
    Ross

    Actually, my strength is not the ass-kicking, it’s more the name-taking.

    And I don’t think I’m contradicting myself. The “API” to request this information has nothing to do with the information (or the protocol to receive the information) itself. There are two components here. The “request method” and the response.

    Where I think the value of unAPI lies is in simplifying the “request method”.

    Think OpenSearch.

    OpenSearch created a new “API” to “simplify” creating “dynamic RSS feeds” contextually (specifically, based on query terms). A9 (thankfully) didn’t bother to create a new protocol to enable this, they used the widely available RSS 2.0 (and, now, Atom). They did, however, create a new “interface” to RSS.

    I see the same method applicable to unAPI. Create the structure around the “request” and borrow a “response”.

    As I’ve already stated, implementing unAPI was easy. That’s not my argument. I just don’t want to see the very real and tangible value of unAPI wasted because the momentum of Atom is stronger or is spoken from the lips of people that have the attention of more ears.

    I realize that they’re not incompatible, but, realistically, people aren’t going to implement both. All I ask is that we consider a widely deployed syndication protocol and use unAPI as a means to leverage that more effectively.

    It changes nothing about unAPI except the actual response document.

  3. Edward Vielmetti Avatar
    Edward Vielmetti

    The OPAC jabberbot was 20 lines of new code to start, based on an existing RSS interface and some existing libraries and an existing jabberbot client. I tried to do the same thing to a Z39.50 catalog which I didn’t have borrowing priveleges from, so when it didn’t work too well I bailed.

    Any time you can compose a new service out of 20 lines of user code you’re doing pretty well. ATOM and RSS can be really easy to wrap results in because of widescale deployment of code that understand how to unwrap that data. I’m led to believe that Opensearch will start to become more ordinary once IE 7 hits the streets, but again if it’s you (as a patron) writing this code you might not want to wait to bother until the library finishes their development. (Hence the ad hoc screen-scraping that goes on for amazon librarylookups…)

  4. Ross Avatar
    Ross

    Edward, I think you’re missing my point. I understand one-off fun things (after all, our resident #code4lib bot, Panizzi, is full of things only a library geek could love — Name Authority lookup, anyone?). No, I completely understand that — that being said, a better use of time would be writing an OpenSearch widget for the OPAC (since you’ve got the RESTful interface anyway) so that the jabberbot could then search the universe of OpenSearch targets (Wikipedia, PubMed, RedLightGreen, etc.) and also AADL.

    Our markets are so freaking small that making people come to us (and library toolbars, bookmarklets, jabberbots, etc. mean coming to us) is a losing battle; why don’t we better make our stuff go to them?

    To try to put it in better perspective, what would you rather have in your pocket? A do-it-all Swiss Army knife? Or a toothpick (note: the Swiss Army knife has a toothpick, too)

Leave a Reply

Your email address will not be published. Required fields are marked *