Meeting Minutes for 04/24/2019

Marmot Union Cataloging Committee
Wednesday, April 24, 2019
Minutes

Announcements

• Aspen School District is leaving Marmot

Completed action items

Discussion Topics

• Discussion of Folio demo.

  • The duplicates committee watched a demonstration of the new Folio ILS cataloging module for their meeting this month.  Oliver from CCU also watched the demo.
  • Folio is a new open source ILS being developed by an international group of Universities.
  • There are very few, if any public libraries involved at this point.
  • We discuss the state of this new system.  It does not appear that it is ready for use.  We complained that it does not have the ability to view more than one MARC record at the same time.  So deduping would be very difficult.
  • It would be nice to have direct influence on the development of this new system, but right now it seems years away from being ready for a system of our complexity.
  • Lloyd points out that it does seem like a nice fit for us because we already have a software development team.
  • Oliver asks if we think we could actually handle a project of this size.
  • Lloyd says that the minimum requirement to participate is to devote a half time developer to work on the project.  We could do that. But we might need to devote more resources than that to actually get it developed into something useful for us in a reasonable amount of time.
  • Tammy points out that the Pika Team was reorganized into Software Development exactly so they could expand onto a project such as this.
  • Adam just sent out an email about Marmot helping to sponsor a meeting in Denver about Folio.
  • Jamie asks if Ebsco is involved with Folio somehow.
  • Lloyd explains that Folio started out as OLE, which was the library segment of what was to be an open source campus management system called Kuali.  A few years ago Ebsco decided to fund it and it became Folio. Ebsco does not appear to be dominating it, but it is not clear.

• MUG topic?

  • MUG will be organized around sessions put on by each of the committees again this year.
  • So the UCC is being asked to develop a session.  It could be a single speaker, or a panel, or lightning rounds, or anything we want.
  • Oliver says he is working on a large pruning project and he could talk about what he has learned from that process.
  • Tammy says that there may be spots open for more than one session if we have more ideas.
  • Jamie says they also implemented a large weeding project when they moved to a new building a few years ago.  There are probably others who also have weeding experience they could talk about. It could be a panel on weeding.
  • Someone asks for a session on how different libraries load records.
  • Lloyd suggests there could be a panel on different acquisitions processes.
  • Jamie likes the idea of a session covering best practices in acquisitions, or in Sierra in general.
  • Lloyd says he would like to learn how the new Sierra API works with vendors.  He will try to learn about that at IUG.
  • Maybe we could have a vendor come talk to us about how their system works with Sierra acquisitions.
  • Maybe Oliver’s pruning discussion or panel could be an academic library focused discussion that could be the MAC session.
  • Tammy wants a title and description set by the end of May.
  • We can continue this discussion on email.
  • Lloyd mentions that for personal reasons he may miss the May meeting so we may have to resolve this entirely on email.
  • Tammy mentions that one idea that came out of the focus groups was that there could be smaller single issue meetings, maybe regional meetings, in addition to MUG.
• How to identify large print titles in Sierra -- Bemis.
  • Bemis library is having a problem where their staff need to be able to find large print titles with Sierra, but without general material designations, that is difficult in Sierra.  Robin would like to see us add the GMD back for large print titles to make this easier.
  • Jamie asks if a single subfield can be protected.  So we could protect the subfield from being overlaid.
  • Lloyd says that you can’t protect a single subfield, but you might be able to protect the entire field only if it has a particular phrase, like “large print.”
  • Lloyd suggests that we might use a custom MAT TYPE field in the bib record.  That would create a facet for limiting in Sierra.
  • Nina asks how that would work with record loading because it would be overlaid.
  • Nina says that they use a different location for large print, and that allows them to use Create Lists to find things like this, but Robin says his staff wants to search with Catalog in the SDA, so being able to limit in Create Lists is not convenient.
  • Nina suggests using Pika for these searches, but Robin’s staff wants a search that also includes suppressed material.
  • We will continue to think about better solutions.  In the meantime, Bemis library can add GMDs to their records.  They may get deleted but nobody has objections to them being inserted.

• DVD grouping, redo

  • Running time will not work as a second match point for Pika grouping because there are too many films with similar running times.
  • Lloyd suggests we go back to looking at using names in the 700 field as a second match point.
  • We talk about the question of how many 700 matches you would need for grouping.
  • One match name is too few because that will create too many false matches, but you can’t require all the names to match.
  • Jamie mentions that the Primo discovery system also uses grouping.  It might be worthwhile to find out how they do it. *Action Item: Lloyd will check how Primo does grouping.
  • 710 is a problem to use because it is likely that the same company will make an original film and the remake.
  • Lloyd suggests a system where we would enter a code in a 9xx field that Pika could use for grouping.  This could replace Pika’s current manual grouping process which we believe does not allow an item to be regrouped after it has been manually ungrouped.
  • Nina suggests title, publication year and one 700 as match points.
  • Lloyd says that years are problematic.  You would want to use the production date in the 046|k.  Dates in the 008 are usually the date of the DVD publication, not film production.  Many records do not have an 046|k. [However, if it were a grouping match point, then you could add an 046|k to resolve a grouping problem rather than using manual grouping or ungrouping.  It could work similar to a 9xx code.]
  • Jamie says that a code in a 9xx field could be added with Create Lists.
  • Jolanda points out that this system could be used to fix the Spanish/English grouping problem.

