EAD Application Guidelines for Version 1.0

How to Use This Manual

Overview of the Application Guidelines
Overview of the EAD Implementation Process
Basic Conventions Used

Overview of the Application Guidelines

The Encoded Archival Description (EAD) Application Guidelines are intended to provide archivists, manuscript curators, and others involved in the description of archives, manuscripts, or other primary research materials with the following information:(4)

In addition to its narrative text, the Guidelines include a variety of useful appendices:

These Guidelines are designed to assist both those considering use of EAD and those actively encoding the descriptive information commonly found in archival finding aids. They address, therefore, the various stages and levels of EAD implementation and its associated activities from both a management and an encoding perspective. They are also intended to provide insight into the rationale, processes, and implications of EAD encoding for a very broad audience, including administrators, resource allocators, managers and supervisors, reference archivists and librarians, finding aid encoders, programmers, and systems administrators. Those needing the broadest possible understanding of EAD will want to study and use all of the chapters as thoroughly as necessary, while those with more limited and specific needs may wish to focus on specific chapters.

Chapter 1 explains EAD in the larger context of archival description and descriptive standards. The selection of SGML is justified; the relationships among EAD, SGML, HTML and XML are explained; the relationship between EAD and the General International Standard Archival Description (ISAD(G)) is outlined; and the continuing important role of MARC records is clarified. Chapter 1 should be studied by anyone considering the use or application of EAD, with the possible exception of programmers and systems administrators.

Chapter 2 focuses on topics relating to management and administration of EAD projects. It covers such issues as the relationship of EAD to institutional mission and goals; the importance of assigning priorities and resources; staffing and training issues; encoding workflow; and questions surrounding conversion of legacy data. It also addresses the possible advantages of outsourcing and of collaborating with partner institutions in cooperative ventures. Chapter 2 will be most useful to those in administrative positions.

Chapter 3, the core of the Guidelines, describes in detail the context within which all major EAD elements are to be applied in constructing an encoded finding aid. This chapter is designed to be used in conjunction with the EAD Tag Library, and one of its principal purposes is to place the Tag Library elements within the context of archival descriptive work. The major components of EAD are presented in a logical progression, beginning with those used to describe the collection as a whole and progressing to those that describe "components" or parts of a collection. A wide range of issues are addressed, from the importance of developing consistent descriptive practice prior to embarking on EAD encoding to specific questions relating to depth of markup. The final section describes use of EAD "metadata" elements, those that describe the finding aid itself. Chapter 3 is of central importance for staff and supervisors actually doing encoding or starting encoding programs. Once they have become familiar with EAD and the various issues and recommendations contained within these Guidelines, particularly as local protocols and processes are established, they will need to refer to this document less frequently. At that point, it may become more expedient to refer directly to the Tag Library for many purposes.

Chapter 4 addresses issues concerned with "authoring" EAD-encoded documents, which refers to the mechanics of using software to apply SGML encoding to a finding aid document. Topics include a comparative discussion of specific software alternatives and authoring approaches; specific software considerations relating to SGML and XML; the relationship of MARC data to EAD finding aids; encoding issues that affect display; and file management.

Chapter 5 describes options for "publishing" EAD documents by making them available to researchers via the World Wide Web. Issues covered here include software choices for searching and resource discovery; stylesheets and their use in both online display and hard-copy output; server- versus client-based delivery and publishing; obtaining hard-copy printouts of encoded finding aids; and systems management issues as they relate to small- and large-scale SGML servers.

Chapter 6 focuses on basic SGML and XML concepts as they relate to EAD. While a comprehensive knowledge of these topics is not essential for all EAD encoders or project administrators, an elementary understanding of them is critical for those responsible for systems design and administration. Subjects covered include the role and structure of the DTD, nesting and inheritance in SGML, character sets, elements, attributes, entities (particularly formal public identifiers), content-bearing versus "empty" elements, general information on presentation and style in both SGML and XML, and the implications of the impending full implementation of XML on SGML in general and EAD in particular.

