Z39.50 Core Services

This page describes the “Core” services that are part of every Z39.50 session:

• Initialisation: the preliminary negotiation of what services can be provided.
• Search: the creation and transmission of a query and the receiving of the first results.
• Retrieve: the selection and retrieval of records from a result set.

Contents Map: Z39.50 Part 2

Contents: this page

Initialisation, Search, Query, Response, Retrieval: Present, Segment, Result-set-delete

Initialisation

The initialisation is, as the name suggests, a precursor to the real work. The Z-client (origin) contacts the Z-server (target) and suggests some basic parameters for the session.  The Z-server can modify these and if both ends agree, the Z-Association begins.  Note that the Z-server is in control.  Whatever may or may not occur between the two computers is up to the Z-server - thus the library can decide with whom it “deals” and what services it shall provide right at the beginning.  Other facilities like access control and resource control give more detailed control.  The parameters that are discussed during the initialisation are:

• Version of Z39.50 to be used - thus a version 3 client and a version 2 Z-server (target) can agree to talk - using the highest common version.
• ID/authentication - usually a password style of control.
• Options - a string of yes/no responses to whether certain capabilities will be used. Search and Retrieve - the basic operations are normally allowed but, because the Z-server (target) is in control, it may be that only record counts for successful searches should be returned - not the records themselves - unlikely perhaps, but possible.  The other options that may be allowed/disallowed at this stage of the game are: delete, resource-report, scan, sort, extended services, resource-control and access control.

The two systems can also agree about:

• segmenting responses how to break-down large record sets when responding
• concurrent operations whether to allow multiple operations at the same time - enabling for example several searches to go against different databases on the same Z-server (target).

Search

This is where the basic power of the standard can be assessed. Z39.50 allows complex searches to be constructed with great flexibility. The search parameters allowed for bibliographic records are defined in the Bib-1 attribute set.  If you look at this set then you can see that it will work with demanding information retrieval applications as well as standard OPAC type bibliographical queries.  The implication is that you could use the same search tool for simple bibliographic queries and then switch to “Power mode” and conduct complex searches against text databases. A well designed Z39.50 tool should provide not only the ability to search across many library catalogues using the same interface but also the ability to search a databases at an appropriate level of complexity if it can support it.

It could be argued that a search tool cannot be all things to all men but Z39.50 has the power to support the various levels and even some capabilities to “dumb down” a search if the target cannot handle the search statement.

Here is how a typical Z39.50 search statement could be packaged up - showing the key parameters of the message passed to the Z-server.

The Query

The Query is a string of data and associated parameters that define the records being sought, the database to search and so on.

Query Structure

The query that is sent to the Z-server (target) is obviously a key part of the whole process. Internally, it is represented in “Reverse Polish Notation” or RPN. The query can use the Boolean operators AND, OR, AND-NOT and also the Proximity operator PROX depending on the version and query type. The Boolean structure can be as complex as required with multiple nesting of search phrases e.g. shown in algebraic format (a AND (b OR d)) OR c.  Also allowed in the query structure are operands for Restriction and Proximity.

When Restriction is allowed, a result-set can be reduced by applying a restriction such as “Author” to restrict the result set to just those records where the query term occurs in the specified field.

Proximity allows the specifying of terms to be near to each other and thus allows for “Full text retrieval”. The “nearness” of terms can be expressed in terms of their distance - expressed in units of text e.g. words, sentence, paragraphs.  E.g. 0 + sentence means in the same sentence. 2 + word means not more than 2 words apart. Relation can be expressed e.g. > 2 words would mean must be more than 2 words apart. The order of the terms can be expressed and also an exclusion flag so that a condition like “cat” not within 5 words of “hat”.

The Response

When the Z-server processes the query, it creates a “result set” - basically a set of pointers to the records in the database - a set of control numbers.

The initial response from the Z-Server is part of the search service and is basically information about the results of the search plus the first few real records as defined by the search parameters.  The possible parts of the first response to the query are as follows:

Summary

Search
“Enquirer: Have you got any books by Peter Evans about library automation - nothing earlier than 1993. Oh... and if there are only a few can I have full bib details please? - USMARC would be best.”

Response
“Ok I have done a search and I found 10 books. I have provided the first 3 records in full MARC as you requested.”

The next section describes what can happen next in the "Present" phase.

Retrieval

The retrieval facility comprises two services - Present and Segment.  Present is a request to the Z-server to send certain records and Segment is the process of breaking a large number of records into smaller numbers for ease of transmission. Segment can also be applied to breaking very large records into parts. The Present service is more interesting to the librarian since it defines how records can be requested. Segment is primarily of interest for optimising network transmission.

Present

After the Search service has retrieved the initial response of records, the user may wish to see more records and a Present message is sent to the Z-server (target).  The parameters of this message deal with how many records, how they should be shown etc.

When the target gets the “Present” request it responds with the records and some associated information.

As mentioned, the Segment service is not of much interest to librarians and so I am not going to cover this aspect of the standard in any detail. It concerns how records are packaged to transmission across the network. However if network speed is a problem, or you are asking routinely for hundreds or thousands of records to be downloaded, or your records are very large, then segmentation issues are likely to be important.

Summary of the Retrieve Service

Once the query has been submitted and the first response returned, the Z-client can ask for records to be retrieved. E.g.

Origin
 “Thanks for the first records from the query, lets call it “cereal diseases -1”, could you send me records 1-5, 16 and 21 please and use the brief record format please.”

Target response
“Here are the records you requested - I couldn’t get record 16 - the record was no longer on the database.”

Result-Set Delete

This service enables a result set to be deleted by the Z-client (origin).  The Z-server (target) responds accordingly.