NCEAD Best Practice Guidelines for EAD Encoding

1. Introduction

The NCEAD Best Practice Guidelines for EAD Encoding provides a guide to the implementation of Encoded Archival Description (EAD) in the multi-institutional NCEAD Project. It is intended to be used as a supplement to the EAD Application Guidelines and Tag Library, in order to further define current best practices for the use of EAD.

Because different institutions have different approaches to archival description, and those approaches have changed and evolved over time, there will be many variations to contend with in a multi-institutional retrospective encoding project utilizing existing finding aids and descriptive information. As stipulated by the design principles of EAD, the DTD itself purposefully supports an extremely wide range of possible practices. As a result, the development of guidelines for an acceptable range of uniform practices agreed upon by all participants in a multi-institutional project is necessary.

As the development of EAD progresses and more institutions implement it as part of their descriptive resources, best practices will continue to develop. At the present it is necessary to consider previous work in developing best practices in order to follow encoding practices compliant with other institutions and union databases.

Whenever working with EAD, XML, SGML, and digital data in general, make a strong effort to ensure uniform and consistent encoding and data structures. Uniform and consistent encoding allows for:

• Easier data manipulation
• Consistency in presentation for users
• Consistency in search results across multiple finding aids
• Ability to utilize shared stylesheets conforming to uniform encoding
• Consistency of structured archival description

2. General Encoding Issues

2.1. Automating the Creation of Finding Aids Using EAD

A good way to standardize encoding is by creating a set of EAD templates and macros and consistently use them during finding aid creation. Because the introductory and high-level descriptive elements of the finding aid are quite regular they lend themselves to automatic processing. Information entered into forms or dialog boxes can be processed into valid EAD markup. By requiring the inclusion of agreed upon information in all fields of these mark-up devices EAD finding aids become more consistant. NCEAD will not prescribe any one set of templates or macros. Each institution will choose the system that works best for them as long as the information and structure outlined in these guidelines is maintained. Sharing and discussing these systems will benefit all.

2.2. Granularity of Encoding

The "granularity of encoding" of a finding aid refers to the amount of effort expended in the application of subject terms, linking, and other elements which, while not necessary for a complete and valid structured EAD document, may be applied to enhance the encoding and searchability.

2.2.1. Subject Tagging

Thorough tagging of subjects within container lists is an important but time-consuming and expensive endeavor. The benefits of tagging to this level of granularity are unclear. NCEAD will strive to tag of each applicable subject term once outside the high-level <controlaccess> section. Each term tagged should be considered integral to understanding the breadth and context of the collection. At a minimum level, subject tagging MUST be used in the high-level <controlaccess> as explained by Section 3.5.5 of these guidelines. These elements include:

More Commonly Used
• <persname>
• <geogname>
• <corpname>
• <famname>
• <subject>
• <genreform>
• <occupation>
• <title>
• <name>

High-level <scopecontent>, <bioghist>, <organization>, <arrangement>, and <odd> may include detailed subject tagging if desired by the participating institution. If an institution wishes to include subject tagging in these high-level elements, such tagging should be done consistently for all encoded finding aids from the institution.

The goal of subject tagging is to assist future searching and indexing of finding aids. It is foreseeable that a search protocol would rank a finding aid higher or more relevant if a subject term were tagged on multiple occasions within a finding aid. Therefore we must be careful to not overstate the signifigance of any particular finding aid. If subject tagging is employed consistently for all finding aids from an institution or institutions, fewer false leads will be encoutered by researchers. At this point, no consensus appears in best practice implementation of subject terms and many guidelines do not even mention this issue outside of <controlaccess>.

2.2.2. Linking Elements

2.2.2.1. Internal Linking

Simple internal links may be made using the <ref> and <id> elements as in the following example:

<scopecontent><p>The <ref target="corr">Correspondence Series</ref> contains...</p></scopecontent>

[...]

<c01><did>
<unittitle id="corr">Correspondence Series, <unitdate type="inclusive">1913-1915</unitdate></unittitle>
</did></c01>

