Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Legend: NOT STARTED IN PROGRESS STALLED DECIDED

Status

IN PROGRESS

Scope

VANGUARD

Description

Choose among valid options for integrating Alma and VDX, primarily for the purpose of resource sharing via WorldShare ILL.

Decision

Owning group

Fulfillment and ILL FG (SILS-FG-FULFILL-L@LISTSERV.UCOP.EDU)

Approver

Stakeholders

R = Fulfillment and ILL FG
A = Fulfillment and ILL FG
C = Discovery FG, Alt Access committee
I = PPC, IC

Decision-making process

Fulfillment FG will make a recommendation in consultation with affected stakeholder groups, then pass to PPC and ICs to inform

Priority

Critical

Due date

Recommendation

(In progress.) The committee has decided that Option 3 is not valid and is continuing to pursue the remaining options.

Reasoning

Background

Currently the Request/VDX system is used for both consortial resource sharing and ILL, with ILL being implemented through OCLC WSILL for all requests that cannot be filled within UC (or for CRL members, by UC or CRL).

In the SILS, we have decided that consortial resource sharing will be implemented using a fulfillment network; but we will still need ILL through OCLC if a request cannot be filled using consortial holdings.

Based on previous information (which should be validated), direct peer-to-peer integration with WSILL is not feasible in Alma because OCLC is not open to integration via ISO-ILL. A high-level decision has been taken to retain VDX as the UC ILL broker until after the SILS migration is complete. This means that we need to integrate VDX with Alma as a solution for WSILL interlibrary loan.

There are various options for integrating an ILL broker with Alma, as outlined in the following training videos:

https://knowledge.exlibrisgroup.com/Alma/Training/Resource_Sharing/B_Broker-Based_Resource_Sharing

Dependencies

  • A high-level decision has already been made by DOC that we are not going to change resource broker until after SILS migration, so VDX can be used as a stopgap solution for integration with WSILL.

  • We are assuming based on previous information that direct peer-to-peer integration with WSILL is not feasible.

  • We have decided to implement an Alma fulfillment network for consortial resource sharing.

  • Other partners, such as CRL, can be configured as peer-to-peer resource sharing partners in Alma at the institution level.

  • OCLC is committed to supporting VDX for several more years.

Options

Option 1: Direct integration between Alma and VDX

In this option patrons will place ILL requests through Alma, through Primo, Google Scholar, an A&I database, or through the Alma Citation Linker (Fetch Item) form. Patron supplies request information, including pickup location, in the Alma Request Item form. (See video above.)

VDX could be integrated with the Alma Request form using ISO-ILL (or email).

VDX would be integrated with the borrowing library circulation system using NCIP 2 messaging (as has been done at UC Davis).

In this scenario the Request system will be completely retired, and we would need to consider whether we need to find ways to recover special functions provided by Request, such as Elsevier Express requests and Hathi link lookup. These features might need to be implemented in some other way if they are to be preserved, such as Hathi Trust API integration with Primo (as currently implemented at UC Davis), and integration between Alma and a patron driven acquisition system of some type for alternative access.

Option 2: General Electronic Service Link to Request

In this option the Request interface will be retained in a simplified form as a patron interface to the ILL broker. Patrons would link to this interface using a Request link in Primo or Alma, or through the Alma Citation Linker (Fetch Item) form.

In this scenario patrons might need to provide a barcode to log into Request, although there may be a technical way around this, such as configuring the General Electronic Service to securely transmit patron data to Request.

This option could present a degraded patron experience if not well integrated with Alma in terms of look and feel, or patron authentication. It also requires UC resources to continue to maintain and develop custom code.

However, this option preserves existing custom features, such as special processing for alternative access requests and Hathi Trust fulltext links, eliminating the need to find alternatives in Alma, and possibly postponing such efforts until after the migration.

This option would still require a direct NCIP 2 integration with VDX to integrate it with the Alma circulation system at the borrowing library when loans are received.

Option 3: General Electronic Service Link to My ILL

Decision: the committee has decided not to pursue this option, as it has none of the advantages of either Option 1 or Option 2.

In this option, the patron will place ILL requests in the VDX My ILL (Zportal) interface. Patrons would link to this interface using a Request link in Primo or Alma, or through the Alma Citation Linker (Fetch Item) form.

In this scenario patrons might need to provide a barcode to log into My ILL, although there may be a technical way around this, such as configuring the General Electronic Service to securely transmit patron data to My ILL.

In this scenario the Request system will be completely retired, and we would need to consider whether we need to find ways to recover special functions provided by Request, such as Elsevier Express requests and Hathi link lookup.

