Book Industry Communication

Library Interoperability Standards

Library Data Communication Framework for Terminal Applications (LCF)[1]

Version 1.3.0

16 December 2023

This document defines data frameworks for messages to meet the data communication requirements of a standard set of business functions for terminal applications within libraries.

The use of this document is subject to license terms and conditions that can be found at http://www.bic.org.uk/resources/license-to-use-bic-standards/.

Terminal applications typically involve the use of terminal devices and systems by library staff and patrons to carry out a range of business functions that involve data communication between a user terminal and a Library Management System (LMS). The user terminal communicates with the LMS to request that a specific function be executed. Execution of the function will normally involve retrieval of or changes to information held in the LMS. The LMS will respond to the request in a variety of ways, depending upon the nature of the request. Terminal applications include self-service applications used by library patrons, as well as other applications used by library staff.

The standard business functions defined by this document are applicable both in circulation management and in stock / holdings management. User terminals may implement any reasonable subset of the functions defined by this document in either of these areas of application, or in others.

Each function is defined in terms of a pair of messages exchanged between the user terminal and the LMS. In terms of the client-server model for system architectures, the user terminal and LMS respectively take the roles of “client” and “server”. In the execution of each function the user terminal issues a request to the LMS and receives a response in return.

The information that these functions retrieve or change related to a number of “entities” that are fundamental to library management. The principal entities involved are:

• manifestations (titles) in a library’s catalogues

• items – individual copies of manifestations – in a library’s stock / holdings

• patrons – users entitled to borrow items from a library

• locations – where items may be located, usually inside a library; the “home library” locations of patrons; or locations associated with library authorities/institutions

• loans – of items to patrons

• reservations – of manifestations or specific copies of manifestations for patrons

• charges – fees and fines incurred by patrons for various reasons

• payments – made by patrons in respect of charges incurred

• contacts – contact details for persons or organizations represented by patrons.

Each entity and each request and response message-pair is defined in terms of a data framework[2], or schema. A data framework specifies how to describe an entity in terms of a collection of properties (identifiers, name, etc.), and how to construct a message (request or response) in terms of entity descriptions and other parameters. Each data element and composite is defined in terms of what data it may contain and its meaning.

This document is inevitably influenced by the widespread use of the 3M™ Standard Interchange Protocol Version 2.00 (SIP2) by library systems. Where appropriate, the relationship between an LCF function or data element and the corresponding SIP2 message type or field is indicated, to promote interoperability wherever possible between SIP2 and the LCF standard.

Data frameworks for terminal applications

Information entity types

Data frameworks are defined for the following principal types of information entity:

• Manifestations

• Items (individual copies of manifestations)

• Patrons (identified library users)

• Locations

• Loans

• Reservations

• Charges

• Payments

• Contacts (contact details for persons or organisations represented by patrons)

• Library authorities/institutions

The data frameworks for the following other types of information entity are also defined:

• Classification schemes (e.g. for manifestation classification) - DEPRECATED in v1.2.0

• Classification codes - DEPRECATED in v1.2.0

• Entity properties recognised by the LMS (used for constructing entity selection criteria - DEPRECATED in v1.0.1)

• Patron authorisation codes

• Message / alert

Each of the data frameworks for entity types defines the properties associated with that entity type. These properties may be either simple data elements or composites: more complex structures, being groupings of data elements and other composites.

Terminal application functions

Data frameworks are defined for the following terminal application functions:

• Core functions that can theoretically be applied to any type of information entity

  • Retrieve entity record

  • Retrieve entity list

  • Create new entity record

  • Modify existing entity record

  • Delete/terminate entity record

• Applications of the core functions to circulation management

  • Check-out / renewal of item to patron

  • Check-in item from patron

  • Make / confirm patron payment

  • Block patron account

  • Un-block patron account

  • Reserve title

  • Set/reset patron password

  • Set/reset patron PIN - (Added in v1.2.0)

• Applications of the core functions to stock management

  • Retrieve location list

  • Retrieve item classification scheme list

  • Retrieve classification list

  • Retrieve stock / holding list

  • Retrieve selection criterion type list - (DEPRECATED in v1.0.1)

  • Retrieve list of available items at a specific location

• Applications of the core functions for various other purposes

  • Apply charge to patron account

  • Acknowledge message/alert

