...

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

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 should handle this.

When discussing real-world challenges, it quickly became clear that these axioms are not sufficient. All use cases are missing, where availability does not only depend on the properties of the medium, but can also be limited by the properties of the user.
This gap is documented in this paper with here. Based on an example and different possible solutions are discussed.

Matching FOLIO tickets

...

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

Challenge

The search interface should offer navigation meaningful action elements (buttons) that are as meaningful as possible in two modes of operation.

1. Without prior registration (patron is unknown) there There are four possibilities of display:
   1. The copy is basically not available. (Infotext 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 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. (Infotext: ...)
   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. (Infotext: ...)

...

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's properties. The full set of circulation rules have has to be evaluated.

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

...

When designing edge_rtac and edge_patron, an attempt was made to avoid any overlaps between the interfaces. As demonstrated in the example
above, this cannot be totally sustained.
In this paragraph we discuss where/how the missing connection between the userpatrons's characteristics and those of the medium can item might be mapped.

Introduction of an additional interface (For example edge_patron-rtac)

...