Chapters 4, 5 and 6 may be of most interest to programmers and systems staff due to their needs to select software, administer EAD servers and systems, and understand the technical aspects of SGML and XML.

Finally, chapter 7 provides detailed information on the use of EAD's linking elements, which facilitate hypertext and navigational capabilities. A variety of useful internal and external linking features are described, including use of the Digital Archival Object element to link from finding aids to digital surrogates of archival materials. This chapter is crucial for those encoders and programmers who intend to implement EAD's rich and complex linking capabilities.

Overview of the EAD Implementation Process

A brief overview of the implementation process is presented in this section to lay the groundwork for the ensuing chapters. In contrast with the "Overview of the Application Guidelines," in which aspects of implementation were addressed in the order in which they are discussed in chapters 1 through 7 of these Guidelines, the present section addresses the basic steps in the order in which a repository might logically confront them.

The basic phases of EAD implementation, with all its apparent attendant complexities, can be summarized by asking three questions:(6)

Each institution's decision to implement EAD will be influenced at least in part by practical considerations. These include such very basic concerns as whether the institution currently has or is prepared to undertake a descriptive program that produces finding aids that are consistent, both internally and with emerging national or international standards. Other questions revolve around institutional mission, goals and audience, and whether implementing EAD will in any way advance the former and serve the latter.

The big question for many institutions will be one of resources: Do we have the staff, the technical competence, and the hardware and software resources to undertake implementation of EAD? If not, is there a collaborative program we can join or develop in order to distribute the resource impact over several institutions? Finally, the question of being able to maintain an EAD program over the long term must be considered, since it will be necessary for repository staff to keep current with changes, such as the evolution of the DTD and the inevitable software upgrades and other innovations that accompany any technological tool.

Once an affirmative implementation decision has been reached, the principal stages in creating EAD-encoded finding aids will include the following:

Finally, repositories must consider possible methods for "publication" and distribution of electronic finding aids in order to make them available to researchers. As with the authoring of encoded finding aids, a variety of scenarios and software choices are available, ranging from simple linking of finding aids to a World WideWeb site, to employing powerful (and often costly) search engines to facilitate researchers' ability to locate relevant materials. All delivery scenarios require use of a combination of conversion scripts and/or stylesheets to interpret EAD encoding for public display and retrieval purposes. Issues pertaining to making printouts of electronic finding aids may also need to be considered.

Basic Conventions Used

To understand many aspects of these Guidelines you will need basic comprehension of some SGML conventions. This section is a brief introduction to these conventions; for more detailed information about SGML in an EAD context, see chapter 6.

Elements: The EAD structure consists of data fields, known as elements. Each element is assigned a unique name, abbreviation, and definition, as specified in the EAD Tag Library. EAD elements are represented by short alphanumeric expressions or tag names, which are surrounded by angle brackets (< >).

In these Guidelines, when each element is first introduced, both its element name and its tag name are given; thereafter, the element is referred to only by its tag name. For example, both the element name Date of the Unit and the tag name <unitdate> are given when this element is first mentioned, but in later discussions of the element, only the tag name <unitdate> is given.

Some EAD elements are known as wrapper elements; they must contain another element before text can be inserted. An example of a wrapper element is Scope and Content <scopecontent>, which must contain a Paragraph <p> before text can be entered. Most elements can contain other elements or text, but not both.

Each piece of text within an encoded finding aid is surrounded by one or more EAD tags; sometimes a specific piece of information is nested within several layers of tags. The examples in these Guidelines illustrate how finding aid text appears between the start-tag and end-tag of each element. For example:

<date>1957</date>

where <date> is the start-tag for the element, "1957" is the finding aid text, and </date> is the end-tag for the element. Unlike HTML, which allows you to omit end-tags for elements such as <p>, SGML permits no tag minimization; you must close every element with an end-tag.

