THE EAD COOKBOOK- 2002 Edition
The first edition of the EAD Cookbook appeared in 2000 in response to a desire within the profession for practical, step-by-step assistance with the implementation of EAD. It contained a simple model encoding protocol with an accompanying suite of software tools for “authoring” electronic finding aids and stylesheets for “publishing” them on the Web. It functioned as an extension of the EAD Tag Library and the EAD Application Guidelines.
The appearance of EAD Version 2002, the shift of the EAD community from SGML to an XML environment, the appearance of new tools for creating and distributing finding aids, and the emergence of community-based encoding protocols necessitate a revision of that earlier work. While the basic EAD recipe has not changed, some of the ingredients have. As an update, this edition focuses on those aspects of implementation that have changed since 2003, specifically changes in the EAD element set, new tools for creating EAD-encoded documents, and the need to provide additional XSLT stylesheets for transforming EAD files into HTML.
The encoding protocol in the first edition was a compilation of guidelines from several sources. In this version, it is based on the "RLG Best Practice Guidelines for Encoded Archival Description," though no significant differences have resulted from that change. Regularized encoding is important for very practical reasons. The consistent use of the EAD element set makes it possible to exchange and consolidate multiple finding aids from many institutions into union databases or simply with others in one's own repository. Without standardized encoding, it is difficult to manage indexing, display, and manipulation of files. Consistency of presentation also improves user understanding of the purpose and scope of inventories just as the standardized display of library catalogs makes them comprehensible to a large and diverse audience. As testimony to the necessity and wisdom of such regularization, every EAD consortium has adopted some form of encoding protocols.
This edition provides assistance in using three applications for creating encoded finding aids- XMetaL,
New stylesheets have been created that accommodate the changes in EAD 2002, offer greater flexibility and more choices for local display, and a simpler and more fully documented syntax to facilitate local modifications.
Michael J. Fox
Step 1. Learn about EAD.
Three volumes published by SAA make a good start: Encoded Archival Description: Context, Theory and Case Studies, the EAD Application Guidelines, and the EAD Tag Library. The EAD Help pages maintained by the SAA EAD Roundtable contain much practical and useful information, including descriptions of many implementation projects and lists of available training opportunities. They are available at:
Step 2. Determine how you will deliver your finding aids over the web.
How will researchers find these documents? Many options are available. You can do any or all of the following:
The tools for creating EAD documents that accompany the Cookbook are applicable to all of these options.
The Cookbook provides explicit directions in Sections 5 through 7 for implementing publishing options a and b above.
Step 3. Review the general principles and specific details of the Encoding Protocol.
These are found in sections 2 and 3. Some encoding choices are specified in the encoding protocol and built into that accompanying templates. You will need to ratify those decisions and; in other cases, decide what your local practice will be. For example, what text do you wish to appear in specific elements? These sections will help you identify your options and make those decisions. The sources cited above and the EAD Tag Library will provide additional information.
Products currently available include XMetaL, XML Spy, Oxygen, Note Tab, WordPerfect 2000, and others. Consult your favorite web search engine for current addresses and additional information about each of these products.
Step 5. Install and configure the software. (Section 4)
Step 6. Create EAD-encoded finding aids. (Sections 3 and 4)
Step 7. Adopt or modify an existing XSLT stylesheet or create your own.
Step 8. Transform your EAD files into HTML or print. (Section 6)
Step 9. Deliver your finding aids to your users. (Section 7)
Section 2: The EAD Cookbook Design Principles
EAD offers great flexibility in how one might encode a finding aid. The options chosen may have a significant impact on the subsequent usability of the file. The particular markup choices suggested in the ^ are designed to facilitate the transport of data between systems, the sharing of data through union catalogs, the reuse of data for different purposes, hyper-navigation within inventories, and the presentation of data in different environments, currently through the web and as print output. The following principles serve as the basis for the model encoding protocol.
6. No method for managing large numbers of images or other associated non-textual files is prescribed. Repositories using finding aids to link to many external files will need to review the options outlined in Section 4.4.3 of the EAD Application Guidelines. The simple inclusion of an institutional logo can be handled through a single Extended Pointer element or by a stylesheet, as is the case with those that accompany the Cookbook (see Section 5.5).
7. There is a growing consensus within the archival community that there is a set of core data elements that ought to be included at a minimum in every finding aid to help users determine the applicability of a collection to their research needs and to identify specific materials for retrieval and inspection. Appendix A of the EAD Application Guidelines specifies four elements that should be included in every finding aid: the top level Descriptive Identification, Biography or History, Scope and Contents, and Controlled Access. Information regarding user restrictions should be included as appropriate. The specific sub-elements within these groups are described in Section 3. Further, there are certain elements necessary for the identification of the electronic file that carries the encoded finding aid. Some of these are required by the EAD DTD, particularly in the EAD Header element. The "RLG Best Practice Guidelines" goes farther and specifies a larger set of elements as mandatory or recommended.
8. The protocol detailed in Section 3 prescribes the explicit inclusion of certain data elements to facilitate transport, display in external systems, internal hyper-navigation, data reuse such as in converting EAD content into MARC records, and the future migration of data to new systems. One cannot assume that local protocols for display, such as may be specified by a local stylesheet, will always travel with the document or be applied to its presentation in other systems and contexts. The protocol in Section 3 is more prescriptive than the RLG guidelines in one respect. It requires the inclusion of user-friendly displays using the Head element for specific individual elements, because, among other reasons, the text of these Head elements is needed to populate the entries in the table of contents produced by the accompanying stylesheets. It also includes recommended text for display labels used with
9. When encoding inventories, other conventions also apply. Observe the recommendations regarding whitespace and internal punctuation found in sections 126.96.36.199 and 188.8.131.52 of the EAD Application Guidelines and Section 3.3.22 of the Cookbook. Internal links are specifically encoded with a Reference element.
10. Additional markup such as the encoding of personal names and subjects beyond the prescribed structural elements may be cost-justifiable only if it supports enhanced comprehension or retrieval through indexing or display. The protocol markup scheme does not provide any special support, such as keyboard macros for data entry or distinctive styling for display through the stylesheets, for nominal content markup such as
within elements for narrative text such as paragraphs. However, this certainly does not preclude in any way their inclusion. This topic is discussed in several of the EAD case studies that appeared in ^
11. Markup follows the “combined” model for the Description of Subordinate Components. The resulting information may be presented either in the sequence in which it is encoded or divided for presentation into separate “analytic overview” and “in-depth” views of the contents of the inventory by a stylesheet. The use of stylesheets to produce either of these outputs from a single set of data eliminates the need for duplicate entry of information common to the two views.
12. No conceptual significance is implied by the sequence in which elements appear in the encoding specifications or the templates except insofar as the EAD DTD enforces a given order. With the use of the stylesheets written in the XSL Transformation (XSLT) language that accompany the Cookbook, the arrangement of information upon output to the web is largely independent of the order of data in the source document. While the protocol makes few assumptions about input sequence, the stylesheets do enforce a predefined order at publication. However, publication techniques other than XSL stylesheets often are not so flexible and one may have little or no ability to reorder elements. In those scenarios, the order of data input may be directly and absolutely related to the order in which data is published.