...

Dies ist die Engllsche Version der Seite: Konzeptionale Lücke bei zwei disjunkten Schnittstellen zu Verfügbarkeit und Nutzer*in-Interaktion

Abstract

Currently  Currently, FOLIO offers provides two disjoint interfaces disjunctive APIs for discovery systems:

• edge_rtac: for item related availability (functional subset of DAIA)
• edge_patron: for ordering (functional subset of PAIA) patron actions
  

The basic axioms are:

1. Availability is a binary property that can be derived exclusively from the properties of the media.
2. The user functions do not require any information other than availability. If nevertheless, the search interface APIs should handle this.

When discussing During the discussion of real-world challenges in the discovery sub-group, it was quickly became clear that these axioms are were not sufficient. All There are use cases are missing, where availability does not only depend on the properties of the medium, but can also be is also limited by the properties of the userpatron.  It was also realized that 'availability' is not really binary, and that there is a need for context.

This gap is documented here. Based on On the basis of an example, different solutions are approaches will be discussed.

...

Related FOLIO tickets

• UXPROD-2422 (Discovery Integrations - Expose Circulation Rules Regarding Requests)
• UXPROD-2758 (Discovery Integrations - Expose Circulation Rules Regarding Renewal Options)
• UXPROD-1630 (Pre-Check Request Policy When Requests are Created and/or Moved)

Generic example

Environment

• A small library has two types of readers and all media are stored in closed stacks.
• Some of the media may be ordered by all readers, some only by group 'A' and others only by group 'B'.
• The library has a discovery system that does not require an initial registration.

Challenge

The search interface discovery system should offer meaningful action elements (buttons) in two modes of operation.

1. Without prior registration (patron is unknown) There are four possibilities of display:
   1. The copy is basically not available. (Infotext Info text for the reason: e.g. ordered, lost, ...)
   2. The copy is available and may be ordered by all patrons. (Button: "Please register and order")
   3. The copy is available but on loan. (Button: "Please register, reservation possibly possible")
   4. The copy is available but may only be ordered by one patron group. (Button: "Please register, ordering may be possible")
2. With prior registration (patron is known) there are again several options:
   1. The copy is basically not available. (Infotext Info text for the reason e.g. on buy, lost, ...)
   2. The copy is available and
      1. the patron's group has the authority to place a hold. (Button: "order")
      2. the patron's group has no authority to place a hold. (InfotextInfo text: ...)
   3. The copy is available but on loan and
      1. the patron's group has the authority to place a hold. (Button: "reserve")
      2. the patron's group has no authority to place a hold. (InfotextInfo text: ...)

...

Task

For the first case of the example, an extended¹ edge_rtac should sufficient.
^{¹) Currently there is no information about the limitations/restrictions of the general availability available.}
In the second case, however, it is necessary to include knowledge about the patron. The full set of circulation rules has to be evaluated.

Currently neither edge_rtac nor edge_patron are able to fulfill the requirement.

...

Possible approaches

When designing edge_rtac and edge_patron , an attempt was made to avoid any overlaps between the interfacesare designed to be distinct. There should be no overlap between the APIs. As demonstrated in the example
above, this cannot be totally always sustained.
In this paragraph we discuss where/ how the missing connection between the patrons's characteristics and those of the item might be mappedto handle the need to combine attributes of objects and patrons.

Introduction of an additional

...

API (For example edge_patron-rtac)

It is seems obvious to outsource functions that cannot be directly assigned to a separate interfaceadd a new API. The advantage is that edge_rtac and edge_patron may stay unchanged. On the other hand every new interface brings new
complexity. Such an additional interface would obviously have a lot of overlaps with edge_rtac and edge_patron. To avoid duplicate code, the
existing interfaces would have to be reworked as wellSo edge_rtac and edge_patron it could be hard to decide which API to use. Also that third API may lead to produce duplicate code.

Extension of the availability information (edge_rtac)

To consider properties of a reader the patron's properties edge_rtac would have needs to know the login data. On the other hand, edge_rtac must also has to work without the login.
This
would result in two different working modes for edge_rtac: "Without login → vague information" vs. "With login → exact information".
The second mode
would correspond be quite similar to the third interface discarded above, but would be clearer to assign.
For a search interface, such an approach had only the disadvantage that existing availability information (hit list) would have to be reloaded after a loginAPI discussed above. But as apart of  edge_rtac  the design would be comprehensible.
This approach has two disadvantages:

• edge_rtac becomes bloated
• If the discovery system handles login in a popup window, some pages will need to be refreshed after login, as the availability information displayed may be out of date.

Extension of the user interaction (edge_patron)

In contrast to edge_rtac, edge_patron always knows the ID of the copy and the reader. Accordingly, a two-step workflow would be conceivable: 1.
fetch the exact availability information; 2. order according to the obtained information.
The first step would again correspond to the third interface (or the 2nd mode for edge_rtac), would be logically most inappropriate assigned to
edge_paron.already needs to handle with patron and item.but adding the same functionality here would have no advantage. It would still require two modes:

1. Before login: fetch the exact availability information via edge_rtac
   
2. After login: fetch the exact availability information via edge_patron

Partitioned expansion of both

...

APIs

The non-overlapping design of edge_rtac and edge_patron can be preserved if both interfaces APIs are slightly extended in their context.

*

...

edge_rtac

...

should extend the basic availability

...

with additional information about restrictions and extensions of the availability,

...

For this extension Even for attributes that depend on user groups, edge_rtac still needs does not need to know the ID of the readerlogin. It is sufficient if the interface becomes should be enough to make the API more talkative and outputs return as much loan
lending-relevant information as possible.

