How are the title matches done? 

Title matching is based on a set of predefined mappings. Each mapping combines several bibliographic elements into a single hash. When two records produce the same hash, they are considered a match.

Here are the mappings for books: 

• External system number + fuzzy title 
• LCCN + brief title + year 
• LCCN + fuzzy title + year 
• LCCN + full title + pagination 
• OCLC + brief title + year 
• OCLC + fuzzy title + year 
• OCLC + full title + pagination 
• ISBN + brief title + date 
• ISBN + fuzzy title + date 
• ISBN + full title + pagination 
• Incorrect ISBN + full title + date 
• Incorrect ISBN + full title + pagination 
• full title + main entry + date + pagination 
• full title + main entry + date + fuzzy pagination 
• Full title + date + publisher + pagination + main entry conditional 
• Full title + date + publisher + fuzzy pagination + main entry conditional 
• Full title + date + pagination + main entry conditional 
• Full title + date + fuzzy pagination + main entry conditional 
• Full title + date + publisher + main entry conditional 

Here are the mappings for journals:  

• Full title (not in common serials list) + External system number 
• LCCN + brief title 
• OCLC + brief title 
• ISSN + brief title 
• Full title (not in common serials list) + place of publication + country of publication + Main entry conditional 
• Full title (not in common serials list) + date + place of publication + main heading conditional + ISSN conditional 
• Full title (not in common serials list)+ date + main entry 
• Full title (can be in list of common titles) + date + main entry + place of publication 
• Fuzzy title (not in list of common titles) + date + main entry + place of publication

You can find the list of common serials here.

Do courses include Alma reading lists, or only Leganto lists?

When determining whether a title appears in a course, the system considers reading lists created in both Alma and Leganto. All active and inactive courses are included in the check; archived courses are excluded.

When limiting the project scope to a specific library, is the usage provided only for that library?

Usage data is always aggregated at the title level across the entire institution. It is not calculated per item or per library.

The institution-wide approach ensures that decisions about retention and deselection are based on the complete usage footprint of a title rather than library-specific variations.

What databases are available for comparison?

Rialto currently supports comparison against HathiTrust holdings. Integration with the Internet Archive is also in progress.

The two HathiTrust comparison databases include:

• HathiTrust U.S. database includes all HathiTrust full-view records, including materials available only to users within the United States and works released under Creative Commons licenses.
• HathiTrust International database includes materials available to users worldwide (including globally available Creative Commons titles) but excludes items restricted to U.S.-based users.

HathiTrust data is harvested through its OAI feed. For details, see the HathiTrust OAI documentation.

How is retention determined?

For books, retention is assessed at the item level. A title is considered retained if at least one item associated with that title has been committed to retention. No additional conditions are required.

For more information on how item-level retention is recorded and managed, see  Retention Information in the Physical Item Editor Page – General Tab table in Working with Items.

Can I create a list of preferred comparison institutions?

You can maintain a reusable set of comparison institutions across projects by using the Clone functionality. You can either:

• Clone an existing project that already contains your preferred institutions
• Create a dedicated template project with the desired institutions and clone it whenever you start a new project

For institutions working within a Network Zone, there is an additional option: selecting the checkbox to include all Institution Zones that have opted in. This option enables you to add all participating IZs at once without having to select them individually.

How are comparisons with other Institution Zones worldwide—potentially located on different servers—performed technically?

Rialto performs cross-institution comparisons by using hash keys rather than sharing catalog records or personal information. Each institution publishes anonymized hash keys for its records to a central location. When another institution initiates a comparison, the system queries this central location to identify matching hash keys across IZs.

If matches are detected, the system then uses a dedicated API to check project-specific criteria (such as whether an item is committed to retention). These APIs are lightweight, limited in scope, and do not affect day-to-day system performance.

How do the workflows distinguish between multiple copies of the same work and a single copy of a work consisting of multiple volumes or parts?

The current workflows intentionally exclude multi-volume monographs by filtering out items that contain the Item Description field (which typically indicates the presence of multiple volumes). These items will be handled in a separate workflow in the future, distinct from journals. In general, multi-volume sets are identified based on the Item Description field.

What determines the Resource Type used in Rialto workflows?

The Resource Type values used in Rialto reflect those assigned by Alma to the bibliographic record. Alma determines these values based on MARC metadata and internal normalization rules. For more information, see The Resource Type Field in the Alma documentation.

What data is shared as part of the Collection Analysis and Development data sharing profile, and how is privacy protected?

The Collection Analysis and Development data sharing profile enables collaborative collection development while maintaining strict boundaries around privacy and data sensitivity. Selected bibliographic, holdings, and discoverable item-level metadata, together with aggregated and anonymized usage indicators, are used to support analysis, benchmarking, reporting, and recommendations. No personal data, user information, transaction-level usage, internal notes, item-level circulation history, or suppressed records are ever shared. Any future changes to the scope of shared data would be clearly communicated to customers.

