With CDI we have no control over preventing CDI content from appearing in our Primo filtered search, when we have full text holdings which matches to this content.
In many cases this may be a good thing, in not needing to worry over making sure full text content is searchable.
However, it is clear that there are collections in CDI with very poor data, which causes linking to fail, and also has content which we do not want at all such as Journals and Books, as we manage the title level by our Alma records.
For example, CRL Catalog has 76,000 Journal records, which duplicate our own records and many of them are failing Link Resolver requests. LIBRIS has similar issues and content, and so does DataCite.
In just one day of Link Resolver data, for CRL we had 17 of 49 requests fail (34%), and for DataCite we had 27 of 124 requests fail (21%).
These numbers are all real users who are having a poor experience in our Primo environment and building a terrible impression of our Library service.
We should be able to remove this content by Alma Electronic Collection, with this content not appearing in our Primo environment if the CDI Electronic Collection is not in our Alma environment, such as not in our Institution Zone, or a new CDI setting to achieve this.
Please restore our autonomy to remove this content, so that we can offer our users a stable and consistent experience.

When the URL in a bib record attached to a portfolio is updated (individually edited, or batch load/overlay of records), there should be a setting to the action so that the URL in an attached portfolio would also be updated and we don't have to remember to manually do this. We have had 2 recent instances, one where we used APIs to update bib records using our old PURL manager to use our new one, only to find that the portfolio URLs also needed to be changed separately, and one where we have a batch of vendor records with changed URLs that we had to delete and re-add in order to get the portfolio URL updated. Both of these were large batches... We'd like to tell Alma to synch URLs in the attached portfolios when we make a manual edit, or load/overlay a batch of records.

If there's a way to do this we don't know, please tell us!

This feature would add the ability to load and export split coverage date ranges for Alma portfolios. Currently, the portfolio loader only allows uploading continuous coverage date ranges. However, in some cases, a journal has split coverage dates. For example, we might have access to a journal from:

1980-1995
1997-present

Currently, there is no way to upload this using the portfolio loader; the portfolio loader will only load one of the date ranges. This means we must do extra manual work to enter these date ranges in the portfolio editor.

Also, the standard portfolio export features in Alma, in cases where a portfolio has split coverage dates, only export the first range. In the above example (coverage from 1980-1995 and then 1997- present), export options (such as "extended export") only export the first range (1980-1995). This creates confusion when performing exports, as the export sheet does not contain accurate date range information. The only way to export split coverage from Alma is to use Analytics.

These improved import and export capabilities should be added for all uploadable date fields and all exportable date fields, including both the current coverage dates that display in Primo and the perpetual access date fields only visible in Alma.

For electronic collections - under the Activation tab for Service temporarily unavailable:

Instead of selecting a date to turn the notice on, allow staff to select the date on which the notice will automatically expire, and then on that date, have Alma automatically set the temporarily unavailable button to off and blank out the reason/text box. Also, consider making that text appear in red.

Logistically, it makes more sense for the notice to automatically disappear, since there is no mechanism in Alma to remind the staff member that such a notice has been added to an electronic collection. So setting an expiry date for the notice (instead of choosing when to turn it on) makes more sense to me. Upon expiry, it would be good to automatically email the person who set the notice initially indicating that this notice expired along with the text of the notice. In case the downtime is extended, then the staff member can reset the notice as necessary, until such time as the service becomes available again.

Thanks for considering. Sandra.
Simon Fraser University.

Use case: we consider subscribing to a new database but want to know how it overlaps with ALL of collections we have access.

Current Problems:

Set Comparison
1. The source collection must be activated
2. Have to select ALL target collections by hand

Selected Titles:
1. Kinda works BUT it DOES NOT look at coverage info

tl;dr: please implement something similar to Overlap Analysis in SerSol's ClientCenter.

Credit

Hi All,

Is there an easy way to compare all of our activated e-resource holdings in our Alma Institution Zone against one database we don’t have activated to determine overlap and unique titles?

I’ve been looking in the “Overlap and Collection Analysis” section and it requires the selection of individual collections for the target and source sets. It would be quite laborious to manually select all collections we have activated.

There’s also no clear explanation of what a “source electronic collection” vs. “target electronic collections” mean. Could anyone clarify this?

Also, is it possible run a comparison between two collections that we don’t have activated? I ask because I don’t see a Community Zone option under “Source Electronic Collection.”

I looked in the Knowledge Center and didn’t find answers to these questions in this article:
https://knowledge.exlibrisgroup.com/Alma/ProductDocumentation/010AlmaOnlineHelp(English)/040ResourceManagement/070AdvancedTools/010Overlap_Analysis

Thanks in advance.

CR

CZ collections vary in regard to the quality of their metadata. Some CZ collections contain rich MARC records, while others contain very poor records. When facing the question whether to import vendor's MARC records or to rely on CZ records, librarians usually lack basic information about the quality of existing MARC records in a given CZ collection.

