Coffee|Code : Dan Scott

Update 2010-09-28: pedantic XHTML fix

The recorded version of the Evergreen episode of the FLOSS Weekly show was released over the weekend. I'm happy to say that Lynn watched it without looking too pained at any given point, and the Evergreen project has already had several responses to our plea for assistance so far, particularly on the packaging front, which is fantastic! Just having one more skilled helping hand makes all the preparation for and stress about the show worth it.

Several points that amused me about the show as I glanced over Lynn's shoulder:

• In Randal's introduction, he said that I "worked for Coffee|Code", full-stop. Aside to Leila Wallenius, the University Librarian of Laurentian University: no, there's nothing I need to tell you, I'm still a full-time employee at the University and I'm not planning on going anywhere! (That said, Coffee|Code Consulting is a registered sole proprietorship that provides small blocks of consulting services for Evergreen software in my spare time).
• For the first half of the show, my affiliation was shown as the (misspelled) http://coffecode.net. So of course I immediately ran out and bought that domain.
• Co-host Dan Lynch expressed a wish that his own show, Linux Outlaws, had a guest list like FLOSS Weekly. Oddly enough, some time ago when the subject of librarians and their fanatical devotion to open access to information came up on Linux Outlaws, I had submitted a feedback form on their site saying (essentially) "hey, if you want to talk to a Linux-loving free software-developing librarian some time, I'm around..." but I think that comment went into the ether.

If I ever do a video interview like this again, I'm going to try to:

• Prop my laptop up on a couple of LCSH books or attach a separate web cam at a proper height so it doesn't appear that I'm looking down on the viewer.
• Cut down on the "uhm"s and "ahh"s and stare a bit more robotically at the camera instead of rolling my eyes as I rack my brains to come up with an answer
• Stop rambling and trust the interviewers to take the show in the direction that their audience will be interested in instead of trying to jam in points that I think are important or interesting
• Ensure that my erstwhile partner in crime has a better Internet connection

Last week, I started my summer vacation with a weekend at a friend's cottage. By Tuesday I was deeply engrossed in some Evergreen enhancement work for the International Institute of Social History. I'm building an authorities management user interface that properly exposes Evergreen's powerful authority support in the 2.0 release: browsing authority lists, editing authorities and having the updates ripple through to the bibliographic records with controlled fields, merging and deleting authorities... here's a screenshot of the interface in progress: . The numbers represent the number of bibliographic records linked to each authority record. These are still early days, but I think there are some cataloguers that are going to be pretty excited about this functionality when they get their hands on it.

This week, I'm on location in the Robertson Library at the University of Prince Edward Island doing some Evergreen consulting work for them. The good people at UPEI have put my family and I up in a nice cottage on the island, so I'm toiling away at improving Evergreen during the day while my family explores the island. Melissa Belvadi and Grant Johnson have put together a list of pain points that they would like me to address that happen to mesh nicely with general pain points that have come up over the years on the Evergreen mailing lists. My first priority has been to make working with spine labels a little less aggravating. I'm happy to say that after a day and a half, I've been able to teach the spine label editor how to (*gasp*) move up and down with the arrow keys and (*ooh-ahh*) insert and delete new lines and (*w00t*) have the spine label defaults come from library settings that only have to be set once instead of being individually set by each cataloguer. Oh, and I've added font size, font weight, and font family to those settings so that you can have 20 pt. bold Helvetica spine labels if you want them.

All of this code is being committed to Evergreen trunk as I hit functionality milestones; much of the authority work has made its way into the Evergreen 2.0 alpha release that was cut on Monday (although not yet announced officially). On Monday I also cut the OpenSRF 1.6.0-alpha release and uploaded a virtual image built on Debian Squeeze reflecting the OpenSRF/Evergreen alpha releases to http://evergreen-ils.org/~denials/Evergreen_trunk_2010_08_23.zip (note that it's 500 MB, and does not come with X installed, so it's primarily aimed at users that are already familiar with Evergreen and just want to see the new stuff without having to go through the entire install process).

