As promised, I've been keeping some very simple metrics on the usage of a virtual card catalog service that I quietly added to the AADL catalog several weeks ago.

But before I go any further, I need to disclose several tidbits about this whole endeavor.

First, this was a "black-ops" project. That is to say, I consulted no one before launching into this. I did not go to the public and ask their opinion. I did not go to my colleagues and solicit their input. I did not float this in committee. I didn't get any official authorization to do it. In fact, the whole thing flew under the radar from its conception through to fruition, which took exactly four days. In many ways, it was a spur-of-the-moment project that I did to keep busy during a few relatively quiet days. Sometimes, you need to throw caution to the wind and just do it.

Bear in mind that the only place this service was advertised was on this blog (where, admittedly, it was subsequently picked up by several others). I did not announce it to AADL staff--I let them discover it on their own. Many probably still don't know it's there. When you look at the numbers, know that they reflect those who either read about the cards on a blog or stumbled across it during their course of regular business.

It was a very fun little project, but the real value was that I could slip it into production very quietly and let it act as a proof-of-concept for some very real, very large changes I want to do to our OPAC (which I definitely need authorization for). Essentially, I wanted to answer a very simple question:

Is the public ready for a social OPAC?

What I found indicates something very special, indeed. In fact, as time progressed, I began double-checking my methods which consisted of a simple laundry list of basic queries, which I'll describe. As you can see, I only have 7 collection dates and they are not at regular intervals so the growth rates represented are a little deceiving, but as I've said before, this is very unscientific--I'm definitely no statistician! The results, however, are real.

The first graph here (above) is the simplest of all. It's the total number of marginalia comments in the system over time. The query was simply:

SELECT COUNT(*) FROM cc_marginalia

The count for each date, respectively is: 35, 107, 160, 413, 593, 634, 790. You can clearly see that the number or cards being marked up is experiencing a steady climb. I actually am not terribly surprised by this, but for an unadvertised service, it's still much higher than I had expected or hoped for.

Now, marking the cards up is one thing--it's a fire-and-forget process, it doesn't even require a user to be logged in. Adding a card to a collection is another. Adding a card requires that a user be logged in to a valid account and represents, what I consider, a higher participation factor. This means that users are not only adding marginalia, but they are taking advantage of the ability to build card catalog collections. To me, this is really exciting stuff because it tells me that a) the service is useful and b) there is a market for this kind of stuff in a library setting. FYI, the query for this data is:

SELECT COUNT(*) FROM cc_savedcards

The data for the preceding graph dates is 8, 43, 66, 82, 216, 320, 388.

If you're interested, you can take a look at my saved cards. In addition to knowing how many cards were being added to collections, I needed to know how many people were collecting cards. This is where I really started to feel my pulse quicken. These numbers told me that, despite a lack of advertisement, a substantial number of people were building card catalog collections. I have to be honest and say that I was expecting only 20 to 30 users participating after three weeks. As of 2/11, however, there were 75 users building collections! Check out the growth over time: 2, 6, 22, 42, 58, 62, 75 for each date respectively. Of course, to put that in perspective, we have 20,955 registered users on our Drupal site as of 2/14--our regular users are an extremely small fraction of that, however. To get this data, I ran the following query:

SELECT COUNT(DISTINCT(uid)) FROM cc_savedcards

So... How many of those users not only started to build card catalog collections, but opted to share their collections with the world? I was blown away by these results. Simply amazing: virtually every person to create a card catalog collection also opted-in to sharing it. To me, this speaks volumes about the types of services our users want and it tells me that a good number of our library users want to interact with each other--a vital ingredient if you want a social OPAC. It also sheds a little light on the sophistication of our users--a lot of them are already Web 2.0-aware and will be sensitive to new services like this. Our commercial counterparts are doing a great job of softening the market for us--now all we have to do is provide the tools on our systems.

