ReShare Update - 12/9/2022
Please see the update from the ReShare team, below:
Since the membership and director meetings in late October and on-site meetings in early November, the ReShare team has made significant progress. Thanks to all of you for your insights and contributions during this time, the Discovery and Planning phase.
The following are a list of accomplishments since late October/early November:
We have determined the best path forward for implementing the standalone libraries by using the public API’s available for both the Polaris and Sierra platforms. Specifically, on both platforms we’ve used the APIs to search for and create patrons, along with placing holds for pickup and to track the status of requests. While we have a few weeks of evaluation remaining, we are on-track for creating a very streamlined circulation workflow within Polaris and Sierra.
We will be leveraging ReShare’s pre-existing streamlined circulation workflows in FOLIO in the context of Resource Sharing. That said, we will confirm over the coming weeks where modifications might be needed.
While our primary focus of the API investigation was on circulation workflows, we also understand how we will implement initial and on-going record loading across all platforms. Obviously, this is a must for creating and updating the union catalog.
We have defined much of the requirements for matching and merging records in the union catalog build. This is where all of the holdings are consolidated from multiple libraries onto one instance and, also, the identification of the best cataloged record for representation in the union catalog (i.e. “master record” selection).
We have defined the union catalog requirements for patron search, LOCATE (the “native” Folio public interface).
We have defined the requirements for item selection in the requesting process.
As we move into the new year and the Development phase, we will continue to tap your knowledge and expertise to guide us to a successful beta and launch!
Project ReShare - Roadmap
...
OpenRS Requirements for MOBIUS
Requesting and circu lation workflows
Patron uses a patron search application to search and make requests from OpenRS
Primary use case supports a patron-initiated request UX without mediation by library staff.
Secondary use case allows library staff to act as proxy requester on behalf of patron.
Patron authentication
If not already authenticated, placing a OpenRS request requires the patron to authenticate via the method used by the patron’s library.
Authentication requires the user to supply credentials to authenticate their library account and check eligibility against their library system.
The patron’s ILS determines patron’s eligibility to request. If not found or eligible, OpenRS will display messages corresponding to the issue blocking a request
If eligible, the patron selects a pickup location from the patron’s library and members participating in the pickup select program.
Patron submits request and the item selection process begins
Item selection process
Identify all items available for loan and on-shelf.
Of those on-shelf, prioritize placing a request on a copy that is closest to the pickup location.
When all items are either on loan or holds, place request on the one likely to be returned soonest (combination of number of holds and due date)
If the instance record has volumes, allow the patron to select a volume and allow OpenRS to select the items using the same item selection process as for monographs
Optional feature to allow staff to place a hold on behalf of a patron and to bypass the standard item selection process in favor of requesting a specific copy.
Request sent to the lending library in near real-time (NRT)
Request processing
Request associated with an institutional patron
Request added to pull list
If library is unable to locate material, library uses ILS to cancel the request, OpenRS searches for another item (using same item selection algorithm for original request)
If library locates material, prepares it for fulfillment/transit and using checkout, circulates the item to the borrowing library.
Print transit slip
The slip will include borrowing library name and code (for label making)
Put into transit
Lending library system automatically updates catalog
In NRT, OpenRS updates union catalog
In NRT, OpenRS updates the borrowing library OpenRS item status
Both library and patron can track the status of their OpenRS transactions within their ILS and patron empowerment features
Courier picks up materials and delivers them to correct borrowing libraries [Not an ILS step]
Borrowing library scans and receives the delivered materials using ILS checkin capability
If items is scanned at the wrong library destination, system to alert operator to route to intended destination and puts item in-transit to destination location
Hold triggered; ILS directs user to put item on the physical hold shelf
ILS updates OpenRS item record
Patron is notified via their ILS ((email, text, sms) via available notification methods of the library system notification capabilities.
Patron arrives at the pickup location to checkout OpenRS item(s)
Circulation of OpenRS items via ILS using ILS circulation rules
ILS updates OpenRS item record
Patron returns OpenRS items
If a patron returns OpenRS item(s) to their library, the ILS updates the item(s) to a returned state
In NRT, OpenRS updates the item library that the item is in-transit to the owning library
In-transit slip produced (dependent upon the capabilities of the ILS)
OpenRS Item shipped to home library
Patron responsibility of OpenRS item(s) complete
Material arrives at home library
Item is scanned using ILS check-in
ILS updates local catalog status
In NRT, OpenRS updates the union catalog
Cataloging
Automatic contribution of records to the OpenRS union catalog in NRT as records are cataloged/added, updated or deleted on the local system.
Contribution of records applies on a per library basis and addressable by encoding on a record-by-record basis.
Patron search
The ability to allow all libraries to enable or, in the case of Sierra and Polaris, create code to execute a pass-through search from the local patron search application to the OpenRS union catalog.
The ability to facet locations by library (not shelving location) in the LOCATE union catalog and apply to both search results and item requesting.
The ability to visually associate an 856 field with the corresponding holding library in LOCATE on the OpenRS union catalog. This is dependent upon known location data stored within the 856 location subfield.
On the full record display, the ability to view libraries with holdings that are currently eligible for loan and are on-shelf at the library.
On the full record display, the ability to place a request.
Administration
As much as possible, provide MCO the means to administer and configure OpenRS tables, settings and parameters
A way to easily identify last copies in the system.
Ability to calibrate via configuration the match algorithm (multiple, definable, hierarchical, matchpoints) to identify matches
Ability to calibrate via configuration the algorithm for determining the best instance record used for “match and attach” of items to a union catalog.
Options on how the system chooses an item to fill a hold and when to prompt for more information from the user (i.e. volume and serial records).
The ability to visually associate an 856 field with the corresponding holding library in LOCATE on the OpenRS union catalog.
The OPAC must be responsive down to a hand-held device.
The ability to generate “Too Long reports” or something similar.
The ability for all MOBIUS members to access OpenRS circulation lending and borrowing statistical reports.
The ability to access OpenRS circulation transaction logs and download in one or more common output formats (e.g. csv).
NOTES
Wherever near real time (NRT) is mentioned, it equates to a range from one second to five minutes. This range is largely dependent upon finding the right frequency of updates allowed by the ILS network traffic controller.
Where mentioned, ILS = FOLIO, Polaris, Sierra library service platforms. Unless a specific library system is mentioned,
Unless specified to the contrary, all capabilities are required for the MOBIUS’ go-live offering. As part of an iterative development process, new capabilities may be identified and folded into go-live plan or post-go-live. This is expected that all parties will, in good faith, seek to balance existing project priorities and new capabilities.
All workflows are intended to illustrate the user journey and are subject to change by K-Int and EBSCO.
Unless others specified, circulation workflow and corresponding functionality heavily leverages the library ILS. That said, there may be cases where the only means for creating a capability is to request development from an ILS vendor. On-site borrowing is one such capability that we already know about. In all cases, it is incumbent upon all parties to consult on the issue and, define and take steps to address. Work as a team, succeed as a team.
The refinement of match algorithms can be a significant investment. Collectively, we are collectively committed to moving at a speed relative to the impact and take measured steps to affect the best outcome for all. Generally speaking, rushing changes in this area of the system are likely to result in significant cost to the project.
...
Project OpenRS - Roadmap
A MOBIUS Project OpenRS roadmap will be detailed here when it is completed.
...