Meeting Minutes for 09/26/2018

Marmot Union Cataloging Committee
Wednesday, September 26, 2018
Minutes in blue

Announcements

• Possible change to Marcive process
  • Marcive has eliminated the bulk discount that we have been taking advantage of.  We have been waiting until we gathered 50,000 records before sending those in. That happened approximately quarterly.  Without this discount, there is no advantage to sending records more frequently.
  • *Lloyd will look into how this process might work.  We may send new records weekly or even nightly if we can figure out how to automate it completely.

Completed action items

Discussion Topics

• Ashley to discuss indexing of 020 in Pika
  • Pika does not currently index the 020|z.  It was set up this way because MARC format defines the 020|z as used for invalid numbers.  However, the field has come to be used for other purposes.
  • It has come to be used for ISBNs of related manifestations of the described text, such as the ebook or audiobook version of a paper book, or vice versa.
  • Pika selects a primary ISBN for grouped works.  That is the number it uses to query for cover art.
  • Ashley says that the Pika Team thinks that the 020|z does not need to be indexed because the general user won’t be interested in searching it.  It can be searched in Sierra and Classic, so staff users have the ability to search it there.
  • Amy Currier chats that CMC students would benefit from searching by 020|z in Pika.  Students will not be able to search Sierra. She thought Pika was already operating that way.
  • Perhaps Pika record grouping overcomes this limitation?
  • Amy points out that her students often search for textbooks by ISBN, and those are frequently not grouped.  However that is exactly when they want to be able to find all versions and are likely to search on ISBN.
  • Jamie points out that following MARC rules you might put the number from the item you are cataloging in 020|z if it is a bad number, such as if the publisher printed the check digit incorrectly.  It is still the best identifier we have for the book, but it belongs in 020|z to recognize that it is wrongly formatted.
  • Oliver points out that there are many records in OCLC with ISBNs in 020|z.  He doesn’t want to have to change the data as it comes from OCLC to search effectively.  Searching by title can be very problematic when you have a very common title, like “New Testament.”
  • Lloyd asks what problems might be created by indexing the 020|z?
  • Ashley says that it could bring back more results than general users are looking for when searching by ISBN.  Pika developers were thinking that users are looking for specific formats and would want the ISBN to not bring back other stuff.  Also, they assumed that record grouping would overcome the problem.
  • Jamie says that it is common for people to not really pay attention to which version an ISBN is attached to.  They just grab one as expect it to work.
  • Grouping only solves the problem if you actually have both versions.  If you only have the one version people still want to be able to get hits on other version’s numbers.  
  • Oliver points out that the question is do we prefer some false positives or false negatives.  Would we create a bigger problem by adding it to the index?
  • Amy points out that we could make the change and evaluate it after a few months and change back if it creates a problem.
  • Ashley thinks that this might affect discovery partners too.  We would have to have this discussion in the Discovery Committee as well.  She is not sure if it is a change that can easily be applied to a single Pika instance.
  • The UCC consensus is that 020|z should be indexed in Pika, but *Lloyd and Ashley will run it by Discovery Committee too.
• Revisit automatic duplicate checking on new records
  • We again discuss the automatic duplicating checking when creating new records in Sierra.
  • We conclude that we want to try turning off duplicate checking for both Key Title and ISBN.
  • They can be turned back on if people notice a problem.
  • *Lloyd will turn this off.
• Updated cataloging standards document.  What’s the deal with 690 and 691?
  • 690 and 691 are a local topical and geographic subject headings.  They could be used in a case where you want to include a subject heading that is not officially approved, such as the name of a local person or place that is not prominent enough to get an LCSH.
  • What are these being used for now?
    • They identify special local collections like book club kits and student theses.
    • They have standard subject headings or notes that belong in other fields.
    • They identify works by local authors
  • Are we using |z correctly?  Should the library adding the note be identified in |z or |2?
  • 690 is indexed in Pika and displays as a subject heading
  • We find that there are very few 691 fields.  None have been created in the last year, and few in the last 5 years.  Most seem to be typos that belong in 651. Maybe Marcive can fix these.  *Lloyd will look into that.
  • *Lloyd will continue to revise the cataloging standards document based on this discussion.
• New duplicate checker
  • New duplicate checker for 001 fields is working now.
  • We still need to include 019 fields.
  • 020 checker still needs development.
  • We notice that Sierra automatically truncates searches in the Bib Util number field in the Staff Module.  Shelly mentions that it would be nice if we could get III to make the system stop doing that automatic truncation.  *Lloyd will investigate whether that is an option we can have them change and start an Idea Lab for it if not.
  • Discussion of how often we want Brandon to update Duplicate Checker.
    • Brandon says it takes him about 15 minutes each time he updates the data in Duplicate Checker.
    • Brandon can’t do it automatically because the location fields don’t come out correctly from SQL.  He says it pulls out one location rather than all of them.
  • We could take this back to duplicates committee to sort out these details.
  • *Duplicates Team will develop procedures and documentation for using Duplicate Checker.
• Stats results files, can we delete after a year?
  • Lloyd sends out messages asking people to remove these, but they are piling up anyway.
  • Maybe people are using Tableau for stats now and these are not necessary.
  • Question is how long should we let people keep files in here before Marmot deletes them.
  • UCC does not object to letting Marmot delete all stats results files more than a year and a half old.
  • We realize this is something we need to bring up with Access Services.  *Lloyd will run it by Access Services Committee.
• Idea Lab to suppress views of |0
  • We could start an Idea Lab proposal to have the |0 suppressed in Staff Module.
  • We might need many Marmots to sign up and vote for it in Idea Lab.
  • *Lloyd will start the proposal in Idea Lab.

New Action Items

Ongoing action items

Duplicates Sub-committee meeting: October 10, 9-10 MT

Next UCC meeting: October 24, 2018, 9-11 am MT