Item Resolution

See also: Item resolution requirements

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