This little feature uses data from our opt-in patron history system. Since we've been offering that system for about a year now, we've been able to accumulate over 300,000 data points. This is another great example of how to reuse your existing data to enrich use experience. Like I've said before, you need to use the data you have to its full potential--even if it's not the data's primary purpose.

Ok, so let's look at the nuts and bolts of this. I was able to cobble this together with two SQL queries. Actually, I was able to get the same results with a single nested query, but for some reason, non-cached results took upward of ten seconds, so splitting the query seemed like the right thing to do.

Anyway..

So basically, you can see what's happening here. First I get an array of all the other users who have checked out this item. Then I get a list of items that three or more of those people have checked out and display it randomly (so it's not always the same list). Pretty easy, of course you need to grow that data before it becomes useful. 300,000 records makes the results pertinent, 300 does not.

If you're curious, head on over to AADL's catalog and test it out.. you might stumble on something new.

The next step, of course, in all this SOPAC business is to try to determine how check-out patterns are changing and whether it will have an impact on collection development.

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.

Drupal 4.7 sports a number of great new features. I'm most excited about the new search engine which does a much better job of indexing the site and allows users to do an advanced search. Searches now actually return meaningful results. Other features include a new Ajax-enabled content creation system with nifty improvements such as re-sizable text fields, collapsible elements, a file upload system that doesn't require authors to leave their work, and live menu updates. On the development side, these new features are accessible via the new form-handling system. In other words, coders can easily incorporate these new Ajax elements in their own work. Theme developers will be happy with the ability to create an infinite number of regions--nice to achieve that highly-polished CSS look. I think a couple new block types were added as well.

Another great feature is the wiki-style revision system that allows editors to roll-back their work and leave editorial log messages (a very useful feature in large, collaborative environments). Commenting benefits, as well, with the ability of site administrators to manage and moderate multiple entries at once. Finally, Drupal 4.7 supports free tagging. Not something we're using at this point, but, from my point of view, it means that the engine is there for future module work. I have a feeling I'll be using those hooks for some forthcoming feature upgrades on the website itself...

The upgrade was fairly smooth. Drupal ships with an update script which ran flawlessly, but that's the easy part. A fair amount of prep-work was done ahead of time to ensure that all of our custom modules were 4.7-compatible. Basically, this meant updating all of our form-handling code to handle the new system. We also segregated all of our own code and theme information from Drupal's using the multi-site capability. This means that we can easily keep track of our own work without it getting mixed up with the vanilla code-base. This wasn't completely necessary, but it was worth the work because it'll make all future upgrades much easier to do. Doing things this way is also in-line with my philosophy of never touching stock code unless you absolutely have to.

The long and the short of this whole upgrade means that our users will probably not notice a lot of difference, but we're now in a good position to work on AADL 3.2. And that they will notice.

For more info, check out these Drupal videocasts:

• An overview of screencasts
• What's new in Drupal 4.7
• Installing Drupal 4.7
• Upgrading to Drupal 4.7
• Contribute your own Drupal Videocast

In addition, Ryan has written up a couple great how-to's on getting item data and featured lists from the XML. I, for one, had no idea it was possible to grab featured lists this way. Ryan Eby has been documenting III's XMLOPAC for quite some time now and he's certainly one of only a handful of authoritative voices on the feature.

David Walker is another, and a very industrious voice at that. Today I had a good chat with him on the Code4Lib IRC channel after he showed me his totally amazing catalog based off his equally cool Shrew project. What he's been doing is exactly what I've been looking for. Even though the Shrew project is currently written in C#, he has plans to port it to PHP5, taking advantage of DomDocument. It's a project I'm completely willing to commit some time to myself, if he asks. The shrew project is "a system that converts the Innovative XML Server into an SRU/SRW and OpenSearch server." He's put a great deal of time into writing XSLT that will translate the III server's output into MARC-XML, Dublin Core, or MODS 3.0. My XMLOPAC class for PHP5 utilizes an older version of his MARC-XML XSLT, but I think when he pulls off this port, the need for my code will go away altogether--his way is preferable.

