1

Migration of Physical to Electronic (P2E) Resources in Alma

2

Overview

Legacy ILS’s had one structure for storing and handling resources – the physical resource

Electronic resources were added as physical because older ILS’s weren’t intended to handle anything else. Each institution managed their electronic resources in whatever way they chose.

In Alma, a physical resource is quite different from an electronic resource and the workflows and structures are not the same

Alma determines how to migrate Electronic inventory based on how it was setup in the legacy ILS

During migration, all inventory is assumed to be physical unless specified otherwise in P2E file

3

Alma Records

Physical Records in Alma

Electronic Records in Alma

4

Electronic Resource In Alma

This is how electronic resource packages look in Alma after the P2E process has been completed

Indicates that the package is an active local record. When greyed out, it indicates an inactive local record.

Indicates the e-resource is global and linked to the Community Zone. P2E records will not be in this category.

5

Physical Resource in Alma

6

Alma Orders

Electronic Electronic only

Physical Electronic and Physical

7

Normal Conversion Process

Convert physical inventory from legacy ILS to Alma with the normal conversion process

8

Institution Resources

The institution is requested to provide a list of bibliographic identifiers that actually represent electronic resources with their corresponding resource type.

Resource Types: Portfolio: single title, purchased online in full-text Electronic Collection

Package: group of portfolio’s sold together DB: for searching article/title info

Note: There will remain an attribute difference between the DB’s and the Packages even after they are both generically called electronic collections.

9

Electronic Locations

The institution will typically provide indication of libraries or locations that represent electronic inventory in the migration form.

The institution may have a single bibliographic record in multiple formats, so we must know to retrieve only the holding/item information for the electronic location and not the physical location.

All ILS’s except Aleph (as two-level lib/loc is migrated automatically)

ILSs with Item-level material types

All ILS’s

10

Records with multiple URL’s/Notes Behavior

When there is one URL found in the 856u holding or bib (or whatever field specified by the institution as electronic link – it is matched on a 1 to 1 basis to the electronic resource.)

When there are multiple URL’s found connected to the record (856u or other), we create separate inventory for each URL (ex: multiple packages)

If we find that the there are identical provider name information and public notes in the (ex: 856u$z [$z - public note], we will match them to their corresponding 856u’s in sequential order.)

11

Records with multiple URL’s/Notes Behavior - ExampleIf the Institution provided this in the migration setup for a specific holding or bib:URL source: 856 |uNote source: 856 |zVendor provider source: 856 |3

We expect 3 e-portfolios with these attributes:

12

Conversion Process

The system processes Institution input by Determining if the bib record exists

Determining resource level of the record – bib, item, or holding (it looks for the lowest level)

Checking if there is an associated order record for the resource (assuming acquisitions are in the scope of migration for institution)

BIB

Holding

Item

Highest

Lowest

Middle

13

BIBS

If a bibliographic record provided by the institution has no attached electronic holdings or items, we create a portfolio, package or DB and associate it with that Bib (that is, there is no e-holding/item to convert, but only new e-inventory to add/associate with that Bib)

In this case, there may be physical holdings/items. However, they will remain untouched.

14

Associated order record

For each record, Alma checks for an associated order record by using the Bib, Holding, or Item ID to find the location from the corresponding inventory list supplied

Alma allows one order per inventory record. When there are more than one associated order for the same resource (e.g. ordered from one vendor, then cancelled and ordered from a different vendor), migration processing will use an open/recent order first .

Other orders will relate to the e-order, but may remain categorized as physical.

The Ex Libris roadmap has plans to handle non-primary orders as well in the future.

15

Associated Order Workflow (Inventory)

Use latest send date

Use any order associated with this e-location with any status

using latest sent date

Inventory

Active Order

Inactive Order

System Action

Order Status

During P2E conversion, the system uses the following workflow for associated orders.

When the criteria is met, the system takes the action and stops.

Single order with no electronic location found

Select the single order even if the order is not in an electronic

location

Multiple orders not in an e-location

Don't link any order

If no inactive order with e-location found, apply logic from above

