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!

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.

When am in the MD Editor, looking at a record for an e-resource, I can "View Inventory" to display the portfolios. From that half of the screen, I can view or edit the portfolios. Within that view or edit, I can click on the "Linking" tab and "Test access". If I find that the link has expired and the portfolio needs to be deleted, I want to be able to delete it at this point. But I have to return to the bib. record, release it, exit the editor, click back as many times as it takes to return to the search results display, then click on the "More actions" ellipses, and "Delete" before I can finally delete that portfolio. If there is more than one portfolio, I might assume that they are displayed in the reverse order of the way they appear within the MD Editor, but I verify that--which requires several more clicks. It takes 23 Alma steps to open, view, backtrack, and finally delete an old portfolio.

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.

Presently, only changes made to some fields in an electronic collection record are tracked on the Electronic Collection Record History tab. For example, if I enter text in the Description field on the Electronic Collection Description tab, the History tab shows a "Modification Date" but does not indicate what field was modified. If I change the Access type field on the General tab, the History tab does not record that any change was made.

The usefulness of the History tab is greatly reduced if not all field changes are tracked. It is more difficult to trust the system or to use the History tab for training or auditing purposes (e.g., determining what operator made the change and why).

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/Product_Documentation/010Alma_Online_Help_(English)/040Resource_Management/070Advanced_Tools/010Overlap_Analysis

Thanks in advance.

CR

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

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.