EAD Application Guidelines for Version 1.0

Appendix A: Minimum Recommended Finding Aid Elements

The EAD elements listed on the next page comprise the minimum elements recommended for creation of a very basic EAD-encoded finding aid. This list includes both the elements required by the EAD DTD for validation (shown in bold type) and additional important structural elements; together these comprise "best practice" for a basic archival description. The list of elements assumes that the archival description begins at the collection, fonds, or series level, but many of the elements listed are applicable at any level of description.

As the brief list of bolded element names reveals, only a handful of elements are required to enable an EAD-encoded finding aid to be validated against the specifications of the DTD. Note, however, that an EAD document consisting only of these elements would barely be a finding aid! The list is extremely brief in part due to reasons related to the SGML rules for writing DTDs, and in part because the EAD developers recognized that many "legacy" finding aids do not contain a full or consistent set of data elements, and they did not wish to eliminate such finding aids' potential for conversion to EAD.

Nesting of elements is shown only where it is required, such as for <titleproper> within <titlestmt> within <filedesc>. The <unitdate> element, on the other hand, is shown outside of <unittitle>, even though it is perfectly valid to encode <unitdate> within <unittitle>.

Only those attributes required for validation (LEVEL on <archdesc> and TYPE on <dsc>) and those representing ISAD(G) equivalencies (LANGMATERIAL and LEGALSTATUS on <archdesc>, COUNTRYCODE and REPOSITORYCODE on <unitid>, LEVEL on <c>) are included in the list. It is recommended, however, that you consistently utilize the ENCODINGANALOG, PARENT, and ID attributes if your system can make effective use of them.

The list also illustrates the required order for the following sections of an encoded finding aid, as dictated by the EAD DTD:

The <eadheader> subelements
The high-level <did> within <archdesc>
The <did> within <c> or <c0x>

In all other cases, the DTD does not specify a particular order of elements. For example, both the <did> subelements and all elements at the same level as the high-level <did> can be encoded in any order (e.g., <scopecontent> can precede <bioghist> and <admininfo>). Keep the needs of your audience in mind when determining a consistent order of elements for your finding aids.

 <ead>
	<eadheader>
		<eadid>
		<filedesc>
			<titlestmt>
				<titleproper>
				<author>
			<publicationstmt>
				<publisher>
				<date>
		<profiledesc>
			<creation>
			<langusage>
				<language>
	<archdesc> with LEVEL, LANGMATERIAL, and LEGALSTATUS attributes
		<did>
			<repository>
				<corpname>
			<origination>
				<persname>, <corpname>, <famname> as appropriate
			<unittitle>
			<unitdate>
			<physdesc>
			<unitid> with COUNTRYCODE and REPOSITORYCODE attributes
			<abstract>
		<admininfo>
			subelements as appropriate
		<bioghist>
		<scopecontent>
		<controlaccess>
			subelements as appropriate
		<dsc> with TYPE attribute
			<c0x> or <c> with LEVEL attribute in as many levels as appropriate
				<did>
					<container>
					<unittitle>
					other subelements as appropriate

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:

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