TagSet-G

Principles, Usage, and Scope


The following usage and scope principles for tagSet-G were agreed upon at the August 1997 ZIG meeting in Copenhagen.

tagSets G and M have been revised, based on these principles. See TagSet-G - Revised TagSets G and M.


Introduction

TagSet-G includes elements with common usage within a significant number of user communities. In the absence of a schema that specifies stricter semantics, TagSet-G elements have broad, loose semantics. They implicitly inherit more specific semantics when used within a specific user community. When used across communities, a schema should be used to tighten those semantics.

For example, the Museum community can use the Title element interoperably with loose semantics; within that community they all know what they mean by a Title. Similarly, the Genealogy community uses Title as well, but with different implied semantics. The problem arises when the Museum of Genealogy want to provide records. Then they will need a schema that defines the semantics of Title.

Scope and Criteria

A generic element may be proposed for addition to tagSet-G, by a group of implementors developing a Z39.50 profile or a schema, if that group believes that the element will provide utility beyond their specific application. The Maintenance Agency will establish corresponding maintenance procedures for tagSet-G; these procedures will directly address the process of adoption or rejection of a proposed element.

Generic Semantics of TagSet-G Elements

Each tagSet-G element will be assigned generic semantics that may be inferred by a client when the element occurs outside the context of any specific schema.

Context specific semantics of TagSet-G Elements

Generic semantics attributed to a tagSet-G element are (in general) weaker than the semantics of that element as defined within a schema. The intent is that general elements may be inherited by schema for more specific usage.

Thus a tagSet-G element may be attributed stronger semantics when it occurs within the context of a specific schema. For example, the element Author has generic semantics such that if it occurs outside the context of a schema it is interpreted as "Author or Creator". A specific schema (for example, pertaining to museum objects) may confine its meaning to "Creator".

For the remainder of this document, an element occurrence is referred to as "context specific" or "generic" depending respectively on whether it occurs within or not within the context of a specific schema.

Schema context of TagSet-G Element

A tagSet-G element may occur within a retrieval record as generic or context specific. A client may infer that a generic occurrence pertains to the record at large, and the client should attribute generic semantics. If the occurrence is context specific and if the client does not support the context (i.e. the schema), the client should not infer any information from the occurrence. A tagSet-G element may have both context specific and generic occurrences within the same record; in that case if the client does not support the context, the client may infer that the generic occurrences apply, while ignoring any context specific occurrences.

For example, suppose a client executes a search across databases creating a result set that represents records from potentially several domains. When the client retrieves a record from the result set, unless the retrieval record includes a schema identifier, the client might not know what schema governs the interpretation of the elements of the record. Suppose in this case the first several elements are from tagSet-G, say: Author, Title, and subject. Following these initial tagSet-G elements, assume there is a structured element with subelements, the first of which is a schemaIdentifier (tagSet-M element 1). Suppose that the client does not support the identified schema, and suppose further that there are several tagSet-G elements following the schema identifier. The client is able to discern that the Author, Title, and Subject pertain to the record, but the client is not able to process the record further, in particular, the client may not infer information from the second set of tagSet-G elements. In this case, the client may be able to inform the user that there is a potential record of interest, and that in order to interpret the record, support for the specific schema is necessary.

As another example, consider a database where an individual record corresponds to a physical object (for example, a work of art) and the record includes one or more digital renditions of the object. An abstract record structure may specify that tagSet-G elements may occur at the beginning of the record, outside the context of a specific schema, followed by a schema identifier, followed by a repeating, structured element, with a repetition for each rendition. There may be tagSet-G elements within each such "rendition" element, and these would pertain to the specific rendition. (The 'Title' or 'Author' for the first rendition may be different from those of the 'second' rendition. For example, the first rendition may be "black and white still image, 35mm" where the listed 'Author' is the photographer; while the second rendition may be a sketch of the physical object, where the listed 'Author' is the artist of the sketch. The Title and Author in both cases would be different from those of the object itself.)

TagSet-G element used as utility elements, within a Tag Path

TagSet-G elements may be used within a tag path, as for example in the GILS abstract record structure: there is an element 'availability' (GILS element 70), subordinate to which is an element distributor (GILS element 90), and thus is constructed the element availability/distributor. Subordinate to this element are several tagSet-G elements: name, organization, address, and telephone. Thus are constructed the following elements: In this scheme These four tagSet-G elements play the role of utility elements, allowing GILS to avoid the need to define special tags for these commonly used elements.

A client receiving a record that includes these GILS elements (assuming the GILS schema to be in effect) should not infer any information from the presence of these tagSet-G elements, unless the client supports the GILS schema.

Utility container elements

Elements such as displayObject (formerly bodyOfDisplay) and documentContent are available as container elements. Additional utility elements may be added, if deemed generally useful.
Library of Congress
November 26, 1997