Meeting Minutes for 12/04/2018

Discovery Committee Meeting
December 4, 2018
Minutes

New Discovery Committee Chair

  • Sean Crow is the new Discovery Committee Chair elect
  • His appointment still needs to go through the committee approval process
  • He works for the Boulder Public Library that is part of the Flatirons Consortium
  • This was Beth’s last meeting as Chair

Demo of new features, bug fixes, and documentation for upcoming release

Discussion of development priorities for the next release

Current Release

  • Addison Implementation
    • Will be going live this month (December)
    • Just need to iron out a few details this week (12/03 - 12/07)
  • AspenCat Migration
    • This is the top priority for December
    • AspenCat is moving to a new ILS
    • The current patron interaction behavior that R&D developed for their current system will not work for the new system
    • R&D will need to rebuild that integration for their new system
    • They will go live at the end of January
  • New Team Member Onboard
    • Chris is the new R&D developer
    • The team has been getting Chris up to speed so he can start working on projects

Next Release

  • Sacramento Discovery Partner Implementation
    • Will go live after the 1st of the year

Next Quarter

  • Bemis Library Marmot Implementation
    • 1st quarter of the year they are joining Marmot
  • Horizon ROA Driver
    • R&D would like to wrap up this project once the other priorities are finished
  • Aurora Implementation
    • Is the last scheduled new Discovery Partner
    • Kickoff call with them in January
    • Work on their Pika site starting in February
  • Sierra API Extract
    • R&D would like to finish this work in the spring
  • Integrate Hoopla APIs
    • Finish up the work that was started last spring

Reports from libraries on special projects

  • Bud Werner launched their new website on October 31, 2018
    • They built a special module to integrate all of the widgets Marmot has built into Pika
    • This module will display widgets uniformly across their website
      • This will also work for other vendor widgets

