Demonstrations and Code

Last month I had the pleasure of participating on a panel with Jason Griffey from University of Tennessee Chattanooga and Eliot Polak from Norwich University on Plugin and Play Apps. We talked about how the WorldShare Platform can enable libraries to build and share cool custom apps with one another. Jason talked provided an intro to the concepts of platforms and their power.

The last prototype application I built was the New York Times Bestseller application. This application is a riff on one of the potential Platform applications demonstrated at last year's ALA. The "Bestseller App 2.0" allows a library to select a given New York Times Bestseller list and see which items from that list the library doesn't currently own. Then a user can select which of these items should be purchased and how many copies should be purchased. An Amazon cart with these items is then created as is a WMS order.

The first application that I built off of the prototype WMS Acquisiton web service was the Amazon Order application. As I've explained in my basic overview of the Platform prototype application, the purpose of the Amazon application was to take an existing WMS order and send that order to Amazon, creating a shopping cart.

The first thing that the application does is generate a form screen which allows the user to input and existing WMS Acquisitions Purchase Order number.

The purpose of the Alibris application is to allow a library to upload a tab seperated file of titles available in a particular topic area from Alibris, see which titles the library does not own, and then select titles for purchase. The first thing the application does is generate a form which allows a user to input their library's OCLC symbol and upload a tab seperated (TSV) file to the server

In the webinar "Introduction to Web Services" last week, I talked a little bit about HTTP Headers. These are bits of somewhat hidden data which is passed with any HTTP request and response. I consider them hidden because when a user makes a typical HTTP request they don't active send them in the request or see them in the response.

For the last three months I've been working on the project of building three applications to demonstrate the OCLC cooperative platform. The intention was for any of these applications to be installed easily in the WMS staff interface as potential part of the Acqusitions workflow. The ideas for these apps came out of a brainstorm session I had with my boss and staff who work on the Acquisitions portion of WMS.

One of my roles with the Developer Network is to test and teach OCLC web services. While it isn't part of my job to do the regular testing of the services, there are some other things that go hand in hand with it that are: documentation and support for the services, building code examples and teaching people about the services. So when someone reports something as an problem, the first thing I do is try to replicate the issue. When my code isn't working, I fall back to making sure the service performs as anticipated. With RESTful read only services this is pretty simple.

Way back in 2007, when Facebook was new and interesting to me, as part of my work in testing how the WorldCat Search API would behave in the real world I wrote a Facebook app that would search WorldCat.  

This issue of url encoding special characters is something you want to keep in mind with any form input you send to an API. An example of this with WorldCat Search API is if someone puts in a title search like "Kate & Leopold". The ampersand in this will cause the API to throw an error message if you don't URL encode it. The wisest way to handle this is to URL encode any form input that might have any special characters in it. Things like title, keyword are likely suspects.

I'm doing a presentation on visualizing library data at ELAG this week. I'm showing off some demonstrations that I built for code4lib 2011 and some new demos that I've built for ELAG. The new demonstrations for ELAG take advantage of two OCLC web services.