16

ILS Electronic Records Duplicated from Link Resolver system

Since Alma intends to store both ILS and link resolver records in one system, the default migration pattern is to identify and eliminate duplicate link resolver records stored in the ILS and presume that the link resolver records will serve as the master.

Via migration, it is possible to recognize the link resolver records as specified in the migration form based on the text specified in 035|a

Exception 1: Another record with linked ILS orders, in which case the link resolver record is transferred as a suppressed record to retain data integrity.

Exception 2: The ILS record has no order, but is still migrated in case the Bib record also has physical inventory.

17

Handling Duplication

Alma Migration Process tries to:

Ensure that the end-user discovery experience is not affected by any duplication. This is achieved by: Primo setup de-dupe to ensure search results are combined where possible Preferring link resolver versions of e-resources via “ViewIT” end-user service menu over ILS-versions

Ensure that there is no data loss by making sure that the relevant order/back-office information managed in the ILS remains. This results in the SFX or other link resolver system version serving as the master for linking/delivery/discovery and the ILS version as the back-office tracking and management master.

Alma offers ongoing optional and manual back-office cleanup.

For back-office duplication elimination – the following manual steps can be optionally undertaken by the institution:

Associate LR/CZ inventory with ILS-originated order * Un-associate ILS-originated e-record with ILS-originated order* Re-link the ILS-originated order to LR/CZ Bib instead of ILS-originated Bib (this is currently planned to be

possible from Jun 2014 release) Delete ILS-originated Bib/inventory (via MD editor or building a set of records for deletion/withdrawal)

* and license, (if relevant), via search and resource editor

18

Use Case 1

Legacy ILS and Link Resolver ALMA

Bibliographic Record

SFX package

OpenOrder 1

Open Order 2

Bibliographic Record

Bibliographic Record

Order 2(Not Migrated)

Order 1 (Migrated)

SFX Package

Bibliographic Record

P2E package

Manual de-duplication options exist for this case

19

Use Case 1 Example

Stub Bibliographic Record in Alma before P2E Process

2 open orders are associated with the stub bibliographic record

20

Use Case 1 – Orders associated with BIB

The 2 open orders are associated with the bibliographic record

Bib is also in the LR/Community Zone

21

Use Case 1 (Post P2E)

Even though there were 2 open orders, only one is migrated based on system logic specified earlier

Use latest send date

Active Order

The BIB linked to the CZ is also migrated, however, a future ALMA release will allow for manual de-duplication of ILS/LR records relinking of the migrated order to Link Resolver record.

22

Use Case 2

Bibliographic Record included in P2E

Bib not included in LR/CZ

Physical item in electronic location

Physical item in physical location

Electronic portfolio made from the electronic location

item

Bibliographic Record included in P2E

Physical item in physical location

remains

23

Use Case 2 (Example) cont…

2 physical copies, although one of them is identified as being in a physical location based on Institution input in the migration form (for all ILS’s except for Aleph)

24

Use Case 2 Example (post P2E)

After the P2E process has been completed – the item which had been associated with an electronic location has been converted to electronic, while the physical resource has remained physical.

25

Use Case 3 (Aleph)

Bibliographic Record

Physical Item in a lib/location with e-material type –

EBOOK

Physical Item in a lib/location with non e-material

type.

Migration Form: Material type =

EBOOK is electronic

Electronic items created for

material type: EBOOK

Bibliographic Record

Physical Holdings/Item

remains for non-EBOOK material

type

26

Use Case 3

In the P2E-Libs_Cols Tab in Migration Form, they have specified material type EBOOK as being electronic

Institution has indicated the library MAIN in the migration form as being an electronic location

27

Use Case 3

Physical title in Alma

3 different items

Contains 1 holding

28

Use Case 3 cont…

Once you drill down to the item level, you can see that there are different material types, even though they are all linked to the same location = MAIN Library

29

Use Case 3 (post P2E)

After P2E process, the item specified as material type = EBOOK has been converted to electronic, while the other 2 have remained physical.

30

Thank You!