Z39.50

Attribute Set Developers Guide

Draft 4

September 1999

**Table of Contents**

1 Introduction and Purpose [2](#introduction-and-purpose)

2 Z39.50 Attribute Sets [3](#z39.50-attribute-sets)

2.1 Utility Attribute Set - [3](#utility-attribute-set)

2.2 Cross-domain Attribute Set [3](#cross-domain-attribute-set)

2.3 Bibliographic: BIB-2 [3](#bibliographic-bib-2)

2.4 Thesaurus [3](#thesaurus)

3 Creating Attribute Sets [4](#creating-attribute-sets)

3.1 Roles and Responsibilities [4](#roles-and-responsibilities)

3.2 Attribute Set Development Procedures and Guidelines
[5](#attribute-set-development-procedures-and-guidelines)

3.2.1 Identify Attribute Types and Attribute Values
[7](#identify-attribute-types-and-attribute-values)

3.2.2 Compare Attribute Values with Existing Z39.50 Class 1 Attribute
Sets-
[12](#compare-attribute-values-with-existing-z39.50-class-1-attribute-sets-)

3.2.3 Create Attribute Set Definition
[15](#create-attribute-set-definition)

3.2.4 Submit Attribute Set to Maintenance Agency
[18](#submit-attribute-set-to-maintenance-agency)

4 Attribute Set Development Summary
[18](#attribute-set-development-summary)

5 Definition of Terms [19](#definition-of-terms)

# Introduction and Purpose

A necessary step in developing a Z39.50 Profile is the identification of
Z39.50 attributes. In order to ensure interoperability within and across
domains it will be necessary to develop the attribute sets for a new
profile in a consistent manner. This document describes a standard set
of procedures, and where necessary guidelines, for developing Z39.50
Attribute Sets. This guide assumes that the Z39.50 Attribute
Architecture as described in Z39.50 Attribute Architecture;
<http://lcweb.loc.gov/z3950/agency/attrarch.html> is the framework for
attribute set development. This guide only addresses the Class 1 as
described in the Attribute Architecture. Additionally, this guide
assumes that the reader has read and understands the Attribute
Architecture. Historical background and a brief technical description
can be found in the Attribute Architecture Document.

This guide assumes a general development model that consists of a domain
specific application definition to include a requirements definition, a
profile, and an associated Attribute Set.

The purpose for this guide is to

-   Provide the procedures and guidelines for developing attribute sets
    to the developer of a discipline-specific attribute set ; and

```{=html}
<!-- -->
```
-   Within the procedures and guidelines provide methods to relate new
    domain-specific attributes to attributes in the more general
    attribute sets, (Cross Domain, and Utility) and other Z39.50 Domain
    Specific Attribute Sets that have been developed within the Z39.50
    Attribute Architecture.

```{=html}
<!-- -->
```
-   Additionally, this guide will provide standard guidelines for
    defining Domain Specific Attribute Sets. These guidelines will
    specify what information is necessary to submit the Domain Specific
    Attribute Set to the Maintenance Agency.

```{=html}
<!-- -->
```
-   Also, this guide will aid the ZIG with coordination of attribute set
    developments. As attribute sets will be developed independently and
    at different times, the guide provides guidelines and procedures for
    consistent development of attribute sets that may interplay.

Collectively, these procedures and guidelines will provide sufficient
information such that whoever defines an attribute set will look at
existing attribute sets to determine if there is already an appropriate
attribute for a proposed attribute, and define an attribute for the
proposed attribute only if one doesn't exist. This means (in terms of
the Z39.50 Attribute Architecture) if the developer of an attribute set
needs \"Title\" and if the syntax and semantics of the Bib-2 Title match
the desired semantics of the proposed attribute Title, then a Title
attribute is not needed for the new attribute set. (The new \*Profile\*
will describe how Title is to be searched, i.e. using BIB-2; and the new
attribute set may include a comment explaining why it doesn\'t contain a
Title attribute).\"

# Z39.50 Attribute Sets 

This section provides a brief description of all known attribute sets
that that have been developed under the Z39.50 Attribute Architecture.

## Utility Attribute Set 

The Utility attribute set defined values (for the attribute types
defined for Class 1, as specified by the [Z39.50 Attribute
Architecture](http://lcweb.loc.gov/z3950/agency/attrarch/arch.html) )
that are independent of any particular domain or community, or values
that would otherwise need to be defined in several attribute sets.

## Cross-domain Attribute Set 

The Cross Domain Attribute Set allows a client to perform a simple
non-domain --specific search of a database. It is not intended for
sophisticated domain-specific searches. Sophisticated domain-specific
searches should use domain-specific attribute sets.

## Bibliographic: BIB-2 

TBD

## Thesaurus

This profile builds on the work of others by using the Z39.50 Attribute
Architecture together with the Utility Attribute Set and the
Cross-Domain Attribute Set developed for it.

As such, it requires servers and clients to support version 3 of the
Z39.50 protocol.

In designing the Zthes-1 attribute set of additional attributes required
for thesaurus navigational searches, we have sought to comply with the
guidelines expounded in the Attribute Set Developers Guide.

Unusually for a Z39.50 profile, the intention of this profile is that it
be used in conjunction with other profiles. It is envisaged that an
application will use the Zthes profile to navigate a thesaurus and
thereby obtain terms suitable for searching in a target database; and
use a second, domain-specific profile such as GILS or CIMI to search in
and retrieve from that database

# Creating Attribute Sets

This section of the Attribute Set Developers Guide focuses on the roles
and responsibilities of the Z39.50 Maintenance Agency and the Z39.50
Implementers Group (ZIG). Additionally, the process for developing
attribute sets within the Z39.50 Protocol is also addressed in this
section.

## Roles and Responsibilities

-   **Maintenance Agency and Registration Authority**

> The Library of Congress is designated as Maintenance Agency and
> Registration Authority for ANSI/NISO Standard Z39.50 and ISO 23950.
>
> As **Maintenance Agency**, formal responsibilities include development
> and processing of, and provision of access to:
>
> [Defect Reports](#defects)
>
> [Amendments](#amend)
>
> [Clarifications](#clarify)
>
> [Profiles](#profiles)
>
> As **Registration Authority**, formal responsibilities include
> maintenance of:

-   [Objects and External Definitions](#objects)

> Within the Objects and External Definitions the Maintenance Agency
> registers and maintains the Z39.50 Attribute Sets. The following
> describes these responsibilities.
>
> **Attribute Set Definitions**
>
> Three categories of attribute sets are considered:

-   A *standard* attribute set is one, which is defined within the text
    of the Z39.50 standard: bib-1, exp-1, and ext-1.

-   A *public* attribute set is one, which is not standard, and not a
    local set. It has an OID of the form {Z39-50 3 m}.

-   A *locally defined* attribute set has an OID of the form {Z39-50 3
    1000 n m} where n is the identifier of a registered Z39.50
    Implementor, and m is a number assigned by the implementor.

> Registration and maintenance of attribute sets involves the following:

1.  **Changes to definitions of standard attribute sets.** These are
    done via amendment or defect report.

```{=html}
<!-- -->
```
1.  **Extensions to definitions of standard attribute sets.** An
    implementor, group, or other interested party may propose an
    extension, to be listed (as pending) in the object register, subject
    to discussion and comment over the ZIG list, and scheduled for
    consideration at the next ZIG meeting. The ZIG might:

-   endorse the proposed extensions;

-   endorse the proposed extensions subject to specific modifications;

-   defer the proposed extensions, pending further discussion; or

-   reject the proposed extensions.

    The Maintenance Agency determines the intent of the ZIG and updates
    the attribute set definition in the object registry accordingly.

    If the proposal is, for example, a list of Use attributes, the
    proposal should not attempt to assign permanent numeric values. The
    values are assigned by the Maintenance Agency when the attributes
    are added, and the proposer should not assume any specific values.

2.  **Registration of public attribute sets.** An implementor, group, or
    other interested party may request registration of an attribute set
    as a public definition. The requesting party should provide a
    complete definition of the attribute set (however, in some cases,
    the request will be considered if the definition is still in
    development and not yet complete), a reference, and justifications
    for a public (rather than local) identifier. The Maintenance Agency
    determines whether the attribute set should be publicly registered,
    and may suggest that it should instead be registered locally. If the
    request is accepted, the Maintenance Agency assigns an OID and adds
    the definition to the object registry.

3.  **Changes or extensions to public attribute sets.** The procedures
    for changes or extensions to public attribute sets are similar to
    those for extensions to standard attribute sets (2 above).

> **Registration of and changes and extensions to locally defined
> attribute sets.** See [Locally Defined
> Objects](http://lcweb.loc.gov/z3950/agency/proced.html#localoid).

-   **Z39.50 Implementers Group (ZIG)**

> The ZIG is responsible for the development and maintenance of the
> Attribute Architecture and associated guidelines documents.
>
> The ZIG's overall role with regards to Z39.50 is to provide advice to
> the implementers of Z39.50 profiles. This may include; reviewing
> Implementors Agreements; providing Commentaries, reviewing
> Clarifications; assisting in the development of Amendments; reviewing
> Defect Reports; and where requested endorsing profiles.

## Attribute Set Development Procedures and Guidelines

The Attribute Set Development Procedures and Guidelines begin with the
identification of domain specific attribute types and values followed by
a list of suggested guidelines for comparing the Domain Specific
Attributes with existing Z39.50 Attribute Sets. Lastly, the procedures
for submitting the domain specific attribute set to the Z39.50
Maintenance Agency as well as providing lessons learned to the ZIG is
also described in this section. The following Figure 1 illustrates the
procedures for creating Z39.50 Attribute Sets. The boxes on this
illustration represent external inputs and the ovals are processes that
capture the activity or task. This illustration is then followed by a
textual description of each of the processes identified in Figure 1.

![](media/image1.wmf)

Figure 1 Attribute Set Development Process

### Identify Attribute Types and Attribute Values

The initial step in the process is to identify the Domain specific
Attribute Types and Values. The following graphically illustrates the
steps followed by a recommended procedure for executing each task in
this aspect of the process.

![](media/image2.wmf)

**Inputs** to the task are the Z39, 50 Attribute Architecture, Attribute
Types and the Domain Specific Query Requirements and Data Requirements.

The Query Requirements/Data Requirements will provide the application
knowledge necessary to identify the required attribute types. For
Example the Query Requirements will assist the developer in determining
the required access points while the Data Requirements allow decisions
such as what formats/structure are required.

The Z39.50 Attribute Architecture will provide the Attribute Type
Framework and corresponding rules for developing the Domain Specific
Attribute Set Definition. This architecture defines each attribute type
and provides guidance in their application. For Example ACCESS POINT
Attribute Type is defined in this document as an Intellectual Access
Point or a Database Fieldname Access Point. Additionally, nesting and
anchoring of the access points is also described. This additional
guidance, provided in the Architecture Document, will assist the
developer in constructing complete and accurate attribute definitions.

**Process**

-   **Query Requirements Analysis**

The Attribute Set Developer will first need to collect the domain
specific requirements. This process assumes that these requirements have
been previously collected, verified and approved. This process also
assumes that these requirements have been previously typed, that is,
that each requirement that applies to a query has been identified as a
query requirement and that each requirement that applies to data has
been identified as a data requirement. Each type of requirement will
offer the necessary information to identify the required types of Z39.50
Attributes.

The developer of the attribute set will need to review the query
requirements and further type these requirements as Application Data,
Data Management and Operational types of query requirements. A
definition for each of these types follows.

**Application Data Access Query Requirements**

Application Data Access Query Requirements are those requirements that
specify what data in the domain can be accessed by the system. Each of
these query requirements should initially be analyzed to determine the
access points and allowable terms. This is achieved by extracting the
terms within the query that identify the field name or abstract database
definition. For example, given the following query requirement,
"Capability to locate all data in the XYZ Database where the Spatial
Coverage overlaps a specified Bounding Polygon or contain within a
specified Bounding Box" the Spatial Coverage would be the Access Point.
Additionally, Bounding Box and Bounding Polygon may be Semantic
Qualifiers of the Spatial Coverage Access Point. Therefore the allowable
terms for a query would be Bounding Box or Bounding Polygon. Each of the
Application Data Query Requirements should be analyzed in the same way
to determine the Access Points and any Semantic/Functional Qualifiers
for the Access Points.

**Data Management Access Query Requirements**

Data Management Query Requirements specify the need to determine the
administrative information associated with the data. These queries
target the administrative details associated with a record. For example
a Data Management Requirement may specify that the Data Administrator
should be provided a capability to determine the date(s) when the
record(s) were created and who created the record(s).

**Operational Query Requirements**

The above were examples of access type of Query Requirements that
address what the query will target. In addition to the access type,
there are also Operational Query Requirements, which address how the
query should operate. For example, an Operational Requirement that
specified that the server should return the number of records that
satisfy each of the operands in the query, would indicate that the Hit
Count Attribute Type should be specified in the Attribute Set
Definition.

**Capturing the Analysis Results**

Capturing the results of this task in the following tables may assist in
identifying the attribute types and values that may be discovered
through the Query Requirements. These are the interim analysis results.
The columns reflect each of the attribute types that may be identified
during this process. The rows contain the attribute values for each of
these attribute types. Table 1-1 illustrates the results of deriving the
attribute types and values from the Application Data Access Query
Requirements. Table 1-2 illustrates the results of deriving the
attribute types and values from the Data Management Access Query
Requirements. Table 1-3 also illustrates the derived attribute types and
values however these are derived from the Operational Query
Requirements. The X's in this table indicate that the attribute type is
in effect for this domain specific application.

Given the following requirement statements these tables would capture
the information as indicated:

**Application Data Access Query Requirement Statement**: Capability to
query the Geospatial Database by spatial coordinates that are contained
within a specified bounding box or overlaps, or contained within, a
specified Bounding Polygon.

The Attribute Type **Access Point** would reflect a value of **Spatial
Coverage**. The Attribute Type **Semantic Qualifier** would reflect a
value of **Bounding Box** and **Bounding Polygon** and lastly the
**Comparison** Attribute Type would reflect the value of **Contained
Within** and **Overlaps**.

It should be noted that the above requirement dictates the need for
semantic qualification. However, it is not always the case that the
access point is semantically qualified. For example, a requirement such
as "Capability to access the Bibliographic Database by Bibliographic
Level" would not be semantically qualified.

An additional **Application Data Access Query Requirement Statement**
may be the "Capability to query the Bibliographic Database by specifying
one or more Authors and a Title and selecting/displaying those Authors
and associated Title that equals the specified Authors and Title.

The Attribute Type **Access Point** would reflect a value of **Author.**
The **Comparison** attribute type would reflect **Equals.** An
additional **Access Point** Attribute Type would reflect **Title** and a
**Comparison** Attribute Type of **Equals.**

**Data Management Access Query Requirement Statement:** Provide a
capability to determine the date of last update of the data records in
the database either by specifying a specific date or a date range.
Additionally provide a capability to retrieve a specified creator of the
records in the database.

The Attribute Type **Access Point** would reflect a value of **Date**.
The Attribute Type **Semantic Qualifier** would reflect a value of
**Last Update** and lastly the **Comparison** Attribute Type would
reflect the value of **Equals** and **Between**.

Further an Attribute Type **Access Point** of **Creator of Record** with
a **Comparison** Attribute Type of **Equals** should also be reflected
in the table.

**Operational Query Requirement Statement**:

For each operand return the number of hits to the requestor.

> An **X** in the **Hit Count** column would indicate that this
> capability is in effect for this domain specific attribute set.

Table 1-1 Application Data Access Query Requirements

+-------+------------+--------+--------+--------+---------+----------+
| *     | **Interim  | **I    | **I    | **I    | **      | *        |
| *Attr | Access     | nterim | nterim | nterim | Interim | *Interim |
| ibute | Point**    | Se     | Func   | I      | Compa   | Expa     |
| T     |            | mantic | tional | ndirec | rison** | nsion/** |
| ype** |            | Quali  | Quali  | tion** |         |          |
|       |            | fier** | fier** |        |         | **       |
| *     |            |        |        |        |         | Interpre |
| *\-\- |            |        |        |        |         | tation** |
| \-\-\ |            |        |        |        |         |          |
| -\-\- |            |        |        |        |         |          |
| \-\-\ |            |        |        |        |         |          |
| --** |            |        |        |        |         |          |
+-------+------------+--------+--------+--------+---------+----------+
| *     | Spatial    | Bo     |        |        | Co      |          |
| *Attr | Coverage   | unding |        |        | ntained |          |
| ibute |            | Box    |        |        | Within  |          |
| Va    |            |        |        |        |         |          |
| lue** |            |        |        |        |         |          |
|       |            |        |        |        |         |          |
| *     |            |        |        |        |         |          |
| *\-\- |            |        |        |        |         |          |
| \-\-\ |            |        |        |        |         |          |
| -\-\- |            |        |        |        |         |          |
| \-\-\ |            |        |        |        |         |          |
| --** |            |        |        |        |         |          |
+-------+------------+--------+--------+--------+---------+----------+
| *     |            | Bo     |        |        | Ov      |          |
| *Attr |            | unding |        |        | erlaps, |          |
| ibute |            |        |        |        |         |          |
| Va    |            | P      |        |        | Co      |          |
| lue** |            | olygon |        |        | ntained |          |
|       |            |        |        |        | Within  |          |
| *     |            |        |        |        |         |          |
| *\-\- |            |        |        |        |         |          |
| \-\-\ |            |        |        |        |         |          |
| -\-\- |            |        |        |        |         |          |
| \-\-\ |            |        |        |        |         |          |
| --** |            |        |        |        |         |          |
+-------+------------+--------+--------+--------+---------+----------+
| *     | Title      |        |        |        | Equals  |          |
| *Attr |            |        |        |        |         |          |
| ibute |            |        |        |        |         |          |
| Va    |            |        |        |        |         |          |
| lue** |            |        |        |        |         |          |
|       |            |        |        |        |         |          |
| *     |            |        |        |        |         |          |
| *\-\- |            |        |        |        |         |          |
| \-\-\ |            |        |        |        |         |          |
| -\-\- |            |        |        |        |         |          |
| \-\-\ |            |        |        |        |         |          |
| --** |            |        |        |        |         |          |
+-------+------------+--------+--------+--------+---------+----------+
| *     | Author     |        |        |        | Equals  |          |
| *Attr |            |        |        |        |         |          |
| ibute |            |        |        |        |         |          |
| Va    |            |        |        |        |         |          |
| lue** |            |        |        |        |         |          |
|       |            |        |        |        |         |          |
| *     |            |        |        |        |         |          |
| *\-\- |            |        |        |        |         |          |
| \-\-\ |            |        |        |        |         |          |
| -\-\- |            |        |        |        |         |          |
| \-\-\ |            |        |        |        |         |          |
| --** |            |        |        |        |         |          |
+-------+------------+--------+--------+--------+---------+----------+

Table 1-2 Data Management Access Query Requirements

+-------+------------+--------+--------+--------+---------+----------+
| *     | **Interim  | **I    | **I    | **I    | **      | *        |
| *Attr | Access     | nterim | nterim | nterim | Interim | *Interim |
| ibute | Point**    | Se     | Func   | I      | Compa   | Expa     |
| T     |            | mantic | tional | ndirec | rison** | nsion/** |
| ype** |            | Quali  | Quali  | tion** |         |          |
|       |            | fier** | fier** |        |         | **       |
| *     |            |        |        |        |         | Interpre |
| *\-\- |            |        |        |        |         | tation** |
| \-\-\ |            |        |        |        |         |          |
| -\-\- |            |        |        |        |         |          |
| \-\-\ |            |        |        |        |         |          |
| --** |            |        |        |        |         |          |
+-------+------------+--------+--------+--------+---------+----------+
| *     | Date       | Last   |        |        | Equals  |          |
| *Attr |            | Update |        |        |         |          |
| ibute |            |        |        |        | Between |          |
| Va    |            |        |        |        |         |          |
| lue** |            |        |        |        |         |          |
|       |            |        |        |        |         |          |
| *     |            |        |        |        |         |          |
| *\-\- |            |        |        |        |         |          |
| \-\-\ |            |        |        |        |         |          |
| -\-\- |            |        |        |        |         |          |
| \-\-\ |            |        |        |        |         |          |
| --** |            |        |        |        |         |          |
+-------+------------+--------+--------+--------+---------+----------+
| *     | Creator of |        |        |        | Equals  |          |
| *Attr | Record     |        |        |        |         |          |
| ibute |            |        |        |        |         |          |
| Va    |            |        |        |        |         |          |
| lue** |            |        |        |        |         |          |
|       |            |        |        |        |         |          |
| *     |            |        |        |        |         |          |
| *\-\- |            |        |        |        |         |          |
| \-\-\ |            |        |        |        |         |          |
| -\-\- |            |        |        |        |         |          |
| \-\-\ |            |        |        |        |         |          |
| --** |            |        |        |        |         |          |
+-------+------------+--------+--------+--------+---------+----------+

Table 1-3 Operational Query Requirements

+--------------------+--------------------+----------------------------+
| **Attribute Type** | **Interim Hit      | **Interim Normalized       |
|                    | Counts**           | Weight**                   |
| **\-\-             |                    |                            |
| \-\-\-\-\-\-\-\-\- |                    |                            |
| \-\-\-\-\-\-\--** |                    |                            |
+--------------------+--------------------+----------------------------+
| **Attribute        | X                  |                            |
| Value**            |                    |                            |
|                    |                    |                            |
| **\-               |                    |                            |
| \-\-\-\-\-\-\-\-\- |                    |                            |
| \-\-\-\-\-\-\--** |                    |                            |
+--------------------+--------------------+----------------------------+

-   **Data Requirements Analysis**

> The next step is to identify the attribute types and values associated
> with the Domain Specific Data Requirements and Specification. The Data
> Requirements/Specification typically specify the objects,
> relationships between the objects and the full description to include
> a definition, valid values, and data type of the data associated with
> each object as well as the file/schema definition. Much of this
> information is typically captured in a Domain Specific Data
> Dictionary. This Dictionary can be used to complete the definition of
> the attributes specified in Tables 1-1 and 1-2. Table 1-4 below
> provides a framework for capturing this additional detail.
>
> A typical Data Requirement may indicate that all data must be captured
> in English in which case the profile associated with this attribute
> set definition would indicate that "English" is the only allowable
> value for Language. This information is also captured in the table
> below.
>
> The Data Specification may provide the occurrence information for an
> Access Point Attribute necessary to define the Occurrence Attribute
> Type for that Access Point Attribute. For example, the Data
> Specification my state that the "Author" field, that was previously
> defined as an Access Point, will contain a maximum of 3 Authors each
> separated by a "," (comma). A query may then specify the 2^nd^
> occurrence of the Author.
>
> The Content Authority is obtained from Terms associated with the
> Attribute Values. For example, A **"TITLE"** Access Point Attribute
> Value may have a term **"Gone With The Wind"** whose Attribute Type
> Content Authority may be ***LCNAF??*** Attribute Value.

Table 1-4 Data Requirements/Specifications

+-----+-----+-----------+------+-----+-------+-------+-------+------+
| **  | **I | **        | **I  | *   | **In  | **In  | **In  | *    |
| Att | nte | Attribute | nter | *Va | terim | terim | terim | *Int |
| rib | rim | Def       | im** | lid | Co    | Fo    | Occur | erim |
| ute | Acc | inition** |      | Va  | ntent | rmat/ | rence | Lang |
| Typ | ess |           | **   | lue | Auth  | Stru  | of    | uage |
| e** | Poi |           | Comp | s** | ority | cture | A     | for  |
|     | nt/ |           | aris |     | for   | for   | ccess | Te   |
| **  | Se  |           | on** |     | T     | T     | Po    | rm** |
| \-\ | man |           |      |     | erm** | erm** | int** |      |
| -\- | tic |           |      |     |       |       |       |      |
| \-\ | Qu  |           |      |     |       |       |       |      |
| -\- | ali |           |      |     |       |       |       |      |
| \-\ | fie |           |      |     |       |       |       |      |
| -\- | r** |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-- |     |           |      |     |       |       |       |      |
| ** |     |           |      |     |       |       |       |      |
+-----+-----+-----------+------+-----+-------+-------+-------+------+
|     |     |           |      |     |       |       |       |      |
+-----+-----+-----------+------+-----+-------+-------+-------+------+
| **  | S   | The       |      |     |       | Real  | 1     |      |
| Att | pat | Spatial   |      |     |       |       |       |      |
| rib | ial | coverage  |      |     |       |       |       |      |
| ute | Cov | indicates |      |     |       |       |       |      |
| V   | era | (usually  |      |     |       |       |       |      |
| alu | ge/ | in very   |      |     |       |       |       |      |
| e** |     | course    |      |     |       |       |       |      |
|     | Bo  | re        |      |     |       |       |       |      |
| **  | und | solution) |      |     |       |       |       |      |
| \-\ | ing | the       |      |     |       |       |       |      |
| -\- | Box | spatial   |      |     |       |       |       |      |
| \-\ |     | coverage  |      |     |       |       |       |      |
| -\- |     | of the    |      |     |       |       |       |      |
| \-\ |     | data      |      |     |       |       |       |      |
| -\- |     | descr     |      |     |       |       |       |      |
| \-\ |     | ibed./The |      |     |       |       |       |      |
| -\- |     | limits of |      |     |       |       |       |      |
| \-- |     | the       |      |     |       |       |       |      |
| ** |     | coverage  |      |     |       |       |       |      |
|     |     | expressed |      |     |       |       |       |      |
|     |     | by        |      |     |       |       |       |      |
|     |     | latitude  |      |     |       |       |       |      |
|     |     | and       |      |     |       |       |       |      |
|     |     | longitude |      |     |       |       |       |      |
|     |     | values in |      |     |       |       |       |      |
|     |     | the order |      |     |       |       |       |      |
|     |     | western   |      |     |       |       |       |      |
|     |     | most,     |      |     |       |       |       |      |
|     |     | eastern   |      |     |       |       |       |      |
|     |     | most,     |      |     |       |       |       |      |
|     |     | northern  |      |     |       |       |       |      |
|     |     | most, and |      |     |       |       |       |      |
|     |     | southern  |      |     |       |       |       |      |
|     |     | most.     |      |     |       |       |       |      |
+-----+-----+-----------+------+-----+-------+-------+-------+------+
| **  | S   | The       |      |     |       | Real  | 1     |      |
| Att | pat | Spatial   |      |     |       |       |       |      |
| rib | ial | coverage  |      |     |       |       |       |      |
| ute | Cov | indicates |      |     |       |       |       |      |
| V   | era | (usually  |      |     |       |       |       |      |
| alu | ge/ | in very   |      |     |       |       |       |      |
| e** |     | course    |      |     |       |       |       |      |
|     | Bo  | re        |      |     |       |       |       |      |
| **  | und | solution) |      |     |       |       |       |      |
| \-\ | ing | the       |      |     |       |       |       |      |
| -\- | P   | spatial   |      |     |       |       |       |      |
| \-\ | oly | coverage  |      |     |       |       |       |      |
| -\- | gon | of the    |      |     |       |       |       |      |
| \-\ |     | data      |      |     |       |       |       |      |
| -\- |     | desc      |      |     |       |       |       |      |
| \-\ |     | ribed./Co |      |     |       |       |       |      |
| -\- |     | ordinates |      |     |       |       |       |      |
| \-- |     | defining  |      |     |       |       |       |      |
| ** |     | the       |      |     |       |       |       |      |
|     |     | outline   |      |     |       |       |       |      |
|     |     | of the    |      |     |       |       |       |      |
|     |     | area      |      |     |       |       |       |      |
|     |     | covered   |      |     |       |       |       |      |
|     |     | by the    |      |     |       |       |       |      |
|     |     | data.     |      |     |       |       |       |      |
+-----+-----+-----------+------+-----+-------+-------+-------+------+
| **  | Da  | Date the  |      |     |       | Date  | 1     | Eng  |
| Att | te/ | record in |      |     |       |       |       | lish |
| rib |     | the       |      |     |       |       |       |      |
| ute | L   | database  |      |     |       |       |       |      |
| V   | ast | was last  |      |     |       |       |       |      |
| alu | Upd | updated   |      |     |       |       |       |      |
| e** | ate |           |      |     |       |       |       |      |
|     |     |           |      |     |       |       |       |      |
| **  |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-- |     |           |      |     |       |       |       |      |
| ** |     |           |      |     |       |       |       |      |
+-----+-----+-----------+------+-----+-------+-------+-------+------+
| **  | Ti  | Name of   |      |     | ***   | S     | 1     | Eng  |
| Att | tle | the       |      |     | LCNAF | tring |       | lish |
| rib |     | pu        |      |     | ??*** |       |       |      |
| ute |     | blication |      |     |       |       |       |      |
| V   |     | or        |      |     |       |       |       |      |
| alu |     | journal   |      |     |       |       |       |      |
| e** |     |           |      |     |       |       |       |      |
|     |     |           |      |     |       |       |       |      |
| **  |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-- |     |           |      |     |       |       |       |      |
| ** |     |           |      |     |       |       |       |      |
+-----+-----+-----------+------+-----+-------+-------+-------+------+
| **  | Aut | Name of   |      |     |       | S     | 3     | Eng  |
| Att | hor | the       |      |     |       | tring |       | lish |
| rib |     | i         |      |     |       |       |       |      |
| ute |     | ndividual |      |     |       |       |       |      |
| V   |     | who wrote |      |     |       |       |       |      |
| alu |     | the       |      |     |       |       |       |      |
| e** |     | pu        |      |     |       |       |       |      |
|     |     | blication |      |     |       |       |       |      |
| **  |     | or        |      |     |       |       |       |      |
| \-\ |     | journal.  |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-- |     |           |      |     |       |       |       |      |
| ** |     |           |      |     |       |       |       |      |
+-----+-----+-----------+------+-----+-------+-------+-------+------+
| **  | C   | Name of   |      |     |       | S     | 1     | Eng  |
| Att | rea | the       |      |     |       | tring |       | lish |
| rib | tor | i         |      |     |       |       |       |      |
| ute | of  | ndividual |      |     |       |       |       |      |
| V   | Rec | who       |      |     |       |       |       |      |
| alu | ord | created   |      |     |       |       |       |      |
| e** |     | the       |      |     |       |       |       |      |
|     |     | record in |      |     |       |       |       |      |
| **  |     | the       |      |     |       |       |       |      |
| \-\ |     | database  |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-- |     |           |      |     |       |       |       |      |
| ** |     |           |      |     |       |       |       |      |
+-----+-----+-----------+------+-----+-------+-------+-------+------+
| **  |     | The       | Bet  |     |       |       |       |      |
| Att |     | target is | ween |     |       |       |       |      |
| rib |     | between   |      |     |       |       |       |      |
| ute |     | the       |      |     |       |       |       |      |
| V   |     | search    |      |     |       |       |       |      |
| alu |     | terms     |      |     |       |       |       |      |
| e** |     |           |      |     |       |       |       |      |
|     |     |           |      |     |       |       |       |      |
| **  |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-- |     |           |      |     |       |       |       |      |
| ** |     |           |      |     |       |       |       |      |
+-----+-----+-----------+------+-----+-------+-------+-------+------+
| **  |     | The       | C    |     |       |       |       |      |
| Att |     | target    | onta |     |       |       |       |      |
| rib |     | spatial   | ined |     |       |       |       |      |
| ute |     | /temporal | in   |     |       |       |       |      |
| V   |     | coverage  | Boun |     |       |       |       |      |
| alu |     | is fully  | ding |     |       |       |       |      |
| e** |     | enclosed  | pol  |     |       |       |       |      |
|     |     | within    | ygon |     |       |       |       |      |
| **  |     | the       |      |     |       |       |       |      |
| \-\ |     | spatial   |      |     |       |       |       |      |
| -\- |     | /temporal |      |     |       |       |       |      |
| \-\ |     | coverage  |      |     |       |       |       |      |
| -\- |     | defined   |      |     |       |       |       |      |
| \-\ |     | by the    |      |     |       |       |       |      |
| -\- |     | search    |      |     |       |       |       |      |
| \-\ |     | term.     |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-- |     |           |      |     |       |       |       |      |
| ** |     |           |      |     |       |       |       |      |
+-----+-----+-----------+------+-----+-------+-------+-------+------+
| **  |     | The       | E    |     |       |       |       |      |
| Att |     | target    | qual |     |       |       |       |      |
| rib |     | value is  |      |     |       |       |       |      |
| ute |     | equal to  |      |     |       |       |       |      |
| V   |     | the       |      |     |       |       |       |      |
| alu |     | search    |      |     |       |       |       |      |
| e** |     | term      |      |     |       |       |       |      |
|     |     | value.    |      |     |       |       |       |      |
| **  |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-\ |     |           |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-- |     |           |      |     |       |       |       |      |
| ** |     |           |      |     |       |       |       |      |
+-----+-----+-----------+------+-----+-------+-------+-------+------+
| **  |     | The       | Over |     |       |       |       |      |
| Att |     | int       | laps |     |       |       |       |      |
| rib |     | ersection |      |     |       |       |       |      |
| ute |     | between   |      |     |       |       |       |      |
| V   |     | the       |      |     |       |       |       |      |
| alu |     | target    |      |     |       |       |       |      |
| e** |     | spatial   |      |     |       |       |       |      |
|     |     | coverage  |      |     |       |       |       |      |
| **  |     | and the   |      |     |       |       |       |      |
| \-\ |     | spatial   |      |     |       |       |       |      |
| -\- |     | coverage  |      |     |       |       |       |      |
| \-\ |     | defined   |      |     |       |       |       |      |
| -\- |     | by the    |      |     |       |       |       |      |
| \-\ |     | search    |      |     |       |       |       |      |
| -\- |     | term is   |      |     |       |       |       |      |
| \-\ |     | non-null  |      |     |       |       |       |      |
| -\- |     |           |      |     |       |       |       |      |
| \-- |     |           |      |     |       |       |       |      |
| ** |     |           |      |     |       |       |       |      |
+-----+-----+-----------+------+-----+-------+-------+-------+------+

-   **Repeatability & Nesting (Rules)**

There are several issues surrounding Nesting and Repeatability. This
document serves to identify these issues that are open for ZIG
discussion.

NESTING

1.  Attribute vs. Element

2.  Searchability

3.  Semantic Qualifiers vs. Nesting of Access Points -- can these be
    used in combination. Design choice to emphasize one vs. another.

REPEATABILITY

1.  Semantic Qualifier

2.  Language

3.  Content Authority

### Compare Attribute Values with Existing Z39.50 Class 1 Attribute Sets- 

The primary purpose for this activity is to identify Z39.50 Attributes
that can be reused within the domain specific application. This activity
uses the existing attribute set definitions described in Section 2 of
this document and the domain specific attribute set requirements
formulated in the previous Section 3.2.1. The actual mapping process
involves both syntactic and semantic activities. The syntactic analysis
requires a mapping of the formal definition of the attribute, i.e.
Format/Structure, while the semantic analysis is more of an intellectual
activity that explores the way in which the information is used within
an application. For example, Title in the Automobile Industry relates to
a document of ownership, Title in the Earth Observation Community may
mean the Title of a scientific publication or journal, and lastly Title
in a Personnel Office may mean the Title of an individuals job (i.e.
Senior Engineer, Data Architect., etc.). Therefore, understanding each
of the domain applications is essential in successfully performing the
semantic analysis activity.

When reusing existing attributes from registered Z39.50 Attribute Sets
it is important that the developer coordinate his efforts with the
appropriate registered Z39.50 Attribute Set Developer to ensure that the
domain developer understands how the reused attribute is being
defined/used by each application.

![](media/image3.wmf)

**Inputs** to this task are the domain specific types, rules and values
created in the previous step coupled with the Z39.50 Attribute Sets
(Utility Set / Cross-Domain Set, etc.) and the domain specific data and
query requirements.

**Process:**

> This process assumes that the descriptive components (name,
> definition, valid values and format/structure) of the Z39.50
> registered attributes are available to the attribute set developer.
> This is a two step process that begins with the Syntactical and
> concludes with the Semantical Analysis of the Z39.50 Registered
> Attribute Sets specified in section 3 of this guide and the Domain
> Specific Attribute Set that was developed in the previous step.

**Syntactical Analysis**

> During the Syntactical Analysis each of the Z39.50 Registered
> Attributes should be compared to the domain specific attributes that
> were identified in the previous step. This comparison should include
> the name, definition, any qualifiers that were identified and the
> format/structure for each of the Access Point Attributes. The purpose
> for this activity is to identify any existing registered attributes
> that may be syntactic candidates for the Domain Specific Attributes
> Set Definition.

**Semantic Analysis**

> The Semantic Analysis is less mechanical than the previous syntactical
> analysis. This activity requires that the developer gain insight into
> the Z39.50 Registered Attribute Sets so that he can successfully
> compare the attributes. During this activity it may be necessary to
> obtain the data dictionaries and data models for the Registered Sets.
> From the information contained in these dictionaries and models the
> developer can gain a clear understanding of how the information is
> used in the associated environments. From the models one can determine
> object relationships that can assist in clarifying the definition of
> an attribute. Often dictionaries contain data constraints such as
> valid values. Collectively this information can help to clarify
> ambiguities within any of the data definitions.
>
> For example, if each Z39.50 Registered Attribute Sets have identified
> an access point of "Title" ,each with it's unique semantic qualifier,
> and the domain specific attribute set also requires an access point of
> "Title", then analysis needs to occur to determine if the registered
> attribute of "Title" can be reused in the domain specific application
> with a domain specific qualifier or, a new access point needs to be
> defined. The information contained in the models and dictionaries may
> assist the developer in making this decision.

**Outputs:**

> **Capturing the Results**
>
> The following tables can be used to capture the results of the
> analysis activities. Each of the column headers identify the Z39.50
> Registered Attribute Sets and the Domain Specific Interim Attributes
> that were used during this analysis. The rows contain the Access
> Point/Semantic Qualifier attribute values that were analyzed.

Table 1-5 Access Point Cross Reference Table

+-------------+---------------+------------+------------+------------+
| **Interim   | **Utility**   | **Cross    | **BIB-2**  | **T        |
| Domain**    |               | Domain**   |            | hesaurus** |
|             | **Access      |            | **Access   |            |
| **Access    | P             | **Access   | Poin       | **Access   |
| Poi         | oint/Semantic | Poin       | t/Semantic | Poin       |
| nt/Semantic | Qualifier**   | t/Semantic | Q          | t/Semantic |
| Qualifier** |               | Q          | ualifier** | Q          |
|             |               | ualifier** |            | ualifier** |
+-------------+---------------+------------+------------+------------+
| **Spatial   |               |            |            |            |
| Coverage**  |               |            |            |            |
|             |               |            |            |            |
| **Bounding  |               |            |            |            |
| Box**       |               |            |            |            |
|             |               |            |            |            |
| **Bounding  |               |            |            |            |
| Polygon**   |               |            |            |            |
+-------------+---------------+------------+------------+------------+
| Date        | **Record      |            |            |            |
|             | Date**        |            |            |            |
| Last update |               |            |            |            |
|             | **Date/Time   |            |            |            |
|             | Last          |            |            |            |
|             | Modified**    |            |            |            |
+-------------+---------------+------------+------------+------------+
| Creator of  | **Record      |            |            |            |
| Record      | Creation**    |            |            |            |
+-------------+---------------+------------+------------+------------+
| Title       |               | **Title**  |            |            |
+-------------+---------------+------------+------------+------------+
| Author      |               |            | **Name**   |            |
|             |               |            |            |            |
|             |               |            | **Author** |            |
+-------------+---------------+------------+------------+------------+

Table 1-6 Comparison Cross Reference Table

+---------------+-------------------+----------+----------+-----------+
| **Interim     | **Utility**       | **Cross  | **BIB-2  | **Th      |
| Domain**      |                   | Domain** | Comp     | esaurus** |
|               | **Comparison**    |          | arison** |           |
| *             |                   | **Comp   |          | **Com     |
| *Comparison** |                   | arison** |          | parison** |
+---------------+-------------------+----------+----------+-----------+
| Contained     | **Contained in    |          |          |           |
| Within        | B                 |          |          |           |
|               | ounding-polygon** |          |          |           |
+---------------+-------------------+----------+----------+-----------+
| **Overlaps**  |                   |          |          |           |
+---------------+-------------------+----------+----------+-----------+
| Between       | **Between**       |          |          |           |
+---------------+-------------------+----------+----------+-----------+
| Equal         | **Equal**         |          |          |           |
+---------------+-------------------+----------+----------+-----------+

The bolded items in the above tables identify the selections that have
been made as a result of this analysis. For example this domain specific
application will be using the Utility Set Access Point Attributes
"Record Date" and "Record Creation" and Comparison Attributes "Contained
in Bounding-polygon", "Between" and "Equal"; Cross Domain Access Point
Attribute "Title", and BIB-2 Access Point Attribute "Name" with Semantic
Qualifier "Author". Therefore it is not necessary to define these
attributes for this domain specific application attribute set
definition. The profile for this domain specific application will
indicate that these attributes will be used as defined in the Utility
Set, Cross Domain Set, and BIB-2 Attribute Set Definitions.

### Create Attribute Set Definition

Creating an Attribute Set is creating an Attribute Set Definition that
can be registered with the Z Maintenance Agency. This definition
includes the Attribute Types, Attribute Values, and rules. The following
section will describe the basic elements of a definition.

![](media/image4.wmf)

**Inputs** to this task are the analysis results captured in the above
tables from the previous task. This would include the contents of tables
1-3, 1-4, 1-5 and 1-6.

**Process:**

Creating the final Attribute Set Definition involves

-   Identifying any mandatory attributes,

-   Identifying any rules that may apply when intermixing attributes
    from multiple Class-1 Attribute Sets,

-   Developing valid attribute combinations when applicable and,

-   Optionally identifying/recording any lessons learned.

**Identifying any mandatory attributes**

Each Attribute Type should be reviewed to determine if the Attribute
Type is mandatory for the domain specific application. For example it
may be a requirement that Hit Counts are returned for each operand in
the query. Therefore Hit Counts is a mandatory Attribute Type for the
domain specific application.

**Identifying any rules that may apply when intermixing attributes from
multiple Class-1 Attribute Sets**

By specifying if the attribute set is dominate (Y or N) the developer is
identifying what rules in the operand prevail. The following provides
three scenarios of how to determine dominance.

1.  **New rules have been identified in the domain specific
    application**. The Attribute Types/Values are unique to the domain
    specific application. Therefore, a new OID will need to be assigned
    to the Domain Specific Attribute Definition because of the new
    rules, and this new OID will be dominant for the profile.

2.  **The domain specific application will reuse Attribute Types, Rules
    and Values from an existing Z39.50 Attribute Definition**.
    Therefore, the existing dominance indicator (Yes or No) for the
    existing Z39.50 Attribute Definition that was reused in the domain
    specific attribute set will be applied.

3.  **Several new attribute rules were specified for the attribute types
    in the domain specific and several attribute types from existing
    Z39.50 Attribute Definitions will be reused.** A new OID will be
    issued for this Attribute Definition therefore it will be necessary
    for the developer to determine which attribute set will be dominant,
    the new attribute set **or** the existing Z39.50 Attribute
    Definition.

**Developing Valid Attribute Combinations**

Attribute combinations are the allowable mixtures of attribute
types/values for the domain. For example a Comparison Attribute Type
whose value is equal to "Contained in Bounding-polygon" would be used
with access point attribute type attribute value Spatial Coverage and
would not be used with access point attribute type -- attribute value
Title. The following table provides an example of how valid attribute
combinations can be specified. The columns reflect the Comparison
Attribute Value and the rows specify the Access Point Attribute Values.
The X in the column indicates that the Comparison Attribute Value is in
effect for the associated Access Point Attribute Value.

> Table 1-6 Valid Attribute Combinations

+---------------------+---+---+----------+------------+----------------+
|                     |   |   |          |            |                |
+---------------------+---+---+----------+------------+----------------+
|                     |   |   | Equals   | Contained  | Between        |
|                     |   |   |          |            |                |
|                     |   |   |          | In         |                |
|                     |   |   |          | Boundi     |                |
|                     |   |   |          | ng-polygon |                |
+---------------------+---+---+----------+------------+----------------+
| Title               |   |   | X        |            |                |
+---------------------+---+---+----------+------------+----------------+
| Date                |   |   | X        |            | X              |
+---------------------+---+---+----------+------------+----------------+
| Spatial Coverage    |   |   |          | X          |                |
|                     |   |   |          |            |                |
| Bounding Box        |   |   |          |            |                |
+---------------------+---+---+----------+------------+----------------+

**Identifying/Recording any Lessons Learned**

Optionally identifying/recording any lessons learned as a result of
creating an attribute set definition using the Attribute Architecture
and the guidelines and procedures in this guide. These Lessons Learned
will be used by the ZIG to modify/clarify this process if necessary.

**Outputs:**

Z39.50 Attribute Set Definition. This definition should include an
Access Point/Semantic Qualifier Attribute Type Data Dictionary, for
which a template follows. Additionally, the applicable rules, dominance
indicator, and valid attribute combinations should also be included in
the definition. The definition should also include an indication of
where other Z39.50 Attribute Set Values were used in this Attribute Set
Definition.

The following is a recommended standard template for capturing the data
dictionary information for Access Point/Semantic Qualifier Attributes,
and Comparison Attributes. By using this template developers of
attribute sets can easily compare Z39.50 Access Point/Semantic Qualifier
Attributes and Comparison Attributes with their domain specific
attributes under development. This template has been modeled after the
ISO 11179 *Specification and Standardization of Data Elements*.

Access Point/Semantic Qualifier/Functional Qualifier Attribute Type

Data Dictionary

+-----+------+----------------+------+------+-----+-------+---------+
| T   | Name | Definition     | Data | Lang | C   | Occur | Perm    |
| ype |      |                | Type | uage | ont | rence | issible |
| of  |      |                |      |      | ent |       | Data    |
| Att |      |                |      |      |     |       | Element |
| rib |      |                |      |      | Aut |       | Values  |
| ute |      |                |      |      | hor |       |         |
|     |      |                |      |      | ity |       |         |
+-----+------+----------------+------+------+-----+-------+---------+
| A   | Spa  | The Spatial    |      |      |     | 1     |         |
|     | tial | coverage       |      |      |     |       |         |
|     | Cove | indicates      |      |      |     |       |         |
|     | rage | (usually in    |      |      |     |       |         |
|     |      | very course    |      |      |     |       |         |
|     |      | resolution)    |      |      |     |       |         |
|     |      | the spatial    |      |      |     |       |         |
|     |      | coverage of    |      |      |     |       |         |
|     |      | the data       |      |      |     |       |         |
|     |      | described      |      |      |     |       |         |
+-----+------+----------------+------+------+-----+-------+---------+
| S   | Boun | The limits of  | Sequ |      |     | 1     |         |
|     | ding | the coverage   | ence |      |     |       |         |
|     | Box  | expressed by   | of   |      |     |       |         |
|     |      | latitude and   | Real |      |     |       |         |
|     |      | longitude      |      |      |     |       |         |
|     |      | values in the  |      |      |     |       |         |
|     |      | order western  |      |      |     |       |         |
|     |      | most, eastern  |      |      |     |       |         |
|     |      | most, northern |      |      |     |       |         |
|     |      | most, and      |      |      |     |       |         |
|     |      | southern most. |      |      |     |       |         |
+-----+------+----------------+------+------+-----+-------+---------+
| S   | Boun | Coordinates    | Sequ |      |     | 1     |         |
|     | ding | defining the   | ence |      |     |       |         |
|     | Pol  | outline of the | of   |      |     |       |         |
|     | ygon | area covered   | Real |      |     |       |         |
|     |      | by the data.   |      |      |     |       |         |
+-----+------+----------------+------+------+-----+-------+---------+
| A   | Date | ***See Utility |      |      |     |       |         |
|     |      | Set            |      |      |     |       |         |
|     |      | Definition***  |      |      |     |       |         |
+-----+------+----------------+------+------+-----+-------+---------+
| S   | Last | ***See Utility |      |      |     |       |         |
|     | Up   | Set            |      |      |     |       |         |
|     | date | Definition***  |      |      |     |       |         |
+-----+------+----------------+------+------+-----+-------+---------+
| A   | Re   | ***See Utility |      |      |     |       |         |
|     | cord | Set            |      |      |     |       |         |
|     | Crea | Definition***  |      |      |     |       |         |
|     | tion |                |      |      |     |       |         |
+-----+------+----------------+------+------+-----+-------+---------+
| A   | T    | ***See Cross   |      |      |     |       |         |
|     | itle | Domain Set     |      |      |     |       |         |
|     |      | Definition***  |      |      |     |       |         |
+-----+------+----------------+------+------+-----+-------+---------+
| A   | Name | ***See Utility |      |      |     |       |         |
|     |      | Set            |      |      |     |       |         |
|     |      | Definition***  |      |      |     |       |         |
+-----+------+----------------+------+------+-----+-------+---------+
| S   | Au   | ***See BIB-2   |      |      |     |       |         |
|     | thor | Definition***  |      |      |     |       |         |
+-----+------+----------------+------+------+-----+-------+---------+

Comparison Attributes

Data Dictionary

  ----------------------------------- -----------------------------------
  Name                                Definition

  Equal                               ***See Utility Set Definition***

  Between                             ***See Utility Set Definition***

  Overlaps                            The intersection between the target
                                      spatial coverage and the spatial
                                      coverage defined by the search term
                                      is non-null

  Contained In Bounding Polygon       ***See Utility Set Definition***
  ----------------------------------- -----------------------------------

The following are the definitions for each of the column headings:

**Name:** Single or multi word designation assigned to a data element.

**Definition:** Statement that expresses the essential nature of a data
element and permits its differentiation from all other data elements.

**Datatype of data element values:** A set of distinct values for
representing the data element value.

**Permissible Data Element Values:** The set of representations of
permissible instances of the data element. The set can be specified by
name, by reference to a source, by enumeration of the representation of
the instances or by rules for generating the instances.

**Occurrence:** The actual number of occurrences of the access point
attribute in the record.

**Content Authority:** The source of the supplied term.

**Language:** Specifies the language for the supplied term.

**Type of Attribute:** The type of the attribute being described.
Allowable values are A=Access Point, S=Semantical Qualifier, and
F=Functional Qualifier.

The example content in this table is from the examples used throughout
this document.

### Submit Attribute Set to Maintenance Agency

Submission Requirements:

**Registration of public attribute sets.** An implementor, group, or
other interested party may request registration of an attribute set as a
public definition. The requesting party should provide a complete
definition of the attribute set (however, in some cases, the request
will be considered if the definition is still in development and not yet
complete), a reference, and justifications for a public (rather than
local) identifier. The Maintenance Agency determines whether the
attribute set should be publicly registered, and may suggest that it
should instead be registered locally. If the request is accepted, the
Maintenance Agency assigns an OID and add the definition to the object
registry.

# Attribute Set Development Summary

The following summarizes the details presented in Section 3.2 of this
document. This summary lists the steps required to develop an attribute
set definition for a new application.

1.  Collect and analyze the data and query requirements.

2.  Identify interim access points and semantic qualifiers.

3.  Identify repeatability and nesting rules,

4.  Compare interim attribute values with existing Z39.50 Class 1
    Attribute Sets.

5.  Create Attribute Set Definition.

6.  Submit Attribute Set to Maintenance Agency.

# Definition of Terms

The following table contains the terms and associated definitions used
throughout this document that have not been previously defined the
Z39.50 standard.

  -------------------- --------------------------------------------------
  **Term**             **Definition**

  Domain Specific      A major topic of interest, such as Earth Science,
  Application          Financial or Library Science, to an organization.

  Z39.50 Attribute     A framework for constructing Z39.50 attribute
  Architecture         sets.

  General Development  The general development model is an application
  Model                specific definition. This definition includes the
                       application requirements, the Z39.50 profile, and
                       the application attribute set.

  Cross Domain         A set of attributes that allows a client to
  Attribute Set        perform simple non-domain-specific searches across
                       domain specific applications.

                       

  Utility Attribute    A common set of attributes that may be applied to
  Set                  dissimilar application domains.

  Valid Values         An allowable list of data values for an attribute.

                       

  Z39.50 Attribute Set Attribute sets that conform to the Z39.50
  Class 1              Attribute Architecture.

                       
  -------------------- --------------------------------------------------