Extend Alma Resource Sharing with UC P2P

See Best Practices for Decision Pages and Tags for groups

Legend: not started IN PROGRESS STALLED decided

Recommendation

RS OST recommends to (move forward/not move forward/reconsider) the implementation plan of extending UC’s Alma Resource Sharing with UC P2P partners for digitization requests.

Impact

Reasoning

Background & charge

With the implementation of the Automated Fulfillment Network (AFN), RS OST were informed that alternative options were available to replace or use in conjunction with AFN. One of those options was Peer-to-Peer (P2P), but the group was not ready to move forward on any additional changes. As limitations with the use of AFN became apparent, further discussions of implementing P2P were discussed.

Interest in P2P were to address the following issues:

• Inaccuracies in Alma Analytic statistics needed for annual reports with AFN

• Inability to request copies from digital formats through AFN

• Failures in AFN to properly locate material held at another UC location

• Potential to request from non-UC institutions (i.e. CSUs)

In October 2023, three campuses and CDL (UCD, UCR, UCSC, CDL) worked with Ex Libris (ExL) to configure and test out configurations and were able to successfully test loan exchanges using P2P. Testing was halted in December 2023, due to the need to focus on potential Tipasa implementation in Summer 2024, which did not end up occurring.

In a meeting on March 27, 2024, RS OST determined that P2P testing should be restarted to address some of the issues stated above. Three campuses volunteered for this testing including UCR, UCSC, and UCSD, with CDL giving project management support. The group was charged with the task to look further into configurations, especially in the context of digitization requests, and test those configurations to determine if P2P can resolve some of the limitations of AFN.

Starting in April 2024, the three campuses, with assistance from ExL, tested various digitization request configurations and scenarios to ensure that the limitations of AFN could be addressed, and reasonable workflows could be accomplished. The group halted on testing loan requests for a later time to prioritize digitization requests, since RS OST determined complete replacement of AFN is not desirable. This phase of testing concluded July 2024 with confidence that the minimum needs are met for implementing P2P for digitization requests.

Testings 

Before testing could begin, the three campuses were set up as peer to peer partners in the Alma sandbox. The configuration instructions (UC only) goes into the detail on setting up each location in Alma and the roles needed in order to make those changes.  

The first round of testing focused on loans.  The group encountered some issues but was ultimately successful with getting the requests to the lender.  We found that when autolocate didn’t work, it was worth checking terms of use in fulfillment configuration to ensure that loanable items have the default rule to always be resource sharing requestable. Peer to peer requests didn’t appear with the AFN requests.  They appear in a separate queue under Active Partner.

The group moved from loans to testing digitization requests (UC Only).  We placed digitization requests for a chapter or section from a physical item, making sure to alter the rota to send to the P2P partner location. The request appeared on the partner’s lending request queue.    Lenders can choose in Digitization Workflow Setup their default delivery method—either as an attachment or with a link.With digitization requests, lender must consider configurations for various rules in order to ensure the resource is sent and received seamlessly using the P2P workflow.

 Requests for a chapter from an electronic resource presented a slightly different workflow for the testers. The workflow also depends on which record in Primo is selected by the patron at the time of request.  In scenarios where a patron requests a book chapter from a print book but P2P partners have holdings for the electronic copy, it is possible for the borrower to edit the request to ensure routing to those locations.   

Findings

The success of these P2P digital requests are dependent on the source’s metadata.  If that metadata is incomplete or empty, no matches will be found.  We often encountered the following situation: print material was requested (with only a print ISSN listed in the metadata), the request only tried to match using that print ISSN, relevant electronic records that could have filled the request were ignored and only the print record matched.  We could possibly tweak the locate profiles to be more inclusive but that runs the risk of rampant false positive matches.  Some options below:  

The “locate by metadata” option in the locate profile could be issued to increase the number of matches.  It was investigated and disabled by a previous task force as it caused a high number of false positives: AFN Task Force  

We could locate only using title with no holdings analysis done at all; this would also result in a high number of false positives as it does not check to confirm that the specific issue being requested is held. Example: library holds Generic Journal issues 4-13, request matches when the patron is requesting issue 2.   

We cannot test analytics in the sandbox but most peer institutions utilizing P2P for digital requests successfully utilize canned analytic reports in Alma Analytics to meet their needs.  

Book chapter issue discovered

Currently, PrimoVE forms convert book chapters to appear as article requests, rather than parts of a book. This causes Alma to look for serial metadata in these requests rather than book metadata, resulting in failure to locate items for book chapters. In order for locate profiles to work properly on book chapter requests, Primo must send these as a ‘book chapter’ format to Alma. Changes in primo forms (such as adding book chapter formats) will require testing downstream to the broker infrastructure (IVEA & VDX as of August 2024). The P2P investigation groups recommends to place this change in the RS OST work plan, and to wait until our broker infrastructure is less volatiles (after VDX is replaced) to make this change

Proposed plan

Rota automation recommendation 

For this phase of testing P2P partners, the P2P investigation group recommends: 

• All digital requests go to P2P partners (article, book chapter, and ebook)

• AFN partners handle only physical requests

• After going through respective AFN or P2P UC partners, requests are routed to external broker (currently VDX)

Ex Libris notes that the P2P and AFN locate profiles are unlikely to find different partners, thus it is not recommended to send requests through both P2P and AFN partners.

Testing in all UC SBs:

• 3 weeks (Sample dates: Sep 2-20): Make configurations in all UC PSBs, P2P configuration instructions (UC only; note ‘rota automation recommendation’ above)

• 6 weeks (Sample dates: Sep 23-Nov 8): Testing in pairs, option to review/discuss testings in RS OST meetings - RS OST decided to extend this testing to Nov 27, 2024 (10/30/2024)

• 2 weeks (Sample Dates: Nov 11-Nov 22): Discuss and evaluate tests & seek feedback from stakeholders about moving forward in production - RS OST decided to change this date to Dec 2 - 13, 2024 (10/30/2024)

• 1 day (RS OST meeting, Sample date: Dec 4): yes/no move forward with P2P in production - RS OST decided to change this date to Dec 18, 2024 (10/30/2024)

If yes, implement in production:

• 1-2 days, coordinated (Sample date: late Jan 2025 or early Feb 2025): Make configurations in all UC production Almas

• 2-6 months (Sample date: Feb 2025 - July 1 2025 - note: might be concurrent with other large project): go wild

• After 1 month (sample date: April 2025): check analytic reports for these requests

• After 6 months (Sample date: August 2025): check in, continue? Undo? expand?

If no:

• 1-2 weeks: think about why not? Use answers to consider next steps, if any.

Action Log