Elag integrating open source
•Download as PPTX, PDF•
0 likes•1,405 views
This document summarizes Stockholm University Library's efforts to integrate open source library systems. It discusses the library's existing LIBRIS system and describes two open source systems - Koha and Viola - that the library is implementing. Viola is used for interlibrary loans and circulation functions. Koha is used as the local catalog and is being integrated with LIBRIS using protocols like OAI-PMH. The library is developing a new service layer architecture to facilitate connections between these systems and provide additional services like a link resolver and ERM system. Moving forward, the document discusses whether the library's open source components should be packaged together for broader collaboration or separated for more use cases.
Recommended
Recommended
More Related Content
What's hot
What's hot (11)
Viewers also liked
Viewers also liked (18)
Similar to Elag integrating open source
Similar to Elag integrating open source (20)
Recently uploaded
Recently uploaded (20)
Elag integrating open source
- 1. 2015-06-11 /Namn Namn, Institution eller liknande Integrating Open Source Library Systems Theodor Tolstoy Andreas Hedström Mace Stockholm University Library
- 2. 2015-06-11 / Namn Namn, Institution eller liknande
- 3. LIBRIS VIOLA KOHA Union catalogue SFX EDS libERM Link resolver Discovery Service Printed materials Electronic resources Information supply systems
- 5. (L)OPAC LIBRIS WEB SEARCH LIBRIS CATALOGUE BIBLIOGRAPHIC RECORDS HOLDINGS RECORDS HOLDINGS RECORDS BIBLIOGRAPHIC RECORDS ITEMS The (SUL) workflow in LIBRIS: LOCAL CATALOGUE ”Cultivating”
- 6. The Library Happens Elsewhere Focus on Delivery not Discovery
- 8. Enter: Viola
- 9. Background: • Old ILL & book logistics system discontinued • Complete rewrite based on existing, well estblished, work flows
- 10. Stack fetching Faculty Office Delivery Viola Outgoing Stack call Ill Request Ill Request Missing books National Ill system
- 11. Interlibrary loans Interlibrary Loan Requests Purchase requests National Ill Requests Viola Incoming Invoicing Circulation National Ill system
- 12. Proven usefulness - outside of Stockholm ● Linnaeus University live with Viola since march ● Hosted in Azure, cost approx. ≈1200€ per year ● Similar workflows, same ILS
- 13. Current development ● More robust & easier to maintain – State Machine, better error handling – Consolidation of business logic ● More generic and open – More configuration – More pluggable architechture ● Azure enabled – Easy to try, deploy & maintain
- 14. Enter: Koha
- 15. Project areas: Data quality Educate staff Workflows Technology/ development Co-operation & communication
- 16. Development Holdings & locations Metadata & data quality System interaction Usability Technology & service Project team Project structure:
- 17. Koha (dis-)abilities Supports plenty of workflows Robust functionality But, no functions for: Handling orders (call slips) Generating automatic invoices etc.
- 18. OAI-PMH ILS-DI svc/ HTTP API SIP2 REPORTS WEB SERVICE Koha interoperability Endpoints: REST API (Soon)
- 20. The big picture
- 21. The LIBRIS connection Project goals: • Adding items to the LIBRIS XL infrastructure • Synchronization between LIBRIS and local systems (OAI-PMH, REST API)
- 22. 2015-06-11 /Namn Namn, Institution eller liknande Towards a new architecture
- 23. Stack fetching Faculty Office Delivery Viola Outgoing Stack call Ill Request Ill Request Invoicing Missing books National Ill system
- 24. Order flow today Interlibrary Loan Requests Purchase requests National Ill Requests Viola Incoming Invoicing Circulation National Ill systemViola Voyager OPAC LIBRIS
- 25. Koha ViolaOPACLIBRIS Order flow tomorrow Interlibrary Loan Requests Purchase requests National Ill Requests Viola Incoming Invoicing Circulation National Ill system Service layer
- 26. Service layer In order to ● Keep Koha simple ● keep Viola versatile ● keep the OPAC lightweight ● Enable more services: – ERM – Link resolver – ... Koha Viola OPAC LIBRIS Service Layer
- 27. The way forward Packaging for collaboration or splitting it up for more use cases?
- 28. The way(s) forward Cooperation Cooperation Viola Koha Service layer Code reuse Stack Fetching
- 29. Questions! Resources on Viola: http://tinyurl.com/viola-elag
Editor's Notes
- Introduction to the work at SUL. Two major processes: Information supply & Publishing support.
- Simplified overview of Informations supply.
- How we work in LIBRIS: Catalogue in LIBRIS, push down to local system –add items. Information sent to web search interface.
- A key strategic decision. Move from working with own search interfaces to focus on delivery. One important result: seperating of flows for print and electronic. Example: our Discovery system does not have printed materials (catalogue). [Rick James]
- Historically we have worked at lot with our OPAC, but we will now move to use LIBRIS as our OPAC (LOPAC). Systems come and go: we are used to working with systems, have knowledge and experience. No fear!
- Talked about the stack fetching part last year
- The stack fetching part of Viola
- Only integrates with LIBRIS Interlibrary Loan system
- Went from two servers to four different containers including solr A few tweaks
- Less resposibility in the GUI Work will end in september.
- Koha introduction. Open source ILS originally created in New Zealand. Code base in Perl. Our old ILS was getting old, and won’t be developed further – need for a new system. Spent a year researching and testing (test migration with BibLibre). Important: we were only looking for a circulation system/module, not complete ILS (connection to earlier strategic decision).
- Decision to use Koha in December 2014. One year process of implementing. Goal to go live at the end of the year. Discuss current project areas.
- Project to big to be handled by only the project team: working groups established. All groups have member from the project group, who are responsible for their activity and providing the project team with information/feedback from the groups. Goals: more focus on one aspect of the process, and getting the staff involved. Very important! Also, not shown in the image, there are reference groups working on things like loan policy etc.
- Koha has several advantages, but also some drawbacks. The biggest concern for us is that some functionality that we would need is missing: handling orders first and foremost, but also a number of smaller issues. Many of these can be handled by Viola or other systems.
- The need for Koha to be able to communicate and work with other systems. There are a several endpoints that can be used, and our evaluation is that more or less everything we need is in place today. However, the need to have one stable and well-documented API: there is ongoing work with incorporating a REST API for Koha.
- We will be working with the Koha community: no forking! All development should be in the community Koha or not at all.
- Now that we have gone more in depth into the involved systems, it is time to zoom out again and look at the bigger picture on how to tie everyting together.
- First of is the LIBRIS connection. How it will communicate with our local systems. We have an onging project with LIBRIS, where goals are to add items to the LXL infrastructure so all cataloging can be done in LIBRIS and then pushed down to Koha for circulation. The synchronization between LIBRIS and local systems then becomes a key issue. We have only begun looking at this but the plan is to use OAI-PMH and LXL:s REST API for this. Koha is Marc based today, so this will have to be accounted for (LXL converts to Marc). Work is being done to implement ElasticSearch into Koha – the hope is that this will help with breaking down its Marc dependancy – but in the long term.
- Ska göras om lite, men den finns här för att visa vilka beställningar som flödar i nästa bild
- Problems replacing Voyager for Koha: While having quite extensive API support, which was our initial fear, Limited functionality in terms of holds, order types and statuses is the missing part here. Other options: Increasing OPAC responsibility is perhaps tempting but not a good long term solution Switching Viola and ILS
- Introducing a Service layer with the purpose of holding much of the business logic