Identifiers in the target and id attributes must be identical. Within each document identifiers must be unique. When possible, convert only the first four characters of the text contained within the <ref> element to lowercase and use these as the attribute content. Otherwise, attempt to only use 4-character references. References may consist of both letters and numbers.

External links may be used to:

• include institutional seals in title pages of finding aids
• include images or other digital archival objects in finding aids
• make links to other resources outside of the finding aid

Insititutional Seals

Institutional seals may be included within <titlepage> by first declaring an entity in the declaration subset of the current document instance. This entity name is then referenced in the <extptr> element to include the contents of the entity file. See sections 3.1 and 3.4 for templates and examples.

Digital Archival Objects

A digital archival object may be included within the finding aid. For most current practical purposes the DAO appears as a thumbnail image embedded within the webpage. To use a DAO, an entity must be declared in the declaration subset of the current document instance. The entity is then referenced from the <dao> element. Descriptive information about the object is typically contained within the <unittitle> and other <did> elements at the level where the <dao> appears. Example of entity declaration and <dao> element:

<!ENTITY TF0021 PUBLIC "-//Duke University::Rare Book, Manuscript, and Special Collections Library//NONSGML (US::NDD::Gedney::TF0021)//EN" "TF0021-small.jpeg" NDATA jpeg>

[...]

<dao entityref="TF0012"></dao>

You may also have the <dao> element refer to an external web page using the "href" attribute.

<dao href="http://scriptorium.lib.duke.edu/">
http://scriptorium.lib.duke.edu/</dao>

The <dao> element is only to be used for materials described by the finding aid and included in the collection but in this case accessed through another web site. Please see the EAD Application Guidelines for more information.

External Links

External links may be created to resources or files outside the finding aid. These may be web pages containing additional information or information that is not part of the materials being described. Use <dao> for linking to materials described by the finding aid and included in the collection.

Example of <extref> using href attribute to make a link to a web page:

2.3. File Naming of Document Instances

2.4. Using Upper and Lower Case Tags

All opening and closing tags and attribute names in EAD 1.0 document instances MUST be in lowercase characters only to ensure XML compliance.

Because XML is case sensitive the tags <EAD> <Ead> <eaD> <ead> are all interpreted as being different tags by an XML-aware system. This is the result of XML being designed to be compatible with Unicode character set specifications. Declarations for elements and attributes in the EAD DTD are specified in lowercase, making it necessary for tags (element and attribute names) in the document instance to be in lowercase as well. Using XML authoring software, macros, and template forms will prevent many mistakes. Attribute values may contain uppercase characters, and should follow the templates in these guidelines.

2.5. Headings

Maintain absolute consistency in headings for sections of finding aids so as not to confuse users or create undue difficulties when creating EAD. For example, a container list heading should always be "Container List" as indicated in the recommended templates, never "Container Listing" or "List of Containers." Exceptions may be made depending on the structure of the finding aid being encoded. The <head> is a a generic element. Information in the <head> element assists readers with identifying major sections of the finding aid but does not provide information that is unique to the collection being described or provide a useful search term. Do not use all UPPERCASE lettering for headings.

<organization>

<head>User's Pathfinder Note</head>

<p>…</p>

</organization>

2.6. Special Characters

2.7. Spacing and Punctuation

Spacing and punctuation in EAD instances are very important. While an EAD instance may be perfectly valid according to the DTD, spacing and other errors may crop up throughout a document, especially surrounding inline elements. Inline tags, such as date and subject, are used to identify smaller segments of text or words in a line of text. Common mistakes include lack of spaces and spaces in the wrong place:

There has been some discussion of the possible implications of this practice on extraction of subject elements from EAD instances for building catalogs and indexes. While it is true that a simplistic extraction of the contents of such element would contain the trailing punctuation and spaces where they are included in the element, it is a trivial issue from a programming standpoint to "clean up" extracted data to remove the trailing punctuation and spaces.

2.8. Titles and Emphasis

2.9. Attribute Values

Always use quotes surrounding attribute values:

2.10. <note> Element

3. Encoding Guidelines

