NCEAD is a consortium supported by NC ECHO, the World Wide Web doorway to the special collections of North Carolina's libraries, archives, museums, and historic sites. The NC ECHO project is supported by the Institute of Museum of Library Services under the provisions of the federal Library Services and Technology Act (LSTA), as administered by the State Library of North Carolina, a division of the Department of Cultural Resources. This innovative and collaborative project seeks to build a statewide framework for digitization in order to facilitate deep, wide, and comprehensive access to the holdings North Carolina's cultural institutions, NC ECHO is co-sponsored by Duke University Libraries and the State Library of North Carolina. Questions and comments may be directed to the NC ECHO staff, ncecho@ncmail.net

Introduction

The NCEAD Best Practice Guidelines EAD 2002 provides a guide to the implementation of Encoded Archival Description (EAD 2002) in the NC ECHO consortium. 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 in North Carolina.

This edition includes references to the Society of American Archivists' Describing Archives: A Content Standard (DACS) as well as other new secitions to the encoding guidelines. It supersedes the January 2004 edition of the NCEAD Best Practice Guidelines EAD 2002.

About NCEAD

NCEAD began as a collaborative Encoded Archival Description (EAD) project funded in part by the Gladys Krieble Delmas Foundation. Initial project participants included Duke University, University of North Carolina at Chapel Hill, North Carolina State University, and the North Carolina State Archives. The overall goals of the project were to develop best practices for encoding based on a representative sample of finding aids from the participating institutions, develop tools for effective encoding of finding aids, and explore technologies for indexing and display of XML finding aids.

