Liblime Acquires Katipo’s Koha Division

March 26, 2007

I first saw this while browsing oss4lib

Press release here: http://liblime.com/news-items/press-releases/liblime-to-acquire-katipo

Wow. Congrats to Katipo.

I’m super keen to get my hands on a working copy of Koha, because I’d love to have a look at it – unfortunately, I have had some problems installing a test version on my home server.

I’m convinced there’s room for Koha to be more widely used in (atleast) the special library market in New Zealand (home of myself, and Koha). Well, I’m convinced there’s room for another small library system in this market anyway, and with Government starting to make more serious noises about open source software, what better than Koha?

As far as I can tell, the NZ special library library system market currently consists of two products: DB Textworks/CS and… Liberty. (er, another software that was homebrewed until it got sold to an Australian company; the name of which I’ve temporarily forgotten). The latter has suffered I believe since it was sold to Australia (both in quality and support) and while I believe DB Textworks is a decent product, I still believe special libraries out there could do better!

I’d love to get a job like working at Liblime as a NZ representative… I was going to approach Katipo upon my return to NZ. So perhaps I’ll drop Liblime an email instead!


Jumbled Thoughts: My OPAC Online Catalogue Sucks…

March 15, 2007

Life as I Know It has a very useful list of various blog postings on the issue of OPACs. And I think Jennifer is on to something when she states:

The function of OPACs is not clear to average library users.

Only, I would go further and say, the OPACs function may not only be unclear to the user, but also to the librarian.

And this is why: I think one of the inherent problems contributing to the suckiness of catalogues is that the systems they are based on, were (I’m presuming here), used primarily by librarians in a “technical services” capacity to catalogue and manage their stock. They were not solely devised as public systems that facilitated the findability of library stock, let alone the findability of documents or information that the library didn’t physically own or have access to. Nor were they designed for the non-professional – it was the librarians that were using these sytems, often on the behalf of clients, so their search functions and interfaces were designed for the informational professional, not the general public.

As a librarian I know I have asked myself: is our catalogue simply a tool for cataloguing and managing our stock? How do we want to use the catalogue to provide access to electronic items? What about items we don’t hold but know users would be interested in, should these be included in our catalogue?

Not so long ago a situation arose at an old workplace: Our manager wanted us to start cataloguing (indexing) key articles from the journals we subscribed to (both hard copy and electronic) so our users would find these when searching our catalogue. And I can see where she was coming from with this – using the catalogue as the primary finding tool for key information on our key topic areas, but conceptually I had a few issues with us doing this:

  1. we had subscribed to a number of full-text and abstract databases – in essence we would be duplicating content (and effort) already available to our users via these specialist databases.
  2. the majority of our journals were circulated, and issues of journals often spent months and months on circulation; as it would be unlikely we would have access to the physical articles we had catalogued, and our budgets were too tight for much of an increase in our document delivery requests, it was decided that we would only catalogue articles we had access to electronically. Which to me contradicted the original concept of why we were cataloguing these articles inthe first place; just because we couldn’t supply the full text of an article didn’t diminish it’s importance our users, but these would not be available via our catalogue anyway.

What I’m trying to say here is more eloquently mirrored in a couple of articles from D-Lib:

And by Karen Schneider:

When we are talking about the suckiness of OPACs, the systems we are comparing our catalogues to and using as a comparison to lament the suckiness of our catalogues (the Amazons and social networking sites) we need to remember that these were built in a completely different era for completely different purposes to the library catalogue of the 1980s (and from what I can tell, most of the big integrated library systems of today are just patched up versions of these.. with the obvious exception on things like Koha). I couldn’t agree with the Creative Librarian more when they say:

Personally, I think the only thing needed in common is the database. Make the database open and write however many different pieces of software you need for what you need to do. Throwing all of the functions needed into one piece of software is part of what’s made it so hard to deal with already. We need to strip out the unnecessary first, then add in all the cool Web 2.0 stuff as it looks useful. And if it turns out not to be used, strip it out again.

I’m thinking a modern library system could be a number of separate (SQL?) databases linked together and run over web interfaces (both the front-end for the user, and the admin-end for the librarian). We need our library systems to reconsider or reinvent the use of MARC and Z39.50, and start thinking about building open systems that utilise XML that can integrate with other web applications easily.