3.1. XML Declaration, DOCTYPE Declaration, and Declaration Subset

Template for the XML Declaration, DOCTYPE Declaration, and Declaration Subset:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<?xml-stylesheet type="text/xsl" href="[nameofstylesheet].xsl"?>

<!DOCTYPE EAD PUBLIC "-//Society of American Archivitsts//DTD ead.dtd (Encoded Archival Description (EAD) Version 1.0)//EN" "ead.dtd" [

<!ENTITY % eadnotat PUBLIC "-//Society of American Archivists//DTD eadnotat.ent (Encoded Archival Description (EAD) Notation Declarations Version 1.0)//EN" "eadnotat.ent">
        %eadnotat;

<!ENTITY [imagename] PUBLIC "-//[NAME OF OWNER]::[SUBORDINATE NAMED DIVISION OF OWNER]//NONSGML ([brief image description])//EN" "[imagename].gif" NDATA gif>

<!ENTITY [entityname] PUBLIC "-//[NAME OF OWNER]::[SUBORDINATE NAMED DIVISION OF OWNER]//TEXT ([brief entity description])//EN" "[entityname].xml">

...other entitities...

]>

(Note that lines should not break within the declarations as they do above)

Discussion

The XML Declaration describes the version of XML and the stylesheet that will be used in rendering the document. The DOCTYPE Declaration identifies the XML document as conforming to the EAD DTD. The Declaration Subset is the information between the open and close brackets [ ]. The Declaration Subset contains declarations of entities or elements that are made in addition to those found in the DTD. Because they are declared in the individual document instance, they may be referenced only in that instance, and likewise must be declared in each instance.

3.2. Overview of High-Level Components:

<ead>

<eadheader>Describes the finding aid and EAD file itself. (not displayed)

<frontmatter>Information about the finding aid, including electronic title page. (displayed)

<archdesc>The description of the materials in the archival collection.

3.3. EAD Header

Possible template for <eadheader>:

<eadheader audience="internal" findaidstatus="unverified-full-draft" langencoding="ISO 639-2">

<!-- One possible eadid -->

<eadid type="SGML catalog">PUBLIC "-//[NAME OF OWNER]::[SUBORDINANT DIVISION]//TEXT (US::[NUC ID]::[LOCAL REFERENCE CODE]::[TITLE OF COLLECTION: John Doe Papers, yyyy-yyyy])//EN" "[FILENAME].xml"</eadid>

<filedesc>

<titlestmt>

<titleproper>Inventory of the [title of collection: John Doe Papers], <date>[inclusive dates of collection: yyyy-yyyy]</date></titleproper>

<author>Processed by: [person(s) who processed the collection]; machine-readable finding aid created by: [person marking up finding aid]</author></titlestmt>

<publicationstmt>

[entity containing name and address: &hdr-[NUC]-[name];]

<!-- Copyright Information Not Required -->

<p><date>&#x00A9; [yyyy]</date> [Copyright holder]. All Rights Reserved.</p></publicationstmt></filedesc>

<profiledesc>

<creation>Machine-readable finding aid derived from

[paper by means of scanning and OCR; OCR file edited for typographical errors before encoding.] [[application name] text editing software.] [typescript by rekeying.] [database name.] [automated markup system.]

<lb/>Date of source: [date of processing completion: month dd, yyyy]

<lb/>Processed by [person who processed the collection] [date of processing completion: month dd, yyyy]; Finding Aid encoded by [person marking up finding aid], [repository], <date>[date of markup: month dd, yyyy]</date></creation>

<langusage>Description is in <language>English.</language>

</langusage>

</profiledesc>

</eadheader>

Discussion

All elements listed in the template should be considered to be required unless otherwise noted, and all data be included even if it is a placeholder. For instance, if the name of the processor is not known, "Library Staff" would be an appropriate placeholder.

3.4. Frontmatter

Template for <frontmatter>:

<frontmatter>

<titlepage>

<titleproper>Inventory of the [title of collection: John Doe Papers], <date>[inclusive dates of collection: yyyy-yyyy]</date></titleproper>

