Z39.50 Profile for Access to Digital Collections

This document is also available in PostScript, and wordPerfect.

(for those having difficulty with the large postScript file, it is also available in three parts: part1 part2 part3)

Draft Seven (Final Draft for Review)

May 3, 1996

Library of Congress

1. Background and Introduction

In August, 1995, the Library of Congress convened a team of representatives from several institutions to develop a Z39.50 profile access to digital libraries.

Early in its development the profile was renamed from Z39.50 Profile for the Digital Library Application to Z39.50 Profile for Access to Digital Collections (nicknamed the Collections profile) as its scope was narrowed, to apply to navigation of digital collections. Other groups were initiating independent efforts to develop profiles aimed at specific types of objects and collections. The intention was to coordinate these efforts and that these latter profiles would be developed as compatible extensions or subsets of the Collections profile. These latter profiles are referred to as companion profiles. An example is the CIMI profile: Z39.50 Application Profile Specification for Use in Project CHIO. CIMI, the Consortium for Interchange of Museum Information, is the sponsor of a demonstration project, CHIO (Cultural Heritage Information Online). Another example is the Z39.50 Profile for Access to Digital Libraries being developed at the Library of Congress.

1.1 Document History

The initial draft of this document was developed in early September, 1995; Draft Two was issued for discussion at the first meeting of the profile team, September 20. Draft Three was issued November 3, for the second meeting, November 14-15. Draft Four, issued in late December was prepared for a meeting that was subsequently canceled. Draft Five was developed via electronic mail and other discussion, for the meeting February 5-6, and was also distributed to the ZIG for discussion at the ZIG meeting February 7-9. Draft Six, issued March 18, reflected extensive discussion at the February 5-6 meeting, the February 7-9 ZIG meeting, as well as subsequent comments.

This draft, Draft Seven, reflects comments on Draft Six, and is available for review and comment until June 1. Following comment resolution, the profile will be proposed for approval.

1.2 Purpose of This Profile

This profile specifies a conforming subset of Z39.50-1995 to address problems described in section 1.3, in particular for access to digital collections organized via descriptive information whose structures are described within this profile. It provides semantics for navigating digital collections, to locate and retrieve objects of interest.

1.3 Problems Addressed by this Profile

Libraries and other institutions are creating a growing number of collections, organized thematically, for example, by subject, creator, historical period, etc.; with numerous, diverse objects, both digital and physical. These collections are often organized hierarchically and distributed across servers.

Significant resources may be invested in digitization and in the intellectual efforts of aggregation, organization, and description of the information in a collection. Yet to a remote user or client, the collection may appear to be simply an accumulation of objects and undifferentiated data, because there is no agreed-upon semantics for navigating the collection, to locate and retrieve objects of interest. Coherent organizational structures, imposed on the data, are necessary to provide a view that supports navigation. A key obstacle to effective navigation is the inability to distinguish content from description. A primary goal of navigation is to locate and retrieve objects of interest; a vital step in that process is to locate relevant descriptive information. Thus it is useful to navigate among descriptive information as well as content, and consequently, to be able to distinguish content from description.

Various forms of descriptive aids have been developed for purposes of describing collections and objects, for example, finding aids, encoded archival descriptions, and exhibition catalogs. Often they do not have a well-defined structure and cannot be used alone for reliable navigation. At many institutions though, descriptive aids of these types have been created, at significant expense. It is therefore imperative that an application relying on descriptive information for collections and objects be able to utilize these available aids, rather than mandate the creation of new redundant structures. In order to exploit these descriptive aids, a higher level enveloping structure is necessary, to allows users and clients to navigate among and select descriptive aids of interest.

Another navigational problem is posed by the various and often complex relationships among and between objects and collections. For a given object, there may be other objects that are duplicates or variations (e.g. different resolutions) or which bear other relationships (e.g. surrogates). For any given collection there may be superior, subordinate, related, and context collections. These relationships among objects and collections must be modelled coherently.

