Norwegian Z39.50 Interest Group
http://www.norzig.no/
 

NorZIG Z39.50 Profile version 2.


Date: 2003-10-28
Editor: Ole Husby, BIBSYS.
Revisions:

0 As accepted by the NorZIG meeting 2002-09-25 2002-10-21 Ole Husby
1 Misprint corrected: The bib-1 diagnostic value for "Unsupported attribute combination" is 123, not 118 2003-10-28 Ole Husby

This document describes the NorZIG Z39.50 Profile Version 2, as accepted by the NorZIG meeting 2002-09-25.

Introduction
Scope
A. Common Requirements
B. Bibliographic Search and Retrieval
C. Holdings Information Search and Retrieval
E. Cross-domain Search and Retrieval
References

Introduction

The intended audience of this document are implementors of Z39.50 services in Norway and their partners and system suppliers.

Further information about the NorZIG activities is available from the NorZIG Web-site:
http://www.norzig.no/

The NorZIG Z39.50 Profile Version 2 supercedes the previous version:

The NorZIG Z39.50 Profile Version 2 is primarily based on the following international profiles:

The profiles listed here in turn references other relevant profiles and materials.

A separate document will give a detailed description of the relations between the present profile and the aforementioned profiles. [4]

Scope

The primary objective of the NorZIG profile is to facilitate interoperability between library systems in Norway, while being conformant to international profiles.

A secondary goal is to allow interoperating between library applications and relevant services within other domains of information services, where one should not expect search and present services to follow the detailed syntaxes that are common in the library domain, such as MARC formats. Museums and archives are prime example of such domains.

Access to services within the specialised fields of A&I (Abstracting and Indexing) databases, full text and similar services may require additional facilities, that are outside the scope of this profile.

The NorZIG profile is intended to cover requirements of the following functional areas:

A. Common Requirements
B. Search and Retrieval of Library Catalogues
C. Search and Retrieval of Holdings information
E. Cross-domain Search and Retrieval
For ease of reference, the same letters (A, B, C, E) are used for the functional areas as in the ONE-2 profile. Functional areas D (Ordering and Interlibrary Loans) and F (Update Service) in the ONE-2 profile are considered to be outside the scope of this profile.

Separate sets of specifications are described for each of the functional areas.

Note that the specifications within functional area C describe two distinct levels of requirements. These levels are not cumulative. I.e. support for the higher level does not imply support for the lower level. This terminology of levels is adopted for the purpose of easy alignment with the ONE-2 profile, and is not used in other areas of the profile.

All systems must support the Common Requirements of functional area A.

A. Common Requirements

Specifications pertaining to different functional areas imply other general requirements in addition to those specified here, e.g. transfer syntax and Z39.50 Services.

Protocol Version

Targets (Servers) and Origins (Clients) must support ISO 23950 i.e. Z39.50-1995 Version 3 [5]

Attribute Sets

Targets and Origins must support the Bib-1 attribute set, (i.e., process requests and responses that contain the OID for Bib-1). [6]

Targets and Origins must support the Bib-1 Diagnostic set. [7]

Initialisation Facility

Targets may limit access to Origins based on ID/Authentication parameters UserID and Password.
In case of denial, the Target must return a diagnostic from the Bib-1 diagnostic set, in the range 1010 to 1023.

Targets may limit access to Origins based on IP authentication.
In case of denial, the Target must return a valid Init response with the following diagnostic from the BIB-1 diagnostic set, 1016: "Init/AC: Blocked network address".

Termination Facility

Targets and Origins must support the Close Service.

ExplainLite Facility

Targets should return an ExplainLite XML document with configuration information in response when requested to do so as part of an Init Request. [8]

Targets should additionally make the same ExplainLite XML document available on a web server.

Character Set

Targets and origins must support ISO 8859-1:1998 Latin-1. This applies to character data within:

B. Bibliographic Search and Retrieval

Targets must support the Search service and the Present service as specified in this functional area. Additionally, targets should support the Scan service as specified in this functional area.

Search Service

Targets and Origins must support Query-type Type-1, i.e. RPN.

Targets must support the Database-names "default" and "xxdefault". In the case when a target includes a database that to some degree is an aggregation of logical sub-databases, it is recommended that these default names should designate this particular database.

Targets must support the Result-set-name parameter and should attempt to retain at least two named result sets for the duration of a session, if the Origin names at least two result sets.

A Z39.50 Origin must supply values for the Bib-1 attribute types Use and Structure. The Origin should supply values for the remaining four Bib-1 attribute types.

