Introduction
Catalyst and Bywater Solutions are both vendors for Koha library management system. We have worked together in the Koha community for 8 years. Both companies support a number of academic libraries (universities, polytechnics, TAFEs, colleges) and are investigating how FOLIO can be of benefit to our customers, with an initial focus on academic libraries.
This paper will explain how Koha and FOLIO can work together to benefit libraries. It will also set out specifications for some ways Koha could connect to FOLIO, and therefore enhance library services.
Background
Koha Integrated Library Management System is the most popular open source software solution for library management. Originally developed in New Zealand in 1999, it is now used in over 15,000 libraries around the world. Over 300 people have now contributed as developers to the project which continues to grow in popularity. Openhub describes the project as having a well established, mature codebase maintained by a very large development team. The average Koha release includes contributions to the code from around 80 individuals.
The Koha project supports a growing number of API connectors and standards in order to interoperate with other library services. The Koha project already offers support for several systems libraries need to interoperate with, but there is always more that can be done. Library system users don’t expect to have to log into – or even look at – multiple interfaces or products any more. Libraries need to deliver on this expectation for their users, so Koha needs to deliver this functionality for libraries.
The potential gains of such fully integrated systems are significant. Library users and staff switching between software packages, electronic databases, and library management systems would be a thing of the past, with users enjoying the benefits of truly joined-up services and one single sign on to provide all the services that they need.
However, linking up the many and varied library systems, in the wide variety of library settings in which Koha is used, is a goal not without its challenges.
At its most basic level, the building of connectors for each piece of software for which libraries would like to see an integrated path with Koha requires a lot of work for developers to write, and for the Koha project to test, release and maintain. With different focuses and systems to integrate with, the efforts of individual institutions can easily be scattered leaving libraries working in silos without enough funding or people to support the end goal. Using open source software like Koha brings the freedom to achieve any goal where contributors have the skills and desire to do so, but these efforts can be more effective if everyone works together.
Further complicating matters, Koha is open source software but many of the other systems used for learning management – ePortfolios, financial systems and the like – are not. This means to connect them, buy-in and willingness to collaborate is needed from all the different providers of proprietary software. On top of a willingness to help, providers also need to contribute their time and money to a project unlikely to positively influence their bottom line.
So when we heard there might be a way for libraries and vendors to work together with a focus on integrating their digital systems, we wanted to know more. Enter FOLIO.
FOLIO is another open source project, started by content provider EBSCO Information Services, and with a growing community. FOLIO reduces the number of connectors required for creating joined up, integrated systems. Instead of the different systems requiring a multitude of separate connections to each other, each system simply connects to FOLIO. It still requires time and effort to build, but we can see some significant benefits to working with FOLIO in this way, particularly for academic libraries who need a way to interoperate with the wider context of support and services provided for students.
With FOLIO being Apache v2 licensed open source and protected by the Open Library Foundation, we know we we can make changes to it if we need to, which becomes important if the requirement is urgent, or another proprietary system has changed and we are have to work around it. We also know that with FOLIO, libraries are safe from the problem of software or a company being unsupported or sold off and becoming inaccessible, and we are also free to swap in and out the various systems that connect with FOLIO if they change.
How?
FOLIO can be thought of as being a layered platform, with four distinct layers. At the bottom, the foundation is the System layer, this is where data is stored, indexed and logged. Built on top of this layer is the Message layer. The FOLIO project call this layer OKAPI, this can be thought of as the API gateway, or “bus”, with well defined structures for tenant context, permissions, authentication, and system APIs. This part of the project is the bit that really interests Koha developers. The OKAPI layer is what we would interact with to interoperate with other connected applications. Libraries can instruct the developer of any application to integrate and with and maintain connection with the OKAPI layer. The next layer is the application layer, this could be micro service level (e.g. a holds app) up to full application level (e.g. Koha). Finally there is the User Interface toolkit, which would be used by developers building new applications more than those connecting existing ones.
Librarians in Special Interest Groups (SIG) are currently detailing the features and integrations they would like to see in FOLIO. Design and development for several core workflow related apps is underway. Additionally, fund grants have been made available (from organizations such as EBSCO) to encourage development of innovative apps on the FOLIO platform. Leveraging these funds can attract Koha developers to connect Koha, FOLIO, and other library environments.
Specifications
Following are some specifications for three ways that Koha could integrate with FOLIO, either by influencing the direction of FOLIO now, or contracting other developers to work on FOLIO after the production release next year.
Idea 1: Koha + Moodle via FOLIO
Most academic institutions will have both a library system and a learning management system. It would be great if these systems could talk to each other.
Imagine if you, a student, could place holds on items on your course reading without leaving the learning management system. If you write a review of a piece of literature in the learning management system, that could be added as a review on the bibliographic record in the library system. Koha and Moodle are arguably the two leading open source solutions for library management and learning management systems, so linking them together makes sense.
Taking just the holds example, the potential development or patch would be to make a Koha app (or apps) at the FOLIO app level. This would act as a translator app, working with the Koha Restful API on one side, and the OKAPI API on the other. To support holds, it would also need to talk to the holds API(s) in Koha.
Those API would potentially be:
/users/
To look up the user details.
/circulation/holds/
To look up the usage details for the item to be placed on hold.
The workflow for placing a hold is, get the information about the user, get the information about the object, check a hold can be placed, place a hold.
GET /users/search/{email} would return a user matching the email
GET /users/{user_id} would return a user matching the id
POST /circulation/holds/place/{user_id}/{biblio_id} would return a hold id on success would return an error message on failure
The Koha holds app would accept messages from the OKAPI layer, parse them, call the appropriate Koha API and format the response to be handed back to the OKAPI layer.
Koha -> | FOLIO Koha Hold App -> Okapi -> Moodle App | -> Moodle
And back the other way. A Moodle app would also need to be created to execute this on the Moodle side.
The above example potentially provides a framework for thinking about how the FOLIO OKAPI layer can connect to a variety of other systems or resources.
Idea 2: Course Reserves App
Another potential development is a course reserves app. This could use the FOLIO user interface layer also.
This would form the basis of a collection of materials in Koha (class, material, course informations) harvested and displayed in app UI for FOLIO – while also adding in materials from electronic materials that are connected to FOLIO (discovery materials, ERM – anything stored in the FOLIO metadata collection).
The required API would potentially be:
GET /courses (Get ALL courses)
GET /courses/{course_id} (Get one course)
GET /courses/{course_id}/items (Given a course_id, get ALL the items)
GET /courses/{course_id}/items/{item_id} (Given a course_id, get the item identified by item_id)
PUT /courses/{course_id} (Update information of the identified course – This will be useful to ‘disable’ course) PUT /courses/{course_id}/course_item/{item_id} (Update an item in an identified course)
POST /courses/ (New Courses with all infos) POST /courses/{course_id}/course_reserve/ (New reserves is added to course)
DELETE /courses/{course_id} DELETE /courses/{course_id}/item/{item_id}
Idea 3: Institution-wide reports
Koha allows full read access to the database for staff users, so it has a very powerful reporting engine, and any report that can be written can also be output as JSON, visualised, and marked public or private. We would not want to replace this reporting engine, but we might want to combine reports with reports from other applications used in the institution. It makes a lot of sense to use FOLIO to do this when multiple applications are connected.
The API we would need on the Koha side would be as follows:
GET /reports (GET all the reports) GET /reports/{reports_id}
PUT /reports/{reports_id}
POST /reports
DELETE /reports/{reports_id}
When?
Koha has never worked in the way proprietary and even some open source projects work – we don’t try to build features and sell them. Every feature is built because a library has asked for it. So, timeframes for producing new features are a lot more flexible, and rely on libraries asking for what they need. FOLIO integration will be done when a library (or libraries) asks for it to be done. We would expect that to happen in the next year or two.
Conclusion
We hope that this paper provides libraries with some ideas for how Koha could work, with FOLIO as the connecting point for a range of integrated systems for libraries and the wider institution or community they serve. Perhaps some libraries will be inspired to look into FOLIO, and ask for certain connections or functions to be built to meet current or future requirements.
Using FOLIO with Koha and other applications still requires effort. We all know that the modern library user is so much more than someone who borrows books, and the expected user experience of a library customer is changing fast. Using FOLIO allows libraries to focus on one place for software to interoperate, so they can offer users more scope to interact with library collections, and reaching into systems provided by the wider institution.
If we have a strong base of libraries using FOLIO for integration, we can put more time into focusing on the user experience, and face less reinventions of the wheel, less custom work to do, with clearer pathways for how we can work together. This would be great news for everyone.
Published October 2017.
This paper can be downloaded as PDF.
About Catalyst IT
We’re the open source experts. The company was founded in 1997 on the belief that free and open source software provides the best solutions for clients. The five founding directors are still as committed to the business (and open source) as ever, and the company is now busy helping clients all over the world to solve business problems the open source way. Koha is a key part of Catalyst’s business and we’re excited to see more and more libraries reap the benefits of using the system.
About Chris Cormack
Chris Cormack, Kāi Tahu, KātiKātKāt e, has a BSc in Computer Science and a BA in Mathematics and Māori Studies from Massey University.
Chris was the lead developer on the original of Koha, produced by Katipo Communications for the Horowhenua Library Trust in 2000. Chris has remained active in the Koha community and is a key figure in the Koha team at Catalyst.
About Bywater Solutions
ByWater Solutions is a company of librarians supporting a product that was created for librarians – Koha Library Management System. The company was founded in 2009 by Brendan A. Gallagher and Nathan A. Curulla, and has grown to support over 1000 libraries worldwide since then.
About Brendan A. Gallagher
Brendan A. Gallagher, MLS Librarian, is an expert on installation, data migration, and customisation of many open source platforms. Brendan was a member of the first class of ALA Emerging Leaders where he focused on ways those in the library profession could re-brand themselves in the digital world. He was honoured as Alumni of the Year for the Southern Connecticut State University in 2011.
