Olly olly oxen free: integrators with Koha, stand up and be counted
Does your project, service, or product interact with Koha in some automated fashion? If so, we’d like to hear from you.
I’m using the phrase “automated fashion” very broadly. There are many ways to receive data from a Koha system, update data in a Koha database, or make transactions happen. A few of these ways include:
- RESTful web service calls
- SIP2 to perform patron and circulation requests
- Z39.50, unAPI, and OpenSearch to retrieve catalog data
- LDAP to authenticate patrons
- MARC exports and imports
- Screen-scraping (although if you’re screen-scraping Koha, we may be able to suggest a better way to do it)
- Direct database access
- And others
Some of the things we’d like to know include:
- The name of your service or product
- What it does for a Koha library
- How it is accessing Koha
- Whether there are specific APIs or entry points that your application depends on
- If there are things that Koha could be doing to make your life easier
We want to hear from everybody, whether you are a library that has integrated Koha with other software, a Koha support group, a vendor providing products or services to libraries, or a member of a free software project whose software talks with Koha. If you work for a Koha library and know that Koha works with another service, we want to hear from you too, even if you don’t know how Koha is doing the talking.
Why do we want to know? Our reasons include:
- Finding out which entry points we should be particularly careful about changing as Koha gets enhanced.
- See if there are things we could be doing better to encourage more people and applications to participate in the Koha ecosystem.
- (Maybe) putting together a list of third-party services that interact with Koha.
To respond, please comment on this post.
it’s already known, but http://drupal.org/project/opac is something that makes heavy use of REST koha webservices that are available at http://git.biblibre.com/?p=koha-restful;a=summary
Hello Koha. Userful is a public computer vendor that has a few customers using Koha. We integrate with the SIP2 database in order to authenticate users onto the computers and verify their age / status / fines and so forth. Our product comes with a time limit manager, which keeps the library patrons from using more than their allotted time per day, so the integration with SIP2 plays a big part in that.
The University of Hartford has done a great job in constructing javascript and css to give the Koha OPAC a very slick look and some added functionality.
The problem is, it appears that this was all implemented with LibLime’s fork and their modifications to the OPAC, so in order to make the scripting work, some slight modifications are needed. For example, certain id tags or references produced by 3.8 and 3.10 do not match those in the UH scripts, so I had to re-write some code to get images to line up, or the css to cascade. I’ve also not had great success making their mapping scripts work, but I haven’t had enough time to experiment. I imagine at least these could be used as a template as well.
They also implement a mobile OPAC. Our library has no need for this, given our specialization, thus I have zero experience with it, but it looks interesting.
Their project is open source and details are at: http://libill.hartford.edu/koha/index.asp
One place that Koha could improve, from my limited experience is on the Authorities front. Now that authorities seem to be available over z39.50 from the Library of Congress, it would be very nice to build a module or service that could more easily manage the Authorities. For instance, while possible, merging authorities and updating associated records is a nightmare when you have a large database. Cleaning up the authorities would make the OPAC much more useful for our patrons, but I don’t have the time to spend doing it, and training staff in the less-than-clear procedure of doing so isn’t something I have time to do either.
News that the SCO will have some stylization and therefore customization is very welcome as well.
Given that both of these could easily be done by applications exterior to Koha proper, this might also be a place for development.
Hi Ian
Unfortunately the script is released under an incompatible license with GPL3+ which is what Koha is released under, from the source code
// Licenced under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License — http://creativecommons.org/licenses/by-nc-sa/3.0/
// Documentation available at http://libill.hartford.edu/koha/facelift^
CC-BY-SA-NC is not a compatible license, so we cant distribute this code with Koha, if they wanted to change the license to be CC-BY-SA then it would indeed be a free software compatible license and Koha users around the world could make use of it.
(The GPL says you can not restrict what the user uses the software for, -NC most certainly does that)
https://www.kuro5hin.org/story/2005/9/11/16331/0655 and http://freedomdefined.org/Licenses/NC#Incompatibility have some good reading on the subject
Im not a developer but I think a good idea is to make a user profile module to normalize permissions and get out of the permissions-specific-user schema.
One clarification: in asking for responses to “… are [there] things that Koha could be doing to make your life easier,” I’m not seeking general enhancement requests. I’m looking for feedback from folks who are currently integrating their software or services with Koha who may have thoughts about how Koha might make such integration easier.
I’m also the author of Libki, a FOSS kiosk management system that uses SIP2 to allow single sign-on between Koha and Libki.
Drupal opac module makes heavy use of ILS-DI too.
Works in progress with pazpar2 and mkdru will makes Drupal interacts with other koha systems using z39.50 or sru/srw.