Home | News & Events | Events | NISO Past Events | Past Events | Attribute Sets for the Z39.50 Protocol (2nd Meeting)

Attribute Sets for the Z39.50 Protcol

Attribute Architecture Meeting

June 2, 1998

Washington, D.C.

The NISO Attribute Workshop held March 3, 1998 provided the impetus for a second meeting on Attribute Sets held June 2, 1998 during the June Z39.50 Implementors Group (ZIG) meeting in Washington, DC.

Meeting Highlights

The following decisions were made at the attribute meeting held at the ZIG meeting:

  • The ZIG endorsed the new attribute architecture as the model for future attribute sets for Z39.50.
  • Ralph LeVan (OCLC) will coordinate a joint Dublin Core/ZIG working group to develop a cross domain attribute set.
  • A mechanical attribute set will be developed by the ZIG.
  • Lennie Stovel of RLG and a representative from Europe will co-chair a group to develop a new bibliographic attribute set. This group will be under the auspices of ISO TC46/SC4/WG4.
  • The Z39.50 Maintenance Agency will draft policies and guidelines for attribute set developers.
  • The attribute architecture document will be revised to incorporate the technical decisions and changes made during the meeting.


The proposed draft architecture on how to handle attribute sets in Z39.50 is at:

One of the outcomes of the March 3 meeting was a consensus that an additional meeting was needed to make progress on the issues that were raised. It was decided to hold the second meeting at the June ZIG meeting to take advantage of the technical expertise of ZIG participants and the broad international participation of the ZIG.

Based on the first Workshop the following discussion points were identified:

  • What is the purpose of the new architecture?
  • Is there a business case for this activity?
  • Will the new architecture be implemented by Z39.50 developers?
  • Will the new attribute sets be supported by Z39.50 implementers?
  • What possibilities does the new attribute architecture open up, and what constraints does it impose?
  • What specific attribute sets would be immediately useful?
  • What degree of modularity should be assumed in the development of attribute sets? What is the interrelationship among attribute sets?
  • How is the universe of attribute sets to be partitioned: e.g.
    • a cross-domain set (use attributes);
    • protocol attribute set(s), e.g., for Explain, Extended Services;
    • a mechanical attribute set (non-use attributes); domain-specific (or application specific)
  • What is the role of Dublin Core? Will it be superseded by the cross-domain set, and if not, is Dublin Core intended for cross-domain searching; and if not, what is it intended for?
  • Are there requirements for backwards compatibility with version 2 (one attribute set per query)? Should the architecture allow for a virtual single attribute set?
  • Should support for Explain be an assumption in attribute set development?
  • Specific architectural questions:
    • Should nesting be permitted for Use attributes?
    • Should specification of occurrence be permitted for Use attributes?
    • Is anchoring sufficiently specified?
    • Is the rule (section 3.1.2 of attribute architecture document) that a class 1 attribute set may not define any attribute types not defined for class 1 overly restrictive?
  • Domain-Specific attribute sets:
    • What kinds of problems does the existence of domain-specific attribute sets cause? Are there interoperability problems that would not exist otherwise? Can these problems be solved? Can domain-specific attribute sets be partitioned so that there is no overlap among them? Should overlap be permitted or discouraged?
    • Should there be interdisciplinary domain-specific attribute set?
    • What should be the level of specificity (precision) or generality of the domain-specific attribute sets?
    • Who should sponsor domain-specific sets? Who should develop them?
    • Should there be registration procedures for domain-specific sets?
  • Bibliographic domain:
    • Is there a bibliographic domain? What does it encompass?
    • Where should the bibliographic domain-specific attribute set be developed and maintained?
    • How can international involvement with the development be assured?
    • Should there be a "MARC" attribute set?
    • Should there be a bib-2 attribute set?
    • What will be the on-going role of the bib-1 attribute set?
    • What are the role and status of the bib-1 semantics document?
  • Administrative and political considerations:
    • How can future work on these issues be international in scope?
    • Who will take responsibility for seeing that guidelines and best practices for attribute set developers get created and disseminated?
    • Who has the standing for speaking for a domain or application area?
    • Who should define the scope of the non-domain-specific attribute sets? Who should develop the sets?
    • How do we ensure coordinated development among these different communities ?
    • Should any or all attribute sets become official standards, and under what structure?
    • Are Z39.50 attribute sets just for Z39.50, or can they be useful in other contexts?
    • Can work on attribute sets proceed in the absence of work on the type-1 query?
    • Should connotation-free attribute set names be created?


