Anyway, we talked about superlibrarians and superpatrons within the context of Eric Von Hippel’s notion of “lead users.” This is an area that should be of great interest to libraries–specifically, how do we identify those lead users, then enable them to mash-up, remix, and create services, tools, and content. We can learn a great deal more from our users than we are currently used to and Von Hippel shows us how in a series of online videos and papers.

I mostly talked about PatREST–its history, what it is, where it might lead, and my decision to build a patron-oriented API on top of our existing ILS. Ed shared some interesting insights into his perspective as a consumer of PatREST and other non-standard distribution channels made available on AADL’s system.

There are a variety of ways to characterize library materials. The type of reader believed to be interested in a particular item is one. Such an indicator, generally known as the audience level, is potentially useful for a variety of activities, including the development of new ways to improve information relevance for retrieval, reference services (including readers advisory) and collection development. Audience-level filters could be implemented in existing retrieval systems to assist users in finding content based on their information needs.

This is not the first OCLC service PatREST has taken advantage of. PatREST has been incorporating data from OCLC’s xISBN service for quite some time. By pulling in the data they make available, the data PatREST is able to return becomes significantly more valuable.

Because AADL’s PatREST implementation relies heavily upon III’s XML server, I’ve added OCLC’s Audience Level functionality to the PHP XMLOPAC class code which is freely available from my files page or you can directly grab it right here.

The new versions allow users to display cover images along with the records. A new option gives you the choice of text only, images only, or images and text. Not a major change, but noteworthy. Also, in case you missed the update in my previous post, the new items gadget can now match subject headings–useful if you want to be notified about new items on a particular topic.

For the purposes of the Talis mashup competition (for the judges), the original xml files are still available under a different name (tops-v1.xml and new-v1.xml). Everyone else, here are the new ones:

• tops.xml
• new.xml

(FYI, it’s the same URL as the previous version. If you’ve already added it to your Google page, the update will be automatic)

While working on this little project, I became painfully aware of PatREST’s limitations when dealing with asynchronous execution — like that of Google gadgets. I previously thought it would be better to limit the amount of data returned in an XML hit-list and use a second record query for and detailed info. I think I may have been a little short-sighted. At any rate, the lesson learned is that the more practical experience I have with PatREST, the more I’ll know what works and what doesn’t.

The upshot of all this is that I’ve expanded the result objects in any PatREST function that returns multiple records to include more information, such as ISBN, cover image, author, and record link. For those asynchronous folks, this will make life a lot easier. The new additions have been added to an updated specification. Existing PatREST applications (I don’t think there are many at this point) will continue to work, of course.

Anyway, my idea was to submit a suite of Google gadgets that, even if it doesn’t win, will serve another important purpose of providing a proof-of-concept for my PatREST specification. So I’ve written four gadgets using the Google Gadgets API. These gadgets then consume the PatREST service for their data. If you’re unfamiliar with the Google gadget, they are the little customizable panels on Google’s personalized home page. This is what the page looks like with all four enabled:

Like all the other gadgets, they can be dragged around the page and individually configured. Also, you can choose which gadget to install, if you don’t want all four. They are:

• tops.xml – – Displays the hottest items at the library. You can configure it to display books, CDs, books on CDs, or everything. You can also select the number of results you want returned.
• new.xml – – Displays the newest material at the library. You can configure it to display books, CDs, books on CDs, or everything. You can also select the number of results you want returned.
• curitems.xml – – Displays all your currently checked-out items.
• holds.xml – – Displays all your requested material.

The beauty of these gadgets is that they require no modification of the code at all in order to be used with other libraries. The catch is that the library needs to provide the PatREST API (and right now, that’s only AADL). My hope is that other libraries will see and recognize the usefulness of a patron-friendly API.

Installing the gadget is dead easy. First, you need to create an account with Google so that you can personalize the Google home page. Then, click the “Add content” button (top-left). You’ll notice a small option next to the search box, “Add by URL”. Click it, and paste in the URL of one of the XML gadget files above. If successful, you’ll see something like:

You can repeat this process for all of the gadgets, if you like. When you’re finished, go back to your personalized homepage, and configure your gadgets:

Configuring the Top Items gadget:

Configuring the Check-outs gadget. Note that you will need a special token. This is the token used to access your personal RSS feeds:

That’s it! I doubt it could be muh easier. AADL patrons can benefit from these gadgets right away. Hopefully other libraries will consider the PatREST specification, (vendors too!). Once I had done the prototyping, creating additional gadgets was very easy because of PatREST’s simplicity and accessibility.

Naturally, these XML files are released under GPL v.2. Feel free to modify and extend them as you like. I have a number of ideas that I just don’t have time for right now, but hope to add in the future.

Also, because of the quality of XML data I get out of the III system, and, what I think is a bug on Google’s end, the results occasionally do not display. Once Google clears it’s internal cache, however, things usually fix themselves. I think this little bug is out of my hands–at least until I can learn more about it.

Please use these, and enjoy them responsibly!