We also discussed some inherent problems with III's XMLOPAC--of which there are a number, and some potential enhancements. Chief among them would be the ability to conduct business--placing items on hold and such. A lot of work needs to be done, but I'm feeling much more optimistic about my OPAC aspirations now and, thanks to David and Ryan, a renewed sense of enthusiasm. Thanks guys!

[update] Ryan reminded me that Rob Casson is the individual who was kind enough to provide hosting for the wiki [/update]

[tags] OPAC, XMLOPAC, XML, XSLT, Library, Code4Lib, PHP, C#, SRU, MARC, DomDocument, Web Services [/tags]

The whole point of these new stickers is to ease the work created by an ever-increasing volume of holds being placed on AADL material. Our processors have been bearing the brunt of increased loads, partly due to general growth, but also because it is so easy to place a hold online now that the number of holds we get has shot up. Now, as far as the processors are concerned, when they scan material that has been routed to the correct pickup location, a custom label, replete with patron information and barcode will spit right out of a networked label printer. This removes a step or two from the process and has led to some very happy circulation staff. Though I'm quite pleased with the way the labels turned out, what pleases me the most (besides the happy processors) is what happens behind the scenes. What's fun about this are the relatively simple back-end components that make this work.

The III circulation client can be configured to send a print job to an email address instead of a standard receipt or line printer. In this case, I've set up an instance of Exim running on a Linux box with an address alias that pipes the email through a very simple PHP script. The PHP script parses the email, creates a PNG on the fly, then sends it to the label printer via cupsys lp. I've been having a lot of fun with PHP's GD module lately and this little project really underscores how slick it can be. In addition to GD, I also made use of PEAR's Image::Barcode class so that the item's barcode could be included on the tag. Because PEAR's barcode class doesn't allow you to return the image as an object, I had to instantiate it as a separate script. That's fine because you can just point imagecreatefrompng to the URL. The barcode script couldn't be simpler. Not only that, it's so generic, you can really use it for all your barcoding needs:

<?php
// bcode.php
if (!$_GET[input]) { return; }
require_once('Image/Barcode.php');
$bcode = new Image_Barcode;
$bcode->draw($_GET[input], 'int25', 'png');
?>

'Eh? What a great class! Here's the guts of the label code--messy, I know, but it works. As you can see, it's utilizing PHP's CLI or CGI build. Yes, PHP makes a great shell scripting language too!

#!/usr/bin/php5 -q
<?php
 
putenv('GDFONTPATH=' . realpath('/usr/local/php/fpdf/ttf/'));  // Where my TTF fonts are
 
$fd = fopen("php://stdin", "r");
$email = "";
while (!feof($fd)) {
        $email .= fread($fd, 1024);
}
fclose($fd);
 
$item = hold_item_info($email);
 
$x = 350;
$y = 350;
$daysonshelf = 8;
$unique = time() . rand(2000000, 6000000);
$font = 'arialbd';
$logourl = "http://www.aadl.org/staticimages/aadllogo.gif";
$bcodeurl = "http://bcodeserver.aadl.org/bcode.php?input=$item[barcode]";
 
// Create the image
$im = imagecreatetruecolor($x, $y);
$im2 = imagecreatefrompng($bcodeurl);
$im3 = imagecreatefromgif($logourl);
 
$white = imagecolorallocate($im, 255, 255, 255);
$black = imagecolorallocate($im, 0, 0, 0);
 
imagefill($im, 0, 0, $$white);
imagefilledrectangle($im, 0, 0, $x, $y, $white);
 
$spine_name = $item[plname];
if ($item[pfname]) { $spine_name .= ', ' . strtoupper($item[pfname]{1}) . '.'; }
 
