Share your Personal Card Catalog

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!.

III-XMLOPAC Class 1.9 update

iii-xmlopac-1.9.tar.gz

While working on the virtual card catalog, I ran into some serious issues with the way my xmlopac class was dealing with III’s malformed XML (sound familiar?). Again, it all comes back to the fact that III’s XML output claims to be UTF-8, but in reality, it is no such thing. These problems have also been plaguing our users who would often complain of missing titles, authors, etc.

Every time this crops up, I’ve fixed the problem, but it’s sort of like putting your finger in the dike–another leak springs up somewhere else. Anyway, the 1.9 update goes a long way toward applying a broader fix to those problems. I’d recommend that anyone who is currently using this class to update because it’ll greatly improve your results.

RESTful output from AADL catalog

After a somewhat restful day… (groan)

In an effort to make the AADL catalog a little more accessible to developers, I’ve written a little bit of middleware that generates REST output from the catalog. Yes, we currently have RSS feeds directly from the catalog, but they are not suited for true development. REST output will allow developers to freely access both hitlist data and bibliographical data without having to do any funky scraping, parsing, or wand-waving.

Please take a look, hack away, try to break it, whatever. Beta testers are always welcome!

Here are the details:

If you were to do a keyword search for “Harry Potter” on our catalog, you would see the URI looking like this:

http://www.aadl.org/cat/seek/search/X?Harry%20Potter&searchscope=26&m=&SORT=D

That, of course, is the hitlist. You want RESTful output. So change the URI to:

http://www.aadl.org/cat/rest/search/X?Harry%20Potter&searchscope=26&m=&SORT=D

Basically, you are just changing “seek” to “rest”. The base URI for the REST interface is http://www.aadl.org/cat/rest/ but going there without a query won’t get you much. Anyway, the output from the preceding looks like:

<?xml version="1.0"?>
<p:Records xmlns:p="http://www.aadl.org"
           xmlns:xlink="http://www.w3.org/1999/xlink">
	<Record id = "1249810" xlink:href="http://www.aadl.org/cat/rest/record/1249810"/>
	<Record id = "1251743" xlink:href="http://www.aadl.org/cat/rest/record/1251743"/>
	<Record id = "1239167" xlink:href="http://www.aadl.org/cat/rest/record/1239167"/>
	<Record id = "1260602" xlink:href="http://www.aadl.org/cat/rest/record/1260602"/>
	<Record id = "1249532" xlink:href="http://www.aadl.org/cat/rest/record/1249532"/>
	<Record id = "1249531" xlink:href="http://www.aadl.org/cat/rest/record/1249531"/>
	<Record id = "1230466" xlink:href="http://www.aadl.org/cat/rest/record/1230466"/>
	<Record id = "1258774" xlink:href="http://www.aadl.org/cat/rest/record/1258774"/>
	<Record id = "1237981" xlink:href="http://www.aadl.org/cat/rest/record/1237981"/>
	<Record id = "1224899" xlink:href="http://www.aadl.org/cat/rest/record/1224899"/>
	<Record id = "1236034" xlink:href="http://www.aadl.org/cat/rest/record/1236034"/>
	<Record id = "1228878" xlink:href="http://www.aadl.org/cat/rest/record/1228878"/>
</p:Records>