Each of the data frameworks for terminal application functions assumes that a function is implemented as a pair of messages exchanged between the terminal application and the LMS, connected over a network. The terminal application initiates the exchange by sending a request to the LMS to execute the function in question. The LMS then sends a response to the terminal application, indicating the outcome of the request.

Each entity and function is defined in terms of data elements. Data elements may be grouped into composites. Each element is identified by a number prefixed by ‘D’ for simple data elements and by ‘C’ for composite data elements.

In addition to defining data frameworks for each function, this standard also defines a data framework for common data components used to convey user identification information and other messaging control data in request and response messages.

NOTE – This document does not mandate that any specific underlying communication infrastructure be employed for connecting the terminal application and the LMS, and therefore does not mandate whether or how the common data components should be used. Their inclusion is to facilitate mapping between existing legacy messaging protocols (e.g. SIP2) and LCF.

Data frameworks for information entity types

E01 MANIFESTATION

Back to entity list

Description

An identified manifestation of an abstract work, e.g. a book, magazine, newspaper or recording (analogue or digital). Sometimes informally referred to as a “title”, but this term is reserved in LCF for the title of a manifestation.

Properties

E02 ITEM

Back to entity list

Description

An identified copy of a manifestation that is in a library’s stock / holding.

Properties

E03 PATRON

Back to entity list

Description

An identified person or organization permitted to borrow an item from a library.

NOTE – Contact information is held in separate contact records for security and privacy reasons. See E09 below.

Properties

E04 LOCATION

Back to entity list

Description

A location associated with a library, such as:

• an identified place where an item may be located, either inside or outside a library;
• a library location associated with a patron, typically the patron’s “home library”;
• a library location associated with a library authority/institution, such as the main or branch site of a library.

Properties

E05 LOAN

Back to entity list

Description

An identified event in which one or more items have been loaned to a patron.

Properties

E06 RESERVATION

Back to entity list

Description

An identified event in which one or more titles have been reserved for a patron.

Properties

E07 CHARGE

Back to entity list

Description

An identified charge made to a patron. May be a fee or a fine.

Properties

E08 PAYMENT

Back to entity list

Description

An identified payment made by a patron to settle one or more charges.

Properties

E09 CONTACT

Back to entity list

Description

Contact details for the primary contact person or organization for a patron, location or authority/institution. (Description changed in v1.0.1)

Properties

E10 TITLE CLASSIFICATION SCHEME (DEPRECATED in v1.2.0)

Back to entity list

Description

An identified scheme for classification of titles.

Properties

E11 TITLE CLASSIFICATION TERM (DEPRECATED in v1.2.0)

Back to entity list

Description

A classification term in an identified scheme for classification of titles.

Properties

NOTE – If the scheme is appropriate, the classification identifier may the chosen to be the same as the classification code.

E12 SELECTION CRITERION (DEPRECATED in v1.0.1)

Back to entity list

Description

An identified property of an entity that can be used as a selection criterion when retrieving a list of instances of that entity.

Properties

NOTE – The selection criterion identifier may be the same as the name. In any case, the name must be unique.

E13 AUTHORISATION (added in v1.0.1)

Back to entity list

Description (clarified in v1.1.0)

A patron authorisation record, containing either a standard code from LCF code list AUT (E13D02) or a library-assigned heading or name (E13D03).

Properties

E14 LIBRARY AUTHORITY / INSTITUTION (added in v1.0.1)

Back to entity list

Description

An entity representing a single node in the logical structure for a library or wider institution. A single library would be modelled using only one entity record. Where a libary forms part of a wider institution or consortia, this can be represented with each node in the hierarchy being one record and the relationships between them described using the LCF code lists indicated below.

Properties

Notes on interpretation of repeated instances of E14C04.3 Library location service period

1. If the period start/end dates of instances of E14C04.3 do not overlap, i.e. they are mutually exclusive, all are applicable.

2. If the date period of one instance of E14C04.3 is wholly contained within the date period of another instance, the instance with the wider scope is overridden by the instance with the narrow scope to the extent of the scope of the latter. An example would be to specify opening and closing times for an academic term in one instance and different times for a specific week of that term in a second instance.

