Union Catalogue Profile
Internationally Registered Profile to be used with ISO 23950
(Z39.50 Information Retrieval Protocol) Extended Service for Update
Last updated June 1999
This Profile is intended for use with the ISO 23950 (Z39.50 Information Retrieval Protocol) standard to allow a data creator to update a database in a distributed environment using the Database Update Extended Service of the standard.
It was developed under the auspices of the IT/19 Committee (a joint committee of Standards Australia and Standards New Zealand) by Janifer Gatenby from Stowe Computing Australia (now GEAC Computing) and Lesley Bezear and Judith Pearce from the National Library of Australia.
Table of Contents
1. Introduction
2. Record
Insert
3. Record Replace
4. Element Update
5. Record
Delete
6. Special Update
7. Record Locking
8. Querying the
Task Package
9. Diagnostic List
10. Notes on Other Areas of Z39.50
11. Conformance
12. Document
History
Appendix 1: Scenarios
Appendix 2: References
Appendix 3: Staged
Base-Level Conformance
Appendix 4: Holdings
Scenarios
1. Introduction
1.1 Overview
This Profile is intended for use with the ISO 23950 (Z39.50 Information Retrieval Protocol) standard to allow a data creator to update a database in a distributed environment using the Database Update Extended Service of the standard.
The Z39.50 standard specifies the formats and procedures for the exchange of messages when an origin searches a target database and retrieves records. This includes formats and procedures for initialising a Z39.50 session and for control by the target of access, and other procedures related to the management of a search and retrieval session.
The Z39.50 Database Update Extended Service specifies the formats and procedures for the exchange of messages when, at some point after initialising a Z39.50 session, the origin requests that the target update a database. The target decides whether and when to initiate the appropriate database operation to complete the task. The task itself is not considered part of the Extended Service operation. The response from the target which completes the operation does not necessarily signal completion of the task, which may have a lifetime beyond the Z39.50 association.
The justification for incorporating update as an extension to a standard for search and retrieval is based on the recognition that the update function is often dependent on searching. Database searches are frequently done at several stages in the update process, for example a preliminary search to determine whether a record already exists, followed by the decision to create or copy a record. The database may also be searched during creation or update of a record, to check related data.
The need for this profile to assist implementors of the Z39.50 Database Update Extended Service originated from work by Janifer Gatenby from Stowe Computing Australia (now GEAC Computing) and Lesley Bezear and Judith Pearce from the National Library of Australia under the auspices of the IT/19 Committee, a joint committee of Standards Australia and Standards New Zealand.
The National Library of Australia operates a national union catalogue which is maintained as a cooperative effort by the Australian library community. Libraries add holdings and original cataloguing data to the union catalogue as part of the process of obtaining records for their local library management systems.
The aim of the work team was to identify a suitable protocol for integrating maintenance of the union catalogue into creator workflows in such a way that creators could perform all creation/ update processes within their own workstation/ systems environment using local client software. The Z39.50 standard was found to be suitable for this purpose. Australian libraries have begun increasingly to use Z39.50 client software for obtaining copy cataloguing data from external databases. With a few minor exceptions, the standard already contains the full range of functionality for developers to enhance this process to enable updating of the union catalogue and the local system at the same time.
While the Z39.50 Database Update Extended Service is rich in update functionality and enables update to be integrated fully with searching, decisions as to how specific update functions might be implemented are left open in the standard. This profile identifies appropriate options and parameters for accomplishing the full range of update functions required to be supported in the union catalogue environment.
To the extent that it provides a generic framework for database update, the profile should be of use to any implementor of the Z39.50 Database Update Extended Service. It supplements the base standard by clarifying the differences between the Z39.50 record insert, record replace and element update actions and the conditions under which each should be used. It also defines procedures for addressing a range of update scenarios not addressed specifically by the base standard. These include:
- Addressing concurrent update through version control alone, or through record locking via the update schema.
- Exchanging messages relating to duplicate detection and control.
- Reviewing submitted records.
- Merging linked records when a duplicate record is deleted.
- Performing batch edit / replaces.
A comprehensive list of diagnostic messages is also included in the profile as an adjunct to those in the base standard.
1.2 Area of Use
For libraries and library system vendors, the major area of use for this profile will be the provision of support for a range of business transactions requiring a library to update a national union catalogue, and/or a consortium catalogue, at the same time as updating its local catalogues. In the Internet environment, union catalogues are still a very efficient location tool. Since multi-target searches strike performance degradation as the number of target databases increase, such searches are inferior in coverage to a union catalogue search and the results may not be subjected to duplicate or authority control.
Features of the profile specific to union catalogue implementations are:
- The conformance tables.
- The logical databases needing to be supported (limited to bibliographic, authority and holdings databases in MARC format).
- The business transactions needing to be supported (these are listed in Appendix 1).
There are significant benefits for libraries and developers in using this profile to support update in a union catalogue environment:
· Reduced training costs and increased productivity. The data creator only has to be familiar with one user interface.
· Efficiencies in local software maintenance and configuration. As organisations migrate to client/ server applications, multiple clients will not have to be installed at the user's desktop to support access to both the local system and the union catalogue.
· Increased modularity. Use of Z39.50 as the internal protocol for searching and update will allow modular development and opportunities for product substitution.
· Client/ server access to legacy databases. Legacy databases can be made accessible and updatable as Z39.50 targets without needing to upgrade the underlying database management system.
· Increased data security. Since the targets interaction with the origin involves only receipt and delivery of protocol transactions, the origin is prevented from directly initiating update programs on the target and thus has no access to an operating system command line.
· Update of multiple databases with less effort. At present, when an organisation wishes to update multiple databases, the organisation is generally obliged to do this through a multistep process. In some cases, local data is selected for extraction in batches and then sent to an external database. In other cases, the data is first created on the external database and later extracted and sent to the local database. More complex cases also occur, where for instance creation occurs on one system but changes occur on both systems, with corresponding effort in keeping the databases synchronised. Use of the Profile avoids this duplication of effort and complexity through allowing a single transaction to update multiple databases.
· More timely update. The Profile allows virtually real-time update of multiple databases and virtually immediate resolution by the origin of any errors or rejections. It also provides a framework for the provision of error messages to the origin for updates performed in batch or background mode.
· Support for richer functionality. The Profile supports, optionally, the processes of merge and global replace, which cannot normally be controlled through batch updates. It also allows the target to provide immediate reports to the data creator on update errors and results of any duplicate detection processes.
1.3 Z39.50 Specifications
The Z39.50 protocol versions, objects and services needing to be supported by origin and target for conformance with the Union Catalogue Profile are specified in Section 11, Conformance. It is recognised that implementors may wish to move towards conformance in stages. A set of possible priorities for staged implementation is included in Appendix 3.
1.4 Development Process
National Library of Australia and IT/19 members first met in July 1996 to determine the feasibility of using the Z39.50 Database Update Extended Service to support update in a union catalogue environment. A draft profile was developed and reviewed by interested parties from the user and vendor communities in Australia and New Zealand before being made available for general comment by the Z39.50 Implementors Group (ZIG) The concept was favourably received at the ZIG Meeting in October 1996 and a second version of the profile was prepared for the April 1997 meeting, incorporating changes resulting from the initial round of comments. A key comment from implementors was the need to incorporate an optional record locking mechanism.
Following the April 1997 meeting, the ZIG undertook to develop a solution for record locking and to review the solutions for record merge and global replace. The outcome was an Update Extended Service Proposal for discussion at the August 1997 ZIG meeting. This proposal addressed the record locking requirement through a new update schema and incorporated several minor changes to the base standard to support a new merge qualifier and to allow a record to be returned with a diagnostic message. A solution for global update was presented separately.
The outcome of the August 1997 ZIG meeting was a new update proposal introducing a new action qualifier defined as an external and a new special update function that supported both merge and batch edit / replace. Global update was renamed batch edit / replace to more adequately reflect its role. The update proposal also allowed for supplementary diagnostics and defined the update schema.
The action qualifier, originally restricted to special update, was later extended to apply to any update function so that it could be used to specify detailed replacement parameters in record replace and element update actions.
A version of the profile was issued in March 1998 incorporating the changes outlined above. This version was approved by ISO TC 46/ SC 4 as an internationally registered profile.
1.5 Status of the Current Version of the Profile
This version of the profile has been updated to include the object identifiers assigned by the Z39.50 Maintenance Agency and minor editorial corrections.
2. Record Insert
Record Insert is used:
- When the origin has no knowledge of the contents of the target database
- When the origin has determined that a record does not already exist on the target database.
2.1 Origin Request
|
Element Name |
Contents |
|
referenceId |
Optional - supplied by origin |
|
function |
Create |
|
packageType |
Update |
|
packageName |
ex: 199607031045 |
|
userId |
ex: NU:46 |
|
retentionTime |
ex: 7 days |
|
permissions |
Omitted (optional) |
|
description |
Omitted (optional) |
|
taskSpecificParameters |
{Z39-50-extendedServices5} esRequest |
|
recordInsert |
|
ex: UC-B (bibliographic record) |
|
Omitted or record insert schema |
|
set containing record ID, version identifier (date / time stamp) and title - default for successful update |
|
used for record review notes or does not duplicate lists |
|
|
|
|
|
optional, i.e. not required for a MARC record insert because within the record itself |
|
optional, i.e. not required for a MARC record insert because within the record itself |
|
not used |
|
waitAction |
wait if possible ( 1-10 records) do not wait |
|
elements |
full - requesting that the target should return all task package elements in the update response where applicable |
|
otherInfo |
Reference id is optional, but package name is mandatory if the client wants to later modify or delete a task package.
2.1.1 Action Qualifier
The action qualifier may be used for duplicate detection or record review. See below.
2.1.2 Duplicate Detection
The "does not duplicate list" allows the client to convey to the server that certain records retrieved in a search had been considered and rejected before this record was created. This information may be used by the target to prevent the supply of potentially irritating diagnostics that could cause an end user to ignore more important diagnostics. This list could also be managed by the client to discard such messages that arrived from the server.
If a record insert action contains only one record, then the does not duplicate list may be sent in the action qualifier using the nonDupRecordId field from the record structure illustrated in the table below. Where multiple records are sent in one request, then GRS-1 record syntax with the record insert schema should be used.
The structure for the Record Insert record ( 1.2.840.10003.10.9) is as follows:
|
Element |
Occurrence |
Repeatable |
Datatype |
|
recordWrapper |
Mandatory |
no |
RecordWrapper |
|
nonDupRecordId |
Mandatory if recordReviewCode absent |
yes |
InternationalString |
|
recordReviewCode |
Mandatory if nonDupRecordId absent |
no |
InternationalString |
|
recordReviewNote |
Optional |
no |
InternationalString |
Definition of RecordWrapper
|
Element |
Occurrence |
Repeatable |
Datatype |
|
schemaId |
Optional |
no |
ObjectIdentifier |
|
record |
Mandatory |
no |
EXTERNAL |
2.1.3 Holdings Information
Holdings information in the form of summary statements or full holdings details could be supplied either:
- Via a MARC field in the bibliographic record
- Via separate holdings record (for example, in the USMARC Holdings Format)
- Via the OPAC schema currently under development
For conformance with the Union Catalogue Profile, the origin must be able to supply holdings as part of the bibliographic record and the target must be able to support the update of holdings supplied as part of a bibliographic record for the specific MARC variant supported.
Support for a separate MARC holdings record or for the OPAC schema is optional.
If supplied as MARC fields in a bibliographic record, then record replace rather than record insert would be used where the bibliographic record already exists on the target. If supplied as a separate record, the control number for the parent bibliographic record must also be supplied (for example, in USMARC Holdings Records, field 004 is used to provide the control number of the parent bibliographic record).
When multiple sets of holdings information are supplied in a bibliographic record or OPAC schema, the target must be able to process each set according to the instructions in the update request.
Inconsistencies within a specific MARC variant in the semantics for supplying holdings information as part of a bibliographic record will need to be resolved outside the Profile. For instance, USMARC targets will need in the short-medium term to handle the fact that holdings may be supplied in a locally defined field (e.g., 984 in Australian implementations) to circumvent limitations of embedded holdings information in the USMARC record. UNIMARC, targets will need to handle the fact that holdings may be supplied in one of the National Use Block fields 9--.
2.1.4 Distributed Review
If the origin wishes to signal that a record being updated should be reviewed by another party, this can be done on a record by record basis for individual supplied records within an update request.
If a record insert action contains only one record, then the review messages may be sent in the action qualifier using the record insert structure as illustrated in the table above under section 2.1.2 without the record wrapper. Where multiple records are sent in one request, then GRS-1 record syntax with the record insert schema as illustrated above should be used.
2.2 Target Response
|
Element Name |
Contents |
|
referenceId |
optional - supplied by origin |
|
operationStatus |
Done |
|
diagnostics |
only if failure |
|
taskPackage consisting of: |
{Z39-50-recordSyntax (106)} taskPackage |
|
Update |
|
ex: 199607031045 |
|
ex: NU:46 |
|
ex: 7 days |
|
Omitted |
|
Omitted |
|
ex: NU46:23 |
|
ex: 19960703104734 |
|
0 (pending) 1 (active) |
|
ex: Diagnostic record, format extServices, permission 1 (id not authorised) |
|
update taskPackage |
|
recordInsert |
|
ex: UC-B (bibliographic record) |
|
Omitted |
|
as per request |
|
Omitted |
|
success |
|
if applicable |
|
|
|
see table under Error Message Handling |
|
as supplied by target |
|
success |
|
see table under Error Message Handling |
|
otherInfo |
Omitted - This data element is returned with the update response which may be given before the update has actually occurred. When this happens, the origin will later use search to access records in the task package. For this reason, information relating to records in the task package must be contained within the task package parameters and hence this data element is of limited value in an update response. |
2.2.1 Background or Batch Processing
The target has control over the timing of the update if the origin request includes the parameter "wait if possible" or "do not wait". If the target receives the parameter "wait" and cannot process the update interactively, then a diagnostic should be sent immediately in the update response. When the target chooses not to process interactively, the update response indicates this via the task status parameter. When the update is completed, the target will update the task package within the extended services database held on the target. When the origin (client) receives an update response with the task (package) status set to pending or active, it notes that it should check on this later via a client defined timetable. The origin (client) later generates a search request / present request on the extended services database to retrieve updated update responses. See Section 8, Querying the Task Package.
2.2.2 Diagnostic Messages
General extended services / update
Validation messages
Update
messages
Authority Control messages
Duplication messages
Holdings
error messages
2.2.3 Error Message Handling
The target may return a message alone, multiple messages, or it may return a record accompanied by one or more messages. A single message is used when the update has been accepted with nothing else to report (e.g. message 950). When a target returns a record, it is because the current database record is different from that supplied. Additional information within the diagnostic message is used by the target to indicate to the origin which parts of the record have changed, so that the origin can use this information, for example to highlight changed data.
|
Case |
recordOrSurDiag |
supplementalDiagnostics |
|
Record accepted unmodified |
Diagnostic 950 (contains record ID + version identifier in additional info) |
blank |
|
Record not accepted because invalid |
Full record |
Diagnostic 933 and / or 935 and / or 938 and / or 943 |
|
Record not accepted because a suspect duplicate |
Full record - existing database record |
Diagnostic 970 |
|
Record accepted but modified |
Full record |
Authority control 980-985 |
|
Record accepted but suspect duplicate |
Full record - existing database record |
Diagnostic 971 or 972 |
|
Record queued or in process |
Record ID plus title |
blank |
3. Record Replace
Record replace is used for the following types of changes:
- Field insert
- Field delete
- Field replace where there is more than one field of the same tag name in the record, where more than one field is being updated and optionally for any other type of field replace
- Holdings insert, replace or delete if supplied as MARC fields in a bibliographic record where the bibliographic record already exists on the target
3.1 Origin Request
|
Element Name |
Contents |
|
referenceId |
optional - supplied by origin |
|
function |
Create |
|
packageType |
Update |
|
packageName |
ex: 199607031045 |
|
userId |
ex: NU:46 |
|
retentionTime |
ex: 7 days |
|
permissions |
Omitted |
|
description |
Omitted |
|
taskSpecificParameters |
{Z39-50-extendedServices5} esRequest |
|
recordReplace |
|
ex: UC-B (bibliographic record) |
|
Omitted or update schema or edit / replace schema |
|
set containing record ID, version identifier (date / time stamp) and title to be used for successful update |
|
Optional - Edit / replace record or update schema |
|
Although the standard says that a full record is necessary, it could be permissible for some single field additions or changes to supply a very brief record, e.g. with record ID, version identifier (date / time stamp) and title and the field being added or changed. The action qualifier is mandatory in this case. |
|
|
|
<record ID> More than one per task package not recommended |
|
version identifier (date / time stamp) |
|
optional |
|
waitAction |
wait if possible ( 1-10 records) |
|
elements |
full - requesting that the target should return all task package elements in the update response where applicable |
|
OtherInfo |
Omitted |
3.1.1 Action Qualifier
The edit / replace record can be used to convey to the target the exact nature of changes that have been made to a record. Without the qualifier, the target would assume that any fields not in the record supplied by the origin are to be deleted. This may not be the intention of the origin that may be unaware that the record it received was not a full record, perhaps having been obtained from an unrelated search that used an unknown element set. In this situation, the target takes risks when accepting a full record but how the target copes with this (e.g., via comparison and merge routines or bumping hierarchies) is outside the scope of the profile.
Where a record replace contains only one record, the Action qualifier can contain an edit / replace record relating to that one record. Where there are multiple records in a single record replace transaction, the records can be sent using GRS-1 as record syntax with the edit / replace schema.
Any modification to a record can be achieved by a record replace, but not all modifications can be achieved by an element update. Those that can only be achieved by a record replace are:
- Field insert (FI)
- Field delete (FD)
Other Edit / replace types that are valid are:
- Field replace (FR)
- Subfield insert (SI)
- Subfield delete (SD)
- Subfield replace (SR)
- Indicator change (IC)
The following tables list the elements of the Edit / replace record (1.2.840.10003.10.10) that are applicable in a record replace.
|
Element |
Occurrence |
Repeatable |
Datatype |
|
persistentResultSetPackageName |
Omitted |
No |
|
|
numberOfRecords |
Omitted |
No |
|
|
creationDateTime |
Omitted |
No |
|
|
reviewCode |
Optional |
No |
InternationalString |
|
reviewNote |
Optional |
No |
InternationalString |
|
changeDataInfo |
Mandatory |
Yes |
Definition of changeDataInfo
|
Element |
Occurrence |
Repeatable |
Datatype |
|
fieldIdentifier |
Optional - all types |
No |
|
|
oldValue |
Mandatory - all types except FI, SI |
No |
|
|
oldValueTruncationAttribute |
Optional - all types except FI & SI |
No |
|
|
conditionalField |
Omitted |
No |
|
|
conditionalValue |
Omitted |
No |
|
|
conditionalTruncationAttribute |
Omitted |
No |
|
|
newValue |
Mandatory - FI, SI |
No |
|
|
editReplaceType |
Mandatory - all types |
No |
|
|
case |
Omitted |
No |
A separate changeDataInfo record should be included for each occurrence of a field to be changed.
Field identifier includes field tag and optionally field sequence number, subfield tag and sequence number. Sequence number for a field applies to the occurrence of a field in a record and not to the
sequence number of the field in relation to the record as a whole. For example, in a USMARC record a 650 field (topical subject heading) might be the second 650 in a record and the 15th field in a record. The field sequence number is 2 in this case. Conversely, sequence number in relation to a subfield counts the relative position of the subfield in relation to the field as a whole. The valid formats for Field identifier are:
<tag>/<seq>:<sf>/<seq>
<tag>:<sf>/<seq>
<tag>:<sf>
<tag>/<seq>
<tag>
In the absence of a sequence number, the default would be to change or delete all occurrences of the specified field or field / subfield which match the specified old value. For a subfield insert, the subfield should be placed on the end of the field. For a field insert, the target may choose where to insert the field within the record.
The edit / replace record is also used in element update and special update, see sections 4.1.1 and 6.1.2.
3.1.2 Holdings Information
If holdings information is sent via MARC fields in a bibliographic record, then the action qualifier may be used to specify the required action (field insert/ field replace/ field delete). In the absence of an action qualifier, the full bibliographic record must be supplied.
3.1.3 Concurrent Update
It is possible for an origin to obtain a copy of a record and subsequently send an update transaction for that record, which has in the mean time been independently updated. Accurate version control of records can be used to avoid this type of incorrect updating. Another method of control is via record locking which assigns an exclusive update option to a particular identified user, optionally for a specific time period. The Profile does not assume that every target would support record locking. See Section 7. Record Locking for specific details.
To control updating, the supplementary identification is used to indicate which version of the record is being changed and the edit / replace record is used to identify which fields of the record are being changed, deleted or inserted. When the target sends records in response to search or present requests, the version identifier (e.g. field 005 in USMARC and UNIMARC) is always sent containing the date and time qualifier of the last update of that record on the target database. The origin must not change this field. It is returned with the record for modification, together with the new data within the supplied records data area and also in the supplementary id field. If the version identifier information (i.e. the date / time stamp) is the same as the targets database record, the target can process the transaction with no further check. If not, then the target uses the edit / replace record, containing the identification of fields and their original contents to determine whether or not it is safe to process the update.
In the scenario where the target accepts update transactions from devices outside the Z39.50 update protocol as well as Z39.50 update transactions, the version identifier (date / time stamp) can be used to control the concurrent update problem. For example, a dumb terminal might be in the process of updating a record, causing a record lock on the target. A Z39.50 update request arrives and is either queued and sent to the task package or the update request is failed with error message 956 - Record replace or element update rejected - record protected or locked by another user. If it is queued, either the record update will fail because of a version conflict with the date / time stamp or, if the terminal released the record without updating it, the update would process.
Note that the update schema may be used even when the target does not support record locking. It is used by the target in a search or present response to convey in an explicit way the record id and version in record formats that do not contain these elements. Some targets may not supply a record suitable for update in a normal search or present response, but will supply it when the request indicates the preferred record syntax of GRS-1 with the update schema. See Section 7 - Record Locking for details on the update schema.
3.2 Target Response
|
Element Name |
Contents |
|
referenceId |
optional -supplied by origin |
|
operationStatus |
Done |
|
diagnostics |
only if failure |
|
taskPackage consisting of: |
{Z39-50-recordSyntax (106)} taskPackage |
|
Update |
|
ex: 199607031045 |
|
ex: NU:46 |
|
ex: 7 days |
|
Omitted |
|
Omitted |
|
ex: NU46:23 |
|
ex: 19960703104735 |
|
0 (pending) 1 (active) 2 (complete) 3 (aborted) |
|
ex: Diagnostic record, format extServices, permission 1 (id not authorised) |
|
update taskPackage |
|
recordReplace |
|
ex: UC-B (bibliographic record) UC-H (holdings record) UC-A (authority record) |
|
Omitted or update schema |
|
as per request |
|
as supplied by client |
|
success partial failure |
|
if applicable |
|
|
|
see table under Error Message Handling |
|
as supplied by client |
|
success |
|
see table under Error Message Handling |
|
otherInfo |
Omitted |
3.2.1 Diagnostic Messages
General extended services / update
Validation
Update
Authority Control
Holdings
3.2.2 Error Message Handling
|
Case |
recordOrSurDiag |
supplementalDiagnostics (examples) |
|
Record replace accepted unmodified |
Diagnostic 953 (contains record ID and version identifier in additional info) |
blank |
|
Record replace not accepted because invalid |
Full record |
Validity 933, 935, 938 Update 943, 944, 945, 955 |
|
Record replace not accepted because version conflict |
Full record from database |
Diagnostic 964, 965 |
|
Record replace not accepted because of procedural error |
Diagnostic 1040-1047, 957, 967 |
|
|
Record replace not accepted because unavailable |
Diagnostic 968, 956, 966, 968 |
|
|
Record replace accepted but modified |
Full record |
Authority control 980-985 Validity 920-932, 934, 936-937, 939-942 Update diagnostics 954 |
|
Record replace queued or in process |
Record ID plus title |
blank |
4. Element Update
Element Update is used for:
- changing a field
- changing the lock status of a record
When used for changing a field in a supplied record, element update cannot be used for inserting or deleting fields. It should be avoided where there are multiple occurrences of the same field because there is no way of specifying the value to be replaced. Record replace should be used in these cases.
4.1 Origin Request
|
Element Name |
Contents |
|
referenceId |
optional - supplied by origin |
|
function |
Create |
|
packageType |
Update |
|
packageName |
ex: 199607031045 |
|
userId |
ex: NU:46 |
|
retentionTime |
ex: 7 days |
|
permissions |
Omitted |
|
description |
Omitted |
|
taskSpecificParameters |
{Z39-50-extendedServices5} esRequest |
|
elementUpdate |
|
ex: UC-B (bibliographic record) |
|
Omitted or update schema or edit / replace schema |
|
set containing record ID, version identifier and title to be used for successful update |
|
Optional - Edit / replace record or update schema |
|
Single field being changed |
|
|
|
<record ID> More than one per task package not recommended |
|
version identifier (date / time stamp) |
|
Optional |
|
waitAction |
wait if possible ( 1-10 records) |
|
elements |
full - requesting that the target should return all task package elements in the update response where applicable |
|
OtherInfo |
Omitted |
4.1.1 Action Qualifier
In the absence of an edit / replace record in the action qualifier, the target will replace the existing field in the database record with the field in the supplied record. If there is more than one occurrence of the supplied field, the target will respond with an appropriate diagnostic (955).
Alternatively, an action qualifier may be used to specify the sequence number of the field to be changed and to supply a copy of the existing field in the database record for correlation purposes.
Where only one record is included in an element update request, the action qualifier can contain an edit / replace record detailing the nature of changes made. In this case, the supplied record need only include record ID and version identifier (date / time stamp). Where multiple records are supplied in an element update request and the records can be sent using GRS-1 as syntax with the edit / replace schema and the action qualifier should be left blank.
The edit / replace record can be used to convey to the target the exact nature of changes that have been made to a record. Edit / replace types valid for Element update are:
- Field replace (FR)
- Subfield insert (SI)
- Subfield delete (SD)
- Subfield replace (SR)
- Indicator change (IC)
- Data string change (DC)
The following table lists the elements of the Edit / replace record (1.2.840.10003.10.10) that are applicable in an element update.
|
Element |
Occurrence |
Repeatable |
Datatype |
|
persistentResultSetPackageName |
Omitted |
No |
|
|
numberOfRecords |
Omitted |
No |
|
|
creationDateTime |
Omitted |
No |
|
|
reviewCode |
Optional |
No |
InternationalString |
|
reviewNote |
Optional |
No |
InternationalString |
|
changeDataInfo |
Mandatory |
Yes |
Definition of changeDataInfo
|
Element |
Occurrence |
Repeatable |
Datatype |
|
fieldIdentifier |
Optional - all types |
No |
|
|
oldValue |
Mandatory - all types except SI |
No |
|
|
oldValueTruncationAttribute |
Optional - all types except SI |
No |
|
|
conditionalField |
Omitted |
No |
|
|
conditionalValue |
Omitted |
No |
|
|
conditionalTruncationAttribute |
Omitted |
No |
|
|
newValue |
Mandatory |
No |
|
|
editReplaceType |
Mandatory - all types |
No |
|
|
case |
Omitted |
No |
Field identifier includes field tag and optionally field sequence number, subfield tag and sequence number. Sequence number for a field applies to the occurrence of a field in a record and not to the
sequence number of the field in relation to the record as a whole. For example, in a USMARC record the a 650 field (topical subject heading) might be the second 650 in a record and the 15th field in a record. The field sequence number is 2 in this case. Conversely, sequence number in relation to a subfield counts the relative position of the subfield in relation to the field as a whole. The valid formats for Field identifier are:
<tag>/<seq>:<sf>/<seq>
<tag>:<sf>/<seq>
<tag>:<sf>
<tag>/<seq>
<tag>
In the absence of a sequence number, the default would be to change or delete all occurrences of the specified field or field / subfield which match the specified old value. For a subfield insert, the subfield should be placed on the end of the field.
The edit / replace record is also used in record replace and special update, see sections 3.1.1 and 6.1.2.
4.2 Target Response
|
Element Name |
Contents |
|
referenceId |
optional - supplied by origin |
|
operationStatus |
Done |
|
diagnostics |
only if failure |
|
taskPackage consisting of: |
{Z39-50-recordSyntax (106)} taskPackage |
|
Update |
|
ex: 199607031045 |
|
ex: NU:46 |
|
ex: 7 days |
|
Omitted |
|
Omitted |
|
ex: NU46:23 |
|
ex: 19960703104735 |
|
0 (pending) |
|
ex: Diagnostic record, format extServices, permission 1 (id not authorised) |
|
update taskPackage |
|
elementUpdate |
|
ex: UC-B (bibliographic record) |
|
Omitted or update response |
|
as per request |
|
as per request |
|
success |
|
if applicable |
|
|
|
see table under Error Message Handling |
|
as supplied by client |
|
success |
|
see table under Error Message Handling |
|
otherInfo |
Omitted |
4.2.1 Diagnostic Messages
General extended services / update
Validity
Update
Authority
control
Holdings
4.2.2 Error Message Handling
|
Case |
recordOrSurDiag |
supplementalDiagnostics (examples) |
|
Element update accepted unmodified |
Diagnostic 953 (contains record ID and version identifier in additional info) |
blank |
|
Element update not accepted because invalid |
Validity 933, 935, 938 |
|
|
Element update not accepted because version conflict |
Full record from database |
Diagnostic 964,965 |
|
Element update not accepted because of procedural error |
Diagnostic 1040-1047, 957, 967 |
|
|
Element update not accepted because unavailable |
Diagnostic 956, 966, 968 |
|
|
Element update accepted but modified |
Full record |
Authority control 980-985 |
|
Element update queued or in process |
Record ID |
blank |
5. Record Delete
Record delete is used to delete a known record.
5.1 Origin Request
|
Element Name |
Contents |
|
referenceId |
optional - supplied by origin |
|
function |
Create |
|
packageType |
Update |
|
packageName |
ex: 199607031045 |
|
userId |
ex: NU:46 |
|
retentionTime |
ex: 7 days |
|
permissions |
Omitted |
|
description |
Omitted |
|
taskSpecificParameters |
{Z39-50-extendedServices5} esRequest |
|
recordDelete |
|
ex: UC-B (bibliographic record) |
|
Omitted |
|
set containing version identifier and record ID for successful transactions |
|
Omitted - not applicable for a record delete |
|
Records can include minimal info, e.g. record ID, version identifier (date / time stamp) and title |
|
|
|
<record ID> |
|
version identifier (date / time stamp) |
|
Omitted |
|
waitAction |
wait if possible ( 1-10 records) do not wait |
|
elements |
full - requesting that the target should return all task package elements in the update response where applicable |
|
OtherInfo |
Omitted |
5.1.1 Action Qualifier
The action qualifier is not used for record delete.
5.1.2 Deleting holdings information
If holdings are supplied as MARC fields in a bibliographic record, then record replace rather than record delete should be used to request the deletion of holdings on the target. Holdings can only be deleted through record replace by using the edit / replace schema.
5.2 Target Response
|
Element Name |
Contents |
|
referenceId |
optional - supplied by origin |
|
operationStatus |
Done Accepted Failure |
|
diagnostics |
only if failure |
|
taskPackage consisting of: |
{Z39-50-recordSyntax (106)} taskPackage |
|
Update |
|
ex: 199607031045 |
|
ex: NU:46 |
|
ex: 7 days |
|
Omitted |
|
Omitted |
|
ex: NU46:23 |
|
ex: 19960703104735 |
|
0 (pending) |
|
ex: Diagnostic record, format extServices, permission 1 (id not authorised) |
|
update taskPackage |
|
recordDelete |
|
ex: UC-B (bibliographic record) |
|
Omitted |
|
as per request |
|
Omitted |
|
success |
|
if applicable |
|
|
|
see table under Error Message Handling |
|
Omitted |
|
success |
|
see table under Error Message Handling |
|
otherInfo |
Omitted |
5.2.1 Diagnostic Messages
General extended services / update
Update
Deletion
Holdings
5.2.2 Error Message Handling
|
Case |
recordOrSurDiag |
supplementalDiagnostics |
|
Record delete accepted unmodified |
Diagnostic 958 |
blank |
|
Record delete not accepted because invalid |
Diagnostic 959, 960 |
blank |
|
Record delete not accepted because version conflict |
Full record from database |
Diagnostic 964, 965 |
|
Record delete not accepted because of procedural error |
Diagnostic 957, 1040-1047 |
blank |
|
Record delete not accepted because unavailable |
Diagnostic 956, 961, 962, 963, 966 |
blank |
|
Record delete queued or in process |
Record ID plus title |
blank |
6. Special Update
Special Update is a new action enabling an origin to convey record merge instructions and batch edit / replace instructions to a target via an externally defined OID, using the action qualifier parameter.
Other special update types may be defined in the future.
6.1 Origin Request
|
Element Name |
Contents |
|
referenceId |
optional - supplied by origin |
|
function |
Create |
|
packageType |
Update |
|
packageName |
ex: 199607031045 |
|
userId |
ex: NU:46 |
|
retentionTime |
ex: 7 days |
|
permissions |
Omitted |
|
description |
Omitted |
|
taskSpecificParameters |
{Z39-50-extendedServices5} esRequest |
|
specialUpdate |
|
ex: UC-B (bibliographic record) |
|
Omitted or edit / replace schema or update schema |
|
set containing version identifier and record ID for successful transactions |
|
externally defined OID - see sections 6.1.1 and 6.1.2 below on Merge and edit / replace |
|
See separate examples in sections following on Merge and Batch edit / replace |
|
|
|
<record Id> |
|
Version identifier (date / time stamp) |
|
Omitted |
|
waitAction |
wait if possible ( 1-10 records) |
|
elements |
full - requesting that the target should return all task package elements in the update response where applicable |
|
OtherInfo |
Omitted |
6.1.1 Merge
A merge request is a form of delete that also transfers linked data to another record. Merge is generally used when duplicate records have been identified on a target database and the origin needs to specify the record to be retained.
In a library catalogue, when a duplicate bibliographic record is deleted, any linked holdings, reservation or order data defined by the target's database need to be transferred to the kept bibliographic record. When a duplicate authority record is deleted, any linked bibliographic records or related authority records need to be transferred to the kept authority record. More than one duplicate record may be involved in a merge transaction.
The merge to information (i.e. the ID of the record that is to be retained) is contained within the actionQualifier external. Using a special update action, merge conveys to the target that a merge is required. The client cannot manage the merge process itself, for example by sending record deletions, holdings deletions and additions because it cannot determine the ripple effect on the database involved.
There can only be one "merge to" record ID in the actionQualifier area, although there may be multiple records in the supplied records area. This allows for example, multiple incorrect forms of an authority to be merged into one authority.
6.1.2 Batch Edit / Replace
Batch edit / replace is a form of special update enabling an origin to convey instructions to a target for a group of records to be changed in a similar way. The special action reduces the traffic that would be required to process multiple element update requests.
To request a batch edit / replace, the origin:
- Conducts a search to identify candidate records
- Uses the Persistent Result Set Extended Service to request the target to create a persistent result from the transient result set with a specific name.
- Creates an edit / replace record.
- Sends a special update request to the target with the edit / replace record as an external parameter in the actionQualifier.
The target is not required to perform all or none of the changes. It may fail some, e.g. because a record is not available for update, or because its version is incorrect, but process others. Detailed results are reported to the task package including results for each record processed or not processed.
The structure for the edit / replace record (1.2.840.10003.10.10) is as follows:
|
Element |
Occurrence |
Repeatable |
Datatype |
|
persistentResultSetPackageName |
Mandatory |
No |
|
|
numberOfRecords |
Mandatory |
No |
|
|
creationDateTime |
Mandatory |
No |
|
|
reviewCode |
Optional |
No |
InternationalString |
|
reviewNote |
Optional |
No |
InternationalString |
|
changeDataInfo |
Mandatory |
Yes |
Definition of changeDataInfo
|
Element |
Occurrence |
Repeatable |
Datatype |
|
fieldIdentifier |
Optional |
No |
|
|
oldValue |
Mandatory |
No |
|
|
oldValueTruncationAttribute |
Optional |
No |
|
|
conditionalField |
Optional |
No |
|
|
conditionalValue |
Optional |
No |
|
|
conditionalTruncationAttribute |
Optional |
No |
|
|
newValue |
Optional |
No |
|
|
editReplaceType |
Mandatory |
No |
|
|
case |
Optional |
No |
BOOLEAN |
The number of records from the transient result set is included as a check. If this differs from the number of records in the persistent result set, the target should not proceed with the update request.
The creation-date-time is the date and time the persistent result set task package was created by the target. If the date and time of last update of a record in the persistent result set is more recent than the date in the Batch edit / replace request, the target should not process the update for that record.
The field identifiers must correlate with the database name and schema cited in the element update package. If there is more than a single occurrence of a specified field in the record, the update should be applied to all occurrences of the field matching the update criteria. If the origin does not specify any field identifiers in the edit / replace record, the target should look for the old value anywhere in the record.
The old value should consist of the entire value to be replaced or deleted as it would appear in the field, with punctuation and spaces. The old value truncation attribute should include values from Bib1 Table A3-5, e.g. 1 = right truncation, 100 = do not truncate. In the absence of a truncation attribute, the target defines the default.
The update should only occur if the conditional field/ value pair is present in the record, taking into account the specified conditional truncation attribute.
The new value is a mandatory field except where the edit / replace type is set to field or subfield delete.
Edit / replace types would include the following values:
- Field insert (FI)
- Field delete (FD)
- Field replace (FR)
- Subfield insert (SI)
- Subfield delete (SD)
- Subfield replace (SR)
- Subfield merge (SM)
- Indicator change (IC)
- Data string change (DC)
Case is an optional toggle with 'true' meaning 'case dependent' and 'false' meaning 'case independent'. In the absence of this field, the target should process the update only if an exact match on case is found.
Field identifier includes field tag and optionally field sequence number, subfield tag and sequence number. Sequence number for a field applies to the occurrence of a field in a record and not to the
sequence number of the field in relation to the record as a whole. For example, in a USMARC record the a 650 field (topical subject heading) might be the second 650 in a record and the 15th field in a record. The field sequence number is 2 in this case. Conversely, sequence number in relation to a subfield counts the relative position of the subfield in relation to the field as a whole. The valid formats for Field identifier are:
<tag>/<seq>:<sf>/<seq>
<tag>:<sf>/<seq>
<tag>:<sf>
<tag>/<seq>
<tag>
Use of sequence number in a batch edit / replace transaction would be rare. In the absence of a sequence number, the default would be to change or delete all occurrences of the specified field or field / subfield which match the specified old value. For a subfield insert, the subfield should be placed on the end of the field. For a field insert, the target may choose where to insert the field within the record.
The edit / replace record is also used in record replace and element update, see sections 3.1.1 and 4.1.1.
6.2 Target Response
|
Element Name |
Contents |
|
referenceId |
optional - supplied by origin |
|
operationStatus |
Done |
|
diagnostics |
only if failure |
|
taskPackage consisting of: |
{Z39-50-recordSyntax (106)} taskPackage |
|
Update |
|
ex: 199607031045 |
|
ex: NU:46 |
|
ex: 7 days |
|
Omitted |
|
Omitted |
|
ex: NU46:23 |
|
ex: 19960703104735 |
|
0 (pending) |
|
ex: Diagnostic record, format extServices, permission 1 (id not authorised) |
|
update taskPackage |
|
specialUpdate |
|
ex: UC-B (bibliographic record) |
|
Omitted |
|
as per request |
|
as per request |
|
success partial failure |
|
if applicable |
|
|
|
see table under Error message handling |
|
Omitted |
|
success queued in process failure |
|
see table under Error message handling |
|
otherInfo |
Omitted |
6.2.1 Diagnostic Messages
General extended services / update
Merge
Batch edit /
replace
6.2.2 Error Message Handling
|
Case |
recordOrSurDiag |
supplementalDiagnostics |
|
Special update - merge accepted |
Diagnostic 990 (contains record ID and version identifier of target record in additional info) |
blank |
|
Special update - merge not accepted because invalid |
Update diagnostics 943-945, 991 |
blank |
|
Special update - merge not accepted because version conflict |
Full record from database |
Diagnostic 997-998 |
|
Special update - merge not accepted because of procedural error |
Diagnostic 1040-1047, 993 |
blank |
|
Special update - merge not accepted because unavailable |
Diagnostic 968, 992, 994-996 |
blank |
|
Special update - batch edit / replace accepted |
Diagnostic 900 (contains new version identifier) |
blank |
|
Special update - batch edit / replace not accepted because invalid |
Diagnostic 943-945, 902-903, 905-906 -------------------------------------- Full record |
blank -------------------------------------- Diagnostic 909 |
|
Special update - batch edit / replace not accepted because version conflict |
Full record |
Diagnostic 908 |
|
Special update - batch edit / replace not accepted because of procedural error |
Diagnostic 1040-1047, 904 |
blank |
|
Special update - batch edit / replace not accepted because unavailable |
Diagnostic 901, 968 |
blank |
|
Special update queued or in process |
Diagnostic 907 (optional) |
blank |
7. Record Locking
Record locking is used to prevent the target from accepting any other update request before the origin who performed the lock sends a record replace, element update, record delete transaction, merge request or a request to remove the lock (via element update).
The lock status of a record is changed by an element update request. The update schema provides a means of conveying between origin and target (and vice versa) both records and essential identification, version and lock status information. The schema is used:
- by the target to convey records in a search or present response or an element update response, indicating both lock status and that the records supplied in the response are suitable for update
- by the origin in an element update request to set or unset record locking. If the target does not supply records suitable for update in search and present responses, then it will supply a record suitable for update in response to an element update request that sets the lock status via the update schema.
- by the origin in a record replace, element update, special update, merge or record delete request to convey changed data and unset the record lock in the same transaction.
Some targets will not send records suitable for updating in normal search and present responses. Others will. The update schema provides a means of conveying records suitable for update, at the same time locking the record, if required.
When the origin sends an element update request using the update schema, requesting to set the lock status on, it indicates to the target whether or not it requires a new version of the record for updating via the information in the version identifier. If the version identifier is blank, then the target must send a record in the element update response. Similarly, if the version identifier is incorrect, then the target returns both a record and a diagnostic.
7.1 Update Schema (1.2.840.10008.13.6)
This retrieval schema models a database record as the actual record together with a few additional fields to support Update functions such as record locking.
Note: When a database record is formatted for transfer, these fields may be included in the transfer record; whether any of these supplementary fields are maintained as part of the physical database record, or whether the fields are dynamically created when constructing a transfer record, is not within the scope of this definition.
The actual transfer record (that would be transferred if this schema were not applied) remains intact, as an element within the transfer record formed by the application of this schema. It is typed as EXTERNAL and as such, the record syntax may be conveyed. (The record syntax for transfer of the record defined by this schema is to be GRS-1.)
The schema identifer within the Update definition should identify this schema. Therefore, a schema identifier is included as an element defined by this schema, to indicate the schema of the actual record (the schema identifer that would be used within the Update definition if the record were not packaged within this schema).
7.1.1 Abstract Record Structure
|
Element |
Occurrence |
Repeatable |
Datatype |
|
setLock |
optional |
no |
NULL |
|
lockSet |
optional |
no |
NULL |
|
lockExpiry |
optional |
no |
GeneralizedTime |
|
lockDescription |
optional |
no |
InternationalString |
|
timeStamp |
optional |
no |
GeneralizedTime |
|
recordId |
optional |
no |
Seedescriptionbelow. |
|
recordWrapper |
optional |
no |
RecordWrapper |
7.1.2 DefinitionofDatatypeRecordWrapper
|
Element |
Occurrence |
Repeatable |
Datatype |
|
schemaId |
optional |
no |
ObjectIdentifier |
|
record |
mandatory |
no |
EXTERNAL |
7.1.3 Description of Elements
|
setLock |
setLock may occur only when schema is sent by the origin (in an ES request). If it occurs, origin requests that the record be locked. |
|
lockSet |
setLock may occur only when schema is sent by the target (in a task package or Present Response). If it occurs, target indicates that the record is locked. |
|
lockExpiry |
lockExpiry may occur only if setLock or lockSet occur. When sent by origin, indicates the proposed expiration date / time for the lock. When sent by target, indicates the approximate expiration of lock. |
|
lockDescription |
lockDescription may occur only if setLock or lockSet occur. It is a text description of the lock, including, perhaps, who set (or is setting) the lock, why it is (or was) set; etc. |
|
timeStamp |
A time stamp of the included database record. |
|
recordId |
The recordId of the included database record. It is an INTEGER, InternationalString, or OCTET STRING, as in the Update ES definition. |
|
recordWrapper |
The recordWrapper is tagSet-M element 20, used to wrap a record together with its schema identifier. |
|
schemaId |
tagSet-M element 1. The schema in which the record (in element 'record') is transferred. The schemaId is optional and may be omitted if the origin and target have a prior agreement of what schema will be used. |
|
record |
The actual database record. |
7.1.4 TagSet (1.2.840.10003.14.7)
A tagSet will be defined and registered, with the following elements:
- setLock
- lockSet
- LockExpiry
- LockDescription
- TimeStamp
- recordId
- record
- instructions
- nonDupRecordId
- recordReviewCode
- record Review Note
- persitentResultsSetPackageNam
- numberOfRecords
- creationDateTime
- reviewCode
- reviewNote
- changeDataInfo
- fieldIdentifier
- oldValue
- oldValueTruncationAttribute
- conditionalField
- conditionalValue
- conditionalTruncationAttribute
- newValue
- editReplaceType
- case
8. Querying the Task Package
In cases where the target has not completed an update task at the time that it returns the update response, the target maintains a series of records for the task within the task package database on the server itself. This is accessible by the package name via a search request. The origin is responsible for monitoring the progress of uncompleted tasks. The table below gives an example of a search request on the task package database.
8.1 Search Request
|
Element Name |
Contents |
|
referenceId |
ex: 199607031145 |
|
smallSetUpperBound |
ex: 20 |
|
largeSetLowerBound |
ex: 99999 (set high to retrieve results rather than just a count) |
|
mediumSetPresentNumber |
ex: 20 |
|
replaceIndicator |
yes |
|
resultSetName |
ex: |
|
databaseNames |
IR-Extend-1 |
|
smallSetElementSetNames |
Omitted |
|
mediumSetElementSetNames |
Omitted |
|
preferredRecordSyntax |
Omitted - assumed to be in task package format |
|
query |
|
|
1 (RPN) |
|
0 (Op Operand) |
|
attrTerm (attributesPlusTerm) |
|
AttributeList = Ext-1 |
|
additionalSearchInfo |
Omitted |
|
otherInfo |
Omitted |
8.2 Search Response
|
Element Name |
Contents |
|
referenceId |
ex: 199607031145 |
|
resultCount |
1 (0 if task package cannot be located) |
|
numberOfRecordsReturned |
1 (0 if task package cannot be located) |
|
nextResultSetPosition |
0 (last record retrieved) |
|
searchStatus |
success (or failure) |
|
resultSetStatus |
blank (or none in the case of failure) |
|
presentStatus |
success (or failure) |
|
records |
The entire task package is regarded as one record, containing multiple taskPackageRecords in the task package format. |
|
AdditionalSearchInfo |
Omitted |
|
otherInfo |
Omitted |
9. Diagnostic List
The diagnostics are returned by the target to the origin via the task package. As they concern a record being added, updated, deleted or merged, they are returned as surrogate diagnostics with or without the current database record (see Z39.50 version 3 page 119). The messages convey to the origin how the target interpreted, processed, accepted, modified or rejected the origin's request. A diagnostic record may include additional information, for example text identifying replaced or rejected data, or text explaining the reason for a record being rejected or modified by a reviewer. Note that the target may determine the update action in the event of an error. The diagnostic list allows for this by multiple occurrences of the same message indicating different server action, e.g. 935-937. The diagnostic list in this profile should be used in conjunction with the diagnostic list in Z39.50, Appendix 4. ERR; DIAG-1
The following tables indicate messages that may be exchanged. The "Include record" column indicates whether or not the current database record is included along with the diagnostic. The values are o = optional, m = mandatory, n = not supplied. The structure of additional information and examples given apply to USMARC data.
Diagnostics 1040-1047 are general to Z39.50 Extended Services and are to be included in the Bib-1 Diagnostic Set. Diagnostics 900-998 form a new jupdate-specific diagnostic set, 1.2.840.10003.4.3.
9.1 General Extended Services
|
Msg # |
Description |
Include dbase record |
AddInfo |
|
1040 |
Invalid function |
n |
function |
|
1041 |
Error in retention time |
||
|
1042 |
Permissions data not understood |
n |
permissions |
|
1043 |
Invalid OID for task specific parameters |
n |
OID |
|
1044 |
Invalid action |
n |
action |
|
1045 |
Unknown schema |
n |
schema |
|
1046 |
Too many records in package |
n |
maximum number allowed |
|
1047 |
Invalid wait action |
n |
waitAction |
9.2 Validity
|
Msg # |
Description |
Include dbase record |
AddInfo (MARC structure) |
Example (MARC structure) |
|
920 |
Invalid tag - field rejected |
o |
tag / seq |
983 / 001 |
|
921 |
Invalid subfield code - subfield rejected |
o |
tag / seq / sf / seq |
700 / 001 / m / 001 |
|
922 |
Invalid subfield code - field rejected |
o |
tag / seq / sf / seq |
650 / 001 / m / 001 |
|
923 |
Invalid indicators - field rejected |
o |
tag / seq |
300 / 001 |
|
924 |
Invalid indicators - warning |
o |
tag / seq |
300 / 001 |
|
925 |
Missing or invalid fixed code element - default applied |
o |
tag / seq / position |
008 / 001 / 35 |
|
926 |
Missing or invalid fixed code element - field rejected |
o |
tag / seq / position |
008 / 001 / 6 |
|
927 |
Missing or invalid fixed code element - element or subfield rejected |
o |
tag / seq / position |
|
|
928 |
Invalid numeric - field rejected |
o |
tag / seq |
|
|
929 |
Invalid numeric - element or subfield rejected |
o |
tag / seq / sf / seq |
|
|
930 |
Invalid repetition of field - field rejected |
o |
tag / seq |
245 / 002 |
|
931 |
Invalid repetition of element or subfield - element or subfield rejected |
o |
tag / seq / sf / seq |
650 / 001 / a / 002 |
|
932 |
Invalid repetition of element or subfield - field rejected |
o |
tag / seq / sf / seq |
650 / 001 / a / 002 |
|
933 |
Missing or invalid mandatory field - record rejected |
o |
tag |
245 |
|
934 |
Missing or invalid mandatory field - default applied |
o |
tag / data |
008 |
|
935 |
Missing or invalid mandatory element or subfield - record rejected |
o |
tag / seq / sf |
|
|
936 |
Missing or invalid mandatory element or subfield - field rejected |
o |
tag / seq / sf |
|
|
937 |
Missing or invalid mandatory element or subfield - default applied |
o |
tag / seq / sf / data |
|
|
938 |
Invalid structure of non sort element - record rejected |
o |
tag / seq / sf / seq |
200 / 001 / a / 001 |
|
939 |
Invalid structure of non sort element - field rejected |
o |
tag / seq / sf / seq |
200 / 001 / a / 001 |
|
940 |
Invalid structure of non sort element - element or subfield rejected |
o |
tag / seq / sf / seq |
|
|
941 |
Invalid structure of non sort element - warning |
o |
tag / seq /sf /seq |
|
|
942 |
Invalid length of fixed field - field rejected |
o |
tag / seq |
008 / 001 |
|
943 |
Invalid record identifier |
n |
record ID |
|
|
944 |
Error in unpacking ISO 2709 record supplied |
n |
record |
|
|
945 |
Unable to read record supplied |
n |
record |
The additional information gives the address within a record enabling the origin to pinpoint the data that is invalid. The address for a MARC record consists of tag / tag sequence / subfield / subfield sequence. Tag sequence refers to the occurrence number of a particular field within a record and not to the sequence of the field in the record as a whole. For example, 700 / 002 refers to the second occurrence of 700 and not to the the second field in the record. Subfield sequence, on the other hand, refers to the actual position of the subfield within the field.
9.3 Update
|
Msg # |
Description |
Include dbase record |
AddInfo |
|
950 |
Record insert reviewed and accepted |
n |
recordID + version identifier + reviewers text optional |
|
951 |
Record insert reviewed and modified |
m |
in additional messages; + reviewers text optional |
|
952 |
Record reviewed and failed |
o |
recordID + reviewers text optional |
|
953 |
Record replace or element update reviewed and accepted |
n |
record ID + version identifier + reviewers text optional |
|
954 |
Record replace or element update reviewed and modified |
o |
in additional messages + reviewers text |
|
955 |
Record replace, element update or record delete rejected - record or element not found or not uniquely identified |
n |
record ID |
|
956 |
Record replace, element update or record delete rejected - record protected or locked by another user |
n |
record ID + version identifier + lock expiry (optional) |
|
957 |
Record replace, element update or record delete rejected - record not locked by requesting user |
o |
record ID + version identifier |
|
958 |
Record delete request reviewed and accepted - record deleted |
n |
record ID |
|
959 |
Record delete rejected - record not on file |
n |
record ID |
|
960 |
Record delete request reviewed and failed - record not deleted |
n |
record ID + reviewers text optional |
|
961 |
Record delete rejected - database error in accessing or deleting record |
n |
record ID |
|
962 |
Record delete rejected - cannot delete target record - linked holdings exist |
n |
number of holdings; list of holdings record IDs or codes optional |
|
963 |
Record delete rejected - cannot delete target record - linked orders, suggestions or reservations exist |
n |
number of orders, suggestions, reservations |
|
964 |
Cannot process update - version conflict |
m |
|
|
965 |
Cannot process update - missing or unrecognised date / time stamp |
m |
time stamp (0 if missing) |
|
966 |
Cannot process update - not authorised |
o |
|
|
967 |
Cannot process update interactively - record replace or element update rejected |
o |
|
|
968 |
Record insert, record replace or element update rejected - database error |
n |
record ID |
|
969 |
Cannot find bibliographic record; replacement request processed as an insert |
n |
record ID |
9.4 Duplicate Detection
|
Msg # |
Description |
Include dbase record |
AddInfo |
|
970 |
Record insert rejected - suspect duplicate |
m |
|
|
971 |
Record insert accepted - warning suspect duplicate |
m |
record ID + version of new record |
|
972 |
Record insert processed as a merge |
m |
record ID + version of database record |
9.5 Authority Control
|
Msg # |
Description |
Include dbase record |
AddInfo |
|
980 |
Heading matches with existing established heading - merged |
o |
tag / seq / data |
|
981 |
New established heading created |
o |
tag / seq / data |
|
982 |
Non preferred heading replaced with established heading |
o |
tag / seq / data |
|
983 |
Authority record rejected - established heading already on file |
m |
|
|
984 |
Authority record merged - established heading already on file |
m |
|
|
985 |
Authority record rejected - heading matches an established non preferred heading |
m |
9.6 Merge
|
Msg # |
Description |
Include dbase record |
AddInfo |
|
990 |
Merge accepted |
n |
record ID + version identifier of target record |
|
991 |
Merge rejected - target record missing |
n |
|
|
992 |
Merge rejected - cannot delete origin record - record protected or locked by another user |
o |
record ID of origin record |
|
993 |
Merge rejected - cannot merge target record - record not locked by requesting user |
o |
record ID + version identifier |
|
994 |
Merge rejected - cannot delete origin record - linked holdings exist |
o |
record ID of origin record |
|
995 |
Merge rejected - cannot delete origin record - linked orders or suggestions exist |
o |
record ID of origin record |
|
996 |
Merge rejected - not authorised |
o |
|
|
997 |
Merge rejected - version conflict target record |
m |
record ID + version identifier of target record |
|
998 |
Merge rejected - version conflict origin record |
m |
record ID + version identifier of origin record |
9.7 Batch Edit / Replace
|
Msg # |
Description |
Include dbase record |
AddInfo |
|
900 |
Batch edit / replace request accepted |
n |
record ID + version |
|
901 |
Batch edit / replace request rejected - not authorised |
n |
|
|
902 |
Batch edit / replace request rejected - result set not found |
n |
|
|
903 |
Batch edit / replace request rejected - number of records different from result set |
n |
number in results set |
|
904 |
Batch edit / replace request rejected - number of records exceeds target threshold |
n |
target threshold |
|
905 |
Batch edit / replace rejected - instructions conflict with update type |
n |
|
|
906 |
Batch edit / replace rejected - target cannot support case independent matching |
||
|
907 |
Interactive special update not possible - request has been batched |
n |
package name |
|
908 |
Update not performed - version conflict |
m |
record ID + version identifier |
|
909 |
Update not performed - string not found |
m |
9.8 Holdings Error Messages
|
Msg # |
Description |
Include dbase record |
AddInfo |
|
910 |
Invalid holdings code - holding addition rejected |
n |
record ID of bib record, code |
|
911 |
Holding not on file - holding change rejected |
n |
record ID of holding |
|
912 |
Holding not on file - holding deletion rejected |
n |
record ID of holding |
|
913 |
Cannot find matching bibliographic record - holding addition rejected (used when holdings are supplied via separate MARC holdings records) |
n |
record ID of holding |
|
914 |
Holding insert rejected - holding record already exists for holding code |
n |
record ID of holding on file |
|
915 |
Holding replacement or deletion rejected - cannot uniquely identify record |
n |
record Ids of holdings records on file |
|
916 |
Cannot find holdings record; replacement request processed as an insert |
n |
RecordID of holding |
10. Notes on Other Areas of Z39.50
10.1 Changes to the base standard
The Union Catalogue Profile was the first Z39.50 profile to exercise the Z3950 Database Update Extended Service. During the process of developing the profile, a small number of business needs for update were identified which were not supported by the base standard. The Z39.50 Implementors' Group has reviewed these requirements and consider them to be sufficiently generic to make necessary the following changes to the base standard:
- A new database update action, specialUpdate[5], together with a new data element actionQualifier were added to the task specific parameters for update. The specialUpdate allows an external to be defined for merge and batch edit / replace. The new actionQualifier has also been used in the Union Catalogue Profile to define externals for other update actions.
- A new data element supplementalDiagnostics has been added to the task package record structure. This allows supplemental messages to be sent with database records and surrogate diagnostics. Examples of cases implementing supplemental diagnostic messages have been included in the main text of the profile.
- An update schema has been defined to allow the exchange of record locking information and also to enable the exchange of explicit update elements in normal search or present responses.
- A recordReplace request no longer needs to contain a full database record as long as sufficient information is included in the record itself and in the edit / replace record to convey the purpose of the update.
A paper detailing the first three changes is available from the Z39.50 Maintenance Agency Web Page, reference: http://lcweb.loc.gov/z3950/agency/defns/esdiag.html.
To protect the existing update implementations, the old update definition has been retained with its existing OID (1.2.840.10003.9.5.1) and a separate OID has been given to the new update definition (1.2.840.10003.9.5.1.1). The version of update used is negotiated during initialisation. See http://lcweb/z3950/agency/nego.html.
These changes to the standard took effect on 5 January 1998.
10.2 Validation and Checking Code Lists
Some origins may be configured as PC clients and may house essential data for validation and some function such as code lists for consultation and subsets of authority files containing all see from references. This profile does not prescribe certain functions for a PC client and allows for considerable variance.
Certain clients may perform extensive validation prior to creating update requests, others may perform little. The target will almost always perform tests that are essential to the integrity of the database being updated. However, it may be possible for the target to minimise checks for certain clients with known validation capabilities and performance. The target will perform validation when it processes an update request. It is not necessary to have a validation request and response transaction pair.
Where a client stores data such as code lists and selected authority records, the extended service persistent query is used so that the target can prepare refreshed records to place in a task package. The client, as origin accesses the task package via search or scan of the extended services database. See Z39.50 Appendix EXT 1.2 for an explanation of persistent query.
Some clients may consult code lists on the target via search or scan requests.
10.3 Using SCAN to acquire Authority MARC Records
To obtain MARC records in Authority MARC format, a search request is sent by the origin including the database name that is different from the main database, for example with a suffix of "-A" and a relevant preferred record syntax, e.g. 10 for USMARC. The records are returned by the target, either as part of the search response, or with the present response.
It is an integral part of cataloguing work flows to be able to scan the authority file, in addition to searching for specific headings. Ideally, it should be possible to retrieve authority records in a scan response, but this is not allowed for in the format. Instead, specific parts of the authority record are given as separate parameters, that is:
- display term
- suggested alternatives (see also from references 5xx)
- alternative term (see from references 4xx)
- occurrence count
- other information (notes 6xx)
Therefore, the client either has the option to build a mini authority record from the information supplied in the scan response or to reformulate the scan results into a search request or requests as necessary with the search terms indicated above.
11. Conformance
This section details the Z39.50 objects and services needing to be supported by a Z39.50 origin or target to claim conformance with the Union Catalogue Profile. Optional features that would enhance a higher level implementation are also identified.
11.1 Conformance Table
M = Mandatory for base level conformance
O = Optional for base level
conformance but desirable in higher level implementations
M/O = Mandatory
or optional depending on whether another item is also supported
M/O only applies to items 9 and 16. Both origin and target must be able to handle requests to delete holdings for base level conformance. This can be achieved either through a record delete action targeting the holdings database or a record replace action targeting the bibliographic database. In the former case support is required for the USMARC holdings format (Item 9). In the latter case support is required for the edit / replace schema (item 16). Impementations need only support one of these mechanisms for base level conformance.
|
Item |
Feature |
Ref |
Origin |
Target |
|
Objects |
||||
|
1 |
Bib-1 attribute set {Z39-50 3 1} |
10.4 |
M |
M |
|
2 |
Ext-1 attribute set {Z39-50 3 } |
10.4 |
M |
M |
|
3 |
Bib-1 diagnostic set { Z39-50 4 1} |
10.4 |
M |
M |
|
4 |
UCP diagnostic set |
9, 10.4 |
M |
M |
|
5 |
MARC record syntax (at least one variant) |
2-6, 10.4 |
M |
M |
|
6 |
OPAC schema (pending) |
2.1.2, 10.4 |
O |
O |
|
7 |
databaseUpdate {Z39-50 9 5} |
2-6, 10.4 |
M |
M |
|
8 |
Record insert schema (pending) |
2.1.1 |
O |
O |
|
9 |
Edit/ replace schema (pending) |
3.1.1, etc |
M/O |
M/O |
|
10 |
Update schema (1.2.840.10003.13.6) |
7, 10.4 |
O |
O |
|
11 |
merge action qualifier |
6.1.1, 10.4 |
O |
O |
|
12 |
taskPackage {Z39-50-recordSyntax (106)} |
2-6, 10.4 |
M |
M |
|
Databases |
||||
|
13 |
Bibliographic/ MARC variant |
2-6, 10.5 |
M |
M |
|
14 |
Authority/ MARC format |
2-6, 10.5 |
M |
O |
|
15 |
Holdings/ MARC variant (embedded in bib record) |
2-6, 10.5 |
M |
M |
|
16 |
Holdings/ USMARC format |
2-6, 10.5 |
M/O |
M/O |
|
17 |
Extended services database |
2-6, 10.5 |
M |
M |
|
Services |
||||
|
18 |
Init |
10.6.1 |
M |
M |
|
19 |
IDAuthentication parameter |
10.6.1 |
M |
M |
|
20 |
Access Control |
10.6.1 |
O |
O |
|
21 |
Search |
10.6.2 |
M |
M |
|
22 |
Present |
10.6.2 |
M |
M |
|
23 |
Scan |
10.6.2 |
O |
O |
|
24 |
Extended Services |
10.6.3 |
M |
M |
|
25 |
Update extended services database |
8 |
n/a |
M |
|
26 |
Query extended services database |
8 |
M |
M |
|
27 |
Database Update |
10.6.3 |
M |
M |
|
28 |
Persistent Result Set (needed for batch edit / replace) |
10.6.3 |
O |
O |
|
29 |
Persistent Query |
10.6.3 |
O |
O |
|
30 |
Persistent Query Schedule |
10.6.3 |
O |
O |
|
31 |
Export Specification |
10.6.3 |
O |
O |
|
32 |
Export Invocation |
10.6.3 |
O |
O |
|
Update Actions |
10.7 |
|||
|
33 |
packageName |
2.1, 10.7 |
M |
M |
|
34 |
retentionTime |
2.1, 10.7 |
O |
O |
|
35 |
Interactive update/Wait if possible |
2.2.1, 10.7 |
M |
M |
|
36 |
Interactive update / Wait |
2.2.1, 10.7 |
O |
O |
|
37 |
RecordInsert |
2, 10.7 |
M |
M |
|
38 |
RecordReplace |
3, 10.7 |
M |
M |
|
39 |
Date / time stamp as supplemental ID |
3, 10.7 |
M |
M |
|
40 |
Date / time stamp in Task package record |
3, 10.7 |
M |
M |
|
41 |
elementUpdate |
4, 10.7 |
O |
O |
|
42 |
RecordDelete |
5, 10.7 |
M |
M |
|
43 |
specialUpdate |
6.1.1, 10.7 |
O |
O |
|
44 |
Include multiple diagnostic messages in response |
9 |
M |
M |
|
45 |
Include record with diagnostic message |
9 |
O |
O |
11.2 Protocol Version
Z39.50-1995 defines two protocol versions (Version 2 and Version 3). Union Catalogue Profile implementations may be based on either version. The Extended Services service is independent of version.
11.3 Communication Services
The Union Catalogue Profile assumes that communication between origin and target will take place on top of the Internet's Transmission Control Protocol (TCP) as defined in the profile "Using Z39.50-1992 directly over TCP (April 1994).
11.4 Z39.50 Objects
The mandatory Z39.50 objects for both origin and target are:
- Bib-1 attribute set {Z39-50 3 1}
- Ext-1 attribute set {Z39-50 3 }
- Bib-1 diagnostic set { Z39-50 4 1}
- UCP diagnostic set - as defined in Section 9 (Diagnostic List) of this Profile
- MARC record syntax - Implementations must support at least one specific national or international MARC variant. (This may be any MARC format whose syntax definition is registered with an object identifier.)
- databaseUpdate {Z39-50 9 5}
- taskPackage {Z39-50-recordSyntax (106)}
Implementations may also optionally support:
- Update schema (1.2.840.10003.13.6)
- Merge action qualifier
- Edit / replace schema (pending)
- Record insert schema (pending)
- OPAC schema (pending)
11.5 Z39.50 Databases
Union Catalogue Profile targets must support access to a bibliographic database and an extended services database. Targets may also support a separate logical authority database and holdings database.
- The logical record structure for the bibliographic database must conform to the MARC format for bibliographic data in the MARC variant supported.
- The logical record structure for the authority database, if supported, must conform to the MARC format for authority data in the MARC variant supported.
- The logical record structure for the holdings database, if supported, must conform to the holdings fields defined in the bibliographic record for the MARC variant supported. An origin or target may also optionally support the USMARC format for holdings data as this format becomes more widely implemented in library systems.
11.6 Z39.50 services
The mandatory Z39.50 services for both origin and target are:
· Init
- Search
- Present
- Extended Services
Implementations may also optionally support:
· Access Control
· Scan
11.6.1 Init and Access Control
It is assumed that any Z-association involving the Database Update Extended Service will requrie user authentication. The IDAuthentication parameter in Init must therefore be supported by both origin and target to allow userid and password information to be passed from the origin to the target. The access control service is optional but may be used by a target to send a security challenge after a Z39.50 session has been initialised.
11.6.2 Search, Present and Scan
The search and present functionality needing to be supported by the Union Catalogue Profile is closely related to that defined in a range of Z39.50 library catalogue interoperability profiles in place or under development. Current examples include:
· Z39.50 BIB-1 attribute set profile for CENL
· MODELS Library Interoperability Profile Family
· Virtual Union Catalogue Z39.50 Profile
It is assumed that the Union Catalogue Profile will be implemented in conjunction with one of these profiles. However, in addition to the BIB-1 attribute combinations specified for conformance in these profiles, Union Catalogue Profile implementations must also support Local Number (use attribute 12/ structure attribute 2).
Implementations may also optionally support one of ISBN (use attribute 7/ structure attribute 1) and ISSN (use attribute 8/ structure attribute 1); or Standard Identifier (use attribute 1007/structure attribute 1). If identifer data elements are not present in the target database, the target should fail the search and return the appropriate diagnostic.
Support for the scan service by both origin and target is considered highly desirable for Union Catalogue Implementations. It is an integral part of cataloguing work flows to be able to scan the authority file, in addition to searching for specific headings to include in a bibliographic record.
11.6.3 Extended Services
The only mandatory extended services service is database update. However, origins and targets using the special update action with the edit / replace schema to request a batch edit/ replace must also support the persistent result set extended service.
The extended services defined in the standard to support current awareness services (Persistent Query, Periodic Query Schedule, Export Specification and Export Invocation) could also optionally be used by implementors to deliver a range of offline services facilitating the mirroring of updates on multiple databases. Business needs specific to the union catalogue environment which might be met in this way are identified as items 19-20 in Appendix 1.
11.7 Update Actions
The mandatory Database Update actions for both origin and target are:
- recordInsert
- recordReplace
- recordDelete
An origin or target may also optionally support:
- elementUpdate
- specialUpdate (merge)
- specialUpdate (batch edit / replace)
Update requests and responses must always include a package name. Retention time for the task is optional. If not given, it is target-defined.
Interactive update is not mandatory, but a target which cannot (or chooses not to) process an update interactively must be able to send an acceptable diagnostic response to an update request with a wait action of "Wait". Where the target cannot (or chooses not to) process a "Wait if possible" request interactively, this must be indicated through the task status paremeter, i.e. by setting it to pending or active.
When the record being updated already exists on the database, the origin must send the unmodified date / time stamp from the database record in the supplied record and as a supplemental ID to identify the version of the record to be updated. As the target incorporates the changes to the database record, it applies a new date/time stamp, which is then placed in the task package record indicating to the origin the latest version id of the record.
Inclusion of a "does not duplicate" list in the action qualifier of an update request or within the record insert schema is optional for an origin and a target may ignore this information if it is included. It is also optional for the origin to use the action qualifier or record insert schema to signal the need for review and a target may ignore this information if it is included.
It is mandatory for both the origin and the target to support the supply of a full record in an update request. Optionally, in a record replace or element update request, the origin may use the edit / replace schema to specify the required changes through the action qualifier. Where the target does not support the edit / replace schema this must be indicated in the update response (doagnostic 1045).
11.8 Staged Implementation
It is recognised that implementors may wish to move towards conformance in stages, for example by implementing only record insert, or by implementing only limited support for the extended services database. A staged approach would allow implementors and their users to develop experience in the Profile, while working towards conformance. To assist implementors who prefer this path, a description of suggested stages is provided in Appendix 3. The suggested stages should not, however, be seen as levels of conformance; they are simply stages of progress towards base level conformance.
The profile supports multiple conformance tables for the exchange of different data formats and within the conformance tables, there are at lest two levels of conformance, basic and high level.
12. Document History
12.1 Versions
Union Catalogue Profile : Using Z39.50 Enquiry and Update
Version 1, July 1996 - Presented to interested parties in Australia and New Zealand
Version 1.1, September 1996 - Presented to the ZIG meeting October 1996
Version 2, March 1997 - Incorporating changes from the ZIG meeting:
Union Catalogue Profile: Internationally Registered Profile to be used with ISO 23950 (Z39.50 Information Retrieval Protocol) Extended Service for Update
Working Draft August 1997 - Presented to the ZIG meeting August 1997
ISO TC46 / SC4 Draft December 1997 - Incorporating changes from the ZIG meeting
ISO TC46 / SC4 Draft March 1998
12.2 Changes in the March 1998 version:
- Correlation Info changed in use and replaced by Edit / replace action qualifier in record replace and element update
- Record locking schema renamed update schema
- A new record insert schema to support duplicate detection and record review in the record insert request
- Global update schema renamed edit / replace schema and used with record update as well as special update.
- In all tables:
- referenceId made optional
- Blank changed to omitted for optional elements
- Indenting used to indicate data element groupings
- creation date and time lengthened
- mergeQualifier changed to actionQualifier
- permissions changed to omitted
- recordOrSurDiag and supplementaryDiagnostics added
- Tables added to each update action under the heading Error Message Handling to illustrate how to implement the recordOrSurDiag and supplementaryDiagnostics elements for certain main cases
- Text added to Section 1.1, Para 3 to clarify that the Z39.50 Database Update Extended Service Z39.50 Database Update Extended Service enables a client to request a server to conduct an update, not to initiate a database operation.
- Section 1.3 added to clarify the scope of the conformance requirements.
- Sections 1.4 and 1.5 updated
- Section on Holdings information in Section 2.1 updated to incorporate the new OPAC schema and to clarify conformance requirements
- Use of record replace to insert holdings supplied in a bibliographic record already on the target server added to Section 3
- Section on Holdings information in Section 3.1 updated to clarify this new use
- New paragraph added to section on Concurrent update in Section 3.1 on use of the update schema to request supply of records suitable for update when the normal present response does not include record id or version identifier.
- Sections 6 and 8 on Record merge and Global update (renamed Batch edit / replace) merged into a new section 6 on Special Update
- oldString and newString in the edit / replace record changed to oldValue and newValue
- New elements added to the edit / replace record to allow the update to be conditional on the presence of a conditionalValue in a conditionalField
- Bib-1 truncation attribute used as mechanism to specify truncation requirements
- Section 8 deleted
- Section 9 renumbered 8
- Section 10 renumbered 9 and the following changes made:
- Text of messages 951, 955, 956 and 957 changed
- Messages 901, 907, 964 deleted
- Messages renumbered:
900/1040; 902/1041; 903/1042; 904/1043; 905/1044; 906/1045; 908/1046; 909/1047
910/945; 911/944; 912/943; 913/968; 914/968; 915/961
952/943
960/956; 961/957; 965/964; 966/965; 967/966; 968/967
990/991; 991/992; 992/993; 993/994; 994/995; 995/996
1000/901; 1001/902; 1002/903; 1003/904; 1004/905; 1005/906;1006/907; 1007/908; 1008/909
1100;901; 1101/911; 1102/912; 1103/913
- Additional info added to messages 970-972
- Messages added: 900, 914, 915, 916, 952, 960, 969, 990, 997, 998
- Text added to clarify that diagnostics 1040-1047 are general to Z39.50 Extended Services and are to be included in the Bib-1 Diagnostic Set. Diagnostics 900-998 form a new update specific diagnostic set.
- Section 11 renumbered 10
- Section 12 renumbered 11 and substantially rewritten to clarify conformance requirements.
- Section 13 renumbered 12.
- A new appendix 4 added with holdings scenarios.
Changes in the June 1999 Version
- Status updated to record its approval as an Internationally Registered Profile.
- Addition of OIDs assigned by the Z39.50 Maintenance Agency and minor editorial corrections.
13. Appendix 1: Scenarios
|
1. Search to identify a bibliographic record |
Z39.50 Search & Present (one search for customer, configured to target local system first, then primary bibliographic utility then other sources of data) |
|
2. Obtain a copy of a record for the local system retrieved as the result of a search of another server |
Z39.50 Present with the other server as target; then Z39.50 bibliographic recordInsert with local system as target |
|
3. Upgrade a bibliographic record on a union catalogue as part of the process of obtaining a copy for the local system |
Z39.50 bibliographic recordReplace with the union catalogue as target; Z39.50 bibliographic recordInsert with the local system as target |
|
4. Obtain a copy of a record for the local system retrieved as the result of a search of another server, adding holdings and bibliographic details to a union catalogue as part of the process |
Z39.50 Present with the other server as target then Z39.50 bib recordInsert (or equivalent) with local system and union catalogue as targets |
|
5. As above, but obtain a copy of the union catalogue version for the local system (e.g., to get the record in a variation of the MARC format not supported by the target server) |
This could be delivered through a range of implementation strategies. One option would be for the union catalogue to act as an origin in its own right for access to key target servers. |
|
6. Delete a bibliographic record on a local system or a union catalogue |
Z39.50 bibliographic recordDelete with local system as target; Z39.50 bibliographic recordDelete with union catalogue as target |
|
7. Merge two or more duplicate bibliographic records on the local system or a union catalogue, transferring any link holdings to the record retained |
Z39.50 bibliographic specialUpdate - Merge, with local system as target; Z39.50 bibliographic specialUpdate - Merfge with union catalogue as target (with record Id of receiving record in actionQualifier) |
|
8. Add holdings to a bibliographic record on a union catalogue as part of the process of obtaining a copy for the local system |
Z39.50 holdings recordInsert or bibliographic recordReplace with the union catalogue as target; Z39.50 bibliographic recordInsert with the local system as target |
|
9. Add holdings and bibliographic data to a union catalogue as part of the process of creating original bibliographic details for the local system |
Z39.50 bibliographic recordInsert with local system as target; Z39.50 bibliographic recordInsert with the union catalogue as target (holdings included in record) |
|
10. Upgrade a bibliographic record on the customers local system with a record from another server |
Z39.50 Present with the other server as target; then Z39.50 bibliographic recordReplace with local system as target. |
|
11. Upgrade a bibliographic record on the local system or another server to enhance the record with more details as they become available or to improve access to the item |
Z39.50 bibliographic recordReplace with local system as target; Z39.50 bibliographic recordReplace with the other server as target |
|
12. Upgrade holdings status on the local system, ensuring significant changes are reflected on a union catalogue as part of the same process |
Z39.50 holdings recordReplace or bibliographic recordReplace with local system as target; Z39.50 holdings recordReplace or bibliographic recordReplace with the union catalogue as target |
|
13. Delete a holdings record on the local system, ensuring this is reflected on a union catalogue as part of the same process |
Z39.50 holdings recordDelete or bibliographic recordReplace with local system as target; Z39.50 holdings recordDelete or bibliographic recordReplace with the union catalogue as target |
|
14. Validate authority headings as part of the process of creating or updating a bibliographic record |
Z39.50 Search & Present or Z39.50 Scan (Configured to target local system authority files first, then other sources of authority data) |
|
15. Obtain authority records for the local system as part of the process of obtaining or creating cataloguing data |
Z39.50 Search & Present for each authority heading, with the source of authority data as target; then Z39.50 authority recordInsert with local system as target |
|
16. Upgrade an authority record on the local system or a union catalogue; optionally reflecting upgrade on both systems. |
Z39.50 authority recordReplace with local system as target; Z39.50 authority recordReplace with the union catalogue as target |
|
17. Delete one or more authority records on the local system or a union catalogue, merging any linked records to the preferred authority heading as part of the process. |
Z39.50 authority specialUpdate - Merge with local system as target; Z39.50 authority specialUpdate - Merge with the union catalogue as target (recordID of receiving record provided in actionQualifier if a merge is required) |
|
18. Perform a global text edit on the local system or another server |
Z39.50 specialUpdate - edit / replace schema with local system as target; Z39.50 specialUpdate - edit/replace schema with union catalogue as target |
|
19. Place standing orders with another server for records based on specified criteria |
Z39.50 Persistent Query, Periodic Query Schedule, Export Specification & Invocation with the other server as target and local system as exportDestination or set up the Standing Order directly with the other service |
|
20. Submit a list of search keys to another server and obtain copies of any matches, with the option of rerunning the query at regular intervals for non-matches |
Z39.50 Persistent Query, Periodic Query Schedule |
14. Appendix 2: References
Information retrieval (Z39.50): Application Service Definition and Protocol Specification / National Information Standards Organization. - Bethesda, Maryland: NISO Press, 1995. (ANSI/NISO Z39.50-1995). ISBN 1-880124-22-X.
USMARC format for authority data. - Washington, D.C.: Library of Congress, 1993.
USMARC format for bibliographic data. - Washington, D.C.: Library of Congress, 1994
USMARC format for holdings data. - Washington, D.C.: Library of Congress, 1989
UNIMARC Manual: bibliographic format. 2nd ed. - München: K.G. Saur, 1994.
15. Appendix 3: Staged Base-Level Conformance
Suggested priorities for a staged implementation to achieve base level conformance to the union catalogue profile.
15.1 Stage 1
15.1.1 Origin and Target
- Holdings record insert, for holdings supplied via bibliographic record
- Bibliographic record insert (including embedded holdings)
15.1.2 Target
- Support for elements in 2.1 and 2.2 except packageName; retentionTime; userId
- Create task package (not named or retained, but returned to origin)
- Relevant diagnostics from 9.1, 9.2, 9.3, 9.8
15.2 Stage 2
15.2.1 Origin and Target
- Holdings record replace, for holding supplied via bibliographic record
- Bibliographic record replace (including bibliographic record with embedded holdings)
- Version Identifier in supplementalId (target supplied and origin returned) as per description in 3.1-3.2
15.2.2 Target
- Extended services database (task packages)
- Query task package (ES database)
- Additional diagnostics from 9.1, 9.2, 9.3, and 9.8 that apply to record replace functions
- Support for elements in 3.1 and 3.2 (including packageName; retentionTime; userId)
15.3 Stage 3
15.3.1 Origin and Target
- Delete holdings record
- Delete bibliographic record (including bibliographic record with embedded holdings)
15.3.2 Target
- Additional diagnostics from 9.1, 9.2, 9.3, 9.8 that relate to delete functions
- Support for elements in 5.1 and 5.2
15.4 Stage 4
15.4.1 Origin and Target (optional for target)
- Insert authority record
- Replace authority record
- Delete authority record
15.4.2 Target (optional)
- Additional diagnostics from 9.1, 9.2, 9.3 and diagnostics from 9.5
- Support for elements in 2, 3, and 5
15.5 Base Level Conformance
- Record insert (Holdings (supplied via bibliographic record); Authorities [optional for target]; Bibliographic)
- Record replace (Holdings (supplied via bibliographic record); Authorities [optional for target]; Bibliographic)
- Record delete (Holdings; Authorities [optional for target]; Bibliographic)
- Create task package
- Task package naming
- Maintain Extended Services database and search response
- Query task package
- Version identifier in supplementalId (target supplied and origin returned)
- Provision of relevant diagnostics contained in Section 9: Diagnostic List, including support for multiple messages where specified in the Profile.
- Support for elements in 2, 3 and 5
15.6 Cataloguing Scenarios Addressed in a Base-Level Conformance Implementation
Base-level conformance to the UCP addresses the following Cataloguing scenarios which are described in detail in Appendix 1:
[NB Scenario 1, Search to identify a bibliographic record is addressed by the Z39.50 standard]
2. Obtain a copy of a record for the local system retrieved as the result of a search of another server
3. Upgrade a bibliographic record on a union catalogue as part of the process of obtaining copy for the local system
4. Obtain a copy of a record for the local system retrieved as the result of a search of another server, adding holdings and bibliographic details to a union catalogue as part of the process
6. Delete a bibliographic record on a local system or a union catalogue
8. Add holdings to a bibliographic record on a union catalogue as part of the process of obtaining a copy for the local system
9. Add holdings and bibliographic data to a union catalogue as part of the process of creating original bibliographic details for the local system
10. Upgrade a bibliographic record on the customer's local system with a record from another server
11. Upgrade a bibliographic record on the local system or another server to enhance the record with more details as they become available
12. Upgrade holdings status on the local system, ensuring significant changes are reflected on a union catalogue as part of the process
13. Delete a holdings record on the local system, ensuring this is reflected on a union catalogue as part of the same process
15. Obtain authority records for the local system, ensuring this is reflected on a union catalogue as part of the same process
16. Upgrade an authority record on the local system or a union catalogue (optional for target)
17. Delete one or more authority records on the local system or a union catalogue, merging any linked records to the preferred authority heading as part of the process (optional for target)
If a staged implementation is used:
Stage 1 addresses the following:
Scenarios 2 (for bibliographic record insert); 4, 5, 8, 9
Stage 2 addresses the following:
Scenarios 2 (for bibliographic record replace), 3, 10, 11, 12
Stage 3 addresses the following:
6, 13
Stage 4 addresses the following:
15, 16, 17
16. Appendix 4: Holdings Scenarios
These scenarios deal with adding, updating or deleting a single holdings record only. They cover initiating events and the range of possible outcomes for implementations with base level conformance and illustrate (where appropriate) the value added by a higher level of conformance. Where multiple records are supplied with a single update request, origin and target will need to support GRS-1 as a record syntax to take advantage of this added value.
16.1 Adding a new holding
16.1.1 The origin supplies holdings as MARC fields in the bibliographic record/ a bibliographic record id is supplied (action = recordReplace; databaseName = Bibliographic database)
The target:
(i) links new holdings to the existing bibliographic record using the supplied record id; OR
(ii) rejects the update request because the bibliographic record already has linked holdings and the target does not know how to handle the ambiguity (but the origin can help to resolve this ambiguity by using the edit/replace record). (914)
(iii) rejects the update request because it cannot find the bibliographic record (913)
(iv) creates a skeleton bibliographic record because it cannot find the bibliographic record and attaches the holdings to this record (969)
16.1.2 The origin supplies holdings in MARC holdings format/ a bibliographic record id is supplied (action = recordInsert; databaseName = Holdings database)
The target:
(i) links new holdings to existing bibliographic record using supplied record id
(ii) rejects the update request because the collection already has linked holdings and the target does not know how to handle the ambiguity (but the origin can help to resolve this ambiguity by supplying a doesNotDuplicateList. (914)
(iii) rejects the update request because it cannot find the bibliographic record (913)
(iv) creates a skeleton bibliographic record because it cannot find the bibliographic record and attaches the holdings to this record (969)
16.1.3 The origin supplies holdings as MARC fields in the bibliographic record/ no bibliographic record id is suppplied (action = recordInsert or recordReplace; databaseName = Bibliographic database)
The target:
(i) creates a new bibliographic record from the supplied bibliographic record and links new holdings to this record; OR
(ii) identifies a match for the bibliographic record on the database using other keys supplied in the bibliographic record and links new holdings to this record; OR
(iii) rejects the update request because it has identified several candidate matches for the bibliographic record in its database (but the origin can help to resolve this ambiguity by supplying a doesNotDuplicateList); (913) OR
(iv) special case of (ii) where the target rejects the update request because the bibliographic record already has linked holdings and the target does not know how to handle the ambiguity. (The origin cannot help with a doesNotDuplicateList because it doesn't know about this holdings record. ) (914)
16.2 Holdings update
16.2.1 The origin supplies changes in MARC holdings format (action = recordReplace; databaseName = Holdings database)
The target:
(i) replaces the full record (if the edit/replace record is not used); OR
(ii) makes the specified changes only (when the edit/replace record is used).
(iii) rejects the update because cannot find the holdings record or finds more than one occurrence (911, 915)
16.2.2 The origin supplies changes as MARC fields in the bibliographic record (action = recordReplace; databaseName = Bibliographic database)
The target:
(i) replaces both the full bibliographic record and the holdings record (if the edit/replace record is not used); OR
(ii) makes the specified changes only (when the edit/replace record is used).
(iii) rejects the update because cannot find the bibliographic record or the holdings record (912 913)
(iv) creates a new bibliographic record and holdings record because cannot find the bibliographic record (969 916)
(v) processes the bibliographic record replace and creates a new holdings record because can find the bibliographic record but not the holdings record (when the edit/replace record is not used) (916)
16.3 Holdings delete
16.3.1 The origin supplies record to be deleted in MARC holdings format (action = recordDelete; databaseName = Holdings database)
(i) target deletes record.
(ii) rejects the deletion because cannot find the holdings record or finds more than one holdings record. (912 915)
16.3.2 The origin uses recordReplace to delete the holdings information (action = recordReplace; databaseName = Bibliographic database)
(i) The target processes the holdings field deletes specified via the edit/replace record
(ii) rejects the deletion because it cannot find the holdings record or finds more than one holdings record. (912 915)