We were expecting since full text is activated that meant our NZ collections should be discoverable in Primo. I understand that analysts will need to look at specific examples, but it seems this is not working as expected - at least not for all the collections. This means we will need to report issues as we find them.

My assumption is that we have to check that NZ collections are discoverable. Does Ex Libris have any instructions we can use to do this? With merged records and the use of metadata from different sources, I can see how this would be difficult to verify that a specific collection is discoverable or not.

Case #00850656, 00851297, 00851265,

Reported to Ex Libris. Developing instructions Full text links were appearing when there was no full text

“ebook says "full text" but no full text access for a collection we don't have CDI. This is one example of records appearing in our Primo with this particular collection - TN_cdi_askewsholts_vlebook. The record says "full text available" but the full record says "no full text available".”

This collection was causing a lot of issues with the full text available displaying when it should not.

Case #00855574

Ex Libris remove the Vlebooks collection from CDI

Database content not discoverable in Primo. (Updated 7/06/2020)

If the special “Full Text active in CDI only: Yes” does not exist in your IZ for Electronic Collection Type: database, then it must be inherited by individual libraries from the NZ or must be activated in the IZ by individual libraries to be discoverable. Complication: the bib record must be unsupressed which is against policy. Recommendation in progress.

Case #852010, 851956. etc.

Reported to Ex Libris. Narrowed the issue down to Databases. Testing out possible solutions.

Slowly developing instructions to check for discoverabilty of NZ collections here.

Full correspondence can be found here.

Proxied OA collections (Updated 7/06/2020)

“16 out of 70 cases (23%) center around this issue. According to ex libris support, there is a "mismatch between the Alma collection being marked as Open Access and the CDI records not being marked as such in the metadata" We asked CDI_Info about how widespread the issue is.

CDI_Info response: “The content team is aware of this. I think there is an issue with certain collections not being fully open access and it is difficult to reflect this correctly on Alma. If these are collections that can be split into open access and none open access items the content team will do this but this is not always possible. The plan at the moment is to flag collections where the split is not possible as partially open access in Alma.”

Case #852731, 851991, 850959, 850506, 850034, 847763, etc.

In progress…

Full correspondence can be found here.

Full Text Availability indication flag in brief record/No link in full record. (Updated 7/06/2020)

About 26/70 (37%) were about this issue. We understand that this can be complicated to address however we thought we'd share some steps we've taken to do our part. First, we updated the " We subscribe to only some titles in this collection" for ProQuest and Gale Aggregator Packages Linkresolver type in the NZ to Yes instead of No….My question is: do you know if this will help and also are there other factors we should take into consideration?

CDI_Info response:

For aggregator collections which have some content without identifiers and which use the link resolver the match can be difficult and fail. So if such collections are set generally to all content as full text available, and some content cannot find a match you have the false positives. While the content team is working on improving this over time I doubt that this is something we can entirely fix. So for collections that have such content it is better to use the selective flag as you suggest in your email. That will definitely make it more accurate. It will lead to some content not being flagged as available so the downside is that you have false negatives. But you have no false positives anymore that can lead to linking problems.

Case# 854035, 852793, 853274, 852728, 851265, etc

Testing different solutions

Full correspondence can be found here.