It’s finally here! After tons of hard work, the Koha community has announced the release of Koha 3.0 RC1. This from the many Koha mailing lists:

You can download from the usual location:

http://download.koha.org/koha-3.00.00-stableRC1.tar.gz
http://download.koha.org/koha-3.00.00-stableRC1.tar.gz.sig

You can check the integrity of the package; either by verifying the provided GPG signature (.sig) or by comparing the MD5 checksum:

5cc0914c5e8250c2491f4dbcf27d4301 koha-3.00.00-stableRC1.tar.gz

I’ve also tagged this in Git as “version 3.00.00 stableRC1″ v3.00.00-stableRC1

This is the third packaged release of Koha 3. Prior to the official stable release of Koha 3.0, translations will be updated; additional issues and bugs may be be addressed. A list of these are documented on Koha’s Bugzilla:

http://bugs.koha.org

and organized on the 3.0 RM’s QA notes Wiki page:

http://wiki.koha.org/doku.php?id=en:development:qanotes3.0

The release notes for this RC1 version are pasted in below, and will also on the koha.org website sometime soon.

Cheers,

–
Joshua Ferraro
Koha 3.0 Release Manager

And as many of you know (well at least those of you on Twitter & Facebook) I have been working on the documentation for this new release and my working draft can be viewed online (hopefully to be moved to a more collaborative medium soon) via LibLime’s Google Sites at http://sites.google.com/a/liblime.com/koha-manual/Home. Feel free to notify me of any changes, suggestions, etc.

Technorati Tags: koha

To do my part for
LibLime's bloging policy
here are two haiku

Koha ILS,
we're nearing the 3rd release
watch koha dot org

Now that we’ve had a beta version of Koha 3.0 out for a little while now, there is some increased interest in getting a final version of Koha 3.0 put together soon. Paul recently started a discussion on the koha developers list about what we need to do to get a release out the door. This includes deciding on the last minute features we would like to include to make it a cohesive, useful product, what bugs absolutely need to be fixed, and the logistics involved in maintaining that version while we set our sights on the next version of Koha. I think that in the coming days and weeks we will see this discussion continue and a flurry of activity as we try to put some effort into finding the balance between completeness and timeliness

Who added AI to Koha?

Hint: Git tries its best to properly assign credit to patches, but it doesn’t always get it right.

As Andrew S. Tanenbaum said, “the nice thing about standards is that there are so many of them to choose from.” Good old non-standardized library jargon provides an even richer field of variation. Do libraries serve members, patrons, clients, or customers? Is a patron placing a hold request or a reservation? When the item arrives and the patron checks it out, do we call the transaction a loan, a checkout, or an issue? Can the library issue an issue to patron? How many synonyms have I missed so far?

Koha’s base HTML templates use “English”; translations to other languages are generated by extracting strings from the templates and giving them to the translators. The files containing translated strings are then used to create a set of HTML templates in the desired language.

I put “English” in scare quotes because while nominally the language of coding is (I think) the New Zealand variant of the Queen’s English, in practice it is a mixture of NZ English, UK English, US English, and so forth. That already opens the door to potentially desirable localizations — after all, one really ought to put one’s “colour” and “flavor” in the right sociogeolinguistic buckets.

Which brings us back to library jargon — a “reservation” in one country is another’s “hold request”. An academic library’s “recall request” is a public library’s “you’ve gotta be kidding!”. A bright idea! Let’s convene an international committee to standardize English-language library jargon! I’m holding my breath with anticipation …

…

Still holding — but why not expand the scope of the committee and handle French library jargon?

…

*thunk*

later

OK, so that didn’t work. For now, it looks like a better solution is to embrace the differences and set up en-NZ, en-US, en-GB, etc. as defined translations for Koha, per some recent traffic on the koha-devel list. Localization ultimately doesn’t apply to just language and country; think of en-US-academic_library, en-US-small_public, etc.

I’m happy to announce that a packaged beta release of Koha 3 is now available. You can download from the usual location:

http://download.koha.org/koha-3.00.00-beta.tar.gz
http://download.koha.org/koha-3.00.00-beta.tar.gz.sig

You can check the integrity of the package; either by verifying the provided GPG signature (.sig) or by comparing the MD5 checksum:

84f6ec3615155cfa755a9e7139bd07df koha-3.00.00-beta.tar.gz

I’ve also tagged this in Git as “version 3.00.00 beta” v3.00.00-beta

This is the second packaged release of Koha 3. Prior to the official stable release of Koha 3.0, software issues, bugs, and unimplemented features must be addressed. These are documented on Koha’s Bugzilla:

http://bugs.koha.org

and organized on the 3.0 RM’s QA notes Wiki page:

http://wiki.koha.org/doku.php?id=en:development:qanotes3.0

The release notes for this beta version are pasted in an email to the koha-devel and main koha user lists, and will also on the koha.org website sometime over this weekend.

Recently, on the Koha list, one of the users asked about the possibility of adding a ‘browse’ feature to the detail of a given record. The idea is, you might want to see what books appear on the shelf before and after that item, in a given location and shelf. As it turns out, it was a fairly trivial exercise — I spent Sunday afternoon whipping up a basic browser degradable shelf browser, and Owen Leonard, Koha’s Interface Designer, made it look pretty :-).

