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 18 Current »

https://openlibraryfoundation.atlassian.net/issues/?jql=issue%20in%20(DCB-1549%2C%20DCB-1541%2C%20DCB-1540%2C%20DCB-1530%2C%20DCB-1411%2C%20DCB-1725%2C%20DCB-1730%2C%20DCB-1735)

Additional References

Item resolution requirements

Availability Date Scenarios for Resolution Ranking

Filter and Sort / Pool and Rank

Selectable Pool

Applies to all resolution strategies (including manual selection)

These suppression and selection factors determine (and limit) the pool of potentially resolvable items

  • CONTRIBUTED / DISCOVERABLE (BIB)

    • Bib suppression / discovery flag

    • Per library bib suppression rules

  • DISPLAYABLE (ITEM)

    • Display Suppression

    • Deleted items

    • Per library suppression rules

    • Shelving location

  • CIRCULATABLE (ITEM)

  • Item is from cancelling supplier

Item Ranking

Applies to all resolution strategies, except manual selection

Items are sorted and resolved in order

  1. Item is from borrowing library’s preferred supplier group

  2. Item is available (on shelf)

  3. Item is currently loaned

    1. due soonest

  4. Item has holds

    1. fewest holds

  5. Geographic proximity

Technical Notes

Resolution strategy

How re-resolution should work with preferred supplier and load balancing features

Previously included in the context of DCB-1411 (Ian Ibbotson)

Currently org.olf.dcb.request.resolution.PatronRequestResolutionService has a method resolvePatronRequest which is called once in the flow. This story will cause re-execution of this method.

Currently the method performs the following steps

return Mono.just(Resolution.forPatronRequest(patronRequest))
  .zipWhen(this::getAvailableItems, Resolution::trackAllItems)
  .map(this::filterItems)
  .flatMap(this::decideResolutionStrategy)
  .flatMap(function(this::applyResolutionStrategy))
  .doOnError(error -> log.warn(
    "There was an error in the liveAvailabilityService.getAvailableItems stream : {}", error.getMessage()))
  .switchIfEmpty(Mono.defer(() -> Mono.just(noItemsSelectable(patronRequest))));

There are three item resolution strategies currently defined:

  • FirstRequestableItemResolutionStrategy.java

  • GeoDistanceResolutionStrategy.java

  • ManualSelectionStrategy.java

The default for normal book lending is Geo Distance. Any implementation can change the default strategy with an environment variable. New strategies can be added at any point. It is important to maintain the item resolver interface ResolutionStrategy.

public interface ResolutionStrategy {
  String MANUAL_SELECTION = "ManualSelection";

  // Resolution Strategies must return a code which can be used to select
  // an implementation based on config
  String getCode();

  Mono<Item> chooseItem(List<Item> items, UUID clusterRecordId, PatronRequest patronRequest);
}

As long as we maintain this clean separation, different choices with requesting groups and load balancing are constrained to the applyResolutionStrategy section - so this code does not interact in any way with requesting or re-reqesting. All that happens is that the resolutionStrategy has to return a specific item to try and get hold of. It is essential that any resolution strategy tries to reduce the list of possible items down to a specific one to “Try next”.

It is expected that a new GeneralResolutionStrategy will be created which allows systems to specify the sort and filter criteria of the items in the input List. For example - Filter [“available items”, “Not already tried”], sort by [“MyLendingGroup”, “GeoDistance”] or “Sort by [“My Lending Group”, “SupplierLoad”].

GeneralResolutionStrategy will then choose the item that sorted highest as the next item to try and request.

In this way resolution strategies are entirely isolated from the re-request process.

Sort order

Previously posted in #dcb-requirements

Ian Ibbotson

"As a developer" I think it over complicates the work to separate out on shelf from holds. We should blend the two.

  1. Due date is not a good guide to availability-date once queue depth is > 0 because it's the return date of the current loan so it gives no indication of when future loans may be returned. All of these concepts should be blended into "AvailabilityDate" which

    1. defaults to now() if the item is on shelf,

    2. due date if the item is on loan but hold count is 0, or

    3. due date + ( default loan period * hold queue depth) for queue depths > 0.

  2. The "Default" system wide sort order will be [ "availability-date" ]. The system works by sorting by availability date desc and them choosing the first item available from a supplier not already tried.

  3. Libraries need to be able to configure the sort criteria for their patrons. On a per library basis in the admin app the sort order can be changed for an institution. Sort order is a list of criteria which includes availability-date and the following fields:

    1. geo-distance from pickup library to lending library

    2. supplier-group priority (1,2,3,4,5..) Each library will configure it's preferences

Libraries will be allowed to choose the order - so [ 'availability-date', supplier-group-priority, 'geo-distance' ] - would give items on shelf priority and within that supplier group and then geo distance.e.g.

DueDate - Supplier Group - Geo-distance
01-Jan-2025 - 0 - 1.356
01-Jan-2025 - 0 - 6.4
01-Jan-2025 - 1 - 34.6
01-Jan-2025 - 2 - 10.4
01-Feb-2025 - 0 - 2.5

Tim Auger

Are you saying that availability-date is something that libraries could choose sort independently or just Supplier Group and Geo-distance? It seems that you are saying that all would be configurable by supplier library.

Ian Ibbotson

Well - we might not want to allow the first sort criteria to be selectable - but thats a UI thing - backend its all part of the same mechanism yes

Increments

Preparatory refactor: preserves existing behaviour

  1. Change resolution strategy to sort only and not select (chooseItem)

    1. Move manual selection out of resolution strategy and into resolution service

  2. Introduce availability date (setting as today (at start of process) for available items)

    1. what is the impact on

      1. request diagnostics

      2. shared index / availability reporting

    2. how do we expose this to DCB Admin? do we need to?

  3. Reorganise resolution to

    1. sort by availability date,

    2. then by resolution strategy (eg, geographic distance) (as tie-breaker)

    3. then choose first ordered (handled in Change resolution strategy)

Verification: should work the same as now. Regression testing on parity basis.

Support requests on checked out items

  1. Add consortial settings to enable or disable requests on checked out items

    1. [add DCB Admin option for consortial setting for requests on checked out items]

  2. Change selection filter to include checked out items

  3. Set availability date to due date for checked out items

Support requests on items with holds

  1. Add consortial settings to enable or disable requests on items with holds

    1. [add DCB Admin option for for requests on items with holds]

  2. Change selection filter to include items with holds

  3. Increase availability date based on hold queue and default loan period

  4. Compensate for lack of hold count data from Polaris

Add diagnostic and configuration support

  1. expose due date and hold count in request errors

  2. expose due date and hold count in live availability

  3. expose due date and hold count in DCB Admin shared index

  4. [add consortial setting for loan period (days)]

  • No labels

Operated as a Community Resource by the Open Library Foundation