Questions to consider

  1. Based on previous information, we are assuming that a direct peer-to-peer integration with WSILL is not feasible. Has anything changed in this regard?

  2. How important is it to have the patron experience be within Alma (as opposed to in the resource broker interface)?

  3. Can a general electronic service securely transmit patron data to the service (esp. primary identifier)?

  4. How important is it to keep custom features in Request (e.g. Elsevier requests and Hathi Trust links), and can these needs be met some other way?

Note that Hathi Trust link function in Request would not be of much utility for ETAS requests once Request is reduced to providing resource sharing outside the UC consortium, because the user will only encounter Request after they have determined that their item is not held at UC, and Hathi ETAS requests are available based on their being held at UC.  This utility would be reduced to search for Hathi full text links. Surfacing these links earlier in the patron workflow would certainly be a better patron experience.

Alternative access requests (Elsevier or other special access content) could possibly be handled earlier in the patron workflow by an integration between Alma and Reprints Desk.

Q & A with Ex Libris

 The following response was provided by Ex Libris to our request for recommendations regarding options 1 and 2:

Le Tran (EXL)

Hi Elizabeth and Joe,

My apologies I missed this question. I'm double-checking with product management regarding option 1.

Re: option 2: this is commonly used. In this option, an General electronic service (link to VDX ILL form) is configured in Alma and displayed as an Interlibrary loan request link in Primo. When patrons click on this link, if VDX ILL supports OpenURL, the citation will be sent to VDX. If VDX is configured to integration with Alma using NCIP, borrowing and lending requests from VDX will be sent to Alma automatically via NCIP messages.

https://developers.exlibrisgroup.com/alma/integrations/resource_sharing/broker/
https://developers.exlibrisgroup.com/alma/integrations/resource_sharing/broker/ncip/

Libraries typically include proxy in their ILL form URL. What is your VDX URL?

Thanks,

Le

Le Tran (EXL)

Hi again Elizabeth and Joe,

I've got confirmation of my understanding from product management.  If option 1 - the resource sharing request form is used, the resource sharing request will be created in Alma, but it won't be pushed and created in VDX automatically. If this option is chosen, you would need to manually create the requests in VDX.

Therefore, I'd recommend that option 2 Alma General Electronic Service be used.

Thanks,

Le

Joe Ferrie

Le,

We would like to discuss this directly with your expert on ILL broker integration, particularly as regards the possibility of ISO-ILL. We believe that we read an Ex Libris publication that listed ISO-ILL as a supported protocol for Alma integration with VDX, and believe it should be possible to create an unmediated request in VDX using this protocol, particularly as no rota will be required. If the request is created with an empty rota, VDX can automatically add WSILL as a "lender of last resort." 

Would it be possible for you to put us directly in touch with an expert in this area to discuss this option?

Joe

I should add that VDX also supports a relatively simple email protocol for placing requests. This is a proprietary protocol and we don't anticipate that you support it, but we wonder whether it would be technically feasible for us to write an adapter that could be used by the Alma Request Item form to send the email into VDX.

Svetlana Smirnov (EXL)

Hi Joe,

Alma supports ISO with VDX.
https://developers.exlibrisgroup.com/alma/integrations/resource_sharing/p2p/

Thank you,
Svetlana

Action Log

Action/Point Person

Expected Completion Date

Notes

Status

Fulfillment and ILL FG watches and discusses recommended video that gives a high-level view of integration options: https://knowledge.exlibrisgroup.com/Alma/Training/Resource_Sharing/B_Broker-Based_Resource_Sharing/02_Resource_Requests_in_Broker-Based_Resource_Sharing

DONE

Joe F. reaches out to Ex Libris to investigate if there are any technical difficulties or unseen complications.

  • FG feels that there doesn’t appear to be any benefits to option three outlined above, and decides to focus on options 1 and 2

DONE

FG discusses feasibility of option 1 and 2

  • Options 1 and 2 are both technically feasible.

    • option 1 may cause issues with Hathi Trust and Elsevier links since the request system would be retired.

    • option 2 may require a lot of work for CDL to get going. There may not be enough time to code a new version of request for Vanguard.

  • Possible solutions for Option 1: There might be an opportunity for direct integration between Reprint’s beta product and Alma. Creating the opportunity for demand driven acquisition (DDA). This could include Elsevier as well as any other content that we decide to make available this way. UC Davis has also managed a recent successful integration with Hathi Trust, and could provide information on their work.

DONE

Decision for Vanguard date is set for July 30th, as we await more information from Ex-Libris on ISO-ILL

See Ex-Libris Q/A above

DONE

Fist of 5 Decision for Vanguard

IN PROGRESS

  • No labels