Flexible and normalized comparison of portfolio coverage dates in Overlap & Collection Analysis
Currently, Overlap & Collection Analysis compares portfolio coverage dates exactly as they appear in the portfolio coverage fields. As a result, equivalent coverage ranges are not always recognized as matches when the dates are recorded at different levels of detail or when some components are missing.
For example, coverage such as:
• 2.1.2016, Volume 1 Issue 1
and
• 2016, Volume 1 Issue 1
may represent the same start point, but the system treats them as different because one includes a full date while the other includes only a year.
In many knowledge bases and vendor data, coverage dates are inconsistently populated — sometimes year only, sometimes year and month, and sometimes full dates. This leads to inaccurate or misleading overlap results.
Proposed enhancement:
Enable configurable comparison granularity, allowing institutions to choose the precision used for matching, for example:
• Year only
• Year + month
• Full date (year + month + day)
This would allow comparisons to succeed even when some date components are not populated, and would let each library select the level of precision that best fits its collection analysis needs.
Expected benefit:
This will:
• Improve matching accuracy in overlap analysis
• Reduce false mismatches caused by different levels of date detail or missing components
• Provide more reliable overlap calculations across vendors and knowledge bases
• Support better collection management decisions (e.g., which collections to activate or deactivate)
• Minimize manual normalization and data cleanup
Merav Aknin
shared this idea
-
Hi Merav,
Thank you for submitting this idea!
I'd like to better understand the proposed solution.
Do you envision this as a configuration option within the Overlap job, or as an institution-level setting?
In addition, I'm wondering whether this should be configurable at all. Would it make more sense for Alma to always normalize partial dates? For example, treating 2026 as equivalent to 01/01/2026, while recognizing that it only partially overlaps with a date such as 01/11/2026.
I'd love to hear your thoughts on this, as well as input from others who may have experience with similar scenarios.
Thanks,
Tamar Fuchs
Alma Product Team
