Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Attendees: Magda Zacharska Charlotte Whitt Kimberly Pamplin Natascha Owens Brian Clark Laura E Daniels

Note-taker:  Brian Clark

Recording:

...

https://vod.video.cornell.edu/media/Inventory+Search+Improvements+Working+Group/1_2zvfgmq0

Agenda:


Notes:

Uses cases reviewed:

  1. Use cases added by Laura
    1. Charlotte: A broader perspective on use cases is important, not just catalogers. Will ask the RM working group for feedback.
    2. Natascha: It is important how the results list displays. Not just list of bibs
    3. These kinds of comments can be added to the notes column on the search improvements uses cases table.
      1. Laura: Added separate column: expected data on the results list
  2. Questions on what was already added to the search improvements table:
  3. Searching by resource title/alternate title: would you like to be able to specify title all/alternate title?
    1. Laura: In most cases we want title all, but in some cases we want alternate title with a specific type (i.e., uniform title)
    2. Charlotte: Identify any alternative title type and see if it was applied consistently?
      1. Laura: I have never wanted to do that. Do want to be able to search for an exact phrase for title all/alternate/series. Especially important for acquisitions
        1. Exact search implemented on back end, but not available through UI
    3. Magda: Do you want to be able to search specifically by resource title? There is no way to search instance title except by title all.
      1. Laura: Not by resource title, but definitely by alternative title (i.e. uniform)
      2. Natascha: Agree. Except in some cases, we would prefer for it be bunched together. We would maybe expect results to be sorted alphabetically, but that doesn’t seem to be happening
      3. Charlotte: In UI group, we are talking about an action window for sorting
      4. Magda: In Elastic Search, by default, ordering is by rank relevance, but can be sorted alphabetically
        1. Charlotte: This should be fixed when working on bugs. Order by index title
        2. Laura: Default sort would be determined by kind of sort. I.e., if searching by call number, search should be sorted on call number
  4. Resource title has same weight as alternative title. Is this not wanted?
    1. This sounds like what we want. Don’t want to have to know variations of title to be able to find resource on list. i.e., time.
    2. Magda: I believe this is the default. The algorithm takes into account frequency of word
    3. Magda: What about alternative titles?
    4. Kimberly: I think I would just use title all
    5. Magda: So only uniform title would be of interest
    6. Laura: Combining uniform title and contributor is especially important to catalogers
  5. Instance – contributor: would inverted names be an issue?
    1. John Steinbeck; Steinbeck, John, etc.
    2. Use cases needed.
    3. Laura: Should be able to accommodate both
    4. Sort order default would be index title if more than one contributor found
  6. Magda: Please continue adding use casesUpdates from dev
    1. Multilanguage support for up to 5 language specific analyzers. This removes stop words and accounts for grammatical differences. i.e., carols, carole and carol. The multilanguage support feature was removed for contributor to make searching more accurate.
      1. Charlotte: Should this be removed for publishers as well?
      2. Laura: Publisher field not controlled vocabulary, so feature could be useful.
      3. Magda: This can be assessed field by field as it is not a heavy burden for development team to remove this feature.
    2. Title sorting enhancement: results should be sorted by index title if present. If not, sort by instance resource title.
      1. Still in backlog. Will be added during one of the sprints in the coming weeks.
  7. Use cases
    1. Confirmed that holdings and items enumeration, volume, copy number do not need to be indexed.
    2. Holdings/item identifiers – need to be searchable?
      1. Do former identifiers need to be searchable separately (not just identifier all)?
        1. Does not seem necessary but might be most relevant for GBV libraries.
        2. Are accession numbers included as identifiers at the item level?
      2. Natascha: should HRID be included in identifier all? Would assume HRIDs would be included in that search.
      3. Holdings identifier all searching will include: HRID and former IDs, but HRID will also be searchable separately.
      4. Item identifier all searching will include: HRID, former IDs, accession number identifiers, but HRID will also be searchable separately.
  8. Electronic access
    1. TAMU use case on searching e-resource URI: librarian searches doc IDs within URI look for vendor-specific access to a given e-resource. ES does not seem to return results when searching URIs.
    2. Search on ‘http’ did not get results.
      1. Maybe a bug.
      2. Indexes may not be refreshed in Iris bugfest.
    3. In the 856 MARC field what should ES search?
      1. ES does not search MARC, searches inventory.
      2. URI would be most important (exact match and truncated (left and right) within in URI).
      3. Link text would be helpful if indexed for us to find sub-collection.
        1. Laura: Helpful if in separate index from URI.
      4. Laura: Material specified can be removed ($3).
      5. Concluded that no changes are needed, just need to verify if it is working.
  9. Notes
    1. Implemented search on public notes only on instance level.
      1. Laura: would be good to have notes all, public notes, and staff notes separately searchable.
      2. Charlotte: Will circulation notes be searchable? – Ask resource access people.
      3. Holdings statements notes? – No need to index and make searchable.
      4. Search all holdings notes and filter by public/staff?
        1. Would require adding facet.
      5. Charlotte: Would this be used for export?