|
Metadata Initiatives
NCDC
PMDO
NCEAD
NCEAC
Digitization
Guidelines
Metadata
Tools
|
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/dig/tools2005.shtml.
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.
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.
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/dig/tools_home.shtml) along with the tools themselves.
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/dig/tools_home.shtml. 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.
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/dig/tools_home.shtml. 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/dig/unicode.shtml.
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.
| Character |
ISO 8879 |
Unicode
Hexadecimal |
| & |
& |
& |
| < |
< |
< |
| > |
> |
> |
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:
<scopecontent><p>The poem, <title render="doublequote">Trees,</title> which was written...</p></scopecontent>
Which displays as: The poem, "Trees," which was written...
Incorrect:
<scopecontent><p>The poem, <title render="doublequote">Trees, </title>which was written...</p></scopecontent>
Which displays as: The poem, "Trees, "which was written...
Incorrect:
<scopecontent><p>The poem, <title render="doublequote">Trees </title>, which was written...</p></scopecontent>
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:
| Single dates |
| July 4, 2003 |
20030704 |
| 4th of July, 2003 |
20030704 |
| July, 2003 |
200307 |
| 2003 |
2003 |
| Range dates |
| July 4, 2003 - July 10, 2003 |
20030704/20030710 |
| July 2003 - August 2003 |
200307/200308 |
| 2003 - 2004 |
2003/2004 |
* Note that in the computer environment, ISO 8601 can be expressed either with or without the hyphens. For instance, 20030704 = 2003-07-04.
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.
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.)
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.
- The XML Declaration and the Doctype Declaration should appear identical to what is shown above except the name and relative path of the files. Entities, however, should reflect the form shown above but each institution will create and maintain their own sets of entities. Entities are best used to display common information that is repeated across an institution's finding aids. This eliminates the need to retype this information, and if the information changes it only needs to be changed in one location. Make sure your entities contain valid EAD/XML code.
|
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">
Discussion
- audience attribute set to "internal" indicating internal use only of the <eadheader> information.
- Attribute values for langencoding, countryencoding, dateencoding, and repositoryencoding are set to the values above.
|
<eadid countrycode="us" mainagencycode="[code] publicid="[formal public identifier]" url="[url of document]">[document file name, no extension]</eadid>
|
Discussion
The <eadid> provides a unique identifier for the EAD instance.
- The mainagencycode attribute refers to the NUC code. It is recommended that each institution obtain an NUC code for interoperability. For more information go to the MARC Code List for Organizations (http://lcweb.loc.gov/marc/organizations/).
- In the example above the formal public identifier provides a filename-independent reference for the finding aid which includes full information about its owner and title. To construct a formal public identifier use:
-//[institution name]::[subordinate division]//TEXT (us::[main agency code]::[local reference code]::[title of resource])//EN
Creating a public identifier:
[institution name] = name of the institution
[subordinate division] = name of the subordinate division (if applicable, if not leave blank)
[main agency code] = organization code from MARC Code List for Organizations
[local reference code] = local system code (if applicable or leave blank)
[title of resource] = title of resource including dates
Leave all "/" and ":" punctuation as is, even if some of the above are blank.
- Include the entire url of the document in the url, including the "http:// " section.
- The text value of this field should contain only the file name without a file extension.
It is assumed that within an institution, this will represent a unique file name.
|
<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>
Discussion
- Multiple names of persons processing the collection can be listed here: John Doe, Jane Q. Doe, Joe Smith
- If such names are unknown, a general attribution such as "Staff" should be used.
- The title of the collection should be preceded by a title prefix. Some prefixes that may be appropriate include:
- Inventory of the
- Preliminary Inventory of the
- Guide to the
- Register of the
- Note that the <titleproper> element provides a title for the finding aid rather than the collection proper.
- The title prefix used in <eadheader><titlestmt><titleproper> should be identical to the one used later in the <frontmatter><titlepage><titleproper>.
- A bulk date may also be included in the titleproper in addition to the inclusive dates. This should be placed in a separate <date> tag.
|
<!-- OPTIONAL: Sponsor statement -->
<sponsor>[sponsor statement]</sponsor>
Discussion
- Use the sponsor tag to acknowledge support from granting agencies. A matching <sponsor> tag should appear in the <frontmatter><titlepage> or in the <archdesc><processinfo> element. This sponsor statement can be as long as needed but is limited to one paragraph. Formatting in the <eadheader> section is not necessary because it is internal information.
- Note that NC ECHO has specific requirements for finding aids created or encoded in NC ECHO grant-funded projects. A sponsor statement should be included in both the <eadheader> amd either the <frontmatter> or the <archdesc><processinfo> sponsor statement options. The statement is as follows:
Funded by the Institute of Museum and Library Services (IMLS) and the federal Library Services and Technology Act (LSTA), with support provided through North Carolina ECHO.
It is preferred although not required to include an external link to the NC ECHO website.
Encoding sample
<eadheader>
<sponsor>Funded by the Institute of Museum and Library Services (IMLS) and the federal Library Services and Technology Act (LSTA), with support provided through North Carolina ECHO.</sponsor>
And choose between
<frontmatter> in <titlepage>
<sponsor>Funded by the Institute of Museum and Library Services (IMLS) and the federal Library Services and Technology Act (LSTA), with support provided through <extref linktype="simple" show="new" href="http://www.ncecho.org/" title="http://www.ncecho.org/">North Carolina ECHO </extref></sponsor>
or
<archdesc> as an additional <p> in <processinfo>
<p>Funded by the Institute of Museum and Library Services (IMLS) and the federal Library Services and Technology Act (LSTA), with support provided through <extref linktype="simple" show="new" href="http://www.ncecho.org/" title="http://www.ncecho.org/">North Carolina ECHO </extref><p>
|
</titlestmt>
<publicationstmt>
<publisher>[department name] <lb/>[institution name]</publisher><address><addressline>[city], N.C., U.S.A.</addressline></address>
Discussion
- The name and address of the department and institution "publishing" the finding aid should be included in the <publicationstmt> element.
- Include the City for location purposes.
|
<!-OPTIONAL: Copyright Information -->
<p><date>© [yyyy]</date> [Copyright holder]. All Rights Reserved.</p></publicationstmt>
Discussion
- Inclusion of a copyright statement for the contents of the finding aid should be placed in this element. Since many institutions are not able to copyright public resources, inclusion of copyright is optional.
- Once an institution determines its copyright status, amendment to the template will ensure that each finding aid reflects that status.
|
<!-OPTIONAL: Note statement -->
<notestmt>
<note type="ncead">
<p>This finding aid is NCEAD compliant.</p>
</note>
</notestmt>
Discussion
- The <notestmt> section indicates compliance with the NCEAD Best Practice Guidelines. An accompanying seal is displayed below the table of contents as part of the NCEAD consortium. Because the seal is embedded in the stylesheet, this notestmt will provide information that accompanies the document about compliance to consortial standards. See http://www.ncecho.org/dig/seal.shtml for more information about the NCEAD Seal.
|
</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>
Discussion
- The appropriate selection should be made from the choices above. Where an automated markup system is used, its template will simply specify "automated markup system."
|
<langusage>Description is in <language langcode="eng">English.</language>
</langusage>
Discussion
- The language section tells the browser that the finding aid is written in English. If more than one language is used to write the finding aid, separate each individual language with a <language> tag.
- Each <language> tag should include a langcode attribute with the value determined by the ISO 639-2b standard. For other language codes, see: http://home.earthlink.net/~banerjek/calculate/.
|
<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>
Discussion
- <revisiondesc> provides information on the date and change of the electronic file. For example, it should be included for those EAD documents that are to be or have been converted from Version 1.0 to Version 2002.
- Any changes made to the electronic document should be recorded in the <revisiondesc> portion of the <eadheader>, including conversion, additions, or general revisions.
- It is important to record this informaiton as well in the <archdesc><descgrp type="admininfo"><processinfo> portion of the finding aid as well if that information would be useful for researchers.
|
</eadheader>
<frontmatter>
Discussion
- The <frontmatter> section provides an "electronic title page" for the finding aid. It is this section that creates the title page as displayed to the user by an XML system. The information displayed in the <frontmatter> is important in identifying the finding aid to the user. Like the <eadheader>, this section will usually be generated automatically.
|
<titlepage>
<titleproper>Inventory of the [title of collection: John Doe Papers], <date>[inclusive dates of collection: yyyy-yyyy]</date></titleproper>
Discussion
- The title of the collection should be preceded by one of the following and must be the same as the one used earlier in the <eadheader><titlestmt><titleproper> section.
- The title of the collection should be devised according to DACS rules, and should contain the name first and type of material last to eliminate confusion about the meaning of the dates following the collection title.
See DACS rule 2.3 Title Element, pp. 17-23
For example: John Q. Doe Papers, 1932-1986
Rather than: Papers of John Q. Doe, 1932-1986
This may require the revision of existing collection names.
- Always use standardized forms for dates, typically yyyy-yyyy at this level, with "undated" representing no date information available.
See DACS rule 2.4.16, p. 28
- 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.
See DACS rule 2.4.10, p. 26
|
<publisher>
<!--OPTIONAL: Institution seal or image -->
<extptr show="embed" entityref="[seal]"/><lb/>
[institution name][subordinate division]</publisher>
&[address entity name];
Discussion
- A seal or other images for the institution may be included through the <extptr> element and entity reference. The entity is declared in the document subset of the EAD instance.
- Institution name and address is included through an entity in the <frontmatter>. The entity is included in the declaration subset and references an xml file containing contact information marked up. For more information and examples of this entity reference see Appendix A.
|
<!-- OPTIONAL: Copyright -->
<p>© [yyyy] [repository]. All rights reserved.</p>
Discussion
- Copyright of finding aids is optional; please see discussion in <eadheader> section. If copyright has been stated in the <eadheader>, it should be reflected in the <titlepage> as well.
|
<! -- OPTIONAL: Sponsor statement -->
<sponsor>[sponsor statement]</sponsor>
Discussion
- Use the sponsor tag to acknowledge support from granting agencies. A public sponsor statement can be included here or in the <processinfo> in the <archdesc>. A matching <sponsor> tag should appear in the <eadheader><filedesc><titlestmt>. This sponsor statement can be as long as needed but it is limited to one paragraph or the use of the <lb/>. You may also include an <extptr> for the URL of the sponsoring body.
- See discussion above for sponsor statements regarding NC ECHO funded projects.
|
</titlepage>
</frontmatter>
<archdesc level="[level]" relatedencoding="MARC">
Discussion
- The <archdesc> element contains the archival description proper. It contains all information related to the materials 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. Possible values include: class, collection, file, fonds, item, recordgrp, series, subfonds, subgrp, and subseries. In addition a value of "otherlevel" is available with an accompanying otherlevel attribute with a value that is determined by the repository. It is recommended that if the level value "otherlevel" and otherlevel attribute is necessary that it be used sparingly and with a controlled vocabulary. Recording specific terms used and their meanings will ensure consistent use of the attribute.
- The relatedencoding attribute corresponds to encodinganalog attributes found throughout the <archdesc> portion of the template.
The <archdesc> contains several important elements. While the DTD allows freedom in the ordering of some of these elements, the listing below is the recommended order. Not all elements will be appropriate for each finding aid. Those in bold are considered "core" descriptive elements and should be considered required. Others listed in the template are required where appropriate.
<did> - Collection-level descriptive identifier
<descgrp type="admininfo"> - Administrative information about the collection
<bioghist> - Biographical and/or historical information about the creator of the collection
<scopecontent> - Scope and content note
<arrangement> - Arrangement information (may also nest within <scopecontent>)
<controlaccess> - Collection level subject access points
<relatedmaterial> - Materials that are not in the collection but valuable in understanding them.
<separatedmaterial> - Materials that are part of the intellectual collection but have been removed for storage, preservation, or other purposes.
<dsc> - Description of subordinate components (container list)
The <note> and <odd> elements are not recommended for inclusion at this level unless careful consideration indicates otherwise. For more information regarding <note>, see discussion above; for more information regarding <odd>, see discussion below. For other elements used for specific cases, please see How do I encode...?.
|
<did>
<head>Descriptive Summary</head>
Discussion
- The <did> element is available and required at each level of an encoded finding aid and forms the basic unit of decription for EAD. Below is outlined those elements recommended for the <archdesc> level of the finding aid. For information about the <did> at lower levels of the document, see the <dsc> section of the template.
- The <did> is one of the most important elements in EAD because it groups together key descriptive information about the unit 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.
|
<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>
Discussion
- The title and dates of the collection in <unittitle> and <unitdate> should appear exactly as they appear in the <titleproper> and <date> elements encoded earlier without the prefix.
- Note that label attribute values' initial letters of elements occurring in the <did> are capitalized to ensure proper display with typical stylesheets.
- <unitdate> type attribute has two available values: "inclusive" and "bulk". Most dates in a finding aid will be type="inclusive." The <unitdate> element may be repeated if a bulk date is also desired. Date normalization is important at this level and should not be overlooked. RLG Best Practice Guidelines requires normalization of all dates. NCEAD has decided that dates should be normalized only at high level descriptions (i.e., <archdesc> and <c01> levels), although dates may be normalized throughout the EAD document if an institution wishes to do so.
- Note that the <unitdate> forms part of the <unittitle>. While this is not required through the dtd or DACS, NCEAD interprets <unitdate> information as an integral part of the <unittitle> element. Encoding the <unitdate> in this way ensures that each <did> has a <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>.
Discussion
- This element indicates the language of the materials being described. It includes an element <language> and a langcode attribute in that element that reflects the ISO 639-2b code for languages. This element is required for NCEAD finding aids. This tag represent the languages present in the materials not the language the finding aid was written in. If more than one language is represented in a collection, the <language> element within <langmaterial> should be repeated for each language.
See DACS rule 2.2, p. 16
|
<physdesc>
<extent label="Extent" unit="linear feet" encodinganalog="300">[number of linear feet]</extent>
</physdesc>
Discussion
- Measurement values within the <extent> tag unit attribute may be altered as necessary - for example, "cubic feet" rather than "linear feet" may be used by a particular institution. The unit attribute value, however, should follow a consistent application. Other units of measurement include items, boxes, oversized cases, etc. Extent information is considered important for collection level description and should be included even if it is only an estimate.
See DACS rule 2.5, pp. 29-32
- Many institutions provide two different measurements of their collection. Each unit of measurement should be separately enclosed within its own <extent> element.
<extent unit="items" encodinganalog="300">About 400</extent>
<extent unit="linear feet" encodinganalog="300">1.0</extent>
- Additional elements <dimensions>, <physfacet>, and <genreform> are also available for further description of the nature of the materials within the collection.
|
<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>
Discussion
- The <abstract> element is highly recommended element for finding aids. The <abstract> provides researchers with an overview of a collection summarizing the primary information about a collection. NCEAD strongly suggests information in an abstract to be constructed of five parts:
- First abstract tag:
- Identification of creator
- Second abstract tag:
- Types of material
- Dates of material
- Function by which the material was created
- Important subjects, names, corporate bodies, geographical places
- Most of the <abstract> can be written by lifting phrases from other elements in the collection level description. For retrospectively converted finding aids an existing abstract may be hard to locate, but following the above model makes it easy to construct suitable abstract components from the information available. A descriptive note from the MARC record may be used if available.
For the first abstact element, see DACS, Chapter 10, pp. 93-104. This is connected to the <bioghist> discussion below. For the 2nd abstract element, see DACS, Chapter 3, pp. 35-39. This is connected to the <scopecontent> discussed below.
- All elements specified above are available to the <did> at all levels of description. However, with the inheritance of information, not all elements need to be used lower than the <archdesc> level. For instance, <physloc> or <repository> would hold true for each item within a collection as well as the collection as a whole. In contrast to this concept, the collection level information represents an aggregation of the detailed information from the description of subordinate components. This impacts the kind of information given at this level for several elements. For example, <unitdate> should represent the range of dates represented in a collection, or <extent> should be the compilation of all material within the collection. In addition, there is a great deal of flexibility within the <did> to meet the needs of description of a particular collection. That being said, it is important to include as much information at the collection level as possible.
|
<descgrp type="admininfo">
<head>Administrative Information</head>
Discussion
- It is NCEAD practice to include these elements within the wrapper <descgrp type="admininfo"> at the collection level. This wrapper allows for a <head> element that labels that section of the finding aid. Administrative information about the collection is helpful to both users who wish access to the collection and to archivists in managing the collection.
- Teh five elements included in the template are required.Other available elements within this section of the finding aid may be added as needed, provided care is taken to ensure that they are applied consistently (see How do I encode...?). Default language should be created wherever possible for heads, information, and restrictions contained within administrative information section elements, although the uniqueness of many collections will defy these attempts.
|
<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>
Discussion
- The <bioghist> element contains the biographical and/or historical note for the collection. Generally a biographical note will contain descriptive paragraphs and/or a chronology of dates and events.
- The order of the element is determined by the institution. Narrative portions of the <bioghist> should be placed in <p> tags. The chronology appears in a <chronlist> consisting of <chronitem>s.
See DACS rule 2.7, p. 34 and Chapter 10 "Administrative/Biographical History," pp. 93-104
- The <head> element may be changed according to the following templates, keeping in mind the need for consistency across all finding aids. Recommended headers for the <bioghist> include:
- Biographical Note (a note containing only biographical information about a person)
- Historical Note (a note containing historical information, usually about a corporation, place, family, event, etc.
- Biographical and Historical Note (a note combining biographical and historical information)
- Chronology (a note formatted as a chronology of events)
- The <chronitem> element also has an <eventgrp> element available that allows you to group a series of events under one date. This kind of encoding is included in the teamplte. For grouping events in a chronology, see Appendix G.
- The discussion above represents one interpretation of the <bioghist> section of the document, although other configurations are possible. See Appendix G for other options.
- Bibliographic citations for sources consulted in order to construct a biographical or historical note should be included in the <bioghist> if considered appropriate by an institution. Do not include these references in <bibliography> as discussed in Appendix G. An example of encoding bibliographic ciations within the <bioghist> would be:
<p><bibref><persname>[author]</persname><title render="italic">[title of monograph</title>. [Imprint information, Place: Publisher, date]</bibref></p>
|
<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>
Discussion
- The <scopecontent> element contains information about the scope and content of the collection. Depending upon the finding aid being encoded, different options are available for the use of <scopecontent> and <arrangement>. See Appendix G for other options. If a legacy finding aid lists arrangement and organization information as part of the scope and content note and it is easily discernable in the text, there is no need to create a separate <arrangement> section. If a separate section is preferable, place the information in its own <arrangement> element but within a wrapper <scopecontent> element for the entire section.
See DACS rule 3.1, pp. 35-39
- The <arrangement> element may contain information about how materials have been divided into smaller units within a hierarchical structure (often used to indicate series titles and refered to as the organization of the collection) and/or the filing sequence of the materials being described (often referred to as the arrangement of a collection). Notes for Original Order are typical examples of information included in an <arrangement> note.
See DACS rule 3.2, pp. 40-42
- NCEAD strongly recommends content tagging for elements such as <persname>, <corpname>, <geogname>, <subject>, <title>, etc. within the text of the <scopecontent> for significant content points if there is sufficient time and resources to do so.
|
<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>
Discussion
- The basic collection-level <controlaccess> element contains a list of subject terms and is required for adequate collection-level description. This list should be identical to the terms used in the collection-level MARC record.
- Each subject term within <item> elements will be further surrounded by one of the elements listed below (represented by <[subelement]> above):
- It is strongly recommended that encodinganalog and source attributes be used to map these elements to their corresponding fields in MARC format and provide information about the controlled vocabulary used to construct the terms.
<item><corpname encodinganalog="610" source="lcnaf">North Carolina Advisory Council on Education.</corpname></item>
<item><famname encodinganalog="600" source="lcnaf">Abbot family.</famname></item>
<item><genreform encodinganalog="655" source="gmgpc"> Photographic prints</genreform></item>
<item><geogname encodinganalog="651" source="lcsh">Durham (N.C.)</geogname></item>
<item><persname encodinganalog="600" source="lcnaf">Twain, Mark, 1835-1910</persname></item>
<item><subject encodinganalog="650" source ="lcsh">Law enforcement.</subject></item>
<item><title encodinganalog="630" source="lcnaf">New Testament.</title></item>
While DACS does not deal specifically with the creation of controlled access points in its rule structure, a discussion of access points appears in the introduction, pp. xviii-xxi.
Subdivisions
- For nominal terms, separate subordinate names with a period and a space. For example:
<corpname encodinganalog="610" source="lcnaf">North Carolina Bar Association. Bankruptcy Section.</corpname>
- For other terms, separate subdivisions with two sort dashes or hyphens (with no spaces) as in the example below. Enclose the entire subject and subdivision within a single element rather than attempting to mark each subdivision individually. For example:
<item><subject encodinganalog="650" source="lcsh">Education--United States.</subject></item>
is correct, rather than:
<item><subject encodinganalog="650" source="lcsh">Education</subject>--<geogname>United States.</geogname></item>
- Because the subject and its subdivisions in the example would occur within a 650 field in the MARC record, the entire subject string is placed within the equivalent <subject> element in EAD.
- While the supplied template combined with added subject elements represents a minimum practice, other more complex implementations of <controlaccess> are possible. See Appendix G for other options.
|
<!-- OPTIONAL: Separated material -->
<separatedmaterial>
<head>Materials Cataloged Separately</head>
<p>[descriptive note]</p>
</separatedmaterial>
Discussion
- <separatedmaterial> is reserved for items or sections that are a part of the collection but have been removed for storage, preservation, or other purposes. Separated materials allows for effective management and tracking of parts of a collection. Use of <separatedmaterial> will depend on local processing and descriptive practice.
|
<!-- OPTIONAL: Related material -->
<relatedmaterial>
<head>Related Material</head>
<p>[descriptive note]</p>
</relatedmaterial>
<dsc type="combined">
<head>Detailed Description of the Collection</head>
Discussion
- The <dsc> element is used for container lists, series descriptions, and other descriptive lists and is the most complex and time-consuming section of the encoded finding aid. When dealing with retrospective conversion of legacy material there will be many variants in container lists to contend with. Based on analysis of current and past descriptive practices, EAD indicates 3 basic types of container lists (specified in the type attribute of the <dsc> element). See Appendix C for example of each.
- Because of the complexity and number of potential variants in container lists, the <dsc> template can serve as a general guide only. Some methods of encoding will be discussed within the context of this example, but much will depend on the contents of a particular collection, its research value, and staff resources. See the EAD Tag Library and EAD Application Guidelines for extensive examples and greater illumination on specific topics.
- The type attribute is a required attribute in the dtd:
- combined - A mixed series description and container list. This is typical of modern finding aids. Each series begins with an overview scope and content note followed by the container listing.
- analyticover - A container list made up of series and subseries descriptions only which should be used in combination with <dsc type="in-depth">.
- in-depth - A container list containing hierarchical description of the components of a collection including box, folder, and other locations. May also be a "boxlist," "handlist," or "calendar." In-depth should be used in combination with <dsc type="analyticover">.
- NCEAD recommends that new finding aids integrate the series descriptions with the container list enabling the use of the "combined" type of <dsc> for easier online navigation and comprehension of the finding aid. Some institutions encode finding aids with a series descriptions in one section (analyticover) followed by a complete container listing (in-depth) in another. A user is thus able to review the series descriptions in summary form or as a table of contents and then turn to the container listing for an in-depth box listing. This type of encoding is generally considered a legacy form of archival description but is helpful for the retrospective conversion of finding aids.
- The basic required element within each component <c0x> is <did> with <unittitle> within.
- In the encoding sample below, indentation is for demonstration purposes only and not required in encoding.
|
<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>
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.
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>
APPENDIX B. eadlocal.ent ATTRIBUTE VALUE DEFINITIONS
The source attribute
The attribute source, which is available in several elements to define the controlled vocabulary used for a subject tag, has been refined in the eadlocal.ent file for NCEAD. Below is a table of existing values (listed in the "code" column) for various controlled vocabularies. Note that a "local" value is available. Any amendments made to the eadlocal.ent file will be announced on the NCEAD email list so that institutions can download the file and replace an older version.
| Code |
Name of Controlled Vocabulary |
| aat |
Art and Architecture Thesaurus http://www.getty.edu/research/tools/vocabulary/aat/ |
| atla |
Religion indexes: Thesaurus |
| gmgpc |
Thesaurus for Graphic Materials: TGM II Genre and Physical Characteristic Terms http://lcweb.loc.gov/rr/print/tgm2/ |
| itoamc |
Index terms for Occupations in Archival and Manuscript Collections (Library of Congress) |
| lcnaf |
Library of Congress Name Authorities File http://authorities.loc.gov/ |
| lcsh |
Library of Congress Subject Headings |
| lctgm |
Thesaurus for Graphic Materials: TGM I Subject Terms http://lcweb.loc.gov/rr/print/tgm1/ |
| local |
Locally controlled list of terms* |
| mesh |
Medical Subject Headings http://www.nlm.nih.gov/mesh/meshhome.html |
| mim |
Moving Image Materials: Genre Terms |
| nal |
NAL Agricultural Thesaurus http://agclass.nal.usda.gov/agt/agt.htm |
| nasat |
NASA Thesaurus http://www.sti.nasa.gov/thesfrm1.htm |
| ncg |
North Carolina Gazetteer |
| nimacsc |
NIMA Cartographic Subject Categories |
| nmc |
Revised Nomenclature for Museum Cataloging: a revised and expanded version of Robert C. Chenhall's system for classifying man-made objects. |
| poliscit |
Political Science Thesaurus II (University Center for International Studies, University of Pittsburgh) |
| rbbin |
Binding terms: A Thesaurus for Use in Rare Book and Special Collections Cataloging (ACRL) |
| rbgenr |
Genre Terms: A Thesaurus for Use in Rare Books and Special Collections Cataloging (ACRL) |
| rbpap |
Paper terms: A Thesaurus for Use in Rare Book and Special Collections Cataloging (ACRL) |
| rbpri |
Printing & Publishing Evidence: A Thesaurus for Use in Rare Book and Special Collections Cataloging [used for printing terms] (ACRL) |
| rbprov |
Provenance Evidence: A Thesaurus for Use in Rare Book and Special Collections Cataloging (ACRL) |
| rbpub |
Printing & Publishing Evidence: A Thesaurus for Use in Rare Book and Special Collections Cataloging [used for publishing terms] (ACRL) |
| rbtyp |
Type Evidence: A Thesaurus for Use in Rare Book and Special Collections Cataloging (ACRL) |
| reveal |
REVEAL: fiction indexing and genre headings (UKOLN) |
| sears |
Sears List of Subject Headings (H.W.Wilson Company) |
| she |
SHE: Subject Headings for Engineering |
| test |
Thesaurus of Engineering and Scientific Terms |
| tgn |
Getty Thesaurus of Geographic Names http://www.getty.edu/research/tools/vocabulary/tgn/ |
* Use of local should be considered the last resort and should refer to a controlled vocabulary established by an institution.
The type attribute for <container>
The attribute type for container allows you to specify what kind of container you have. This list has been amended to provide a controlled vocabulary. Any or all of these types can be used to describe your containers. If you have a container that is not listed here, or you would like to change this list, it is your prerogative. This list is provided as a starting point only. Unlike the source attribute discussed above, this attribute is only used for your display purposes and will not be used for search and retrieval. To edit this list, please see below.
| Attribute Value |
Container type display |
| audiocassette |
Audiocassette |
| audiodisc | Audiodisc |
| audiotape | Audiotape |
| box | Box |
| cd | CD |
| datacd | Data CD |
| dvd | DVD |
| film | Film |
| folder | Folder |
| image | Image |
| imagefolder | Image Folder |
| interview | Interview |
| museumitem | Museum Item |
| notebook | Notebook |
| odc | Optical Disc Cartridge |
| oimage | Oversize Image |
| oimagefolder | Oversize Image Folder |
| opaper | Oversize Paper |
| opaperfolder | Oversize Paper Folder |
| ovolume | Oversize Volume |
| photoablum | Photograph Album |
| reel | Reel |
| scrapbook | Scrapbook |
| sfimage | Special Format Image |
| videodisc | Videodisc |
| videotape | Videotape |
| volume | Volume |
Editing the eadlocal.ent file
The eadlocal.ent file structure implemented in EAD 2002 allows for a broader implementation of EAD, both within the United States and internationally. One option is to leave attribute value lists open. However, confining attribute value lists should be seriously considered in order to avoid conflicts resulting from typographical errors by encoders. An alternative way to avoid such errors is to use macros or dialog boxes available in XML authoring programs to generate attribute values. This will not prevent hand-entering undesirable values but is likely to curtail the practice. This method does not, however, benefit from a "checking" mechanism in the validation process that is enforced using the eadlocal.ent.
The example below demonstrates the editing process for those attributes that have NMTOKEN as a value. In order to edit the eadlocal.ent to define a new attribute value list, simply replace NMTOKEN with your controlled vocabulary list. That list should be in parentheses and each value should be separated by a space, a vertical bar, and another space:
(a | b | c) not (a|b|c)
Keep in mind that XML is case sensitive. Therefore, it is best practice to use lowercase values when controlling a attribute value list. have been excerpted from the instructions resident in the eadlocal.ent file. For more information, see the entire set of directions there.
Example:
<!ENTITY % am.container.type
'type
NMTOKEN
#IMPLIED'
>
You replace the NMTOKEN with your list:
<!ENTITY % am.container.type
'type
(audiocassette | audiodisc | audiotape | box | cd | datacd | dvd | film | folder | image | imagefolder | interview | museumitem | notebook | odc | oimage | oimagefolder | opaper | opaperfolder | ovolume | photoalbum | reel | scrapbook | sfimage | videodisc | videotape | volume)
#IMPLIED'
>
This example shows what has been done for the attribute type for the element container. Note that you may add or change these attribute values for your own institution's needs. Make sure that you include a statement in the Revision History at the beginning of the document so that you will know what you have changed. DO NOT change the list of values for source discussed above. That attribute value list is controlled through the consortium.
APPENDIX C. EXAMPLES OF DIFFERENT TYPES OF <dsc>
The following examples are intended to demonstrate how different types of <dsc> may appear. They are not meant to be prescriptive of format, organization, or content. Each finding aid will merit different levels of encoding based on the institution's resources and mission.
Example of a combined <dsc>
The combined <dsc> joins the information in an analytic overview <dsc> and an in-depth <dsc> into one <dsc>. This is the common method for encoding new finding aids.
<dsc type="combined">
<head>Description/Container List</head>
<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>
<c02 level="subseries">
<did>
<unittitle>[subseries]</unittitle>
</did>
<c03>
<did>
<unittitle>[collection content]</unittitle>
</did>
</c03>
<c03>
<did>
<unittitle>[collection content]</unittitle>
</did>
</c03>
<c03>
<did>
<container type="box">2</container>
<unittitle>[collection content]</unittitle>
</did>
</c03>
<c03>
<did>
<unittitle>[collection content]</unittitle>
</did>
</c03>
</c02>
</c01>
<c01 level="series">
<did>
<container type="box">3</container>
<unittitle>[series], [yyyy-yyyy]</unittitle>
</did>
<c02>
<did>
<unittitle>[collection content]</unittitle>
</did>
</c02>
<c02>
<did>
<unittitle>[collection content]</unittitle>
</did>
</c02>
<c02>
<did>
<container type="box">4</container>
<unittitle>[collection content]</unittitle>
</did>
</c02>
<c02>
<did>
<unittitle>[collection content]</unittitle>
</did>
</c02>
</c01>
</dsc>
Example of an analytic overview <dsc>
An analytic overview <dsc> will usually only include description of the series and possibly the sub-series levels. Often scopecontent descriptions will be included.
<dsc type="analyticover">
<head>List of Series</head>
<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>
<c01 level="series">
<did>
<container type="box">2</container>
<unittitle>[series], <unitdate type="inclusive">[yyyy-yyyy]</unitdate></unittitle>
</did>
<scopecontent><p>[scope and content note about this series]</p></scopecontent>
</c01>
</dsc>
Example of an in-depth <dsc>
The in-depth <dsc> (when preceded by the analytic overview <dsc>) usually includes only cursory information of the series and subseries levels while providing more detailed information of folder, item or other lower levels of description.
<dsc type="in-depth">
<head>Container List</head>
<c01 level="series">
<did>
<unittitle>[series], <unitdate type="inclusive">[yyyy-yyyy]</unitdate></unittitle>
</did>
<c02 level="subseries">
<did>
<unittitle>[subseries]</unittitle>
</did>
<c03>
<did>
<container type="box">1</container>
<container type="folder">1</container>
<unittitle>[collection content]</unittitle>
</did>
</c03>
<c03>
<did>
<container type="folder">2</container>
<unittitle>[collection content]</unittitle>
</did>
</c03>
<c03>
<did>
<container type="box">2</container>
<container type="folder">1</container>
<unittitle>[collection content]</unittitle>
</did>
</c03>
<c03>
<did>
<container type="folder">2</container>
<unittitle>[collection content]</unittitle>
</did>
</c03>
</c02>
</c01>
<c01 level="series">
<did>
<container type="box">3</container>
<unittitle>[series], [yyyy-yyyy]</unittitle>
</did>
<c02>
<did>
<container type="folder">1</container>
<unittitle>[collection content]</unittitle>
</did>
</c02>
<c02>
<did>
<container type="folder">2</container>
<unittitle>[collection content]</unittitle>
</did>
</c02>
<c02>
<did>
<container type="box">4</container>
<container type="folder">1</container>
<unittitle>[collection content]</unittitle>
</did>
</c02>
<c02>
<did>
<container type="folder">2</container>
<unittitle>[collection content]</unittitle>
</did>
</c02>
</c01>
</dsc>
APPENDIX D. CROSSWALKS
Crosswalks enable interoperability between metadata systems and help decrease redundancy in metadata creation. The NCEAD template and XSLT clips available in the NoteTab clip library have two different crosswalks embedded. Both Dublin Core and MARC crosswalking are part of the NCEAD template and are recommended where appropriate for NCEAD participating institutions.
Dublin Core
The Dublin Core crosswalk is generated through the XSLT clip that creates HTML versions of finding aids. This information is culled from the <archdesc> level information. See http://www.ncecho.org/dig/ for more information about North Carolina's Dublin Core standards. The crosswalk constructed to derive Dublin Core for the HTML version is compliant with the NC ECHO Dublin Core implementation guidelines.
Because many institutions will be creating various types of metadata representations for their collections, the Dublin Core representation is extremely important. Dublin Core acts as the common metadata format across NC ECHO participating institutions. In addition, browser compatibility issues necessitate the representation of EAD finding aids in HTML format.
| Area of description |
EAD element* |
Dublin Core field |
| Local call number | <eadid> @publicid* | Identifier |
| Personal main entry | <origination><persname> | Creator |
| Corporate main entry | <origination><corpname> | Creator |
| Title | <titleproper> | Title |
| Physical description | <physdesc><extent> | Format.Extent |
| Physical description | <physdesc><genreform> | Format.Medium |
| Language note | <language>@langcode | Language |
| Repository | <repository><corpname> | Publisher |
| Biographical or historical note | <abstract>
(bioghist abstract) | Description |
| Contents note | <abstract>
(scopecontent abstract)
| Description |
| Description
Access note | <accessrestrict> | Description |
| Copyright note | <userestrict> | Rights |
| Immediate acquisitions note | <acqinfo> | Description or Provenance |
| Personal name subject | <controlaccess><persname> | Subject |
| Corporate name subject | <controlaccess><corpname> | Subject |
| Family name subject | <controlaccess><famname> | Subject |
| Topical subject* | <controlaccess><subject> | Subject |
| Geographical name subject | <controlaccess><geogname> | Subject |
| Genre format subject | <controlaccess><genreform> | Subject |
| Title subject | <controlaccess><title> | Subject |
| Originals location | <originalsloc> | Relation.IsFormatOf |
| Alternate Form Available | <altformavail> | Relation.HasFormat |
| Citations to Materials | <bibliography> | Relation.IsReferencedBy |
| Rules | <descrules>* | Relation.ConformsTo |
* Note that these two elements are located in the <eadheader> while the majority of the elements reside in the <archdesc>.
MARC
Unlike Dublin Core, MARC crosswalking is overtly expressed within the EAD template in this guide. This crosswalk is achieved through the use of the relatedencoding and encodinganalog attributes within the <archdesc> section of the finding aid. Below is listed the EAD elements and their respective MARC elements currently embedded in the NCEAD template.
| Area of description |
EAD element |
MARC field |
| Local call number |
<unitid> |
099 |
| Personal main entry |
<origination><persname> |
100 |
| Family main entry |
<origination><famname> |
100 |
| Corporate main entry |
<origination><corpname> |
110 |
| Title |
<unittitle> |
245 |
| Physical description |
<physdesc><extent> |
300 |
| Language note |
<langmaterial> |
546 |
| Biographical or historical note |
<abstract> (bioghist abstract) |
545 |
| Contents note |
<abstract> (scopecontent abstract) |
520 |
| Access note |
<accessrestrict> |
506 |
| Copyright note |
<userestrict> |
540 |
| Immediate acquisitions note |
<acqinfo> |
541 |
| Personal name subject |
<controlaccess><persname> |
600 |
| Corporate name subject |
<controlaccess><corpname> |
610 |
| Family name subject |
<controlaccess><famname> |
600 |
| Topical subject* |
<controlaccess><subject> |
650 |
| Geographical name subject |
<controlaccess><geogname> |
651 |
| Genre format subject |
<controlaccess><genreform> |
655 |
| Title subject |
<controlaccess><title> |
630 |
Note that this crosswalk is based upon the assumption that you are using a Library of Congree Subject Headings thesaurus to construct your topic terms (expressed in the source attribute). Use of a different controlled vocabulary would cahnge the MARC field value.
Note that all encodinganalog attributes reflect collection level description. NCEAD approaches catalog records as the summary description of the detailed description in an archival finding aid. The catalog record should provide enough information to summarize the collection's content and point to the EAD finding aid. Other MARC fields are available in the EAD document that are not directly expressed through the attributes. For instance, <eadheader><eadid> url attribute has the complete URL for the finding aid, which can be used in the 856 field of a MARC record.
If you are constructing or using a transformation script or other application to extract the MARC information from your EAD finding aids to create MARC records, recognize that the fixed fields, indicators, and subfields are not represented in the EAD record.
APPENDIX E: FILE MANAGEMENT FOR NCEAD
One of the most crucial aspects of an effective and operative EAD program is file management. This is because EAD is dependent on a series of interacting files that need to be in the right place largely because of the reliance on relative paths in the XML declaration.
NoteTab Software and the tools created by NCEAD complicate this matter because they require their own file management structures. This appendix demonstrates both the NoteTab and the EAD file management structures. Institutions using the NCEAD tools should use this structure. If you decide to deviate from the structure, it is important to understand that some NCEAD tools will not work unless they are adjusted to reflect your new file structure.
Relative Paths
Relative paths tell your computer where to go when it is looking for related files. If you follow the file management structure recommended below, the paths should be simple.
XML Declaration
This view of the xml declaration demonstrates several of the relative paths as they appear at the beginning of the <ead> document. The XML declaration, the code that appears before <ead> in your document, is the first use of relative paths. It points to the stylesheet, the dtd, address entities, and your institutional seal, using very specific addresses. This demonstrates the need for conscientious and accurate file management. For instance, if you move one file (i.e., your stylesheet) every single EAD document will "break" (give you an error) in your browser.
NoteTab File management
c:\notetab\
The above picture illustrates the folders that accompany the NCEAD toolkit that are to be placed in the c:\notetab\ directory. Note that NotePro.exe does not accompany the toolkit but must be purchased from NoteTab (http://www.notetab.com/). NoteTab lite can also be used. NoteTabPro was included in the illustration to demonstrate the relationship between the executable file for the software and the accompanying files.
| batch | Created by NCEAD, batch files for parsing and executing Saxon |
| ead | Created by NCEAD, see below |
| errors | Created by NCEAD, contains errors.txt for displaying parsing errors |
| Libraries | Supplied by NoteTab, contains libraries that are a series of "clips" for easy encoding in NoteTab programs |
| Saxon |
Created by NCEAD, XSLT processor |
| Templates | Supplied by NoteTab, contains templates that are a series of codes for beginning a document |
| Validator |
Created by NCEAD, Validates the xml document with the references dtd. |
c:\notetab\ead\
Within the ead folder, there are five folders that are part of the NCEAD Toolkit. These folders correspond to the relative paths expressed in the NCEAD template described above and within the templates and libraries as part of the NCEAD Toolkit.
| addresses | Includes address entities |
| dtds | Includes the ead.dtd, eadlocal.ent, and several other rules files |
| images | For digital archival object images |
| seals | Includes images for the table of contents and the NCEAD seal. This is where the institutional seal and other static images (such as a sound file image (WE HAVE THE SOUND FILE IMAGE AND THE AUDIO FILE IMAGE IN IMAGES)) should be saved. |
| styles | Includes stylesheets: eadbase.xsl, eadcust.xsl, eadshared.xsl, and eadfo.xsl |
| test.xml | This is an xml file to demonstrate where your EAD files would live in relation to the other files. It is not included in the toolkit. |
APPENDIX F: NCEAD DATES
Dates in NCEAD are expressed following the rules outlined in DACS (rule 2.4, pp. 24-28). It is strongly recommended that dates in the <eadheader>, <archdesc>, and <c01> are "normalized" or, using a normal attribute, translated into machine-readable format as specified by ISO 8601 (see Date Normalization and ISO 8601 above).
Dates however are not as straightforward as ISO 8601 would have us believe. There are several mechanisms for providing date information, including verbal expressions of dates, calendar variations, and professional judgment that all play roles in the assignment of date information to the materials we are describing. Below is represented a variety of different possibilities and normal attribute equivalents and other information that will help you in the process of providing accurate information about the numeric representation (ISO 8601) and the nature of the dates you are providing.
Three attributes are employed (definitions from the EAD Tag Library):
| normal | A consistent form, usually from a controlled vocabulary list, of the content of the following elements can be provided to facilitate retrieval…. In <date> and <unitdate>, the NORMAL attribute follows ISO 8601 Representation of Dates and Times, as specified in the DATEENCODING attribute in <eadheader>. |
| era | Period during which years are numbered and dates reckoned, such as A.D. or C.E. The value "ce" is the default. |
| certainty | The level of confidence for the information given in a <date> or <unitdate> element. |
Other date attributes include (these are used very infrequently and are not discussed below):
| datechar | Term characterizing the nature of dates, such as dates of creation, accumulation, or modification. Available only in <unitdate>. |
| calendar | System of reckoning time, such as the Gregorian calendar or Julian calendar. The value "Gregorian" is the default. Available in <date> and <unitdate>. |
| Dates |
normalization and notes |
| about 1900 | certainty="approximate" normal="1900" |
| 1930s | normal="1930/1939" |
| early 1900s | normal="1900/1904" |
| late 1950s | normal="1955/1959" |
| late 1800s - early 1900s | normal="1895/1904" |
| 1891 or 1892 | certainty="approximate" normal="1891/1892" |
| 1930s or 1940s | certainty="approximate" normal="1930/1949" |
| 1920s around World War I | normal="1920/1922" (note the year after world war I ended) |
| April 1984 | normal="198404" |
| Spring 1973 | normal="197303/197305" |
| 1990 January - 1990 February | normal="199001/199002" |
| 1990 January - Februay | normal="199001/199002" |
| January 1990 | normal="199001" |
| January 12, 1990 | normal="19900112" |
| January 13 - February 14, 1990 | normal="19900113/19900214" |
| January 1990 - March 1992 | normal="199001/199203" |
| March 12 1998 - April 1, 1999 | normal="19980312/19990401" |
| Spring 2000 | normal="200003/200005" |
| First quarter 2000 | normal="200001/200003" |
| 1980 February 18 - 1985 March 20 | normal="19800218/19850320" |
| 1980 February 1-20 | normal="19800201/19800220" |
| 1980-2000 and undated | normal="1980/2000" * note cannot account for undated in normalizing. It is not part of the <<unitdate>> statement. |
| undated | is not normalized. It is not part of the <unitdate> |
| 100 years before Christ | era="bce" normal="100" |
| 1965-1970, 1983 | normal="1960/1983" *alternatively, you could repeat the <unitdate> element, using the range for one and the single date for another. That way you could normalize each according to the standard. |
APPENDIX G: HOW DO I ENCODE...?
This section of the Best Practice Guidelines seeks to explain and provide examples of encoding for elements that are not commonly used and therefore not included in the NCEAD Encoding Guidelines above. In order to streamline the documentation, we have created a separate appendix that includes some suggested encoding for these optional aspects of finding aids.
What do I do with additional administrative information?
The encoding guidelines specify five elements in the administrative information section of the template. There are several other elements available in this section that should be used where appropriate. These elements include: <accruals>, <altformavail>, <appraisal>, <custodhist>, and <originalsloc>. For those institutions that wish to use these elements, standardized language and application is encouraged.
|
<accruals> -- This element informs the user of anticipated additions to the unit being described (see DACS rule 5.4, pp. 66-67). This can be especially useful for institutional or organizational archives finding aids, as deposits may be made on a regular basis. Use of this element would therefore inform the user when the next installment is expected. For manuscript collections that represent an on-going relationship with a living donor, this element might also be useful. |
| <altformavail> -- This element indicates the existence, location, and availability of copies or other reproductions of the material being described when they are available for use in an institution, or for loan or purchase, or available electronically (see DACS rule 6.2, pp. 71-72). References to microfilm copies should be in the format specified by the MARC standard (see example below). Include filmed date(s), if available, for microfilm. These dates can be a span, a single year, or a month and year, but do not tag with <unitdate>. If there's only one reel, call it Reel 1 and list contents, even if you use the phrase "Entire collection". If there are multiple reels, repeat <item> tags for each reel.
<altformavail> for Microfilm:
<altformavail encodinganalog="530">
<head>Alternate Form of Material</head>
<p>Microfilm copy (filmed [give date(s) if known; if not, delete this part]) available.</p>
<list type="simple">
<item>Reel 1: [contents, e.g. Folders 1-14]</item>
</list>
</altformavail> |
| <appraisal> -- This element provides information about the rationale for appraisal decisions, destruction actions, and disposition schedules that are relevant to the understanding and use of the material being described (see DACS, rule 5.3, pp. 63-65). This note should be constructed using a locally established protocol for communicating this kind of information. |
|
<custodhist> -- This element provides information about the custodial history of the material. Do not confuse this element with <acqinfo>, which refers to the immediate source of acquisition of the material by the institution. Note that <custodhist> should be used only in those circumstances where that history has an impact on the authenticity, integrity or interpretation of the materials (see DACS, rule 5.1, pp. 59-60). |
|
<originalsloc> -- This element indicates the existence and location of original materials if you have only copies in your repository (see DACS, rule 6.1, pp. 69-70). |
What if I have multi-part scope notes, biographical notes or subject headings?
<scopecontent>, <bioghist>, and <controlaccess> are recursive, which means that they can contain themselves. This recursiveness allows the creation of multiple sections within one larger section. For instance, in the <bioghist> portion of the collection-level description, you may want to provide separate biographical notes about individuals within a collection of family papers:
<bioghist>
<head>Biographical Notes</head>
<bioghist>
<head>Mickey Mouse</head>
<p>[biographical note for Mickey]</p>
</bioghist>
<bioghist>
<head>Minnie Mouse</head>
<p>[biographical note for Minnie]</p>
</bioghist>
<bioghist>
<head>Pluto</head>
<p>[biographical note for Pluto]</p>
</bioghist>
</bioghist>
If you need to use recursiveness in order to create subheadings such as in the example above, be sure that those subheadings are defined appropriately in your stylesheet.
Some institutions prefer to create multiple lists according to type of access point, i.e. personal names in one list, topical access points in another, etc. Although <controlaccess> is recursive, NCEAD recommends that multiple <list> elements be used instead.
<controlaccess>
<head>Online Catalog Terms</head>
<p>These and related materials may be found under the following headings in online catalogs.</p>
<list type="simple">
<head>Personal Names</head>
<item><persname source="lcnaf" encodinganalog="600"></persname></item>
</list>
<list type="simple">
<head>Corporate Names</head>
<item><corpname source="lcnaf" encodinganalog="610"></corpname></item>
</list>
<list type="simple">
<head>Subjects</head>
<item><subject source="lcsh" encodinganalog="650"></subject></item>
</list>
<list type="simple">
<head>Geographical Places</head>
<item><geogname source="lcsh" encodinganalog="651"></geogname></item>
</list>
</controlaccess>
Make sure that the <list><head> element is defined in your stylesheet. An alternative to <list><head> is to use <listhead> instead of <head> for these subheadings so that you can more directly control of the display. <listhead> would need to be defined in your stylesheet. This is only available within the <list> element.
How do I include a bibliography?
<bibliography> provides a formatted list of citations for works that are based on or about the materials being described. Current descriptive practice argues against this kind of information because of the problem of maintaining the bibliographies over time. but many legacy finding aids include citations as part of their description. There are a variety of different formats for bibliographical references; consult the EAD Tag Library and EAD Application Guidelines for more information. The NCEAD stylesheet is defined to list each <bibref> separately rather than relying on a <list> tag.
See DACS, rule 6.4, pp. 75-76
<bibliography>
<head>Bibliography</head>
<bibref><persname>[author]</persname>. <title render="italic">[title of monograph or serial]</title>. [Imprint information, Place: Publisher, date]</bibref>
</bibliography>
What do I do with oversize or separated materials?
Oversize materials present a unique problem in the creation of a detailed description of the material, and there are several options for accounting for them. In general you should:
- Include a <separatedmaterial> element that indicates that the material has been separated.
- Describe for the oversize materials in the intellectual location in the detailed description of the collection where they belong.
How can I encode a publications list?
Publications lists are often part of the <bioghist> section of a literary or scholarly manuscript collection. Publications lists can be encoded using <chronlist>, which provides <date> and <event> information. <date> would represent the date of publication and <event> can be used for the title of that publication.
<chronlist>
<chronhead>Publications List</head>
<chronitem>
<date>1925</date>
<event><title render="italic">The Great Gatsby</title></event>
</chronitem>
<chronitem>
<date>1934</date>
<event><title render="italic">Tender is the Night</title></event>
</chronitem>
</chronlist>
How do I account for more than one event in a given year in my chronology?
EAD has a grouping mechanism called <eventgrp> that allows you to list more than one <event> with a single corresponding <date>
<chronitem>
<date>1955</date>
<eventgrp>
<event>Graduated from college</event>
<event>Got married</event>
<event>Started working at the factory</event>
</eventgrp>
</chronitem>
Be sure that this option is defined in your stylesheet so that the display will look something like:
| 1955 |
Graduated from college
Got married
Started working at the factory |
| 1957 |
... |
This can be used for either a regular chronology or a publications list.
How do I encode an index?
Indexes can be found in both current and legacy finding aids. EAD has created a set of elements for encoding these indexes.
<index>
<head>Journal Index</head>
<p>Subjects represented throughout the journals.</p>
<indexentry>
<subject>Apples</subject>
<ref>Journal 1, p. 15</ref>
</indexentry>
<indexentry>
<persname>Appleseed, Johnny</persname>
<ref>Journal 1, p. 16</ref>
</indexentry>
</index>
Note that each entry in the index should be encoded in its own <indexentry>. If you have multiple terms with one reference, use <namegrp> to group those terms. In this case, the term "name" is used in a general sense meaning "term" rather than in a specific sense as in persname or corpname. If you have multiple reference points for one term, use ptrgrp. These grouping elements act exactly like <eventgrp> does above in "How do I account for more than one event in a given year in my chronology?"
Some indexes are more complex than a simple alphabetical list with reference pointers. <index> is recursive and allows you to create a sub-index from a larger index. <index> may also be included in <descgrp> if you have several layers to account for. Use the type attribute (<descgrp type="index">) in order to make clear what description group you are encoding.
Complex index example:
<descgrp type="indexlevel1">
<head>Baptismal Records Index, Methodist Episcopal Church, South</head>
<p>Arranged in three groupings: N.C. Conference, Western N.C. Conference, and Va. Conference, and then listed by county. Index was compiled in 1968 and does not include any additions to the collection since then.</p>
<descgrp type="indexlevel2">
<head>N.C. Conference</head>
<index>
<head>Bladen County</head>
<indexentry>
<name>Elizabeth Circuit, Church Registers Nos. 1 and 2, 1888-1930,</name>
<ref>Box NCC32</ref>
</indexentry>
</index>
<index>
<head>Beaufort County</head>
<indexentry>
<name>Bath Circuit, Church Records, 1860-1902,</name>
<ref>Box NCC32</ref>
</indexentry>
</index>
</descgrp>
</descgrp>
Note that you can use internal navigation and linking elements (see above) in the <ref> element. Remember, though that in creating internal linking you must include an id attribute to target with your <ref> element. This can require a great deal of work so that kind of encoding should be approached with caution.
|
