EAD or Encoded Archival Description is an SGML application for tagging information in archival finding aids. Finding aids are the inventories, descriptions, lists or indices that a researcher might use to find particular documents in an archive or collection. The Library of Congress has a better definition of finding aids and a fuller description of the EAD.
Finding aids? Finding aids provide structure to collections of papers and help interpret the materials. Archival materials like manuscripts, letters and photographs, are usually by-products of activities and thus fragmentary, rather than finished products. A cataloging record usually doesn't need to interpret a book in terms of the author's biography, but many finding aids must do precisely that. (Speaking of catalogs, here's information on the National Union Catalog of Manuscript Collections, at LC http://lcweb.loc.gov/coll/nucmc/).
Why EAD? EAD allows you to define logical structures and relations. Databases can be programmed to express logical structure (many finding aids are local databases). But most finding aids tend to be prose lists, indexes, registers or a combination of everything. EAD can handle it all and it allows the encoder to impose a logical structure. You can use as much or as little structure as you wish.
Prose and logical relations? With a wordprocessor you usually express logical relationships by placement (like a list or outline) or by typographical appearance. A classic example is the multiple meaning of italics to represent emphasis (HTML's "<em>" tag), the Title of a Book (HTML's "<cite>" tag) or a foreign word (no HTML equivalent). An SGML application like the Text Encoding Initiative (TEI) could let you distinguish each use. This "granularity" can be useful.
Why not a Database? That's a good question. Proponents see EAD as a text database (it just needs some software to create indices and to make it useable). However, EAD isn't as easy to use as a relational database -- at least for those people who have learned how to use one. Indeed, a powerful RDMS like SQL (rather than Access, dBASE, Foxpro or Paradox)
An Open Future. The logical structure created in EAD won't be lost when you switch wordprocessors. Switching from Wordperfect to Microsoft Word could trash your outline, your redlining, your footnotes or your laboriously differentiated fonts. But SGML applications do not rely on proprietary software or hardware. You're not trapped. Like HTML, EAD uses pure text and <tags>.
Viewing EAD? Yuck. Raw EAD can't be displayed attractively by Web browsers except as pure text containing distracting tags. Currently (early 1998) EAD finding aids can be delivered on the Web in two ways:
The converted files won't have all the logical structure of an EAD file, but they're readable, and you still have the master EAD files. Maintaining two sets of files isn't ideal, but the setup works. The future holds some possibilities with eXtensible Markup Language (XML); see my description and links on SGML.
The EAD sites page has some links to programs converting "on-the-fly"; other options include Perl scripts (shudder!).
External Links. External links from EAD finding aids to URLs or to images are still a problem. In order to manage links, your EAD manager should have some proficiency Perl or programmers editors like Multiedit, to make global changes. Personally, I think this is less a problem than some professionals make it.
People looking to link external images, audio files, etc., to EAD inventories should check out the Ebind DTD (see links). It's a tagging system for elements which fall outside of formal finding aids, transcripts or cataloging records.
Envoi: I'm still reading and thinking about EAD. I remain a little skeptical of EAD since I'm not a programmer comfortable with Perl scripts. I'm troubled by a lot of things:(UC Berkeley has a nice toolkit and a Perl-based form template for generating EAD conformant SGML.) I hope these troublesome things will eventually go away. I'm watching and hopeful.
- the lack of widely available tools to create and verify EAD.
- the lack of tools to serve EAD (either by dumbing-down to HTML or by hooking into a Web browser).
- the number of projects that have a "let's jump on the bandwagon" feel.
In the meantime, it behooves every archivist and curator to examine EAD and be able (or prepared) to map their current systems to EAD tags, even if they don't take the plunge. Sure, a relational database in Foxpro, MS-Access or even SQL, is faster than EAD, but some materials will always be more easily described in prose. Also, you must be careful about being locked into a data format which you can't control (Wordperfect or MS Word DOC files, DBF, MDB or WKS files). (And for those archivists who tout relational databases like Paradox or Access, check out my links on SQL databases.) Archivists and librarians control EAD, not some corporation only concerned with short-term profitability. (Incidentally, I have read on comp.text.sgml of some individuals working on [what seems impossible] an RDBM DTD. N.B. This isn't the same as SDQL [Standard Document Query Language])
More on databases. A good technical article is now online called XML and Databases by Ronald Bourret, which talks about (among other things) the differences between data-centric and docu-centric systems.
This article describes a way of converting finding aids in Microsoft Access 97 databases to EAD < http://sunsite.berkeley.edu/FindingAids/uc-ead/tools/database/>. Prepared by Gabriela Montoya, UC Berkeley Library. (The article describes creating a report in which you embed the EAD into the report's objects, opening the report's results in MS Word, saving as text, and processing with a Perl script to remove excess lines, and pasting into the rest of your finding aid. You use Access data to create the list of collection items in the finding aid. My take: why not create a parent "meta" table containing the collection-level information and a linked definition table [defining EAD entities], and output all three to separate SGML and HTML files? Much safer to automate the conversion and assembly than to be required to do it by hand repeatedly.)
I look forward to your comments, corrections and additions. Contact Paul Romaine. I'm happy to acknowledge.
[Home] [Work] [Research & Notes > Libraries > EAD] [Personal]