Link to recording

Date

06 Nov 2020

Announcements

Attendees

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: 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: 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: the SIG has started a vision document, and that could be filled out to go to the steering committee.

Scott: we need to think about how this could be resourced.

Jill: 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: 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: 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: 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: 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: 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: 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: 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: Record matching is important to GALILEO too. She says they have many libraries that will never have any interest in being on FOLIO.

Lloyd: 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 thing in the 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 that sorts through the results quickly. The advantage of that system is that they provide you access to records that they can't sell for copyright reasons. All they are doing is creating the interface that allows you to make a copy. They are not making a copy, so they don't have a copyright problem. If we harvest records in to a central database and make them available, we are going to have to have mechanisms to avoid pulling in records we don't have rights to copy.

Jill: the model you describe is the same as the OCLC Relay product is built on. It's a Z39.50 search that creates a shared view of what's available for lending. Actually Index Data built out some of that functionality. That is a way of doing it. It's slow, and we would like to get away from that with a shared index. We want to be able to use it for other purposes and that is difficult if you are just looking at a view. PALCI is using that now.

Lloyd: I have seen Z39.50 before, but usually that is just a big dump of records that you have to sort through. The advantage of BTCat is it identifies quality records for you.

Noah: At Indiana we have Autographics and it does not identify quality records, so it is not great. Lucy, if our group can focus on those user requirement, that is the best thing to do at this point. How things work is not as important right now as the needs and use cases. For us our institutions are very small but they have instances where they need to do original cataloging, or they are relying on OCLC. My concern would be that not having access to obscure records could increase the need to do original cataloging, unless there was a very good way to do that. The other scenario in in the resource sharing realm, depending on how record matching works, is it efficient enough that you can easily move from your own group, to a larger group to OCLC if you need to. To make sure that process is not difficult searching many different systems with different search functionality.

Jill: I think in terms of that second question we are using the Gold Rush algorithm. When that comes back you can expand and see what's underneath all of that. I don't know how that would work to scale back into smaller indexes. One thing we have talked about in ReShare is managing requests in and out of ReShare as well so that things can flow between various systems using ISO18626 or whatever protocols. That is part of the goal is to create a request that can easily flow to another system if it needs to . We don't what to contain something within this environment. We want to be able to work with other partners as well.

Rick: I have a different thought. Clearly those of you from the FOLIO side are more technically savvy about the details of this. What I'm thinking about in the context of ICOLC is, what is our greater strategy here? I need to talk to Jill and Lucy more about this. I'd like to get a better understanding of how ReShare is funding it's operations so far and what resources it needs. We clearly have the technical expertise amongst this community to do this. What we don't have is a really solid strategic plan to raise the money to do this right. And then swing the library's opinion over from using something like OCLC to this new model. We could have these calls and discuss these technical details, but maybe we could have a second tanget. We are talking about merging this with ReShare, but it seems bigger that that. One of the things I would like to take to the ICOLC coordinating committee is what is ICOLC's role in this and how far do we want to go? To be Don Quixote and tilt at the OCLC windmill by making some prononcement might not be so productive, versus in the background amassing some resources to back this up and tapping all the resources that we know to do that. So I would suggest that if we continue to have these conversations that we have a topic that keeps a focus on the big strategy. I have no doubt that we could pull this off, but do we have the resources to build this on top of all the other work that needs to be done for these projects? We have big ideas, and that will take big money.

Noah: I think I remember a while back when we had Sebastian on a call, he suggested that this could be a parallel project to ReShare, rather than trying to fit it into ReShare's priority list. There could be enough interest that it could warrent it's own track. It could mirror the structure and organization, but have it's own pathway to follow.

Lloyd: Does that mean it would be a separate OLF project?

Noah: maybe something like that.

Lucy: I agree with all of that, but I think the first thing we need before we have any of those conversations is a better understanding of the vision we are trying to accomplish here. If the vision is for one one hand a way for folio or reshare libraries to have a plac eto go to look for records that reduces their dependence on OCLC that's fantasitic. If the vision is to have something that's good enough that we don't need OCLC at all any more, that's a different vision. And we're talking about a system where you will use OCLC as a last resort, then you still have to pay for OCLC. So, my vision for this is to get to a point where, at some point you want to have a product that is robust enough that we don't need OCLC at all. Either the record is in there, or someone within the collective will catalog it.

Jill: One of the things that reshare did early on which might be a model here was work with the Big Ten and the write paper they wrote about their vision for resource sharing. They built around that shared vision that people could buy into and invest into. Once that is solid enough that people coule invest in it, that's where you start to be able to build unique partnerships. The model that we had with reshare early on was athat the people who invested time and money into it were going to turn around and buy services from the people developing them. And there was a promise of some potential revune that they could recoup fr that investment. That model worked because we all bought into a vision and we didn't actually need to see the thing before we paid into it. But I've had so many peole tell me that there's a there there. Well there's not going to be a there unless we co-invest in a vision that we can all beleave in. I agree with Lucy that we have to built the vision in a way that is understandable and people can see the benefit. Also, what is the alternative if we don't do this. That story is really important for us to tell.

Lucy: Once we have that I am all in. I'm not saying ICOLC shouldn't have any imput into it, they should ahv input in the the vision. The point at which ICOLC has to make a decision about what are we going to say about this as an organization comes once the vision is developed. After we know waht we are endorsing.

Rick: I agree, Lucy, I want to get to the point of having htat strategic discussion. If we can go forward with some action items about what we want to do. Part of the problem is that the OCLC task force report ahsn't been fully released to the rest of ICOLC to asses what they think about it. ICOLC is an informal association, it's not a governing body anyway, buy the statements that ICOLC has mad in the past have had invludence. Ift ehre's a way we can do that, that would be value that ICOLC can brin goto this.

Lucy: If this group fleshes out the initial user stories, a bit further. Have an initial conversation with ReShare, so that at least we have a guiding high level vision. I big goal we want to accomplish. I think I am perfectly happy to wait on the release of any further communication with the ICOLC OCLC task force until we have that. Then it seems like a pivot to presenting the new project that people can help shape and guide forward. Maybe that 's the point where ICOLC endorses. I don't think it's too much more work to get to the oint where we can have a conversation with ReShare.

Scott: To Rick's point, I would love to see ICOLC marshal actual resources toward this. We have many consortia in many places that could bring resources.

Rick: That's what I was getting at. It's just a

Lucy: I have a statement already in the document that says if we spent 1% of our annual bills with OCLC and spent it on this project we would more than be able to fund it. But are we ready to say that now? No. We need to have the vision for what the project is. We are losing that call to action if we say that too soon.

Charlotte: I think that some how the timing is good, because ReShare has

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

Browser not supported