Profile Specifications

General Z39.50 Specifications Applying to All Functional Areas

Z39.50 Specifications

This section summarizes the general Z39.50 specifications to address the functional requirements addressed by the profile.

Protocol Version

The profile requires Version 2 or Version 3 of Z39.50-1995, depending on Functional Area and Conformance Level.  All implementations are encouraged to use Version 3, but in the near term, conformance to certain specifications prescribed by this profile is available to Version 2 implementations.

Z39.50 Objects

The profile uses a number of Z39.50 registered objects.  The following table summarizes all Z39.50 objects referenced in the profile's Functional Areas.

Object OID
bib-1 attribute set 1.2.840.10003.3.1
holdings attribute set 1.2.840.10003.3.16
bib-1 diagnostic set 1.2.840.10003.4.1
holdings schema 1.2.840.10003.13.7
eSpec-q 1.2.840.10003.11.3
UNIMARC record syntax 1.2.840.10003.5.1
MARC21 record syntax 1.2.840.10003.5.10
Simple unstructured records syntax (SUTRS) 1.2.840.10003.5.101
XML record syntax 1.2.840.10003.5.109.10

Support for these registered objects by Z-clients and Z-servers is specified in each of the Functional Areas. For information on Z39.50 registered objects, see the Z39.50 Maintenance Agency's Z39.50 Registry of Object Identifiers (see also Z39.50 Maintenance Agency).

Z39.50 Services

The profile specifies the use of the following  Z39.50 services:

See individual Functional Areas for specific requirements related to these Z39.50 services.

No additional services are required for conformance to this profile. Z-clients and Z-servers optionally may use other Z39.50 services.  Future releases of the profile may require additional services.

Standard Z39.50 Init Service negotiation procedures control the use of all services.

Init

Z-clients conforming to this profile may use the IDAuthentication parameters to transmit authentication information (e.g., userid and password). Z-servers conforming to this profile may or may not require authentication. The profile specifies no other security requirements. Z-clients may need to know in advance the authentication policy of a given server, and be prepared to provide values for userid and password.

Character Set Negotiation is required for Z-clients and Z-servers for particular Functional Areas.

Search: Query Type and Attribute Sets

The profile requires Z-clients and Z-servers to use Z39.50 Type 1 queries (i.e., general purpose Boolean query structures).

The Result-set-name parameter is required for Z-servers, and Z-servers must be able to retain at least two named results sets for the duration of a session.   Exceptional server situations may override the "two named results sets" requirement.

To accommodate the searching requirements for the three Functional Areas, the profile requires Z-clients and Z-servers to use one or more of the following attribute sets:

Object OID
bib-1 attribute set 1.2.840.10003.3.1
holdings attribute set 1.2.840.10003.3.16

Conformant Z-clients and Z-servers will support Attribute types and values according to individual Functional Areas. "Support" in this context means:

This means that all implementations conforming to this profile must have search capabilities for attribute types and values listed in each Functional Area and Conformance Level for which conformance is claimed. Z-clients and Z-servers may also use attribute types and values from other public or private attribute sets in addition to those required by this profile.

Complex keyword searches can be expressed using Boolean operators to connect one or more operands where the operands are constructed using the searches defined in these specifications. 

The bib-1 Attribute Set plays a primary role in this profile for both basic bibliographic searching and for cross-domain searching.  Semantics for most of the bib-1 attributes specified for support in this profile can be found in Attribute Set bib-1 (Z39.50-1995): Semantics (September 1995).  Not all current bib-1 attribute values, however, are defined in that document. However, the complete bib-1 Attribute Set is available at http://lcweb.loc.gov/z3950/agency/defns/bib1.html.

The following table summarizes the bib-1 Attribute Set types and values referenced in the Functional Areas A and B:

Attribute Type Attribute Values Attribute Names
Use (1) 4, 21, 31, 1003, 1007, 1016 title, subject heading, date of publication, author, identifier-standard, any
Relation (2) 1, 2, 3, 4, 5 less than, less than or equal, equal, greater than or equal, greater than
Position (3) 1, 3 first in field, any position in field
Structure (4) 1, 2, 101 phrase, word, normalized
Truncation (5) 1, 100 right truncation, do not truncate
Completeness (6) 1, 3 incomplete subfield, complete field

[NOTE:  I will update this table once we have finalized the search requirements in Functional Areas A&B.]

 

The following table summarizes the search types defined for Functional Areas A & B.

Fields Containing One or More Words
Search Type Functional Area A Functional Area B
  Level 0 Level 1 Level O Level 1
