Z39.50 Attribute Architecture
Version 1.1
July 9, 1999
August 6: clerical error corrected in table in 3.3. Functional qualifier is repeatable (had been listed as not repeatable).
Document Status and Change History
Version 1.1 is the current version of the Z39.50 Attribute Architecture, and is a revision of version 1.0, dated January 20, 1999. Version 1.1 amends version 1 as follows:
- In 3.1.1, "Semantic Precedence and Interaction among Sets", there is revised wording concering the definition of a "dominant" set. Also, the rule prohibiting mixing of class 1 attributes with pre-architecture attributes is strengthened.
- In 3.2.2, a new attribute type is defined: Functional Qualifier (also added to the table in 3.3).
- Section 3.5 is re-written to elaborate the roles of and differences between the Utility and Cross Domain sets.
1. Introduction and Preliminary Notes
1.1 Historical Background
The initial attributes for the bib-1 attribute set were developed by
representatives of the Library of Congress, RLG, OCLC and
WLN in the mid-1980s. This U.S. set was merged with a similar set from European library system developers to become bib-1. It was the only attribute set definition included in the published
version of Z39.50-1992 (version 2).
Problems with the bib-1 attribute set began to surface at that time (1992). Within the bibliographic community, implementors had no published definitions of the bib-1 attribute semantics, thus vendors implemented the bib-1 attribute set with their own interpretations of the attribute usage. A document was produced to clarify this (Bib-1 Semantics Document), although it was never formally included as part of the standard.
As the Internet grew, more communities wanted to implement Z39.50 and, in turn, needed additional attributes (beyond those already in bib-1) to reflect the types of data they wanted to exchange. This proved difficult as Z39.50-1992 did not allow a query to include attributes from more than a single attribute set. Since bib-1 was the only publicly visible set, it was expanded to accommodate the needs of these communities. Thus, bib-1 grew without plan or rigor, evolving away from the bibliographic community where it had started, and "bib-1" became somewhat of a misnomer as it grew into a global set of attributes.
In 1994 and 1995, as Z39.50 version 3 was being finalized and as Z39.50
began to be widely implemented, additional concerns arose over the relationships among attribute sets that other groups were developing, notably the STAS and GILS attribute sets. The Z39.50 Implementors Group (ZIG) had many questions about the development and implementation of multiple attribute sets, including duplication of attributes across sets. In early 1996 a discussion paper by Cliff Lynch (Defining and Maintaining Attribute Sets for Use with the Z39.50 Protocol: A
Discussion Paper ) detailed the issues:
- Duplication of common attributes in specialized attribute sets,
due to the limits of the version 2 query.
- Interoperability problems due to attribute set proliferation, for
example, how to know which basic attributes were imbedded in
specialized sets.
- Ambiguities in the semantics of attributes.
- Lack of rigorous semantics in the bib-1 attribute set; lack of a
scope statement for the bib-1 attribute set; lack of consultation
with the broad community concerned with bibliographic records.
- Lack of guidance about the semantics of mixing attributes
from different attribute sets in a single Z39.50 query (and in particular, in a single query operand).
Following discussion of these issues at the February 1996 ZIG meeting, Lynch
volunteered to bring together a group of interested people to
recommend resolutions of the issues. The group met three times.
Lynch prepared interim reports that were discussed at subsequent ZIG
meetings. The final report of the group was presented at the
January 1998 ZIG meeting. The current text of the new architecture
includes revisions based on discussions then as well as at subsequent
ZIG meetings and over the ZIG mailing list.
The major conclusion of the group was that a new architecture for
attribute sets should be developed; they went on to recommend an
architecture based on classes of attribute sets, with expanded
attribute types. Another major conclusion was that expert
communities, rather than the ZIG, should be responsible for
developing and maintaining attribute sets (following the example set by GILS
and STAS). Notably, they recommended that the bibliographic
community, rather than the ZIG, develop the next generation of
bibliographic attributes. The ZIG should continue to be responsible
for attributes that are general to Z39.50, that is, not specific to
a given community.
1.2 Brief Technical Background
Z39.50 defines a number of query types, and requires support for the type-1 query (support for other defined query types is optional). This document addresses the Z39.50 type-1 query only.
The type-1 query consists of one or more search terms, each with a set of
attributes, specifying, for example, the type of term (author, title,
subject, etc.), whether the term is truncated, its structure, etc. The
server is responsible for mapping attributes to the logical design of the
database.
A term in a type-1 query, together with its accompanying collection of
attributes, is called an operand. Operands may be
combined in a type-1 query, linked by boolean operators (And, Or, And-not,
and Proximity).
Each attribute is a pair: an attribute type and a value
of that type. An Attribute set defines a set of attribute types,
and for each type defines the set of possible values.
An attribute set definition is assigned an object identifier, referred to
as its attribute set identifier.
Example: The bib-1 attribute set defines a
number of attribute types; one of which is Use. For bib-1 Use attributes,
many attribute values are defined, one of which
is personal name. Each type is assigned a numeric value, and each value is assigned
a numeric value: type Use is assigned the value 1, and Use attribute Personal Name is
assigned the value 1. Thus bib-1 Use attribute Personal Name is represented as the pair
(1,1). This pair is further qualified by the bib-1 attribute set identifier (1.2.840.10003.3.1) to distinguish it from the pair (1,1) that may be defined by another attribute set.
Version 2 of Z39.50 has two serious limitations inhibiting the development of attribute architecture, both corrected in version 3:
- In version 2, all attributes within a query must belong to the same attribute set (the query accommodates only a single, global attribute set id). In version 3, attributes may be combined from different attribute sets, within a single query, even within a single operand (an attribute set id may accompany every attribute). This is a significant enhancement, for two reasons: First, it is useful when searching multiple databases. (Although version 2 supports multi-database searching, all attributes within a query must belong to a single attribute set, which inhibits the ability to search multiple, heterogeneous databases.) Second, new attribute sets may be defined with less replication.
- Version 2 allows only a single ASN.1 representation for search terms, namely ASN.1 type OCTET STRING. In version 3, new data types for terms are defined, for example, integer and character string.
1.3 Limitations and Restrictions
1.3.1 Version 3 Assumption
There are several enhancements in version 3 pertaining to attribute sets
and query construction; the two enhancements described
at the end of 1.2 are certainly the most important, and are seen to be functional
prerequisites for the development of an attribute architecture. For this reason, version 3 is
assumed by this architecture, and version 2 is not addressed.
1.3.2 Type-1 Query Limitation
The Z39.50 type-1 query has known limitations, and the architecture
specified in this document is restricted by these limitations. As the
standard evolves and new versions are approved, the architecture may be
expanded. See section 4: "Lessons Learned: Recommendations for Future Enhancements to the Z39.50 Query".
1.3.3 Semantic Indicator
In order to compensate for some of the type-1 limitations, it may be
necessary to utilize the semantic indicator (provided within version 3)
for purposes that would otherwise be accomplished by more coherent
mechanisms if these limitations were not present. It is intended that these limitations
will be addressed in future versions of Z39.50, obviating the need for extensive use of the semantic
indicator at the attribute level.
2. Attribute Set Class Definitions
The attribute architecture allows definition of multiple attribute set classes. An attribute set class provides an umbrella context for the definition of an attribute set belonging to a particular class. It defines attribute types that may be included in an attribute set for that class. Attribute set Class 1 is defined as part of this architecture document (section 3).
This architecture strongly recommends that an attribute set definition that conforms to a particular class but defines attribute types that are not defined for that class should carefully define the interactions between the new attribute types and existing types defined for that class.
The architecture provides the attribute-set-class approach to allow flexibility and future expansion within the existing architecture. It is believed that attribute set Class 1 meets all known needs for an attribute class at this time. There may be other approaches developed which partition the set of attributes into fundamentally different types. This might result in the definition of a new attribute class inconsistent with Class 1. However, no need for such a separate class has been identified and it is not known whether additional classes will be necessary.
2.1 Attribute Values
These rules for construction of attribute values pertain to all classes.
An Attribute set may define the set of values for a particular attribute type as follows:
- The attribute set definition may supply a finite list (where individual members of the list may be numbers or character strings).
- The attribute set definition may define the type as numeric. For example, the value of an 'occurrence' attribute may simply be the actual occurrence, that is, to indicate "second occurrence of field N" the value of the Occurrence attribute would be 2.
- The attribute set definition may specify that a locally defined value, either a number or string, may be used as the value of the attribute for that type.
- The attribute set definition may specify that the attribute may take on a sequence of values, where each is any of the above (1, 2, or 3).
An Attribute value in an operand may thus be a number, string, or sequence of numbers and strings. A number value might take the role of 1 or 2 above, and a string value might take the role of 1 or 3; in each case, the role is interpreted by the attribute set definition.
3. Attribute Set Class 1
Class 1 is intended to cover all known, existing requirements, at the time that this version of the attribute architecture was finalized. (Existing attribute sets may need to be re-specified within this framework.)
The purpose of enumerating all of the possible attribute types within
this "universal" attribute class is to provide a template for developers
of attribute sets, and to set up a framework for interoperability among
independently defined attribute sets which are intended to serve various
communities. In particular, it should be possible for groups of content
experts to develop new Access Point attributes, ASN.1
datatypes, comparison operators, and perhaps Format/Structure attributes which fit comfortably
within this framework. Based on the template
defined here, server developers may recognize attribute types omitted in a
query operand, as well as illegal repetitions or combinations of attributes
of given types that would indicate a malformed query operand.
3.1 General Rules for Class 1
3.1.1 Semantic Precedence and Interaction among Sets
The context of this attribute class is in effect for a query when the OID of an attribute set conformant with Class 1 is specified as the global OID (the object identifier within the type-1 query that does not accompany a specific attribute). For Class 1, the global OID is referred to as the dominant OID for the query. When
attributes from different attribute sets are mixed within a query, and
when the respective attribute set definitions conflict such that the
resulting semantics are ambiguous, the semantics of the dominant set
prevail. As an example, suppose attribute set definition A declares that the Language type is mandatory in an attribute list, while attribute set definition B declares it to be optional. If attribute set A is used as the dominant set for a query, then the Language attribute would have to be supplied within every operand; if attribute set B is the dominant set, it would not.
When an attribute set is developed in accordance with Class 1, its definition should state that it is a Class 1 attribute set. In addition, the definition may describe the rules that apply (when it is used as the dominant set) for intermixing of attributes from different sets within an operand or query.
Attributes from attribute sets conformant to Class 1 should not be mixed, within a query operand, together with attributes from historical attribute sets defined prior to the development of this attribute architecture (e.g. bib-1).
3.1.2 Populating Class 1 Attribute Sets
An attribute set consistent with this attribute class will define
attributes of one or more of the types specified in 3.2.
Any Class 1 attribute set follows the rules prescribed for Class 1
that apply to attribute types defined for that set. However, a Class 1
attribute set need not define nor populate every attribute type defined
for Class 1. A Class 1 attribute set may define as few as one attribute
type, or as many as all of the attribute types defined for Class 1.
Thus no specific attribute type is mandatory in the sense that it must be included in an attribute set definition. (This use of the term mandatory is different from the use of mandatory to mean that a particular attribute type may not be omitted in an operand, as used in the Occurrence column of the table in 3.3. For example, the Comparison attribute type is mandatory in an operand.)
However, a Class 1 attribute set must use the numeric values in the "Type Number" column in the table in section 3.3, to represent the types; if any of these types is omitted in the attribute set definition, the definition should skip the value for that type rather than renumber.
An attribute set might be developed for an application or profile and may refer to values of a particular attribute type that are defined by a different attribute set. If all of the values of that type that are required by the application are already defined by that other attribute set, then that attribute t
ype need not be defined for the new set.
There may often be a close relationship between the development of a profile for a particular application, and the development of an attribute set definition to support the application. The profile might refer to several attribute sets in describing how to construct query operands (or entire queries).
Thus the attribute set definition is not, itself, responsible for specifying all of the details of searching for the application when those details involve attributes from different attribute sets; however, the attribute set may offer as much commentary as it deems necessary and
appropriate, for example, it may explain why a particular attribute has been omitted from its definition (for example, because another attribute set has defined it). It might explain how certain attributes that are defined in the set are to be combined with attributes from other sets.
3.1.3 Omitted Attributes
An attribute set definition should not specify a default value for an attribute type to
be applied when that attribute type is omitted from an operand. Each individual server may
determine the semantics of omitted attributes. Thus when a client omits an attribute of a given
type from an operand (unless that type is not applicable for the given attribute combination, or unless the attribute type is mandatory) the client is, in effect, leaving it to the server to select a value. See also 3.2.1.3, "Omitted Attributes in Conjunction with Nested Access Point Attributes".
The presence or absence of any attribute should not imply the presence of any other attribute, whether of the same or a different type. (For example, the presence of an Access Point attribute should not imply the presence of an otherwise omitted Format/Structure attribute, even if the relationship seems obvious.)
3.1.4 Syntactic Content of Search Term
A query operand should be constructed such that the server may determine the syntactic content of the search term based on the ASN.1 datatype of the term as well as the Format/Structure attribute, if supplied (and if the Format/Structure attribute is not supplied, by the ASN.1 datatype alone). In general, the value of the Access Point attribute should not contribute to this determination.
Even in cases where there is only one legal value of a Format/Structure attribute, and when the client might expect the server to deduce that value, it should be explicitly supplied. An exception is when the ASN.1 type completely and unambiguously determines the format, for example when the ASN.1 type is INTEGER or GeneralizedTime, or when the Z39.50 Date/Time definition is supplied (as EXTERNAL); in these cases the Format/Structure attribute may be omitted. ASN.1 type InternationalString does not unambiguously determine the format.
An attribute set developer should determine all of the Format/Structure attribute values necessary to fully specify the term formats relevant to the attribute set, and for each, either include it as a Format/Structure value in the attribute set definition, or ensure that it is defined in another attribute set (and provide appropriate reference within the attribute set definition).
3.1.5 Repeatability
In general, if an attribute type is allowed to be repeatable within an operand, the semantics of
repeating the attribute type must be well-defined.
While repeatability may be permissible for a given attribute type, as a
general principle, an attribute type should not be repeated as a
substitute for Boolean operations. To amplify this point, an attribute
definition might prescribe how to interpret, for example, multiple
Access Point attributes in a single operand. The definition might
prescribe (as examples):
- Multiple Access Point attributes may be supplied in
order of preference, so if a server does not support the first supplied, then use the second, etc.; or
- if multiple Access Point attributes are supplied, the server
is to choose the "best" among the set; or
- if multiple access point attributes are supplied, they are to be treated as nested access points (see 3.2.1.1).
The above three examples are for illustration only. There may be other possible interpretations for multiple Access Point attributes.
The definition may include a semantic indicator, allowing a client to
select among several semantic alternatives. However, none of those
alternatives should be to construct separate operands (linked by boolean
'and' or 'or') for each Access Point attribute -- the type-1
query supports boolean operations, so allowing another means of specifying boolean operations
would add unnecessary complexity (in contrast to potential semantic interpretations of multiple
Access Point attributes which cannot be otherwise
represented via the type-1 query, as in the examples above).
3.1.5.1 Mechanism for Repeating Attributes
There are two mechanisms supplied by the Z39.50 standard for providing multiple attributes of the same type within an operand:
- Via 'list' within 'complex' CHOICE of 'attributeValue' within
AttributeElement; defined in section 4.1 of Z39.50-1995, Abstract Syntax and ASN.1 Specification of Z39.50 APDUs. (This mechanism is provided by version 3, and not supported in version 2.)
- Via separate instances of AttributeElement.
Although Z39.50 provides both of these mechanisms, the first mechanism is prescribed for Class 1.
3.2 Attribute Types Defined within the Attribute Class
3.2.1 Access Point Attribute Type
The Access Point attribute defines either an intellectual access point (for applications that work with abstract database definitions) or an access point corresponding to a database fieldname (for applications where searching is defined in conjunction with a specific database schema, or defined to correspond to a specific Z39.50 tag set).
The presence of an Access Point attribute is mandatory in an operand.
An attribute set definition that defines this type should include a discrete list of values.
3.2.1.1 Nesting and Anchoring of Access Point Attributes
Nesting of Access Point attributes may be supported by an attribute set definition. If so, nesting should be indicated by repetition of the Access Point attribute type (as prescribed in 3.1.5.1), where the order of nesting is as in the following example: field 1, field 2, and field 3, supplied in that order, means "field 3 within field 2 within field 1". An example of the use of nesting might be a field path within an SGML database.
An Access Point attribute may be indicated as not anchored (matching may occur beginning at any
node within the element tree) by nesting it within an Access Point attribute of value 'wildpath' (for example as defined in the Utility attribute set). In the absence of a wildpath attribute, it is considered anchored (matching must occur from the root of the element tree).
Example of Anchored vs. Not Anchored:
Suppose a schema includes elements Description, Contact, and Availability, where Description is unstructured (has no sub-elements), Contact is structured into sub-elements Name, eMail, and Description, and Availability is structured into sub-elements, one of which is Contact, similarly structured (leaf elements shown in bold):
- Description
- Contact
- Availability
When the single Access Point attribute Description is specified as anchored, then it is
intended to match first-level element Description; if multiple Access Point
attributes Contact and Description are specified as anchored, then it is
intended to match Description within first-level element Contact. If Contact and Description
are specified as not anchored, then it may match Description within first-level element Contact, or Description within Contact within Availability. If the single Access Point
attribute Description is specified as not anchored, then it may match first-level element Description, Description within first-level element Contact, or Description within Contact within Availability.
3.2.1.2 Mixing Access Point Attributes from Multiple Attribute Sets
Mixing Access Point attributes from multiple attribute sets, within an operand, is permissible.
Attribute sets might be defined that correspond directly to tag sets (which define Z39.50 retrieval elements). A search field might be defined corresponding to an element path defined by a retrieval schema. A type-1 query operand might correspondingly be constructed with nested Access Point attributes corresponding to the elements in the tag path for the field. Those elements may be from different tag sets, where the different tag sets correspond to different attribute sets. Correspondingly, the Access Point attributes would belong to different attribute sets.
3.2.1.3 Omitted Attributes in Conjunction with Nested Access Point Attributes
When an attribute type is omitted, and when nested access points are specified (via multiple Access Point attributes values), the server will choose values for the omitted type based on the most specific access point in the list. For example, when searching field-1 within field-2, and the language attribute is omitted and the server must then select one, it should select it based on field 1, not field 2.
3.2.2 Qualifying Attribute Types
- Semantic Qualifier Attribute Type
One or more Semantic Qualifier attributes may be included in a query operand.
The server is to pair each supplied value with the Access Point attribute
to try to find a best match with its indexes.
When the operand includes nested access points, each semantic qualifier value applies to the entire access point specification, that is, to the set of nested Access Point attributes.
The client may indicate that the server may ignore the Semantic Qualifier(s) by including a null Semantic Qualifier (see Utility attribute set) thus allowing the server to match the Access Point attribute value with null, in effect rendering it unqualified. The Semantic Qualifier attributes are in no sense combined among themselves. They are not presented as a list of increasingly precise qualifiers. An attribute set definition that defines this type should include a discrete list of values. This attribute is repeatable.
The Semantic Qualifier attribute is distinguished from the Functional Qualifier attribute, and the distinction is described below.
- Functional Qualifier Attribute Type
One or more Functional Qualifier attributes may be included in a query operand.
The mechanical aspects of the usage of the Funtional Qualifier type are the same as those of the Semantic Qualifier type: the server is to pair each supplied value with the Access Point attribute to try to find a best match; when the operand includes nested access points, each functional qualifier value applies to the entire access point specification; the Null value (from the Utility set) may be included to indicate that the server may ignore the functional qualifier(s);
an attribute set definition that defines this type should include a discrete list of values; the attribute is repeatable.
The Semantic Qualifier and Functional Qualifer types correspond to "type" and "role" respectively. The Semantic Qualifier describes the term itself, while the Functional Qualifier describes the relationship of the term to the object being searched. For example, consider a search on an author, where the author is a person and thus the term is a personal name. The Access Point attribute value would be 'name', the Semantic Qualifier value would be 'personal name' and the Functional Qualifier value would be 'author'.
When a qualifier (semantic or functional) is to be defined and it is unclear whether it should be a Semantic Qualifier or Functional Qualifier, it is recommended that it be defined as a Semantic Qualifier.
- Language Attribute Type
The value of this attribute indicates the language of the supplied term. An attribute set definition that defines this type should either include a discrete list of values, derived from some standard source, or else refer to some standard source for values. In the interests of simplicity it is recommended that this attribute be non-repeatable, though there may be situations where repeatable Language values could be
meaningfully interpreted.
- Content Authority Attribute Type
The value of this attribute indicates the source of the supplied term. An attribute set definition that defines this type should include a discrete list of values. In the interests of simplicity it is recommended that it be non-repeatable, though there may be situations where repeatable content authority could be meaningfully interpreted.
- Expansion/Interpretation Attribute Type
This attribute may be used to indicate, for example, that thesaural expansion, singular/plural matching, part of speech qualification, phonetic matching, case sensitivity,
stemming, truncation (including left and/or right anchored as well as word-by-word truncation), or various loose forms of phrase matching, should be used in the query evaluation.
Server preprocessing instructions should be included in this type, for example, "do not treat any words in this term as a stopword" and "do not remove punctuation".
An attribute set definition that defines this type should include a discrete list of values. This attribute is repeatable.
3.2.3 Query Management Attribute Types
These attributes have the property that they can be rewritten by the
server as part of a revised query that the server returns to the client.
- Normalized Weight Attribute Type
The value of this attribute is the weight of the operand (in a weighted boolean query). An attribute set definition that includes this type should specify a normalization value (e.g. 1000).
This is a non-repeating, numeric attribute.
- Hit Count Attribute Type
The value of this attribute is the number of records satisfying the operand. This attribute is intended to convey information from server to client, but it may be passed back from client to server when the client simply wants to turn around a reformulated search -- in that case, it is to be ignored by the server. This is a non-repeating, numeric attribute.
3.2.4 Comparison Attribute Type
The Comparison attribute defines the relationship between the term in the operand and the term in the term list at the server.
The presence of a Comparison attribute is mandatory in an operand, as it is presumed that there is always a relationship between the term and the value of the access
point to which the term is compared (otherwise there would be no basis for comparison) and that the client knows the relationship; therefore, based on the principle stated in 3.1.3 ("Omitted Attributes") the client should always supply the relationship.
The Comparison attribute is a generalization of the bib-1 Relation attribute, though named differently to avoid confusion. (The bib-1 Relation attribute is not mandatory in bib-1, as bib-1 has no such rules of occurrence, nevertheless, there is always a relationship, implied or explicit. One of the problems with bib-1, that Class 1 tries to correct, is the potential ambiguity when the relationship is not supplied.)
An attribute set definition that defines this type should include a discrete list of values. This attribute is non-repeatable.
Sample values might
include:
- complete match
- does not match
- contains
- contained in bounding-polygon
- match via regular expression
- relevance feedback
- equal, not equal, greater than, etc.
- between (range operations in conjunction with a range datatype)
3.2.5 Format/Structure Attribute Type
This attribute is used primarily to help with the interpretation of a character-string term; it provides guidance for the datatype conversion process.
Developers of specific Access Point attributes should consider defining (or utilizing existing) ASN.1
datatypes to support their applications -- for example, personal names,
dates, geospatial information (points and polygons). There will of
course be cases where the ASN.1 approach to datatyping will be too
heavy-weight; in those cases the Format/Structure attribute type can be
used in conjunction with ASN.1 type InternationalString to indicate that the content of a string
represents data in a specific format. However, a character string term should not be used to represent an integer (e.g. to represent the integer 123, the term should assume ASN.1 type INTEGER, rather than the character string '123'.)
Personal names are an interesting boundary case where one might argue either for an ASN.1 based definition or a Format/Structure attribute indicating a normalized name according to some
rules; the choice of the appropriate approach is best left to a bibliographic-attribute-definition working-group.
An attribute set definition that defines this type should include a discrete list of values. This attribute is non-repeatable.
3.2.5.1 Dates
A date/time value might be expressed in any of the following forms:
- ASN.1 type GeneralizedTime,
- The Z39.50 ASN.1 Date/time
definition,
- Some other EXTERNAL definition for date and/or time,
- ASN.1 type InternationalString.
In case 4, a Format/Structure attribute should accompany the term, indicating for example, that the term is a normalized date. For cases 1 through 3, no Format/Structure attribute should be supplied.
3.2.5.2 Character String
A term which is to be treated as a literal character string, or as a word-oriented phrase subject to preprocessing by the target, should be accompanied by the Format/Structure attribute 'Character String'. Whether and what type of preprocessing applies should be indicated by an
Expansion/Interpretation attribute.
Whenever the 'Character String' Format/Structure attribute is supplied:
- The order of the words in the supplied term is to be preserved (when preprocessing applies).
- The Term should be represented as ASN.1 type InternationalString.
3.2.6 Occurrence Attribute Type
The value if this attribute is the desired occurrence of an access point. For example "second occurrence of field-1". This is a non-repeating, numeric attribute.
3.2.7 Indirection Attribute Type
The presence of this attribute indicates that the actual content of the term is not supplied, but instead, a pointer (e.g. url) to the term is supplied in lieu of the actual term. An attribute set definition that defines this type should include a discrete list of values; e.g. URL, URN. This attribute is non-repeatable.
3.3 Enumeration and Summary of Class 1 Attribute Types
The table below enumerates and summarizes the Class 1 Attribute types.
An attribute set definition must use the numeric values in the "Type Number" column below to represent the types. If any of these types is omitted in an attribute set definition, the definition should skip the value for that type rather than renumber.
In the "value" column, 'list' means that when an attribute set defines that type, the attribute set definition should include a discrete list of values for the type.
In the Repeatable column, if the value is "yes" (meaning that the attribute type is repeatable) an attribute set definition may declare the type to be non-repeatable, but if the value is "no", an attribute set may not declare the type to be repeatable. (When an attribute set definition declares a type non-repeatable, this means that the attribute type may not repeat within any operand of a query, when the attribute set is specified as the dominant set for the query.)
In the Occurrence column, "mandatory" means that the attribute type must occur in an operand (it does not mean that a given attribute set must define that type). "Optional" means that in general the attribute type need not occur in every operand; however, a specific attribute set definition may declare that the attribute is mandatory (or mandatory in certain circumstances) in which case, the rules specified would be in effect when the attribute set is specified as the dominant set for a query. An attribute set definition may not declare an attribute type to be optional if it is listed as "mandatory" in this table.
The numerical order of attributes types (as listed in this table) differs from the order in which they are defined in section 3.2.1: attribute type Functional Qualifier is new in version 1.1 (it was not defined in version 1.0) and was added to the table at the end, to avoid re-numbering.
| Attribute Type | Type Number | Value | Repeatable | Occurrence | Roughly-corresponding Bib-1 Type |
|---|
| Access Point | 1 | list |
yes | mandatory | Use |
| Semantic Qualifier | 2 | list |
yes | optional | (new) |
| Language | 3 | list |
yes | optional | (new) |
| Content Authority | 4 | list |
yes | optional | (new) |
| Expansion/Interpretation | 5 | list |
yes | optional | Truncation and some of Relation |
| Normalized Weight | 6 | numeric |
no | optional | (new) |
| Hit Count | 7 | numeric |
no | optional | (new) |
| Comparison | 8 | list |
no | mandatory | most of Relation and part of Completeness |
| Format/Structure | 9 | list |
no | optional | Structure |
| Occurrence | 10 | numeric |
no | optional | (loosely) Completeness |
| Indirection | 11 | list |
no | optional | (new) |
| Functional Qualifier | 12 | list |
yes | optional | (new) |
3.4 Attribute List Construction
Within a properly constructed operand, the attribute list within an operand should:
- include attributes in ascending order by attribute type;
- include all types listed as mandatory;
- include no more than a single occurrence of a given type for any type listed as not repeatable; and
- conform to any further restrictions (not specified at the Class 1 level) on allowable combinations of attribute types, as specified by the attribute set definition for the dominant attribute set for the query.
3.5 Utility and Cross Domain Attribute Sets
Both a Utility attribute set and a Cross Domain atttribute set will be developed and maintained; these will be Class 1 attribute sets.
The Utility set will define commonly used values for the Class 1 types. In addition it will include metatdata access points for records, as distinguished from metatdata access points for resources; the latter is the province of the Cross Domain set.
This distinction between record and resource is characterized by the example of a MARC record that describes a document. The MARC record is the "record" and the document is the "resource". This is not to imply that this architecture (or that Class 1) models record and resource as always distinct. When the record is the resource (e.g. in a document database) the metadata access points are the province of the Cross Domain set.
An example of an access point that characterizes the difference in purpose of the two sets is 'language': There will be a language access point in both sets. Utility set Access Point Language will refer to the language of the database record, while Cross Domain set Access Point Language will refer to the value of the language field. For example a MARC record, created in English, might describe a French book. The Utility Access Point attribute Language would refer to the language of the MARC record, while the Cross Domain Access Point attribute Language would refer to the language of the book (English and French, respectively). Another example: the "creator" of the MARC record is similarly distinguished from the "creator" (or author) of the book that the record describes.
The Cross-domain set is defined for use by cross-domain queries (where a single query is applied to multiple domains) and more generally, for attributes that apply to multiple domains, whether to be used in a cross-domain query or not. For example, Access point 'title' will be defined in the Cross Domain set and then need not be defined in any domain-specific set. Thus a bibliographic set need not define 'title'; rather, it could define semantic and/or functional qualifiers for 'title'; then, effective access point "bibliographic title" would be constructed using 'title' from the Cross Domain set and appropriate semantic and/or functional qualifiers from the bibliographic set.
4. Lessons Learned: Recommendations for Future Enhancements to the Z39.50 Query
As a result of the deliberations over this architecture, limitations posed by the type-1 query have
resulted in identification of recommended enhancements that should be considered for a future
version of Z39.50. These are documented here; additional contributions to this list are welcome and will be added:
- The term in an operand should be replaced by a sequence of Terms. In the interim, ASN.1 definitions such as MultipleSearchTerms-1 may be
used.
- Explicit range operators will be useful and should be added in favor of boolean combinations
of operators that result in range definitions.
- Attributes on operators should be supported.
- Nesting should be handled at the operator level rather than by repeating attributes. That is,
for "field 1 within field 2", 'within' should be an operator.
Library
of Congress
Comments