Different digital objects, even within the same collection, may be retrievable by different protocols (e.g. Z39.50, HTTP, FTP). It is therefore important that structures describing these objects, and how they may be accessed, be defined independent of any specific protocol.

These problems amplify when a collection is distributed across institutions (or otherwise distributed in a manner requiring access to multiple servers). In particular some normalization of query semantics is necessary for coherent navigation of collections. Clients must be able to formulate queries that will be interpreted consistently across servers.

1.4 Scope Limitations

This profile assumes that companion profiles (compatible extensions to or subsets of this profile) will be independently developed, extending or limiting the use of this profile to specific applications or classes of information, for example, museum objects, satellite photographs, geospatial data, or chemical compounds. Thus this profile does not directly address all of the problems cited in 1.3, but provides a framework for companion profiles to do so: Although this profile emphasizes the logical separation of descriptive information from content, it does not include guidelines or specifications for determining whether information is description or content. The profile does not address organizing principles, i.e, the means by which objects are aggregated into collections. Although this profile addresses distributed collections, it does not address distributed databases. Different parts of a collection may be managed by different institutions; therefore different databases, corresponding to a single collection, may reside on different servers, but no individual database is distributed across servers. Only the Z39.50 protocol is addressed by the profile. The profile does not, however, preclude multi-protocol clients, gateways, or digital collections where part of a collection is accessible via Z39.50 while another part is accessible by other protocols.

1.5 Definitions

Associated Description
A unit of descriptive information associated with a collection or object, for example, an encoded archival description or a finding aid (for an archival collections), or a catalog record (for library materials).
Child
Collection or object A is a child of collection B if B is a parent of A. A collection may have objects as well as subcollections as children.
Collection
A group of related objects and/or collections, possibly distributed across locations. A collection is a tree, where leaf nodes are objects and non-leaf nodes are subcollections.
Collection Descriptive Record: A Descriptive Record that describes a Collection.
Companion profile
An independently developed profile which is a compatible extension to or subset of this profile, extending or limiting the use of this profile to specific applications or classes of information, for example, museum objects.
Context Collection
Collection A is a context collection for collection or object B if it is a superior, related collection, and the organization with responsibility for the management of B considers that although collection A may be relevant to a user who is interested in B, any collection superior to collection A is likely not relevant.
Descriptive Record
A unit of descriptive information at a higher level of abstraction than an Associated Description. A Descriptive Record may include one or more Associated Descriptions in addition to other information that describes either a collection (and possibly its contents) or an object within a collection. A Descriptive Record is either a Collection Descriptive Record or an Object Descriptive Record.
Member (of a collection)
Child.
Object
A Physical Object or a Digital Object.
Object Descriptive Record
A Descriptive Record that describes an object.
Parent Collection
Collection A is a parent of collection or object B if A is immediately superior to B.
Related Collection
Collection A related to collection or object B if the organization with responsibility for the management of B considers that collection A may be relevant to a user who is interested B.
Subcollection
Child collection.
Subordinate
Collection or object A is subordinate to collection B if A is a node on a tree whose root is B.
Superior Collection
Collection A is superior to collection or object B if B is a node on a tree whose root is A.

1.6 References

2. Model, Assumptions, and Principles

The data model and descriptive data described in this section and section 4 are intended for general use, not specific to Z39.50. In particular, the intellectual content of the descriptive data modelled by this profile is distinguished from the format used for its transfer. Z39.50 specifics are described in section 5.

2.1 Model of an Object

An object is a Physical Object or a Digital Object. For any given Physical Object, there may or may not be a Digital Object which is its digital representation. Any given Digital Object may or may not be the digital representation of some Physical Object. A Digital Object may be text or it may be a digitized object; in any case, this profile treats a Digital Object as opaque.

2.2 Model of a Collection