<publisher>[repository name][subordinate division]

<lb/>

<extptr show="embed" entityref="[entityname]"/>

<lb/>[institution]

<lb/>[city, state, zip, USA]</publisher>

&tp-[NUC ID]-[name];

<list>

<defitem>

<label>Processed by </label>

<item>[person who processed the collection]</item></defitem>

<defitem>

<label>Date Completed </label>

<item><date>[date of processing completion: month dd, yyyy]</date></item></defitem>

<defitem>

<label>Encoded by </label>

<item>[person marking up finding aid]</item></defitem></list>

<!--copyright inclusion is optional-->

<p>&copy; [yyyy] [repository]. All rights reserved.</p>

</titlepage>

</frontmatter>

Discussion

• The title of the collection should be preceded by one of the following and should be the same as the one used earlier in the <eadheader> section:
• Inventory of the
• Preliminary Inventory of the
• Guide to the
• Register of the

"Inventory of the" may be used as a default.

Note that the <titleproper> element provides a title for the finding aid rather than the collection proper. Because <frontmatter> occurs before the <archdesc> we are not yet describing the archival collection, but rather the finding aid itself and XML file that contains it.

• The title of the collection should be devised according to APPM rules, and should contain the name first and type of material last. This will eliminate confusion about the meaning of the dates following the collection title. For example:

John Q. Doe Papers, 1932-1986

Rather than:

Papers of John Q. Doe, 1932-1986

Notice potential confusion between dates of the collection materials and birth and death dates. This may require the revision of existing collection names.

• Always use standardized forms for dates, typically yyyy-yyyy at this level, with "n.d." representing no date.


• A bulk date may also be included in the titleproper in addition to the inclusive dates. This will be placed in a separate <date> tag.

3.5. Archdesc

<archdesc level="collection" langmaterial="eng">

[ ... ]

</archdesc>

The <archdesc> element contains the archival description proper. It contains all information related to the collection being described, whereas elements leading up to <archdesc> describe the finding aid document itself.

The level attribute of <archdesc> is required and represents the highest level of description contained within the finding aid. Although the default is "collection," other possibilities are: series, file, fonds, item, otherlevel, recordgrp, subgrp, and subseries.

3.5.1. Did

Template for <did>:

<did>

<head>Descriptive Summary</head>

<unittitle label="Title">[title of collection: John Doe Papers],

<unitdate type="inclusive">[inclusive dates of collection: yyyy-yyyy]</unitdate></unittitle>

<unitid>[Collection number]</unitid>

<origination label="Creator"><persname>[authority name of creator]</persname></origination>

<!-- Do not include langmaterial until the next version of EAD DTD is released -->
<langmaterial>Language the Finding Aid is written in</langmaterial>

<physdesc label="Extent">

<extent>[number of linear feet] Linear Feet</extent>

<extent>[number of items] Items</extent></physdesc>

<repository label="Repository">

<corpname>[Repository]</corpname></repository>

<physloc label="Location">Contact reference services for access to these materials.</physloc>

<abstract label="Abstract">[Abstract]</abstract>

</did>

Discussion

The <did> is one of the most important elements in EAD because it groups together key descriptive information about the collection or unit that is being described. At the highest level, located directly within the <archdesc> and often called the "high-level <did>," the <did> contains several elements, indicated in the template, which are considered to be required for adequate archival description. These elements should always be included, and placeholder text inserted if information does not exist or is not to be shared. For retrospective conversion, it may be necessary to consult additional sources of information such as MARC records.

• The title and dates of the collection should appear exactly as they appear in the <titleproper> and <date> elements encoded earlier. Note that label attribute values of elements occurring in the <did> are capitalized to ensure proper display with typical stylesheets.

<unitid countrycode="US" repositorycode="[NUC code]" label="Collection Number">[Consult Repository]</unitid>

• The <unitid> element contains the code or number that uniquely identifies the collection, and through attributes indicates the country and institution at which it is held. A default value of "Consult Repository" may be used. This is new to NCEAD but it is prescribed by both the Online Archive of California and Virginia Heritage Project consortia.

