Skip to main content
ExLibris
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    Electronic Resource Handling in Alma Migration (P2E)

    One of Alma’s goals is unification. In order to achieve unification during migration from various source systems of different source data types, a certain amount of identification and re-categorization of ILS-originated records that are not actually physical in nature needs to be performed.  In Alma Migration, this is called Physical to Electronic, or P2E for short.
    Additionally, SFX, 360Link, and other link resolver systems provide a significant amount of electronic resource information (targets, objects/object portfolios, and services) and valuable linking and package-relationship information that are not likely to be represented in the ILS system, the combination of which may lead to some duplication in Alma.
    Further, digital resources may be owned or managed by the institution, but are represented in the ILS as if they are electronic resources, which may lead to some duplication in Primo and possibly Alma.
    Finally, 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 SFX or other 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.
    The purpose of this document is to explain the following:
    • How ILS-managed electronic resources are identified and converted to electronic inventory during Alma migration, referred to as Physical to Electronic, or P2E (standard offering)
    • Which functions in Alma and Primo identify potential duplication between SFX or other link resolver systems, ILS-derived electronic resources, and digital repositories such that this potential situation is manageable, correctable, and does not negatively affect the end-user discovery experience (standard offering) 
    • How ERM-managed data fits into the migration approach (dependent on the scope of work with Ex Libris – not standard offering)
    Ex Libris migrates your acquisitions data only if this service was purchased by your institution and is stipulated in your contract with Ex Libris.

    P2E: Electronic Resource Identification and Preparation

    Most legacy ILS systems have a single format for resources. Physical and electronic resources are stored using the exact same data structures – bibliographic, holding, and item records. In Alma, electronic resources have a different database structure than physical resources. In order for the migration programs to change physical resources into electronic resources, you have to indicate which resources to change from physical to electronic (P2E).
    Electronic resource identification and classification is achieved by:
    • You provide an input file to Ex Libris with the relevant ILS BIB numbers representing electronic resources and their types (portfolio, package, or database).  
    • You provide input in the migration form regarding the libraries and/or locations that represent electronic inventory in order to allow sub-identification (for cases where there is physical and electronic material linked to the same BIB) based on the BIB input file received.
      The format for P2E and migration form input is described in the Alma Migration Guides for your source ILS.
    • The converted electronic resource may contain linking information, sometimes more than one link field source, usually populated and typically based on the originating holding record’s 856 |u field or fields or the originating BIB record’s 856 |u field or fields. Each linked field will become a separate electronic record in Alma.
    • The migration programs create at least one electronic resource for each unsuppressed BIB identifier in the p2e file.  If no holdings/items are present or if all holdings/items are not marked as electronic, the migration program creates an electronic resource based on information in the bibliographic record only.
    • Typically a linking note is associated with the public/general note based on the 856 |z if it exists in the source holding or bibliographic record.
    • You can optionally provide input as to which metadata field in the BIB (or its holdings) record denoted in the input file represents the name of the electronic provider/vendor name, in your Migration Form at the bottom of the Questionnaire tab.
    For each of the three source fields noted above: Only one field/subfield source is allowed across all electronic records.  Only the first instance of the subfield within a field is used.
     
    Ex Libris’ migration processing categorizes input correctly as electronic inventory in Alma (portfolio, database, or package) with the relevant vendor provider association.  None of the e-resources is assigned a service.  The p2e process also sets each electronic record’s associated order, if present, as electronic type order rather than physical type order.
    For example:
    If the migration form indicates the following (see the bullets below), migration processing checks whether each BIB provided in the P2E list has any items in the following Library:Location pattern: ONLINE:ELECT. If it does, each item matched with this pattern is designated for conversion to the relevant e-type indicated (Portfolio, Package, or DB):
    • The ONLINE library and ELECT location in the ONLINE library are electronic
    • 856 |u is the source for the URL
    • 856 |z is the optional source for the electronic public note
    • 940 |a is the optional source for the vendor name
    For cases of portfolios, the output is always a standalone portfolio (see below for more information about portfolios that are part of packages and their handling), with the linking information from the Holding 856 |u or BIB 856 |u if the holdings record does not have an 856 |u. As noted above, if there are multiple URLs at the level the linking source field is found (Holding or Bib) – each link field results in an e-inventory record. If URLs are found at the holding level, only they are used, and the bib level URLs are left in the bib.
    The migration form indicates that the vendor/provider is stored in the 940 |a field which results in e-inventory records in Alma populated with this vendor/provider information.
    If all of the BIB’s items are identified with the above pattern (and thus deleted), the remnant holdings with no more item records is also deleted. This check ensures that physical and electronic records referencing the same BIB are treated independently of one another in case they were managed together.
    If there are no items matched to this Library:Location or no items exist at all for this BIB ID, Alma processing moves on to the bibliographic records holdings and checks each holding 852 $b and $c against the Library:Location pattern.  A match for each holdings record is converted to a portfolio with the relevant URL, note, and vendor name population. 
    If no match or no holdings exists with this pattern, the BIB level is set for conversion. In this case, the BIB is left in place, a new e-inventory record is created with the relevant URL, note, and vendor name population.
    How many e-resources are generated?

    If the bib listed in the p2e file is suppressed, then no e-resources are generated.

    If the bib listed in the p2e file has no electronic inventory, either because there is no inventory at all or because the inventory present is not in an electronic location, then an e-resource is generated based on information in the bib only.  In this case, it appears that the e-resource is generated out of nothing.   Note: if there are multiple 856s on a single bib, multiple e-resources could be generated, see Multiple providers/links on the same bib, below.

    If the bib listed in the p2e file has inventory in an electronic location, then an e-resource is generated for each one found.  If there are three items in an electronic location, then three e-resources are generated.  The inventory is removed during the p2e process.  In this case, it appears that the inventory is transformed from physical to electronic. Note:  more than one e-resource could be generated for each inventory found if multiple 856s are on the same bib, see Multiple providers/links on the same bib below.

    Multiple providers/links on the same bib
    There may be cases where there are multiple providers for the same bibliographic resource.  This may happen, for example, if a journal is available from multiple packages subscribed to by the institution. 
    If all of the linking information (typically in 856 tags) is provided in the bibliographic record, and there is a source inventory record for each provider/link, then the p2e program is not able to determine which linking information matches which source inventory record.    In other words, we don't know which 856 matches which inventory.  In this case, the p2e program generates an e-inventory record for each item *and* each 856 tag found.
    As an example, a bib record with the following 856 tags will have three e-inventory records created for each incoming inventory record.  If there are multiple inventory records on the bib identified by the P2E program, for example two holding records both in an electronic location, then the above tags, if they are all on the bib record, will result in six resources created for this bib. 
    856    41 |u http://accesslink.edu/1 |3 Emerald |z Campus connection required
    856    41 |u http://accesslink.edu/2 |3 LexisNexis |z  Campus connection required
    856    41 |u  http://accesslink.edu/3 |3 Swets |z (1992)- (No full text for latest year)
    This situation is likely to be more common where libraries are managing multiple e-accesses for the same resource at the Bib-field level rather than associating e-access information separately at the holdings level. 
    To avoid this situation, customers may do one of the following: 
    •  provide the 856 information in the holding record which will be transformed to the e-inventory record.  In this case, the inventory record can be directly linked with the 856 in the holding.  If there are three holding records, with the 856s in the individual holding records, then only three e-inventory records will be created, and the 856 information will be taken from the holding record. 
    •  if all e-inventory is in the same location, leave all 856s in the bib and provide only one incoming inventory record
    Multiple fields which contain linking information
    Sometimes an institution may manage multiple e-accesses at the bib-field level using multiple fields.  For example, there may be tags such as the following for three separate providers, where the notes and providers are not matched to the linking information:
    856    41 |u http://accesslink.edu/1
    856    41 |u http://accesslink.edu/2
    856    41 |u  http://accesslink.edu/3
    856    41  |3 Emerald |z Campus connection required
    856    41  |3 LexisNexis |z Campus connection required
    856    41 |3 Swets |z (1992)- (No full text for latest year)
    The above case will result in the same note and provider being applied to all resources created for this bib.  The non-matched notes are applied to *each* resource created.  In order to avoid all notes being copies to each e-inventory record created, provide all of the linking information in the same field.  Alternately, ensure the provider (here subfield $3) is provided in both fields, in which case the fields can be matched.
    Material Types

    When the electronic resource is generated from an item, the electronic material type is derived from the item’s material type. When the electronic resource is generated from a bibliographic or holdings record, the material type is generated by consulting the LDR of the bibliographic or holdings record. First, the Alma physical bibliographic material type is determined based on the Fields that Identify the Bibliographic Material Type table on the Searching in the Repository page. Then, that value is mapped to the E-Material type based on the following mapping by the P2E process:

    Print material type

    Electronic material type

    ARTORIG

    OTHERVM

    ARTREPRO

    OTHERVM

    AUDIOCASSETTE

    RECORD

    BOOK

    BOOK

    CALC

    OTHERVM

    CD

    CDROM

    CDROM

    CDROM

    CHARG

    OTHERVM

    CHART

    OTHERVM

    DATABASE

    DATABASE

    DIORAMA

    OTHERVM

    DISK

    OTHERVM

    DISSERTATION

    DISSERTATION

    DVD

    VIDEO

    DVDRM

    VIDEO

    FICHE

    OTHERVM

    FILM

    OTHERVM

    FILMREEL

    VIDEO

    FILMSTRIP

    OTHERVM

    FLASHCARD

    OTHERVM

    FLIPV

    OTHERVM

    FSADT

    OTHERVM

    GAME

    OTHERVM

    GRAPHIC

    OTHERVM

    HEAD

    OTHERVM

    IPAD

    OTHERVM

    ISSBD

    JOURNAL

    ISSUE

    JOURNAL

    JOURNAL

    JOURNAL

    KIT

    OTHERVM

    LPTOP

    OTHERVM

    LRDSC

    VIDEO

    MANUSCRIPT

    MANUSCRIPT

    MAP

    MAP

    MASTERTHESIS

    DISSERTATION

    MICROFORM

    OTHERVM

    MICROSLIDE

    OTHERVM

    MODEL

    OTHERVM

    OTHER

    OTHERVM

    PHDTHESIS

    DISSERTATION

    PICTURE

    OTHERVM

    PLAYAWAY

    OTHERVM

    REALIA

    OTHERVM

    RECORD

    RECORD

    SCORE

    SCORE

    SLIDE

    OTHERVM

    TECHDRAWING

    OTHERVM

    TOY

    OTHERVM

    TRANSPARENCY

    OTHERVM

    VIDEOCASSETTE

    VIDEO

    VIDEODISC

    VIDEO

    VRECORD

    VIDEO

    The logic for DB and package is very similar to that of portfolios, except that in these cases, the inventory type output and related order types are a different type, since Alma databases and packages (e-collections) and their orders have different functional behavior than portfolios/standalones. 
    Orders
    After the inventory level for the resource is identified, the system then checks whether a purchase order is associated with the inventory record. If it is, the system converts it to a matching electronic type order. 
    Alma allows one order per inventory record. When more than one e-order is identified for a particular record, migration processing will prefer an open and recent order first, in an electronic location. Other orders will relate to the e-order, but may remain categorized as physical.The most recent open purchase order associated with this bibliographic record becomes electronic as well.
    The following criteria are used to determine the best order:
     - attached at the identified inventory level (item, holding) 
     - in an electronic location preferred - if none found, will use orders in a non-electronic location
     - if none found, will move up to bib level orders
     - when multiple orders found within a given level/location (holding/item or bib), then the best order is selected based on status, and if multiples are in the same status, then the send date and approval dates are checked (most recent preferred)
    The following are the analogous e-order types for the input Physical order types and e-inventory types defined in the P2E input. As mentioned above, Alma migration identifies only one order to be transformed to electronic with each physical resource.   
    The following table shows the map of physical order types to the electronic order type.
    P Order Type E Inventory E Order type
    Print * One Time Portfolio Electronic * One Time
    Print * One Time E-Collection (Package and Database) E-Collection * One Time
    Print * Subscription Portfolio Electronic * Subscription
    Print * Subscription E-Collection (Package and Database) E-Collection * Subscription
    Print * Standing Order Portfolio Electronic * Standing Order
    Print * Standing Order E-Collection (Package and Database) E-collection * Subscription
    The 'Other Services' Purchase Order type is not listed here because it should only be used on non-inventory orders, and by definition an order with electronic inventory has inventory.
     

    P2E Illustrated Examples

    Here are some illustrated examples of P2E processing:
    1. Two holdings, one is electronic
    P2E functionality: Holding with Electronic Location will be identified as the entity to convert to electronic.  Electronic portfolio will be generated and that holding record will be deleted.  856 from the Holding with Electronic location will be used.  856 from Bib A will not be used because we already found an 856 in the identified holding record. HOL with Physical location will be ignored/migrated as is.
    2. Two holdings, one is electronic, and the electronic holding does not have an 856 but the bib does
    P2E Functionality: Holding with Electronic Location will be identified as the entity to convert to electronic.  Electronic portfolio will be generated and that holding record will be deleted. There is no 856 in the identified holding record, so 856 from Bib record will be used. HOL with Physical location will be ignored/migrated as is.
    1. One physical holding
    P2E functionality: No holding record is identified as electronic. Electronic portfolio will be generated based on the bibliographic record only. This will appear as if an electronic record is being ‘generated’. 856 from bib record will be used. HOL with Physical location will be ignored/migrated as is.

    ILS Electronic Records Duplicated from LR System – MARCIt or 360MARC

    In many cases, the MARCIt service is used to duplicate SFX serial records in ILS systems – usually for discovery purposes. Since Alma intends to store both physical and electronic in one system, it is important to note that the default migration pattern is to eliminate MARCIt records (MARCIt records are identified by the existence of the text SFX in a Bib record’s 035 |a field) and presume that the CONSER–enriched SFX records will serve as the master going forward – both for management purposes and for discovery purposes. In addition to MARCIt records, it is possible to designate a different text in 035 |a to be considered during migration for the same handling as with MARCIt records. 360MARC is a similar service for 360 Link customers to import bibliographic records to their ILS. The text used in the 035 to distinguish the records is WaSeSS.
    Two exceptions to the above case are the following:
    • 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 such cases, the MARCIt record is transferred to Alma as a suppressed record to retain data integrity.
    In both of the above exceptional cases, a duplicate SFX, 360Link, or other link resolver system record also migrates to Alma and results in duplication in the back-office management.
    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.

    ILS Electronic Records Other Than MARCIt

    Electronic records in the ILS that are not MARCIt records generally fit into two main categories:
    • Records that do not exist in SFX or other link resolver systems (generally e-books not in packages, databases, government documents, and so forth). In such cases, there should be no duplication.
    • Records that do exist in SFX or other link resolver systems (serials, packages, e-books in packages, and so forth and are not MARCIt (or not identifiable via a 035 |a string similar to MARCIt records), or are MARCIt, but have order associations). These records are going to initially be duplicated in Alma.
    It is important to note that the package relationships to portfolios are generally not maintained in ILS systems and the electronic version, when migrated from the ILS system, does not have the parent-child package/portfolio relationship when initially transferred to Alma. Therefore, the following is true initially, following migration:
    • Package/portfolio relationship information is reflected from SFX or other link resolver systems and not from the ILS e-records, which are created by the P2E process.
    • ILS electronic record versions have order associations (if orders exist) and not SFX or other link resolver system versions.
    • 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-identified packages are more likely to be duplicated initially with SFX or other link resolver system originated target/packages in the Alma back-office, since MARCIt records are not used for packages and packages often have order associations.
    • ILS portfolios identified become standalone portfolios in Alma – at least initially – with no relationship to any package.
      This case will be duplicated with SFX or other link resolver systems only when an SFX or other link resolver system version also exists. In this case, the name “standalone” will be a misnomer from the Alma back-office. See Managing Duplication in Alma below.
      In many cases, no SFX or other 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.
    • SFX 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 SFX or other link resolver system equivalents are the back-office acquisitions master only.
    • ILS electronic versions without SFX or other 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.

    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.

    ERM Overlay

    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.

    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).
    • 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.

    Troubleshooting

    Q: Why a package is not active after P2E?

    A: Check for the following:

    1. Package have a URL added to the "Electronic Collection Level URL" - If there is no URL the package will be marked as not active
    2. Package "Additional descriptive information" is linked to a BIB - If there is not BIB, the package will be marked as not active
    3. The BIB is not suppressed from publication - If the BIB is suppressed, the package will be marked as not active
    • Was this article helpful?