A collection is a group of related objects and/or collections, possibly distributed across locations. Thus a collection is a tree, where leaf nodes are objects and non-leaf nodes are subcollections. Collection A is said to be related to collection or object B if the organization with responsibility for the management of B considers that collection A may be relevant to a user who is interested B. Collection A is said to be superior to collection or object B if B is a node on a tree whose root is A; B is said to be subordinate to collection A if A is superior to B. Collection A is said to be a parent of collection or object B if A is immediately superior to B; B is said to be a child of collection A if A is a parent of B. Collection A is said to be a context collection for collection or object B if it is a superior, related collection, and the organization with responsibility for the management of B considers that although collection A may be relevant to a user who is interested in B, any collection superior to collection A is likely not relevant. The concept of a context collection is related to, but differs from, the concept of a root collection (which this profile does not employ). A context collection might informally be considered a "relative root" collection, for purposes of navigation. "Root" (as in "root collection") has the connotation of absolute or static. In contrast, "context" (as in "context collection") is relative; furthermore, although a collection might be a root collection from the view of a subordinate collection, a parent collection may subsequently be created for the former, so that it is no longer a root collection, and this new relationships might not be conveyed (nor might it be meaningful) to the subordinate collection. For any given collection or object there may be zero or more parent collections, zero or more related collections and zero or more context collections. For any given collection there may be zero or more child collections. A collection is a different logical construct than a database, in several respects:

2.3 Model of a Record

Z39.50 models database records, abstract database records, and retrieval records. It employs the concept of an abstract record structure defined by a database schema: a common understanding shared by client and server of the information contained in the records of a database, allowing logical components of that information to be addressed, selected, and represented.

A database record is a unit of information in a database, represented in a data structure local to the server. An abstract database record is an abstract representation of the information in a database record, formed by the application of an abstract record structure to the database record, where the abstract record structure is known to the client. A retrieval record is the information in an abstract database record represented in an exportable structure (by the application of a record syntax).

This profile employs the concept of a record according to the Z39.50 model, thus the term record is used to mean database record, abstract database record, or retrieval record, depending on usage and context. The Descriptive Record (Collection Descriptive Record and Object Descriptive Record) is a fundamental construct in this profile. The term Descriptive Record may refer to a database record, in particular when the context is searching. It refers to an abstract database record when the context is the definition of the Descriptive Record. It refers to a retrieval record when the context is retrieval.

2.4 Descriptive Information

This profile exploits organizational structures in order to allow a client to navigate through structured information, possibly hierarchically structured. A coherently defined set of descriptive data is used to manage and navigate collections of otherwise undifferentiated data. These organizational structures allow the data to be viewed as distributed collections, loosely hierarchical.(From a top-down view, a collections is a tree. From a bottom-up view, collections are directed graphs, because any object or collection may have multiple parents.)

2.4.1 Descriptive Information and Content

Collections modelled by this profile are characterized by the logical separation of descriptive information from content. This logical separation is not intended to constrain an implementation. Servers may choose to separate descriptive data from content in retrieval records using the record structure defined in this profile. However, servers are not required to perform this separation. In any case the profile does not prescribe nor address how servers store data.

In general, a collection may include Digital Objects that are completely self-describing, Digital Objects that include some self-description while additional descriptive information is separate, as well as Digital Objects where descriptive information is completely separate.

This profile does not provide guidelines for determining whether information is description or content. It is the responsibility of the institution managing a collection to make that determination, and this profile does not presume that different institutions will make the same determination for similar or even identical information. For example, a Physical Object, for which there is a digitized picture, could be modelled as a Physical Object with no corresponding Digital Object, where the picture is treated as descriptive information; alternatively, the picture could be treated as a Digital Object.

As another example, a Digital Object might be largely self-describing, including, for example, a caption that is an integral part of the Digital Object. A copy of that Digital Object might reside in a different collection, managed by a different institution, that might designate it instead to be description (of a physical object) with no corresponding Digital Object.