3. If the date periods of two or more instances of E14C04.3 overlap, but the date period of any instance is not wholly contained within the date period of another instance, the instances cannot be interpreted unambiguously and these instances should be ignored.

4. If the days of the week of two or more instances of E14C04.3.4 and E14C04.3.5 overlap, the instances cannot be interpreted unambiguously and these instances should be ignored.

5. If the time periods of two or more instances of E14C04.3.5.2 in the same instance of E14C04.3.5 overlap, the instances cannot be interpreted unambiguously and these instances should be ignored.

E15 MESSAGE / ALERT (added in v1.0.1)

Back to entity list

Description

A message is any form of communication that should be displayed to any group of Patrons or an individual Patron.

Messages for a specific Patron are typically retrieved through a request for the Patron record, which includes the associated messages for a specific Patron in field E03C34. This follows the use case for a self-service terminal, where the Patron is known and using the terminal.

Messages which require acknowledgement should follow LCF function 32, confirming which messages have been acknowledged by the Patron.

All message entities must have a type, indicated by the MAT code list, indicating whether action is required, or whether the message relates to the Institutional, Collection, or Patron level notices.

• Examples of Institution-level messages include opening hours, holiday closure periods, where the library as a whole may be unavailable, etc.
• Examples of Collection-level messages include additions or removal of items from collections, whether there are rule changes for accessing collections, etc.
• Examples of Patron-level messages include lost property or specific messages about fees or fines for one specific Patron, etc.

Properties

Common components

The following data elements and composites are typically used for control of message handling and authentication between the terminal application and the LMS. In some implementations these may be used in message headers and trailers, but in many, if not most, implementations these will be handled at a different level in the messaging protocol stack (e.g. in HTTP or SSL) and not in the message payload. They are primarily included here because of their inclusion in SIP2.

Q00 Elements common to requests

R00 Elements common to responses

Core functions

NOTE ON CARDINALITIES IN RESPONSE MESSAGES - The cardinalities for the elements of responses assume that there is no exception condition, which would be indicated by the inclusion of element R00D05 in a response. If there is an exception condition, only elements in table R00 above would be included in the response.

01 Retrieve entity instance information

Back to functions list

This function may be used to retrieve information about an instance of an entity of any type. In practice the most likely uses of the function are to retrieve information about titles, items and patrons, but it could also be used to retrieve information about instances of any entity type, such as locations or charges.

Request

* The correspondence with a SIP2 element depends upon the entity type. For entity types ‘patron’ and ‘item’ the correspondence is with SIP2 elements AA and AB respectively. The only other entity type that is likely to be specified with any frequency is ‘manifestation’.

Response

NOTE – The elements included in the response will depend upon both the entity type and whether a specific level of detail has been requested, by the inclusion of one or more elements Q01D03 in the request. Elements marked as mandatory may only be omitted if there has been an exception condition and the response is in effect empty.

02 Retrieve entity instance list

Back to functions list

This function may be used to retrieve a list of entity instances, with or without detailed information for each entity instance in the list. Normally the list would be retrieved with minimal information (mandatory elements only) or no detailed information apart from the identifier of the item.

Request

Response

03 Create entity item

Back to functions list

This function is used to create a new item of a specific entity type. In practice it is most often used to create a new reservation or a new loan.

Request

Response

04 Modify entity item

Back to functions list

This function is used to modify an existing item of a specific entity type.

Request

Response

05 Delete entity item

Back to functions list

This function is used to delete an item of a specific entity type. Since deletion of an item involves removal of all references to this item, this function would not normally be implemented as a terminal application.

Request

Response

Circulation management functions

11 Check-out / renewal (create loan)

Back to functions list

The check-out / renewal function, if successfully executed, causes an LMS to perform a number of consequential actions to create, delete or modify various entity records. These actions are performed internally within the LMS, so how they are performed is beyond the scope of LCF. Depending upon the precise circumstances, some or all of the following entity record creation, modification or deletion actions might be performed by an LMS:

• Unless this is a confirmation (request type RQT02) or cancellation (request type RQT03) of check-out or renewal, an LMS would typically retrieve the patron, item and manifestation records to check the patron’s status and ensure that check-out is permitted and to check for any applicable fees. An LMS may not block a confirmation request (equivalent to “no block” in SIP2). (Modified in v1.3.0)