Discussion Topics

  • MARC records in Spanish language (Lloyd)
    • The Marmot Union Catalog Committee (UCC) discussed what to do with Spanish language records in the system
    • There was an issue that some folks were pulling in records that were actually cataloged in Spanish 
    • UCC had a discussion about allowing a duplicate record if there was an item with a record cataloged in Spanish, and another record describing the same thing in English
    • In the UCC it was decided that in Marmot they did not want to have two records 
      • We would go with a single record system, but people could add additional Spanish language content to the primary English record, if they felt it would be valuable
      • The UCC discussed having people add a second 520 with a different field group tag, so that field could be protected
      • If someone overlayed a record with a new version from OCLC that Spanish language field (that had been inserted) would not get overlayed because of the field group tag, but the rest of the record would get updated
      • they could also add in Spanish language subject headings
      • They found that Pika will run both notes together without any break, but we could not replicate this behavior during the DC meeting
    • Lloyd asked whether folks had other ideas about how this might best be handled in terms of display and searching to make this more effective
      • Lloyd knows that the Spanish language limiter is Pika is not working correctly
      • The thought was to bring this issue to the Discovery Committee to see if other people had suggestions for how this might best be handled in terms of display and searching
    • Ashley pointed out that R&D prefers descriptions from Syndetics or Content Cafe, whichever the content enrichment comes from first
      • When Pika cannot query one of those vendors for a description then the 520 fields are used 
    • Lloyd was unaware that the description comes from Syndetics first before the Sierra 520 field
      • He asked the group if this is the behavior everyone wants out of Pika
    • Ashley let Lloyd know that this is a setting that in Pika that can be toggled on or off
      • This is probably the explanation for why Pika behaved differently in UCC
    • Ashley pointed out that R&D needs to fix the grouping when there are two titles one in English and one in Spanish that group together
    • Pascal pointed out that record grouping is major project for 2019
      • He wants to make the primary language material a factor in the record grouping improvements
        • This would be using language as a factor for whether or not items should group together
    • Lloyd mentioned the problem of the language limiter not working correctly as well
    • Pascal shared that the language facet is not scoped
    • Lloyd wanted to run this issue by everyone to see if there was anymore input people would like to make on how we in the long run like our system to handle Spanish language
  • Indexing the 020$z for ISBN searching in Pika (Lloyd)
    • Marmot did a reindexing where the indexing of ISBN was changed
      • In Sierra there is a separate index for the 020a versus the 020z
      • This allows us to target our matching more precisely while still allowing a broad search in the OPAC
      • The Classic catalog is set up to search both 020a and 020z
      • We realized the Pika is only searching the 020a
      • The 020z is used for many different reasons
        • It can be used for and ISBN that is formatted incorrectly, nevertheless it is the assigned ISBN
        • It can be used for alternate versions of materials
    • There are Marmot members who wanted to search all the ISBNs
      • Mostly used for acquisition purposes
      • The 020z is a broader search that will bring up different formats, and invalid or incorrect things
      • The 020z is often correct things that are often a different format
    • The UCC (Union Catalog Committee) suggested to have PIka changed to search all the ISBNs in the ISBN search
    • Lloyd wanted to know what the Discovery Committee group thought about this idea
    • Beth from Flatirons thinks their catalogers use subfield z to put ISBNs that were displaying an incorrect cover
      • Beth wondered if Pika indexes that field would it impact cover display, or would it just be for searching 
    • Lloyd asked how Syndetics knows which ISBN to use
    • Ashley explained that every record has a primary ISBN at a grouped work level, and that is what Pika uses
      • Ashley does not know that if they started indexing the 020z, if Pika would use those ISBNs to build that pool for the primary ISBN
      • This could mean that some items may not get cover art, or call for incorrect cover art
      • The primary ISBN will be for descriptions as well as cover art
      • Ashley was under the impression that the 020z was just for different formats which is something they hoped would be solved with record grouping 
        • When you search for a title you will get all the different formats as they exist in the catalog, so you would not need to search by 020z ISBN
        • Lloyd mentioned that the UCC discovered that record grouping does not solve the issue of seeing and finding all the different formats 
    • Lloyd mentioned that if Pika is changed to do the reindexing, that we would want to make sure that the formula that creates the primary ISBN will never pull an 020z
      • Pika would leave the primary ISBN blank, before it would pull an 020z
    • We invite feedback from Discovery Committee members on this potential change/addition
    • Pascal mentioned that ISBNs do not play a part of the grouping functionality
      • The primary ISBN does get associated with every grouped work
      • Primary ISBN on grouped works comes from Novelist
      • Novelist has a system where they have ISBNs associated with a title
      • Any ISBN lookup with Novelist and the data that comes back includes a primary ISBN
        • Pika keeps the primary ISBN to get content enrichment
    • Pascal is not sure if he can separate the subfield z
      • There is an ISBN facet
      • If the 020z is added, the facet would treat all the ISBNs the same
      • There will be unintended consequences to adding the 020z to the index
    • Lloyd would like a ticket created so this indexing can be investigated
      • Ticket has been created at D-2534
    • Pascal would prefer that a new facet for this type of searching have a label that explains what is is and what is does
    • Pascal says that Pika could have two ISBN indexes for different functions
    • Lloyd pointed out that this was exactly what we did in Sierra
      • Sierra now has one focused index with only 020a for backend purposes, and a broad index with both 020a and 020z for searching by the public
      • It is this second broad index the UCC would like to see in Pika as well
      • Lloyd agrees with Pascal’s suggestion that Pika could also have two ISBN indexes
    • Pascal could create the facet for the advanced search, so it does not cloud up any other ISBN searches
    • Lloyd suggested that for public searching that there only be one ISBN search, since it might be too confusing to try to explain why there are two ISBN searches
    • Send other suggestions for this topic to pika@marmot.org, and Ashley will add them to the ticket

Reschedule for January DC meeting/deployment

  • The next Discovery meeting is for January 1st, which is New Year’s Day
  • A doodle poll was suggested, or pushing it back to the week after
  • The following week there is an E-Content Committee meeting the following week
  • R&D will take a look at the calendars, and send out an email about rescheduling the meeting and deployment
  • Due to the New Year’s Day holiday, the next Discovery meeting is on Thursday, January 3rd at 1:00 p.m.
Meeting Date: 
Tuesday, 2018, December 4
Documentation Type: 
Meeting Minutes
Link to File: 
Discovery Meeting Minutes for 12.04.2018 (Google Doc)
Committees: 
Discovery Committee