$holdtil = (time() + ($daysonshelf * 86400));
$holdtilfmt = date("n/j", $holdtil);
$canceldate = date("m-d-Y", $holdtil);
 
$details = 'Title: ' . $item[title] . "\n" .
        'Author: ' . $item[author] . "\n" .
        'Callnum: ' . $item[callnum] . "\n" .
        'Barcode: ' . $item[barcode] . "\n" .
        'Held for: ' . $item[plname] . ', ' . $item[pfname] . "\n" .
        'Pickup location: ' . $item[pickuploc] . "\n" .
        'Hold until: ' . $canceldate;
 
imagettftext($im, 28, 270, 40, 20, $black, $font, $spine_name);
imagefilledrectangle($im, 72, 20, 74, 345, $black);
imagefilledrectangle($im, 15, 300, 70, 335, $white);
imagettftext($im, 12, 0, 32, 320, $black, $font, $holdtilfmt);
ImageCopyMerge($im , $im2, 85, 40, 0, 0, ImageSX($im2), ImageSY($im2), 100);
ImageCopyMerge($im , $im3, 85, 275, 0, 0, ImageSX($im3), ImageSY($im3), 100);
imagettftext($im, 12, 0, 85, 120, $black, $font, $details);
 
imagepng($im,"/tmp/pic$unique.png");
imagedestroy($im);
 
if ($item[printer]) {
        $printer = $item[printer];
        exec("/usr/bin/lp -d $printer /tmp/pic$unique.png");
}
 
unlink("/tmp/pic$unique.png");
 
// Functions Below
 
function hold_item_info($email) {
    // This function returns the $item array -- customize it for your environment.
}
?>

The script creates a PNG that looks something like this:

The PNG is sent to the Zebra S4M and printed on a label that has Post-It-like adhesive. Processors then peel off the backing and fold the sticker over the spine of the book and put it on the hold shelf.

The hardest part of this whole project was getting the printer to work with CUPS. I wound up bastardizing some existing postscript drivers through trial and error. As you can see from the photos, I still don't have it right. I'd like the image to take up the entire sticker area. All in good time. If anyone out there wants the driver I'll be glad to email it--maybe you can get it working better! Just ask.

[update]
This is how the labels are affixed to material:

You can overlook the fact that the label info doesn't match the book info--it's just for show!
[/update]

[tags]library, libraries, PHP, coding[/tags]

Much has changed in the last year with respect to the notion of a "library website". It's as though the clear, glassy surface of a morning bay has been turned and cast about by steel, unforgiving turbines. Many unsuspecting libraries are now caught in that turbulent wash, casting about for something, anything to hold on to as they begin the daunting task of "the redesign". The problem is, where do we even begin? If there was no gold standard before, there still is none, but we now acknowledge two things: Traditional library websites drain the life-force from patrons. Our OPACs finish the job.

So where do we go from here? Is there anything, anything at all we can use as a modus operandi as we, once again, begin the process of re-provisioning the obligatory library website?

Let me suggest five directives that may help get your creative minds turning. I want to talk about these not only because they represent common sense, good design, and patron convenience, but also because by using these directives as a kernel in your new project, you are sure to come out the other side feeling highly rewarded and sporting a new website that will invigorate your inner-geek for years to come.

Social software, as you are probably aware, was born of the read/write web. Partially due to persistent connections, newer software, higher bandwidth, and plain old human acceptance of the machine, the social web is a beautiful lace spun with minds, machines, and information. It is who we are as humans--it is community. just like the public library is community. So to ignore social software in the context of our library websites, is to ignore our communities. We need to find a prominent place on our mantle for it and ensure that our websites invite humanity in and give it right back. The point here is to extend the boundaries of the library, perhaps blurring the edges like watercolor so we're not quite sure where the library ends.

