Alma is a unified resource management system, meaning that all types of records like physical, electronic, and digital are managed in the same system. Prior to migrating to Alma, institutions may have managed the different types of records in a variety of different places, and in some cases managed the same resource in multiple places.
This document describes various inputs for electronic resources.
- the different types of electronic resource records that are expected
- how those resources may be duplicated
- how to decide which version of a resource to migrate
- if necessary, how to manage duplication in Alma post-go live
Sources for Electronic Resource records
Generally, electronic resource records may come from any one of the following sources:
ILS: Resources from your ILS which appear to be physical, but actually represent electronic resources. During migration, all resources which come from an ILS are migrated as physical, but some of them, which you identify, can be re-categorized as electronic. In Alma Migration, this is called Physical to Electronic, or P2E for short.
SFX or 360Link: Resources from a link resolver system which is supported by migration, which currently include SFX and 360Link. Link resolver information from these two systems are exported, processed, and the relevant resource is activated in Alma.
Other link resolver: Resources from a link resolver system which is not currently supported by migration. In this case, customers may provide information in the E-Activation Worksheet (an Excel spreadsheet) which will then be loaded into Alma. Information in the spreadsheet will be used to activate packages, portfolios, or databases, along with title information for Selective packages.
Digital Resources: The library may own or manage digital resources, which may be managed/stored separate from the ILS, or they may be represented in the ILS. If resources are represented in the ILS for discovery purposes and also managed separately, this may lead to some duplication in Primo and possibly Alma, depending on migration decisions.
Electronic Resource Management (ERM) systems: ERM systems usually work in conjunction with a link resolver system, such as Verde and SFX, or 360RM/Intota and 360Link. The ERM system manages information associated with the electronic resource, such as licenses and vendor interfaces.
PQIS resource activations: After all electronic resources are loaded by the migration team, we run an activation process which checks that purchased ProQuest resources are activated in Alma. The Migration team uses the customer's PQIS ID. Customer may request to not activate these for cutover.
EBook Central: Owned, DDA, and Subscription integration will be set during test load for EBook Central customers, starting with testloads beginning after September 2020. The migration team uses the customer's EBC ID (Ebook Central ID), and the Ebook Central integration profile should be set up on the ProQuest side. After this is set up, it runs every day to update the packages in Alma. Customer may request to not activate these for cutover. By default, Ebook central activations are not migrated with SFX nor 360Link, and are not included in the E-Resource Activation Sheet.
Provider Zone records: Ex Libris is partnering with content providers so that the providers can maintain the bib records for their own resources. As part of this process, specifically in track two, there are two bibliographic records for each resource. Information about the Provider Zone is available at this link: https://knowledge.exlibrisgroup.com/Alma/Content_Corner/Supporting_Resources/Provider_Zone_Documentation.
ILS Electronic Records Duplicated in Link Resolver or Other System
In many cases, institutions create a duplicate representation of their electronic resources in the ILS. Both SFX and 360Link provide a mechanism to load bibliographic records to the ILS. In SFX, this is called MARCIt, and in 360Link it is called 360MARC. Other link resolvers may have similar mechanisms. Additionally, there are other types of resources where the resource is available in an external system and is duplicated in the ILS, such as E-book collections. If you will activate your e-book collections in Alma directly from the source, and you also have ILS records for these e-books, then you will want to consider eliminating these ILS records during migration.
Usually the duplication of resources is for discovery purposes, when the ILS is used as the main discovery platform for the institution. However there may be other reasons, such as ordering and invoicing. In any case, if a customer migrates these resources from both the ILS and the link resolver system, there will be duplicate resources in Alma.
The default migration recommendation is to eliminate the duplication from the ILS migration, in favor of the activations from the source - SFX/360Link/LR/e-book vendor, etc. The primary reason this is the recommendation is that P2E creates local activations only. There is no way to link a P2E-derived electronic resource to the associated Community Zone/Knowledge Base entry. Using the resources that are migrated from SFX, 360Link, or E-Resource Activation sheet will ensure that the resources are linked to the CZ master record and will be updated by the KB team on a regular basis going forward.
Customers may be able to not export bibliographic records which represent duplication during the export process. That is, instead of exporting all bibliographic records from the ILS, you can export everything except these resources which represent duplications.
If a customer is unable to limit the export, they may use the SFX_PREFIX question on the migration form for their particular ILS. Every ILS has this question on the Questionnaire tab. Even though the question is called SFX_PREFIX, it is used to skip bibliographic records with certain strings in the 035. For example, when MARCIt records are imported to the ILS, they have an 035 $awith an internal SFX number, and it usually looks like: (SFX)1234567. Therefore, a typical response to the SFX_PREFIX question is '(SFX)', which means that any record where there is the string '(SFX)' in the 035 $a will be skipped. The text used in the 035 to distinguish 360MARC records is WaSeSS. Multiple strings can be used in the SFX_PREFIX question in the Voyager migration only.
There are two cases where even if the string is found in the bib record, the record is NOT skipped:
- Bibs that have inventory as well. In such cases, the record must be brought as is so as not to lose the inventory.
- MARCIt or equivalently marked records that have ILS orders linked to them.
In both cases, the bib record is transferred to Alma as a suppressed record so that the physical inventory or order information can be migrated also. In these cases, a duplicate SFX, 360Link, or other link resolver system record also migrates to Alma and results in duplication - once from the ILS and once from the Link Resolver. Typically what customers do is manually combine the information on the suppressed bib record with the CZ-activated record post-golive.
Discovery should not be affected by back-office duplication of this type, due to various safe-guards and Primo functionality. For more information, see Managing Duplication in Alma below.
Currently, in Voyager migration, there is an option to include or not include suppressed records in the p2e process with the question P2E_SUPP_BIB. if you answer the question 'Include suppressed bib records in the p2e processing' as No, then the suppressed bib record above will not be included in p2e processing, and therefore no e-resource will be generated for that bib, and the order will remain physical. If you answer the question 'Include suppressed bib records in the p2e processing' as yes, then an e-resource will be generated, the associated order will be transformed to electronic, and you will have duplicate e-resources to manage: one CZ-linked package from 360 or SFX, and one local database/package (non-CZ linked) from the p2e process. For assistance on managing duplications like this, see the "Managing Duplication in Alma" section below.
Package and Portfolio relationships
It is important to note that the package relationships to portfolios are generally not maintained in ILS systems. When an ILS records is sent through P2E, it does not have the parent-child package/portfolio relationship when initially transferred to Alma. Therefore, when deciding whether to keep an ILS record or a link resolver version of the record, the following is true, following migration:
- Package/portfolio relationship information is reflected in records that came from link resolver systems and not from the ILS e-records, which are created by the P2E process.
- ILS electronic record versions typically have order associations (if orders exist) and link resolver system versions do not have orders.
- Identified ILS packages become packages in Alma, but are unrelated to their portfolio constituents. (Packages are also referred to as “Electronic Collections” in Alma. These types of Electronic Collections are typically suppressed and not published to Primo.)
- ILS portfolios identified become standalone portfolios in Alma – at least initially – with no relationship to any package. In many cases, no link resolver system equivalent portfolio exists. In such cases, there should be no issue of duplication and the ILS standalone portfolio will remain as the back-office and delivery master.
- ILS databases identified become databases in Alma. Databases are a type of “Electronic Collection,” and are more likely to be published to Primo and have ViewIt/delivery linking information.
- Link Resolver electronic versions always contain package structure and linking information, and will be the master for structure and linking when analogous records for these resources arrive from the ILS.
- ILS electronic versions that have link resolver system equivalents are the back-office acquisitions master only.
- ILS electronic versions without link resolver system equivalents are the linking delivery master and back-office acquisitions master.
If the ILS has bibliographic records for individual portfolios that are part of a larger package, it is recommended to start managing these resources at the package level in Alma, rather than the portfolio level. Post-migration, you can associate the standalone portfolios that were created as a result of the p2e process with the package (local e-collection) in Alma. The advantages of managing resources at the package level are that any information about the package that changes will affect all resources, such as license and access information. You need only manage this information once at the package level instead of multiple times at the portfolio level. For more information about associating licenses with packages, see ERM Overlay below.
Managing Duplication in Alma
Since most MARCIt records and marked equivalents are not be migrated from your ILS (unless holdings and/or items and/or order information is associated, as described above), much of the SFX or other link resolver system-ILS duplication for serial records is eliminated.
However, inevitably, when moving from a multi-system environment to a uniform and consolidated environment, some duplicates remain.
Ex Libris does not automatically de-duplicate remaining electronic inventory identified from the ILS system with SFX or other link resolver system counterparts. The main limitations of this de-duplication are due to the fact that:
- Typically source ILS systems do not have enough consistent information in the e-records to determine specific package associations for the e-titles.
- There are a variety of cases where enriched vendor BIB records have been purchased and may not be desirable to de-duplicate.
Instead, the following approach, which involves ViewIt delivery logic and tools in Alma to allow phase-out/management of the duplicates, has been adopted.
- Primo and Alma logic focuses on best ensuring the end-user discovery experience is not affected by any back-office duplication. This is achieved by preferring link resolver and community zone versions of resources for ViewIt linking over an ILS version of the same resource, and leveraging Primo’s robust de-duplication algorithm to further ensure a single result for resources being discovered via Primo.
- Ensure that there is no data loss by making sure that the relevant order/back-office information managed in the ILS remains. As noted, this results in the SFX or other link resolver system version as the master for linking/delivery/discovery and the ILS version as the back-office tracking and management master.
- Alma functions exist for ongoing purposes that allow optional Alma back-office cleanup. This currently includes the ability to:
- Identify the P2E records and build them into sets.
Common ways of identifying P2E-created inventory which may be candidates for suppression or removal:
- Gathering the e-journal portfolios which may not have been marked for exclusion from the ILS:
By Performing an Alma advanced search for:Electronic portfolio where All titles (Tag Suppressed equals "No" and Originating System contains keywords "ILS”) and Electronic Portfolio (Is Standalone equals "Yes" and Material Type equals "Journal").These are likely to be, but are not necessarily, duplicates with a better quality link-resolver system version of the e-resource and can be reviewed and potentially batch deleted or suppressed within Alma.
- Repeating the above for suppressed e-journal duplicate candidates (e.g. changing Tag Suppressed equals “Yes”) that may have been identified for exclusion, but due to other factors such as being linked to an order, are still migrated to Alma.
- Gathering e-collections with electronic type = Package which migrated via P2E which are more often than not simply a placeholder record to link to orders.
By Performing Alma advanced search for:Electronic Collections where All titles (Originating System contains keywords "ILS") and Electronic Collection (Electronic collection Type equals "Selective package").The above 3 cases are the most likely results that can be considered for clean-up consolidation post go-live. Some common actions that may be taken for them:Remove order or license linkages from the duplicate e-inventory record (usually the ILS electronic record would be considered duplicate if an SFX or other link resolver system equivalent also exists for the resource).
- Identify the P2E records and build them into sets.
- Re-link any information (orders, licenses, Bib) to the “master” link resolver/CZ inventory record and deleting/suppressing the duplicate version:
- Editing the e-resource via editor and find the appropriate e-order and/or license with which to associate the inventory record and populating the PO line ID field and/or license field (for e-collections/packages this is from the General tab and for portfolios from the Portfolio Information tab)
- Finding the PO line via the PO line search and using the “Change Bib Reference” function to associate the order with the e-inventory record’s BIB record.
- Delete the order/license relationship via the e-inventory editor of the extraneous duplicate inventory record.
- Delete the duplicate e-inventory resource.
At this point, only the master version remains as the full management, linking, and structural master of the resource in Alma.
Even if you do not want to delete the records you may still want to suppress the record from discovery. Via set building, the Suppress Bib records from discovery job can be run in order to batch suppress the relevant records.
In cases where ERM system data is included, dependent on the scope of work with Ex Libris, it needs to be added or overlaid such that the appropriate resources are identified. Links from a migrated ERM system require an identifier – such as OrderId, SFXid or other link resolver system ID, and/or ILSBibId – that can link to the relevant resource and update it with the ERM-stored electronic resource-specific information.
It is expected that all e-resources managed in the ERM are reflected already in some way in the ILS and/or link resolver systems (in some cases, perhaps only as a suppressed bibliographic record). In addition, it is expected that all e-orders managed in the ERM are reflected in the ILS system.
Ex Libris migrates your acquisitions data only if this service was purchased by your institution and is stipulated in your contract with Ex Libris.
Identify e-resources for ERM enrichment (when relevant, based on your scope agreement with Ex Libris). Depending on your ERM system, the main match point may be with the Alma CZ via SFXid/Alma KB id, and/or with information loaded from the ILS (OrderId or BibId). In either case, the incoming ERM information is loaded by matching to the ERM reference in Alma.
ERM information includes:
- Licenses and their associations
- Interface/vendors and their associations, including localized access/admin information
- Enriching e-resources with key, localized e-inventory information
- Enriching related ILS order information with key acquisition record field information, such as subscription dates, renewal dates, vendor reference number, and order relationships and repeatable notes.
ERM enrichment is recommended primarily for individual portfolios that are not part of any package, and for packages. It is not recommend for portfolios that are managed as part of an e-collection or package.
For more information on migrating ERM resources into Alma, see ERM to Alma Data Delivery Specification.
Digital Repository Records and P2E
In general, digital repository records that are owned and/or managed by the institution in a digital management system should NOT be included in the P2E process from the ILS.
For example, a library can create bibliographic records in their ILS for a locally-owned digital resource and include an 856 link to the repository object. This appears to be an electronic resource in the ILS because of the 856 link, but the digital object will most likely be included in a pipe to Primo. If the bibliographic record from the ILS is included in P2E, this will result in duplication in Primo.
If the digital resources that are on a bibliographic record contain item or holding records, they should be withheld from migration or deleted in Alma immediately after migration to avoid having them be false “P” or “E” in Alma.
Digital inventory can be integrated with Alma using standard Alma tools following go-live.
Usage statistics (SUSHI)
Ex Libris migrates usage statistics from two places: USTAT (Aleph) and COUNTER (360). Configuration of SUSHI is not included in migration; SUSHI is configured on the vendor record. Since vendors are loaded once at testload and then not loaded again for cutover, any SUSHI configuration made on the vendor is retained during cutover.