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

Current Page

SiteMap:contents
Z39.50 Core Account, Browse, Sort Extended services Diagram Facilities Bib-1 Record syntaxes

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.

Parameter

Notes

Query type

There are several types but type 1 is usual for bibliographic queries. Other types may be defined in the future.

Query

The query itself can be

  • a new query e.g. author=Evans
  • a previously defined result set
  • a result set + a restriction

The Query message sent to the Z-server (target) use the Reverse Polish Notation to format the query.  This is hidden from the user with the Z-client (origin) reformatting normal OPAC style search statements.

Database names

A Z-server may hold several databases - this parameter defines the name(s) of the databases to be searched.

Result set names

Means that the results can be referenced by name in later searches

Small record format

Defines the fields to be displayed if a small number of records is retrieved.  Allows you to show a full record if only one is retrieved for example.

Medium record format

Defines the fields to be displayed if a medium number of records is retrieved

Preferred record syntax

E.g. USMARC, UNIMARC etc.

Record size definitions

Parameters that define how many records are in a “small set”, a “medium set” and a “large set”. If a query results in a small set then all records are returned, if a medium set, then a parameter defines how many are to be returned. If a large set is returned then no records are returned - just the number in the set. This allows the Z-client to be set-up according to needs of the likely user and also to take account of bandwidth limitations.

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:

Parameter

Notes

Response records

The first few records as defined in the search parameters + any diagnostic records.

Result Count

The total number of records in the result set.

Number of records returned

The number of records returned in this first response. The searcher will generally go on and ask for more - see Present service.

Next result set position

Next record in the set to be retrieved.

Search status

Either “success” or “failure” - note that the search can be a “success” in Z39.50 terms and not return any records!  It is referring to the search process being a success.

Result set status

Used when a “failure” occurs to say why.

Present status

Used to say whether all, some or none of the records can be retrieved after a “success” and why.

Additional search information

The parameter can be used by the target to provide further information about a search response e.g. intermediate search counts or why certain records have been returned.

Other information

Information outside the standard can be exchanged via this parameter.

Reference ID

Identifies the query so that when many queries are submitted for concurrent processing, the responses can be matched to the queries.

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 SegmentPresent 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.

Parameter

Notes

Number of records requested

A simple number meaning, for example, “send 10 records”

Start position

e.g. “Send 10 records starting at number 15”

Additional ranges

Allows further ranges to be requested e.g. the Z-client can ask for records “1-10”, “15-16” and “24-32”.

Result set ID

A transient name for the result set.

Record format

Field names e.g. author title and record syntax e.g. Simple Unstructured Text (SUTRS) or UKMARC format. In version 3, the record format and data elements requested can be specified, depending on the record syntax used, to a high degree of detail. The GRS-1 (Generic Record Syntax)  will be used for complex tree structured data (non-MARC) and will allow highly specific extraction of data from a database.

Segment information

If the response records are to be segmented then the number and size of the segments is specified.

Z-server (target) Response

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

Parameter

Notes

Response records

These are either the records as requested - specific fields and syntax or diagnostic records saying why the records cannot be sent.

Number of records returned and next record number.

A simple number of records with the ID of the next record in the sequence - basically keeping count.

Present status

Used to say whether all, some or none of the records can be retrieved after a “success” and why.

Additional search information

The parameter can be used by the target to provide further information about a search response e.g. intermediate search counts or why certain records have been returned.

Other information

Information outside the standard can be exchanged via this parameter.

Reference ID

Identifies the query so that when many queries are submitted for concurrent processing, the responses can be matched to the queries.

Segment

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.

Parameter

Notes

Delete function

Either “delete result set x” or delete all current result-sets - a bulk delete.

Result-set list

A list of the result-sets to be deleted.

Delete operation statuses

Sent from the Z-server (target) back to the Z-client to say whether the delete has been done properly and if not why not.

Next section: Access, Account, Browse and Sort facilities