Page Comparison

...

• Lloyd Chittenden
• Noah Brubaker
• Lucy Harrison
• Peter Sbrzesny
• Rose Nelson
• Charlotte Whitt
• Scott Garrison
• Peter Murray
• Rick Burke

Goals

• Draft vision document for an Open Source Bib Utility

...

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 thing in this 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.41 minutes  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 abou tin 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.  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 OCLC to this new model.  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 do

Discussion items

...