Why degradable? Glad you asked. One of the goals of the Koha project from the beginning is that all of the interfaces are fully degradable and will work in any browser. So whenever we code a new feature, we write it for that environment first, then we slap on any additional functionality to make it prettier or more Ajaxy, etc.

Anyway … Here’s a basic screenshot of the display:

Ever thought it would be kind of cool to be able to IM your ILS and find out when the items you have out are due back? Or do a quick search of the catalogue? Well I did, so here’s what we have so far.



You can login, find out what you have out, and search by title or author. It still needs to be expanding a bit, currently its only working with AIM (jabber is in progress), and there is a lot more it could potentially do. Perhaps renewal, placing reserves, and of course expanding the search. The API is all there in Koha so its just a matter of writing the layer between the IM protocol and Koha.

If people have any suggestions they are willingly accepted.

There’s been quite a lot of talk lately in library tech circles about OCLC’s new commercial xISBN web service as well as similar free services available from LibraryThing and PINES. From OCLC’s announcement:

The xISBN service is a machine-to-machine service that communicates metadata derived from WorldCat. The goal of xISBN is to help connect different expressions (each identified by an ISBN) of a single work.

For example, if a library owns two copies of the book “Horrible Harry”, each with different ISBNs (paperback and library bound, for example, 0141306742 and 061345278X), the OPAC system can use the xISBN system to join the two records. Or, if the OPAC needs to make links to the newest version of a book in Amazon, or join a database of book reviews, xISBN service can be invaluable.

I’m happy to announce that the Nelsonville Public Library has just put live a new web services module in Koha that supports all three of these services, and exposes the content in a new ‘Editions’ tab on the OPAC detail page for every record. Here’s a screenshot of what it looks like:

There’s even a nice set of system preferences to manage this new feature. They allow the library to turn the feature on/off, specify whether or not to use ThingISBN, and throttle the number of queries to the xISBN service, ensuring compliance to the terms of the free service (499 queries per day).

This new feature provides an excellent example of the power of web services for delivering enhancements to existing content, and building relationships that aren’t inherent in the data itself.

Over the past few years, since I wrote the original Amazon.com module for Koha, I’ve received literally hundreds of complaints, mostly from librarians, about the legality of Koha’s use of Amazon.com’s Web Services. In fact, it’s fair to say I’ve spent considerably more time responding to these questions than I did writing the original module.

So … first of all, shocking as it may seem, Koha has the capability to use Amazon.com content in the OPAC search results and detail pages. To see this in action, feel free to visit the Athens Public Library’s OPAC:

http://search.athenscounty.lib.oh.us

It’s perfectly legal to aggregate the content in web applications such as Koha. In fact, Amazon.com expressly created the web services program so that people would write applications around it. Their business angle is no different than any other content provider — they expect to make money. The difference is that they don’t want to make the money from the people aggregating the content. Instead, they are hoping that the content will drive users to the Amazon.com website and that those users will purchase something.

If you have hesitations about this business model and don’t think your library should be involved in it, no problem, you can simply turn it off in your Koha installation and purchase similar services from other content providers with more traditional compensation methods. The Koha community is not trying to force you to use Amazon.com.

However, if, like many of the libraries that LibLime supports, you are on a tight budget, yet want to provide your patrons with this content, Amazon.com’s alternative service model gives you that ability. Here’s how it works and why it’s legal.

Let me preface this by adding that I’ve had extensive conversations with Amazon.com’s US legal department about Koha’s use of Web Services, and they have confirmed that Koha does not violate the terms of their agreement. This point is worth making: they want your library to use their content :-).

First off, a bit of background on Amazon.com’s Web Services Program. The basic idea is that Amazon provides machine-readable access to content they have for sale. That content is indexed by ISBN number, which makes it trivial to identify a relationship between an item in a library catalog and an item on Amazon.com. Web Services data includes:

• Item Jacket Cover Images;
• Item reviews by Amazon.com patrons;
• Item ratings by Amazon.com patrons;
• Professionally written item descriptions and reviews.

Koha’s Amazon module can interact with Amazon.com’s web services program in several possible ways, in accordance with the license agreement that every Web Services user must abide by:

• Koha can be configured to periodically download content en masse and locally cache the content on one of your library services and serve it to your users via the OPAC;
• Koha can download the content in real-time as a search result set or detail page is loaded.

The Web Services agreement has very specific requirements about usage and discusses both of these methods in great detail. The most relevant points to this discussion are:

• if content is cached locally, it must be updated every 24 hours;
• if you download in real-time, you can only download up to 1000 items per IP address per day;
• if you download in real-time, you cannot download more than one item per second per IP address.
• if you use their content, you must provide a link back to any Amazon.com page

Since Koha’s system supports both caching and real-time downloads of the content, based on a library’s usage patterns, they would need to determine which method or combination of methods would work best for their situation. Keep in mind that images are downloaded from the user’s browser, not from the Koha application, so the 1000 queries per day per IP address and 1 download per second rules don’t apply to the Koha server(s).

If a library didn’t want to cache data locally, yet had more than 1000 views of their detail pages, it would be very trivial to simply track the number of times that Amazon.com content was syndicated, and turn it off after the day’s cap. It would be similarly trivial to keep track of the number of queries to detail pages per second and only permit one per second; or to use javascript to download the content from the browser rather than the server.

So the bottom line is that it’s not at all difficult to use Amazon’s program without abusing it. It’s up to each library to make an informed decision about whether and how to use it.