• The name of the creator of the collection, if known, should be entered in authority form. Close adherence to APPM and AACR2 rules for generating authority name forms is recommended. Note that the <persname> element used in the template will need to change to <corpname> as necessary.

--IN 2002--<langmaterial>[to be determined]</langmaterial>

• This element is new in the forthcoming EAD DTD update due out in early 2002. Forseeably it will require an attribute indicating the language. When the new version is released, this element will be required for NCEAD finding aids and is included in the update in response to the internationalization of EAD. This tag will represent the languages present in the materials not the language the finding aid was written in.

• Items within the <extent> tag may be altered as necessary - for example, "Cubic Feet" rather than "linear feet" may be required or number of items eliminated. Always attempt to find this information, use "Unknown" as a placeholder only after all avenues have been eliminated. Each unit of measure should be separately enclosed within its own <extent> element. The additional elements <dimensions>, <physfacet>, and <genreform> are also available for further description of the nature of the materials within the collection. Please see section 3.5.6.4. for more discussion of the <physdesc> element.

• The placeholder text within the <physloc> element serves to instruct users how to access the physical location. Although this element was designed to hold a shelf location for the collection being described, because such information is continually changing as repositories manage their collections, a better long-term solution is to maintain this information separartely. This eliminates the need to continually update the finding aids, or to have to update the shelf locations in both MARC records and finding aids. This might be an ideal location for an entity reference indicating how to contact research services and other information.

• The <abstract> element is new to EAD 1.0 and is a highly reccomended element for new finding aids. The <abstract> provides researchers with a pithy overview of a collection summarizing the primary information of the <scopecontent> and <bioghist> elements, thus enabling a researcher to determine relevance. Most of the <abstract> can be written by lifting phrases from these two other elements. Unfortunately, for retrospectively converted finding aids an existing abstract may be hard to locate. Descriptive notes from the MARC record may be used if available, or the <abstract> element may not be included at all. If no text is available simply do not include <abstract> and do not provide placeholder text as with the other <did> elements.

3.5.2. Admininfo

This section of the <dsc> will undergo substantial changes when the new version of the EAD DTD is released. See below.

Template for <admininfo>

<admininfo>

<head>Administrative Information</head>

<accessrestrict>

<head>Access Restrictions</head>

<p>[restrictions]</p></accessrestrict>

<userestrict>

<head>Usage Restrictions</head>

<p>[copyright notice]</p></userestrict>

<!-- Note: "[Identification of item]" will always appear in brackets -->

<prefercite><head>Preferred Citation</head><p>[Identification of item], [title of collection: John Doe Papers], [institution].</p></prefercite>

<acqinfo>

<head>Acquisition Information</head>

<p>[gift, purchase, etc.] </p></acqinfo>

<processinfo>

<head>Processing Information</head>

<p>Processed by [person who processed the collection]</p>

<p>Completed [date of processing completion: month dd, yyyy]</p></processinfo></admininfo>

Discussion

All elements in the <admininfo> will be unbundled in the next version of the EAD DTD due out in early 2002. This section will have to be changed to reflect the update. It would be best to have this conversion in place as soon as the DTD is released to avoid any more retrospective conversions of finding aids. EAD 1.0 will be supported for the forseeable future but legacy data conforming to EAD 1.0 may not be worth maintaining if it can be converted easily. This section will change substantially when the new release is available.

The <admininfo> element is another important required element within <archdesc>. It provides administrative information about the collection helpful to both users who wish access to the collection and to archivists in managing the collection. Items included in the template should be considered to be required. Other available elements within <admininfo> may be added as needed, provided care is taken to ensure that they are applied consistently. Default language should be created wherever possible for headers, information, and restrictions contained within <admininfo> elements, although the uniqueness of many collections will defy these attempts.

• Physical access to the collection may be restricted due to privacy concerns, conservation issues, or other factors. See the EAD Tag Library for <accessrestrict> definition. If there are no restrictions use "Collection is open for research." as default text.