The term subelement is used when the discussion focuses on a broader parent element. For example, within the discussion of Descriptive Identification <did>, Repository <repository>, Origination <origination>, and other elements that are available within <did> are referred to as <did> subelements. Every EAD element except <ead> is a subelement of one or more other parent elements (<ead> is the highest-level element, or document element, in the EAD DTD, and thus has no parent elements).

Attributes: Most EAD elements can be modified through the use of attributes. Although attributes most frequently make the meaning of an element more specific, some are instead used to control display or retrieval. For example, the Date <date> element can be used to encode dates, except those associated with the creation of archival materials (for which <unitdate> would be used). In some cases you may wish to specify what kind of date is being encoded, such as birth dates, publication dates, or acquisition dates; this is accomplished by using an attribute. Whenever attributes are applied, the attribute name and its value are noted within the start-tag of the element:

<date type="publication">

In the above example, "date" is the tag name, "type" is the attribute name, and "publication" is the attribute value. The order and syntax is always the same: tag name, followed by attribute name, followed by an equals sign, followed by the attribute value in quotation marks. Several attributes may be strung together within an element's start-tag.

Within the narrative text of these Guidelines, attribute names are always stated in ALL CAPS, and attribute values always appear within quotation marks. When an attribute name is used within an example, however, it appears in lowercase to match its appearance in an encoded document (as in the example immediately above).

EAD makes extensive use of attributes, most of which are optional (the only two required attributes are LEVEL in <archdesc> and TYPE in <dsc>). For the most part, attributes make it possible to limit the number of elements needed in EAD. The developers utilized generic element names wherever possible to eliminate archival jargon that might have a specific meaning in a given institutional or international context; EAD allows more specific terms to be expressed in an attribute. For example, Component <c> has a LEVEL attribute that specifies the level within the collection's hierarchy which a given component represents--whether it is a series, a subgroup, or a subseries-in lieu of defining separate "series," "subgroup," and "subseries" elements in EAD. All attributes are fully defined in the EAD Tag Library.

The DTD: The structure of a valid EAD-encoded finding aid is controlled by the EAD Document Type Definition (DTD). The DTD defines the elements, determines the order in which they can be used and whether or not they are repeatable, and also controls which attributes are available for each element. The EAD DTD is quite flexible and will accommodate many forms of "legacy data,"(7) while also encouraging archivists to standardize their descriptive practices. This flexibility means that you will often have several options for encoding the same piece of information. When that is the case, the Guidelines present the options in the discussion of the element, along with any pros and cons.

Examples: Examples of markup are provided for each of the elements discussed in these Guidelines. Note that the examples focus on the element being explained and do not include required parent elements. Three fully-encoded finding aids are provided in appendix E. Note that the EAD Tag Library also includes one or two examples of usage for most elements.

Footnotes

  1. Please refer to the glossary in appendix F for the meaning of unfamiliar terms or acronyms mentioned in this introduction and throughout these Guidelines. Many terms are defined elsewhere in the Guidelines in addition to appearing in the glossary.

  2. The term "finding aid" is used throughout these Guidelines to refer to the types of archival descriptive tools typically known as inventories and registers. Although EAD has been optimized for such finding aids, its design precludes neither its use for other kinds of finding aids nor its further development to accommodate new forms of archival description.

  3. Michael Fox, "Implementing Encoded Archival Description: An Overview of Administrative and Technical Considerations," American Archivist 60 (summer 1997): 342.

  4. Legacy data" is a term used to describe finding aids created prior to the existence of EAD. Such finding aids often must be restructured to some degree in order to fit within EAD's hierarchical structure and set of data elements.

Table of Contents
Home Page Preface Acknowledgments How to Use
This Manual		 Setting EAD
in Context		 Administrative
Considerations
Creating Finding
Aids in EAD		 Authoring EAD
Documents		 Publishing EAD
Documents		 SGML and XML
Concepts		 EAD Linking
Elements		 Appendices

Go to:

Copyright Society of American Archivists, 1999.
All Rights Reserved.

[VIEW OF LC DOME] The Library of Congress

Library of Congress Help Desk (11/01/00)