For example, here is the AADL top items list using onr of my Google gadgets (seems to not work in some browsers):

Very cool and very easy.

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.

The first ever mashup camp drew to a close yesterday. It was the brain-child of David Berlind and Doug Gold. Essentially, It was a collection of mashup authors from around the country and, ostensibly, the world who gathered to share their creativity and brainpower. Notably, among them was Ann Arbor's Ed Vielmetti. He's reported back on the "camp's" progress--be sure to check out his blog.

But what does this have to do with libraries, and why should we be paying attention to this? Well, beside the fact that mashups are the new, hot technology and we should be keeping up with all new, hot technology, mashups have enormous potential to redefine he library boundary both in terms of the technology itself and the people creating it.

Immediately, we can see the potential on our own sites by bringing in highly-polished, powerful tools in ways that enhance the information we already have to offer. A good example that Stephen Abram cited, was the ability to use the Google Maps API to provide very specific, very user-friendly directions to library branch locations. What makes mashups so exciting is that creativity and innovation are the key elements at play in the construction of these things.

The fact that new, high-level scripting languages and development engines like Ruby or Ruby on Rails, even, are being developed make the assemblage of Web 2.0 APIs a fairly easy endeavor. As a result, we're starting to see our patrons get into the groove as they begin to spin their own creations. Ed Vielmetti's Amazon mashup is a great example of this. He's written a Greasemonkey plugin that sneaks item availability into an Amazon record. The subversive nature of these things really tickles my fancy--it allows us, as end users, to do things that would mortify any sales team. We need to laud the use of our data wherever our patrons decide it should be.

Mashups are about individual empowerment. As libraries, we need to be able to step right in and lend tools to our users that will allow them to start creating these unintended uses. Again, this requires us to have... that's right, suitable APIs! The PatREST project I'm working on strives to do just that and I'm so grateful that Dave Pattern at Huddersfield has joined me. We've been able to create a bilateral push for this by producing near-identical results using two very different systems.

The mashup also poses some fundamental questions about the library's reach--where it begins (from the patron view) and where it ends (from our insider's view). By enabling users to spin our library tendrils into any place they like, we're creating a very ambiguous border on our OPACs, which, in turn, causes the entire ILS to recede into the background and play a significantly different role. Increasingly, it's just the business logic we want.

And so, as a whole new generation of Frankensteins are born, can you say that your ILS ready? Can you deal your data out under the table? With sleight-of-hand, we're going to make the library insidious.

[tags]Mashups, API, Web 2.0, Library 2.0, Programming, Coders, Superpatron[/tags]