Draft Seven
(Final Draft for Review)
May 3, 1996
Library of Congress
Contents
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:
Digital Objects are treated as atomic, that is, their content is opaque and is not addressed by this profile. Thus the profile addresses searching descriptive information rather than searching Digital Objects. Companion profiles may model the content of specific objects (e.g., museum objects).
Associated Descriptions (e.g., finding aids, exhibition catalogs; see 2.3.2) are treated as opaque (their content is not addressed by this profile), though clients may have at their disposal helper applications that are able to process or display them. Companion profiles may model the content of Associated Descriptions.
The profile does not model complex relationships among objects of all classes. Companion profiles may do so for specific object classes.
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
ANSI/NISO Z39.50-1995. Information Retrieval (Z39.50): Application Service Definition and Protocol Specification. See /z3950/agency.
CIMI Profile. Z39.50 Application Profile Specifications for Use in Project CHIO.
Z39.50 Profile for Access to Digital Libraries. Library of Congress.
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:
A database is an aggregation of records, and a collection is an aggregation of objects, some of which may be physical objects.
The apportionment of records into databases might be based on very different criteria than the apportionment of objects into collections. For example, a server might provide the following databases: Books, Serials, Maps, Photos, SoundRecordings, and MotionPictures, containing digitized books, serials, maps, photos, sound recordings and motion pictures, respectively. A single collection might contain objects from all of these categories, and therefore records (corresponding to objects in the collection) would be distributed across these databases. The collection might be organized by theme, while the databases are organized, for example, by media type.
The property of belonging to a collection differs from the property of belonging to a database; section 2.6 describes this difference.
A database resides on a single server, while a collection may span servers (that is, different databases corresponding to a single collection may reside on different servers).
A single database may include records corresponding to objects in more than one collection.
A single object might belong to more than one collection, while the database record for that object may be retrievable from only one database.
An object might belong to a single collection, while the database record for that object is retrievable from multiple databases, which may be on different servers.
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 collection. 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:
an Object Descriptive Record (if the member is an object),
a Digital Object (if the member is a Digital Object), or
a Collection Descriptive Record (if the member is a subcollection).
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.
The user might know the name of a collection of interest, as well as the database where the Collection Descriptive Record for the collection resides.
The user may know the name of a collection but not the database where its Collection Descriptive Record resides. In that case, if the client and server both support Explain then the client may attempt to determine that database via Explain (see 5.5.)
It may be that neither the client nor the user knows any collection names. In that case if the client and server both support Explain, the client might attempt to learn which databases in general correspond to collections and search those databases for desired Collection Descriptive Records. The client may then retrieve Collection Descriptive Records from these databases and display summary information to the user, including brief descriptions.
The user may select a collection and then navigate to other collections of interest: the client may retrieve a list of related collections, including parent, superior, and context collections, brief descriptions of these collections, and descriptions of their relationship to the subject collection. The user might select one of these collections, determine its parent, superior, and context collections, etc.
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 might retrieve part or all of the Object Descriptive Record for the object, in particular an enumeration of its Associated Descriptions, and, as in the Collection Descriptive Record scenario above, the client displays brief descriptions of Associated Descriptions to the user, who selects an Associated Description of interest for the client to process or display.
Alternatively, the client might retrieve and display object metadata including a list of available formats for the object, and for each, its size, and level of integrity (see 5.4.9). The user might select a format and the client may then retrieve the object in that format.
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:
Element | Occurrence | Repeat-able | Datatype |
typeOfDescriptiveRecord | mandatory | no | INTEGER |
briefDescription | optional | no | BriefTextDescription |
collectionInfo | optional; occurs only if typeOfDescriptiveRecord is 1 | no | CollectionInfo |
objectInfo | optional; occurs only if typeOfDescriptiveRecord is 2 | no | ObjectInfo |
associatedDescription | optional | yes | AssociatedDescription |
relatedCollection | optional | yes | relatedCollection |
Element typeOfDescriptiveRecord distinguishes whether the Descriptive Record describes a collection or an object, i.e., it distinguishes a Collection Descriptive Record from an Object Descriptive Record. It is one of the following:
1 = Describes a collection
2 = Describes an object
3 = Unspecified
Note: 'Unspecified' in included cases when there is a unit of information, possibly an Associated Description, where it is unclear whether that information is a collection or object, yet the information is interesting enough to warrant a descriptive record.
Element briefDescription is intended for use in a brief record, for display to the user. It is a brief description of the collection or object that the Descriptive Record describes.
Element collectionInfo consolidates elements that occur only in a Collection Descriptive Record (as opposed to an Object Descriptive Record). It includes the name of the collection, the databases that pertain to the collection, and an enumeration (possibly partial) of the members of the collection.
Element objectInfo consolidates elements that occur only in an Object Descriptive Record (as opposed to a Collection Descriptive Record). It indicates the type and category of the object, as well as the Digital Object itself (or a pointer to the Digital Object).
Each occurrence of element associatedDescription represents an Associated Description. Multiple occurrences of this element represent different Associated Descriptions (to represent multiple representations of the same Associated Description, see 4.2.3).
Each occurrence of element relatedCollection identifies a parent-, superior-, related-, or context collection. The name of the collection and the database where Collection Descriptive Record resides are indicated, as well as the nature of the relationship.
When the Descriptive Record is an Object Descriptive Record (typeOfDescriptiveRecord = 2), this element may indicate the collections to which the object (described by this Descriptive Record) belongs.
4.2 Datatype Definitions
This section defines the following datatypes:
CollectionInfo
ObjectInfo
AssociatedDescription
CollectionAndDb
RelatedCollection
ServerAndDb
EnumeratedMember
DigitalObject
Description
RecordPointer
BriefTextDescription
4.2.1 CollectionInfo
Datatype CollectionInfo is structured as follows:
Element | Occurrence | Repeatable | Datatype |
collectionName | mandatory | no | InternationalString |
database | optional | yes | ServerAndDb |
enumeratedMember | optional | yes | EnumeratedMember |
fullyEnumerated | optional | no | BOOLEAN |
childrenKnowThisParent | optional | no | BOOLEAN |
Element collectionName is the name of the collection.
Each occurrence of element database identifies a database. The collective set listed is the set of databases that pertain to the collection. The set of databases may span servers.
When this element is omitted, the client should infer that it was omitted either because the server did not know, or did not wish to indicate, the pertinent databases. When one or more occurrences are included, the client should not infer that all of the pertinent databases are necessarily included.
The occurrences of element enumeratedMember enumerate the members of the collection. Each occurrence corresponds to an object or subcollection. The enumeration may or may not be inclusive, as indicated by the element fullyEnumerated. Each occurrence may include a pointer to an Object Descriptive Record, to a Digital Object, or to a Collection Descriptive Record.
Element fullyEnumerated indicates whether or not the enumeration of members, as enumerated by the occurrences of element enumeratedMember, is a complete enumeration of the members of the collection. If this element is not supplied no default should be inferred; it should be omitted only if the target does not know or does not wish to indicate if the enumeration is complete.
Element childrenKnowthisParent, if 'true', means that every member of this collection lists this collection as a parent. If this element is not supplied no default should be inferred; it should be omitted only if the target does not know or does not wish to indicate its value.
Note: A value of 'true' for element fullyEnumerated indicates that the client may discover the members of the collection via retrieval (by retrieving occurrences of element enumeratedMember). A value of 'true' for element childrenKnowThisParent indicates that the client may discover the members via search (see 4.7.1, Collection-1 Use attribute Parent-collection). If both elements have value 'false', this indicates that there is no straightforward way to discover the members of the collection.
4.2.2 ObjectInfo
Datatype ObjectInfo is structured as follows:
Element | Occurrence | Repeatable | Datatype |
typeOfObject | mandatory | no | INTEGER |
categoryOfObject | optional | no | InternationalString |
digitalObject | optional; may occur only if typeOfObject less than 4 | yes | DigitalObject |
Element typeOfObject is one of the following:
0 = Unspecified.
1 = Object is a Digital Object.
2 = Object is a Digital Object for which there is a Physical Object.
3 = Object is a Digital Object for which there is no Physical Object (for example when an object is originally created electronically).
4 = Object is a Physical Object.
5 = There is no (separate) object.
Element categoryOfObject may be included to indicate that a Digital Object is, for example, an exhibition catalog or cataloging record (these examples are purely illustrative and not intended as inclusive). This profile does not define any categories. It is anticipated that companion profiles will do so.
Note: See also categoryOfAD within AssociatedDescription. A given object in one collection might be treated as an Associated Description in a different collection (perhaps managed by a different institution). Therefore, there may be categories of objects in common with categories of Associated Descriptions.
Each occurrence of element digitalObject includes the actual Digital Object, or a pointer to the Digital Object. Multiple occurrences of this element identify different representations of the Digital Object, such as variant resolutions, color depths or encodings (they do not represent different Digital Objects; datatype ObjectInfo represents a single, logical Digital Object).
4.2.3 AssociatedDescription
Datatype AssociatedDescription is structured as follows:
Element | Occurrence | Repeatable | Datatype |
briefDescriptionOfAD | optional | no | BriefTextDescription |
categoryOfAD | optional | no | InternationalString |
description | mandatory | yes | Description |
Element briefDescriptionOfAD is a brief text description of the Associated Description, for display purposes.
Element categoryOfAD may be included to indicate that the Associated Description is, for example, an encoded archival description, exhibition catalog, or cataloging record (these examples are purely illustrative and not intended as inclusive). This profile does not define any categories. It is anticipated that companion profiles will do so.
Note: See also categoryOfObject (and its note) within ObjectInfo.
Each occurrence of element Description includes the actual Associated Description or a pointer to the Associated Description. Multiple occurrences of this element represent different representations of the Associated Description (they do not represent different Associated Descriptions; multiple occurrences of associatedDescription in the main structure may be used to represent different Associated Descriptions).
4.2.4 RelatedCollection
Datatype RelatedCollection is structured as follows:
Element | Occurrence | Repeatable | Datatype |
collection | mandatory | no | CollectionAndDb |
relationship | optional | yes | INTEGER |
relativeLevel | optional | no | INTEGER |
descriptionOfRelationship | optional | no | InternationalString |
Element collection identifies the related collection.
Element relationship is one of the following:
1 = superior collection
2 = context collection
3 = collection may be of interest (no familial relationship implied)
Notes:
(1) The subordinate relationship is not included here, because subordinate collections are enumerated within element enumeratedMember of collectionInfo.
(2) Relationship is repeatable, and the valid combinations are 1; 1,2, and 3; and 3.
Element relativeLevel indicates the level of this collection relative to the (subject) object or collection. A value 0 means "sibling" (or "same level"), 1 means "parent", and a value greater than 1 means "superior but not parent".
Element descriptionOfRelationship provides a text description of the nature of the aggregation, relationship, or context, and may indicate why the collection might be of interest.
4.2.5 CollectionAndDb
Datatype CollectionAndDb is structured as follows:
Element | Occurrence | Repeatable | Datatype |
collectionName | mandatory | no | InternationalString |
database | mandatory | no | ServerAndDb |
Element collectionName is the name of a collection.
Element database identifies a server and database.
4.2.6 ServerAndDb
Datatype ServerAndDb is structured as follows:
Element | Occurrence | Repeatable | Datatype |
server | optional; if omitted, the indicated database is assumed to be on this server; must be supplied if indicated database is not on this server | no | InternationalString |
db | mandatory | no | InternationalString |
Element server identifies a host and port.
Element db is a database on the indicated server.
4.2.7 EnumeratedMember
Datatype EnumeratedMember has the following structure:
Element | Occurrence | Repeatable | Datatype |
briefDescriptionOf
Member |
optional | no | BriefText
Description |
pointer | optional | no | RecordPointer |
whatPointerPointsTo | occurs if and only if pointer occurs | no | INTEGER |
Element briefDescriptionOfMember is a brief text description of the object or subcollection.
Element pointer is a pointer to an Object Descriptive Record or Digital Object, if the member is an object, or to a Collection Descriptive Record if the member is a subcollection.
Element whatPointerPointsTo is one of the following:
1 = element pointer points to an Object Descriptive Record
2 = element pointer points to a Digital Object
3 = element pointer points to a Collection Descriptive Record
4 = type of pointer is Unspecified
4.2.8 DigitalObject
Datatype DigitalObject is structured as follows:
Element | Occurrence | Repeatable | Datatype |
briefDescriptionOfDOVariant | optional | no | BriefTextDescription |
actualDO | occurs if and only if pointerToDO does not occur | no | variant or category dependent; default is OCTET STRING |
pointerToDO | occurs if and only if actualDO does not occur | no | RecordPointer |
authoritative | optional | no | BOOLEAN |
Element briefDescriptionOfDOVariant is a brief text description of this particular variant or representation of the Digital Object. It is intended to allow the user to discriminate among variants or representations of the Digital Object. It is not intended as a description of the Digital Object itself; that description is provided either from element briefDescription in the Descriptive Record (when the object is obtained via an Object Descriptive Record) or from element briefDescriptionOfMember in enumeratedMember (when the Digital Object is discovered via a Collection Descriptive Record).
Element actualDO is the actual Digital Object.
Element pointerToDO identifies a retrievable information object that is (or contains) the Digital Object. It may be retrievable via Z39.50 or via other mechanisms outside the scope of this profile.
Element authoritative indicates whether the server deems this representation of the digital object to be an authoritative representation. The server may provide several representations of the Digital Object (represented by multiple occurrences of element digitalObject within ObjectInfo) some considered authoritative and others not considered authoritative, as reflected by the value of this element.
4.2.9 Description
Datatype Description is structured as follow:
Element | Occurrence | Repeatable | Datatype |
briefDescriptionOfADVariant | optional | no | BriefTextDescription |
actualAD | occurs if and only if pointerToAD does not occur | no | variant or category dependent; default is InternationalString |
pointerToAD | occurs if and only if actualAD does not occur | no | RecordPointer |
authoritative | optional | no | BOOLEAN |
Element briefDescriptionOfADVariant is a brief text description of this particular variant or representation of the Associated Description, intended to allow the user to discriminate among variants or representations of the Associated Description. This element is not intended as a description of the Associated Description itself; that description is provided by element briefDescriptionOfAD within associatedDescription.
Element actualAD is the actual Associated Description.
Element pointerToAD identifies a retrievable information object that is (or contains) the Associated Description. It may be retrievable via Z39.50 or via other mechanisms outside the scope of this profile.
Element authoritative indicates whether the server deems this representation of the Associated Description to be an authoritative representation. The server may provide several representations of the AssociatedDescription (represented by multiple occurrences of element description within associatedDescription) some considered authoritative and others not considered authoritative, as reflected by the value of this element.
4.2.10 RecordPointer
Datatype RecordPointer has the following structure:
Element | Occurrence | Repeatable | Datatype |
database | occurs (in conjunction with recordId) if and only if alternativeIdentifier does not occur | no | ServerAndDb |
recordId | occurs (in conjunction with database) if and only if alternativeIdentifier does not occur | no | OCTET STRING |
alternative
Identifier |
occurs if and only if Database does not occur | no | OCTET STRING |
typeOf
Identifier |
optional; occurs only if alternativeIdentifier occurs | no | OBJECT IDEN-TIFIER or Inter-nationalString |
RecordPointer is used in the following element: pointer within EnumeratedMember, pointerToDO within DigitalObject, and pointerToAD within Description. It points to a database record or other retrievable information object corresponding respectively to: the Descriptive Record for an object or collection enumerated by EnumeratedMember, a Digital Object, or an Associated Description. It takes one of the following two forms:
(a) a database (serverAndDb) and unique identifier of a record within the database (recordId),
(b) some alternative identifier.
In case (a) the format of recordId is local to the server. In case (b), the alternative identifier might be, for instance, a URL. It might self-identify its type, but in any case its type may optionally be indicated by the element typeOfIdentifier.
Elements database and recordId occur together and identify a database and record.
Alternatively, element alternativeIdentifier occurs if elements database and recordId do not, and it identifies a database and record.
Element typeOfIdentifier indicates the type of identifier, for example a URL or URN, for element alternativeIdentifer.
4.2.11 BriefTextDescription
Datatype BriefTextDescription has type InternationalString.
4.3 Schematic Representation of Descriptive Record
typeOfDescriptiveRecord
briefDescription collectionInfo collectionName database (repeatable) (server and db) enumeratedMember (repeatable) briefDescriptionOfMember pointer (database and recordId) XOR (alternativeIdentifier and typeOfIdentifier) whatPointerPointsTo fullyEnumerated (BOOLEAN) childrenKnowThisParent (BOOLEAN) objectInfo typeOfObject categoryOfObject digitalObject (repeatable) actualDO XOR pointerToDO (database and recordId) XOR (alternativeIdentifier and typeOfIdentifier) authoritative (BOOLEAN) associatedDescription briefDescriptionOfAD categoryOfAD description (repeatable) actualAD XOR pointerToAD (database and recordId) XOR (alternativeIdentifier and typeOfIdentifier) authoritative (BOOLEAN) relatedCollection (repeatable) collection (collectionName, server, and database) relationship (repeatable) relativeLevel descriptionOfRelationship |
4.4 Tag Types
For this schema a GRS-1 record will use the following tagTypes:
TagType Usage
1 Elements from tagSet-M defined in Z39.50-1995, Appendix TAG, TAG.2.1. A target may include an element from tagSet-M at its discretion, and an origin may ignore it.
2 Elements from tagSet-G defined in Z39.50-1995, Appendix TAG, TAG.2.2. A target may include an element from tagSet-G at its discretion, and an origin may ignore it.
3 Reserved for tags locally defined by a target. This profile does not define the usage of tagType 3, but companion profiles may do so.
4 The tagSet defined in 4.5.
4.5 Descriptive Record TagSet
This section defines a tagSet for the Abstract Record Structure defined in 4.1. The object identifier for this tagSet is {iso (1) member-body (2) US (840) ANSI-standard-Z39.50 (10003) tagSet (14) digital collections (5)}
Tag Element DataType
1 typeOfDescriptiveRecord INTEGER
2 briefDescription BriefTextDescription
3 collectionInfo CollectionInfo
4 objectInfo ObjectInfo
5 associatedDescription AssociatedDescription
6 relatedCollection relatedCollection
7 collectionName InternationalString
8 database ServerAndDb
9 enumeratedMember EnumeratedMember
10 fullyEnumerated BOOLEAN
11 childrenKnowThisParent BOOLEAN
12 typeOfObject INTEGER
13 categoryOfObject InternationalString
14 digitalObject DigitalObject
15 briefDescriptionOfAD BriefTextDescription
16 categoryOfAD InternationalString
17 description Description
18 collection CollectionAndDb
19 relationship INTEGER
20 relativeLevel INTEGER
21 descriptionOfRelationship InternationalString
22 collectionName InternationalString
23 database ServerAndDb
24 server InternationalString
25 db InternationalString
26 briefDescriptionOfMember BriefTextDescription
27 pointer RecordPointer
28 whatPointerPointsTo INTEGER
29 actualDO variant dependent; default is OCTET STRING
30 briefDescriptionOfDOVariant BriefTextDescription
31 pointerToDO RecordPointer
32 authoritative BOOLEAN
33 briefDescriptionOfADVariant BriefTextDescription
34 actualAD variant dependent; default is InternationalString
35 pointerToAD RecordPointer
36 database ServerAndDb
37 recordId OCTET STRING
38 alternativeIdentifier OCTET STRING
39 typeOfIdentifier OBJECT IDENTIFIER or InternationalString
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:
Element | Occurrence in Brief Record |
typeOfDescriptiveRecord | Always included. |
briefDescription | Included if available. |
collectionInfo | (When typeOfDescriptiveRecord is 1) include the element collectionName only. |
objectInfo | (When typeOfDescriptiveRecord is 2) include elements typeOfObject and categoryOfObject. Also, optionally, digitalObject: include only actualDO (of DigitalObject), if it is available, and include only the variant information (no content). |
associated
Description |
Optional. Some or all occurrences may be included at target discretion. Include the elements briefDescriptionOfAD and categoryOfAD only. |
relatedCollection | Excluded. |
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:
Element | Occurrence in a navigation record |
typeOfDescriptiveRecord | Always included. |
briefDescription | Excluded. |
collectionInfo | Occurs if available. All available elements of CollectionInfo occur. All available elements and all occurrences of EnumeratedMember (within CollectionInfo) occur. |
objectInfo | Excluded. |
associatedDescription | Excluded. |
relatedCollection | All occurrences included. |
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.
4.7.1 Collection-1 Use Attributes
The following Collection-1 Use attributes are defined:
Value Use
1 Record-id
2 Record-type
This attribute is used to distinguish the types of records of interest, as follows:
Term Meaning
0 record is a Descriptive Record
1 record is a Collection Descriptive Record
2 record is a Collection Descriptive Record for a context collection
3 record is an Object Descriptive Record
4 record is a Digital Object
3 Object-type
This attribute is used to distinguish types of objects, as follows:
Term Meaning
1 object is a Digital Object
2 object is a Digital Object for which there is a Physical Object
3 object is a Digital Object for which there no Physical Object
4 object is a Physical Object
This attribute may be combined with Use attribute Record-type, for example, to search for Object Descriptor Records describing Physical Objects only.
4 Parent-collection
This attribute is used to search for Descriptive Records that list the collection (specified by the term) as a parent.
Note: There is no requirement in this profile that a collection or object know all of its parents, but when it does not, full functionality might not be achieved.
This attribute may be combined with Use attribute Record-type to restrict the search to Collection Descriptive Records or Object Descriptive Records.
5 Superior-collection
This attribute is similar to Parent-collection, used to search for subordinate, but not necessarily immediately subordinate, Descriptive Records.
6 Related-collection
Used to search for Descriptive Records for objects or collections that list the collection (indicated by the term) as a related-collection.
7 Collection-name
Used to search for the Collection Descriptive Record for the collection (indicated by the term).
4.7.2 Collection-1 Relation Attributes
The following Collection-1 Relation attributes are defined:
Value Relation
1 equal
2 always-matches
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.
CompSpec is defined in Z39.50 as follows:
CompSpec ::= SEQUENCE{
selectAlternativeSyntax [1] IMPLICIT BOOLEAN,
generic [2] IMPLICIT Specification OPTIONAL,
dbspecific [3] IMPLICIT SEQUENCE OF SEQUENCE{
db [1] DatabaseName,
spec [2] IMPLICIT Specification} OPTIONAL,
recordSyntax [4] IMPLICIT SEQUENCE OF OBJECT IDENTIFIER
OPTIONAL
}
Specification ::= SEQUENCE{
schema [1] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
elementSpec [2] CHOICE{
elementSetName [1] IMPLICIT InternationalString,
externalEspec [2] IMPLICIT EXTERNAL} OPTIONAL}
When the CompSpec parameter is used for the purpose of retrieving a Descriptive Record, it should be used as follows:
A value of 'false' for 'selectAlternativeSyntax' should be accepted by the target.
'generic' should occur.
'dbSpecific' should not occur.
'recordSyntax', which is a SEQUENCE OF, should be the single syntax, GRS-1.
'schema' should be the Descriptive Record schema defined in section 4.
For 'elementSpec', when 'elementSetName' is chosen it should be 'b', 'navigation', or 'f' (see 4.6).
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:
as a variant request in an element specification using eSpec-1, and as such the usage of variant-1 is detailed in 5.4.10;
as an appliedVariant in a GRS-1 record, and as such the usage of variant-1 is detailed in 5.4.11; or
as a supportedVariant in a GRS-1 record, and as such the usage of variant-1 is detailed in 5.4.11.
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:
distinct Digital Objects, using separate instances of ObjectInfo;
a single logical Digital Object, using a single instance of ObjectInfo with multiple occurrences of digitalObject; or
a single logical Digital Object, using a single instance of ObjectInfo and a single instance of digitalObject, with Z39.50 variant information provided for element actualDO.
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.)
5.4.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':
'simpleElement' must be supported, and within SimpleElement the variantRequest must be supported. A variant request will use the variant-1 definition and consist of one or more of:
- a variantId;
- Piece, where Piece is 'start' or 'next' of 'what-fragment wanted'.
Within TagPath, specificTag will always include tagType and tagValue. 'occurrence' is mandatory, for retrieval of the following repeatable elements:
- associatedDescription in the main structure of the descriptive record,
- enumeratedMember of CollectionInfo,
- digitalObject of ObjectInfo, and
- description of AssociatedDescription.
Within Occurrences, 'values' should be supported, and within 'values', 'start' and 'howMany' should be supported. This is useful when the origin wishes to scroll through enumerated Associated Descriptions or collection members, or multiple versions of a given Associated Description or Digital Object.
Support for 'compositeElement' is optional. Companion profiles may mandate its support, for use with Associated Descriptions or Digital Objects which, though opaque to this profile, might not be opaque to a companion profile. For example, an origin might request specific elements of an Associated Description to be packaged as a single SGML element within a GRS-1 transfer record.
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.
For ElementData:
octets Support mandatory.
numeric Support mandatory.
date Optional.
ext Optional.
string Support mandatory.
trueOrFalse Support mandatory.
oid Optional.
intUnit Optional.
elementNotThere Support mandatory for origin, optional for target.
elementEmpty Support mandatory for origin, optional for target.
noDataRequested Support mandatory for Enhanced V3 Conformance.
diagnostic Support mandatory for origin, optional for target.
subtree Support mandatory.
For ElementMetaData:
Series order Optional. (Useful for enumerated collection members or Associated Descriptions when they are arranged in a meaningful order that the target wishes to convey.)
usage right Support mandatory for origin, optional for target. See 5.4.14.
hits Optional. (Not within the scope of this profile, however, companion profiles that model the content of Digital Objects might specify its use.)
display name Optional.
supported variants Support mandatory for Enhanced V3 Conformance.
variantId Always supplied.
bodyPartType Always supplied.
formatting Optional.
language Optional (if applicable; see 5.4.12).
character set Optional (if applicable).
piece Not supplied.
metaData -- cost Optional.
metaData -- size Optional.
metaData -- integrity Optional. If supplied, zero represents highest integrity; higher values indicate progressively less integrity.
metadata -- (all other) Not supplied.
(other) Not supplied.
message Support mandatory for origin.
element descriptor Optional. (Not within scope of this profile; however companion profiles might specify its use, for example to include an SGML DTD.)
surrogate for Optional. See 5.4.13.
surrogate element Optional. See 5.4.13.
For appliedVariant:
variantId Not supplied.
bodyPartType Always supplied.
language Optional. See 5.4.12.
character set Optional (if applicable).
piece For Enhanced V3 Conformance, must be supplied if applicable: values 'start', 'middle', 'last', and (optionally) 'whole' of 'what fragment returned'. If not supplied, 'whole' is assumed.
metaData Optional. (Not within scope of this profile. Companion profiles may specify additional metadata.)
highlighting Optional. (Not within scope of this profile. Companion profiles may specify highlighting.)
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:
that it conforms as an origin or target (or both); and
that it conforms at one of the following levels:
- Basic Conformance,
- Basic V3 Conformance, or
- Enhanced V3 Conformance.
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:
Present parameter CompSpec See 5.4.1.
Element specification eSpec. See 5.4.3.
Variant set variant-1. See 5.4.4.
Fragmentation. See 5.4.5 (and 5.4.9).
Metadata and appliedVariant of GRS-1. See 5.4.11.