Link to recording
- Date
Announcements
Attendees
- Lloyd Chittenden
- Noah Brubaker
- Lucy Harrison
- Peter Sbrzesny
- Rose Nelson
- Charlotte Whitt
- Scott Garrison
- Peter Murray
Goals
- Draft vision document for an Open Source Bib Utility
Notes
Lloyd will type up notes from the previous meeting. He was planning to do that before this meeting but has not had time.
Lucy says the ICOLC task force will meet next Friday to decide what to do with the report.
Sebastian is out today, but we have Charlotte Witt.
Before we started these meetings with ICOLC the SIG was starting to develop a proposal to bring to ReShare, but we don't know what the process should be now.
Jill says we should clearly define what we want from such a project, and bring that to a ReShare steering committee meeting. The steering committee can take that to figure out how that can fit in to the ReShare project.
Lucy points out that the SIG has started a vision document, and that could be filled out to go to the steering committee.
Scott says that we need to think about how this could be resourced.
Jill says the steering committee meets once a week on Mondays at Noon. It would be easy to add this to the agenda once we are ready with the vision. They are currently talking about how to build membership and revenue.
Lloyd says that the SIG has not firmed up what the product would be, but that is good because ReShare can still help shape it. We don't know enough about ReShare to say much about how it would work technically in that context.
Lloyd posts the vision document.
Lucy says we don't need the conceptual diagram for the Steering committee. They will want to do that because it will need to work in the ReShare context. We need the user stories and some basics of the functional requirements. Organizational governance can be figured out later. The user stories are what we need to nail down first.
Jill says what the steering committee would want to do is take representatives of the SIG and representatives from ReShare to work on building the rest of this out together.
Lloyd says the user stories would be fairly easy to flesh out. The main point of uncertainty that we had was the basic structural question of whether people wanted a system where the user is maintaining their records in a central system, or the user is maintaining records in their own system which is interacting with a central system.
Jill says that currently ReShare is build on the second option because it needs to work with many different systems. It gives members of a consortium the flexibility to make their own local choices. Then they can iron out what's needed in a shared inventory in ReShare. She thinks that would be esier, since that is already what ReShare is doing. It would be preferable to something like Alma Resource Sharing where everyone is working in a central system. It is not compatible with other systems.
Lloyd says that makes sense. We have been thinking that since we are the FOLIO SIG we will all be on FOLIO, but that's not what ReShare is thinking.
Scott points out that MCLS and Marmot are multi-type. In that context record matching is really important. If this system had really robust record matching, that would be really useful.
Lucy says record matching is important to GALILEO too. She says they have many libraries that will never have any interest in being on FOLIO.
Lloyd says that we have been thinking we could borrow the matching system from Gold Rush where you pull from all the relevant fields to build one giant field that is used as a matching key. This allows you to match based on which ever fields you choose. This has been thought through by Gold Rush.
Scott says that GR record matching is a good start, but INN-Reach is already better.
Noah: Another topic we didn't conclude was that ReShare is set up with pools of libraries. If you are in a pool with a major institution you will have a good pool. But if you have smaller groups, they would have a limited benefit if they can't reach across to other groups. They would need to be connected. How would record de-duplication happen if you are connecting to records outside of your own instance.
Jill: one thing reshare has worked on is the concept of multiple consortia within a larger consortia. they aren't yet set up to bring multiple indexes together.
Peter: I'll just add that I think reshare is developing as a great example of how the overarching view that sebastian has in teh bib network of sindication of records and harvesters of records. That capability is not in reshare code, but it does not exclude that posibility from happening. One could envision that with the right about of resources we could get away from the hub and spoke system to a peer to peer record shareing system. Particularly at the consortial level.
Lloyd: What reshare does create a shared index for a group of libraries. How is it getting those reocrds? Is it not harveting them?
Peter: Now it is harvesting them from teh libraryies and putting them into a central catalog, what is not in reshare is the notion of publishing that set of records and subscribing in a syndication kind of way to those records where you might aggregate records at a higher lever and or disperse records down to other segments of the community. So yes, the ability to get records from a local system to a central catalog is there no matter what that local system is. Next we need to take those kind of things to the next step is to build the peices that do the syndication in and out of those central catalogs.
Charlotte: The developer, nelson has developed the module inventory update. You do a load and you can get the updates. Those pieces are being build already.
Jill: To some extent there's some pushing our of data through vufind now for discovery. We are looking at being able to takes what's in that central inventory and be able to push it out for discovery purposes.
Lloyd: So, when you create a central searching system for a central database, you are using vufind for discovery?
Jill: Yes, we are using VuFind for discover. We are also working on the integrations of discovery with other discovery providers like EDS or Primo.
Lloyd: I wonder about this. You are pulling records from libraries that are part of your system, but if we were doing a bibliographic utility we are going to want to pull records from other open sources like Library of Congress that are not part of our group. Would that be a difficulty?
Peter: I think that would be a source of the peer to peer syndication that has been talked about:
Jill: We've talked about bringing together records from many different sources. We haven't been thinking about creating one giant index but bringing these different indexes together in a shared environment. Technically, I don't think it's an issue. We got excited about the idea of being able to cover 99 percent of what people need by bringing different peices together rather than relying on a single shared index that people have to load their stuff into. Just let them do their thing and merge them together afterword. That is very exciting. Right now long tail stuff is so dependant on OCLC. If you have a good group set up then you are good, but if not are are at the mercy of OCLC
Peter: the overlapping circles speaks to the linked data world we are trying to get to as well. Where there are statements of entities being published and in order to make our catalogues work we want to cashe what other's have said about entities and use them in our own catalogs. There's some conceptual work that needs to be done to get from where we are now to an entity based model, but there is the kind of publish and sindicate model is a way to get to that. It would bridge those worlds.
Charlotte: Here the development in FOLIO might be helpful There is the entities management group in FOLIO. This is mentioned in this working group. This work is mentioned in their vision and strategie paper. It is on the road map for 23-25. FOLIO might be helpful.
Lloyd: I just had an off the wall thought. I saw a demo of the new BTCat product from Baker and Taylor. This is another think in this bib utility market. I realized that you can access the BT records, but mostly you are doing Z39.50 searching. They create a bib utility on the fly. There is no central thing. Every time you do a search it creates something on the fly.
41 minutes
Discussion items
| Time | Item | Who | Notes |
|---|---|---|---|
| Draft Vision Document | https://docs.google.com/document/d/14sqECAp87ZMpNeGP6Qxd4tIes4YUQ3SzxnLUWN9sCD0/edit?usp=sharing | ||
Action items
- Invite Theodor Tolstoy to next meeting Lloyd Chittenden
- Invite Kristin Wilson Lloyd Chittenden