Outgoing

{Code}4Lib(); The Conference--Wednesday

The Code4Lib 2006 Conference started today (2006 February 15) in Corvalis Oregon on the campus of Oregon State University.  OCLC is one of the 'Platinum' sponsors, and there are five of us here (counting Eric Hellman of Openly).  Looks like there are something like 80+ people here, which is nice to see.  When the idea of this was proposed it sounded like a good idea to me; it no longer seems strange to see an email list generate a conference.

The first session this morning was a 'virtual' keynote from the Evergreen development team of the PINES consortium in Georgia.  This was done by phone with local PPoint slides, and actually worked pretty well using a mike over a speaker phone.  PINES is growing to about 300 libraries, with 2 million patrons and 20 million holdings and will be running on an ILS they are writing themselves.  Evergreen uses OpenSRF (Open Scalable Request Framework), which uses the Jabber instant messaging protocol for communications.  It wasn't quite clear to me why this stack is such a great idea, but the developers seem sold on it for its scalability and flexibility.

Evergreen is planning to have a 'production' release this summer and to go live this fall (2006).  Since the current ILS doesn't handle serials processing and acquistions, neither will Evergreen on its first release.  It sound like they have around a half-dozen developers involved in the project.  They are developing this themselves because they didn't feel either the existing commercial and open source ILS's didn't support the scale of PINES well.

--Th

Art Rhyno thinks our interfaces should be more like Beeb Beeb Buggy (which he actually sold at one time).  He's probably right, although I've argued otherwise.

--Th

Dan Chudnov just did a talk about unAPI.  Part of the idea of unAPI is to have the simplest protocol possible, since people "just don't get' complicated protocols, or even protocols as simple as OAI-PMH.  Maybe I should have been paying more attention (rather than looking for pictures of beep-beep-buggies), but I'm afraid all I got out of Dan's talk was that even the simplest protocol can be 'hard to get', in particular to see what it can do and how you would use it yourself.  I'm sure it will all become clear on reflection.

--Th

Levels of FRBR

By levels I don't mean the FRBR group 1 WEMI (work-expression-manifestation-item) entity hierarchy, but more the amount of effort devoted to using FRBR.  At the high end you get specialized databases such as AustLit, the Australian literature catalog (which unfortunately you need a log-in to use), where they've gone to a lot of work to make sure they know who everyone is and understand the different editions of an author's work.  Just below that there are systems like FictionFinder here at OCLC that work with existing bibliographic information, but do extensive processing of the data to come as close as possible to a real FRBR understanding of the records.

It is possible, though, to step down from there and still make use of the FRBR hierarchy.  Probably about the minimal level is what Open WorldCat has been doing the last year: for each work a representative manifestation is chosen and that's what is exposed in Yahoo and Google.  This leaves much to be desired, but since the search engines aren't very intelligent about metadata, it's a lot better than giving them multiple manifestations for popular works and confusing everyone.  And, as Open WorldCat has shown, if someone does get into the system via that manifestation, you can then show them the other possibilities. (This week, Open WorldCat has gone a step further.  When you land on a Find-in-a-Library page (e.g. The Broker in hardcover, or The Broker in paperback) the libraries that display are rolled-up based on FRBR matching and icons for other formats we're aware of are displayed.)

The interface I've been working on with Phoenix Public is an attempt at something in between Open WorldCat and FictionFinder.  It starts with the same FRBR matching that those use, but, like FictionFinder, all the manifestations are searchable.  The search results, though, only show one manifestation from a work.  Of course, since the data is about Phoenix's collection, the item level is important and can easily have two dozen copies in a dozen different branches.  This brings up the same problem Open WorldCat faces--how to show the patron the possibilities without confusion.  The solution is probably to add some sort of annotation to the displayed manifestation to lead users to other manifestations if they so desire, similar to how Open WorldCat is giving access to various formats.

--Th