Meeting Minutes for 09/28/2022

Announcements

• Flatirons Library Consortium is joining Marmot
  • The six libraries of the Flatirons Consortium are joining Marmot
  • They are on their own Sierra server now and they will remain on that server
  • Marmot will run 2 instances of Sierra
  • One issue is we don't know what to name these new units
  • For now they are Marmot 1 and Marmot 2, but that doesn't seem satisfying
  • Flatirons Library Consortium will cease to exist 
  • They often go by FLC, but Marmot already has a member called FLC, so that name conflict would be a problem
  • We don't want to call the old members "Marmot" and the new members something else because the new members are full members of Marmot
• Sierra 5.5 is out
  • We will upgrade soon
  • We are on 5.1, so this will be a major upgrade
  • We have not been upgrading because of a bug in 5.3
  • The bug has been fixed in 5.5
  • Release notes were emailed to UCC group
  • We go over the changes we will get with the upgrade

Completed action items

Discussion Topics

• Flatirons joining Marmot, what to do about the catalog committee(s)?
  • Discussion of whether to have a separate catalog committee for the new Flatirons group, or if we should have a single cataloging discussion group.
  • Jo asks if having two groups would not be more work. If we are going to have the same rules why do we need two committee?
    • There are topics outside of cataloging rules that we discuss such as indexing on the different servers, acquisitions procedures.
  • Jamie points out that many of the things we discuss are unique to our server.
  • Nina asks if they will have their own Pika.
    • Yes they will use Pika, but have their own instance of Pika.
  • Nina asks what are the advantages and disadvantages of a single group.
    • Lloyd says the main advantage would be more cross communication between the groups
    • There would be better harmonization and synchronization.
    • Synchronizing the two systems would be easier on Marmot. It would be easier to document and support.
  • Nina suggests we try a single meeting and see how it works.
  • Tammy says that we usually document what Sierra does, not people's local processes, so maybe they won't be that different.
  • Tammy says they don't share documentation. They all maintain local documentation.
  • Jamie suggests we could put Flatirons topics at the end of the meeting, and people who don't want to participate in that discussion could leave.
  • Lloyd suggests a three part meeting. The first part could be MLN1 topics, the second part could be joint topics, and the third part could be MLN2 topics.
  • We could even have three completely separate meetings.
  • Cindy Young is for one committee because they could have ideas we can use.
  • Question, will their items be in our Pika catalogs?
    • No, the only resource sharing we will be doing is through prospector for now.
  • Kelly suggests we start with one committee and revisit the idea after we have tried it for a while.
    • We could actually revisit the idea later either way we start.
  • A single committee would help us feel more unified.
  • Suggestion of a load profile committee. Maybe we could have multiple topic centered joint committees.

• Should we implement the 790 field for local added author names?
  • Nina found an example of a situation where the author's authorized name is completely different from the name she uses on her books.
  • If this author's books are cataloged correctly you would use the authorized name from the authority record, but that is not what users would search on because it is not what she is known by professionally.
  • Nina's question is how can we catalog this correctly and make the name searchable.
  • This problem is what authority records are for. Authority records solve this problem, but Pika doesn't use them, so we need another solution.
  • Lloyd's suggestion is we could use the 790 field in bib records. We could put authors' additional names in 790 fields in bib records. This would have to be indexed in Pika and VuFind. 
  • It could be indexed in Sierra, but since Sierra does have authority records, it should not be a problem in Sierra now.
  • We could use additional 700 fields but that is overlaid by OCLC, so they could be lost. The 790 could be protected like the 590 is now.
  • Cindy likes the idea.
  • Kelly also likes the 790.
  • Jamie says that's really easy in VuFind, so it is probably easy in Pika too.
  • Nina's issue was that she can't tell if the author and the person on the authority record are the same person.
  • We look up the author's authority in OCLC. The name is J.M. Lee. There are two authority records for people with that name in OCLC. We figure out which one is correct. There is a See reference in the authority, but that will not have any effect in Pika.
  • Jamie suggests that we should have libraries that add 790 fields also add a 998 note to say which library added it.
  • Nina asks what people are doing with cutter numbers in a situation like this. Steamboat uses the last name for the cutter.
    • Lloyd says they should use "LEE" for the cutter. 
    • The cutter number is just a device to control where it goes on the shelf, and you should use it to put the book where you want it to go on the shelf, not follow the author name in the 100 field.
  • Lloyd will add this to the cataloging standards and make the proposal to have it indexed in Pika.

