Retrieving a list of valid reservation pickup locations

[andrewdaye]

Looking for advice on the best way to implement retrieving pickup locations when placing a reservation.

Currently, the locations are available via the GET /lcf/1.0/locations call, and there were some additions in #132 to define pickup locations.

There is however a level of complexity that this does not cover - in some cases (especially larger consortia) the list of pickup locations will differ by patron and manifestation that is reserving and being reserved. I can't see how the current structure can encompass this?

Thanks,

Andrew.

[franciscave]

No, indeed, @andrewdaye. This is definitely a level of complexity that LCF doesn't currently support.

In LCF v1.2.0 support was added for defining a location to be a "pickup location", or "collection point" as it is described in code list LOP (location purpose).

I am presuming that a manifestation or item could be associated with certain collection points and not others, and a patron would be able to use certain collection points and not others.

The simplest solution would be to add a single code value to the code list LAT (location association type), the code having the meaning "possible collection point". When used in a manifestation or item record, the associated location would be a collection point that can be used by any patron for collecting that specific manifestation or item. When used in a patron record, the associated location would be a collection point that can be used by that patron for collecting any manifestation or item. Only locations whose purpose is specified to be "collection point" would be valid locations with this association type. For a patron to be able to collect a specific manifestation or item from a collection point, both the manifestation or item and the patron would have to have an association with that particular collection point.

I note that LCF does not currently support the association of a location with a manifestation, only a location with an item. Since a manifestation is any copy, would we wish to be able to associate any copy of a manifestation with a collection point, or would it be sufficient to be able to associate individual items (copies) with a collection point? If we want to add support for associating any copy with a collection point, we would need to add the associated location structure (see E02C06) to E01 Manifestation.

[mdovey]

Agreed at technical panel on the 3/11/2021, to add associated location to manifestation and ensure code list for reservation pick up is usable with manifestation.

[franciscave]

I propose the following change to code LAT (adding code value '07'):

LAT Location association type

Code ID	Code value	Definition	Notes
...	...	...	...
LAT06	06	Website of library authority/institution, branch or section	Added in v1.0.1
LAT07	07	Possible collection point	May be used to associate a manifestation or item with a specific location used for collection Added in vx.x.0

[franciscave]

I propose the following change in the LCF Data Framework to E01 Manifestation (adding E01CXX):

E01 MANIFESTATION

...

Properties

Id	Element	SIP2 ID	Card.	Format	Description
...	...	...	...	...	...
E01D12	Other description		0-1	String	Other descriptive information about the manifestation.
E01CXX	Associated location		0-n		Added vx.x.0
E01DXX.1	Location association type		1	Code	LCF code list LAT
E01DXX.2	Location reference		1	String
E01C24	Associated manifestation		0-n		Added vx.x.0

[franciscave]

I propose a corresponding change in the XML binding to E01 Manifestation:

E01 MANIFESTATION

	Element ID	XML structure	Card.	Data type	Notes
...	...	...	...	...	...
37	E01D12	description	0-1	string
37A	E01CXX	associated-location	0-n
37B	E01DXX.1	association-type	1	Code	LAT
37C	E01DXX.2	location-ref	1	string
38	E01C24	associated-manifestation	0-n

[franciscave]

See pull request #290.

[franciscave]

At the Technical Panel meeting on 11 October 2022, Andrew Daye pointed out that this change would not satisfy the original use case, so the issue has been re-opened.

[andrewdaye]

Scenario: As a client application that supports creating reservations, I want to show the user a list of pickup locations so that they may choose their preferred pickup location from a list of all valid pickup locations.

To display a list of valid pickup locations, it requires a number of LCF calls, that scales with the overall number of locations in the system.

Request 1: /lcf/1.0/locations?os:count=2000 (or a suitably high enough number to get all locations).

This will return all of the locations in the system, potentially including a large number of non-pickup locations. As an example, we have a customer where this is a list of around 1200 location-refs.

Request 2-1201: (each entity id from the previous request)

This will return the details of each location, allow us to determine if that location is a valid pickup location. Without making this call for every returned enetity ID in the first call, we dont know if the location is a valid pickup location, so this needs to be called for every location. In the customer example, only around 300 of those locations are valid pickup locations.

Two options:

1. Make the location requests sequentially - this could take 100 ms per call, meaning a wait time of two minutes for the location list.
2. Make the location requests asynchronously - this would likely be miscontrued as a Denial of Service attack by the server.

There are other options - e.g. batch the calls to make 50 requests at a time, followed by the next 50, etc. but this will still be subject to latency.

A more optimal solution would either be to:

(a) return the entity bodies in the initial call (potentially a large amount of data in a single request, but no more than the 1200 individual calls), or
(b) adding querying or filter options to the original request, such that only those entities that meet the criteria are returned, or
(c) a combination of both.