2017-04-07 - Consortia SIG Notes
Date
Attendees
- Tania Hewes
- Christopher Holly
- Charlotte Whitt
- Martina Tumulla
- David Dahl
- Filip Jakobsen
- Kirstin Kemner-Heek
Goals
For this week’s call, Hkaplanian would like us to consider the models listed in the notes from the last meeting as well as the 6 areas of responsibility that a consortia entity might have that we identified last week:
- Share collections
- Exposing collections for sharing
- Load Balancing
- Tracking floating collections / Inventory management
- Electronic Materials
- Cooperative retention or weeding – Who will retain what? And the policies to support this. (East Project using Green glass for this). Libraries can belong to multiple programs. No real ideal tools that integrate with existing systems.
- Buying Club - Large purchases for better pricing
- Sharing finance capability – Collection, Staff, systems, etc.
- Infrastructure & Support
- Sharing cataloging load, crowdsourcing KB management
And try to answer these questions:
- Which of the 4 models represent your consortium?
- What works well about your configuration?
- What challenges do you face because of your configuration?
- What is missing from your configuration?
- With what you know now, would you change to a different given model?
- Without the restrictions of the following models, how would an ideal system be structured for your consortium?
- What do you prefer to share?
- What needs to be separate per library?
- What levels of administrative control are necessary?
- What do you need to keep separate/independent in metadata records? Is this just a permissions/ownership issue?
- How do the 6 areas of responsibility listed above fit into this?
- How much of the workflows you use today are based on the capabilities/limitations of the software you use today?
- If you could start over, how should it work?
Discussion items
Time | Item | Who | Notes |
---|---|---|---|
Introductions | All |
| |
Which of the 4 models represent your consortium?
| David Dahl: Model #2 for USMAI. Using Aleph.
Former user (Deleted): Model #2 for FLO. Voyager.
Christopher Holly: Model #2 for CCS. SirsiDynix Symphony.
Sebastian Hammer and Charlotte Whitt worked with the Danish national library service that operates a shared ILS infrastructure with a shared catalog; all are required to be a part of it. Would often speak of trying to match Amazon's level of service (can see this title and have it in 'x' days; reducing the complexity of what appears to the patron). Biggest roadblock becomes access to patron information to enable instant decisions for resource sharing without violating privacy guidelines. Increasing interested in how FOLIO can support heterogeneous groups of libraries – linking them together in the common whole. Monoliths in this area become very complex. Christopher Holly: Something like #1 is good but can be expensive. Former user (Deleted): what is the bare minimum of patron information that needs to be shared; want to minimize the amount of patron information that is being shared. Sebastian Hammer: Is something like Shibboleth possible to make this happen? David Dahl: Something like shibboleth minimizes the amount of information that needs to be stored. Martina Tumulla: Libraries have their own local systems. Several different local systems at libraries. An issue - different types of libraries: 1. main library of an institution with several branches, but all branches "belonging" to this main library. 2. main library of an institution and several independent libraries in departments at the same institution. Libraries that are more independent than "branches"; their own staff and their own funds. Should not see each other's data; particularly fund hierarchy and balances. 3. Mixture of 1 and 2: main library with branches and independent libraries at the same institution Christopher Holly: a similar example is with law libraries and health center libraries and their relationships to the main libraries. Different operational units; think of them almost as different institutions. Kirstin Kemner-Heek: Noticed that questions are asked from the perspective of a buyers club and not from a network. All four models exist within GBV, and that is the challenge in their context – the system needs to support all of these models. One library system which is consistent in itself; two-track systems of libraries that are independent but organized; and mixtures of libraries working along and libraries that are collaborating in parts or in whole. Finding the right setup in the beginning is important because changing later can be challenging; don't have the flexibility to change later. The configuration of the system is more complex when a lot is shared; libraries have to align themselves in areas of budget structure, organizing supplier database, organizing request structure; how to print things; how offline jobs are organized. Because the system was not thought to be used in such a big way makes it challenging. Would appreciate a more strict structure of the data model; a big chance now to do it in a clean, well-structure, and efficient way while keeping the way to support different opportunities. (Carries a lot of load from the history of the system because there are so many side effects for changing pieces of the system.) | ||
Review of what we discussed. | Christopher Holly: A lot of discussions so far have been about resource sharing, but there are also concerns about buying club consortia (e.g. sharing cooperative purchase of content packages, for example).
Sebastian Hammer: Behind the politics and practices of individual libraries, is there an ideal that can be glimpsed? Exploring the ambition of an idealized vision of what we should be doing in each of these areas? Can we disentangle the politics and practices from the service goals of what we are striving to provide? | ||
For next meeting... | No meeting next week due to holidays. Next meeting will be April 21, 2017. |
Action items
- Christopher Holly: Try to share the process and outcomes from the CCS review.