• If check-out / renewal is to proceed, an LMS would create a loan record for the specified patron and item and, in the case of renewal, modify or delete the existing loan record. If cancelling a check-out or renewal, an LMS would retrieve and either delete or modify the loan record.

• If there is an associated reservation record for the specified patron and manifestation (or item), an LMS would retrieve and modify or delete this record.

• If fees apply to check-out of this item, an LMS would create a charge record for the applicable fee. If cancelling a check-out or renewal, an LMS would retrieve and either delete or modify the charge record.

• An LMS would modify the item record to update its circulation status and location and (optionally) add a reference to the loan record. If cancelling a previous check-out or renewal and deleting the associated loan record, an LMS would remove any reference to this loan record from the item record.

• An LMS would modify the patron record to update patron status and the number of items on loan and (optionally) add a reference to the loan record. If cancelling a previous check-out or renewal and deleting the associated loan record, an LMS would remove any reference to this loan record from the patron record.

This implies that the terminal application must provide sufficient information in the request for all the necessary consequential actions to be performed by the LMS.

Request

Response

12 Check-in

Back to functions list

The check-in function, if successfully executed, causes an LMS to perform a number of consequential actions. These actions are performed internally within the LMS, so how they are performed is beyond the scope of LCF. Depending upon the precise circumstances, some or all of the following entity record modification or creation actions might be performed by an LMS:

• Unless this is a cancellation (request type RQT03) of check-out or renewal, the LMS would retrieve the item record and modify to update circulation status and location. An LMS may not block a confirmation request (equivalent to “no block” in SIP2). (Modified in v1.3.0)

• The LMS would retrieve the loan record for this item and modify it to update its status.

• The LMS would retrieve the patron record and modify it to update the number of items on loan.

• If appropriate (such as when the item is overdue, or when a loan fee is dependent upon the precise date and time of check-in), the LMS would create a charge record for any fine or fee due.

Request

Response

13 Patron payment

Back to functions list

The patron payment function, if successfully executed, causes an LMS to perform a number of consequential actions. These actions are performed internally within the LMS, so how they are performed is beyond the scope of LCF. Depending upon the precise circumstances, and assuming payment has been authorised or does not require authorisation, either or both of the following entity record modification or deletion actions might be performed by an LMS:

• The LMS would create a payment record for the amount to be paid. If cancelling a payment, the payment record is deleted or the payment status is modified.

• The LMS would retrieve and modify the relevant charge records to update their charge status.

Request

Response

14 Block patron account

Back to functions list

Used to prevent unauthorised use of a patron account, such as when the patron’s library card is stolen or mislaid. This function could alternatively be implemented using core functions to retrieve and modify a patron entity: the patron’s current record is retrieved, the patron status and library card status are updated and any blocked card messages is added, as appropriate.

Request

Response

15 Un-block patron account

Back to functions list

This function is very similar to function 14 Block patron. Any blocked card message is removed. This function could alternatively be implemented using core functions to retrieve and modify a patron entity: the patron’s current record is retrieved and the patron status and library card status are updated as appropriate.

Request

Response

16 Reserve manifestation / item

Back to functions list

The reserve function, if successfully executed, causes an LMS to perform a number of consequential actions to create, delete or modify various entity records. These actions are performed internally within the LMS, so how they are performed is beyond the scope of LCF. Depending upon the precise circumstances, some or all of the following entity record creation, modification or deletion actions might be performed by an LMS:

• Unless this is a confirmation or cancellation of reservation, the LMS would retrieve the patron, item and/or manifestation records to check the patron’s status and ensure that reservation is permitted and to check for any applicable fees.

• If reservation is to proceed, the LMS would create a reservation record for the specified patron and manifestation or item. If cancelling a reservation, the LMS would either delete or modify the corresponding reservation record.

• If fees apply, the LMS would create a charge record for the applicable fee. If cancelling a reservation, the LMS would either delete or modify the corresponding charge record.

• The LMS would modify the manifestation or item record to add a reference to the reservation record. If cancelling a previous reservation and deleting the associated reservation record, the LMS would remove any reference to this record from the associated manifestation or item record.

