Meeting Minutes for 01/24/2018

Marmot Union Cataloging Committee
Wednesday, 24 January, 2018
Agenda

• Duplicate Committee Report

  • Karen has left duplicates committee (and all of Marmot ☹) so the committee could use new members.  Anyone can join duplicates committee.  It is usually a troubleshooting session.  Anyone who wants to help with the duplicates problem is welcome.  We meet with Zoom on the second Wednesday of each month at 10:00AM.
  • We invited Amy Sieving from Wilkinson Public Library to join because we would like to get input from someone using the Marquis macro into the duplicates issue.  Amy has agreed.

• Quarterly Authority Update

  • Our new authority vendor, Marcive, allows a bulk record discount for more than 50,000 records.  We now have 61,000 new records since the database overhaul last year.  It looks like we create over 50,000 new records each quarter year.  So we are going to try sending them new records on a quarterly basis so we can get the bulk discount.
  • The bulk rate is about $0.04 per record verses their standard rate of $0.06 per record.
  • One disadvantage of the bulk system is that they don’t guarantee a quick turnaround.  However, in practice they did return the records in less than two days.
  • Chat asks if there is anything that members should not do while the records are out.
    • The returning records will only overlay authorized fields, so it is okay to add notes.  However, changes to authorized fields would be overlaid by the incoming information.
  • People would like to be notified next time records are going out for authority work so they don’t make edits they might lose.
  • Lloyd will add this to the process next quarter.

• Instructions for setting URL colors

  • Tammy created documentation on how to set the colors of the URLs in records, so the subfield zero URIs are not so annoying.  This is now on Marmot’s Sierra documentation and training page.  https://docs.google.com/document/d/1SbKIoeexLkFHchFA4PBoIjZJxMMLMtoMPSf5Qp6_eGc/edit

Discussion Topics

• Reindexing Project

  • The reindexing project has been funded by the Marmot Board.  So we can go ahead with planning it.  The reindexing team met this month and finalized the ideas for reindexing.  They are listed in detail on a page linked from the UCC web page: https://www.marmot.org/for-members/committees-and-task-forces/union-catalog-committee/reindexing-project

• Four ideas for changing bib record indexes were discussed:

  • Remove 074 from ISN index.  The 074 is used for certain federal government document numbers.  It is not a unique identifier.  The government applies the same number to many different documents.  The result is that these many different documents appear in Headings Reports as duplicates.  They clutter up the report with junk that does not belong there.
  • Jamie points out that they need to be able to search this number and wonders if it will still be searchable.  We do some experimentation, and it does not seem to be searchable now as a keyword.  We can check with our III people about what can be done to make it searchable in some way.  However, CMU’s VuFind can be setup to index whatever they want, so if CMU needs to search the 074, they could easily do that with their own catalog.  Nobody else speaks up that they need to search it.
  • We do some experimenting and find that CU Boulder appears to have the 074 in the ISN index in their system, so it seems likely that this is the standard III set up.
  • Lloyd will send out an email to find out if anyone is using this field.

• Move 019 from ISN index to BIB UTIL index.  The 019 is used by both OCLC and SkyRiver for old record numbers.  When they merge two records, one of the record numbers goes into the 019.  When we load a new record that has a 019 matching an old 001 in our system, Sierra does not see that is a duplicate and creates another record.  If these numbers were in the same index, then that new record would overlay the old one.  Also, matches between the 001 and the 019 would appear in Headings Reports as duplicates.
• The only danger we can see if that the reverse could happen.  If someone loaded an older record with a 001 that matched a 019 in Sierra, then you would overlay a new record with an old one.  We think this is a rare situation.  The only likely source for such an old record would be a vendor, and the vendor load profile matches on ISN anyway, so this change would not effect that load.  Even if this did happen, it would still be a correct record, just less complete.

• Create a second ISBN index.  We have a problem now where it is common for records to have ISBNs from various different formats in the same record.  There might be numbers for Ebooks, audiobooks, large print and regular books all in the same record.  This is useful so that a search on any of those numbers will get a hit so you know we have that title in some format.  However, it creates a problem when loading records.  If Sierra finds a match on one of these numbers for a different format, it will overlay the wrong record.  You will get items attached to a bib record that describes a different format.  Worst of all, the wrong items will often times belong to other libraries who didn’t load the new record and don’t even know it happened.

  These ISBNs for different formats are supposed to be entered in a subfield z of the 020 field, while subfield a is reserved for the correct ISBN.  We could take advantage of this by creating a second ISBN index.  The first index, called ISNa, would only include the 020|a fields.  That would be used for matching.  The second one, called ISNz, would have all the 020 fields, both |a and |z.  That would be used for searching.  That way, to the extent that the 020 is used correctly, we would avoid overlaying wrong format records, but still be able to do a broad ISBN search.

  The question of how this would operate in Headings Reports comes up.  We think we would have to select one or the other of these to be the operable ISBN index in Headings Reports.  It seems like it would make sense for that to be the ISNa.  Records the ISNz sees as duplicates are not things we really consider duplicates, so this change would also make Headings Reports more efficient.