Targets must interpret (i.e. neither ignore nor substitute) the values supplied for all of those attribute types, which are submitted in a given query.

Targets must support the following values for Relation-, Truncation-, Completeness- and Position- attributes.

If one or more of those four attribute types are missing in a query, the Target may choose to substitute the values given above as default values for the missing attribute type - or reject the incomplete query with the following diagnostic from the Bib-1 diagnostic set, 123: "Unsupported Attribute Combination".

Note: The concepts of "fields" and "subfields" are not clearly defined in the context of the Z39.50 data model. Targets may therefore return the same hits, regardless of whether given Completeness and Position attributes refer to "fields" or "subfields".

The following Structure attribute values must be supported together with relevant Use attributes:

Note that in the case of Name normalised, the required syntax is last name, first name(s). Any spaces between the comma and the first name must be ignored by the Target.

Targets must support the following combinations of Bib-1 attributes:

Name Use Relation Position Structure Truncation Completeness
Personal name - normalized 1 3 3 101 1, 100 1
Corporate name 2 3 3 2 1, 100 1
Conference name 3 3 3 2 1, 100 1
Title - phrase 4 3 3 1 100 1
Title - word 4 3 3 2 1, 100 1
Title - first characters 4 3 1 1 1 1
Title - exact 4 3 1 1 100 3
Title series 5 3 3 2 1, 100 1
ISBN 7 3 3 2 1, 100 1
ISSN 8 3 3 2 1, 100 1
Local number 12 3 3 2 100 1
Dewey 13 3 3 2 1, 100 1
UDC 14 3 3 2 1, 100 1
Local class number 20 3 3 2 1, 100 1
Subject - phrase 21 3 3 1 100 1
Subject - word 21 3 3 2 1, 100 1
Subject - first characters 21 3 1 1 1 1
Subject - exact 21 3 1 1 100 3
Date of publication - year 31 3 3 4 100 1
National bibliography number 48 3 3 2 100 1
Author - normalized 1003 3 3 101 1, 100 1
Author - un-normalized 1003 3 3 102 1, 100 1
Author-name personal 1004 3 3 101 1, 100 1
Author-name corporate 1005 3 3 102 1, 100 1
Author-name conference 1006 3 3 102 1, 100 1
Any 1016 3 3 2 1, 100 1
Doc-id 1032 3 3 2 100 1
Possessing institution 1044 3 3 2 100 1

The requirement to support an attribute combination is not absolute, but should only apply in the case when the data type corresponding to the use attribute is present in the database. If not, the target must fail the search, and return the following diagnostic from the Bib-1 diagnostic set, 114: "Unsupported use attribute".

Targets are recommended to support additional combinations enumerated in the Bath Profile V1 requirements for Level-1 Bibliographic Search and Retrieval.

Present Service

Targets must support the following types of Preferred-record-syntaxes:

For each of these record syntaxes, targets must support the following Element-set-names (ESN):

When holdings data elements are supplied as part of a bibliographic record, they must conform to the NorZIG Holdings Profile Version 2. [9]

Targets must encode all records in ISO 8859-1:1998 Latin-1.

Scan Service

Targets supporting the Scan service must comply with the requirements in this section.

Targets must support the Database-names "default" and "xxdefault", c.f. the requirement for Search Service.

Targets must support the following combinations of Bib-1 attributes:

Name Use Structure
Personal name - normalized 1 101
Corporate name 2 2
Conference name 3 2
Title - phrase 4 1
Title - word 4 2
Title series 5 2
Dewey 13 2
UDC 14 2
Local class number 20 2
Subject - phrase 21 1
Subject - word 21 2
Author - normalized 1003 101
Author-name personal 1004 101
Author-name corporate 1005 102
Author-name conference 1006 102
Any 1016 2
Possessing institution 1044 2

The requirement to support an attribute combination is not absolute, but should only apply in the case when the data type corresponding to the use attribute is present in the database. If not, the target should fail the scan, and return the following diagnostic from the BIB-1 diagnostic set, 114: "Unsupported use attribute".

Target must support Step-size = 0, i.e. "do not skip any entries" and Position-in-response = 1.

Target must return the number of entries (hits) associated with each SCAN Term.

C. Holdings Information Search and Retrieval

The requirements in this area are based on the Z39.50 Holdings Schema Version 1.2 and the corresponding Holdings XML Schemas. [10]

Search and retrieval of bibliographic Holdings information is specified in two levels:

