SUNY Libraries Consortium (SLC) 2017-2022

Members:

• Nancy Babb, University at Buffalo, co-chair Discovery Working Group
• Michelle Eichelberger, SUNY Library Services
• Rebecca Nous, University at Albany
• Jennifer Parker, SUNY Cortland
• Noah Roth, Broome Community College
• Amanda Hollister, Broome Community College

Charge:

Ex Libris is implementing a new Central Discovery Index (CDI), which will take the place of the current Primo Central Index (PCI). SUNY will be included in the early adopter phase to begin at the end of 2019. The CDI Task Force will focus on reviewing upcoming changes related to CDI implementation, and developing and recommending best practices for the SUNY Library community. The Task Force will begin its work in August 2019, with an expected end date in March 2020. The CDI Task Force will investigate the following:

• The evolution of the new CDI product and how it operates
• How PCI to CDI Migration will work
• Processes and configuration needed for CDI maintenance
• Changes to current practices such as Alternative Coverage PCI activation for EBSCOhost indexes
• How other Alma campuses intend to use the CDI
• Beta testing of the CDI

Deliverables from the CDI Task Force will be:

• Overview of what the CDI is and how it will work.
  • Projected Completion Date: October 15, 2019
• Test the CDI and report on findings.
  • Projected Completion Date: November 15, 2019
• Recommendations for campus implementation of the CDI.
  • Projected Completion Date: December 15, 2019
• Presentation to SLC members on CDI.
  • Projected Completion Date: December 1, 2019

We sent this list of questions to Ex Libris on Friday, January 3 in preparation for a meeting on Monday with Ex Libris, Nancy Babb, Shannon Pritting, and Michelle Eichelberger. Ex Libris responses on 1/6/20 are in red.

SUNY asked how yesterday's updates went (ability to suppress, availability issues): weren't able to do it yesterday, will happen 1/12 instead.

Known Issues: Is there an update to the 12/17/19 Known Issues document? Not much has changed, will update in a couple of weeks.

Fully-flexible vs. EasyActive models: If all of SUNY has to go live with the same model, can individual campuses change their model later? No answer from EL - CDI Task Force will pursue in EL CDI Basecamp.

Searching:

• Full-text: you've said that it's not necessary to mark yes to "Active for search in CDI" for full-text aggregator content because it's automatically searched unless you explicitly mark it no. Do you have recommendations for how to explain to our libraries that it doesn't matter if they say yes to search or not? Correct, if you activate an aggregator database for full-text, it will be automatically searchable, you don't have to also mark it "active for search in CDI" but it doesn't hurt to do that. It will happen automatically in activation wizard.
• Is it necessary to mark yes to "Active for search in CDI" for other types of content, ex: Database? Or is all content, collections of all type, automatically included in Primo VE search results if activated in Alma, unless explicitly marked "Do not show as Full Text available in CDI even if active in Alma"? Anything marked full text is active for unexpanded search. The search comes from the CDI metadata index - not from specific collections.
• Alternate coverage: you've recommended keeping PCI EBSCO alternative coverage packages active for searching. Campuses have already started asking why they need to keep these packages active if everything that's full-text is covered for searching. Thoughts for how we should answer this? You do not need to keep alternative access databases active to make EBSCO content discoverable. Anything full-text, including EBSCO, will be searchable via the CDI metadata Index. However, if you would like to search your PCI "alternative coverage" databases in your expanded search, you can keep them active for search.
• Expanded searching:
  • If expanded searching indexing includes all of the full-text indexing, (your Basecamp post said that expanded searching was full-text index + any additional activated search collections) which is the entire Central Discovery Index, why do we have to activate any other packages for searching? I'm specifically asking about packages for which we don't have full-text. Use case: campus had Proquest Religion Database active for search in PCI for alternative coverage, package was moved into Alma and set up for Active for Search in PCI. If the entire Central Discovery Index is active for search in expanded searching, why should the campus leave the Proquest Religion Database active? If you don't activate any databases for searching besides what you have full-text, your unexpanded search and your expanded search will give you the same results. You can only add results for non-full-text content by activating other collections for search.
  • If something like Hathitrust is being used for indexing for full-text content, and we can't control that, is there any way to get it out of indexing for expanded content? If it's part of the full-text indexing, which is part of expanded searching, can we get rid of it? Many campuses won't want that level of reference entry detail in their expanded search. EL will look into changing Hathitrust searching from full-text to metadata searching, which could decrease the number of search results you get. This won't happen right away, would be a couple of months. SUNY agrees that chapter level and article level searching is useful, but not full-text searching, especially for Hathitrust books where a search term might only appear once in a 300 page book.
• Is the only way to remove something from expanded searching to add it to Alma for searching only, then mark it no for "active for search"? The system works in reverse to this - you can only get a non-full-text collection active for searching by activating it for search. You can't control how full-text is searched.
• Can we tell if some collections are being searched in full text and some just metadata records and if we have any choice/control over that? Labels are inconsistent and EL will work on that.

Local Collections:

• Can you search the bib records in local collections? Yes, should work the same as with Alma/PCI
• Do local collections allow article-level searching, or not because they're local and not part of the CDI? Note: article-level searching currently works for local collections with PCI indexing. This should work the same way - if it's not, please report and EL will explore
• If you can't search them at the article level, will they show up as available on article index records from the CDI, based on their ISSN or other metadata? Will work the same way they do with Alma/PCI
• Will they show up in the View Online section like they do now in the PCI? Yes

Availability:

• Will the "on-the-fly" look-up of availability on the full record work the same in the CDI as it does for the PCI, usually based on ISSN or ISBN match? Yes, still based on ISSN/ISBN
• Why are some available things showing as available and then when you open the full record, the link is either missing or doesn’t work? Need to review after fixes and report problems.

Facets: 

• Will the Alma and CDI facets match up? Or will we still have Alma e-Books in Books while CDI eBook records show as eBooks? Also, video vs. videos. CDI facet for eBooks will be books, if it's not, please report and EL will investigate. Video and Videos won't match, but they'll send us documentation on how to make them match.

eBooks: 

• Can we replicate current PCI practices where we can search the Alma bib record (title, author, etc.) for eBook collections but not search by article/reference entry? It sounds like this will be possible if we put eBooks in a local collection with no article/reference entry indexing, but then we have the questions about local collection fulfillment. No. It's either bib record and contents searching or no searching.

Link Display:

• Will the labels for links in the View Online area of records be updated to display the specific collections? Currently, we are seeing many records in the CDI with generic label "View record" and no helpful identification of source being linked to. They're working on this - known issue