* edge_parton

...

should provide a mock order

...

function to query

...

each patron's state,
individual restrictions (lock, ...) and individual options (pickup location, ...).

The concept of a mock order can be adopted taken from the basically comparable interface PAIAsimilar API 'PAIA'.. The procedure is as follows:

1. If When the reader patron wishes to place an order/reservation, this is requested without additional information (collection location, ...a hold, the discovery system sends an incomplete request to edge_patron (e.g. no pick-up location). This triggers a
   test dummy order in the library systemcirculation module. This test order does not lead to any change in the loan status. But, as with a 'normal' order, all borrowing
   rules are evaluated to determine any and mock should not write anything, but should evaluate all circulation rules and return the detected restrictions/options. (restricted list Subset of possible pickup pick-up locations, list of possible delivery options,
   info on individual restrictions, ...).
2. With The discovery system generates a dialogue box with the result of the query, the search interface generates a dialog box in whichdummy request to:
   1. inform the reader is informed patron why the order/registration is not possible for you.  (Ee.g. : Blocked blocked due to too many open charges).
   2. allow the reader has the possibility patron to select the order parameters . (pick-up location, delivery option, cost transferacceptance costs, ...)
      
3. The search interface sends the order/reservation with selected parameters to the interface. In the library system, this triggers a regular
   With the additional information the discovery system can send a complete request to the API. This will trigger a regular order attempt.
4. The search interface informs about the success discovery system displays a feedback with the status of the order.

The current behavior of edge_patron is already similar. To place a hold currently likely. Currently, at least the parameter 'pickup location id' parameter is expectedrequired to place a hold. Without it, edge_patron reacts responds with an error message. At this point, a dummy order could be included. At this point an mock order could be triggered, to do a full evaluation. included
(Currently such a mock order is not yet supported by FOLIO, bur requested -> Tickets).

Summary

Even though they all sketched approaches are possible in principle, the first three possibilities seem to be inconsistent.

• An additional interface API would confuse more than help.
• The extension only of 'edge_rtac', would disturb the flow in the search interfacediscovery system
  
• Extending only 'edge_patron' would blur the clear separation to edge_rtac.

In contrast, the partitioned extension of both interfaces APIs fulfills the requirements without logical breaks.

Appendix

More application examples

Of course, there are many other framework conditions real library challenges besides the example above that need to be covered with the approach discussed above. In the
following, further basic examples are outlined and it is examined whether the solution described above is sufficient.

Remote locations 1

Environment

1. A library has two library locations.
2. Local stock should not be able to be ordered.
3. Stock from site 'A' should be able to be ordered to site 'B'.
4. Stock from site 'B' should be able to be ordered to site 'A'.
5. The library has a search interface discovery system that does not require registration for research.

Discussion

This example is only item depended. But still it has two aspects:

• edge_rtac
  The discovery system needs the information, that local ordering is limited by placelocation ("not local").
  
  
• edge_patron
  The mock order returns only issue pickup locations from other locations like that of the specimenitem. (a use case of UXPROD-2689)

Remote locations 2

Framework

1. In a departure from the previous example, there is a privileged group that is also allowed to order locally.
2. Additionally, there is a third group that is allowed to order locally for a handling fee.

Discussion

1. edge_rtac
   The orderability constraint Orderability should be specified as a property of the group.
   

   Code Block
   title possible response
   {"limitations": [    {"place" [      {"ordinary patrons": "non local"},      {"privileged patrons": "also local"},      {"payer": "local for money"}    ]} ]}

   Note: The example above isn't a realistic goal. But

   'rtac' might provide

   providing all non classified attributes and notes of holding, location and item

   . this

   might be sufficient

   for the

   . The discovery system

   to visualize all 

   should be able to identify the cases.
   
   

2. edge_patron
   The Returns the usable pickup locations are filtered by readerandcopy.
   If Returns the patron is member amount of the fee a 'payer' group, the amount of the fee could be provided also from the mock ordercould by accept.

Reading room

Environment

1. A library has a collection order for an areamandate. Media that have been procured for this purpose may not leave the building, but can may be viewedconsulted.
2. Some of the media items are stored in a closed magazine. For reading, these stacks. They can only be ordered to read in special reading rooms. There the media can
   be used exclusively during the loan period.Additionally, there During the loan period, the items are kept there and reserved for the patron.
3. There is a trusted group that is allowed to order to other pickup locations of customers who can order to any pick-up location in the house.

Discussion

1. edge_rtac
   

   The orderability constraint

   Orderability should be specified as a property of the group.
   

   Code Block
   title possible response
   {"limitations": [    {"place" [      {"ordinary patrons": "only reading rooms"},      {"trusted patrons": "only for in house use"},    ]} ]}

   
   

2. edge_patron
   The Returns the usable pickup locations are filtered based on readerandcopy.

Short-term loan

Environment

1. For some media (blank book collection) shortened lending times apply from the usual standardSome items (e.g. textbooks) may have a shorter loan period than usual.

Discussion

1. edge_rtac
   

   To allow

   Indicate the

   interface to indicate shortened lending times. The restriction should be specified as a property of the group.edge_patron
   The pickup locations are filtered based on readerandcopy

   shortened lending time

   Code Block
   title possible response
   {"limitations": [

...

1. {"

...

1. shortened loan period" [

...

1. {"

...

1. ordinary patrons": "

...

1. 3d"},

...

1. {"privileged patrons": "

...

1. 5d"}

...

1. ,    ]}

...

1. ]}

...

1. 
   

2. edge_patron
   Returns the usable pickup locations.