2.4.2 Modelling Descriptive Information

Collections and objects often have descriptive information associated with them. For example, archival collections are described in encoded archival descriptions and finding aids; library and other materials are described in catalog records; museum objects and collections are described in wall texts and exhibition catalogs.

An important design objective of this profile is to support the use of such descriptive information, here called an Associated Description, for use in navigating collections. A server implementing this profile may have created and stored an existing base of Associated Descriptions; it is the intention of this profile that the server be able to deliver these existing Associated Descriptions without the need to modify or reformat them.

Because of the wide variety of possible descriptive information, this profile does not attempt to enumerate or restrict the types of Associated Description that may be available. It is anticipated that companion profiles will enumerate the types of Associated Description appropriate for particular domains.

Neither does this profile attempt to describe the structure or contents of any Associated Description; for the purpose of this profile an Associated Description is an opaque data element passed from the server to the client along with other information relevant to navigating collections. A client that receives an Associated Description may either display it to the user or pass it to some application that can process it. The nature of such processing is outside the scope of this profile.

This profile supports the retrieval of information needed to navigate within and between collections and to retrieve both Digital Objects and Associated Descriptions. It does so by defining the structure of a Descriptive Record, which is at a higher level of abstraction than either a Digital Object or an Associated Description. A Descriptive Record may include one or more Associated Descriptions in addition to other information that describes either a collection (and possibly its contents) or an object within a collection.

This profile requires that a server be able to provide Descriptive Records (for collections and/or objects). These could be stored as database records, or alternatively, retrieval records may be created upon request by appropriate processing of other information available to the server, including information within digital objects and Associated Descriptions. This is, however, strictly an implementation matter; this profile does not specify how, or if, the Descriptive Records are to be stored. It only specifies the format for transfer from server to client. (Thus, although according to the Z39.50 abstract record model, a retrieval record corresponds to a database record, whether that database record physically exists on the server is transparent to the client.)

2.4.3 Collection and Object Descriptive Records

A Descriptive Record describes a collection or an object and is, respectively a Collection Descriptive Record or Object Descriptive Record.

A Collection Descriptive Record may provide an overall description of a collection as well as collective or individual descriptions of some or all of the objects in the collection.

An Object Descriptive Record describes an object: a Digital Object (which may or may not be the digital representation of a Physical Object) or a Physical Object.

Both a Collection Descriptive Record and Object Descriptive Record may list parent-, context-, and related- collections. A Collection Descriptive Record may list child collections as well.

For a given Digital Object, there need not necessarily be an Object Descriptive Record. The institution managing a collection to which the object belongs is responsible for making that determination. An object may, for example, be sufficiently described by a Collection Descriptive Record. As another example, a set of digitized photographs might be distinguished as distinct Digital Objects and aggregated into a collection or might be combined as a single Digital Object. If they are aggregated into a collection, there may be a single Collection Descriptive Record and there may or may not be individual Object Descriptive Records for some or all of the individual Digital Objects.

2.5 Datastore Model

A collection is represented by a datastore: part or all of one or more databases on one or more servers (distributed databases, however, are not addressed by this profile; see 1.4). To a given collection there corresponds a set of databases that include the descriptive records for that collection: Object Descriptive Records for objects and Collection Descriptive Records for subcollections.

The databases corresponding to a collection are not exclusive to that collection. They may include other records: records pertaining to other collections, or records not related to digital collections.

This model does not prescribe where Digital Objects reside; any given Digital Object may be represented as nested within its Object Descriptive Record, as a distinct record within the same database as its Object Descriptive Record, on a different database within the same server, or on a different server. A Digital Object may be accessible via Z39.50 or via another protocol.

2.6 Enumerating the Members of a Collection

For modelling purposes, members of a collection are objects and subcollections. Note: thus the property of belonging to a collection differs from the property of belonging to a database. For example, suppose an Object Descriptive Record describes a Physical Object in a collec- tion. The Object Descriptive Record belongs to a database (but is not a member of the collection, because, by definition, only objects and subcollections are members) while the Physical Object is a member of the collection (but does not belong to a database).

