Meeting Minutes for 08/28/2019

Marmot Union Cataloging Committee
Wednesday, August 28, 2019
Minutes

Announcements

• Montrose go-live set for October 17.

Completed action items

Discussion Topics

• Pika test server now using API extract – Ashley

  • This process will be a continuous extract of bib and item data from Sierra to Pika.  Changes from Sierra should take about 15 minutes.
  • We are doing final testing on the test server.  It will on the live server next Tuesday, Sept 3.  Please look for problems in the test server and let us know about any issues you find after it is live.
  • There will be a button under staff view in Pika to force a new extract from Sierra, and there will be a time stamp of the last extraction on the staff view as well.
  • We are still pulling the nightly extract as back up for now, but the plan is to completely replace the nightly extract with this API process.
  • This will change grouping and ungrouping and format facets.  
  • This was created for our discovery partner LION, and they have been using a version of this since May.  This is an updated version of what they have been using.

• “Amulet” cataloging mess

  • There was a problem with the graphic novel Amulet.  This is a series of graphic novels. Bemis is using a single record for the whole series.  Many libraries somehow got their items for volume 4 attached to this record.
  • Nina mentions that she is sure her records were on the correct record a week ago, but somehow they got moved to the wrong one.

• Test of title verification loader – Selene

  • We tested a load profile function that would check titles of records before loading them.  It would check the match number, then make sure the title also matches.
  • Lloyd thought it created as many problems as it solved because we used it on a vendor loader that was overlaying order records.  It would often reject a good match because the title field changed between the order record and the item record.
  • Selene found that the [B] load profile would flag duplicates, but the test loader would not.  She thinks this is a reason that the test loader is not an improvement.
  • Lloyd suggests that this feature might be more useful for a loader that overlays OCLC records rather than order records.  A title difference between two records with the same OCLC number is more likely to be an indication of a bad record.
  • Selene mentions that an added subtitle would still get flagged with this.
  • Lloyd wonders about the idea of a process that would run batches of records through an OCLC loader that checks title verification to search for bad records.
  • Jamie says that CMU has already checked their records for these bad title.
  • Also, Nancy worked on an automated process to search for these.  She used that process to check records for SD51 and Adams state.  
  • That process did the title comparison in Excel, so it was a lot more complicated.  This would be similar, but more streamlined because Sierra would do the title comparison.  
  • Another thought is that OCLC now has API access.  Lloyd wonders if we could develop something that would use that access to do it even faster.
  • ACTION ITEM: Lloyd will look into developing such a process.
  • Lloyd needs someone’s OCLC login to do this for their records.

• DVD grouping revisited

  • Lloyd analyzed a sample of DVD records for how grouping works.
  • He compared grouping based on running time vs. names in 700 fields vs. the current method using publisher.
  • The current method actually checks the 710 then the 260$b then the 245$c.  This process is very out of date, and didn’t really make that much sense in the first place.  Few of our records still have 260 fields, and the 245 would be very unlikely to be useful.
  • Time got the correct grouping 82% of the time.  700 fields were correct 72% of the time and the current method was correct 41% of the time.
  • Running time was the most successful method, but running time is not a flexible field.  The running time listed in a record can’t be adjusted within the cataloging rules. However, we could change what appears in 700s or 710s to make them work for grouping.
  • The process assumed plus or minus 5 minutes would be a match on running time.
  • The plus or minus 5 would be a programing complexity for SD, so Jamie suggests we try a test of running time without leeway for time.
  • SD is already working on a project to reevaluate all grouping logic.  This could be incorporated into that project.
  • The group thinks that the running time is the best of these options because they prefer to use Pika’s manual grouping process rather than change MARC records to make them group. 
  • ACTION ITEM: Check the running time method with exact match on time.
• Tallie says they are on SkyRiver.  She wants to know if Marmot would prefer them to be on OCLC.
  • Yes.  It would simplify things for Marmot if you can afford it.
  • Shelley thinks that OCLC also saves her time so she prefers it even though it costs more.
• ​Oliver asks about the non-marc g field.  Do we have to worry about the extra information in those fields in old records?
  • Ashley answers that the old information is just ignored.  It can be deleted or left alone.
  • Tammy mentions that in the documentation for the non-marc g, there used to be a list of sources for people to use.  That list is now a linked google doc that people can edit if they want to add new sources.

New Action Items

Ongoing Action Items

Next Duplicates Sub-committee meeting: September meeting canceled.

Next UCC meeting: September, 25