![[VIEW OF LC DOME]](http://www.loc.gov/homepage/lc2.gif)
The Library of Congress
As explained in section 1.4, SGML provides the capability to encode the full structure and intellectual content of documents in a nonproprietary software environment; as an SGML Document Type Definition, EAD shares these characteristics. Further, SGML's inherently hierarchical approach to data structure mirrors the information hierarchies that have long been a fundamental part of archival description. Thus, use of EAD, which was written specifically for encoding archival finding aids following the rules of SGML, represents an important investment in a repository's finding aid data by capturing the full meaning of its structure and content, in addition to enabling sophisticated retrieval, display, and navigational techniques.
HTML, on the other hand, provides only the capability to encode visual presentation characteristics such as font size, bolding, italics, and line breaks. The structure and content of a finding aid cannot be exploited when the encoding is in HTML. Future data migration is not facilitated because the meaning of data elements and their structural relationships are not retained; this increases the likelihood that data will have to be reformatted or reconfigured manually when migration to a new software environment is necessary. See section 1.3 for additional information.
EAD provides a standardized set of data elements for finding aids that was devised by archivists who are experts in archival description. Its developers have refined EAD in response to widespread input received from colleagues from throughout the United States and several other countries. EAD already is in widespread use, and as the archival community gains experience in its use, consistency of practice is likely to improve and software products will be developed to make implementation easier and cheaper. Perhaps most importantly, user comprehension of archival descriptive data can be expected to improve as more and more repositories share the same encoding structure and rules to create finding aids for their collections and disseminate them internationally via the World Wide Web.
Prior to the development of EAD, many repositories already were using in-house relational database software to create finding aids for complex collections in order to take advantage of powerful searching capabilities and the ease of indexing and updating data. Regardless of how well they have served their individual repositories, however, such internal databases lack the standardized data structure and the platform independence that is assured by use of EAD and that is essential for searching across finding aids from multiple repositories.
Use of EAD does not, however, preclude use of database software for local data input and storage. Repositories that already create finding aids using software such as Access or dBase may wish to determine the extent to which their database fields are analogous to EAD elements, make any necessary changes to ensure compatibility, and then call upon the expertise of a programmer to develop a conversion script that will map the database fields into EAD (see section 4.2.4). EAD can then be used as the basis for making the finding aids available to users, as described in chapter 5.
As discussed in section 1.4, the TEI data structure is designed for encoding literary and other scholarly texts, and it has gained widespread acceptance within the humanities community. TEI does not include many of the specific elements that appear in archival finding aids, however, and thus would not have served the archival community's needs effectively. On the other hand, TEI is an excellent encoding scheme for use by an archives that wishes to encode digitized versions of actual scholarly texts, which can then be linked to EAD-encoded finding aids in appropriate situations.
Section 1.6 sets MARC cataloging into context with EAD. At this point in the development of EAD, MARC catalog records constitute important navigational metadata that makes it both easier and more efficient to get to encoded finding aids from existing bibliographic and other systems. Many users begin their searching for research resources in an online library catalog, and it is crucial to maintain summary archival information within such integrated bibliographic systems in order to lead those users to EAD-encoded finding aids and the archival materials they describe.
ISAD(G) is an international standard that provides a framework for multilevel archival descriptions and that can serve as a strong basis for establishing "best practice" for EAD-encoded finding aids. EAD is a much more detailed and specific data structure standard that was developed with ISAD(G) in mind and thus is compatible with ISAD(G). See section 1.2 for additional information.
Chapter 2 outlines a variety of administrative issues that are important to consider at the outset when contemplating use of EAD. As a supplement to chapter 2, the Implementation Checklist in appendix D will help you ponder the many organizational variables that must be taken into account in your planning.
Most repositories that decide to go ahead and adopt EAD will face two distinct types of implementation work: creating new finding aids and converting existing finding aids. Each type presents its own challenges, and although this may seem counterintuitive, creating new finding aids is likely to be easier than converting existing finding aids. This is because it will be possible to think afresh about how to structure the content of new finding aids after getting a sense of EAD's data structure. See sections 2.5.3 and 2.5.4 for more information.
Due to EAD's basis in the platform-independent metalanguage SGML, users have a wide variety of hardware and software choices; no single environment is required. To be able to encode its own finding aids, a repository will need a minimum of a desktop computer and some sort of software for applying EAD tags to finding aid documents. If a repository wishes to disseminate encoded finding aids on the World Wide Web, or to upload its finding aids into a shared or union database, it also will need a network connection and the ability to serve data to the Internet. As with most hardware and software, the more money you can spend, the more sophisticated the functionality you will be able to afford, but a basic implementation of EAD is feasible with minimal investments in hardware and software. Chapter 4 describes a variety of scenarios for selecting authoring software, and chapter 5 details various methods for serving finding aids to the Web.
As discussed in section 3.3, it is recommended that each repository examine its existing descriptive practices for both overall consistency and for compatibility with EAD prior to beginning any encoding. Following such analysis, a repository will be able to identify the array of EAD elements and attributes that best fit its descriptive needs, the order in which the elements will be presented for overall presentation of a finding aid, and the visual layout characteristics that will be written into a stylesheet to effect the display of clear and consistent finding aids to users. It is particularly important that such conventions be developed in the context of multi-institutional cooperative projects.
In addition, those repositories that create MARC catalog records may have some decisions to make about how to effect compatibility between MARC records and EAD finding aids, as well as how to alter existing workflow in order to avoid duplication of effort. More information is provided in section 1.6.
The necessary training will vary depending on the particular tasks that a staff member will be expected to perform. Those who will determine which EAD tags are to be applied to finding aids will need thorough familiarity with both the EAD Tag Library and chapter 3 of these Guidelines. As of 1998, the Society of American Archivists offers EAD workshops, as does the University of Virginia's summer Rare Book School program. Consortia (including the Research Libraries Group) often sponsor workshops to train participants at the outset of an EAD project.
Those who will use particular software packages to apply EAD tags will of course need training in the repository's chosen software. Systems specialists will need more sophisticated understanding of SGML files and systems; some of this information is provided in chapter 6 and chapter 7 of these Guidelines.
For additional information, see sections 1.7.3 and 2.5.2.
The answer to this question depends on a variety of factors, including the realities of a particular repository's staff expertise, the methods currently used for producing finding aids, existing computer resources, and budget for acquisition of software. A variety of options for "authoring" of EAD finding aids (that is, for using computer software to apply EAD encoding to finding aids) are presented in section 4.2.
Section 2.5.4 discusses conversion of existing finding aids, often referred to as "legacy data." The discussion is organized around three major topics: prioritization of existing finding aids, revision strategies, and conversion techniques.
As described in section 2.5.4.1, each repository must examine a number of variables and make its own decisions about prioritization. Your decision making may focus on striking a balance between two major issues: which finding aids are considered the most important, and which will be the easiest and quickest to convert.
It certainly can. As discussed in section 3.5.2.3, EAD provides the capability to describe materials at the item level at whatever level of detail a repository feels is necessary, and this has been accomplished successfully by a variety of early implementers.
Section 4.4 details five relevant types of "integrity" that must be considered: encoding consistency, DTD conformance, file names and locations, version control, and security. Most will be familiar from your experience with descriptive standards and management of online systems.
Chapter 5 describes a variety of scenarios for "publishing" EAD finding aids, or in other words, for making them available to users. These scenarios range from the simple and affordable to the complex and costly. In addition to online delivery, EAD finding aids can of course simply be printed.
The development of large databases of EAD-encoded finding aids documenting collections from numerous repositories, and the dissemination of these finding aids on networked systems such as the World Wide Web, can be expected gradually to result in a critical mass of widely available descriptive data about archival materials. Within such a context, the encoded finding aids will provide a viable intellectual infrastructure through which digital copies of original historical materials, or "digital archival objects," can be linked to the finding aids that describe them. In some environments, links will also be made from encoded finding aids to MARC records describing archival collections at a summary level. Thus, users will be able to navigate from MARC records to encoded finding aids to digital representations of actual archival materials. See chapter 5 for additional scenarios by which users may be able to access encoded finding aids.
There are three essential online sources of such information:
The Encoded Archival Description Official Web Site, maintained by the Network Development and MARC Standards Office of the Library of Congress, is the official source of the EAD Document Type Definition files. The site also includes background information on the development of EAD, instructions for subscribing to the EAD Listserv, and descriptions (with links) of numerous EAD implementation sites, including some of the most significant cooperative projects. URL: <//www.loc.gov/ead/>.
The EAD Help Pages, maintained by the EAD Roundtable of the Society of American Archivists, contains a wide variety of useful information and links to helpful sites. Items include links to tools and helper files (both those available from commercial vendors and others made available for free by EAD implementers), descriptions of the authoring and publishing software used by individual EAD implementation sites, links to useful readings on SGML and XML, and an "I need help!" feature in which users can write for assistance with a specific question. Archivists are invited to participate in the EAD Roundtable and contribute to the Web site. URL: <http://jefferson.village.virginia.edu/ead>.
The EAD Listserv is an interactive forum for learning the latest EAD news and asking questions of experts. Subscription information is available online at <//www.loc.gov/ead/eadlist.html>.
In addition, other well-maintained Web sites focusing on EAD, SGML, and XML applications are listed in the Bibliography in appendix G.
The Library of Congress