• The LMS would modify the patron record to update patron status and the number of items on loan and (optionally) add a reference to the reservation record. If cancelling a previous reservation and deleting the associated reservation record, the LMS remove any reference to this record from the patron record.

Request

Response

17 Set/reset patron password

Back to functions list

This function sets the password associated with a Patron entity. Since, for security reasons, this password is not held as a property of the Patron entity, it cannot be set or retrieved using any of the core functions.

Request

Response

18 Set/reset patron PIN

[Added in v1.2.0]

Back to functions list

This function sets the PIN associated with a Patron entity. Since, for security reasons, this PIN may not be held as a property of the Patron entity, it cannot be set or retrieved using any of the core functions.

Request

Response

Stock management functions

21 Retrieve location list

Back to functions list

This function is the same as core function 02 for retrieving a list of entities of type E04 Location.

22 Retrieve title classification scheme list

Back to functions list

This function is the same as core function 02 for retrieving a list of entities of type E10 Title classification scheme.

23 Retrieve title classification list

Back to functions list

This function is the same as core function 02 for retrieving a list of entities of type E11 Title classification code.

24 Retrieve (stock) item list

Back to functions list

This function combines the core functions for retrieval of a list of manifestations (entity type E01) and list of stock items (entity type E02).

25 Retrieve selection criterion type list

[Deprecated in v1.2.0]

Back to functions list

This function is the same as the core function 02 for retrieving a list of entities of type E12 Selection criterion.

NOTE - Implementation of this function is now deprecated. A new approach to the expression of search and selection criteria for the retrieval of lists of entities is to be added in a future version.

26 Retrieve list of available items at a specific location

[Deprecated in v1.2.0]

NOTE - Implementation of this function is now deprecated. A new approach to the expression of search and selection criteria for the retrieval of lists of entities is to be added in a future version.

Back to functions list

This function selects all items that are available to be borrowed at a specific location and is the same as function 25 with specific Selection criteria: a specific location and a specific circulation status (CIS03 = ‘Available’).

Various other functions

31 Apply charge to patron account

Back to functions list

The function applies the following core function:

• Unless this is a cancellation of a charge, create a charge record of the appropriate type and associate it with the corresponding patron record. If cancelling a charge, either delete the charge record or modify its status to indicate that it is cancelled.
• Modify the patron record to add a reference to the new charge, or to remove the reference if cancelled.
• Make any necessary change to patron status as a consequence of creating or cancelling the charge.

Request

Response

32 Acknowledge message/alert

Back to functions list

The function modifies a Patron entity to change the delivery status of an associated Message/alert (E03D34.2) to ‘Delivered, acknowledged’ (MAD03), and is the same as function 04 applied to a Patron entity with entity modification type ‘update’ (MOT02), the request containing the associated Message/alert (E03C34) to be updated. The response is as for function 04.

[1] The acronym “LCF” derives from an informal, abbreviated name for the standard, coined during its development: “Library Communication Framework”.

[2] The term ‘data model’ is avoided here, because it could lead to confusion between this specification and specifications of other standard data models used in library applications, especially in RFID applications.

[3] The “cardinality” of an element is the number of times that an element is allowed to be included at that point in a message. The allowed values are ‘0-1’, ‘1’, ‘0-n’ and ‘1-n’. These are equivalent to ‘non-mandatory and non-repeatable’, ‘mandatory and non-repeatable’, ‘non-mandatory and repeatable’ and ‘mandatory and repeatable’. In general, elements in responses that are specified to be mandatory, i.e. they have cardinality ‘1’ or ‘1-n’, are mandatory unless there is an exception condition, in which case none of the specific response elements is included. If appropriate, information from the request may be included in the exception description element to assist in determining the cause of the exception condition.

[4] Identifiers in requests are mandatory except when creating a new entity. When creating an entity, the LMS may expect the terminal to provide the identifier in the case of Item, Patron and Authorisation entities, but when creating any other type of entity the LMS will generally assign its own identifier to the entity and ignore any identifier provided by the terminal.

[5] The ONIX code lists are maintained by EDItEUR. For the latest issue of the ONIX code lists see https://ns.editeur.org/onix/en.

[6] Elements where the cardinality is followed by ‘R’ are “response-only” or “read-only”. These elements should only occur in responses from an LMS to a terminal application/device and will be ignored when included in requests.