• Proposed updates to Cataloging Standards
  • PRE-STAMPS
  • Previously Marmot recommended putting a call number pre-stamp in subfield |d. Now we are recommending subfield |f. This is because the print templates system expects to find a pre-stamp in |f for printing on a spine label. Subfield |d is fine if you are not using print templates. The old spine label system ignores subfields. If you want to implement print templates for spine labels and have pre-stamps, you will need to global update them from subfield |d to |f.

• The committee approves these changes to the Marmot Cataloging Standards Document.

• Overdrive magazine list from CMU (excel file)
  • The records from Overdrive do not have ISSNs. CMU realized that ISSNs are required for these serials to be connected with A-Z list system that many libraries use.
  • So CMU has developed a list that can be uploaded to Gold Rush, or whatever A-Z product you are using so your A-Z list will be connected to your databases correctly.
  • It will also allow link resolvers to work as well.
  • Lloyd sends out a copy of the ISSN list to the UCC email group.so everyone has a copy.

• Problem with OCLC automatic holdings process
  • Jamie realized there is a serious problem with the OCLC holdings project some of our libraries just performed.
  • OCLC does not just set your holdings based on the number. They also do a comparison of your record and look for a better record for the same thing in OCLC. If they find a better record they move your holdings to the different record.
  • The problem is that some Marmots did not do the process and they will still be on the old record. If we change our records to the new number, those libraries will have wrong holdings and if we don't change them, then the library that did the project will have the wrong holdings.
  • CMU found a lot of these changes in the records they got back.
  • Jamie says the solution is fairly simple. He sent a new file of his OCLC numbers, not the whole records, just the numbers to OCLC and they reset his holdings.
  • He is also able to get new copies of his records easily with the new Collection Manager system from OCLC.
  • All the libraries who did the OCLC project need to redo the project. Jamie says it is not difficult.
  • Lloyd will get in touch with each of the libraries who did the project.

FOLIO Updates

• Marmot has postponed a FOLIO test server until 2023
• Morning Glory release is available
  • This is the second release of 2022
• Library of Congress is adopting FOLIO
  • They will use EBSCO hosting
  • They are giving EBSCO something like $10,000,000 for development.
  • LC is primarily interested in getting a system that can function natively in BIBFRAME.
  • Jamie asks if the LC code will be public
  • We don't know. That's always a big question with EBSCO.
• WOLFCON
  • Index Data is designing a module called Reservoir that would harvest records from multiple sources, dedupe them and export them to another external system.
    
    • Reservoir has been implemented by Ivy Plus
    • Will be the backbone of ReShare
    • Much more efficient than FOLIO currently
    • Currently bad data ingesting causes huge costs for cloud computing.
    • Does not export back to FOLIO
• Data Import
  • In Orchid, 2023R1, we will be able to load multiple holding on a single instance and multiple items on a single holding. It is not determined how that will work.
  • Working on EDIFACT invoice loading
• App Interaction
  • How to deal with column sorting in tables
• Metadata Management
  • New Entity management group
    • This is authority control, but it's hoping to use linked data.
  • Link to authority record based on $0
    • No floating subfields will be linked. System will assume there is only a single $0 in each field and only link when the whole field is authorized as a unit.
• QuickMARC
  • Discussion of editing LDR in bibs

Ongoing Action Items