Extended and Explain Services

Contents Map: Z39.50 Part 2

Current Page
SiteMap:contents
Z39.50 Core Account, browse, sort Extended services Z39.50 Diagram Bib-1 Record Syntaxes

Contents: this page

Extended Services, Task packages - persistent result set, persistent query, persistent query schedule,  order an item, database update, create export spec, invoke an existing spec.; Explain, Future, Implications

Extended Services

The extended service facility is a major enhancement to the standard’s original “Search and Retrieve” objectives.  Extended services allows the Z-client (origin) to start-up specific “task packages” on the Z-server (target) and to control how they operate.

Much of the interest in the extended services lies in the set of currently defined task packages as shown in the package type parameter below. Z39.50 defines how to start and control these packages via parameters in the various messages in the table - and it also defines task packages. The definition of the task packages is the key to appreciating the implications of the extended services of Z39.50.

When an extended service task package is started up, details are kept in an extended services database. These may be searched (via Z39.50 of course) in order to see what is running on the Z-server (target).

Parameter

Notes

Function

Create, Delete or Modify: allows a task to be started, changed or stopped by the origin.

Package type

The defined package types are:

  • Save a result set for later use
  • Save a query for later use
  • Define a periodic search schedule
  • Order an item
  • Update a database
  • Create an export specification
  • Invoke a previously created export specification.

Clearly these package types allow SDI, ILL/Acquisitions, and cataloguing operations to be handled via Z39.50. For the implications and further comment see below.

Package names

A name so the package can be referenced for action

User ID

User ID - again to control later control of the package

Retention time

Allows a period of days or hours to be specified.  After this period the task is deleted i.e. no longer running or available.  Could be used to control subscriptions to SDI for example.

Permissions

A list of user Ids allowed to access the task package. Different people may be given different operational permissions e.g. a librarian may be able to create an SDI profile whilst many others can “invoke” it - run it - whenever they want.

Description

A description of the task e.g. name of an SDI profile.

Target reference

An ID for the package - supplied by the target.

Creation date/time

When the package was created

Task Status

Pending , active, completed or aborted.

Package diagnostics

Diagnostic messages from the target

Task specific parameters

Additional parameters as defined by the individual task package - these are described in the section below on the extended services themselves.

Wait action

Whether to perform the task immediately or not and whether to return the task package.

Elements

The elements of the “task package” to be returned - i.e. the output spec. for whatever the task package delivers e.g. list of fields for an SDI run.

Operation status

Done, Accepted or failure

Operation diagnostics

If a failure this tells you why

Task packages

The output from the task.

Other Information

Specified outside the standard

Reference ID

To keep track of this task amongst others.

Extended Services: definitions of task packages

This section covers  the extended services so far defined by the standard and gives a description of the main features and implications for library and information service provision.
Persistent Result Set

This Service allows the Z-client (origin) to save a result set during a normal search session and then specify that result set during another session to retrieve the records. The persistent result set can be added to or deleted as required.  This service could be used if building up a large result set that is a result of several different searches on the Z-server (target) before they are downloaded.  Another use might be the creation of a set of records which could then be accessed by several users or actively sent to several users as part of a “Push” type service.  New book records from suppliers as a potential requirements or “desiderata” list could be handled this way.

Persistent Query

A persistent query can be stored on the Z-server (target) for use in subsequent sessions - as a search profile for an SDI service for example - especially when combined with a Periodic Query Schedule Service. Note that the Bib-1 attribute set includes the data added to the database as a searchable parameter so that a query asking for books with Subject =“Library Automation” added since “1 Jan 1998” is possible.
Persistent Query Schedule

This service has been specified to allow a query (either a new one or a previously defined Persistent Query) to be run at intervals automatically - this is the basic requirement for an SDI service.  Furthermore, the results can be “exported” to a specific destination via a specified mechanism such as Fax, e-mail, X400 address etc.  The important parameters for this service are given below:

Parameter

Notes

Active flag

Allows the origin to stop and start a schedule at any time.

Query specification or actual Query

The origin can supply either a new query associated with this schedule, or an existing Persistent Query

Database name(s)

Required if the query is a new one or the database names are not in the Query Package.

Period

Time between the query being run - e.g. number of days, weekly, monthly etc.

Expiration

