Mashup Apps:Community Dev

John BlybergChris Deweese

Internet Librarian 2006Monterey, CA

Good afternoon, bla bla bla....

It seems to me that every year another set of buzzwords emerge at conferences like these. Last year it was stuff like “folksonomy”, “tagging”, “delicious”, “flickr”.

“Mashups”, however, hadn’t “hit” yet. This year is a different story.

So, I’m not going to dwell too much on the definition of mashups, since previous sessions have already done that. Instead, I wanted to talk a little bit about what the mashup philosophy means to libraries, and what we should be thinking about in terms of reacting to the mashup trend and preparing for what’s possibly next.

In case you missed any number of previous sessions, a mashup is simply a piece of software that accesses two or more other pieces of software to generate a new type of output.

The name itself comes from the music industry and refers to a form of electronic music that remixes different songs in a way that

What’s so great about ‘em?

The don’t require wicked coding skillz

Results are instant

Results can be striking

Mashups = The evolving web

So, what’s the big deal and why is “mashup” such a buzzword now?

Well, like I said, technology has allowed mashup developers to do some very interesting, powerful things and remixability has its own inherent values--chiefly among them is that the mashup represents a shift in the web’s balance of power. Regular people are seizing control of their online experience.

Mashup developers do not necessarily need to be programmers - A common mis-conception is that in order to produce a mash-up, you need to be a geeky code-guru. This is definately not that case. Mashers are regular people who have spent just a little bt of time figuring out some of the most basic elements of web 2.0 programming.

And as you’re developing a mashup, the results are instant - Actually, results are typically presented in real-time. Mashups are the ultimate in instant-gratification that way. When you’re talking about consuming two or more existing services, the nice thing to know is that the services themselves are already well-established pieces of software that just “work”. So as regular people, mashers

Can libraries mash?

We better!

Bib# ISBN Check Google

Cache result

Put it here(if @ Google

Books)

As libraries, we’re in a great position to take advantage of mashup technologies. The reason for that is that we’re already sitting on top of a goldmine of data that has the potential to be used in so many different ways.

This is an example of a very very simple mashup. When the Google Books folks announced that they would be linking to some library catalogs from within their interface, I thought, well, if they can run queries against our catalogs in the pursuit of adding functionality to their site, why can we do the same to them? Besides, our OPACs might really suck, but their search capability really really leaves a lot to be desired.

So I quickly hacked together this little mashup that checks to see if a particular item exists in the Google Books database. If it does, then a link to it is added to the hitlist.

Like I said, this is a simple, but effective, mashup that I was able to quickly add to our system. But this is something that I was able to add directly to our existing offerings. What if I wasn’t on the AADL payroll? What if I was just a library user who wanted to take advantage of my library’s data, but I wasn’t privvy to all the

It’s all about markup

And that’s where web services come in.

As the web evolves, it will require a number of descriptive technologies to address the shortcoming of HTML, which is intended to be consumable only by humans. These descriptive languages are XML, RDF, and OWL (in that order as you travel up the stack here)

XML (extensible markup language) has been around for quite some time and has established itself as a very effective way of transmitting structured documents. It’s important, however, to bear in mind that XML is a standard for syntactical format only, and really does not impose any semantic constraints or meaning on the data it carries.

RDF (Resource Descriptive Framework) is the next step up this stack. It is a simple data model for carrying (and referring to) a payload of object data. In other words, a logical grouping of data. For example, an object could be a checked-out item, including all the neccesary bit of information like, Title, Author, Duedate, etc. RDF is often represented in XML format. Can anyone think of a very popular RDF format? RSS is indeed an RDF object.

REST? Sounds lazy...

REpresentationalStateTransfer XML

SchemaRDF

But right now, we’re only concerned with XML and RDF and a specification called REST.

REST, or Representation State Transfer is a URI-based web services layer, meaning that it is interfaced only via the URL. This makes it very easy to access data in a logical way. It’s very attractive to developers who simply need to know the URI convention and the XML schema in order to start developing.