Keyword Title, Subject, Any Author, Title, Subject, Any    
Keyword with right truncation   Author, Title, Subject, Any    
First characters   Title, Subject    
First words   Title, Subject    
Unanchored normalized name Author Author    
Unanchored phrase        
Exact match   Author, Title, Subject    

One Word Fields
Search Type Functional Area A Functional Area B
  Level 0 Level 1 Level O Level 1
Exact match   Identifier; Date of Publication    

[NOTE:  I will update this table once we have finalized the search requirements in Functional Areas A&B.]

The Holdings Attribute Set is used for searches involving holdings information and is detailed in Functional Area B.

 
Present: Record Syntaxes

For interoperability, Z-clients and Z-servers must support two or more common record syntaxes.  Support of a record syntax means that for every record in a result set, the Z-server can deliver the record in a required record syntax.  Exceptional server situations may override this required syntax requirement (e.g., database temporarily not available).  Local policies may also restrict access to records in one or more specific record syntaxes to authorized users.  In such cases, the server should return an appropriate diagnostic.

Z-clients and Z-servers have different responsibilities in their support for record syntaxes.  Z-clients will support all syntaxes required in a Functional Area and at a given Conformance Level, while Z-servers will normally support only those syntaxes required for their business.

For Basic Bibliographic Retrieval (Functional Area A), the MARC21, UNIMARC, SUTRS, and XML record syntaxes are required depending on Conformance Level.   Regional, national, state, local, or project companion profiles may specify other Z39.50 registered MARC record syntaxes in addition to those required by this profile.  In the case where a user requests a record syntax (e.g., MARC21) and the Z-server only provides records in UNIMARC, the Z-server should return the appropriate diagnostic.  

[NOTE:  I will revise the above paragraph once we have finalized the retrieval requirements in Functional Areas A&B.]

Interoperability requires use of  standard character sets.

For retrieval of bibliographic holdings information (Functional Area B), XML Record Syntax is required.  Use of XML for bibliographic holdings information requires the use of a Z39.50/XML Schema.  The Z39.50/XML Holdings Schema is required.

See individual Functional Areas for specific requirements regarding record syntaxes.  Z-clients and Z-servers may support other registered Z39.50 record syntaxes in addition to those required by this profile. 

Diagnostic Messages

The profile requires that Z-servers return appropriate diagnostic messages from Diagnostic Set bib-1. To assist implementors in sending the appropriate diagnostic for an error condition, Appendix B contains a listing of bib-1 Diagnostics to use for specific error conditions.  In addition, Z-clients are encouraged to display usable and meaningful diagnostic messages to users.  To assist implementors, Appendix B also includes suggested wording for diagnostic messages meant to be read by a user.  

For servers that provide records in selected record syntaxes for specific authorized users, a new diagnostic has been proposed to the Maintenance Agency, bib-1 Diagnostic #1070: "User not authorized to receive this record in requested syntax.”

The Maintenance Agency has added Diagnostic #1069: "No syntaxes available for this request."  This diagnostic should be used in the case where a Z-server conforms to the Profile in supporting either MARC21 or UNIMARC and receives a request for a non-supported record syntax.  Z-Servers should not return a record in an alternative record syntax until requested by the Z-client.

[NOTE:  We will need to decide whether to reproduce the Appendix B from the Bath Profile here or just reference it.]

Conformance

Z-clients and Z-servers may claim conformance to one or more Functional Areas at specific Conformance Levels and be in compliance with this profile. Requirements and specifications for each Functional Area are compatible. While Functional Areas differ in their focal concern, it is likely that conformance to certain Functional Areas may imply conformance to other Functional Areas (i.e., to support a particular Functional Area may require conformance to one or more other Functional Areas).

This section identifies required Z39.50 specifications for Z-clients and Z-servers to claim conformance for each of the Functional Areas at a particular Conformance Level.  This release specifies conformance for:

The goals, objectives, and detailed specification of this profile preclude Z-clients and Z-servers from "default" behavior.  Z-clients are required to form queries using all attribute types and values listed for specific searches.  Z-servers are required to execute the search specified in the query and are not to do a more general or a more specific search than the one specified in the query (e.g., Z-servers will not execute a Name search if the query specifies an Author search and vice versa).

Profile-compliant servers will occasionally receive search queries from non-conformant clients that may not specify all 6 attributes. Where it is feasible to interpret the intent of the search, the server should not fail the query but rather perform the search using the most appropriate values for the missing attributes. The values should comply with the values defined in the profile for the type of search being performed.

 

[end]