*** Update 8/19/2006 ***

Added subject search to the New Items gadget.

*** Update 9/1/2006 ***

Not sure why I didn’t do this before, but I added “Add to Google” buttons to the links in this post, as well as on my files page. All you need to do to use these gadgets is click on the button and confirm by clicking on “Add it now”. How’s that for simple?

First, two new functions have been added to the service. One provides access to tops (or popular items) lists. The other provides access to the new materials lists. I believe these are significant-enough additions to the service that they merit the 1.1 version number.

The top items query is scalable by result size and can be paginated, just like the search results. In addition, it can be scoped by material type: books, cd, dvd, or bocd (books on CD). When applied to the AADL XSLT, it looks something like this:

The new items query is similar to the top query in that it can be scaled by material type, size and be paginated. You can also search new items using their subject headings–useful for querying those new knitting books, Ed… It looks something like this:

Second, and probably more importantly, I’ve finally drafted a specification for PatREST which includes an explanation of it’s XML schema and some documentation for it’s various functions. It’s about time, I know. It can be found in the files section, or downloaded here. (PDF)

I’m not going to go in to too much detail about the two new functions in this post because the new documentation contains everything you need to know to get started with them.

When last I wrote about this, it was little more than a working proof-of-concept, but I’ve been working on it a lot this week–partly driven by DaveyP’s experiments and Ed’s tinkering, but mostly because I’ve been planning to do this for a long time now.

So, to cut to the chase:
PatREST now provides an easy, RESTful URI to do searches on quite a few fields. Essentially, you will plug the search key into the URI, followed by the search term. You can also request optional paging for keyword, author searches by appending hits-per-page and page-# to the URI. It looks like this:

http://www.aadl.org/rest/search/[searchkey]/[searchterm]/[hits-per-page]/[page-#]

The following search keys are available:

title
author
callnum
keyword
subject
gvtdocnum
stdnum (ISBN/ISSN)
titlekey
controlnum
barcode
record (Bib #)
bibnum (Bib # – Same as record)
itemnum

Go ahead and try this keyword search. It’ll look something like this:

You’ll notice that the XSLT stylesheet presents it nicely, all the data may not be displayed, but the XML is sound. Go ahead and view source to examine the schema. I’ve departed quite a bit from my original schema in order to provide a little bit of metadata for processing purposes. The XSLT allows you to click on a title which will take you to another RESTful record:

You’ll notice that the URI for this record looks like /rest/record/1035670/ … It’s /rest/record/[bibnum]/. The XSLT allows you to click on either the title or cover image to go to the regular OPAC record. Again, view source for the XML schema. This schema has changed little and you’ll notice that I’m taking advantage of OCLC’s xISBN service.

The real treat in all this, however, is the ability to access your personal records RESTfully. To do this, I make use of the RSS token that is provided to every cardholder who has registered for an online account. This is the token that authenticates RSS readers against our system. It is a 32 character MD5 hash that looks something like “316928e0d260556eaccb6627f2ed657b”. Accessing personal data is as easy as using the following URIs:

For checkouts, you would use /rest/checkouts/[token] (ie http://www.aadl.org/rest/checkouts/316928e0d260556eaccb6627f2ed657b). You’ll then get output at looks something like:

For holds, the URI is /rest/holds/[token]. Output looks like:

Both of those results allow you to click on the bibnum and access the REST record for that item. Again, check the XML schema with your browser (no point in putting it here).

Please hack away at this and send me your comments/suggestions. You’re absolutely correct that it doesn’t adhere to any existing standard, but that’s because I didn’t want it to.

On a slightly less geek-oriented note…

I’ve gone several rounds with Talis’s Richard Wallis before, so I want to call your attention to a post he made the other day in which he suggest that a) DaveyP and I collaborate and b) I/we consider using industry standards. I’d like to respond by saying that Dave and I have been communicating extensively. Ed Vielmetti has been involved as well.

Richard writes:

I encourage John, Dave, and those that follow them to take a look at these standards like we have

I can’t speak for Dave, but I’m very familiar with these standards and so is Ed. I think Richard is completely missing the point of this whole project which is to put a friendly, accessible, and useful development interface into the hands of patrons. Ed offers just a small example of the type of features that existing standards don’t readily make available:

Already there is a lot more useful function in it than you can get in SRU, e.g. permalinks for card records and a sensible way to get item availability.

Bear in mind, that comment was made prior to my work with RESTful holds and checkouts, which, as far as I know, don’t even have a standard XML schema–I don’t think it’s been done before! (I’d love to be corrected on this) This project will also evolve to the point where holds can be placed RESTfully, items renewed, fines paid. It’ll also extend to our other features like checkout history, wifi device management, personal card catalog management. Adding this functionality is not only going to allow the public to develop highly useful applications, but it’ll be a framework by which we ourselves can build new services in-house. Vendor’s obviously haven’t stepped up to this, so we are–and we believe in our patrons. They deserve this kind of access to their public library.