PatREST (Patron REST)

http://www.aadl.org/rest/top/books/10/2

Anyway, I’ve always wanted to create an environment shaped around the library that was friendly and accomidating to developers and amateur coders. Ann Arbor is a college town with a large number of people who simply love to get involved and hey love their public library. So I thought this was a perfect situation to implement something thay they could use to do.. whatever, really.

But I was looking at our ILS, Innovative, and there was really nothing out-of-the box that was remotely friendly enough to present to the public.. We’re just not that cruel. And there are some other XSLT (xml stylesheets) that can translate III’s only XML output to MARC-XML and Dublin Core, but even those seemed way too librarianish. First of all, patrons should never be expected to know that MARC exists, let alone what it is. And Dublin core is, well, not much better.

What I wanted was a schema that was simple, clean and easy to understand. So I started to put something together. The result was something I called “Patron REST”, or PatREST for short. It does several things, first it allows you to do searches against the catalog, but it cal also return new and top items, as well as

Stuff you can do...

Travel back in time...

But let’s take a quick look at some of the stuff that uses this web service now.

This image was generated by a social software application I built last spring that allows our users to see a catalog card image for each item in our catalog then lets them add marginalia notation to them. It was a very fun and spontaneous experiment wanted to try and it’s become quite a hit.

But this application consumes data grabbed from the PatREST server. Of course the application itself renders the image, handles the comments, and such, but the bibliographic data here is easy taken from PatREST.

Stuff you can do...

Electronic SignageThis is a screenshot of an electronic signage application we have running on our new Pittsfield branch that just opened in March. This application is actually written in Apple’s Quartz Composer--a very interesting development platform that is completely visual in nature. It literally looks like a bunch of spaghetti on the screen.

Anyway, I didn’t create this application, our component developer, Eric Klooster, did. But he was able to consume the PatREST service to get top and new items data and present i in a very slick way.

This application runs all day long on a 40 inch plasma display and really looks slick. He did a great job.

Stuff you can do...

Ed Vielmetti’s (Superpatron) Wall of Books

Here is an application produced by Ed Vielmetti, who some of you may know as “The Superpatron”.

BTW, if you can get a superpatron of your own, do it. But you can’t have ours.

What he was able o do was to construct some custom “wall of books” pages using the cover images. These were then deep-linked into that book’s item record in our catalog.

A neat little application with some interesting possibilities.

Stuff you can do...

Then there is this thing. These are the four gadgets I submitted to the Talis for their Mashing Up the Library competition. These are actually very simple and easy-to-create bits of javascript embedded inside XML.

Stuff you can do...

So here is a close-up on two of the gadgets with their preference panes open. The nice thing about creating these is that Google has already provided all the functionality required to get these things up and running. I didn’t need to do any form creation and the Ajax-type asynchronous data calls are all prewritten. So really, these are really simple applications.

IF INTERNET: Do Demo

Why let the public do it?Creates a sense of stewardship

Unlocks a potential brain-trust

Encourages innovation

Benefits other libraries

Solicits high-quality feedback

Promotable as a service

Puts library data into new contexts

So the real question here is why should we let the patrons have access to this kind of functionality?

Well, there are a number of reasons.

First is this idea of “library stewardship”. If you can invite users to be part of the building process and get them to feel like they are adding value to the library, they tend to turn into very strong advocates of the library itself.

It also can tap into the knowledge and expertise of the people in your community. As I mentioned before, Ann Arbor is a college town with, as many of you know, a great library school. PatREST has allowed us to do some outreach with that program and just the other day I received an email from a grad student who wanted to use it to develop a reccomendation system based on patron checkouts.

Um, hell yah, that’s work we won’t have to do!

So, as the popularity of this thing has grown, we’re begining to see some very interesting innovative things emerge from that

fin

I’m going to pass the mic to Chris who is going to demonstrate how to create a quick and easy Google Maps mashup, then hopefully we’ll have some time to do questions...