• Copyright information or other usage restrictions affect how the materials may be used after physical access has been granted. See the EAD Tag Library for <userestrict> definition. Here is an example of basic default text often used in Duke's collections:

The copyright interests in the Edgar Hatcher Papers have not been transferred to Duke University. For further information, see the section on copyright in the Regulations and Procedures of the Rare Book, Manuscript and Special Collections Library or consult a reference archivist.

• Depending upon the collection, a shorter or longer notice may be necessary. Additional paragraphs may be added to the <userestrict> element as needed.

• This default structure for <prefercite> may be changed to suit individual repositories or collections as needed.

<acqinfo>

• This element is used for information about how the current repository obtained possession and/or rights to the collection. If this information is not known use "unknown" as default text. If this information can not be disclosed use "Check Repository" as default text.



• Information associated with provenance (transactions of the information prior to the current institutions) should be used with the <custodhist> tag. See the EAD Tag Guidleines for more information.

• This area is used for description of noteworthy items that affected the processing of the collection.
• Paragraphs may be added as needed within <processinfo>.
• Information about the processor and processing dates may be included here as well as in <frontmatter>.
• If a legacy finding aid contains a long description of how the collection was processed, this is the place for that information to reside.

3.5.3. Bioghist

Template for <bioghist>

<bioghist>

<head>Biographical Note</head>

<chronlist>

<chronitem><date>[yyyy]</date>

<event>[event]</event></chronitem>

<chronitem><date>[yyyy]</date>

<event>[event]</event></chronitem>

<chronitem><date>[yyyy]</date>

<event>[event]</event></chronitem></chronlist>

<p>[Biographical/historical note paragraph describing the creator of the collection.]</p>

<p>[Biographical/historical note paragraph describing the creator of the collection.]</p>

</bioghist>

Discussion

3.5.4. Scopecontent, Arrangement, Organization, and ODD

Template for <scopecontent>

<scopecontent>

<head>Collection Overview</head>

<p>[Scope and Content Note paragraph describing the collection]</p>

<p>[Scope and Content Note paragraph describing the collection]</p>

</scopecontent>

3.5.5. Controlaccess

Template for <controlaccess>

<controlaccess>

<head>Online Catalog Headings</head>

<p>[Boilerplate Text: These and related materials may be found under these subject headings in online catalogs.]</p>

<list type="simple">

<item>[subject term]--[subdivision]</item>

<item>[subject term]--[subdivision]</item>

<item>[subject term]--[subdivision]</item>

<item>[subject term]--[subdivision]</item>

<item>[subject term]--[subdivision]</item>

<item>[subject term]--[subdivision]</item>

</list></controlaccess>

Discussion

The basic collection-level <controlaccess> element contains a list of subject terms and is required for adequate collection-level description. These should be identical to the MARC record for the collection. Some legacy finding aids contain a list of subject terms which should also be included in this section.

Each subject term within <item> elements will be further surrounded by one of the elements listed below:

• <subject>
• <persname>
• <corpname>
• <geogname>
• <famname>
• <genreform>
• <occupation>
• <title>
• <name>
• <function>

See the EAD Tag Library for definitions of these elements.

Encodinganalog and source attributes may be used if desired to map these elements to their corresponding fields in MARC format:

<corpname encodinganalog="610" source="lcnaf">Board of Game and Fish Commissioners of Minnesota.</corpname>

<subject encodinganalog="610" source ="lcsh">Law enforcement.</subject>

Separate subdivisions with two short dashes or hyphens (with no spaces) as in the example.

Enclose the entire subject and subdivision within a single element rather than attempting to mark each subdivision individually. For example:

<subject>Education--United States.</subject>

is correct, rather than:

<subject>Education</subject>--<geogname>United States.</geogname>

3.5.6.1. Components

The basic required element within each component <c0x> is <did> with <unittitle> within. For example:

<c02><did>

<unittitle>[collection content]</unittitle>

</did></c02>

Because of the hierarchical nature of EAD, all elements within <did> are also available at this level in addition to such elements as <scopecontent>, <admininfo>, <arrangement>, <organization>, etc. See below for discussion of the use of these elements.