In 2002, NCEAD became part of NC Exploring Cultural Heritage Online (NC ECHO, http://www.ncecho.org/). Membership expanded to include all interested institutions in North Carolina. Representatives from eastern, western, and central regions participate in various capacities in NCEAD, and the consortium is currently facilitated by the NC ECHO Metadata Coordinator.

The revision process to EAD 2002

The Standards Working Group reviewed the January 2004 edition of the Best Practice Guidelines. In anticipation of the publication of Describing Archives: A Content Standard (DACS), NC ECHO 2004 summer intern Peter Hymas reviewed the Best Practice Guidelines to reconcile the new descriptive standard with NCEAD's implementation of EAD. This work forms the primary impetus for this new edition. It was considered imperative that the standard and the Guidelines be reviewed to assure compliance. The Stnadards Working Group seeks to maintain currency and clarity with the Best Practice Guidelines. As a result, DACS rules and page numbers are referred to extensively throughout the encoding guidelines below. These Guidelines should be considered DACS compliant.

In addition, the Standards Working Group reviewed the Best Practice Guidelines in light of a full year of encoding experience. As with all standards, guidelines for implementaton must be reviewed on a regular basis to assure their consistency with application. The Standards Working Group has made several small revisions to ensure the robust and widespread implementation of EAD in North Carolina. A complete list of changes made to the NCEAD template and tools is available at http://www.ncecho.org/ncead/documents/tools2005.htm.

The current Standards Working Group members include:

• Ruth Bryan, Rare Book, Manuscripts, and Special Collections Library, Duke University
• Jackie Dean, NC ECHO, State Library of North Carolina
• Valerie Gillispie, Special Collections Department, North Carolina State University Libraries
• Lynn Holdzkom, Manuscripts Department, Wilson Library, University of North Carolina at Chapel Hill
• Peter Hymas, Manuscripts Department, Wilson Library, University of North Carolina at Chapel Hill
• Jill Katte, University Archives, Duke University
• Kathy Wisser, Rare Book, Manuscript, and Special Collections Library, Duke University, NC ECHO Metadata Coordinator

This document would not have been possible without the solid foundation established in the first four year of NCEAD and the thoughtful input of the Standards Working Group members. Questions and comments about the guidelines and template in this document should be addressed to Kathy Wisser, NC ECHO Metadata Coordinator (kwisser@unc.edu).

About DACS

It is strongly recommended that institutions creating EAD finding aids familiarize themselves with the content standard, Describing Archives: a Content Standard (DACS), published by the Society of American Archivists. Not only has the NCEAD template and guidelines been updated for DACS compliance, the use of the <descrule> element in the template states that the finding aid is written in accordance with DACS. These guidelines do not attempt to cover material that forms the core of DACS but to provide an introduction to the content standard and to point out some areas in which DACS will impact how you write finding aids.

DACS is structured to facilitate description for archival collections. While platform-neutral, it includes examples of descriptive elements in both EAD and MARC, with an appendix of full examples of each at the end. The descriptive elements included are:

• Identity
• Content and Structure
• Conditions of Access and Use
• Acquisition and Appraisal
• Related Materials
• Notes
• Description Control

In addition, DACS provides detailed information on levels of description and the description of creators. The Forms of Names portion of the standard complements and extends those chapters in Anglo-American Cataloging Rules 2nd ed. Revised that form the standard for the creation of name authority files used in the controlled vocabulary LCNAF. Appendices include a glossary, companion standards, and crosswalks.

Some DACS information that may impact how you write finding aids:

• DACS prescribes the use of "undated" for material that does not have a date (see rule 2.4.16, p. 28).
• DACS discourages the use of abbreviations in description.
• DACS discourages the use of square brackets to communicate description. A legacy system from Anglo-American Cataloging Rules, the use of square brackets has in general been abandoned by archivists when creating finding aids. The explicit direction to not use square brackets in MARC catalog records promotes a closer parallel between EAD and MARC coding. This will not affect your EAD document, but should positively affect your MARC records.

About this document

The inclusion of DACS references throughout the template has not dramatically changed the structure of this document. Some aspects of the best practice guidelines have remained the same, others have been revised, and new sections have been added to meet the needs of the growing NCEAD community. This document is meant to represent the best practice for the implementation of EAD in North Carolina in order to assure consistency across instituitons as well as to provide a starting point for documentation within an individual institution. These guidelines are in no way meant to be the only documentaton an individual institution will need to consult. NCEAD community members are strongly encouraged to familiarize themselves with DACS. Where appropriate, relevant rule numbers and page numbers have been indicated, but the rules themselves are not repeated in this document. Every effort has been made to accurately match the appropriate content standard rule with encoding guidelines. Currently, there is no online version of DACS so hypertext links to rules cannot be made at this time.

In addition, institutions will be required to examine the EAD Tag Library Version 2002 and other resources available on the implementation of EAD. There are several aspects of the NCEAD template that may compel individual institutions to examine their arrangement and description procedures. While this document provides guidelines to the kinds of decision-making processes that need to take place for EAD implementation, it in no way assumes that there are single answers to those questions. There are a number of supporting documents that provide detailed informaitona bout certain aspects of an EAD program. IN order to streamline and produce effective Best Practice Guidelines, these documents are cited, but not reproduced here. One such document, entitle "Examples Accompanying the NCEAD Best Practice Guidelines EAD 2002" is intended as a series of encoded finding aids that will demonstrate various interpretations of NCEAD's encoding guidelines with accompanying discussion. It is hoped that this document will be dynamic as participating instiutitons contribute newly encoded interesting case studies to share with the NCEAD community. The examples documents is forthcoming.

Back to Contents

General Encoding Issues

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 to use them consistently 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 consistent within institutions. NCEAD does not prescribe any one set of templates or macros. Each institution should choose the system that works best for it as long as the information and structure outlined in these guidelines is maintained. Sharing and discussing these systems benefits all.

Tools created by NCEAD and made available through the NCEAD website are consistent with the encoding practices outlined in this document. These tools however require some customization for individual institutional implementation. Guidelines for customizing the tools are available on the Tools webpage (http://www.ncecho.org/ncead/tools/tools_home.htm) along with the tools themselves. Institutions wishing to contribute forms, dialog boxes or other tools for sharing should contact Kathy Wisser, the NC ECHO Metadata Coordinator (kwisser@unc.edu).

XSL Stylesheets

XML encoding relies upon external stylesheets to render the documents in a web browser. These stylesheets are written in eXtensible Stylesheet Language (XSL). XML and XSL are inter-dependent: the former focuses on content, while the latter focuses on display. Although a few EAD tags (<emph> and <title> discussed below) directly affect display in a browser through an attribute, most elements in EAD are independent of display and rely on definitions in a corresponding XSL file for rendering in a browser. Because of this relationship, all elements used in an EAD document that have display specifications must be defined in the corresponding XSL document.

The NCEAD toolkit includes a simple XSL stylesheet solution created for individual institutional customization. Directions on customizing and downloading this stylesheet package are available at http://www.ncecho.org/ncead/tools/tools_home.htm. Information on the stylesheet itself and related XSL information can be found on that page and within the stylesheets themselves. NCEAD welcomes the addition of other stylesheets from contributing members. Please contact Kathy Wisser, NC ECHO Metadata Coordinator (kwisser@unc.edu).

File naming of document instances

As the number of finding aids grows, it is important that each institution maintain a system for creating a unique name for their EAD XML instances. It is recommended that file names be made up of letters and numbers only with no blank spaces or special characters. They must include .xml as the suffix. There are a variety of valid systems for creating filenames although using collection names and/or numbers is considered good practice. Consistent file naming for your EAD instances will provide much needed structure to increasing numbers of XML documents and will allow you to quickly navigate through your files.

XML Syntax

Because it was designed to be an unambiguous structure, XML is case sensitive. Thus all element and attribute names MUST be in lowercase characters as this assures XML compliance to the document type defintion. 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 guard against making errors in character case. Attribute values may contain uppercase characters and should follow the recommended templates in these guidelines.

NMTokens

One of the most dramatic changes to the dtd in EAD 2002 was the move from semi-closed lists and the implementation of NMTokens for many attributes (see Appendix B. NMTokens consist of an undefined attribute value list. For each applicable element, EAD 2002 allows for the option of restricting an attribute value list in a separate file. These defined values would be confirmed during the parsing process of an individual EAD instance.

NCEAD has chosen to exercise this option for the source attribute and the type attribute for <container> and has provided an altered eadlocal.ent file for institutions. Because it is necessary to "turn on" the option in the EAD dtd, both of these files should be downloaded at http://www.ncecho.org/ncead/tools/tools_home.htm. These files are included in the toolkit.zip file, but are also available separately on that page. Update information is maintained to assure that you have the most current version. Note that both the ead.dtd and the eadlocal.ent files should be maintained in the /dtds/ folder of your directory in order to avoid processing errors. See Appendix E for more information on file management practices and principles. Appendix B provides information on the attributes defined by NCEAD in the eadlocal.ent file.

While NCEAD has left most NMToken attributes undefined through this option, individual institutions may be interested in further restricting attribute values for other elements where it will benefit them for consistent encoding or in software operation. Appendix B provides an example for further customizing the eadlocal.ent file for your institution.

Headings

It is important to maintain absolute consistency in headings for sections of finding aids to avoid confusing users or creating undue difficulties in EAD creation. 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, but these exceptions should be well-documented for consistent application. The <head> is a generic element. Information in the <head> element assists readers in 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. For headings, mixed case lettering is recommended rather than all UPPERCASE.

In general, a heading should look like this:

<scopecontent>
<head>Collection Overview<head>
<p>…</p>
</scopecontent>

Special characters

Special characters are frequently found in EAD-encoded XML documents, especially for finding aids with significant non-English content. EAD recognize either ISO 8879 character references or Unicode Hexadecimal References. As seen below Unicode hexadecimals are not nearly as intuitive as ISO 8879. See the EAD application guidelines section 6.5.2.1 for further discussion of special character entities in EAD.

For a list of commonly used special characters and their ISO 8879 and Unicode hexadecimal equivalents visit http://www.ncecho.org/ncead/documents/unicode.htm.

Whether using ISO 8879 or Unicode Hexadecimal References all entities should be checked for proper display. This is not always an easy task. Popular web browsers support special character display differently from each other and from different versions of the same software. Unicode Hexadecimal References appear to be the developing standard for XML and these guidelines encourage their use, although for the purposes of proper display, ISO 8879 references are an alternative. As noted above, there may be a need for retrospective conversion at a later date.

While many characters may be represented with ISO or Unicode entities, it is not worthwhile to utilize them for common ASCII characters such as punctuation, hyphens, quotes, or parenthesis. Instead, focus should be placed on providing correct representation of alphabetic characters and diacritics for English and other languages. Exceptions to this include a few special characters that are used in XML syntax. These require the special character equivalent because of the special role they play in XML.

Other character entities should be used based upon testing in browsers and internal institutional decisions.

Spacing and punctuation

While an EAD instance may be perfectly valid according to the DTD, spacing and other errors may emerge when a document is rendered in a browser. The process of encoding an individual line of text using inline tags, such as date and subject, to identify smaller segments of text or words in a line of text is particularly susceptible to these kinds of errors. Common mistakes include lack of spaces or spaces in the wrong place:

Correspondence1934

Bill T. Jones , 1899-1976

The EAD Application Guidelines addresses the issues surrounding spacing and punctuation in sections 4.3.5.1 and 4.3.5.2. Here is a summary of suggestions:

• Single spaces should be used to divide words and sentences.
• Using two or more spaces together for display purposes is not advised and often unsuccessful. Consider stylesheets for implementing these affects.
• Tags do not replace the need for spaces.
• Keep spaces outside of inline tags (content tags, <emph>, <unitdate>, etc.).
• Include punctuation within inline tags in accordance with applicable writing style rules.
• Maintain elements such as the <unittitle> and inline elements on a single line within the markup. Natural word-wrapping by software applications for single screen display is fine.
• See below for special consideration of the <emph> and <title> tags.

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 remove these extra characters.

The render attribute

The <title> and <emph> tags use the render attribute to specify the appearance of PCDATA when transformed by a stylesheet. The render attribute includes such values as doublequoted, bold, italics, underline, etc. Here is an example of an italicized title:

<title render="italic">Darkness Visible</title>

Some suggestions:

• Use the "doublequote" attribute as required for title requiring quotation marks. Do not use ISO 8879 or Unicode Hexadecimal References for quotation marks.
• A full list of render attribute values appears under the <title> element in the EAD Tag Library.
• The XSLT Stylesheet controls the display of these formatting attributes. If no attribute is specified no formatting will result.
• Subject elements such as <persname>, <geogname>, etc., may NOT be utilized within <title> or <emph> elements. <date> may occur within <title>.

It is important to be careful with spacing and punctuation with the <title> AND <emph> tags especially when using "doublequote" or "underline" render attribute values. Be sure that the closing tag immediately follows all affected text. Otherwise quotation marks or underlines may extend beyond the intended characters and may not conform to standard English practices.

Correct:

Which displays as: The poem, "Trees," which was written...

Incorrect:

Which displays as: The poem, "Trees, "which was written...

Incorrect:

Which displays as: The poem, "Trees", which was written...

The <note> element

NCEAD considers the <> element too vague for good description of contextual information about the collection. Information within <note> tags may be useful for specific purposes, but will generally not be useful for advanced searching. There may be times when <note> is appropriate, but more suitable tags are often discovered through a careful review of the EAD Tag Library (http://www.loc.gov/ead/tglib/index.html) and/or consultation with colleagues. NCEAD considers <note> an element of last resort.

Date normalization and ISO 8601

Date normalization refers to the application of the normal attribute for <unitdate> and <date> elements to provide a machine-readable format for date information. While the normal attribute is available for any <date> or <unitdate> element throughout the EAD instance, NCEAD requires the use of this attribute for <date> elements in the <eadheader> and <unitdate> elements at the collection and <c01> levels only in the <archdesc>.

Date format:

For other available attributes or how to express more complicated dates in ISO 8601, please see Appendix F.

Encoding granularity and content tagging

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 EAD document, may be applied to enhance searchability.

Thorough tagging of content within container lists is an important but time-consuming and expensive endeavor. The benefits of tagging to this level of granularity are unclear. NCEAD recommends tagging each applicable content term once that does not occur in 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, content tagging MUST be used in the high-level <controlaccess> as explained in the encoding guidelines below.

These elements include:

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

In addition to the use of these content tags in the <controlaccess> section of the EAD instance, NCEAD recommends that the archdesc-level <scopecontent> include detailed content tagging. If an institution includes content tagging in this high-level element, such tagging should be done consistently for all encoded finding aids from the institution. Content tagging at subcomponent-level <scopecontent> elements can also be considered if that tagging will yield content access not available in the archdesc-level <scopecontent>.

The goal of content 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 content term were tagged on multiple occasions within a finding aid. Therefore we must be careful to not overstate the significance of any particular finding aid by using content tags throughout every section of the finding aid. If content tagging is employed consistently for all finding aids, fewer false leads will be encountered by researchers.

Guidelines for content tagging include:

• Tag only those terms that have significance for the collection.
• Tag the first instance of a particular term only once within all <scopecontent> notes (i.e. if tagged in archdesc level, do not tag in series or subseries level <scopecontent>)
• The normal attribute can be used to offer normalized forms of names or terms, but remember this can be very time-consuming and is not easily automated. In addition, if the normal attribute is used, a source attribute should be employed to indicate the controlled vocabulary used.

Back to Contents

Encoding Guidelines

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 "+//ISBN 1-931666-00-8//DTD ead.dtd (Encoded Archival Description (EAD) Version 2002)//EN" "./dtds/ead.dtd" [
<!ENTITY [imagename] PUBLIC "-//[NAME OF OWNER]::[SUBORDINATE NAMED DIVISION OF OWNER]//NONSGML ([brief image description])//EN" "./seals/[imagename].gif" NDATA gif>
<!ENTITY [entityname] PUBLIC "-//[NAME OF OWNER]::[SUBORDINATE NAMED DIVISION OF OWNER]//TEXT ([brief entity description])//EN" "./addresses/[entityname].xml">
...other entitities...
]>

(Note that lines breaks enforced by word processing programs should not be reflected in the XML document. Therefore do not use hard returns to reflect the structure demonstrated above, but continue entity declarations in one continual line. For more information about entities references and declarations, see Appendix B.)

NCEAD EAD 2002 Template

All elements listed in the template should be considered to be required unless noted with an <!-- OPTIONAL --> comment. All data should be included even if it is a placeholder. Default suggestions are made throughout the template for "placeholders" that might be appropriate, and are incorporated into the software tools* created for NCEAD. This template does not include all elements and attributes available in the document type definition. Instead, it includes those tags recommended or required for NCEAD as well as optional elements and attributes that have been defined in the NCEAD XSL stylesheet. For informaiton on other tags and attributes, please refer to the Encoded Archival Description Tag Library Version 2002.

* Software tools created for NCEAD include NoteTab®. Other software is also available for EAD encoding.

For the elements presented in this template, links have been provided to the Encoded Archival Description Tag Library Version 2002 for definitions and explanation. These links go directly to individual elements within the Tag Library.

<ead>
<eadheader audience="internal" countryencoding="iso3166-1" dateencoding="iso8601" langencoding="ISO 639-2" repositoryencoding="iso15511">

<eadid countrycode="us" mainagencycode="[code] publicid="[formal public identifier]" url="[url of document]">[document file name, no extension]</eadid>

<filedesc>
<titlestmt>
<titleproper>Inventory of the [title of collection: John Doe Papers], <date normal="[normalization of inclusive dates]">[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>

<!-- OPTIONAL: Sponsor statement -->
<sponsor>[sponsor statement]</sponsor>

</titlestmt>
<publicationstmt>
<publisher>[department name] <lb/>[institution name]</publisher><address><addressline>[city], N.C., U.S.A.</addressline></address>

<!-OPTIONAL: Copyright Information -->
<p><date>&#x00A9; [yyyy]</date> [Copyright holder]. All Rights Reserved.</p></publicationstmt>

<!-OPTIONAL: Note statement -->
<notestmt>
<note type="ncead">
<p>This finding aid is NCEAD compliant.</p>
</note>
</notestmt>

</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 langcode="eng">English.</language>
</langusage>

<descrules>Finding aid was prepared using <title>DACS</title></descrules>

</profiledesc>
<!-- WHEN APPROPRIATE: Revision description -->
<revisiondesc>
<change>
<date normal="[normalization of date]">[date of change]</date>
<item>[specification of changes made]</item>
</change>
</revisiondesc>

</eadheader>
<frontmatter>

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

<publisher>
<!--OPTIONAL: Institution seal or image -->
<extptr show="embed" entityref="[seal]"/><lb/>
[institution name][subordinate division]</publisher>
&[address entity name];

<!-- OPTIONAL: Copyright -->
<p>&copy; [yyyy] [repository]. All rights reserved.</p>

<! -- OPTIONAL: Sponsor statement --> <sponsor>[sponsor statement]</sponsor>

</titlepage>
</frontmatter>
<archdesc level="[level]" relatedencoding="MARC">

<did>
<head>Descriptive Summary</head>

<unittitle label="Title" encodinganalog="245">[title of collection: John Doe Papers], <unitdate normal="[normalized date]" type="inclusive">[inclusive dates of collection: yyyy-yyyy]</unitdate></unittitle>

<unitid countrycode="us" repositorycode="[NUC code]" label="Collection Number" encodinganalog="099"> [Collection number or Consult repository]</unitid>

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

<langmaterial label="Language of Material" encodinganalog="546">Material in <language langcode="[language code]">[Language]</language>.</langmaterial>.

<physdesc>
<extent label="Extent" unit="linear feet" encodinganalog="300">[number of linear feet]</extent>
</physdesc>

<repository label="Repository">In the <corpname>[Repository]</corpname>.</repository>

<!-- OPTIONAL: Location of material. -->
<physloc label="Location">Contact reference services for access to these materials.</physloc>

<abstract label="Abstract" encodinganalog="545">[Biographical/Historical context abstract]</abstract>
<abstract label="Abstract" encodinganalog="520">[Scope and Content abstract]</abstract>
</did>

<descgrp type="admininfo">
<head>Administrative Information</head>

<accessrestrict encodinganalog="506">
<head>Access Restrictions</head>
<p>[restrictions]</p>
</accessrestrict>

<userestrict encodinganalog="540">
<head>Copyright Notice</head>
<p>[copyright notice]</p>
</userestrict>

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

<acqinfo encodinganalog="541">
<head>Acquisition Information</head>
<p>[gift, purchase, etc.]</p>
</acqinfo>

<processinfo>
<head>Processing Information</head>
<p>Processed by [person who processed the collection], [date: month dd, yyyy]</p>
<p>Encoded by [person who encoded the collection, [date: month dd, yyyy]</p>
</processinfo>

</descgrp>
 
<bioghist>
<head>Biographical Note</head>
 
<chronlist>
<head>Chronology</head>
 
<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>[additional biographical/historical note paragraph describing the creator of the collection.]</p>
 
</bioghist>

<scopecontent>
<head>Collection Overview</head>
<p>[Scope and Content Note paragraph describing the collection]</p>
<p>[additional scope and content note paragraphs describing the collection]</p>
 
<arrangement>
<head>Arrangement Information</head>
<p>[Arrangement Note paragraph describing the arrangement of the collection]</p>
</arrangement>
 
</scopecontent>

<controlaccess>
<head>Online Catalog Headings</head>
 
<p>[Suggested Text: These and related materials may be found under the following headings in online catalogs.]</p>
 
<list type="simple">  
<item><[subelement] encodinganalog="[6xx]" source="[source code]">[term]</[subelement]></item>
 
<item><[subelement] encodinganalog="[6xx]" source="[source code]">[term]</[subelement]></item>
</list>
</controlaccess>

<!-- OPTIONAL: Separated material -->
 
<separatedmaterial>
<head>Materials Cataloged Separately</head>
<p>[descriptive note]</p>
</separatedmaterial>

<!-- OPTIONAL: Related material -->
 
<relatedmaterial>
<head>Related Material</head>
<p>[descriptive note]</p>
</relatedmaterial>

<dsc type="combined">
<head>Detailed Description of the Collection</head>

<c01 level="series">
   <did>
      <unittitle>[series title], <unitdate type="inclusive" normal="[normalized date]">[series date]</unitdate></unittitle>
      <physdesc><extent>[series extent]</extent></physdesc>
   </did>
 
   <scopecontent>
      <p>[series scope and content note, can be multiple paragraphs by repeating "p" elements]</p>
   </scopecontent>  
   <c02 level="subseries">
      <did>
         <unittitle>[subseries title]</unittitle>
         </did>
 
      <c03>
         <did>
            <unittitle>[folder or item title]</unittitle>
         </did>
      </c03>
 
      <c03>
         <did>
            <unittitle>[folder or item title]</unittitle>
         </did>
      </c03>
   </c02>
 
   <c02>
      <did>
         <unittitle>[folder or item title]</unittitle>
      </did>
   </c02>
</c01>
 
<c01 level="series">
   <did>
      <unittitle>[series title], <unitdate type="inclusive" normal="[normalized date]">[series date]</unitdate></unittitle>
      <physdesc><extent>[series extent]</extent></physdesc>
   </did>
   <scopecontent>
      <p>[series scope and content note, can be multiple paragraphs by repeating "p" elements]</p>    </scopecontent>  
   <c02>
      <did>
         <container type="box">[box #]</container>
         <unittitle>[folder or item title]</unittitle>
      </did>
   </c02>
   <c02>
      <did>
         <unittitle>[folder or item title]</unittitle>
      </did>
   </c02>
 
   <c02>
      <did>
         <unittitle>[folder or item title]</unittitle>
      </did>
   </c02>
</c01>

</dsc>

</archdesc>
</ead>

Back to Contents

Additional Issues

Linking Elements

Linking elements may be used to facilitate internal navigation of the EAD document and to provide access to external digital archival objects and other resources. Linking can make encoding a complex process. This section provides only a basic guide to simple linking techniques. This should not discourage experimentation with linking elements as described in the EAD Application Guidelines Chapter 7. However, not all linking possibilities are supported by current software and stylesheets. Further, any links used should be tested when the finding aid has been stored in its final location.

As opposed to SGML, in XML all elements must be closed as well as opened. However, the EAD DTD makes a certain exception for five elements namely: <lb>, <extptr>, <extptrloc>, <ptr>, and <ptrloc>. None of these elements may contain other elements nested within or PCDATA (parsed character data). Rather than creating a second element to close the open tag, XML allows these tags to be automatically closed by including a "/" immediately before the ">".

Internal Links

Simple internal links may be made using the <ref> element and id attribute 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>

The values of the target and id attributes must be identical. In addition, 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

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 named seal file.

Digital Archival Objects

A digital archival object may be included within the finding aid. This represents materials that are digitized from the collection. It is not appropriate to use digital archival objects elements for images of materias that are not contained within the collection(like an institutional seal). For most current practical purposes the digital archival object appears as a thumbnail image embedded within the finding aid on the web and links to an access image that is launched in a separate window. <daogrp> may appear within <bioghist>, <scopecontent>, or at any component level. For information on best practices for digitizing materials from your collections, please see NC ECHO's Guidelines for Digitization.

Encoding for digital archival objects is as follows:

<daogrp>
<daodesc><p>[description]</p></daodesc>
<daoloc role="thumbnail" href="[relative path]" title="[html alt tag text]"/>
<daoloc role="reference" href="[relative path]"/>
</daogrp>

This structure for digital archival objects sets up the thumbnail as the means of access to the image. The role attribute value "thumbnail" represents the thumbnail of the image that appears within the body of the finding aid. If you do not have a thumbnail-access image structure, you do not include the second <daoloc> element. Anchors and image html values are hard-coded into the stylesheet and use the role attribute to distinguish between the two <daoloc> elements.

<daodesc> allows you to provide more description about the image. It must appear first in order to parse in the <daogrp>. It can be used for a simple caption or a more detailed description of the digitized item. For instance, if you have produced an image of one letter from a folder of letters, you may add the <dao> at that component level. Note that the <unittitle> element for the <did> is <unittitle> of the component level while the <daodesc> provides space to make a title for and describe the digital object drawn from that component.

Sound files may also be linked using the <daogrp> element structure. The <daoloc role="thumbnail"> image links to a sound file image and the <daoloc role="reference"> is the link to the sound file itself. For sound files, it is highly recommended to include a <daodesc> that describes the sound file and any necessary technical playback information that a user may need.

Resources outside the finding aid

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:

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

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 additions 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 existing 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, those situations entail 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>

<odd>: When Nothing Else Fits...

Try again! The element Other Descriptive Data, like the <note> element, is an element of last resort, and should only be used in the case of retrospective conversion projects, where major restructuring of finding aid information is not possible and some portions simply do not fit appropriately into other elements. If you have questions about the appropriateness of certain elements for information in your finding aids, consult the NCEAD Email list, as others may have found a good solution.

References and Resources

Dooley, Jackie, ed. "Encoded Archival Description Part 1 - Context and Theory." American Archivist, v. 60(3), Summer 1997.

Dooley, Jackie, ed. "Encoded Archival Description Part 2 - Case Studies." American Archivist, v. 60(4), Fall 1997.

EAD Round Table of the Society of American Archivists. EAD Help Pages. http://jefferson.village.virginia.edu/ead/

EAD Working Group of the Society of American Archivists. Encoded Archival Description Application Guidelines Version 1.0. Society of American Archivists, 1999. http://www.loc.gov/ead/ag/index.html

EAD Working Group of the Society of American Archivists. Encoded Archival Description Tag Library Version 2002. Society of American Archivists, 2002. http://www.loc.gov/ead/tglib/index.html

Encoded Archival Description: Official EAD Version 2002 Web Site. http://www.loc.gov/ead/

Pitti, Daniel and Wendy M. Duff, ed. Encoded Archival Description on the Internet. New York: The Haworth Press, Inc., 2001.

RLG EAD Advisory Group. RLG Best Practice Guidelines of Encoded Archival Description. http://www.rlg.org/rlgead/rlg-ead-bpg.pdf

Appendix A. Entity Reference Examples

Entity references are an excellent way to include information that is repeated in all or many finding aid instances. Besides not having to re-type information, if the information in the entity is updated it only needs to changed in one location to implement the change in all finding aid instances. Below is an example of how Duke University incorporates text entity references into a EAD/XML document for repository information. An entity may have any name but it must contain valid and parsable encoding for where it will appear in the EAD/XML instance.

To insert text entities into the finding aid surround the entity name between an ampersand and a semicolon. e.g.
&addressfile;

Entity addressfile
<!-- Called by entity addressfile -->
<!-- Lives in file ./addresses/addressfile.xml -->
<!-- Duke University Rare Book, Manuscript, and Special Collections Library -->
<!-- Title page address and contact information -->
<list type="simple">
<head>Contact Information</head>
<item>Rare Book, Manuscript, and Special Collections Library</item>
<item>Duke University</item>
<item>P.O. Box 90185</item>
<item>Durham, North Carolina</item>
<item>27708-0185 USA</item>
<item>Phone: 919/660-5822</item>
<item>Fax: 919/660-5934</item>
<item>Email: <extref href="mailto:special-collections@duke.edu">special-collections@duke.edu</extref></item>
<item>URL: <extref href="http://scriptorium.lib.duke.edu/">http://scriptorium.lib.duke.edu/</extref></item>
</list>

Non-text entities (primarily images) will be declared in the same way as text entities but they are included in the EAD finding aid differently. One method is to use the external pointer element and identify the entity with the attribute entityref. In the example below the Duke University Seal is declared.

<extptr show="embed" entityref="dukeseal"/>
<!ENTITY dukeseal PUBLIC "-//Duke University::Rare Book, Manuscript, and Special Collections Library//NONSGML (dukeseal)//EN" "dukeseal.gif" NDATA gif>