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!

Advertisements

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.


Installing Koha

February 22, 2007

Having a test server set up on my home PC, I thought I’d try installing Koha and have a play around with it.

There’s a Windows install package for Koha which I downloaded and ran. It appears to be a straight-forward install… except for one catch. The install appears to rely on Apache, and ActivePerl to be installed in specific drive locations in order for the install to correctly amend various configuration files.

Unfortunately my Apache/PHP/MySQL server configuration is not installed in the default C:\ locations, so the Koha install from the Windows.exe file did not work.

I browsed around online to try and find a “quick fix” to the problem, namely the content I would need to input into the apache httpd.conf, koha.conf, and myini.conf files manually. Unfortunately I didn’t find the necessary content for these files anywhere.

I’m aware that Koha has a number of mailing lists and forums I could use to help me out with this, but I think perhaps playing with Koha may just have to wait until I can set up a server on a standalone box (as opposed to my every-day laptop on which it runs at the moment).

 Le sigh.


Response to : The “OPAC doesn’t do like Amazon/Google” problem

November 22, 2006

I posted a response to Opacula’s recent post The “OPAC doesn’t do like Amazon/Google” problem. My comment covers what I think really, but I can totally see where Opacula is coming from with this.

Coming from a special library background, I’m often irritated at the lack of customisation or experimentation done by special librarian’s with regards to their online catalogue(s) and other tech-tools they should be using. This is usually due, in my experience, to the lack of IT skills in the library… and relying on an in house IT team to help you out is usually totally out of the question. Mostly because of a lack desire to explore and experiment with new technology from the IT team, who is too focussed on security and procedure, or because they have no clue about what the library does or what it wants to achieve.