Targets must support the Use attribute number 1044 i.e. Possessing-Institution within bibliographic searches, as required in area B. The expected value of this attribute is a code (library symbol or other code) of the institution which possesses the document.

A two-step process can retrieve holdings information:

Note that Level-1 Holdings may be retrieved without the extra second step by using the Element Set name F (Full), whereas Level-2 Holdings require the second step.

Targets must support Level-1 Holdings, and should support Level-2 Holdings.

Level-1 Holdings

Level-1 supports retrieval of Minimal bibliographic level holdings information according to the NorZIG Holdings Profile Version 2. [9]

The Minimal bibliographic level holdings data must be returned within NORMARC or MARC 21.

Level-1 Retrieval of Holdings information is initiated by a Present Request where Record syntax = NORMARC or = MARC21 and ESN = B1.

Level-2 Holdings

Level-2 supports retrieval of Summary bibliographic level holdings information according to the Z39.50 Holdings Schema Element Set B2 summaryBibLevelHoldings.

The Summary bibliographic level holdings must be returned within an XML structure corresponding to the Z39.50 Holdings XML Schema for Element Set B2.

Level-2 Retrieval of Holdings information is initiated by a Present Request where Record syntax = XML and ESN = B2.

E. Cross-domain Search and Retrieval

the Cross-domain Searching Functional Area E is intended to support scenarios where the Target or the Origin does not support the exchange of MARC records, such as in museum systems.

Search service

The requirements for Functional Area B search service all apply, except the support of the attribute combinations.

For the Cross-domain search, Origins and Targets must support the following combinations of Bib-1 attributes:

Name Use Relation Position Structure Truncation Completeness
DC.Title - phrase 1097 3 3 1 1, 100 1
DC.Title - word 1097 3 3 2 1, 100 1
DC.Title - first characters 1097 3 1 1 1 1
DC.Title - exact 1097 3 1 1 100 3
DC.Creator - normalized 1098 3 3 101 1, 100 1
DC.Creator - un-normalized 1098 3 3 102 1, 100 1
DC.Subject - phrase 1099 3 3 1 1, 100 1
DC.Subject - word 1099 3 3 2 1, 100 1
DC.Subject - first characters 1099 3 1 1 1 1
DC.Subject - exact 1099 3 1 1 100 3
DC.Publisher 1101 3 3 1 1, 100 1
DC.Date 1102 3 3 2 100 1
DC.Identifier 1104 3 3 2 100 1

Present service

Dublin Core metadata elements are encoded according to the DC/RDF XML specification, that is available from the DCMI. [11]

The metadata will correspond to the Reduced (R) Element Set Name described in the Present Service specification in functional area B.

The DC/RDF XML information must be returned in response to a Present Request where Record Syntax =XML and Element Set Name=R. For the purpose of alignment with the ONE-2 profile, a Present Request where Record Syntax =XML and Element Set Name=F should be treated in the same way, however without holdings data.

Note: Record Syntax=XML and ESN=B2 must return Holdings XML Data.

Element Set Names are here used to distinguish between entirely different types of record syntaxes (e.g. DC/RDF and XML Holdings), which happen to share XML as encoding format.

References

[1] Norwegian Z39.50 profile Version 1.0.
http://www.norzig.no/profiles/norprof.html

[2] ONE-2 Profile v3 r2.
http://www.portia.dk/pubs/one2/Profiles/ProfileV3R2/ONE-2ProfileV3R2.pdf

[3] The Bath Profile: An International Z39.50 Specification for Library Applications and Resource Discovery. Release 1.1
http://www.nlc-bnc.ca/bath/bp-current.htm

[4] NorZIG Z39.50 profile Version 2. Relation to other profiles
http://www.norzig.no/profiles/profile2_diff.html

[5] ISO 23950 i.e. Z39.50-1995 Version 3.
http://lcweb.loc.gov/z3950/agency/1995doce.html

[6] Bib-1 Attribute Set.
http://lcweb.loc.gov/z3950/agency/defns/bib1.html

[7] Bib-1 Diagnostics.
http://lcweb.loc.gov/z3950/agency/defns/bib1diag.html

[8] The Explain-lite DTD.
http://www.one-2.org/technical/el_dtd.html

[9] NorZIG Holdings Profile Version 2
http://www.norzig.no/profiles/holdings2.html

[10] Z29.50 Holdings Schema Version 1.2.
http://lcweb.loc.gov/z3950/agency/defns/holdings.html

[11] An XML Encoding of Simple Dublin Core Metadata.
http://dublincore.org/documents/2001/04/11/dcmes-xml/