Component Levels

The highest level components should be identified with "series" attributes when what is being described is a true series, usually occurring with the word "Series" in the title, i.e. "Correspondence Series." In this case, set the level attribute for the <c01> to "series." In the case of a box listing without hierarchy in which materials are not arranged into series, <c01> elements are used without the attribute. For example:

<dsc type="in-depth">

<head>Container List</head>

<c01><did><unittitle>Office Files</unittitle>

</did></c01>

<c01><did><unittitle>Correspondence</unittitle>

</did></c01>

</dsc>

The <c02> element is often used without its level attribute set to "subseries." Like <c01> it is normally only set if the component being described contains the word "subseries" or is easily discerned as a subseries. It is a common occurrence to find a long list of components on the <c02> level which are not subseries.

In summary, <c01> is not always a series and <c02> is not always a subseries; they are both simply components of description. It is common to have a finding aid with some <c02 level="subseries"> (or even <c02 level="series"> in the case of additions. See Section 4.2.) used where appropriate while <c02> without an attribute is used in other areas of the finding aid.

Repositories that number component levels should include the numbers in the <unittitle> element:

<c01><did>

<unittitle>1. Correspondence</unittitle></did>

<c02><did><unittitle>1.1. Early, 1966</unittitle></did></c02>

</c01>

3.5.6.3. Unitdates and Unittitles in Components

It is important that every described <c0x> level include a <unittitle> element. The unittitle is what describes the component level and more broadly describes all components nested within. A component without a unittitle should be carefully evaluated to discover what purpose it serves before including it in the EAD encoding.

• For titles of components which consist of dates only, for instance:

  Correspondence

  1956

  1957-1958

  Always place the date within a <unittitle>, as the date constitutes the title of the unit as well as a date:

  <unittitle>

  <unitdate type="inclusive">1956</unitdate>

  </unittitle>

• Set the type attribute of <unitdate> to "inclusive" by default, and to "bulk" or "single" as needed. Usually, inclusive is considered appropriate even for single years, since it is assumed that the date includes materials from different times throughout the entire year. The only time "single" should be used is in the case of a date such as "1999 March 31" or, in the case of serials, a year and month "March, 1999" which normally will only occur at the item level and are thus infrequent.



• Unless it is unnatural to do so, always include the <unitdate> within the <unittitle>.



• A bulk <unitdate> element can be used in conjunction with an inclusive to further specify preponderance of materials.

  <unittitle>Correspondence, <unitdate type="inclusive">(1956-1965), </unitdate><unitdate type="bulk">1961-1962</unitdate></unittitle>

3.5.6.5. Scopecontent, Organization, Arrangement in Components

In "analyticover" and "combined" type <dsc>s the <scopecontent> element will be frequently used. This tag is used outside of the <did> tag for narrative information limited to the component level it appears in.

<c01 level="series">

<did>

<container type="box">1</container>

<unittitle>[series], <unitdate type="inclusive">[yyyy-yyyy]</unitdate></unittitle>

</did>

<scopecontent><p>[scope and content note about this series]</p></scopecontent>

</c01>

<arrangement> and <organization> may also be used as needed, however if a descriptive narrative blends such information with a scope and content, use <scopecontent> only. If such a narrative blends scope and content, biographical, arrangement, and/or organization information use <odd>.

For short scope and content notes in an "in-depth" type <dsc> and "combined" <dsc>s, you may avoid the use of <scopecontent> by simply encoding the description as part of the <unittitle>. This was developed as a standard practice in the American Heritage Project. For example:

Correspondence, 1989

Includes notes and clippings

EAD encoding:

<c02><did>

<unittitle>Correspondence, <unitdate>1989</unitdate> Includes notes and clippings</unittitle>

</did></c02>

3.5.6.6. Admininfo in Components

This section will change substantially when the new version of EAD is released early in 2002. Primarily, elements such as <accessrestrict> once bundled within <admininfo> will now be available directly through the <c0x>.