A Collection Descriptive Record may provide an enumeration of the members of the collection it describes. Each item in the enumerated list is a pointer that refers to one of the following:

3. Navigational Scenarios

This section describes some of the scenarios that sections 4 and 5 are intended to support. When a client connects to a server providing access to digital collections, on behalf of a user interested in digital collections, the following scenarios are possible. In any case, eventually the user may identify a collection of interest. A number of possible scenarios might ensue:
  • The client might retrieve an enumeration of the Associated Descriptions for the collection. For each Associated Description, the client may retrieve the Associated Description type, format, size, and a brief text description. The client might use the Associated Description types and format to determine which Associated Descriptions it can process or if not process, display to the user. The client might then display the brief descriptions (and size) of those Associated Descriptions to the user, who then selects an Associated Description of interest for the client to process or display.
  • The client might retrieve from the Collection Descriptive Record an enumeration of the objects in the collection. For each object, the client retrieves a brief description for display to the user (if the number of enumerated objects is large, the client can retrieve a few at a time). For a given object:
  • The client may search the collection based on user supplied search criteria. (Here, "search the collection" means search the databases corresponding to the collection, where the search is restricted to Object Descriptive Records which list the collection as a parent.) User supplied search criteria are not addressed by this profile, but may be addressed by companion profiles. If the client and server both support Explain the client may retrieve information about the databases, for example, attributes supported, in order to assist the user in formulating meaningful searches. (Note that this profile does not require support for Explain.)
  • The client might expand the search to apply to superior collections and/or subordinate collections. The user might identify an object of interest and wish to locate other objects, related in a specific way. The client may assist the user by listing the various collections to which the object belongs, including descriptions of criteria used to aggregate objects in each collection.

    For example, consider a collection of digitized theater costumes, with various subcollections. One of the objects is a digitization of an eighteenth century, yellow, Shakespearean costume. That single object might belong to a number of collections, including "18th century costumes", "yellow costumes" and "shakespearean costumes". A user interested in that object might select one of these collections to search, based on the specific aspect of interest.

    Note that the scenarios above suggest that a collection may know of subordinate collections and objects, and a collection or object may know of superior collections; correspondingly, a client might build a collection-map bottom-up or top-down. It must be emphasized that this profile does not mandate nor does it intend to favor either approach. A companion profile may choose to favor or mandate either approach.

    4. Descriptive Record Schema

    This section defines a schema for the Descriptive Record. The object identifier for this schema is [iso (1) member-body (2) US (840) ANSI-standard- Z39.50 (10003) schema (13) descriptive record (3)].

    4.1 Abstract Record Structure

    The abstract record structure for a Descriptive Record is defined as follows: Abstract record structure not yet available in html. See postscript.

    4.6 Element Set Names Defined for this Schema

    The following element set names are defined for this schema:
  • 'b' (brief)
  • 'navigation'
  • 'full'

    4.6.1 Brief Record

    The brief record is defined as follows: Brief record definition not yet available in html. See postscript. Companion profiles may specify additional elements that are to be included in a brief record, including elements defined by tagSets other than the tagSet used in this profile.

    4.6.2 Navigation Record

    The Navigation record is defined as follows: Navigation record definition not yet available in html. See postscript.

    4.6.3 Full Record

    In a full record, all available elements for all available occurrences should be included.

    4.7 Collection-1 Attribute Set

    This section defines attribute set collection-1, for searching databases with records whose structure is as defined by the Descriptive Record schema. The object identifier for this attribute set is [iso (1) member-body (2) US (840) ANSI-standard-Z39.50 (10003) attributes (3) digital collections (7)]. The Collection-1 attribute set defines the two attribute types: Use (type 1) and Relation (type 2). Semantics for combining attributes from this set with attributes from a different set, within a single operand, are not provided by this attribute set definition.

    1 Collection-1 Use Attributes

    The following Collection-1 Use attributes are defined: Use attributes not yet available in html. See postscript.

    2 Collection-1 Relation Attributes

    Relation attributes not yet available in html. See postscript.

    5. Z39.50 Specific Profile Details

    Section 6 below defines three levels of conformance. These are briefly summarized here:
    Basic Conformance
    Version 2; support required for the DR schema and the GRS-1 record syntax.
    Basic V3 Conformance
    Basic conformance, plus support required for version 3.
    Enhanced Conformance
    Basic V3 conformance, plus support required for selected additional features.
    When a feature is stated to be mandatory, then unless otherwise specified, support is mandatory both for origin and target, and for any conformance level.

    5.1 Protocol version

    Both version 2 and version 3 of Z39.50 are addressed by this profile. For Basic V3 Conformance or Enhanced Conformance version 3 must be supported.

    5.2 Services and Facilities

    The Init, Search, and Present services are mandatory. The Segment service is optional for Basic V3 and Enhanced Conformance (and excluded for Basic Conformance). The Explain facility is optional; see 5.5.

    5.3 Search

    Support for the Collection-1 attribute set (see 4.7) is mandatory. The use and semantics of Type-1 query operands that combine attributes from the Collection-1 set with attributes from a different set is not within the scope of this profile. Companion profiles may specify such usage and semantics.

    5.4 Retrieval

    5.4.1 Present Parameters

    Support for Present parameter CompSpec is mandatory for Enhanced Conformance; it is optional for Basic V3 Conformance and excluded for Basic Conformance.

    When the CompSpec parameter is used for the purpose of retrieving a Descriptive Record, it should be used as follows:

    5.4.2 Segmentation

    Support for level-2 segmentation is optional for Basic V3 and Enhanced Conformance (and excluded for Basic Conformance). Support for level-1 segmentation (without level-2 segmentation) is outside the scope of this profile.

    5.4.3 Element Specification

    Support for element specification eSpec-1 is mandatory for Enhanced V3 Conformance. See 5.4.10.

    5.4.4 Variant Set

    Support for variant set variant-1 is mandatory for Enhanced V3 Conformance. A variant specification may occur:

    5.4.5 Fragmentation

    Support for fragmentation is mandatory for Enhanced V3 Conformance. See 5.4.10.

    The term fragmentation, as used in this profile, refers to the use of Z39.50 variants to retrieve a fragment of an element (see 5.4.10). A fragment is a logically contiguous piece of the element not necessarily distinguished as a subelement (i.e. if the entire element were to be retrieved, considering that element as a string of bits, a fragment is any substring of that string). Criteria for defining fragments are determined by the target. For example the target could define fragments based on number of bytes, or could define a page or screen to be a fragment.

    For the purpose of this profile, fragmentation applies to either an Associated Description or Digital Object, and is used to retrieve either the "first" or "next" fragment.

    5.4.6 Record Syntax

    Support for GRS-1 is mandatory. See 5.4.11.

    5.4.7 Descriptive Record Schema

    Support for the Descriptive Record schema (section 4) is mandatory.

    5.4.8 Brief and Navigation Descriptive Records

    Support for element set names 'b' and 'navigation' (4.6) are mandatory.

    5.4.9 Digital Objects and their Variants

    A server providing access to different versions, instances, or representations of a given Digital Object may represent these as: The server may also use a combination of these. For example, the server might provide several variants of a Digital Object (using Z39.50 variant capabilities) and also provide a pointer to another representation of the Digital Object (perhaps on a different server). For the latter representation, the server would have to provide the pointer in a separate instance of digitalObject.

    In any case, whenever a server provides a Digital Object via element actualDO (rather than pointer), whether only a single variant or multiple variants are provided, the server should use the Z39.50 variant capabilities including variant-1 and (for Enhanced V3 conformance) should support a request to list the available variants, including body part type. In addition a server may choose to indicate a level of integrity for a variant. (The variant may be a derived object, created on demand, and as such may be a conversion or reduction of the genuine object. See 5.4.11, ElementMetadata, supported variants MetaData -- integrity.)

    10 Element Specification eSpec-1

    For Enhanced V3 Conformance, usage of element specification eSpec-1 is defined as follows:

    In the main structure, the parameter 'elements' must be supported, and none of the other parameters should be included (elementSetNames, defaultVariantSetId, defaultVariantRequest, or defaultTagType). ElementRequest may select 'simpleElement' or 'compositeElement':

    5.4.11 GRS-1

    Usage of record syntax GRS-1 within this profile is defined as follows: In the GRS-1 main structure, the following parameters must be supported: tagType, tagValue, tagOccurrence, and content. In addition, for Enhanced V3 Conformance, metaData and appliedVariant must be supported.

    5.4.12 Language

    'Language' (type 4 class 1 of variant-1) is applicable for text elements only, when there is a predominant language.

    For Digital Objects, 'language' is not within the scope of this profile, however, companion profiles may specify its use.

    For elements of type BriefTextDescription, 'language', within an applied variant, is the prescribed mechanism for a target to indicate the language of the description.

    For an Associated Description, 'language', within a supported or an applied variant, is the prescribed mechanism for a target to indicate the language.

    5.4.13 Surrogates

    When a Digital Object is considered to be a surrogate for another Digital Object, and both objects are members of the same collection and thus are both represented as enumerated members within the same Collection Descriptive Record, the surrogate relationships may be expressed via 'surrogate for' and 'surrogate element' of GRS-1. (Note, however, this profile does not define what is meant by a surrogate relationship).

    The enumerated member for a surrogate object may indicate via a tagPath the enumerated member representing the Digital Object for which it is a surrogate, and vice versa. The two elements will share the same tagType and tagValue, and are distinguished by tagOccurrence.

    5.4.14 Usage Right

    Via the 'usage right' parameter of ElementMetaData of GRS (see 5.4.11) a target may either (a) indicate whether a Digital Object is re-distributable or restricted, or (b) supply a license pointer.

    When a client product claims to support this parameter, the claim means that the product is implemented with the intention that whenever the client receives what it perceives to be a usage right statement or pointer, it will make a good-faith effort to inform the user. It does not mean that it will follow the pointer, attempt to enforce the usage right statement, or obtain acknowledgement or concurrence from the user.

    5.5 Explain

    The use of the Z39.50 Explain facility is optional for this profile. Targets that support Explain may wish to distinguish one or more databases as those which provide access to digital collections (i.e. databases which include Descriptive Records). It is recommended that targets assign to those databases the searchable keyword 'collection-descriptive-records', searchable via the exp-1 Use attribute Keyword.

    A Target using this feature may apply whatever criteria it deems appropriate in selecting databases to assign this keyword. For example a target may select only databases that include Collection Descriptive Records (as opposed to Object Descriptive Records), or only databases that include Collection Descriptive Records for context collections.

    6. Conformance

    An implementation claiming conformance to this profile shall indicate:

    6.1 Basic Conformance

    An implementation claiming conformance at the Basic Conformance level must support version 2 of Z39.50-1995 (see 4.4 of that standard for specific conformance requirements), the DR schema specified in section 4, and the GRS-1 record syntax.

    6.2 Basic V3 Conformance

    An implementation claiming conformance at the Basic V3 Conformance level must conform at the Basic Conformance level (see 6.1) and in addition must support version 3 of Z39.50-1995.

    6.3 Enhanced V3 Conformance

    An implementation claiming conformance at the Enhanced V3 Conformance level must conform at the Basic V3 Conformance level (see 6.2) and in addition must support the following features:
    Library of Congress
    Library of Congress Help Desk (01/13/97)