Z39.50 Record Source Schema
Revised Draft For Review
August 23, 2000
This schema definition was approved at the July ZIG meeting, subject to the following change: the url for a source
record need not necessarily be a Z39.50 url; multiple urls may be supplied (actually, URIs), in the case where
multiple URIs (possibly of different types) exist for the record.
The definition has been revised, for review. Please consider the following question. Suppose two or more URIs
are supplied by a surrogate record. Should the client assume that they all identify the same source record (i.e.
at the same server)? Or, should it be possible for the intermediary, having decided that two or more records on
different source servers are duplicates, to supply, within a single surrogate record, URIs to these multiple
records? If this is allowed though, then how would the client be able to distinguish these two cases, that is,
whether two URIs identify the same source record (at the same server) or duplicate records at different servers?
The Object Identifier for this Schema definition is 1.2.840.10003.13.11
Background
This schema is defined in response to a requirement to identify the "source" of a Z39.50 record. The requirement is
for a Z39.50 server, acting as an intermediary, to provide information to the client for a given result set record,
enabling the client to subsequently retrieve the record directly from the source server for that record.
Model
In the model for this schema, the Z39.50 server acts as an intermediary, receiving queries against a "virtual"
database and retransmiting the queries to a set of other Z39.50 servers. The intermediary server creates a single
logical result set combining the results from the individual result sets (although, the nature of this combining
process is not prescribed). The records at the intermediary are referred to as "surrogate records" and the records
at the source servers are referred to as "source records". Each surrogate record include one or more identifiers
(URIs) for the source record that it identifies, enabling the client to subsequently retrieve the source record
directly from the respective source servers.
Method
The method prescribed by this schema is for the surrogate record to identify a source record by a URI, conveyed by
TagSet-M element 12. The URI might be a Z39.50R url, or another type of URI that identifies the record. The server
might supply multiple URIs (via multiple occurences of TagSet-M element 12) when there exist multiple URIs for the
source record.
Purpose of this Schema
The purpose of this schema is to assign specific semantics to the usage of tagSet-M element 12, namely, that it is a
URI for the source-record. In the base definition of tagSet-M, element 12 is defined as "url", implicitly, a url for
the database record. However, for this model, the base definition leaves open the question of whether the url
identifies the actual database record that the result set item points to (i.e. the surrogate record at the
intermediary server) or the source record.
When used in the context of this schema, tagSet-M element 12 means URI "for the source record" and not "for
the surrogate database record on the intermediary server".
Usage
A server constructing a retrieval record including tagSet-M element 12 to be used in this manner should include the
schema identifier for this schema. That is, it should include the following two elements:
- tagSet-M element 1: Identifier for this schema, 1.2.840.10003.13.11
-
tagSet-M element 12: URI for source record. Multiple occurence of this element are allowed, when there
are multiple URIs for the source record.
The retrieval record may consist entirely of these two elements. Alternatively (and beyond the scope of this
definition), it may also include additional elements, for example metadata about (or from) the source record. In
that case, Refer to the clarification
Use of nested Schemas for Cross-domain searching and Semantic interoperability
for constructing retrieval records with multiple schemas. For example, the two tagSet-M elements above could be the
first two elements respectively within the retrieval record, followed perhaps by additional tagSet-M elements,
followed by a structured element within which a different schema identifier occurs.
Limitation
This schema assumes for a given record that it is possible to create a URI that uniquely identifies the record. The
schema does not address records where no such URI can be created.
Library of Congress