That’s useful to get the hitlist of records for that search. Obviously, those URI’s above denote the corresponding records in REST format. The first one (http://www.aadl.org/cat/rest/record/1249810) looks like:

<?xml version="1.0"?>
<p:Record xmlns:p="http://www.aadl.org"
          xmlns:xlink="http://www.w3.org/1999/xlink">
	<callnum>823 Bu</callnum>
	<author>Burkart, Gina, 1971-</author>
	<fulltitle>A parent's guide to Harry Potter / Gina Burkart</fulltitle>
	<title>A parent's guide to Harry Potter </title>
	<pubinfo>Downers Grove, Ill. : InterVarsity Press, c2005</pubinfo>
	<desc>112 p</desc>
	<bibliography>Includes bibliographical references</bibliography>
	<contents>The Harry hype -- More than a story -- The modern fairy tale -- Discussing fantasy with children -- Morals, not magic -- The real issues in Harry Potter -- Dealing with traumatic experiences -- Facing fears -- Battling bullies -- Delving into diversity -- Hiding hurts -- Letting go of anger -- Getting help -- Choosing good over evil -- The power of love -- Facing spiritual battles</contents>
	<isbn>0830832882</isbn>
	<price>$11.00</price>
	<lang>eng</lang>
	<copies>0</copies>
	<catdate>08-16-2005</catdate>
	<mattype>a</mattype>
	<avail>No copies available</avail>
	<recordlink xlink:href="http://www.aadl.org/cat/seek/record=1249810"/>
</p:Record>

This data would be very easily accessible using something like PHP’s simpleXML. I think one of my next little side projects will be to write a class that accesses this and make it available for download here. Enjoy!

Hichcliffe on Ajax

I know I’ve written a fair amount in response to Dion Hinchcliffe’s posts, but I wanted to point out his latest offering which highlights a number of great Ajax resources. He’s tends to look at Web 2.0 objectively in a way that I appreciate. Lately he’s been on a roll.

I’ve said before that we need to be careful about laying our hopes and dreams at the feet of the (supposed) almighty Ajax. I still believe that, but I think it can fill a niche that desperately needs to be filled. I was talking with Eli Neiburger today about the new MiLE client. (You may remember from a previous post of mine that MiLE was recently hacked. Badly.) Their new client, much to my chagrin, is java. Java is a network administrator’s nightmare, a relic that urgently needs to be put out to pasture. I’m truly disappointed. For what that client does, an Ajax alternative could easily take its place.

Ajax is well positioned to address the need for client-side, stateful applications. I’d like to see the “next gen” ILS and ILS support software take advantage of it in place of Java. Requiring a contemporary web browser is a much more reasonable expectation than requiring customers to juggle different versions of the JRE. I understand that using java has helped to defray operating costs for vendors, but with Web 2.0 technology, the same level of ubiquity can be achieved without penalizing the customer by encumbering them with a ’90s albatross. This could easily be done using the model I (and others) have been begging for: light clients, extensive, standards-based APIs. The tools Web 2.0 has made available obviate the need for complex client-side applications.

Let me be clear on the difference between what I’m suggesting in this post as opposed to what I’ve said about Ajax in the past. I do not think we should launch into projects that require our patrons to have Ajax-capable browsers. I think that would be premature and somewhat irresponsible. I’m saying that the applications vendors require libraries to use on the back-end should adopt Web 2.0 technologies, such as Ajax. Shedding an old technology like java should be a priority.

Hinchcliffe’s article also serves as a good starting point is you are looking to read some material that will familiarize you with Ajax. He also points out that it is improving, and worth keeping an eye on.

III Bib # to ASIN to Cover Art

azImgSrc-1.0.tar.gz

I’ve written a PHP script that takes a III Bib # and, using amazon’s REST interface, it tries it’s darnedest to find the ASIN for that item. It will then store that Bib#-ASIN pair in a database. After that, it will cache the small, medium and large cover images associated with that ASIN in another database table and display whichever one you want.

This script requires the latest version of the III-XMLOPAC class (1.6), PEAR::DB, MySQL (of course) and PHP5 (or PHP4 with SimpleXML). In addition to that, you’ll need to have your own Amazon Dev token, etc.

Essentially, I wanted a way to get more cover art into the catalog. If you currently use Syndetics, you’ll know that you almost never get any cover art for CDs and DVDs. My solution was to write this. Just to warn you, though, this script will not return ASINs and cover art for all the items in your collection. Far from it. There is about a 30% hit-rate. I could easily get that higher, but then accuracy drops off, and I want 100% accuracy.

So, I plan on working with this script, massaging the search to figure out ways to get that 30% up. Please feel free to hack away at it yourselves too, but bear in mind, that I’m looking for accuracy above all else. If you’re really interested in how I’m determining an accurate hit, take a look at the code. Basically, I’m doing an initial search, then I match the UPC number on the amazon record to the stdnum info from the Bib record. Doing it this way, I haven’t seen a wrong match yet.

Incidentally, here is a hit list with images from this script:

To use it, you’d basically do something like this:

<?php
 
$bibnum = "123456";
echo  '<img src="/azImgSrc.php?bnum=' . $bibnum . '">';
 
?>

As a side bonus, you’ll have a nice table with Bib#-to-ASIN data. You can even manually add data to that table to ensure your favorite records have images associated with them.