Coffee|Code : Dan Scott, Caffeinated Librarian Geek

I gave up on trying to get Ubuntu 6.10 (Edgy Eft) to run ejabberd today; it looks like there are some fundamental issues going on between the version of erlang and the version of ejabberd that get bundled together. That was a fairly serious setback to my "Evergreen on VMWare" project.

So I decided to give it a go on Gentoo instead. Yes, I can hear the groans already... but hey, I've been running Gentoo at home now for a long time (four years or something like that) and I like that I can pretty easily switch package versions if I don't like the current blessed versions. However, I ran into the nasty cannot open root device or unknown block Grub error when I tried to reboot into my virgin VMWare Gentoo image.

After much gnashing of teeth -- we're talking hours here -- I finally tracked down the problem: I had failed to compile the correct SCSI driver for VMWare into the kernel. Folks, if you're trying to build a VMWare image with a Linux kernel that you're compiling from scratch, the SCSI driver you need is the Fusion MPT driver. And no, it doesn't happen to be kept in the "low-level SCSI drivers" section of the kernel config menu, for some reason. Gah.

Onward to the next painful barrier!

Update: Also, the net device is an AMD PCnet32 Lance. 'Cause you know, I managed to forget to configure that on my most recent Gentoo install.

I managed to corner Mike Rylander after Brad Lajeunesse waved his hands in surrender and offered Mike up as a sacrifice to my questions about Evergreen's support for internationalization. If you're travelling to Canada to tout a piece of (or multiple components of) software, you can be sure that somebody in the crowd is going to be interested in knowing how capable that software is of supporting a bilingual community. As Laurentian University is a bilingual institution, I took it upon myself to be "that guy" and grill Mike a bit on that topic. The good news is that he survived the grilling, and didn't earn the nickname "pork chop"; the better news is that it sounds like Evergreen hits most of the internationalization requirements on the head.

• OPAC interface can be multilingual; Georgia has a large Spanish community and PINES is in the process of translating the OPAC interface into Spanish
  • Sorting results alphabetically (for browsing by author / title) is problematic, however:
    • PostgreSQL doesn't have a good locale implementation for collating sequences
    • Probably not as much of an issue for French / English as it would be for Finnish
• Search currently ignores diacritics (e == é == è), but this setting can be changed in TSearch2
• Subject heading equivalency is possible for the simple use case of "when I search for History--United States--19th century, also show me records with Histoire--Les Etats Unis--19e annee" (or whatever the real LCSH/RVM equivalence would be)
  • This possibility is based on authority records containing both sets of headings -- we can probably rely on / or possibly participate in the EU project to generate equivalence for LCSH, RVM, and German subject headings to seed this data