There are many ways to incorporate social software into your sites, not the least of which is the use of mash-ups, or the judicious use of an open source database like MySQL in conjunction with a little PHP, running on Linux, served up by Apache. Adopting open-source platforms and technologies in a library is not just financially beneficial. Philosophically, it's the right thing to do. We ought to be developing on open-source then turning around and making our work freely available to one another. We are libraries after all, we ought to act like it, not just in the stacks and at the circulation desks, but in the server rooms and IT departments as well. Don't forget the intrinsic benefits of supporting and pursuing an open sourced development program. Eric Raymond writes in The Cathedral and the Bazaar:

...we have fun doing what we do. Our creative play has been racking up technical, market-share, and mind-share successes at an astounding rate. We're proving not only that we can do better software, but that joy is an asset.

Joy truly should be an asset as you continue to plug away at your web project. If it is, the final product will reflect it. Open source allows success to be contagious as code is reused, changed, improved, forked, spawned into radical new ideas. That sounds like something a public library ought to be involved with, doesn't it?

I think it's time libraries took the notion of single sign-on seriously. We need to get away from the model where patrons are required to have their library cards handy every time they reserve an item. Who wants to have one set of credentials to access the OPAC and yet another to make a blog comment, or fill out an ILL request? Why not be like the rest of the world and simply require a username and password? Let me take this one step further, as well, and suggest that your new websites support session-based single sign-on--a useful little bit of web technology that has been around since, well, almost forever. When I create an account on a site I use frequently, I expect that I'll not have to keep re-entering my password every time I visit. Otherwise, I won't be visiting that site very frequently.

Single sign-on is not just about convenience, either. A unified user management system is a vital ingredient in the foundation of a cohesive online experience. Think about what your users will be doing, especially in light of the fact that you're going to implement all those great social software features. As I've mentioned before, the library website can be so much more than just a resource--it can, and should be a destination--a community touchstone. You can't do that if there is a functional disconnect between what you're offering and how you're offering it.

Single sign-on will prove to be a more difficult implementation than you may be thinking at the moment. As you scratch the surface, you'll see why, what will all the disparate software you'll be gluing together. After all, it's not like our vendors are going out of their way to offer and support open standards. We ought to, of course, for many of the same reasons I've outlined for open source. Open standards, however, gives us the flexibility both internally and externally to promote vital services in a timely and easily accessible manner. That sounds good, right? Adopting W3C standards will ensure that we've provisioned for any eventuality. Need to export? No problem. Someone wants to get Greasemonkey all up in your site? Go right ahead, Ed. RSS feeds? Absolutely essential. Want to offer a web services front-end to your OPAC? Why not use SOAP and throw in some WSDL so that potential coders can hit the ground running? Open standards, open minds, open doors.

Then there's the white elephant. Your OPAC--that malignant growth that looks nothing like the rest of your site and appears to have been coded by a CS 101 student who is contemplating switching majors to say, English. Insist on an integrated OPAC. Again, this may be a technical challenge, but nothing is impossible. If you find a way to tame the beast, you're going to completely transform the way your website operates. Ideally, the OPAC should be embedded inside the framework of your site so that you have access to all the site data and functionality during page parse. Once you've got control over what, where and when your OPAC displays, you'll find that a world of opportunity has opened up to you. While pondering a way to achieve this, you may find yourself, again, at your vendor's doorstep, whimpering, "please sir, may I have some more?" Unless the request is in an RFP, however, good luck. All we can do is chip away at them, in the meantime, there are ways of getting around that technical hurdle, but they probably require a programmer--a position libraries should consider adding anyway.

All this is an oversimplification of an arduously complex process, I confess. Sometimes, however, when you're not sure where to begin, it helps to consider all your options within a set of parameters. If I were to launch into a library website project right now, these are the "must-haves" I'd start with. For my part, these comprise an ideal that will stand a project in good stead as we continue to cast about in a 2.0 world.

[tags]Library, Libraries, L2, Web Design, OPAC, Development, Programming, Coding, PHP, HTML, HTTP, AADL[/tags]

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]

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.

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.