The data shared as part of collaborative collection development does not include transaction-level or personally identifiable information.

Aggregated usage indicators (such as loans and lending/digitization requests) may be used to support collection development analysis, benchmarking, and recommendations.

Usage data is:

• Aggregated and anonymized
• Reported at a high level suitable for analysis, not at the level of individual transactions
• Associated with titles / bibliographic entities, not individual users, items, or transactions

No data about individual users is shared.

User identities, user groups, and any personal or demographic information are completely excluded.

Usage is used in aggregated yearly form to support analysis and reporting. Fine-grained temporal breakdowns (e.g., per day, per user session) are not shared with other institutions.

Holdings and records are not directly visible to other institutions.

Instead, the shared dataset consists of selected bibliographic and holdings metadata that support collaborative analysis, such as:

• Title, author, and imprint information
• Classification numbers and subject metadata
• Indicators that a given library or location holds a title
• Discoverable item-level metadata

The following are not shared:

• Internal notes or local fields (e.g., bibliographic 5XX notes, item notes, internal holdings notes)
• Any suppressed records - records suppressed in Alma remain suppressed in these workflows, just as they are in discovery.
• Any personal or patron-related data

Ex Libris uses the shared data only for collection development purposes, including generating recommendations, facilitating collaborative workflows, benchmarking, and producing reports for participating institutions. It is not used for any purpose outside these workflows, and it is not shared with third parties.

What is the process for matching electronic book records to physical bibliographic records in collection development workflows?

The system matches electronic book records to physical book records in two stages: finding potential matches and validating those matches.

The system searches for electronic book records that meet at least one of the following criteria relative to a physical book record:

• The electronic record contains one of the ISBNs found on the physical record (including ISBNs in 77X fields)
• The electronic record has the same full title as the physical record (exact match)
• The electronic record is linked to the physical format through an Additional physical form relationship

A potential match is considered valid if it meets all of the following conditions:

• The electronic record is of type Book
• The publication year matches the physical record
• The edition matches the physical record

Additional validation rules apply in some cases:

• If the match is based on title and the title contains three words or fewer, the system also requires at least one matching author name between the physical and electronic records
• If required values (such as publication year, edition, or author) cannot be extracted from one or both records—because they are missing or in an unsupported format—the system does not reject the match based on that validation

• If a publication date appears as a range, the system checks whether the publication dates of the physical and electronic records overlap
• Hebrew publication dates are supported; if both records contain a Hebrew date, those dates are compared during validation

When validating authorship, the system:

• Compares first and last names only, ignoring middle or additional names
• Ignores titles such as Dr., Prof., and similar prefixes
• Checks both the main and the additional author fields

How does Rialto determine whether an electronic match has perpetual access?

An electronic match is considered to have perpetual access if at least one of its associated portfolios provides perpetual access. Rialto determines whether a portfolio has perpetual access by evaluating portfolio and collection data in the following order:

• Portfolio access type — If the portfolio’s Access Type is set to Perpetual, the portfolio is considered to have perpetual access.
• Collection access type — If no access type is defined at the portfolio level, Rialto checks the Access Type at the collection level. If it is set to Perpetual, the portfolio is considered to have perpetual access.
• Purchase model — If neither the portfolio nor the collection defines perpetual access, Rialto evaluates the purchase model. Portfolios with an owned purchase model are considered to have perpetual access.

How can I apply item-level retention based on retention information in my holdings MARC records?

If your holdings records contain retention information (for example, a MARC 583$a action note), you can apply item-level retention in Alma by using the Change Physical Item Information job.

First, you need to create a set (for details, see Creating Itemized Sets). You can create the set in one of the following ways:

• In Alma, use advanced search to identify holdings that include a MARC 583$a action note and create a holdings-level set.
• In Collection Development, create a retention project and use Additional Fields to identify items based on the holdings action note, then generate a recommendations list as part of the workflow.

After creating the set: 

1. Go to Admin > Manage Jobs and Sets > Run a Job.
2. Select Change Physical Item Information (under the Information Update job type) and select Next.
3. Select the set you created and select Next.
4. In the Change retention information section:
   • Set Set item committed to retain to to Yes and enable the option by selecting its checkbox.
   • (Optional) Select a Retention reason and specify conditions if required. Enable the option by selecting its checkbox.
   • (Optional) Enter a Retention note and specify conditions if required. Enable the option by selecting its checkbox.
5. Select Next, review the job details, and select Submit. Confirm the action if prompted.

When the job completes, all items in the selected set are marked as Committed to Retain. Any retention reason and retention note specified in the job are also applied.