<admininfo> is also available in components. This is most often used when a series, subseries, folder, or other level component is restricted, but may also be used as needed for other administrative information such as preservation concerns. Example:

<c01 level="series">

<did>

<container type="box">1</container>

<unittitle>[series], <unitdate type="inclusive">[yyyy-yyyy]</unitdate></unittitle>

</did>

<admininfo>

<accessrestrict>Restricted</accessrestrict>

</admininfo>

</c01>

3.5.6.7. <head> Elements in Components

Do not use the <head> element for <c0x> elements. <head> elements usually repeat the contents of <unittitle> and thus should not be included.

4. Additional Issues

4.1. Oversize Materials

The inclusion of an Oversize Materials listing is one method of describing materials associated by provenance to a collection but because of abnormal size or format they are not able to be stored with the rest of the collection. These oversized materials may be described in a separate section of the finding aid which appears at the end of the container list. (Conversely this may also be done as an <add><separatedmaterial> (See section 3.5.7.), or not encoded at all.)

Encode oversize materials as a series with the title "Oversize Materials" as a <c01> component as if it were another series in the collection. When the series from which oversize materials are drawn are listed, they will fall at the <c02> level as in the example below. Since these items are separated from the rest of the collection that detailed container information be included.

Example:

<c01 level="series"><did><unittitle>Oversize Materials</unittitle></did>

<c02 level="subseries"><did><unittitle>Advertisements Series</unittitle></did>

<c03><did><container type="box">Hartman Center Ovsz. Box 1 (20x24)</container>

<unittitle><corpname>Beechcraft (McCann-Erickson), </corpname><unitdate type="inclusive">

1983-1987</unitdate></unittitle></did></c03>

[...]

View the finding aid containing this example at:

4.2. Later Accessions and Additions

A challenge frequently faced by encoders is that of highly active collections to which there are many additions over a period of time. Often these are the result of living donors who donate parts of their collections over time, resulting in a series of several accessions at the repository. Other times they are archival collections with records management schedules which dictate periodic additions. Each addition to a collection necessitates a review to discover whether this acquisition establishes a new collection or is added to the end of the exisisting collection. In the former case, the effect on EAD encoding is simply to create another finding aid, since a new body of materials is being described. For the latter situation, the information about the new edition must be added to an existing finding aid. These additions to finding aids will be added as a <c0x> element creating an artificial series at the end of the document. Adding an artificial series is preferable to encoding the addition as a new <dsc>. Although there are situations where multiple <dsc>s are allowed, in these cases each of the <dsc>s are describing the same body of materials in different ways or to different levels.

In addition to adding the accession description to the end of the finding aid, the new accession will usually mandate changes to collection level description in the <archdesc> to include the content and context of the new accession. Additionally, the <revisiondesc> tag in the <eadheader> should be used to retain information about changes to the finding aid.

The heading "Accession [number]" is used as the <unittitle> on the <c01> level, with the series making up the accession falling at the <c02> level. The <unitid> element is used to further distinguish this accession from previous or subsequent accessions.

Example:

<c01 level="series">

<did>

<unitid>2001-0022</unitid>

<unittitle>Accession 2001-0022</unittitle>

</did>

<scopecontent>

<p>This accession includes correspondence files; author files; galley proofs of books; sales and marketing files, including journals in which advertisements or reviews of Sarabande Books'</p>

</scopecontent>

<c02>

<did>

<container type="box">1</container>

<unittitle>Nonprofit Files, <unitdate>1997</unitdate></unittitle>

</did>

<c03>

<did>

<unittitle>Board Meeting</unittitle>

</did>

</c03>

<c03>

<did>

<unittitle>Nonprofit Activity</unittitle>

</did>

</c03>

The finding aid from which this example is drawn may be found at:

References and Resources

Dooley, Jackie, ed. Encoded Archival Description Part 1 - Context and Theory. American Archivist V. 60 number 3 Summer 1997

Dooley, Jackie, ed. Encoded Archival Description Part 2 - Case Studies. American Archivist V. 60 number 4 Fall 1997