[At this point we invite Pascal and Chris from Software Development into the meeting]

• We tell the SD people about the 9xx code idea and its advantage over Pika manual grouping and ungrouping because it would allow you to regroup something that has been manually ungrouped from something else.
• Pascal says that he has an idea to allow Pika to regroup things that were manually ungrouped.  If that works, then the 9xx code would not have an advantage. Pascal’s idea would also have the advantage that many things are already been manually ungrouped and we don’t want to have to recreate that work.
• The 9xx system would have the advantage that you could use Create Lists to add the code to a group of records.
• Chris asks about what code would you use in the 9xx?  How would you find the code you needed to add to one record to make it group with another record?  How would you keep track of these numbers?
• You would look in the record that already had the code and copy it to the new record.  If there was not already a group, then you would add the same number to both records.
• We could use a random string generator, but we would have to keep track of numbers used.
• We could use UUIDs.
• Chris suggests we could use the Pika grouping ID that already exists.
• What about manual errors?  Two people could create duplicate groups if they were working at the same time.
• Selene asks would this code be added by Marmot or by catalogers?
  • Lloyd thinks that catalogers could do this similar to the way they can manually group and ungroup now.  Marmot could also work on it as Tammy is now doing with manual grouping.
• Pascal will find the ticket that already exists for fixing the manual grouping system so he can evaluate if this idea is better.
• Pascal is also thinking that the 9xx tag could have two subfields, an unmerge subfield could have a code that says merge or don’t merge.  A second subfield would have a group ID.
• Chris asks what if you want to force your new item to join an existing group in Pika?  You could put the existing group ID in a 9xx field. That’s an advantage of using the existing Grouped Work ID.
• Pascal says that the Grouped Work ID is created by “hashing” the title, author, and category.  He suggests that we could create a 9xx field for the grouping author and another for the grouping title.  Then those could be filled in manually in the MARC record. If Pika found them in a record it would substitute them for the ones that Pika would otherwise create automatically.  That would have the effect of creating the same Grouped Work ID that Pika would create and cause that item to group. That would give us manual control, but allow the automatic process to work as well.  This would have the advantage that two people following the same rules could independently create the same Grouped Work ID without even being aware of the other record.
• Chris says you could just add the Grouped Work ID found in Pika.  Pascal’s idea does not require the cataloger to find the group they want to join, if they followed the same rules, it would get in the same group.
• Nina thinks that the grouping in Pika is working well enough that we don’t want to create another system.
• Nina says that Pika can already manually regroup things that have been manually ungrouped.  Bud frequently manually ungroups travel books and moves their item back into another group.
• Tammy says she’s done the same thing.
• Pascal says there’s a two-step process.  When you ungroup a record what happens is that record will generate its own new Grouped Work ID and apparently you can use that Grouped Work ID to attach it to a destination work.  There must be a bug in that process that explains why there have been reports that you can’t regroup these items.
• SD is planning a major overhaul of record grouping.  They hope to get to it this year. The issues are well documented.  They hope to work with grouping on the test servers over several months and work with catalogers to improve the automatic system.
• The current manual grouping and ungrouping lists can be used as test cases to check how the new system works.
• The Grouped Work IDs will change in the new version.  That will mean we lose all of our current manual grouping and ungrouping.
• Lloyd says that we still need to find a new automatic grouping system for movies.
• We move back to talking about using names in the 700 field for movie grouping.
• One name match is not enough to be sure of a match for a movie.
• Chris thinks using the 700s could work.  We will still have to use a manual system sometimes.
• Lloyd asks if you can require 2 names to match, but maybe not the same two names in each record?
• A cataloger could force a grouping by copying names from one record to another to get 2 names to match.
• Chris asks what records look like for TV shows.  How would cast changes effect this?
• Lloyd points out that there is also the problem of movies based on a TV shows.  Those could have the same actors and title.
• We look at the TV show 24.  Those have a season number in the title, so they would not group.  We don’t want different seasons grouped.
• Nina says there is more deduping to be done.
• What about director’s cut editions?  Do we group them?
• Pascal says they would be treated as a different edition, so they would be grouped, but have its own section in the display.
• Jamie asks if we can experiment with different options when we to the overhaul of the grouping system.
• Pascal says, yes there will be experimentation.
• Tammy points out that once we have this set, it should be explained in the cataloging standards.
• Pascal asks about the running time idea.  We only found one bad example. Maybe we should check if that is really a common problem.
• Lloyd says we could do a more thorough check of running times.  He could pull a list into openrefine to see if it is a broader problem. *Action Item
• The running time fixed field only has 3 characters, so it tops out at 999 minutes.  That is about 16 hours, so there are not many things that long, but there could be some.
• Jolanda asks if anyone has used the browser extension called Library Extension.  It does seem to work for EVLD. She wants to know if it works for others.
  • Lloyd has not heard of it.
  • Pascal says there have been reports that it does not work correctly with Pika, maybe because of grouped works.
  • Lloyd will check it out. *Action Item.

New Action Items

Ongoing Action Items

Duplicates Sub-committee meeting: May 8, 9-10 MT

Next UCC meeting: May 22, 9-11 am MT

Note: depending on personal circumstances Lloyd may be out of town on May 22, so it is possible that next month’s meeting will be canceled.