I would like to suggest that each CZ collection will include basic statistical information about the MARC records quality. Such information could be generated in different ways.

One possibility is to provide an analysis based on predefined quality profiles of MARC records. Here, specific profiles of MARC record quality would be defined (such as: 'brief', 'basic' and 'rich'), this in accordance to the type and number of MARC tags included in each profile. Based on those predefined quality profiles, each collection would then include a summary of the percentage of records fitting each quality profile. The librarians could see that CZ collection 'X' contains 10% 'brief' MARC records, 60% 'basic' MARC records, etc.

Second possibility (complementary to the previous), would be to provide a general MARC tags count for all the collection records. Here, librarians would easily see the frequency of each MARC tag in the records set. With this information provided, it would be easier for librarians to assess the MARC records quality of a collection, judging by the percentage of records that contain certain tags, as ISBN (020), ISSN (022), subject heading (6xx), etc. Preferably, within the CZ collection view, librarians would be provided with a summary of the information, focused on several important tags (ISBN/ISSN, authors, subject heading, etc.), and an option to download a full frequency analysis report.

As an electronic resource librarian, I would like to see a better way to deal with rolling coverage dates. There does not seem to be a good way to deal with gaps in portfolio coverage when there's a moving target date involved. For example, if a title includes perpetual access from 2011-present, and issues 12 years or older are open access, unless you include a public note, what will display is:

Available from 2011 volume: xx issue: xx
Most recent 12 year(s) not available

This is confusing to patrons and librarians alike. It would be useful to have the option to select a rolling date within the "local date information" field, instead of having a separate field that displays rolling date information in a different manner than other coverage information. For example, with the proposed enhancement, you could have date coverage:

Available from 1923 volume: xx issue: xx to 2005 volume: xx issue: xx (or even "issues older than 12 years")
From 2011 volume: xx issue: xx

Currently electronic portfolios are generated from the 856 fields in the bibliographic record, but they appear in reverse order in ALMA and Primo. Vendors often have 856 for multiple volumes in their records and they often list URLs in the order of their importance. In my attached example, the vendor includes a link to browse the particle resource first, then links to search the collections which contains the resource. The links are listed in order of importance. It is confusing to the user to list v.2 before v.1 and less important searching options before the most direct way of access the material. This should be corrected.

We now have the ability to log current access dates and perpetual access dates on a portfolio. However there is no way to display the perpetual access dates in Alma or Primo unless looking at the coverage tab of the portfolio.

It would be good if there was an option to use the perpetual coverage dates as our display dates either by having an additional option for the local, global, local and global section, or just displaying those dates if local only is selected and there is nothing in the local section.

We have titles that we had current and perpetual coverage for , now publication has ceased and we only have access to our perpetual coverage. For this to display in Alma and Primo we have to update the local coverage dates to match our perpetual coverage dates.

There are some electronic services and portfolios in the Alma CZ that do not use parser parameters. Instead, they use ISSN or some other element drawn from the MARC metadata to construct their links. However, there is no indication in Alma when a service or portfolio behaves this way. To the Alma user, it looks as if the portfolios must be misconfigured, as they have no parser parameters and no apparent way to link at the title level. This makes troubleshooting linking problems very difficult, and it conceals the actual linking functionality from Alma customers.

To be fully transparent with customers and to enable customers to better troubleshoot linking problems, Ex Libris should add an indication at the service level linking tab (inherited by portfolios) 1) showing when MARC metadata is used instead; and, when this field is selected, 2) either the Parser parameters field or a new field should show which MARC fields are used to construct the links. I will attach an image showing where I think these new indications should appear in the service linking tab (they should also be inherited by portfolios).

An example collection that behaves this way is Akademiai Kiado, CZ Collection ID 611000000000000691

Please add a new Rapid ILL lending status field to electronic collections so libraries can indicate the following Rapid ILL lending statuses and more easily create logical sets to automatically send holdings to Rapid:
• LendableInternational: You are able to fill lending requests from any other Rapid libraries around the world. This is typically the Lendable value used for print materials that you want to make available in Rapid.
• LendableCountry: You are able to fill lending requests only from Rapid libraries in your country. This is typically the Lendable value used for electronic materials.
• LocalOnly: You are not able to fill lending requests from other Rapid libraries, however these items are still available to fill your local patrons’ borrowing requests.

Currently, the documentation suggests putting these labels in electronic collections’ internal notes field. https://knowledge.exlibrisgroup.com/RapidILL/ImplementationGuides/AlmaHoldingsHarvestfor_RapidILL

It would better to have a dedicated field in electronic collections where a Rapid lending status value could be selected.

Libraries should also have the ability to perform bulk changes to this field via the E-Collection Quick Update Cloud App.