Following is a preliminary list of notes from the Attribute Architecture meeting. Please send additional notes (or corrections) to rden@loc.gov

1. The so-called "cross domain" set will be developed in conjunction with the Dublin Core set, and Ralph LeVan will coordinate the develoment of a group to get this effort started.
2. A "mechanical" set will be developed by the ZIG. The Maintenance Agency will coordinate this effort, and will develop a preliminary draft. The mechanical set will include "abstract" attributes (formerly know as "Use" attributes; see below) as well as other types (previously it was suggested that the mechanical set include only Use attributes). Potentially, the mechanical set might populate every class 1 type (except fieldname).
3. Question: where do the "collection" attributes belong? For the present, these will be assumed to be mechanical, and will be integrated into the mechanical set (this is subject to discussion).
4. Lennie Stovel will Chair the bib-2 group, which will be developed under the auspices of ISO TC46/WG4/SC4.
5. The attribute architecture document does not provide sufficient guidelines for development of attribute sets. So a document "Guidelines for the Development of an Attribute Set" needs to be developed. The Maintenance Agency will help coordinate this work, but will depend on contributions from attribute set developers, e.g. CIMI, ZBIG, CIP. One of the "guidelines" will be: review existing attribute sets, in order to evaluate, for every potential attribute, whether an existing attribute already satisfies the requirement. In that event, usage of the existing attribute may be "profiled", rather than explicitly adding an attribute to the new set.
6. The category formerly referred to as "Use" will now be called the "Access Point" category. The type within that category formerly called "Use" will now be type "Abstract". (No longer will there be Use attributes; they are replaced by "Abstract" attributes. So in summary; formerly there was category "Use" with types "Use" and "Fieldname". This is replaced by category "Access Point" with types "Abstract" and "Fieldname".)
7. Technical agreements:
   • No nesting of abstract attributes.
   • No occurrence of abstract attributes.
   • Drop "anchor" attribute. Instead, define pre-defined attributes for wildcards. If only a field is specified, it's anchored.
     Thus nesting and occurrence apply only to fieldname attributes, and may not apply together, i.e. no occurrence allowed in conjunction with nesting. Thus may specify "field1 within field2", or "second occurrence of field3" (implicitly anchored, see previous rule); but may not specify "second occurrence of field 1, within field 2".
8. The issue regarding the rule that prohibits an attribute set definition from defining types not listed in the class 1 definition still seems unresolved. One of the suggestions is that instead of prohibiting it, "strongly recommend" not doing it.
9. The dominant attribute set is described as being "most likely one of the utility attribute sets ..... that the ZIG (will) develop" . This is no longer true (and it's not clear that it ever was) and it will be struck.
10. The types of class 1 will be explicitly enumerated.
11. Lennie will supply section 1.1 (Historical Background) and Cliff will supply 1.2 (Acknowldgements).