• Remove |0 and |1 from indexes.  These fields were added in the recent Marcive authority overhaul.  Someday they will allow us to use cool linked data in the catalog, however for now they create problems.  In the classic catalog, when there is a record with the same heading, but one has the |0 and the other does not, you get two separate headings.  The system can’t see that they are the same thing.  Removing these subfields from indexing will fix this problem.

• During the discussion of indexing issues, Jamie asks how we are getting along without Nancy’s job.  We discuss the topic.

  • Nancy’s critical duties, such as deleting dummy records and orphan bibs are getting done by Marmot staff.  However, lower priority tasks such as Pika record grouping, deduping and fixing bad 001 fields are not getting done much at the Marmot level.
  • We would like to find ways to help members to work on these things more effectively.  We developed a process for Nancy check bad 001 numbers in batches.  We would like to teach members to use it, if they have staff with time to work on it.
  • Jamie has a staff person who could learn Nancy’s 001 checking process.  We will set up a meeting for Jamie to learn about the process to see if his staff could use it.
  • Shelly says she has a volunteer who could work on it as well.
  • If anyone else has staff who wants to learn Nancy’s process for checking bad 001 numbers, contact Lloyd and we will set up a meeting.

• Cataloging and grouping travel books

  • Nina brought to our attention the fact that Pika treats travel books weirdly.  As an example we search “lonely planet northern california.”  The first hit is “Fodor’s 2013 Northern California”.  One copy of Lonely Planet is grouped with Fodor’s for some reason.  We investigate, and it does not seem to be a manual grouping.  We notice that a Mobile travel guide is also grouped with Fodor’s.
  • Nina recommends using serial records for these because they won’t change with authors, so they should group better.  She also uses serials checkin cards to keep track of these, so they can do claiming with the vendor when the expected copy is late.
  • Some libraries don’t have the serials module, so they don’t have access to checkin cards.
  • Vail also uses serial records for travel guides, but not checkin cards.
  • Garfield prefers to use monograph records because then people will create bib level holds.  That way patrons will put holds on the specific editions they want.
  • Amy points out that the edition at the top of the list is not the most current, but that is the one that will get the first hold if a request is placed.
  • Jamie suggests setting up a subgroup of people who are interested in this topic to investigate what’s going on with travel books and how they are grouped and ordered in Pika.
  • Jo points out that we should get someone from R&D in that meeting.
  • Betsey is troubled by the fact that non-fiction is not sorting with the most recent version on top.
  • These issues may already be in YouTrack, if so UCC people could vote for them to push them up in priority.  If they are not, we could add them.
  • Tammy could do a training for UCC on YouTrack.

• Saved searches, sorts, lists and exports
  • We have maxed out the number of saved exports in Sierra, and the others are fairly full as well.  III will increase them for us if we want, but we already have many of them that we probably don’t need.  Adding more will slow down the system, and allow us to add even more clutter.
  • It would be better to get a handle on what is in there.  We would like to find a way to identify which of them are obsolete.
  • Amy points out that some of these are actually exact duplicates of each other.  We could set up community use saves that everyone could use rather than everyone duplicating the same thing.
  • Lloyd suggests that people could identify saves they are actually using, then we could find the ones we can get rid of.  This would require doing a Save As to make a copy of each save with a new name.
  • Jamie does not like the fact that doing Save As would cause the saves to move to the end and would no longer be in their expected location on the list.
  • Lloyd suggests that he could produce a list of all the saves, and send it out to everyone.  People could then identify which ones they are using.
  • We should start by people deleting ones they know are not being used.
  • We would also like everyone to use more helpful names.  All saves should have the library’s initials in the name or they won’t be saved.
  • Circulation people also use these saves.  We need to include them in any process of cleaning them out.  Lloyd will email AllPoints about the project to get everyone involved.

• Draft Marmot Cataloging Guidelines

  • Lloyd has been working on updating the Marmot Cataloging Guidelines.  However, it seems like this document has been serving two different purposes, and maybe that does not make sense.  It is both a policy document and a training document.  It is getting very long to be useful as a policy document.
  • Jamie and Shelly point out that the document needs to be clear about what level of cataloger it is targeting.  They don’t think it should be for original catalogers.  People doing original work will have access to OCLC and RDA documentation.  This should be for copy catalogers.
  • Diane wants a document specific to Marmot requirements.  What does Marmot need that is different from standard cataloging?
  • Jamie says that would just be a brief outline
  • It should cover what is important to Pika.
  • It could include load table information.  That is specific to Marmot.
  • How we share records.  We all use the same records.
  • Information for cataloging in Sierra.  New people may know cataloging, but not Sierra.

• Chat asks when are we getting more I-TYPES?

  • Amy says Brandon told her he expects this to be expanded in the 2018 Q3 release.

• Jamie asks when we can expect to upgrade to the release we were going to beta test.

  • III has said that will go into general release around the end of January.
  • We have not set our upgrade date.
  • We didn’t do the beta test because there were serious problems found in the beta test.
  • It does not appear that the beta process tested the needless transit fix at all.

• 938 fields in bib records
  • We did not get to this topic.

Ongoing action items

Duplicates Sub-committee meeting: February 14, 10am MT

Reindexing Sub-committee meeting: February 14, 11am MT

Next UCC meeting: February 28, 2018, 9-11am MT