Meeting Minutes for 11/22/2017

Marmot Union Cataloging Committee
Wednesday, 22 November, 2017
Minutes in blue text

Reports

• Check if Marquis loader is removing fields​
  • Marquis process is not removing fields.  Before 2014 it would check for a match in the 028 field in a way that would remove the 001 field when the record was reloaded.  However, Andy removed that search in 2014, possibly because of this failure.  We now know what was wrong with that search, so Andy can now add the 028 search back to a new version of Marquis.
  • Lloyd discovered that Marquis was duplicating 590 and 583 fields when it reloads records.  He changed the load profile to stop doing that, and is using the Global Update duplicate field remover to clean them up.  This change means that it would not work to add a 590 or 583 note with the Marquis reload, if anyone is doing that.
  • Andy is considering developing a simplified version of Marquis, since only Telluride uses most of the bells and whistles.  

• Report from Duplicates Subcommittee

  • Review file 38 is duplicates found by comparing 019 fields to 001 fields with Openrefine.
  • Many of these were duplicates created by flc prefix, these were mostly cleaned up after Duplicates meeting.
  • 019 and 001 could be compared again for current dups.
• Report from Reindexing Subcommittee
  • Do we need these indexes?​
    • Gov doc number (g) separate from local call number (m)
    • UPC (j) separate from ISN (i)
    • TitleKey (k)
    • Author/Title (q)
    • CARL BID (v)
    • Course ID (x)
    • (y)
• III has agreed to have Nancy Quan, their indexing expert, join the meeting of our reindexing subcommittee on Dec 13 to answer our questions.
• Lloyd has learned that each phrase index is linked to a lower case letter, so there can only be 26 phrase indexes.  Keyword indexes and record number indexes are linked to upper case letters, so there can be more indexes, but not phrase indexes.  We are not sure what the difference is.  We will ask Nancy Quan.
• We have also realized that many of the problems we want to solve could actually be fixed by creating new field group tags.  The break out function in Global Update is based on Field Group Tags not Indexes.  We are not sure if changing field group tags is similar difficulty and expense to indexing.  We will ask Nancy about that as well.
• It looks like we only need two new indexes.  The rest of our issues can be fixed by changing existing indexes or with new field group tags.  The letter ‘y’ is already free, so we would need to eliminate one existing index.
• CARL BID (v) is a good candidate to eliminate.  Nobody seems to know what that is for.
• Karen says she needs to keep the COURSE ID (x) index.
• Several people say they frequently use the Author/Title (q) search in classic catalog, so they want to keep that.
• TitleKey (k) is not useful, but we’re not sure the system will allow it to be changed.  Karen points out that they find it to be a nuisance.  It never finds useful duplicates and it creates a useless step when creating records.  We will ask Nancy about it.
• Another question for Nancy: what is the difference between a phrase index and a keyword index, and could anything we now have in a phrase index exist as a keyword index to free up a lower case letter.  Why is ISN in a phrase index?  ISNs are not phrases.  What about Course ID, could that be a keyword index?
• Maybe UPC could be combined with ISN.  Amy points out that staff currently search DVD barcodes as a UPC and book barcodes as an ISN.  They would need retraining if this changed.  We are not sure of the value of having these in different indexes.  It might be easier on staff to be able to search them both the same way.  This might be worth changing even if we don’t need to free up the letter.
• Jamie needs the Gov doc number index separate from Call number because he needs to be able to sort by SuDocs numbers.
• Karen points out the Sierra documentation on indexing: https://csdirect.iii.com/sierrahelp/Default.php#sgil/sgil_search_indexes.html.
• Amy asks about indexing patron telephone numbers and birth dates​
  • III has told us that patron telephone numbers and email addresses can share a single index.
  • Indexing patron birth dates has not been brought up in this discussion before.  Lloyd will add it to the web page.  It would probably mean we need to free up another lower case letter.
  • Could the issues with patron birth dates be solved by putting them in a field group?
  • Could either birth dates or phone numbers/emails go in a keyword index?  Do they need to use a phrase index?
  • Could dates share an index with phone numbers?  What about sorting?

• This is the link to where we are collecting reindexing ideas: https://www.marmot.org/for-members/committees-and-task-forces/union-catalog-committee/reindexing-project

Discussion Topics

• Probably upgrade to Sierra 3.4 beta next week​
  • 3.4 is supposed to fix much of the needless transit problem.  III needs customers who have the needless transit problem to test the beta version.  Since Marmot is one of those customers, III has asked us to beta test.
  • We are currently on 3.1.  In order to implement the beta version, we have to be on 3.3 first.  We can skip over 3.2, but we have to be on 3.3 to implement 3.4.
  • We are considering upgrading to 3.3, then 3.4 the next day.  This would be only a few days after 3.4 becomes available to anyone.
  • There have been reports from users of version 3.3 that they have seen the problem where checkin cards become unstuck.  We hope this is fixed in 3.4, but nobody knows yet.  We have asked III about it, but have not heard back yet.
  • Several members have serious concerns about implementing a beta version so early.  They suggest that we not go first.  We could allow other customers to test for a while before we upgrade to the beta version.
  • We invite Brandon and Jimmy into the meeting to discuss timing of the upgrade.
  • This is short notice because III didn’t give us much notice.
  • Being a beta tester of the needless transit fix means that we can get it fixed quickly if it doesn’t work for us because of something unique to our setup.  After general release it may be harder to get III to address our unique issues.
  • Jimmy is anxious to implement a solution to the needless transit problem because we have been waiting many years.
  • After discussion of concerns about beta testing, we determine that we could do the upgrade a couple of weeks later.  That will give us time to hear reports from other beta testers.  December 11 or 12 would work.
  • Brandon will discuss the details with Julie at III before we make any commitment.  He will email Allpoints when we settle on a final plan.
  • Brandon will bundle up the release notes of all the versions we will implement and send them in an email to Allpoints.
• 995 note can identify exporting library based on 994 from OCLC​
  • At last month’s UCC meeting, we realized that OCLC Connexion puts a code in the 994 field that tells you which library exported the record.  Lloyd used this to build a translation map that will add the name of the exporting library to the 995 field with the name of the load profile used.  That is now implemented in the test loader.  You can see it if you add a “*recs=test;” command to a 949 field when you export from Connexion.  This will cause the system to load the record with the test loader.  
  • It should add a 995 field that says something like “Exported from Connexion by Adams State and loaded with m2btab.test in this month”
  • This works with Connexion, but we don’t know about the browser, or OCLC record sets.
  • We do not think this will do anything with SkyRiver because it does not add the 994 field.
• What about moving 590 notes into items?​
  • Last month we talked about the possibility of editing our export profiles so that 583 notes would move from item records to bib records for the Gold Rush export so they would be in bib records for the Alliance last copy project, but we could keep them in item records in Sierra.
  • III has tentatively given us permission to edit our export profiles for this purpose.
  • If we can do this with 583 notes what about 590 notes?  This would allow us to keep them in item records with the items to which they apply, but they would move to the bib records on export to Pika.
  • The notes have to be in bib records in Pika so they can be searched and will display intelligibly.  However, local notes often apply to a specific item and keeping them in item records makes it clearer in Sierra.  If we can move them on export, maybe we can have the best of both.
  • Another option might be simply to keep the information in both bibs and items if it is important which item has a special characteristic.

• At this point we ended the meeting because Lloyd was feeling sick.

Ongoing action items

Duplicates Sub-committee meeting: December 13, 10am MT
Reindexing Sub-committee meeting: December 13, 11am MT
Next UCC meeting: December 27, 2017, 9-11am MT