Clifford Lynch (CNI) reviewed the history of attribute set development, the impetus for the architecture document and the conclusions of the March 1998 NISO Attribute workshop. He noted that some underlying assumptions were made in developing the architecture, such as the assumption that Version 3 of Z39.50 would prevail. Other assumptions made were that Bib-1 would be superseded by a new bibliographic attribute set with better semantics. Lynch noted that one of the questions that the community will need to decide is whether or not it was worth the investment to develop attribute sets based on the new architecture.

Other issues that Lynch raised included what new attribute sets needed to be developed, what needed to be done about the Dublin Core and how to handle the Dublin Core in Version 2, should there be a lowest common denominator utility attribute set and what should be in it, how many attribute sets needed to be developed and how would the development process for developing attribute sets be managed, and how should the attribute set space be managed to accommodate multiple attribute sets. Finally, Lynch brought up the question of what should be the scope of any new bibliographic attribute set, how should it be developed, what was its relationship to a general cross domain attribute set that was also under discussion, and the possible need for another new bibliographic attribute set tied to MARC fields and subfields.


Lennie Stovel (RLG) traced the growth of the various attribute types in Bib-1 from the original 1988 standard to the current 1995 version.

ZBIG Group

The Z39.50 Biological Collections Implementors Group or ZBIG, Z39.50 implementors in the biological collections community, reported on their interests and activities. ZBIG is developing a profile for how to use Z39.50 to access their collections. The ZBIG community needs to integrate data residing in relational databases from multiple institutions and make it widely available. ZBIG has built a prototype Z39.50 implementation using the YAZ toolkit.

A general discussion covering a number of issues followed. Questions were raised about how existing attribute sets would fit into the new architecture and how to deal with them; the vendor commitment to a new architecture, the benefits of a new architecture and how disruptive it might be.

From this discussion an endorsement emerged for the overall architecture and principles presented in the architecture document and a consensus that the new architecture should move forward.

Following this general consensus and endorsement, the meeting focused on the remaining technical issues surrounding the architecture:

Cross Domain Attribute Set

There was a general consensus that a cross domain attribute set was needed. This lead to a discussion of the relationship between a cross domain set and the Dublin Core. The group concluded that there should be coordination with the Dublin Core community in the development of a cross domain attribute set. Ralph LeVan (OCLC) agreed to contact the Dublin Core and to coordinate a joint Dublin Core/ZIG working group to develop the cross domain set.

Mechanical Attribute Set

A mechanical attribute set was conceived as being a set of core and common attributes that would most likely be defined in almost all attribute sets and would thus be defined in one place to avoid duplication in multiple places. This set could contain common use attributes and non use attributes like common relation and structure attributes. There was a consensus that such a set was needed and that the ZIG is the appropriate group to define and manage it. Ray Denenberg (Library of Congress) as Director of the Z39.50 Maintenance Agency agreed to take responsibility for drafting the Mechanical Set.

Domain Specific Attribute Sets

The consensus was that communities would need to define themselves, determine the functionality they need to provide, the specific scope of their attribute sets, and examine what may be available in existing sets or sets being developed by other groups. There was also a discussion of the need to develop guidelines and policies for attribute set developers. It was agreed that the Z39.50 Maintenance Agency will take responsibility for this, with the understanding that the process of developing guidelines would be an iterative one.

Bibliographic Attribute Set

After some discussion it was agreed that it be recommended that a group be formed under the auspices of ISO TC46/SC4/WG4 to draft a new bibliographic attribute set. The first action of this new group will be to develop a statement defining the scope of the new bibliographic attribute set and defining how it relates to the cross domain and mechanical sets in development. Lennie Stovel agreed to co-chair this group with a representative from Europe.

Other technical issues

Discussions on the outstanding technical issues surrounding the new attribute architecture resulted in these conclusions.
  • Nesting will be allowed for field names but not Use attributes.
  • Occurrence should not be allowed for Use attributes.
  • Anchoring: The anchor attribute will be dropped.
  • Nesting and occurrence could not be used together.
  • The document will be modified to provide more guidance to developers who might assume they need a new attribute type. The guidance will indicate that proposed additions should be brought to the ZIG for consideration.
  • Use attribute will be renamed to Abstract.
  • The architecture document will be revised to reflect the decisions made at this meeting; Clifford Lynch will supply the historical background section and acknowledgments section.

Report prepared by Mark Needleman.