IFLANET home - International Federation of Library Associations and InstitutionsActivities and ServicesSearchContacts

UDT Series on Data Communication Technologies and Standards for Libraries

Models for Open System Protocol Development : A Technical Report (1994)

2. SEARCH AND RETRIEVE PROTOCOL (SR)

The SR protocol is defined for the communication between two information systems. An information system is, in this context, an automated information system, such as an automated library catalogue.

One system is the initiator to the communication, the Origin system, the other system is the responder, the Target system. The Origin system has control of the communication. The communication is carried out by the exchange of messages.

2.1 End User View

To the end-user, the local system is the Origin, the remote system the end-user has requested is the Target system. The Origin may or may not have a local database. The Target system must have at least one database.

In some cases the end-user using the Origin system requests services and may, or may not, be aware of the fact that the actual processing of the request may be carried out by a remote system. In other cases the end-user will choose which remote system to search and thus be aware of the fact that the search is not carried out in the local database.

The model where the Origin system sends the request to multiple Target systems at the same time, multicasting, is not covered in the standard. However, a local system may offer a multicasting service to the end-user by communicating with a set of Target systems, but presenting the results to the user after all Targets have responded. This is the choice of the local implementors and does not influence the way the protocol works.

The SR protocol does not define the user dialogue in the local system, nor does it restrict the design of such a dialogue. Some systems implementing the Origin role of the SR protocol may, however, choose to extend their user dialogue to enable their users to send searches not locally supported, choose Target databases, or obtain more help from the Target systems.

The main service in the present SR standard is the Search service. This service enables the end-user to request a search using different types of terms (names, titles, subject headings, dates, etc.), boolean operators, truncation, term positions, term composition (word, phrase, etc.), etc. The end-user enters the search criteria in the local system and the local system converts the search request to the standard protocol form. The result of the search is also presented to the end-user by the local system and therefore the search result may be displayed in the same way as a search result from the local database.

The SR protocol translates the local dialogue commands into protocol messages and interprets incoming protocol messages and acts upon them.

When two or more automated information systems, i.e., systems with both user interfaces and databases, have implemented both Origin and Target of the SR protocol, their end-users will potentially have access to all these systems' databases through their own system. The end-users will use their local system's user-dialogue when accessing the other systems' databases.

Records retrieved from the Target systems may be stored in the local database. To the end-user a record retrieved from a Target system does not differ from one retrieved from the local database, nor from one entered at the terminal.

2.2 Target and Origin Only Implementations

An information system may act as only an SR Target in the network. That means that the end-users of other automated systems may use this system's database as if it were one of their own local databases. But the end-users of such a Target system, will not be able to use other systems' databases through their own system.

An information system may also only act as an SR Origin system. In that case its end-users may use other systems' databases as their own, but end-users connected to other system will not be able to use the databases of this SR Origin system.

Origin-only systems, called SR kernel systems, have been developed; they are also referred to as stand-alone clients. These systems enable the end-user to use remote databases as their local databases, searching all with the same user dialogue. But an SR kernel system does not have its own database, and thus there is no database where the retrieved records can be stored directly by the local system.

2.3 SR Services

The services or actions supported in the SR protocol, which are basic to all information retrieval, are listed below. Section 4 describes many extensions to SR that are being processed to augment this basic functionality.

  • Initialize - Sets up communication for subsequent services, setting certain options, etc.

  • Search - Permits the Origin to search a database on the Target for records that meet certain criteria and permits the Target to respond indicating the results of the search.

  • Present - Permits an Origin to retrieve records from a result set on the Target formed as a result of a search, and permits the Target to respond to the request by returning the requested records.

  • Delete-Result-Set - Permits an Origin to delete result sets at the Target, and permits a Target to respond to the request indicating the outcome of the request.

  • SR-release - Permits an Origin to request an orderly termination of the application association, and permits the Target to respond indicating the outcome of the request.

  • SR-abort - Permits either an Origin or a Target to request abrupt termination of the application association

2.4 Example Content of an SR APDU

The communication between two systems is performed by the exchange of messages called Application Protocol Data Units (APDU). The type of content and the syntax of these messages, as well as the rules for how to react on the receipt of a message, is described in the protocol. In this section data elements of the Search request APDU are described as an example.

The Search request APDU may contain many fields, some are mandatory and others are optional. The contents of some fields inform the Target how the Origin prefers the response, one field identifies where to search (in which databases), and some fields contain the actual query. A Search request APDU may consist of the following information fields:

referenceID
An optional field which is the same for all APDUs in one operation.

smallSetUpperBound
An integer which informs the Target system that if the result set is smaller than, or equal to, this number, all records should be sent back in the Search response APDU.

largeSetLowerBound
An integer which informs the Target system that if the result set is larger than, or equal to, this number, no records should be returned in the Search response APDU.

mediumSetPresentNumber
An integer which informs the Target system that if the result set is neither small nor large, the Origin would like maximum this number of records to be returned in the Search response APDU.

proposedResultSetId
The Origin prefers to refer to the result set by this string of characters (name, numbers, etc.) and informs the Target of this through this field.

replaceIndicator
The Origin may have used the value in the proposedResultSetId earlier in the session. The Target may, or may not be aware of this. This indicator tells the Target that it may, or may not, replace an earlier result set by the new to be created. The field acts as a protection against overwriting an existing result set by accident.

databaseId
This field contains one or more names of databases in which the Origin wants the Target to search. The names of the Targets' databases must either be stored in the local system, or the end-user must know them.

smallSetRecordComposition
This is a name for a set of fields the Origin wants for the records in a small result set. In the standard two values are defined for this field: "full" and "brief". The Target decides which fields belong in a brief format.

mediumSetRecordComposition
This is a name for a set of fields the Origin wants for the records in a medium result set. In the standard two values are defined for this field: "full" and "brief". The Target decides which fields belong in a brief format. NOTE: Systems usually display a list of records in a result set in a short form. In order to reduce the network traffic, the ability to order "less than full" formats is included in the standard.

preferredRecordSyntax
This field contains the identifier for the format the Origin prefers; e.g. UNIMARC, USMARC, NORMARC, etc. This field is optional because of the use of the protocols in environments where one only uses one format.

query
The query itself. This field is structured. First is the identification of the type of query: RPN form (Reverse Polish Notation), CCL form (ISO 8777), or private format. Then the different parts of the query are identified, e.g., are there any operators such as "less than", "equal to" etc, or Boolean operators like AND, OR, etc. The terms used are qualified by type of attribute (author, title, Dewey, etc.), whether the term is truncated or not, and other qualifiers.

*    

Latest Revision: April 27, 1995 Copyright © 1995-2000
International Federation of Library Associations and Institutions
www.ifla.org