Liblime Acquires Katipo’s Koha Division

March 26, 2007

I first saw this while browsing oss4lib

Press release here:

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!


Mobile Media

March 15, 2007

It was a sad day in my life yesterday… my iPod died.

After some heavy use over the last year or so, in which it recently survived my rather cack-handed (yet successful) attempt at replacing a knackered battery, the play/pause button finally stopped working. And when I tried to re-open the case as I had done to replace the battery, I committed the cardinal sin of ripping the electronic taple connecting the scroll-wheel to the battery panel, ensuring my iPod was royally f**cked :(

The demise of the iPod had got me thinking about what to replace it with. I would seriously reconsider buying another iPod, they are as sexy as hell, but I wasn’t that impressed with the short life-span of my original, and the difficulty in replacing what should be easy-to-replace parts (ie. the ones most likely to crap out – e.g. the battery). So what shall I get instead?

I’ve been playing with my Sony Ericsson k750i lately – I’ve loaded the Gmail app and Shozu onto it – the idea being that whilst travelling around Europe I can keep (myself and other people) up-to-date and post photo’s and messages online easily (either via txt [sms] or these java apps). Which has got me thinking about other devices I could be using to keep mobile, as I’ve decided I’m not lugging my laptop around with me for three months backpacking through Europe, and would it be wise to have a device that can keep me mobile (ie. online) and play music and play movies and possibly even do a bit of gaming.

So I’ve been looking at the Sony PSP as such an option, it looks pretty, does music and videos, has wi-fi (but does it handle the web very well… I’d definitely want it to cope with uploading to Flickr, YouTube, and maybe even writing emails, and blog posts; or is the wi-fi only good for multiplayer gaming). Do a search for “sony psp” and “hack” or “homebrew” and you’ll start to see the PSP can be used for a lot more than music movies and games. However, UMD (proprietry Sony movie format for the PSP) sucks, and do I really need a gaming machine – nice to have, but a bit indulgent.

Should I just stick to ye olde internet cafes – cos if the PSP ain’t no good at picking up free wi-fi I’m going to have to be visiting those anyway, in which case, it would be just as easy to use a cafe’s PC. In which case, should I just be looking at another iPod or a variation thereof??

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.