Life’s had me buried, so I’ve neglected my blog–be kind and cut me some slack!

At any rate, my little holiday treat this year is a catalog search cloud for the AADL catalog. For about four months now, I’ve been collecting search statistics on queries done against our catalog with the sole intention of creating this little proof-of-concept app.

Basically, it looks at the {x} most popular searches in the past {x} days and generates, what we all recognize, as a tag cloud of those searches with links into the catalog for each.

I say this is a “proof-of-concept” feature because in the coming months, we’ll be launching into our AADL.ORG 3.3 development push which will, hopefully, include a whole lot more of this type of stuff.

Have a safe, happy holiday. I won’t take 2 months to do another post, I promise!

I’ve updated AADL’s PatREST interface to reflect an addition I’ve made to the PatREST specification (now 1.3). This addition takes advantage of OCLC’s Audience Level indicator. OCLC makes this information available via an XML web service. From their service page:

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.

In honor of today’s launch of iTunes 7…

I’ve been floating this idea for while, and I thought I’d sketch it out here on the off-chance that someone might run with it.

I think it’s safe to say that iTunes is a fairly ubiquitous application. Versions exist for both Mac and Windows operating systems. It’s free to download, and all things considered, it’s a very nice piece of software. I can also fire up iTunes at any time during the day at work and I’ll almost always see several other users’ shared libraries on our wireless network. I’ve even had people listen to my shared library. This begs the question, why aren’t we sharing an iTunes library at our, um, library?

The problem is that we could definitely create an iTunes share on a computer somewhere, but we would soon run in to disk-space issues and other complications such as always having to be logged in with iTunes running in order for the service to be active. Well, I’ve been using a very cool piece of open-source software for a while that solves this. It’s called mt-dappd. It’s basically an iTunes server that runs as a daemon in Linux. It has a number of nice features, including playlist support. It would be quite easy to set up a new server with a terabyte or two of storage, and have your technical services department start importing new CDs as they come in (tech-serv. people are going to kill me, I know). Of course, they don’t have to import every CD they get, maybe the more popular ones–that’s up to your library.

Once your tech services folks are done importing a batch of CDs, they could be given an rsync script that syncs the new material to the dappd server. I’ve experimented with this a bit and use the following command to do it for my iTunes library:

rsync -zrptL --delete-after --progress -e "ssh" --include=core --include=tags --exclude=.DS_Store --cvs-exclude "/Users/TechSrv/Music/iTunes/iTunes Music/" root@dappd.mylibrary.org:/path/to/itunes/volume/

If you’ve set the rescan_interval option in your mt-daapd.conf file, the running mt-daapd daemon will automatically re-scan the file system for changes. The result is that you’ve got a system for sharing music that requires little or no intervention after the initial setup. Because mt-dappd allows you to specify multiple locations for music files, you could simply change your rsync script to point to another directory once the tech services computer fills up with music.

This seems to me to be an easy way to provide low-barrier access to content on your existing guest and wifi networks. It also doesn’t require the material to be on the premises. In addition, If your library produces podcasts, the playlist feature would be a great way to showcase those.

I’d love to hear if anyone does something like this.

I spent a little time last night putting together a little virtual card catalog card generator. Insomnia? Maybe a little.

At any rate, I wanted to share the love and let the people of the world generate their own card catalog images. Usage is fairly straight-forward. Just fill out the info you’d like to see on the card and make it. Obviously, it doesn’t pull any bibliographical data from anywhere, so that leaves a lot up to your imaginations…

Please be kind to it and don’t try to incorporate this service into your own OPACs directly from here (you never know). I’ve provided the source code for that if you’re so inclined.

Enjoy!

Reference:

• Creating a virtual card catalog
• Source code for virtual card catalog images
• Share your Personal Card Catalog

** Update 9/7/2006 **

Fixed the apostrophe slash bug.

A little over a year after launch, AADL's Drupal-powered site has been upgraded to 4.7 from 4.6. Those familiar with Drupal's release schedule and changelog will know that this is a substantial upgrade that puts us in a good position to be ready for the touted and forthcoming 5.0 release (for which there is now a code freeze).

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

[tags] AADL, AADL.ORG, Drupal, CMS, PHP, Library, Web [/tags]