There is currently no mechanism within Alma to ensure that exported or published binary MARC records have valid record structures. Even though Alma uses MARCXML and is not impacted internally by invalid binary MARC, libraries must still provide binary MARC records to external entities in the course of regular business (vendors, outsourcers, agencies, other stakeholders).

Structurally invalid binary MARC records significantly hamper data sharing for libraries. A third party application, MarcEdit, can be used to validate MARC record structure, but since our data is stored in Alma, there should be a mechanism *native to Alma* that validates binary MARC structure prior to export or publishing.

An internal job or process to validate the structure of single or files of binary MARC records should be added so that customers are not reliant on a third party application for this.

There is a known issue of some sites not adhering to the Community Zone (CZ) Contribution Guidelines and Community Catalog Standards.
An example of this is the addition of local 9xx fields to CZ records.
Ex Libris already uses a normalization routine to validate CZ records which are changed by customers.
However, this routine does not specifically prevent the addition of local 9xx fields, even though the guidelines are clear that only changes which benefit the broader community should be made.

Use case:
This has been a longstanding issue, but has been fixable in the Primo Back Office to an extent by using normalization rules.
However, Ex Libris has developed the category tree for Primo Database Search by direct API call to Alma, via an Alma job which runs daily for any unsuppressed database record which has the site’s chosen dbcategory field.
The end result is that categories appear in your category tree which belong to other customers, and we have lost autonomy over our own Primo UI.
This would not be an issue if the category tree was developed to instead use the dbcategory PNX field or if the Alma daily job only published IZ records with the dbcategory field.
In lieu of development which supports customers to maintain the integrity of their UI, Ex Libris should stand behind their Community Catalog standards by adding to the validation routine to prevent all 9xx local fields from being saved to CZ records.

https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/040Resource_Management/040Metadata_Management/110Community_Zone_Contribution_Guidelines

Because all norm rules can be edited by all staff with cataloger roles, there is great room for erroneous changes for rules that are applied to batch jobs. For example, the norm rule that is applied to records being brought in from Z39.50 targets can be edited by any staff member. A single error in the rule can break the z39.50 import process for all staff until the source of the error is identified. Likewise, if we have a rule applied to import profiles and a staff member inadvertently changes it and we load 50,000 records, that could cause huge data corruption. There needs to be a way to secure a norm rule to administrators such that normal staff with cataloger roles cannot change them.

Alma authority control does not handle cases where the bib heading is linked to an authority via a cross-reference, but the preferred and non-preferred terms are in different fields, e.g. preferred term is in authority field 130 and cross-reference in authority is in 410.

Alma should be able to handle this scenario. Currently when the bib heading matches the authority cross-reference, Alma won't correct these and instead puts them on this report: Preferred Term Correction - Bib Heading found no authorized term.

Example bib heading that Alma won't correct:

110/2_ $$a Allied and Associated Powers (1914-1920). $$t Treaties, etc. $$g Germany, $$d 1919 June 28.

The authority record that this heading links to (via its cross-reference)

130/_0 $$a Treaty of Versailles $$d (1919 June 28)
410/2_$$a Allied and Associated Powers (1914-1920). $$t Treaties, etc. $$g Germany, $$d 1919 June 28

The bib heading in 110 links to the authority via the cross-reference in the 410, but because the preferred term in the authority is in 130 (and not 110), Alma will not flip the heading.

When a 655 field is coded for LCSH and matches a non-preferred term in LCGFT, Alma flips the heading to the preferred LCGFT term but does not update the coding (it should change the 2nd ind to 7 and add $2 lcgft).

The problem is limited to cases where:

A bib heading 655/_0 matches a non-preferred term in an LCGFT authority

What happens is:

The PTC job flips the heading to the LCGFT preferred form, but it does not change the 2nd-indicator from 0 to 7, and does not add $2lcgft

What is not a problem:

655/_0 headings that already match preferred LCSH/LCGFT form
655/_7, $2 lcgft (these get controlled appropriately)
655/_7, $2 fast (these get controlled appropriately)
655/_7, $2 any other vocab (these do not get controlled)


Example of the bug:

Before: 655/_0 $a Dissertations, Academic
After: 655/_0 $a Academic theses.

We would like to be able to copy multiple lines from MARC records and paste them into the metadata editor so that multiple MARC fields are pasted into the record in one action. This would help us enormously with our workflow of importing MARC authority records from LibrariesAustralia into Alma.

For us, this is necessary because the LibrariesAustralia headings are not in the community zone and are unlikely to ever be included there and Alma does not allow for Z39.50 import of authority headings.

We have this functionality of copying and pasting multiple fields in the LibrariesAustralia Cataloguing Client and other library systems allow it. At the moment we need to paste each line one by one into Alma and it is slow and repetitive. This process is a step backward from previous functionality.

Here is an enhancement request concerning bibliographic records editing history.

Currently, the "View Versions" can only tell the different version of a bib. record. However, this cannot tell logging history of updating/editing the bib. records, e.g. who add/remove a MARC fields/who suppressed/released the bib. record etc. This is no history tab to keep tracking the changes of a bib. record which is unlike other history tab functionality available in other Alma pages, e.g.

• The PO Line Summary page when editing a PO line
• The Physical Item Editor page when editing item records
• The License Terms Details page when editing license details

It is good to know logging history of updating/editing the bib. record for a record life cycle.

I'd like to suggest to add features that make generating cataloguing statistics easier, e.g.
1. cataloguing date
(We want a date format field that is stored as a local field, independent of the 005 MARC field because every time the record is edited, the date and time details in 005 field will be changed, and often these activities should not be counted as a cataloguing event.)
2. cataloguer details
3. whether this is original cataloguing or copy cataloguing
4. whether this is a cataloguing contribution from Institution Zone to the Network Zone, or vice versa (i.e. copied from the Network Zone to the Institution Zone)

Thanks!
Ian

Currently, the OCLC Number for a record is indexed in the search index "Other System Number." This is not ideal, since the Other System Number indexes other numbers related to vendor record, CONSER, related item, etc.
We request that Ex Libris provide a separate search index for OCLC number based on the presence of the '(OCoLC)' prefix in the 035 $a and/or $z, or (without prefix) in the 019 $a if there is a number in the 035 with an (OCoLC) prefix. Currently these specific (OCoLC) numbers are mixed in with other numbers occurring in the 019, 035, 773, 774, 775 777, 786, 800, 810, 811, 830 $w tags and subfields. Disambiguating these specific (OCoLC) numbers from the "other system numbers" would allow us to use them as unique identifiers. We see the potential for: Improved search Improved matching upon record import Cleaner Excel exports from Alma (we currently have to clean this field every time we export) Creation of a new Analytics field for OCLC number in Alma Analytics Establishment of a model for non-OCLC systems to create other unique search indexes