Date after which the query schedule will lapse.

Result set package name

An existing Persistent Result Set can be named or a new one created.

Result set disposition

Can be set to create a new result set each time the query is run, append to an existing one or replace the existing one.

Alert destination

An alert destination can be supplied e.g. e-mail address, fax number, printer etc.

Export parameters

The name of an export parameter package if given here tells the target what to send to the alert destination. It could be the records, the count of records etc. See the Export parameter package service below.

Last query times

The last time the query was run.

Last result numbers

Number of new records obtained on the last run.

Number since modify

Number of records created since the Query was last modified.
Item Order

This service allows a user to place an order for an item.  The item can be either an item from a result set or a request - possibly coming from an ISO 10161 Inter Library Loan system. The name of the requester with details of address etc. can be included in the order.  Billing information e.g. credit card number and purchase order number can be included.

Database update

This service allows the Z-client (origin) to update records on the Z-server (target).  Records can be modified, added or deleted. Note that the standard does not address the problem of two users trying to modify the same record - this has to be controlled outside the standard.  It does allow for a client-server model for the basic cataloguing function and has been used by both Geac in their successful GeoCAT product and also by CGI in the Amicus product.  It also points the way to a possible new class of Z39.50 product which would work against any Z39.50 database.  Thus an LMS (Library Management System) without a MARC cataloguing data entry screen could bundle in a third party MARC editor to work against its catalogue database.

Export Specification

This service allows the Z-client (origin) to define the composition of records to be exported to a destination. The specification includes the fields, syntax e.g. USMARC and the address e.g. e-mail address, printer address, fax number etc.
Export Invocation

This service allows the target to “invoke” an export specification i.e. use the export specification to send a file of records in the required format to the given address. The parameters of this service include:

Parameter

Notes

Export specification name

The name of the Export spec. to be used.

Result set

The name of the result set - from a previous Query or Persistent Query.

Record IDs from the result set

The specific record Ids from within the record set - can be specified as a range or simply “ALL”.

Number of copies

The number of copies of each record required.

Estimated quantity and quantity so far

Gives an estimate of the number of records to be exported and how far through the list the process is.

Estimated cost and cost so far

An optional estimate of the cost of the records so far supplied.

Explain

Explain is a version 3 facility designed to maintain a searchable database of all the features of a Z39.50 implementation on a Z-server (target). The Z-client (origin) can interrogate this database and find out exactly what services and their basic characteristics are available at the target.  For instance the query types supported, Attribute sets, record syntaxes, Term lists (for browsing) extended services etc.  There is also provision for a text description of the databases available, when available, number of records, copyright information etc. The Explain facility should allow the Origin to understand exactly what the Z-server (target) can offer. This information can then be presented to the user and/or used to adjust the configuration of the Z-client (origin).  The intelligent Z39.50 client of the future will be able to query the database to be used and suggest the most appropriate way of searching it or automatically adjust the way that it presents a query.

Termination

The termination facility allows the Z-client (origin) or Z-server (target) to close down a Z-Association a reason for the close is given e.g. system problem, cost limits, security violation etc. The Z-client (origin) can also ask for a resource report as part of the close request i.e. how much money have I got left in the account?

Future

There have been many criticisms of Z39.50 in technical terms - the very extensibility of Z39.50 has meant that it could become hampered by an ever widening group of potential interested user communities. It is considered old-fashioned and complex because it is implemented at a fairly low level - requiring specific binary bits to be set by the program etc. More modern protocol methodologies are available and would be used if it were re-written. 

The most important thing about Z39.50 right now is that it exists as a standard and is affecting the way that libraries trade with each other and the services they offer their clients.  Should technical considerations force a re-think on how it should operate, from the librarians point of view the most important thing is that it should retain at least the functionality currently implemented. What is required is an open standard allowing seamless information retrieval and associated services from different databases.

Implications

Just as the Web created a new force within the IT industry - even a new industry, so the Z39.50 standard and associated extended services could revolutionise the library industry by creating a class of software products that can talk to any library system. In turn, the use of such products by individual users will mean libraries doing business directly with researchers. Libraries will be competing with each other for this business as it grows - and much of it will probably still be book based...We are already seeing stand alone products with Z39.50 and ILL facilities coming on to the market.

Next section: Z39.50 Structure Diagram