• Staff client is mostly multilingual-ready (hasn't been a priority requirement for PINES):
  • Most strings are contained in XML files, but there are still pockets of hardcoded strings
  • Switching the locale would immediately load the new strings in the staff client interface
  • "JavaScript doesn't have a good sprintf() implementation" -- check to see whether this suggests that token order can't be rearranged. LibX seems to manage to be able to do this.
• Forgot to ask about boolean operators (e.g. AND / ET, OR / OU)

After the Future of the ILS Symposium wrapped up, Beth Jefferson walked some of us through the current state of the BiblioCommons mocked-up Web UI for public library catalogs; the project grew out of a youth literacy project designed to encourage kids to read through the same sort of social networking and recommendation mechanisms as employed by Amazon, NetFlix, etc.

• Users spend an incredible amount of time in My Account (possibly skewed somewhat due to the Unicorn defaults) -- almost 50% of the page hits in the subject catalogs; therefore they make the account page the home page, rather than the PINES approach of a stripped-down Google-like search interface
• Default settings favour maximum privacy, but initial activities (e.g. adding a review) prompt the user to decide whether they want to share this information or not; very granular, dynamic scheme
• Avoid "top ten" item lists on front page because you're setting your patrons up for a disappointingly long hold time
• Home page is "recently returned items", which prompts users for reviews, tagging, discussions, "users waiting for this item might also like" recommendations; they're trying to build an electronic analogue of the physical return cart (which is what many patrons intuitively use as a recommendation service today
• Tagging is categorized (genre, personal, some other categories I forget)
  • You can subscribe to individual tags that another user has set (so if you only care about what somebody has tagged "mystery", you can avoid getting recommendations for what they tagged "earth science"
  • Unlike most social networking sites, a targeted user has no option to prevent you from adding them as a friend; they can, however, prevent you from sending them an instant message
• User avatars consist of username + font customizations; icon avatars presented too much visual conflict with book covers
• List of books on hold provides alternate recommendations per book
• Technically, the project is being built on top of Unicorn -- catalog data and circ status is dumped on a nightly basis, live circ status is retrieved via NCIP only when an individual item record is displayed
• If a given item is not available at a branch, display says "Available in 2-4 weeks" (or whatever) rather than saying "request by interlibrary loan" -- maybe not so applicable to the OPAC in single-site libraries, but a possible enhancement for a link resolver: "Get it @ XYZ Library" is exactly what students are trying to do in the overall research process, so instead tell them whether something is "available via full text download", "available in print in the XYZ Library", or "available in 1-2 weeks" (for something that will require ILL)
• Bibliocommons hope to make the module an interface that can provide different wrappers for underlying library systems
• Beth offered to provide a webcast walk-through of the UI for a broader audience -- stay tuned

I headed down to Windsor early on Tuesday morning for the Future of the ILS Symposium hosted by the Leddy Library at the University of Windsor. It was a good thing I decided to take the 12 hours of bus + train approach to getting there, as Sudbury's airport was completely shut down due to fog. Despite the fogginess of my own brain after that trip, I managed to make it out to the welcoming reception where Dr. Ross Paul, the president of the University of Windsor (and formerly the president of Laurentian University when I was but an undergrad student there), gave a warm and mercifully short welcome address. It looked like about 75 people made it to the reception, and more like 85 or 90 for the symposium the next day.

If you haven't already, I strongly suggest glancing through Peter Binkley's ultra-concise round-up of the symposium as well as Ryan Eby's summary to get the flavour of the event. I'll put the two unique pieces that I have to offer -- answers to my questions about the I18N support that Evergreen is capable of, and Beth Jefferson's impromptu and impressive demo of the wireframe mockups for BiblioCommons -- here, along with my micro-summary. Ah, and Art pointed to Amanda Etches-Johnson's blog for impressively complete notes from the sessions and discussion panel.

Art Rhyno gave an excellent opening talk on the state of the ILS that came to the conclusion that, if we as the library community want to try to address some of the problems we're facing with the ILS today using our own tools and know-how, the "barn-building" approach is a better fit for our relatively small community with specialized needs than the "bazaar" approach of more general open-source projects. The barn-building tradition of rural communities gives participants a chance to work collectively, share knowledge, and build expertise in the community as they complete project after project. I think this really set the tone: in informal discussions and panel discussions throughout the day, directors were asking "what can we do to move this forward?" and techie types like Peter Murray (despite his assistant director status) were saying "don't let tactical problems consume all of our time; raise the priority of focusing on strategic issues; and let us continue to come together via events and communication channels like code4lib, Access, and this symposium to build that community and expertise".

When asked what we wanted to get out of the day, Art suggested metrics, Eric Lease Morgan suggested a "Windsor manifesto", and I was hankering for a business case to decide whether to continue with a commercial ILS or adopt an open-source ILS like Evergreen. I think Art and I were in the same ballpark (albeit without Ty Cobb); you need metrics for a business case, and they can't simply be "we pay $XXX for annual support, and open-source is free!". You have to take into account how many staff you require for supporting and customizing the commercial ILS vs. an open-source ILS, but that's relatively easy. Measuring patron satisfaction is getting into the harder realm.

What's arguably hardest are the soft metrics for the business case: take human resources concerns. Staff might be afraid that all of the investment that they've put into learning vendor X's cataloging interface will be thrown away with a migration to a different ILS, but if enough libraries adopt that other ILS then staff actually have a more valuable, more portable skill. And if that ILS can be freely deployed by library school students eager to get some hands-on experience, and the install is incredibly easy because it's a preconfigured VMWare image, then libraries gain by being able to hire co-ops or new librarians who already come with useful skill sets. I don't see the traditional vendors satisfying this model today; I can't even tinker with our commercial ILS at home during the evening because I don't want to pay the thousands of dollars that would be required for a test version of that ILS.

So guess what ILS I've been working on creating a simple VMWare image of? If you said "Evergreen", you guessed right!

Anyways, I think most of us need to go through the exercise of building a business case. The time is right for starting serious conversations about where we're going to go in the next couple of years. It doesn't make sense that we should all have to go off and build our business cases in private; there's an awful lot of criteria that we should be able to share, even if we don't want to share numbers. Hopefully we'll continue this discussion, perhaps over at that Future of the ILS blog.

A while back I mentioned on the DSpace-devel mailing list that I was interested in adapting DSpace to use embedded Apache Derby as the default database, rather than PostgreSQL, as a means of lowering the installation and configuration barriers involved with setting up access to an external database. I haven't had time yet to actually carry out my musing, but today I had the chance to set up the Archimède institutional repository on a test server -- and imagine my surprise when I saw a derby.log file sitting in the Archimède repository. It looks like someone else at Université Laval had the same idea as me much further back.

It's still on my horizon to adapt DSpace to Derby; seeing that it works well for Archimède confirms my belief that it's the right direction to go.

Just a short note to let y'all know that I received the thumbs-up from my fellow PEAR developers to add File_MARC as an official PEAR package.

What does this mean? Well, assuming you have PHP 5.1+ and PEAR installed, you can now download and install File_MARC and its prerequisite with a simple command:

pear install File_MARC-alpha

I've also imported the File_MARC source into the PEAR CVS repository, so you can poke and prod and provide patches.

Before moving to a 1.0 release, I have to write up some user-oriented documentation. I have a hankering to provide MARCXML support as well, so that will probably work its way into the package before 1.0. I'd love some more testing and feedback from other library geeks; now that installation is so simple, I'm hoping to see the bugsfeedback roll in.

Oh yes: a big thanks to the PEAR developers who have given me some excellent suggestions along the way, from my first proposal all the way through to this alpha release. File_MARC wouldn't be what it is today without your help!

No candy for Amber this year... just unbearable cuteness!

Her first tooth is poking through her gums, and it was a bit of a tough process for her, but she always has lots of giggles and smiles for us.