I did take some time off of Evergreen development this afternoon, as I was honoured to be one of the two guests on the FLOSS Weekly podcast. Mike Rylander and I were there to discuss Evergreen with the hosts, Randal Schwartz and Dan Lynch. Unfortunately for Mike, me, and the audience, Mike's Skype connection kept dropping and I had to do the bulk of the talking. Despite missing the contributions from Mike's massive brain, I'm told that the show went well. So if you're interested in hearing a bit about Evergreen and why I do what I do, keep an eye open for the interview at http://twit.tv/floss132 - it should be edited and online by Friday, August 27th at the latest. I tried not to swear too often so they wouldn't have to do much editing work - heh.

Finally, somewhere in there I celebrated another birthday. Oh yeah! Older? Yes! Wiser? Probably not.

I've just released the PHP PEAR library File_MARC 0.6.0. This release brings two JSON serialization output methods for MARC to the table:

• toJSONHash() returns JSON that adheres to Bill Dueber's proposal for the array-oriented MARC-HASH JSON format at New interest in MARC-HASH JSON
• toJSON() returns JSON that adheres to Ross Singer's proposal for an object-oriented JSON format (I could only find a sample at this paste - not sure if there's a broader description anywhere, but really -- who needs it?)

The JSON formats should be useful for developers who don't want to have to deal with the overhead and sluggishness of a MARC parsing library (yes, File_MARC, I'm looking at you) just to deal with MARC data. Both formats are round-trippable and compact, which is why I chose to support them.

The use of the json_encode() function bumps the minimum PHP version requirement for File_MARC up to 5.2.x from 5.1.x, which kind of sucks, but given that PHP 5.2.0 was released in 2006, I think it's worth it.

You can install File_MARC using the 'pear' command on most environments as follows:

pear install File_MARC-beta

As a librarian who works at a library that primarily uses the Library of Congress classification scheme, I have been interested for a long time in teaching Evergreen to be aware of call number schemes other than Dewey. The problem, in a nutshell, is that Evergreen simply applies an alphabetical sort against the the uppercased version of the call number when generating call number browser displays - resulting in LC call numbers that sort incorrectly, like:

• K 215 .E53 W37 1997
• K 22 .U748 v.18

When the subject recently came up on the open-ils-general mailing list, I decided to follow up with some code. So, as of this weekend, Evergreen trunk now has a generalized infrastructure for generating sort keys for call numbers. The broad strokes of the current implementation are:

• The classification scheme is set the level of the call number.
• Classification schemes are defined in the asset.call_number_classification table with a pointer to a database function to call to generate a normalized sort key for the given call number.
• Three classification schemes are available out of the box:
  • Generic (the default) - a simple normalization approach that produces reasonable results in the absence of special rules for Cutters, etc
  • Dewey (DDC) - a normalization routine taken from the Koha C4::ClassSortRoutine::Dewey Perl module
  • Library of Congress (LC) - a normalization routine that simply wraps Bill Dueber's excellent Library::CallNumber::LC Perl module
  - and adding more classification schemes is just a matter of adding another row to the asset.call_number_classification table and the appropriate sortkey-generating database function.

Note that this is the first time, to my knowledge, that Koha code has been adopted directly by Evergreen. I included attribution for the copyright holders in both the Generic and Dewey normalization functions. I wrote the Generic implementation in Evergreen from scratch shortly after taking a look at Koha's approach, so in some corners my work would be considered a "derived work". Koha's Dewey normalization function was (somewhat surprisingly) the only open-source implementation that I could find for Dewey, so it made perfect sense to me to adopt that for use in Evergreen. Many thanks to Koha for their use of the GPL v2 or later licence!

There are still some limitations and low-hanging fruit that I hope to address in the near future:

• Right now you can only manipulate classification schemes via SQL. The Holdings Maintenance dialogue needs to give cataloguers the ability to set the classification scheme for each call number, because I'm sure they don't want to drop down to the command line. This setting should probably be sticky during a given session, so that if they're processing a cart of government docs, they won't have to change the scheme from the default to CODOC for each item.
• Speaking of defaults, each library needs to be able to define a default classification scheme - so your consortium can have a Dewey library and an LC library and a SUDOC library, and their preferences won't trample each other. This can just be a simple org-unit setting.
• Following on Mike Rylander's advice, the asset.call_number_classification table should gain a new column that lists the field/subfield combinations used to find the appropriate call number (if any) for each scheme in a given bibliographic record. Then the Holdings Maintenance dialogue can offer the appropriate call number based on the classification scheme.