There is a very good chance I'm overlooking something here--if there is a metric you'd like to see me add, please ask for it and if it's feasible, I'll do my best to provide it.

Our users are smart, clever, interesting, positive, intuitive, and social. They may not know it yet, but they're waiting for their public libraries to be a catalyst for the community. There is something wonderfully special and intimate about shared experience--that is why Web 2.0 is so successful. When those experiences are centered around books, movies, and music and they're aggregated at the local level, the product becomes highly personal--how inspiring would it be to have patrons who are proud of the job they've done for their library?

NOTE: The above graphs were created using the open source graph library, jpgraph.

[Update 4/16/2006 2:42PM]
Somehow, this post got flagged as "private" .. Odd. Very odd, but fixed now.
[/Update]

[tags]Web 2.0, Virtual Card Catalog, Library 2.0, Programming, Library, AADL[/tags]

I can't tell you how many people have emailed me about getting the source code to the virtual card catalog images I announced a few weeks ago. Anyway, I've finally gotten around to stripping out all the garbage from the script that generates the images, and I'm releasing it here (and as always, it'll be available in the files section). There are a few things you need to keep in mind about it, however.

First, this code is written for use with III's XMLOPAC and requires my PHP XMLOPAC class. That said, an astute PHP coder could easily port this app and make it usable on another system (I heartily encourage that). Someday, I plan to make it completely generic so that all you need to do is pass it the data itself. I'm a little busy at the moment, however.

I am not releasing the card stock images that AADL uses. There was no license info associated with the original images. Until I can contact the folks at UPenn and find out what the deal is, I'm not going to make them available. It'd be very easy to create your own stock, however.

Same deal with the fonts. I was able to freely download them--so should you.

At present, this code is really meant for developers, it is not a "package" that will work out of the box. You must know what you're doing in order to get this going.

I'm releasing it under GPL for all the world to use freely, forever and ever.

Included in the tarball is a README file with some basic instructions. Be sure to read that before emailing me your questions.

Enjoy. I'm looking forward to some possible creative uses. Please email me if you get it working as I'd love to see what you're doing with it. If you come up with a particularly interesting use, I'll be sure to showcase it here.

[tags]PHP, Programming, Virtual Card Catalog, AADL, Web 2.0, Library 2.0, Open Source[/tags]

After a fair amount of work, I'm releasing an update to the iii-xmlopac class. I've been sitting on this update for awhile because it's a fairly big update and I wanted to make sure it was performing like it should. I highly recommend that anyone using this class update because a number of fairly critical bugs have been fixed, including a messy tangle of UTF8 encoding issues.

In addition, I've included an XSLT file written by David Walker which I've modified slightly. It allows me to easily extract subject headings from the XML, so yes, this class now will return an array of subject headings!!

So, be sure to download the latest version. As always, you can grab it anytime from the files section.

[tags]PHP, XML, Programming, XMLOPAC, OPAC, AADL, Open Source, III[/tags]

(Codenamed PatREST in my SVN)

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.

I got a lot of positive feedback concerning the virtual card catalog I put together last week. Among other things, I received a request for the ability to share your Personal Card Catalog in the same spirit of Library Thing. I thought that was a great idea, so here it is.

Anyone who has a valid user account at www.aadl.org can create a Personal Card Catalog (you do not need to be an AADL cardholder, so anyone can try it out!). Once you've added some cards to your own catalog, you can then go to your preferences and enable sharing:

After you've done that, anyone can head on over to http://www.aadl.org/pcc/(your user name). Feel free to check out mine (not much in it yet). Of course, privacy is king for all this which is why the service is opt-in with the default off. It's not that hard to go ahead and enable it, though.

I'm going to use this service as the subject for a very unofficial study in the efficacy and popularity of Web 2.0/L2 tools. Obviously I will get statistics from database usage, number of records, queries, etc. I want to get a handle on just how useful and meaningful tools like this really are. I'll definitely share what I find, so stay tuned!.