Buffalo Niagara Online Archive:
Best Practice Guidelines for Encoded Archival Description

Version 1.0, December 2006 (updated for online viewing, June 29, 2007)

Introduction

These guidelines are a work in progress. They were compiled by members of the EAD Working Group at the University at Buffalo (John Bewley, Karen Morse, Jessica Tanny and Karen Spencer) and the Albright-Knox Art Gallery (Susana Tejada, Gabriela Zoller) with the intent to align units at UB and the Albright Knox Art Gallery as well as to plan for the future inclusion of outside institutions. These standards will further the established collaborative EAD effort between the University at Buffalo and the Albright Knox Art Gallery which has been supported by three RBDB grants from the WNY Library Resources Council in 2005, 2006 and 2007.

These standards will be applied, tested and modified to meet the needs of a proposed regional repository of online finding aids. The ultimate goal is to improve access to archival collections documenting the cultural heritage of the Buffalo-Niagara region, hence the name, Buffalo Niagara Online Archive.

These guidelines are intended to supplement existing documentation for Encoded Archival Description and should be used in conjunction with the EAD Version 2.0 Tag Library (to which hypertext links have been provided in the HTML document), Describing Archives: A Content Standard, and in some cases, the EAD Application Guidelines, Version 1.0. The guidelines are based in large part on best practice documents from other sources, including the Library of Congress, Research Libraries Group (RLG) (available in PDF format), Northwest Digital Archives (NWDA), North Carolina EAD (NCEAD), and the Online Archive of California (OAC). Element definitions quoted directly from the EAD Version 2.0 Tag Library are noted as "Tag Library Definition".

XML Declaration

The XML Declaration describes the version of XML and the stylesheet that will be used in rendering the document

Tag example:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?xml-stylesheet type="text/xsl" href="./shared/styles/nameofstylesheet.xsl"?>

Status:

Required; Stylesheet statement Recommended

Repeatable:

Comments:

The first line will be stated verbatim.
The stylesheet declaration (2nd line) enables users of XML software to preview the finding aid as it will appear in browser display. It is recommended that this be omitted from the final version of the finding aid.
See Appendix 1 - File Naming

DOCTYPE Declaration and Declaration Subset

The DOCTYPE Declaration states the name, version, and location of the XML DTD (document type definition, or set of rules developed for a particular kind of document, such as an archival finding aid) to which the finding aid document adheres.

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.

Tag example:

<!DOCTYPE ead PUBLIC" +//ISBN 1-931666-00-8//DTD ead.dtd (Encoded Archival Description (EAD) Version 2002)//EN" "../shared/ead/ead.dtd"

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

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

(Note: line 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.)

Status:

Required; Entity statements recommended

Repeatable:

Comments:

Entities 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.
See Appendix 2 - Entities for more information about entities references and declarations.

ead

Encoded Archival Description

Outermost wrapping element for an EAD-encoded finding aid.

Tag example:

<ead>

Status:

Required

Repeatable:

eadheader

EAD Header

The EAD Header serves to identify the EAD instance unambiguously and to facilitate interchange of metadata about finding aids (NOT about the contents of collections). The header does not display to users but may be used in search and retrieval. It also serves an internal housekeeping, or version control function.

It contains metadata about the title, author, and creation date of the finding aid, as well as information about the language in which the finding aid is written and details about its encoding. These are recorded in four subelements that appear in the following order: <eadid>, <filedesc>, <profiledesc>, and <revisiondesc>.

Tag example:

<eadheader audience="external" countryencoding="iso3166-1" dateencoding="iso8601" langencoding="ISO 639-2b" repositoryencoding="iso15511" relatedencoding="DC" scriptencoding="iso15924">

Status:

Required

Repeatable:

Comments:

audience attribute set to"external" so data can be used to create title page. Setting the audience attribute to internal in order to protect data was eliminated as a possibility after considering NWDA's statement on the subject: "Once a finding aid passes beyond purely local or consortial control, it is possible (even likely) that information may be displayed to the public that the repository intended strictly for in-house access. For this reason, the NWDA strongly recommends that consortium members avoid the use of the audience attribute to protect purely in-house information. A local database or collection management tool, rather than a finding aid, is the safest home for such information."
Values for langencoding, countryencoding, dateencoding, and repositoryencoding attributes are set to their defaults values in the example above.
Relatedencoding attribute set to DC (Dublin Core) for <eadheader> and to MARC21 for <archdesc> based on prevalent practice.
Findaidstatus attribute will not be used for University at Buffalo finding aids. For reference purposes, the entire list of values is:
- unverified-partial-draft
- unverified-full-draft
- edited-partial-draft
- edited-full-draft

eadid

EAD Identifier

EAD identifier. The content of this element, together with its attributes, must uniquely identify the EAD finding aid document. The <eadid> for a finding aid remains constant no matter how many times the finding aid may be revised or expanded.

Tag Library Definition:

Two of the attributes, countrycode and mainagencycode, are required to make the <eadid> compliant with ISAD. In addition to these two attributes, it is recommended that repositories also use at least one of the following attributes: url, publicid, or identifier to make the <eadid> globally unique. publicid should be a Formal Public Identifier, url an absolute or relative address, and identifier a machine-readable unique identifier for the finding aid file.

Tag examples:

Example 1:

<eadid countrycode="US" mainagencycode="code" publicid="formal public identifier">document file name.xml</eadid>

Example 2:

<eadid countrycode="US" mainagencycode="NBuU-Mu" publicid="-//State University of New York at Buffalo:: Music Library//TEXT (US::NbuU-MU::Mus. Arc. 2.1::Morton Feldman Papers)//EN">ubmu2_1.xml
</eadid>

Status:

Required

Repeatable:

Comments:

Practice: University at Buffalo finding aids will use only publicid in <eadid>
See Appendix 1 - File Naming for information regarding URL vs. URN, etc.
See Appendix 3 - Publicid for information on how to create a Formal Public Identifier (FPI)
See Appendix 4 - University at Buffalo Naming Conventions for decisions regarding both visual and textual identities for the university and its units.
The mainagencycode attribute refers to the NUC code. For more information go to the MARC Code List for Organizations (http://lcweb.loc.gov/marc/organizations/).
Local values for mainagencycode attribute:
- NBuU-AR - University Archives
- NBuU-Mu - Music Library
- NBuU-L - Law Library
- NBuAK - Albright-Knox Art Gallery
Do NOT include the collection dates in the <publicid> unless necessary to distinguish between similarly named collections.

filedesc

File Description

File description is a wrapper element for information about the finding aid itself, NOT the collection contents. Information such as the finding aid's title, subtitle, filing title, author, and publisher are encoded in a series of subelements. Data from this area will be used to create a title page for the finding aid.

Tag example:

<filedesc>

Status:

Required

Repeatable:

Subelements:

Listed in recommended order. Encoding analogs listed below are required.

<titlestmt> Required
- <titleproper encodinganalog="title"> Required
- <subtitle> use only where necessary
- <author encodinganalog="contributor"> Required if available
- <sponsor encodinganalog="contributor"> Required if mandated by grant conditions

<editionstmt> Optional
- <edition>

<publicationstmt> Required
- <publisher encodinganalog="publisher"> Required
- <address> Required
- <date encodinganalog="date" normal="(ISO 8601 normalized date)"> Required

<notestmt>
<note> Use of the <note> element is strongly discouraged at this location in the finding aid.

titlestmt

Title Statement

Wrapper element to contain information about the finding aid's title(s), including title, subtitle, filing title, author, and sponsor (optional).

Tag example:

<titlestmt>

Status:

Required

Repeatable:

titleproper

Title Proper of the Finding Aid

Used to record formal title of the finding aid (not the title of the collection). Repeatable, it is also used to record a filing title.

Tag example:

<titleproper encodinganalog="title"> Finding Aid for the Leo Smit Score Collection,
<date era="ce" calendar="gregorian" type="inclusive" normal="1940/1998" encodinganalog="date"> circa 1940-1998 </date> </titleproper>

<titleproper type="filing" altrender="nodisplay"> Smit (Leo) Score Collection </titleproper>

Status:

<titleproper> is Required - titleproper element should be used twice, once for the formal title and once for the filing title
<date> within <titleproper> is required when available
<subtitle> is Optional

Repeatable:

<titleproper> Yes

Comments:

NOTE: <date> is stated as an element within <titleproper>, not outside, or separate from it.

If bulk dates are stated in addition to inclusive dates, state the bulk dates separately in a second <date>. For example, adding bulk dates to the example from above:

<titleproper encodinganalog="title">Finding Aid for the Leo Smit Score Collection,
<date era="ce" calendar="gregorian" type="inclusive" normal="1940/1998" encodinganalog="date">circa 1940-1998</date>
<date era="ce" calendar="gregorian" type="bulk" normal="1960/1969">bulk, 1960-1969</date>
</titleproper>

Use era, calendar, type, encodinganalog, and normal attributes for <date> within <title>. See Appendix 5 - Treatment of Dates for more information about encoding dates in EAD.
Filing titles will be created for every finding aid using the following format:
- "Smit (Leo) Score Collection" is the filing title for "Finding Aid for Leo Smit Score Collection, ca. 1940-1998"
- See Appendix 6 - Filing Titles for instructions on creation of filing titles
It is recommended, though not required, that terms reflecting estimation (ca.) be spelled out (circa) rather than abbreviated, as abbreviations may not be understood by all users. (DACS 2.4.12 footnote 30) It is recommended that names of months be spelled out in full.
Practice: Formal titles for University finding aids will be formatted as: Finding Aid for [Collection Name], date. Other terminology, such as Guide, Inventory, Register, should not be used for formal titles.

author

Author

Tag Library Definition:

Name(s) of institution(s) or individual(s) responsible for compiling the intellectual content of the finding aid. May include a brief statement indicating the nature of the responsibility, for example, archivist, collections processor, or records manager.

Note: Use the <creation> element found under <profiledesc> to designate the encoder of the finding aid. Use the <persname> or <corpname> element with the role attribute to designate the author in a Bibliographic Reference <bibref> citation. Use the <origination> element to designate the compiler, collector, or creator of the materials being described.

Tag example:

<author encodinganalog="contributor">Finding aid prepared by Blah Blah.</author>

Status:

Required when available

Repeatable:

Comments:

See Appendix 7 - Finding Aid Authors, Encoders, and Collection Processors for further information.

sponsor

Sponsor

Use the <sponsor> element to acknowledge support from granting agencies.

Tag example:

<titlestmt>
<sponsor>Encoding funded by the Foundation.</sponsor>
</titlestmt>

Status:

Optional

Repeatable:

editionstmt

Edition Statement

Tag Library Definition:

An optional subelement within the <filedesc> portion of the <eadheader> element that groups information about a finding aid edition by providing an <edition> element as well as a Paragraph element for narrative statements.

Tag example:

<titlestmt>Your Title</titlestmt>
<editionstmt>
<edition>2nd ed.</edition>
This edition reflects substantial additions to the collection in 1994.
</editionstmt>
</titlestmt>

Status:

Optional

Repeatable:

Comments:

There is no Dublin Core Element for edition so do not use encodinganalog attribute.

publicationstmt

Publication Statement

Tag Library Definition:

A wrapper element within the <filedesc> portion of <eadheader> for information concerning the publication or distribution of the encoded finding aid, including the publisher's name and address, the date of publication, and other relevant details. The <publicationstmt> may contain just text, laid out in Paragraphs , or it may include the <publisher>, <address>, and <date> elements, which allow for more specific tagging of a publisher's name and address, and the date of publication.

Tag example:

<publicationstmt>

Status

<publicationstmt> Required
- <publisher encodinganalog="publisher"> Required
- <address> Required
- <date encodinganalog="date" normal="(ISO 8601 normalized date)"> Required

Repeatable:

publisher

Publisher

When stated within <publicationstmt>, <publisher> contains the name of the party responsible for issuing the finding aid, with complete statement of address.

Tag example:

<publisher encodinganalog="publisher">State University of New York at Buffalo. University Archives</publisher>
<address> <addressline>420 Capen Hall</addressline>
<addressline>Buffalo, New York</addressline>
<addressline>14260-1625</addressline>
<addressline>United States</addressline>
<addressline>Phone: 716 645-2916</addressline>
<addressline>Fax: 716 645-3714</addressline>
<addressline>Email: lib-archives@buffalo.edu</addressline>
<addressline>URI: http://ublib.buffalo.edu/libraries/units/archives/</addressline></address>

Status:

Required

Repeatable:

<publisher> Yes; also available in bibliography
<address> Yes
<addressline> Yes

Comments:

See Appendix 4 - University at Buffalo Naming Conventions for background information on how to formulate the University and Unit names.
Full address included here to provide source for "title page" contact information. Data will be handled by an entity reference.

date

Date

Date of copyright of the finding aid.

Tag example:

Example 1:

Practice: University at Buffalo finding aids will use a full copyright statement as follows, with only the encodinganalog attribute applied:

© <date encodinganalog="date">2007</date>State University of New York at Buffalo. All rights reserved.

Example 2:

The other possibility for statement of copyright date alone is as follows:

<date calendar="gregorian" era="ce" encodinganalog="date" normal="1995">1995</date>

Status:

Required

Repeatable:

Comments:

See Appendix 5 - Treatment of Dates for more information about encoding dates in EAD.
Inclusion of a copyright statement for the contents of the finding aid should be placed in this element and the <date> element must be stated within a element as in the example above.

This ends the </filedesc> section

profiledesc

Profile Description

Tag Library Definition:

A subelement of the <eadheader> that bundles information about the creation of the encoded version of the finding aid, including the name of the agent, place, and date of encoding. The <profiledesc> element also designates the predominant and minor languages used in the finding aid.

Do not confuse with <filedesc>, which bundles such bibliographic information as the title, author, publisher, edition, and publishing series of the finding aid.

For newer finding aids, the author and encoder may be the same person or institution, but for most older finding aids, someone other than the author will be converting and encoding the document. The encoder should be listed in the <creation> subelement of <profiledesc>, while the author should be identified in the <titlestmt> subelement of <filedesc>.

Within <profiledesc> the Descriptive Rules <descrules> element can be used to specify the descriptive code or guidelines followed in creating the finding aid.

Tag example:

<profiledesc>

Status

Required

Repeatable:

creation

Creation

Tag Library Definition:

A subelement of the <profiledesc> portion of <eadheader> used for information about the encoding of the finding aid, including the person(s) or agency(ies) responsible for the encoding, the date, and the circumstances under which the encoding was done.

Tag example:

<profiledesc>
<creation>Finding aid encoded in HTML by Larry Tate; encoded in EAD by Jessica Tanny,
<date normal="2005" era="ce" calendar="gregorian" type="inclusive">2007. </date>
</creation>
</profiledesc>

Status:

Required

Repeatable:

Comments:

See Appendix 7 - Finding Aid Authors, Encoders, and Collection Processors for further information.
Practice: University at Buffalo will not apply the <date> element to dates within the <creation> element. The example above does not represent UB practice.

langusage

Language Usage

Tag Library Definition:

A subelement within the <profiledesc> portion of the <eadheader> that provides a statement about languages, sublanguages, and dialects represented in an encoded finding aid. The language(s) in which the finding aid is written can be further specified using the <language> subelement within <langusage>. For bilingual or multilingual finding aids, either identify each language in a separate <language> element, or mention only the predominant language.

Tag example:

<profiledesc>
<langusage>Finding aid written in
<language>English.</language>
</langusage>
</profiledesc>

Status:

Required

Repeatable:

Comments:

See information under <language> below for more complete tagging instructions.
Do NOT confuse with <langmaterial> used to record languages in the collection itself.
Use of the <langusage> element is recommended due to possibilities of searching finding aids at the global level rather than institutional level.
Practice: University at Buffalo University Archives finding aids will include the altrender attribute with a value set to "no display" for the <langusage> element.

language

Language

Tag Library Definition:

A subelement of <langusage> within the <profiledesc> portion of the <eadheader> that specifies the language or communication system in which the finding aid is written. For bilingual or multilingual finding aids, either identify each language in a separate <language> element, or mention only the predominant language. The langcode attribute can be used to provide the three-letter ISO 639-2b code for the language.

Also a subelement of <langmaterial> within <did>, where it specifies the language of the materials being described. In this instance, the langcode attribute may be used to provide the three-letter ISO 639-2b code which is the equivalent of the MARC 041 field.

Tag example:

<langusage>Finding aid written in
<language langcode="eng" encodinganalog="language">English</language>and
<language langcode="fre" encodinganalog="language">French.</language>
</langusage>

Status:

Required

Repeatable:

Comments:

Use as many <language> tags as necessary to encode languages predominantly represented in the text of the finding aid.
Set scriptcode attribute for <language> using ISO 15924 only if nonroman script needs to be noted.

descrules

Descriptive Rules

Tag Library Definition:

A subelement of Profile Description <profiledesc> for the enumeration of the rules, standards, conventions, and protocols used in preparing the description.

Do not confuse this element with the rules attribute in the <controlaccess> subelements, e.g., <persname>, <geogname>, and <title>, which are used to specify the descriptive rules, such as AACR2R, used in formulating individual access points.

Tag example:

<descrules>Finding aid prepared using DACS (<title render="italic">Describing Archives: A Content Standard</title>).
</descrules>

Status:

Optional

Repeatable:

Comments:

See DACS, Rule 8.1.4., p. 81
Not mandatory in legacy finding aids if the descriptive rules used by the original author(s) are not known.

This ends the </profiledesc> section

revisiondesc

Revision Description

Tag Library Definition:

An optional subelement of the <eadheader> for information about changes or alterations that have been made to the encoded finding aid. The revisions may be recorded as part of a <list> or as a series of <change> elements.

Tag examples:

Example 1:

<revisiondesc>
<change encodinganalog="583">
<date normal="1999-07">1999 July</date>
<item>Finding aid revised to incorporate additional materials in December 1998, and re-encoded by John Smith. </item>
</change>
</revisiondesc>

Example 2:

Record multiple changes in reverse chronological order, most recent first.

<revisiondesc>
<change encodinganalog="583">
<date normal="2004-05-18">2004-05-18</date>
<item>converted from EAD 1.0 to EAD 2002</item>
</change>
<change encodinganalog="583">
<date normal="2000-04">2000 April</date>
<item>linked to digital content</item>
</change>
</revisiondesc>

Status:

Optional, as applicable

Repeatable:

Comments:

<revisiondesc> provides information on the date and change of the electronic file.
Any changes made to the electronic document should be recorded in the <revisiondesc> portion of the <eadheader>, including conversion, additions, or general revisions.
Provide sufficient information about each major change to identify the nature of the change. Name or identify the parties responsible for changes to the electronic finding aid if different from those already recorded under <creation>.
Give year and month, or year, month, and date for each change; list the date before the change. List changes in reverse chronological order.
It is important to record this information as well in the <archdesc><descgrp type="admininfo"><processinfo> portion of the finding aid as well if that information would be useful for researchers.
Practice: University at Buffalo finding aids will apply the <date> element within <revisiondesc> with optional use of normal attribute for dates with months.

This ends the </eadheader> section

frontmatter

Frontmatter

The <frontmatter> element is a wrapper for publication-type structures, <titlepage> and <div>. The <titlepage> element groups bibliographic details about the encoded finding aid in an order and format optimized for display.

Standard practice discourages use of <frontmatter> in favor of generating title page displays from the EAD header. University at Buffalo will follow this practice.

Comments:

See Appendix 8 - Frontmatter for other prefatory content, including Contact info.
For full information about the use of <frontmatter> and its subelements to create title pages, see the Tag Library.

archdesc

Archival Description

The <archdesc> element is a wrapper for collection-level information. It contains all information related to the materials being described, whereas elements leading up to <archdesc> describe the finding aid document itself.

Tag example:

<archdesc level="collection" type="inventory" relatedencoding="MARC21">

These most significant subelements are listed in locally recommended order:

Element

Name

Local Label

Local status

<did>

Basic Description: The High-Level <did>

Collection Overview

Required

<descgrp type="userinfo">

Not in Tag Library

Information for Researchers

Required

<descgrp type="admininfo">

Administrative Information

Administrative Information

Required

<bioghist>

Biographical, Historical, or Chronological Note

Biographical Note, or Historical Note, or Chronology

Required

<scopecontent>

Scope and Content

Scope and Content Note

Required

<arrangement>

Arrangement

Arrangement

Required

<dsc>

Description of Subordinate Units

Container List (at top)

Required

<controlaccess>

Controlled Vocabulary Terms

Search Terms

Required

<descgrp type="add">
Containing:

<separatedmaterial>

<relatedmaterial>

Adjunct Descriptive Data

Separated Material
Related Material

None

Separated Material
Related Material

Optional

Element	Name	Local Label	Local status
<did>	Basic Description: The High-Level <did>	Collection Overview	Required
<descgrp type="userinfo">	Not in Tag Library	Information for Researchers	Required
<descgrp type="admininfo">	Administrative Information	Administrative Information	Required
<bioghist>	Biographical, Historical, or Chronological Note	Biographical Note, or Historical Note, or Chronology	Required
<scopecontent>	Scope and Content	Scope and Content Note	Required
<arrangement>	Arrangement	Arrangement	Required
<dsc>	Description of Subordinate Units	Container List (at top)	Required
<controlaccess>	Controlled Vocabulary Terms	Search Terms	Required
<descgrp type="add"> Containing: <separatedmaterial> <relatedmaterial>	Adjunct Descriptive Data Separated Material Related Material	None Separated Material Related Material	Optional

Status:

Required; with level attribute

Repeatable:

Comments:

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.
It is important to note that the level attribute is used at the high descriptive level of the <archdesc> element AND at the container level within finding aids. The list of possible values stated above covers both the high and container levels. Therefore, some of the terms are suitable to the higher level (collection, fonds, record group) and others more suitable to the container level (subgroup, series, file, item). This is made clear in the following quote from p. 13 of the Tag Library (in General Attributes Chapter, under "level" ):

This attribute is available in <archdesc>, where the highest level of material represented in the finding aid must be declared (e.g., collection, fonds, record group), and in <c> and <c01-12> (e.g., subgroup, series, file).
The relatedencoding attribute corresponds to encodinganalog attributes found throughout the <archdesc>.
Acceptable values for the type attribute are: guide, inventory, register, and accession.
Practice: University at Buffalo finding aids will use the value of "inventory" as a default for the type attribute.
Practice: The default value for the level attribute of <archdesc> for University at Buffalo finding aids is "collection" . Other possibilities include:
- recordgrp
- series

did

Descriptive Identification

Tag Library Definition:

A required wrapper element that bundles other elements identifying core information about the described materials in either Archival Description <archdesc> or a Component <c>. The various <did> subelements are intended for brief, clearly designated statements of information and, except for <note>, do not require Paragraphs to enter text.

The <did> groups elements that constitute a good basic description of an archival unit. This grouping ensures that the same data elements and structure are available at every level of description within the EAD hierarchy. It facilitates the retrieval or other output of a cohesive body of elements for resource discovery and recognition.

The <did> in <archdesc> is sometimes called the high level <did>, because it describes the collection as a whole. Consider using the following elements for this high level <did>: <head>, <origination>, <unittitle>, <physdesc>, <repository>, and <abstract>. The <unitid> and <physloc> elements are suggested if applicable to a repository's practice. A <did> within a Component <c> can be less complete, and might have only a <container> or <unitid> and a <unittitle>.

Tag example:

<did>< head>Collection Overview</head>

Subelements:

Listed in locally recommended order:

Element

Name

Local Label

Local status

<head>

Heading

Collection Overview

Required

<unittitle>

Title of the Unit

Title

Required

<unitdate>

Date of the Unit

NONE; displayed within collection title

Required

<unitid>

ID of the Unit

Collection Number

Required

<origination>

Origination

Creator

Required

<physdesc>

Physical Description

Extent

Required

<materialspec>

Material specific details

Details

Optional

<physloc>

Physical Location

Location (for collections located offsite)

Optional

<langmaterial>

Language of the Material

Language of Material

Required

<repository>

Repository

Repository (displayed as subunit, unit)

Required

<abstract>

Abstract

Abstract

Required

<note>

Note

Note

Optional

<daogrp>

Digital Archival Object Group

Digital Object

Optional

Element	Name	Local Label	Local status
<head>	Heading	Collection Overview	Required
<unittitle>	Title of the Unit	Title	Required
<unitdate>	Date of the Unit	NONE; displayed within collection title	Required
<unitid>	ID of the Unit	Collection Number	Required
<origination>	Origination	Creator	Required
<physdesc>	Physical Description	Extent	Required
<materialspec>	Material specific details	Details	Optional
<physloc>	Physical Location	Location (for collections located offsite)	Optional
<langmaterial>	Language of the Material	Language of Material	Required
<repository>	Repository	Repository (displayed as subunit, unit)	Required
<abstract>	Abstract	Abstract	Required
<note>	Note	Note	Optional
<daogrp>	Digital Archival Object Group	Digital Object	Optional

Status:

Required; with <head> subelement

Repeatable:

unittitle

Title of the Unit

Encode the collection title, formulated according to DACS Section 2.3.

Tag example:

<unittitle label="Title" encodinganalog="245$a">[Title of collection: John Doe Papers]</unittitle>

Status:

Required

Repeatable:

Comments:

Titles should be descriptive enough to stand as the primary access element (e.g., "Papers of Shirley Jackson" rather than "Papers") Give the collection title in direct order, unless your cataloging practice varies. 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 (Finding Aid of).
If the collection consists of only one type of material, that format may be reflected in the title. (For example, Allen Sapp Score Collection, ca. 1936-1992).
No punctuation should be supplied between <unittitle> and its component <unitdate>, although a space should be left before the <unitdate> for cases when both will display on one line. Experience shows that the placement of <unittitle> and <unitdate> information in the Collection Overview varies considerably in Library and outside implementation, and omission of punctuation between the two elements is least likely to result in inappropriate display. (LC)
Note that label attribute values' initial letters of elements occurring in the <did> are capitalized to ensure proper display with typical stylesheets.

unitdate

Date of the Unit

Dates of the materials comprising the collection; the dates may be given as inclusive, bulk, or both.
See Appendix 5 - Treatment of Dates for more information about encoding dates in EAD.

Tag example:

<unittitle>Title of the collection
<unitdate label="Dates" encodinganalog="245$f" type="inclusive" datechar="creation" certainty="approximate" normal="1950">circa 1950</unitdate>
</unittitle>

Labels/Heads:

Suggested content for dates, if dates are displayed on a separate line from the collection title:

Label="Dates" (may be used for any type)
Label="Span Dates" (type="inclusive")
Label="Bulk Dates" (type="bulk")

Status:

Required

Repeatable:

Comments:

Practice: <unitdate> will be stated within <unittitle>.
For a list of practices at other institutions, see the <unitdate> section of Appendix 5 - Treatment of Dates.
The date may be displayed on the same line as the title or on different lines depending on the stylesheet used.
Always give span and bulk dates in separate <unitdate> fields in order to supply the appropriate type, label, encodinganalog, and normal attributes.
Use only one <unitdate> when there is only one date or when there are no bulk dates to accompany the inclusive dates.
Do not put a comma between <unittitle> and <unitdate>, but make sure there is a space before the opening <unitdate> tag. It is equally possible to display the two elements on the same line (omitting the label for <unitdate>) and to put them on different lines (labeling the <unitdate>).
Always supply a label for dates. However, it is not necessary to supply a label for bulk dates if there is no desire to display them on a separate line from inclusive dates.
Set the type attribute for all <unitdate> elements. The most common value, "inclusive", can be set as the default value in creation and conversion tools.
Set the normal attribute to take advantage of date searching.
Set the datechar attribute with value "creation". Creation dates are "the date(s) at which the unpublished documents in the unit being described were originally created or captured in some material form," in contrast with other categories such as dates of reproduction or of publication. Available values are creation, recordkeeping, publication, broadcast.

unitid

ID of the Unit

Tag Library Definition:

Any alpha-numeric text string that serves as a unique reference point or control number for the described material, such as a lot number, an accession number, a classification number, or an entry number in a bibliography or catalog. An important subelement of the Descriptive Identification <did>, the <unitid> is primarily a logical designation, which sometimes secondarily provides location information, as in the case of a classification number. Use other <did> subelements, such as <physloc> and <container>, to designate specifically the physical location of the described materials.

Do not confuse <unitid>, which relates to the archival materials, with <eadid>, which is used to designate a unique identification string for the finding aid.

Although not required, the countrycode and repositorycode attributes should be used in <unitid> at the <archdesc><did> level to comply with ISAD(G) element 3.1.1. The repositorycode attribute specifies the ISO 15511 code for the institution that has custody of the materials described, while countrycode provides the ISO 3166-1 code for the country in which that institution is located. The identifier attribute should contain a machine-readable unique identifier, containing a value similar to the text in the <unitid> element. The type attribute may be used to indicate the system from which the <unitid> was derived, e.g., accessioning system, record group classification scheme, records retention scheduling system, etc.

Tag example:

<unitid label="Collection number" encodinganalog="099" countrycode="US" repositorycode="NBuU-AR">4/7/19</unitid>

Labels/Heads:

Label should be appropriate to content. Do not supply label if unitid element has no content.

label="Collection Number" (Default for University at Buffalo)
label="Call No."
label="ID No."

Status:

Required

Repeatable:

Comments:

Institutions that do not assign a collection or other control number to their collections should enter the text "Consult repository."

origination

Origination

Tag Library Definition:

Information about the individual or organization responsible for the creation, accumulation, or assembly of the described materials before their incorporation into an archival repository. The <origination> element may be used to indicate such agents as correspondents, records creators, collectors, and dealers. Using the label attribute may help identify for a finding aid reader the role of the originator, e.g., "creator," "collector," or "photographer." It is also possible to set the role attribute on the name elements that are available within <origination>, i.e., <corpname>, <famname>, <name>, and <persname>.

The choice and number of names should be determined according to DACS Chapter 9.

The form of the name(s) should be taken from a standard naming authority file, such as the Library of Congress Name Authority File or Union List of Artists' Names. If a name does not appear in an authority file, establish the name according to a content standard such as AACR2.

See DACS rule 2.6, p. 33 and Chapter 9, pp. 89-92

Tag example:

<origination label="Creator">
<persname encodinganalog="100" source="lcnaf" role="creator">Feldman, Morton, 1926-1987</persname>
</origination>

Labels/Heads:

Label="Creator" -- (default for University at Buffalo finding aids)
Label="Collector"

Encoding Analog:

Encodinganalogs should be set for the subelement <persname>, <famname>, or <corpname> with the following values: 100 (personal or family name main entry), 110 (corporate name main entry), 600 (personal/family name subject entry), 700 (personal/family name added entry), 710 (corporate name added entry).

Other Attributes:

It is recommended that the MARC Code List for Relators be used as a source for terms used as values in the role attribute. Use role="collector" for <persname>, <famname>, or <corpname> when label="Collector" is used in <origination>
Use the source attribute for <persname>, <famname>, or <corpname> in <origination> (value is usually "LCNAF")
If the name was not found in the LC authority file but was formulated using DACS or AACR2 rules, enter "dacs" or "aacr2" in the rules attribute.

Subelements:

Use of one of the following subelements is required:

<persname>
<famname>
<corpname>

Status:

Required where applicable

Repeatable:

Comments: (LC)

Use the form of name found in the LC Name Authority File as it appears (usually indirect order), with the content of all subfields included, including role ($e) when given. See Example 1 below.
When there are multiple originators, but one person or group can be identified as the primary originator, provide the first name (1xx in catalog record) under origination, and include secondary originators. Consult cataloging rules for guidance in making this determination. See Example 2 below.
When two or more originators are of equal importance (i.e., catalog record has title main entry with 7xx entry for each originator), record each originator within an <origination> tag with appropriate attributes. See Example 3 below. If there are two originators known to be of equal importance but the catalog entry selects one as main entry, record each originator within an <origination> tag with encodinganalog attribute set to "100".
When there are a number of originators of equal importance, it may be more appropriate to omit the origination field in Collection Summary and give the originator's names only in the <controlaccess> area. See Example 4 below.
When no originator can be identified, usually an artificial collection (a topical or format-oriented collections aggregated by the institution), where the catalog record has title main entry, there will be no <origination> and no creator identified in the <controlaccess> area). See Example 5 below.
Use the role attribute to describe the role of the named party in relation to the collection.

Additional tagging examples:

Example 1: One originator (cataloging record has 1xx field for originator)

<origination label="Collector">
<persname encodinganalog="100" role="collector" source="LCNAF">Cushing, Caleb, 1800-1879</persname>
</origination>

Example 2: Multiple originators, but one predominates

<origination label="Creator">
<persname encodinganalog="100" source="LCNAF">Roosevelt, Kermit, 1889-1943</persname>
</origination>

Example 3: Bob Fosse/Gwen Verdon Collection: title main entry with 7xx entry for each originator

<origination label="Creator">
<persname encodinganalog="700" source="LCNAF">Fosse, Bob, 1927-1987</persname>
</origination>
<origination label="Creator">
<persname encodinganalog="700" source="LCNAF">Verdon, Gwen</persname>
</origination>

Example 4: No <origination>; family names recorded in <controlaccess> only

<unittitle>Key-Cutts-Turner family papers, 1808-1975</unittitle>

Example 5: No <origination> given

<unittitle label="Title">California travel diaries, 1849-1851</unittitle>

Selected Relator terms:

Associated name [asn]: Use for a person or organization associated with or found in an item or collection, which cannot be determined to be that of a Former owner [fmo] or other designated relator indicative of provenance.
Collaborator [clb]: Use for a person or organization that takes a limited part in the elaboration of a work of another person or organization that brings complements (e.g., appendices, notes) to the work.
Collector [col]: Use for a person or organization who has brought together material from various sources that has been arranged, described, and cataloged as a collection. A collector is neither the creator of the material nor a person to whom manuscripts in the collection may have been addressed.
Contributor [ctb]: Use for a person or organization whose work has been contributed to a larger work, such as an anthology, serial publication, or other compilation of individual works. Do not use if the sole function in relation to a work is as author, editor, compiler or translator.
Correspondent [crp]: Use for a person or organization who was either the writer or recipient of a letter or other communication.
Creator [cre]: Use for a person or organization responsible for the intellectual or artistic content of a work.
Originator [org]: Use for a person or organization performing the work, i.e., the name of a person or organization associated with the intellectual content of the work. This category does not include the publisher or personal affiliation, or sponsor except where it is also the corporate author. Includes a person designated in the work as investigator or principal investigator.

physdesc

Physical Description

Tag Library Definition:

A wrapper element for bundling information about the appearance or construction of the described materials, such as their dimensions, a count of their quantity or statement about the space they occupy, and terms describing their genre, form, or function, as well as any other aspects of their appearance, such as color, substance, style, and technique or method of creation. The information may be presented as plain text, or it may be divided into the <dimensions>, <extent>, <genreform>, and <physfacet> subelements.

Tag example:

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

Status:

Required at high-level <did>

Repeatable:

Comments:

See Appendix 9 - Physical Description for more examples
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>
The content of the encodinganalog attribute should be "300" without subfields, as the MARC subfields do not map precisely to subelements of <physdesc>.
Use separate <physdesc> element sets to accommodate physical description information for different formats included in the collection (e.g., one <physdesc> for number of cubic feet of papers, another <physdesc> for number of photographic prints).
Use additional <extent> tags with a type attribute="dao" to encode a statement specifying the number of digital objects represented within the finding aid.
Values for the unit attribute include, but are not limited to:
- items
- linear feet
- cubic feet
- containers
- oversize containers
Practice: recommended practice is to use multiple <extent> statements to encode the different descriptions of the collection (linear feet, containers, items, etc.)

genreform

Genre/Physical Characteristic

Tag Library Definition:

A term that identifies the types of material being described, by naming the style or technique of their intellectual content (genre); order of information or object function (form); and physical characteristics. Examples include: account books, architectural drawings, portraits, short stories, sound recordings, and videotapes.

All genres and forms of material mentioned in a finding aid do not have to be tagged. One option is to tag those <genreform> terms for which access other than basic, undifferentiated keyword retrieval is desired. Use of controlled vocabulary terms is recommended to facilitate access to the information within and across finding aid systems. The <genreform> element may be used in text elements such as . To indicate a function with major representation in the materials being described, nest <genreform> within the <controlaccess> element. To associate a <genreform> term with more detailed physical characteristics, use <genreform> within the <physdesc> or <physfacet> elements.

Use the source attribute to specify the vocabulary from which the term has been taken. The normal attribute can be used to provide the authority form of a term that has been encoded with <genreform> in narrative text, e.g., within a paragraph. The authfilenumber attribute can be used to identify a link to an authority file record that has more information about the term or cross references for alternative forms of a genre term.

Status:

Required as part of <controlaccess> (UB)

Repeatable:

Comments:

See Appendix 9 - Physical Description
Practice: <genreform> will only be used within <controlaccess> where controlled vocabulary can be applied.

physfacet

Physical Facet

Tag Library Definition:

A <physdesc> subelement for information about an aspect of the appearance of the described materials, such as their color, style, marks, substances, materials, or techniques and methods of creation. It is used especially to note aspects of appearance that affect or limit use of the materials. It generally should not be used for aspects of physical description that are covered more directly by the <extent>, <dimensions>, and <genreform> elements, although use of <genreform> may be appropriate for further specification within some <physfacet> instances.

The type attribute may be used to specify which aspect of the physical appearance is being designated.

Tag example:

<physdesc>
<extent>3 daguerreotypes,</extent>
<physfacet>hand colored</physfacet>
</physdesc>

Status:

Optional

Repeatable:

Comments:

See Appendix 9 - Physical Description
There are too many potential uses for <physfacet> to summarize here. Look for examples in other EAD finding aids.
See the Tag Library for the full range of attributes available for this element.
Practice: <physfacet> will only be used at the container level.

dimensions

Dimensions

Tag Library Definition:

A subelement of <physdesc> for information about the size of the materials being described; usually includes numerical data. Measurements may be expressed in any convenient unit. Attributes may be used when the unit of measurement or type of dimension is not clear in the finding aid text. The unit attribute specifies the kind of measurement, for example, "inches" or "meters". The type attribute specifies the kind of dimensions being measured, for example, "height" or "circumference". Multiple dimensions, for example, height-by-width, can be tagged in a single <dimensions> element or in separate <dimensions> with distinctive attribute values.

Tag example:

<c01>
<did>
<unittitle>Cartuarium vetus</unittitle>
<physdesc>
<extent>3 paper leaves; 1 parchment on paper leaf; 175 leaves, 4 inserts, 2 schedules, parchment; 4 paper leaves</extent>
<dimensions>approximately 230 mm x 163 mm.</dimensions>
</physdesc>
</did>
</c01>

Status:

Optional

Repeatable:

Comments:

See Appendix 9 - Physical Description
For guidance on stating the measurements of particular types of materials (such as the height and width of photographs or the diameter and tape width of reel-to-reel audio tapes), consult the appropriate content standards listed in DACS, Appendix B.
Practice: <dimensions> will only be used at the container level.

materialspec

Material Specifications

Tag Library Definition:

Data which are unique to a particular class or form of material and which are not assigned to any other element of description. Examples of material specific details include mathematical data, such as scale for cartographic and architectural records, jurisdictional and denominational data for philatelic records, and physical presentation data for music records.

Tag example:

<materialspec label="Scale" encodinganalog="255">1:100,000</materialspec>
<materialspec label="Projection" encodinganalog="255">Modified Polyconic</materialspec>

Status:

Optional

Repeatable:

Comments:

Most likely use is at the container level.

physloc

Physical Location

Tag Library Definition:

Information identifying the place where the described materials are stored, such as the name or number of the building, room, stack, shelf, or other tangible area.

Do not confuse with <container>, which is used to identify the cartons, boxes, reels, folders, and other storage devices used to hold the described materials. Also do not confuse with <repository>, which is used to identify the institution or agency responsible for providing intellectual access to the described materials.

Like all Descriptive Identification <did> subelements, the <physloc> element has a label attribute which may be used to provide a readily understandable heading for the element's content. The type attribute may also be used to identify the nature of the storage location. For security reasons, the audience attribute value may be set to "internal" to shield public access to storage location information.

Tag examples:

Example 1:

<physloc label="Location" encodinganalog="852$z">Bernice K. Noble Papers, 1976-2003 (bulk 1994-2003) are stored off-site. Please contact Special Collections several days in advance of your visit to assure that the containers you wish to consult will be available when you arrive.</physloc>

Example 2:

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

Status:

Optional

Repeatable:

Comments:

Although this element was designed to hold a shelf location for the collection being described, because such information is continually changing as repositories manage their collections, a better long-term solution is to maintain this information separately. This eliminates the need to continually update the finding aids, or to have to update the shelf locations in both MARC records and finding aids. See DACS rule 4.2.6, pp. 46-47
An alternative use of the element can be seen in the second example above.
Practice: Any general, collection-level statements about a need to contact the institution for more information regarding the physical location of a collection should be stated in <userestrict>.

langmaterial

Language of the Material

A prose statement naming the language(s) of the materials in the collection or unit. One or more language name(s) are enclosed in nested <language> tags.

Do NOT confuse with <langusage> in <eadheader>, which describes the language(s) of the finding aid.

Tag examples:

Example 1:

<langmaterial label="Language of Material" encodinganalog="546">Collection material in
<language encodinganalog="041" langcode="eng">English</language>and
<language encodinganalog="041" langcode="ger">German.</language>
</langmaterial>

Example 2:

If the collection, such as a photograph collection, contains no associated text, state that fact in <langmaterial> using wording similar to the following:

<langmaterial>No textual materials are included in the collection.</langmaterial>

Status:

Required

Repeatable:

Comments:

If more than one language is represented in a collection, the <language> element within <langmaterial> should be repeated for each language.
Set the scriptcode attribute for <language> within <langusage> and <langmaterial> using ISO 15924 only if nonroman script needs to be noted. See DACS rule 2.2, p. 16
Practice: Include <langmaterial> on every finding aid, using example above when no textual materials are included in the collection. Text of the statement is free so it can include qualifications when necessary.

repository

Repository

Tag Library Definition:

The institution or agency responsible for providing intellectual access to the materials being described. The <corpname> element may be used within <repository> to encode the institution's proper name.

Although the repository providing intellectual access usually also has physical custody over the materials, this is not always the case. For example, an archives may assume responsibility for long-term intellectual access to electronic records, but the actual electronic data files or systems may continue to reside in the office where they were created and maintained, or they may be held for long-term storage by a unit such as a data library that is able to provide the appropriate technical facilities for storage and remounting. When it is clear that the physical custodian does not provide intellectual access, use <physloc> to identify the custodian and <repository> to designate the intellectual caretaker. When a distinction cannot be made, assume that the custodian of the physical objects also provides intellectual access to them and should be recognized as the <repository>.

Tag examples:

Example 1:

<repository label="Repository" encodinganalog="852">
< corpname>State University of New York at Buffalo.
<subarea>University Archives</subarea>
</corpname>
</repository>

Example 2:

<repository label="Repository" encodinganalog="852">
<corpname>
<subarea>Charles B. Sears Law Library </subarea>
State University of New York at Buffalo</corpname>
</repository>

Example 3:

<repository label="Repository" encodinganalog="852">
<corpname>Albright-Knox Art Gallery</corpname>
<address>
<addressline>Buffalo, New York</addressline>
</address>
</repository>

Status:

Required

Repeatable:

Comments:

The <repository> element should indicate the holding repository of the collection. Use the authoritative form of the corporate name for repository.
DACS requires that the location of the repository (but not necessarily the complete address) be provided if not obvious from the name of the repository. If the location (city and state) of the repository is not obvious from the repository's name, provide it in <addressline>. This is for the convenience of users who may be searching a multi-national database.
Note that location information of the repository is available through the <eadheader> publication statement and is not included in this element.
Practice: State University name as "State University of New York at Buffalo. Unit name", except for the Law Library which is demonstrated above.

abstract

Abstract

Tag Library Definition:

A very brief summary of the materials being described, used primarily to encode bits of biographical or historical information about the creator and abridged statements about the scope, content, arrangement, or other descriptive details about the archival unit or one of its components.

Within the <archdesc><did>, the <abstract> is often extracted from the longer descriptions found in <bioghist> and <scopecontent>. Its purpose is to help readers identify quickly those materials they need to explore at greater length.

Use of the type and encodinganalog attributes on <abstract> may assist in extracting information for such MARC equivalents as summary note (520$a) and biographical or historical data (545$a). The langcode attribute can be used when abstracts are provided in more than one language.

Tag example:

<abstract label="Abstract" encodinganalog="520">Professional and personal correspondence, speeches, articles and memorabilia of Samuel P. Capen, first director of the American Council in Education (1919-1922); first full-time Chancellor of the University of Buffalo (1922-1950); and spokesman for academic freedom and educational reform.</abstract>

Status:

Required

Repeatable:

Comments:

The <abstract> element at the top level of <did> can be harvested to display in a brief format list of finding aid titles retrieved by a search. For that reason, it is recommended that <scopecontent> be used at the component level (e.g.," folder" or" item") rather than <abstract>.
A typical abstract may consist of the following information:
- Identification of creator
- 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.
Practice: Use <abstract> only at the high-level <did>. Do not use at the container level.

note

Note

Generic explanatory text. In Collection Overview, may be used to indicate that the materials described in the high-level <did> are a component of a larger body of materials not described by the finding aid.

Tag example:

<note label="Note" encodinganalog="500">
Both the finding aid and the collection itself are currently to be considered works in progress. Rather than wait until the entire collection is processed before making it generally available to researchers--our usual practice--we have decided to make each series available as it is completed; the music will be the last series in the collection to be processed.
</note>

Status:

Optional

Repeatable:

Comments:

Use only where necessary to explain exceptional circumstances.

daogrp

Digital Archival Object Group

Tag Library Definition:

A wrapper element that contains two or more related Digital Archival Object Locations <daoloc> that should be thought of as a group and may share a single common Digital Archival Object Description <daodesc>. They may also form an extended link group to enable a set of multidirectional links. The <dao>, <daogrp>, and <daoloc> elements allow the content of the described materials to be incorporated in the finding aid.

Tag example:

<daogrp>
<daodesc>
<head>Image Sampler</head>
Images from the Ella Baker Papers 
</daodesc>
<daoloc href="baker_2007.jpg">
<daodesc>
Ella Baker, head-and-shoulders portrait
</daodesc>
</daoloc>
</daogrp>

Status:

Optional

Repeatable:

Comments:

In the Collection Overview area, use for "image samplers", or other visual or multimedia overviews of the collection consisting of selected images or other digital versions of collection material.
Use <daogrp>, <daoloc>, and <dao> only to point to electronic versions of material from the collection being described; links to external materials will be made using other tags, and are not appropriate for the <archdesc>< did>.
<dao> elements may be used at many points in the finding aid, both at the component level (container list) and in the other major components. (<bioghist>, <scopecontent>).

descgrp type="userinfo"

Description Group (User Information)

Definition:

This wrapper element assembles background information that is essential for users.

Elements listed below fall into several general groups, which may be thought of describing the collection in the following terms:

What users can do with it: <userestrict>, <accessrestrict>
How to cite: <prefercite>

Subelements:

Listed in locally recommended order.

Element

Name

Local Label

Local status

<head>

Heading

Information for Users

Required

<prefercite>

Preferred Citation

Preferred Citation

Required

<accessrestrict>

Conditions Governing Access

Terms of Access and Use

Required

<userestrict>

Conditions Governing Use

Copyright

Required

Status:

Required as <descgrp type="userinfo">

Repeatable:

No, not as <descgrp type="userinfo">; <descgrp> itself is repeatable.
Alternative, and more standard practice, is to combine the contents of this <descgrp> with the following one as one large <descgrp type="admininfo"> Use of type="userinfo"is local Practice.

prefercite

Preferred Citation

Tag Library Definition:

Information about how users should identify the described materials when referring to them in published credits. Generally the repository or agent responsible for providing intellectual access to the materials will supply users with a recommended wording or prescribed format for structuring references to the described materials in bibliographies, footnotes, screen credits, etc.

Do not confuse with Archival Reference <archref> or Bibliographic Reference <bibref> which are used to cite and/or link to materials other than those described in the finding aid.

Tag example:

<prefercite encodinganalog="524">
<head>Preferred Citation</head>
[Description and dates], Box-Folder#, 3/5/897, Campus Unrest: Research conducted by Dean G. Pruitt and James Gahagan, Social Psychology Department, 1967-1972, 1975, University Archives, State University of New York at Buffalo.

<extref entityref="citations" show="new" actuate="onrequest">For additional information, see the Archives' preferred citations instructions.
</extref>

</prefercite>

Status:

Required

Repeatable:

Comments:

The default language for <prefercite> may be changed to suit individual institutions or collections as needed.
Note that "[Description and dates]" is part of the preferred citation statement. The other bracketed information should be filled in for the appropriate collection.
Do not use this element for bibliographic citations of published material (MARC encoding analog 510); these should be tagged using Bibliographic Reference <bibref>.
It is also possible to make this a standard statement that refers to a boilerplate text about formulating citations, either through the use of an entity statement or reference to another online document (or both) (See Example above). See DACS, rule 7.1.5, pp. 78-79

accessrestrict

Conditions Governing Access

Tag Library Definition:

Information about conditions that affect the availability of the materials being described. May indicate the need for an appointment or the nature of restrictions imposed by the donor, legal statute, repository, or other agency. May also indicate the lack of restrictions.

Do not confuse with Conditions Governing Use <userestrict>, which designates information about limitations on the use of the described materials after access has been granted.

Tag example:

<accessrestrict encodinganalog="506">
<head>Terms of Access and Use</head>
Leon E. Farhi Papers, 1964-2003 are open for research.
</accessrestrict>

Status:

Required

Repeatable:

Comments:

If materials have no restrictions on access, a statement such as the following should be used: "Collection is open for research."
Text should be enclosed in paragraph tags; is repeatable.
Physical access to the collection may be restricted due to privacy concerns, donor restrictions, or other factors.
<legalstatus> is available within <accessrestrict> for any statement regarding a statutorily-defined status of the material. This tag should be used after a general access restriction statement. See DACS rule 4.1, pp. 43-45

userestrict

Conditions Governing Use

Tag Library Definition:

Information about conditions that affect use of the described materials after access has been granted. May indicate limitations, regulations, or special procedures imposed by a repository, donor, legal statute, or other agency regarding reproduction, publication, or quotation of the described materials. May also indicate the absence of restrictions, such as when copyright or literary rights have been dedicated to the public. Do not confuse with Conditions Governing Access <accessrestrict>, which designates information about conditions affecting the availability of the described materials. Preferred Citation <prefercite> may be used in conjunction with <userestrict> to encode statements specifying how the described materials should be referenced when reproduced, published, or quoted by patrons.

Tag examples:

Example 1:

<userestrict encodinganalog="540">
<head>Copyright</head>
Copyright of papers in the collection may be held by their authors, or the authors' heirs or assigns. Researchers must obtain the written permission of the holder(s) of copyright and the University Archives before publishing quotations from materials in the collection. Most papers may be copied in accordance with the library's usual procedures unless otherwise specified.
</userestrict>

Example 2:

<userestrict>
<head>Copyright</head>
Copyright is held by The State University of New York at Buffalo, University Archives. Copyright in other papers in the collection may be held by their authors, or the authors' heirs or assigns. Researchers must obtain the written permission of the holder(s) of copyright and the University Archives before publishing quotations from materials in the collection. Most papers may be copied in accordance with the library's usual procedures unless otherwise specified.
</userestrict>

Status:

Required

Repeatable:

Comments:

Provides information about copyright status or other conditions that affect the use of a collection after access has been provided. In addition to copyright status, this may include limitations or special considerations imposed by the repository, donor, legal statute, or other agency regarding reproduction, publication, or quotation of the described materials.
Text should be enclosed in paragraph tags; is repeatable.
If no use restrictions have been placed on the collection, repositories are strongly encouraged to state that fact in <userestrict>.
Use restriction information affects how the materials may be used after physical access has been granted. Copyright information forms the core of this restriction. Here are a few examples of basic default text often used in copyright statements:
- Copyright is retained by the authors of items in these papers, or their descendants, as stipulated by United States copyright law.
- The State University of New York at Buffalo does not own copyright to this collection. Individuals obtaining materials from the University Archives, State University of New York at Buffalo are responsible for using the works in conformance with United States copyright law as well as any donor restrictions accompanying the materials.
- Literary rights to specific documents are retained by the authors or their descendants in accordance with U.S. copyright law.
- The copyright interests in the Edgar Hatcher Papers have not been transferred to Duke University. For further information, see the section on copyright in the Regulations and Procedures of the Rare Book, Manuscript and Special Collections Library or consult a reference archivist.
- Copyright for Official University records is held by the State University of New York at Buffalo; all other copyright is retained by the authors of items in these papers, or their descendants, as stipulated by United States copyright law.
- Copyright for materials resides with the creators of the items in question, unless otherwise designated.
Depending upon the collection, a shorter or longer notice may be necessary. Additional paragraphs may be added to the <userestrict> element as needed. See DACS rule 4.4, pp. 50-53. In particular, note Copyright Status commentary on pp. 50-51 for clarification on the importance and structure of copyright information.
For more information on U.S. Copyright see the Digital Libraries and Archives copyright page at Virigina Tech. See also Copyright Term and the Public Domain in the United States, compiled by Peter Hirtle, Cornell University.

This ends the /descgrp type="userinfo" section

descgrp type="admininfo"

Descriptive Group (Administrative Information)

A wrapper element that assembles background information about administrative aspects of the collection, including acquisition information, processing information, custodial history, and information about accruals.

Elements listed below fall into several general groups, which may be thought of describing the collection in the following terms:

Where it came from
What the repository did with it
Formats available for use

Subelements:

Listed in locally recommended order.

Element

Name

Local Label

Local status

<head>

Heading

Administrative Information

Required

<acqinfo>

Acquisition Information

Acquisition Information

Required

<custodhist>

Custodial History

Custodial History

Optional

<accruals>

Accruals

Accruals and Additions

Optional

<altformavail>

Alternative Form Available

Alternate Forms

Optional

<originalsloc>

Location of Originals

Location of Originals

Optional

<processinfo>

Processing Information

Processing Information

Required

<appraisal>

Appraisal Information

Appraisal Information

Optional

<phystech>

Physical Characteristics and Technical Requirements

Physical Characteristics and Technical Requirements

Optional

Status:

Required as <descgrp type="adminfo">

Repeatable:

No, not as <descgrp type="adminfo">; <descgrp> itself is repeatable.

acqinfo

Acquisition Information

Tag Library Definition:

The immediate source of the materials being described and the circumstances under which they were received. Includes donations, transfers, purchases, and deposits.

After opening a Paragraph within <acqinfo>, optional subelements may be used to tag separately such common acquisition information as the name of the source, e.g., <persname> or <corpname>; the <date> the materials were received; or the accession number <num> assigned to them. The <address> element could be used to document the address of the source, and the audience attribute could be set to" internal," if the address information should only be available to authorized staff. Note that the accession number may also serve as the <unitid> and be encoded as such within a <did>.

For detailed information about items acquired and then subsequently alienated from the materials being described, the Separated Material <separatedmaterial> element can be used. It designates items related by provenance that have been physically removed from the materials being described.

The Custodial History <custodhist> element can be used for information about the chain of ownership before the materials reached the immediate source of acquisition.

Tag example:

<acqinfo encodinganalog="541">
<head>Acquisition Information</head>
The collection was given to the Music Library by the estate of Christopher Nobody.
</acqinfo>

Status:

Required

Repeatable:

Comments:

If this information can not be disclosed or is not readily available use "Check Repository" as default text.
Practice: Application of <persname>, <corpname>, etc. at this level should be reserved for exceptional circumstances. University at Buffalo finding aids will not apply <date> element within <acqinfo>. Neither will sensitive information about donors, such as addresses, be included in University at Buffalo finding aids.

custodhist

Custodial History

Tag Library Definition:

Information about the chain of ownership of the materials being described, before they reached the immediate source of acquisition. Both physical possession and intellectual ownership can be described, providing details of changes of ownership and/or custody that may be significant in terms of authority, integrity, and interpretation.

Although the history of custody is sometimes synonymous with provenance, a description of archival provenance may be more appropriate for the <origination>, <bioghist>, or <scopecontent> elements.

Use Acquisition Information <acqinfo> for text about the immediate source of the described materials and the circumstances under which they were received by the repository.

Tag example:

<custodhist encodinganalog="561">
<head>Custodial History</head>
The George Franklin Papers were maintained by the staff of the Mayor's Office, City of Irvine, California, in the records storage facility at City Hall from the time of Franklin's death in 1972 until they were transferred, at his family's request, to Special Collections and Archives, The UC Irvine Libraries, in 1988.
</custodhist>

Status:

Optional

Repeatable:

No - use multiple statements for additional entries

Comments:

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).
Practice: University at Buffalo finding aids will not apply <date> element within <custodhist>.

accruals

Accruals

Tag Library Definition:

Information about anticipated additions to the materials being described. Can indicate quantity and frequency. Can also be used to indicate that no additions are expected.

Tag examples:

Example 1:

<accruals encodinganalog="584">
<head>Accruals and Additions</head>
Noncurrent additions to this Record Group are transferred from the Development Department annually at the end of the fiscal year in June.
</accruals>

Example 2:

<accruals encodinganalog="584">
<head>Accruals and Additions</head>
No further accruals are expected to this collection.
</accruals>

Status:

Optional

Repeatable:

No - use multiple statements for additional entries

Comments:

Used primarily for archival records; may be useful in other situations such as collections which accrue ongoing donations from a living donor or collections where new material is received on a regular basis.
Application of the second example above is optional.
Practice: University at Buffalo finding aids will not apply <date> element within <accruals>.

altformavail

Alternative Form Available

Tag Library Definition:

Information about copies of the materials being described, including the type of alternative form, significant control numbers, location, and source for ordering if applicable. The additional formats are typically microforms, photocopies, or digital reproductions.

Do not confuse with Location of Originals <originalsloc>, which is used to encode information about the existence, location, and availability of originals where the unit described consists of copies.

Use if original material is still available for public use. If the original material is not available for public use, place this information in Processing Information <processinfo>.

Tag examples:

Example 1:

<altformavail encodinganalog="530">
<head>Alternate Forms</head>
Microfilm copy available (<num type="microfilm reel">M-5030/1</num>).
</altformavail>

Example 2:

<altformavail encodinganalog="530">
<head>Alternate Forms</head>
Selected items from the papers of the Alexander Graham Bell family are available on the Library of Congress Web site at <extref href="http://memory.loc.gov/ammem/bellhtml/" show="new" actuate="onrequest">http://memory.loc.gov/ammem/bellhtml/</extref>. Of the 4,700 items selected for digitization, 4,650 items are currently available in digital format via links provided in the container list of this register.
</altformavail>

Status:

Optional

Repeatable:

Comments:

Information about the material might include the format of the alternate form, its extent, identifying codes, and the source/procedure for ordering copies.
If copies exist in more than one format, <altformavail> may be repeated with a head appropriate to its content. (This same rationale, and repeatability of <processinfo> is stated in EAD vs. 1 application guidelines).
Note: This is not the place to record all forms of content contained within the collection.
If a collection is available in multiple formats (for instance, microform and electronic), separate paragraphs with appropriate headings should be used.
Information about how to order copies, restriction and reproduction of alternate forms, how to view etc., may be included as part of <altformavail>. If such statements are lengthy or are common to many finding aids, it may be better to make a link to an external entity such as a web site where such information is available.

Two scenarios may apply in the use of <altformavail> for electronic content:

Electronic forms of collection material are available in a separate presentation (See the Juan B. Rael Collection in Library of Congress's American Memory). The finding aid does not contain specific links to collection material at a folder level.
- Action Required:
 - Include <altformavail> note which links to overall presentation
 - No further links are required
Electronic forms of collection materials are available in a separate presentation (See the Leonard Bernstein Collection in Library of Congress's American Memory). The finding aid includes specific links to digitized collection material at a folder level.
- Action Required:
 - Include <altformavail> note which links to overall presentation
 - Include <dao> links from folder listings (or from another level of hierarchy, such as series or subseries) in container list
- Optional: include image concordance <daogrp> providing <daoloc> links to all digital images linked to in the finding aid. This is done directly under <archdesc>, rather than as part of <archdesc> <did> as would be done for an illustrative "image sampler."

originalsloc

Location of Originals

Tag Library Definition:

Information about the existence, location, availability, and/or the destruction of originals where the unit described consists of copies.

Do not confuse <originalsloc> with Alternative Form Available <altformavail>, which is used to encode information about copies of the material being described.

Tag examples:

Example 1:

<c01 level="file">
<did>
<unittitle>Dream diary
<unitdate normal="1947/1948">>1947-1948</unitdate>
</unittitle>
</did>
<originalsloc>
File contains photocopies of original still held by the donor.
</originalsloc>
</c01>

Example 2:

<c01 level="series">
<did>[...]</did>
<originalsloc>
Originals destroyed after microfilming, 1981.
</originalsloc>
</c01>

Status:

Optional

Repeatable:

Comments:

Use will most likely occur at the container level.

processinfo

Processing Information

Tag Library Definition:

Information about accessioning, arranging, describing, preserving, storing, or otherwise preparing the described materials for research use. Specific aspects of each of these activities may be encoded separately within other elements, such as <acqinfo>, <arrangement>, <physloc>, etc.

Tag examples:

Example 1:

<processinfo encodinganalog="583">
<head>Processing Information</head>
Processed by Murray Kemp.
</processinfo>

Example 2:

<processinfo encodinganalog="583">
<head>Reformatted Materials</head>
Reference copies of audio materials on 10-inch reel-to-reel tape have been made for service in the AFC reading room. The original 36 12-inch acetate-on-aluminum discs (AFS 3905-3940) and the 5 10-inch preservation reel-to-reel tape copies (LWO 4872: reels 255-259) are stored in the Motion Picture, Broadcasting and Recorded Sound Division, Library of Congress.
</processinfo>

Status:

Required

Repeatable:

Comments:

Revision information should also be included in this section. This information should mirror the information included in the <revisiondesc> in the <eadheader> section, although the format may be different as it will be displayed publicly.
Additional processing information may be included in additional tags if necessary. If a legacy finding aid contains a long description of how the collection was processed, this is the place for that information to reside.
Processing information may include names of processors and dates of processing as well as any notable or unusual processing activities. The <processinfo> element may be used to describe original processing or further processing later in time. Routine processing need not be recorded and use of this element is not always required if it repeats information already available in header and title page display.
Processing information for electronic records may include information about reformatting or migration of data which does not result in alternate forms available for public use, such as when the original is not usable or data has been migrated to a usable form.
If original material is still available for public use, newly formatted versions should be listed in Alternate Form Available <altformavail> instead of <processinfo>)
Practice provides two options:
1. enter here only processing information. Enter author of finding aid in <filedesc><author> and encoders in <profiledesc><creation>. See Appendix 7 - Finding Aid Authors, Encoders, and Collection Processors for further information.
2. Enter author of finding aid in <filedesc><author> and encoders in <profiledesc><creation>, but suppress them from display. Restate information from those elements in <processinfo> along with information about collection processing. This use of <processinfo> is required for University Archives finding aids.
Practice: University at Buffalo finding aids will not apply <date> element within <processinfo>.

appraisal

Appraisal Information

Tag Library Definition:

Information about the process of determining the archival value and thus the disposition of records based upon their current administrative, legal, and fiscal use; their evidential, intrinsic, and informational value; their arrangement and condition; and their relationship to other records.

Tag example:

<appraisal>
The appraisal of this collection was carried out in consultation with Robert Heinmiller, a research associate at Woods Hole Oceanographic Institution during MODE.
</appraisal>

Status:

Optional

Repeatable:

Comments:

Use only for significant appraisal issues that hold true for the entire collection.

phystech

Physical Characteristics and Technical Requirements

Tag Library Definition:

A description of important physical conditions or characteristics that affect the storage, preservation, or use of the materials described. This includes details of their physical composition or the need for particular hardware or software to preserve or access the materials.

Tag example:

<c02 level="subseries">
<did>[...]</did>
<phystech>
<head>Physical Characteristics and Technical Requirements</head>
48K RAM; Apple Disk II with controller; color monitor
</phystech>
</c02>

Status:

Optional

Repeatable:

Comments:

Use will most likely occur at the container level.

This ends the /descgrp type="admininfo" section

bioghist

Biography or History

Tag Library Definition:

A concise essay or chronology that places the archival materials in context by providing information about their creator(s). Includes significant information about the life of an individual or family, or the administrative history of a corporate body. The <bioghist> may contain just text in a series of Paragraphs , and/or a Chronology List <chronlist> that matches dates and date ranges with associated events. Additional <bioghist> elements may be nested inside one another when a complex body of materials, such as a collection of family papers, is being described, and separately headed sections are desired. The <bioghist> element may also be nested to designate a portion of the essay or chronology that might be extracted as a MARC 545 subfield.

Many elements, such as <bioghist> are recursive (i.e., the elements are available within themselves) to facilitate the use of multiple headings with subdivided descriptions for complex collections, and to enable EAD markup to be used for a variety of output.

Tag example:

<bioghist encodinganalog="545">
<head>Historical Note</head>
In October 1964 the incoming Labour government created new office of Secretary of State for Economic Affairs (combined with First Secretary of State) and set up the Department of Economic Affairs under the Ministers of the Crown Act 1964 to carry primary responsibility for long term economic planning.
</bioghist>

Head:

The <head> element language should be selected from:

Biographical Note
Historical Note
Chronology (this can be stated as a heading or can appear as a component within either Biographical Note or Historical Note)

Status:

Required

Repeatable:

Comments:

See Examples of <bioghist> statements and use of <chronlist> within it.
Generic text formatting elements such as , <list>, and <table> can also be used under <bioghist>.
Text should be enclosed in paragraph tags; is repeatable.
It is recommended that encoding of text in <bioghist> for names, titles, and dates be the exception rather than the rule. Only those pieces of text that relate to information contained within the collection should be considered for markup, and of those, only the smaller group of text pieces that provide unique points of access (information not repeated in the container list or list of search terms) should be marked up.
Biographical information in <bioghist> may be expressed as a narrative text, as a chronological list, or as a simple list.
When <chronlist> tagging is used, be sure to include list head tagging that is Required for proper accessibility in a Web display.
Bibliographic citations for sources consulted in order to construct a biographical or historical note should be included in a Bibliographic Reference <bibref> statement within the <bioghist> if considered appropriate by an institution. An example of encoding bibliographic citations within the <bioghist> would be:

<bibref><persname>[author]</persname><title render="italic">[title of monograph</title>.
[Imprint information, Place: Publisher, date]</bibref>

chronlist

Chronology List

Tag Library Definition:

A formatting element that designates information about the sequence in which significant past events, associated with the described materials, occurred. The <chronlist> also provides a structured display to list these dates and events. Each <chronlist> contains Chronology Items <chronitem>s that pair a <date> or date range with a brief description of an associated <event> or events <eventgrp>.

A <chronlist> most often appears in finding aids as part of the Biography or History <bioghist> element, but <chronlist> is also available for use in other elements that might need to present historical dates and events in a multicolumn list.

Tag example:

<bioghist>
<head>Chronology</head>
<chronlist>
<chronitem>
<date normal="18401012">1840</date>
<event>Born Helena Opid in Krakow, Poland on October 12th.</event>
</chronitem>
<chronitem>
<date normal="1861">1861</date>
<event>Made stage debut as Helena Modrzejewska in charity fair production of <title>The White Camellia</title>, in Bochnia, Poland.</event>
</chronitem>
</chronlist>
</bioghist>

Subelements:

<head>
<listhead>
<chronitem>, with further subelements <eventgrp> and <event>

Status:

Optional

Repeatable:

Comments:

See Examples of <bioghist> statements and use of <chronlist> within it.
Practice: University at Buffalo finding aids will apply the <date> element within <chronlist> but will not provide normalization.

This ends the /bioghist section

scopecontent

Scope and Content

Tag Library Definition:

A prose statement summarizing the range and topical coverage of the described materials, often mentioning the form and arrangement of the materials and naming significant organizations, individuals, events, places, and subjects represented. The purpose of the <scopecontent> element is to assist readers in evaluating the potential relevance of the materials to their research. It may highlight particular strengths of, or gaps in, the described materials and may summarize in narrative form some of the descriptive information entered in other parts of the finding aid.

Additional <scopecontent> elements may be nested inside one another when a complex collection of materials is being described and separate headings are desired. For example, when a collection is received and processed in installments, individual scope and content notes may be created for each installment. EAD permits these separate narrative descriptions to be encoded as discrete <scopecontent> elements, but it also enables the encoder to gather the independent <scopecontent> notes within a single larger <scopecontent> reflective of the materials as a whole. Nested <scopecontent> elements might also occur when an institution encodes the first paragraph of a long scope and content note as a separate summary <scopecontent> with an encodinganalog attribute set to MARC field 520$a.

Tag example:

<scopecontent encodinganalog="520">
<head>Scope and Content Note</head>
The records of BIKE WNY, 1990-2002 were collected and maintained by Suzanne Toomey Spinks, one of the co-founders of the organization. This collection contains materials relevant to the advocacy organization. Materials include biking articles and newsletters, correspondence, promotional items, safety outreach, tour and trail guides, as well as information on related local advocacy groups and projects. Some of the research materials retained with the collection pre-date the organization.
</scopecontent>

Status:

Required

Repeatable:

Comments:

Text should be enclosed in paragraph tags; is repeatable.
Content tagging for elements such as <persname>, <corpname>, <geogname>, <subject>, <title>, etc. within the text of the <scopecontent> should be limited to only exceptional needs.
Practice: <scopecontent> can be used at <c01> and <c02> levels as necessary to describe series and subseries, but no encodinganalog attribute will be set at those levels.

This ends the /scopecontent section

arrangement

Arrangement

Tag Library Definition:

Information on how the described materials have been subdivided into smaller units, e.g., record groups into series, identifying the logical or physical groupings within a hierarchical structure. Can also be used to express the filing sequence of the described materials, such as the principle characteristics of the internal structure, or the physical or logical ordering of materials, including alphabetical, chronological, geographical, office of origin, and other schemes. Identifying logical groupings and the arrangement pattern may enhance retrieval by researchers.

The <arrangement> element may occur within <archdesc> and <c> or as a subelement of <scopecontent>.

Tag examples:

Example 1: with <ref> used to link within the finding aid (based on LC example)
For more information on linking within a document, see Appendix 15 - Linking Elements, specifically the example that demonstrates how the referenced component must be encoded in order to enable the link.

Text (without links highlighted)

Tagging

Arrangement

<arrangement encodinganalog="351$a">
<head>Arrangement</head>

The Blackwell Family Papers are organized in two series:

The Blackwell Family Papers are organized in two series:

Alice Stone Blackwell Papers, 1848-1957
Elizabeth Blackwell Papers, 1836-1946

<list type="simple">
<item>
<ref target="clalice" show="replace" actuate="onrequest">Alice Stone Blackwell Papers, 1848-1951</ref>
</item>
<item>
<ref target="cleliz" show="replace" actuate="onrequest">Elizabeth Blackwell Papers, 1836-1946</ref>
</item>
</list>
</arrangement>

Example 2: showing encodinganalog attribute set to" 351$b" for filing sequence:

<arrangement encodinganalog="351$b">
<head>Arrangement</head>
The Charles Wellington Reed Papers are arranged alphabetically by type of material with oversize items located at the end of the collection. 
</arrangement>

Example 3: encodinganalog set to "351" with series statements and filing sequences intermingled

<arrangement encodinganalog="351">
<head>Arrangement</head>
Arranged in two series: 1. Correspondence (alphabetical); 2. Subject files (alphabetical by topic).
</arrangement>

Subelements:

<head>
<list>
<item>

Status:

Required

Repeatable:

Comments:

The recommendation is for encoding this information separately in an <arrangement> section in view of emerging community practice. This element may also be used at the component level to explain the organization or arrangement of papers within that component.
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 referred 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.
Text should be enclosed in paragraph tags; is repeatable.
Encode as <arrangement encodinganalog="351$a"> the manner in which the collection has been ordered (e.g., organized into series; see Example 1), and as <arrangement encodinganalog="351$b"> the filing sequence of the material (e.g., alphabetical or chronological; see Example 2). Encode as <arrangement encodinganalog="351"> if statements about organization and arrangement are intermingled (see Example 3).
Consider creating links from a list of series to the series title in the container list. This may be done with <ref> tags, as illustrated in Example 1, or with a stylesheet, as described in the EAD Cookbook.
Practice: University at Buffalo finding aids will set the encodinganalog attribute to "351" without subfields for all statements of <arrangement>. The <arrangement> element will be stated separately from <scopecontent>, whether in <archdesc> or <c>. No encodinganalog attribute will be set at the container level.

This ends the /arrangement section

Container List

Container lists are as varied as the collections they describe and the archivists who write them. It is not possible to standardize every aspect of either the structure or encoding of container lists. However, it is possible to adopt some standard practices that can be applied and any efforts to make container lists consistent in format, encoding, and structure will be beneficial to researchers. The following is a list of some of the recommended practices and reminders culled from the following, more detailed descriptions of EAD encoding for container lists.

All elements available at the higher level (<archdesc>) are also available at the component level of description.
The entire container list is to be stated within just one <dsc> element.
Only the use of numbered components (<c01> to <c12>) is permitted.
Recommended practice is to use the type attribute "combined" for <dsc>. This requires integration of narrative descriptions of series within <scopecontent> and/or <arrangement> inside <dsc>.
Recommended minimum best practice is that container information such as box, box/folder, or reel numbers given in a finding aid should be repeated at the lowest (e.g., folder) level for better search results, data extraction, and navigation of long lists of headings.
Every component (<c0x>) must contain a <did>
Recommended practice is to include a <unittitle> within every component's <did>.
Where no <unittitle> content exists (or if a <unittitle> is meant to be "inherited" by succeeding entries), but dates are provided, include a <unittitle> element and place the date(s) inside <unitdate>.
Do not use <abstract> at the component level. Use < scopecontent> instead.
Encode for <persname>, <corpname>, etc. at the component level where appropriate.
Normalize dates at the series and subseries levels.
Practice: University at Buffalo finding aids will not apply the encodinganalog attribute at the container level. Application of the encodinganalog attribute at this level has been omitted from all of the relevant examples. <unitdate> will be stated within <unittitle>.

dsc

Description of Subordinate Components

Tag Library Definition:

A wrapper element that bundles information about the hierarchical groupings of the materials being described. The subordinate components can be presented in several different forms or levels of descriptive detail, which are identified by the element's required type attribute. For example, "analyticover" identifies an overview description of series and subseries, which might be followed by a second <dsc> with the type attribute set to "in-depth" that provides a more detailed listing of the content of the materials, including information about the container numbers associated with those materials. The type attribute value "combined" is used when the description of a series is followed immediately by a listing of the contents of that series. The type attribute "othertype" is for models that do not follow any of the above-mentioned formats, in which case the othertype attribute can then be used to specify a particular presentation model.

Tag example:

<dsc type="combined">
<head>Container List</head>

Type Attribute Values:

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 and is the recommended approach. Each series begins with an overview scope and content note followed by the container listing. This approach prevents duplication of information in terms of both encoding and searching, and the need to lead researchers through layers of the finding aid. The adoption of XSL stylesheets can present data encoded using this combined approach to display either as combined or broken out into Description of Series and Container List, as described in the EAD Cookbook, 3.3.10. Separate encoding of description of series and container list is not recommended. See Example 1.
"in-depth" - A container list containing hierarchical description of the components of a collection including box, folder, and other locations. When a collection is not organized into series (typically a small collection), the <dsc> type will be "in-depth" for a container list. See Example 2.
"analyticover" - A container list made up of series and subseries descriptions only. Use type="analyticover" for collections for which only series descriptions, and no file or item-level container list, are available. See Example 3.
"othertype" - Use for an alternative view of the components in addition to the usual "combined", or in other situations as appropriate.

Subelements:

<thead>
<row>
<entry>

Status:

Required, with type attribute

Repeatable:

Yes, but not recommended

Comments:

A single <dsc> should be used with nested components in which descriptions for subgrp, series, subseries, file, item, and otherlevel (as reflected in the intellectual arrangement of the collection) are placed at the appropriate level in the component hierarchy.
The basic required element within each component <c0x> is <did> with <unittitle> within.
When a tabular display is intended, use table heading tags (<thead> and its subelements,) to provide HTML versions of the finding aid with headings for each column. This is required to meet accessibility requirements for users of text browsers, voice recognition software, etc. The contents of these tags should match what is being described.
All elements available at the higher level (<archdesc>), such as <scopecontent> and <arrangement>, are also available at these lower levels of description. In implementing EAD, an institution needs to reflect on the necessity of particular information at a lower level, remembering the concept of inheritance of information and the reciprocal relationship between more finite description and less detail. In other words, typically the lower down in the description (file or item) the less description needed because it has inherited information from the descriptions above.
The id attribute can be used to enable linking from <arrangement> to the related place in the container list. It has been applied to <unittitle> in Examples 1, 3, and 4 below.

Additional tagging examples:

Example 1 -- type attribute set to "combined": <dsc> with type attribute set to "combined". This is typical of modern finding aids and is the recommended approach. Return to "combined" description.

Example 1 (text only):

Container List

Series I. Recipient Files, 1946-1949
Scope and Content note: The Relief Project kept two files on relief recipients. Files from Subseries A (labeled "A") contain personal data and lists of package contents sent to the recipient. Files from Subseries B (labeled "B") contain correspondence, usually with English translations of letters written in foreign languages.
Arrangement: Files are arrange alphabetically by last name.

Subseries A. "A" File

1.1-1.2 Alpheus, Karl and Grete (Freiburg, Germany), undated

1.3 Baldass, Ludwig and Pauly (Vienna, Austria), 1948

Subseries B. "B" File

1.4-1.8 Mannoury, S.D. (Amsterdam, Netherlands), 1946-1949

1.9-2.6 Zanasi, Lusiano (Modena, Italy), 1947-1948 [8 folders]

Example 1 (text and tagging side by side):

Text

Tagging

Container List

<dsc type="combined">
<head>Container List</head>

Series I. Recipient Files, 1946-1949

<c01 level="series">
<did>
<unittitle>Series I. Recipient Files, 1946-1949
<unitdate type="inclusive" normal="1946/1949">1946-1949</unitdate>
</unittitle>
</did>

Scope and Content note: The Relief Project kept two files on relief recipients. Files from Subseries A (labeled "A") contain personal data and lists of package contents sent to the recipient. Files from Subseries B (labeled "B") contain correspondence, usually with English translations of letters written in foreign languages.

<scopecontent>
Scope and Content note: The Relief Project kept two files on relief recipients. Files from Subseries A (labeled "A") contain personal data and lists of package contents sent to the recipient. Files from Subseries B (labeled "B") contain correspondence, usually with English translations of letters written in foreign languages.
</scopecontent>

Arrangement: Files are arrange alphabetically by last name.

<arrangement>
Arrangement: Files are arrange alphabetically by last name.
</arrangement>

Subseries A. "A" Files

<c02 level="subseries">
<did>
<unittitle>Subseries A. "A" Files
</unittitle>
</did>

1.1-1.2

Alpheus, Karl and Grete (Freiburg, Germany), undated

<c03 level="file">
<did>
<container type="box/folder">1.1-1.2</container>
<unittitle>Alpheus, Karl and Grete (Freiburg, Germany), undated</unittitle>
</did>
</c03>

1.3

Baldass, Ludwig and Pauly (Vienna, Austria), 1948

<c03 level="file">
<did>
<container type="box/folder">1.3</container>
<unittitle>Baldass, Ludwig and Pauly (Vienna, Austria)
<unitdate type="inclusive">1948</unitdate>
</unittitle>
</did>
</c03>
</c02>

Subseries B. "B" Files

<c02 level="subseries">
<did>
<unittitle>Subseries B. "B" Files
</unittitle>
</did>

1.4-1.8

Mannoury, S.D. (Amsterdam, Netherlands), 1946-1949

<c03 level="file">
<did>
<container type="box/folder">1.4-1.8</container>
<unittitle>Mannoury, S.D. (Amsterdam, Netherlands)
<unitdate type="inclusive">1946-1949</unitdate>
</unittitle>
</did>
</c03>

1.9-2.6

Zanasi, Lusiano (Modena, Italy), 1947-1948

[8 folders]

<c03 level="file">
<did>
<container type="box/folder">1.9-2.6</container>
<unittitle>Zanasi, Lusiano (Modena, Italy)
<unitdate type="inclusive">1947-1948</unitdate>
</unittitle>
<physdesc>
<extent>[8 folders]</extent>
</physdesc>
</did>
</c03>
</c02> </c01>
</dsc>

Example 2 -- type attribute set to "in-depth" (adapted from LC): <dsc> with type attribute set to "in-depth". Small collection without series (Container List only). Return to "in-depth" description

Text

Tagging

Container List

<dsc type="in-depth">
<head>Container List</head>

Box 1

Diaries, 1843, 1849-1896

(4 folders)

<c01 level="file">
<did>
<container type="box">1 </container>
<unittitle>Diaries
<unitdate type="inclusive" normal="1843">1843</unitdate>,
<unitdate type="inclusive" normal="1849/1896">1849-1896</unitdate>
</unittitle>
<physdesc>
<extent>(4 folders)</extent>
</physdesc>
</did>
</c01>

Box 1-5

Family correspondence

<c01 level="file">
<did>
<container type="box">1-5</container>
<unittitle>Family correspondence</unittitle>
</did>

Box 1

1803 May-1832 Apr.

(5 folders)

<c02 level="file">
<did>
<container type="box">1</container>
<unittitle>
<unitdate type="inclusive">1803 May-1832 Apr.</unitdate>
</unittitle>
<physdesc>
<extent>(5 folders)</extent>
</physdesc>
</did>
</c02>

Box 2

1832 May-1835 Mar.

(6 folders)

<c02 level="file">
<did>
<container type="box">2</container>
<unittitle>
<unitdate type="inclusive">1832 May-1835 Mar.</unitdate>
</unittitle>
<physdesc>
<extent>(6 folders)</extent>
</physdesc>
</did>
</c02>
</c01>
</dsc>

Example 3 -- type attribute set to "analyticover" (adapted from LC): <dsc> with type attribute set to "analyticover" (Series Description only). Return to "analyticover" description.

Text

Tagging

Description of Series

<dsc type="analyticover">
<head>Description of Series</head>

Boxes 1-16

Reels 1-8

Correspondence, 1800-1874

<c01 level="series">
<did>
<container type="box">1-16</container>
<container type="reel">1-8</container>
<unittitle>Correspondence
<unitdate type="inclusive" normal="1800/1874">1800-1874</unitdate>
</unittitle>
</did>

Letters to Webster and letters by and about him.

<scopecontent>
Letters to Webster and letters by and about him.
</scopecontent>

Arranged in groups as general correspondence, invitations, and selected transcripts and chronologically therein.

<arrangement>
Arranged in groups as general correspondence, invitations, and selected transcripts and chronologically therein.
</arrangement>
</c01>
</dsc>

Example 4 -- type attribute set to "analyticover"(adapted from LC): Headings for tabular display. Return to "analyticover" description

Text

Tagging

Container List

<dsc type="analyticover">
<head>Container List</head>

Box

Reel

Contents

<thead>
<row>
<entry>Box</entry>
<entry>Reel</entry>
<entry>Contents</entry>
</row>
</thead>

Box 1

Reel 1

Correspondence, 1800-1874

<c01 level="file">
<did>
<container type="box">1</container>
<container type="reel">1</container>
<unittitle>Correspondence
<unitdate type="inclusive" normal="1898/1975">1800-1874, undated</unitdate>
</unittitle>
</did>

Box 1

Reel 1

General

<c02>
<did>
<container type="box">1</container>
<container type="reel">1</container>
<unittitle>General</unittitle>
</did>
</c02>
</c01>
</dsc>

c

What is a Component?

Tag Library Definition:

A wrapper element that designates a subordinate part of the materials being described. A Component <c> provides information about the content, context, and extent of a subordinate body of materials. It is always nested within a Description of Subordinate Components <dsc> and often within another <c> element. Each <c> element identifies an intellectually logical section of the described materials. The physical filing separations between components do not always coincide with the intellectual separations. For example, a <c> that designates dramatic works might end in the same box in which the next <c> begins with short stories. Also, not every <c> directly corresponds to a folder or other physical entity. Some <c> elements simply represent a stage within a hierarchical description.

Components may be subdivided into smaller and smaller components and may eventually reach the level of a single item. For example, the components of a collection may be series, components of series may be subseries, components of subseries may be files, and components of files may be items. A component may be either an unnumbered <c> or a numbered <c01>, <c02>, etc. The numbered components <c01> to <c12> assist a finding aid encoder in nesting up to twelve component levels accurately.

Use the level attribute to identify the descriptive character of the component, for example, "series," "subseries," "subgrp," "file," (the term file is used here to mean an intellectual unit of archival materials, not the contents of a physical housing such as a folder) or "item." Assigning a level attribute for the highest <c> is recommended; thereafter the attribute may be used when the repository deems it useful.

Recommended practice is to use only numbered components. Remember that the numbers carry no intellectual significance and that a particularly numbered component level may correspond to a variety of intellectual levels. Intellectual distinctions are made using the level attribute

Tag example:

<c>

Level Attribute Values:

level="collection"
level="series"
level="subseries"
level="subgrp"
level="file"
level="item"
level="otherlevel"

Subelements:

<did>Basic Description of Each Component
<descgrp type="admininfo"> and <descgrp type="userinfo">subelements, including <accessrestrict>, <userestict>, <acqinfo>, <altformavail>, <custodhist>, <processinfo>
<bioghist>Biographical or Historical Note
<scopecontent>Scope and Content Note
<descgrp type="add"> subelements, including <separatedmaterial>, <relatedmaterial>, <bibliography>, <fileplan>, <index>, <otherfindaid>
<originalsloc>Location of Originals
<phystech>Physical Characteristics and Technical Requirements
<odd>Other Descriptive Data

Comments:

If a collection is arranged into series, set attribute <c01 level="series">. If a collection is arranged into series and subseries (subgroups worthy of separate overall description and placement in a navigator), set attributes <c01 level="series"> and <c02 level="subseries">. Set level attributes of "file" or "item" for other components as appropriate.
Not all series have subseries; in series that do not, <c02> elements have attribute "file" (or, in unusual cases, level="item").
If a collection is arranged into series, subseries (subgroups worthy of separate overall description and placement in a navigator), and other subgroups worthy of separate overall description, set attributes <c01 level="series"> and <c02 level="subseries">; set each subsequent important subdivision as <c03 level="subseries">, <c04 level="subseries">. Subordinate components would be set for level file or item, as appropriate. This practice would be needed only for very large and complex collections.
If a collection is not arranged into series (small collections especially), set <c01 level="file"> and subordinate levels at file or item, as appropriate.
It is possible to set encoding analogs for component subelements as they are set at higher elements, e.g., <unittitle> is "245$a" whether in the Collection Summary or a subseries title. This will benefit future searching and interoperability without detracting from the ability to extract a pseudo-MARC record from the non-<dsc> portions of the finding aid. UB will not apply encodinganalog at this level.
Information about the physical location (box, folder, item, reel, etc.) of materials within the collection is encoded within the <container> element. Primarily, this information is used by researchers to request materials and reference services to retrieve materials. It may also help users to understand the amount of materials in a section of the collection. Since EAD is primarily focused on the structure of the intellectual content, information about the physical organization is of secondary concern. There are several methods of encoding container information that range from more general to more specific. Check the EAD Application Guidelines for a full description of options.
It is important that every described <c0x> level include a <unittitle> element. The unittitle is what describes the component level and more broadly describes all components nested within. A component without a unittitle should be carefully evaluated to discover what purpose it serves before including it in the EAD encoding.
The administrative information elements are also available in components. This is most often used when a series, subseries, folder, or other level component is restricted in some way, but may also be used as needed for other administrative information such as preservation concerns, special processing information or original locations for specific materials within a larger collection. These are merely types of component level administrative information that could be necessary, however, the application of administrative information elements is not restricted to those listed above. Be mindful that the administrative information at the collection level (<archdesc>) is inherited to all levels of the <dsc> so the administrative information elements used with the components either enhance or are more specific than the general administrative information outlined in the collection level description.
Practice:
- only numbered <c> elements are allowed
- encodinganalog attribute will not be used at <c> level
- dates will be normalized at the series and subseries levels.

Additional tagging examples (lacking the <container> statements):

Example 1 (adapted from LC): Collection with series and some subseries

Text

Tagging

Family Papers, 1872-1892

<c01 level="series">
<did>
<unittitle>Family Papers
<unitdate type="inclusive" normal="1872/1892">1872-1892</unitdate>
</unittitle>
</did>

 Diaries, 1872

 <c02 level="file">
 <did>
 <unittitle>Diaries
 <unitdate type="inclusive">1872</unitdate>
 </unittitle>
 </did>
 </c02>

 Notebooks, 1875-1892

 <c02 level="file">
 <did>
 <unittitle>Notebooks
 <unitdate type="inclusive">1875-1892</unitdate>
 </unittitle>
 </did>
 </c02>
</c01>

Correspondence, 1938-1976, undated

<c01 level="series">
 <did>
 <unittitle>Correspondence
 <unitdate type="inclusive" normal="1938/1976">1938-1976</unitdate>,
 <unitdate>undated</unitdate>
 </unittitle>
 </did>

 General, 1938-1976

 <c02 level="subseries">
 <did>
 <unittitle>General
 <unitdate type="inclusive" normal="1938/1976">1938-1976</unitdate>
 </unittitle>
 </did>

 Adams, John, 1944-1945

 <c03 level="file">
 <did>
 <unittitle>Adams, John
 <unitdate type="inclusive">1944-1945</unitdate>
 </unittitle>
 </did>
 </c03>
 </c02>
 <c02 level="subseries">

 Organizations, 1943-1976, undated

 <did>
 <unittitle>Organizations
 <unitdate type="inclusive" normal="1943/1976">1943-1976</unitdate>,
 <unitdate>undated</unitdate>
 </unittitle>
 </did>
 </c02>
</c01>

Example 2 (adapted from LC): Collection with complex subseries arrangement

Text

Tagging

Special Files: Public Service, 1918-1986

<c01 level="series">
 <did>
 <unittitle>Special Files: Public Service
 <unitdate type="inclusive" normal="1918/1986">1918-1986</unitdate>
 </unittitle>
 </did>

 World War II Files, 1941-1981

<c02 level="subseries">
 <did>
 <unittitle>World War II files
 <unitdate type="inclusive" normal="1941/1981">1941-1981</unitdate>
 </unittitle>
 </did>

 Harriman Mission, 1941-1946

<c03 level="subseries">
 <did>
 <unittitle>Harriman Mission
 <unitdate type="inclusive">1941-1946</unitdate>
 </unittitle>
 </did>

 Folder title, 1944

<c04 level="file">
 <did>
 <unittitle>Folder title
 <unitdate type="inclusive">1944</unitdate>
 </unittitle>
 </did>
 </c04>
 </c03>

 Moscow Files, 1943-1949

<c03 level="subseries">
 <did>
 <unittitle>Moscow Files
 <unitdate type="inclusive" normal="1943/1949">1943-1949</unitdate>
 </unittitle>
 </did>

 Folder title, 1943-1946

<c04 level="file">
 <did>
 <unittitle>Folder title
 <unitdate type="inclusive">1943-1946</unitdate>
 </unittitle>
 </did>
 </c04>
 </c03>
 </c02>

 Truman Administration, 1943-1963

<c02 level="subseries">
 <did>
 <unittitle>Truman Administration
 <unitdate type="inclusive" normal="1943/1963">1943-1963</unitdate>
 </unittitle>
 </did>
 </c02>
</c01>

Example 3 (adapted from LC): Small collection with no series

Text

Tagging

Journal and diaries, 1843, 1849-1896

<c01 level="file">
 <did>
 <unittitle>Journal and diaries
 <unitdate type="inclusive" normal="1843">1843</unitdate>,
 <unitdate type="inclusive" normal="1849/1896">1849-1896</unitdate>
 </unittitle>
 </did>
</c01>

Correspondence

<c01 level="file">
 <did>
 <unittitle>Correspondence</unittitle>
 </did>

 May 1803-Apr. 1832

<c02 level="file">
 <did>
 <unittitle>
 <unitdate type="inclusive" normal="1803-05/1832-04">May 1803-Apr. 1832</unitdate>
 </unittitle>
 </did>
 </c02>
</c01>

did

Descriptive Identification (Basic Description of Each Component)

Tag Library Definition:

A required wrapper element that bundles other elements identifying core information about the described materials in either Archival Description <archdesc> or a Component <c>. The various <did> subelements are intended for brief, clearly designated statements of information and, except for <note>, do not require Paragraphs to enter text.

The <did> groups elements that constitute a good basic description of an archival unit. This grouping ensures that the same data elements and structure are available at every level of description within the EAD hierarchy. It facilitates the retrieval or other output of a cohesive body of elements for resource discovery and recognition.

The <did> in <archdesc> is sometimes called the high level <did>, because it describes the collection as a whole. A <did> within a Component <c> can be less complete, and might have only a <container> or <unitid> and a <unittitle>.

Tag example:

<did>

Subelements:

Element

Name

Local Use

<container>

Container Information

Recommended

<unitid>

ID of Unit

Use the ID of the Unit <unitid> element to designate control numbers not associated with a physical container, for example, accession numbers.

<unittitle>

Unit Title

Required

<unitdate>

Unit Date

Required if available (nested within <unittitle>)

<origination>

Origination

Consider using <origination> at the series level when the creator/collector differs from that described in the Collection Summary, e.g., when the John Doe, Sr. papers comprise a series of the John Jay Doe Papers.

<physdesc>

Physical Description

Recommended if available

<materialspec>

Material Specifications

Use <materialspec> when material requires: Examples of material specific details include mathematical data, such as scale for cartographic and architectural records, jurisdictional and denominational data for philatelic records, and physical presentation data for music records.

<langmaterial>

Language Material

Use <langmaterial> at the component level only if the material being described is in a language different from that already specified at the <archdesc> level.

<abstract>

Abstract

Do not use at component level; use <scopecontent> instead

<physloc>

Physical Location of Materials

Use for information identifying the place where the described materials are stored, such as the name or number of the building, room, stack, shelf, or other tangible area.

<note>

Note

Use only when information does not fit into a better defined element.

<daogrp>

Digital Object Group

Use when required to identify digital objects or surrogates.

See Tag Library for full list of valid subelements.

container

Container Information

Tag Library Definition:

A <did> subelement for information that contributes to locating the described materials by indicating the kinds of devices that hold the materials and identifying any sequential numbers assigned to those devices. The <container> element is used most frequently at the component level, i.e., once a Description of Subordinate Components <dsc> has been opened. This storage information can help researchers understand how extensive the material is, especially in the absence of a specific physical <extent> statement at the component level.

Use of the type attribute is strongly recommended to clarify the nature of the storage device. Use any useful designations, such as "box," "folder," and "reel."

The Physical Location <physloc> element can be used to designate the shelves, stacks, rooms, buildings, or other places where the containers are stored.

Use the ID of the Unit <unitid> element to designate control numbers not associated with a physical container, for example, accession numbers. Most repositories use either <container> or <unitid> as the call numbers for fetching material for researchers. If both elements are used, consider setting the label attribute to specify which element is the call number.

The parent attribute can be used to point to the <container> element that describes the box in which a folder is housed.

Tag example:

<container>

Values for type attribute:

Choose required type attribute as appropriate. Typical values would be:

type="box"
type="folder"
type="reel"
type="frame"
type="box-folder"
type="box/folder"
type="item"
type="mss"

Comments:

Container numbers and control numbers are used to identify physical housing aspects such as boxes, folders, and reels of microfilm. Setting the correct type attribute to identify variety of container will allow appropriate displays to be generated. Labels may be used to provide further information specific to the container.
The arrangement of the physical collection into containers is less important than the intellectual order; therefore, the nesting of components within the container list is based on intellectual order. When container information is given in a finding aid, it should be associated with each component level to provide the clearest association between the intellectual description and information required for physical retrieval.
Recommended minimum best practice is that container information such as box, box/folder, or reel numbers given in a finding aid should be repeated at the lowest (e.g., folder) level for better search results, data extraction, and navigation of long lists of headings.
Recommended practice requires that the type attribute be set for each container as its value is used to correctly label container number displays.

Repeated container information:

When container information is listed in a finding aid, it should be given at each component level to clearly associate intellectual description with information needed for retrieval.
Some display options for repeated information are to display as encoded, suppress repeated information, or to subordinate the container information to the intellectual descriptions.
When box and folder numbers are included in a finding aid, it is also possible to use the "parent" attribute of the container element to associate folder numbers with a box number without repeating the box number. For more information see Section 7.2.5 of the Application Guidelines.

TYPE attribute:

The type attribute should be set in order to generate a display constant to accompany the container number (e.g., Box 17, Folder 2, Reel 4, etc.) Multiple types of containers may be indicated.
Do not include information as part of the container number value which is already expressed as part of the attribute value. If you encode <container type="folder">Folder 1</container>, your display will be FOLDER Folder 1.
While the type attribute should be used to indicate the basic nature of the storage device, it is not necessary to use the most specific type available when the display need not be labeled as such. For instance, box/folder numbers in Music Division finding aids could be coded as <container type="box-folder">2/16</container> but could also validly be encoded as <container type="box">2/16</container> and displayed as "Box 2/16".

Similarly, an oversized container could be encoded <container type="oversize">2</container> to display as "Oversize 2", but could also be encoded as <container type="box">OV 2</container> with display "Box OV 2."

LABEL attribute:

label attributes can be used to record information about containers in addition to the type value: for instance <container type="box" label="restricted">13</container> could be displayed as Box 13 (Restricted).
In some cases container-type information can be recorded as a label attribute to an empty <container> tag. In this case, no type attribute would be set. Example: <container label="not filmed"></container> would display as "Not filmed" in lieu of a container number.

Container numbers and box breaks:

If the lowest component level is broken between two or more containers, statements of extent for the contents of each container and the container numbers will be recorded within the same component and <did>. See Example 6 for this discouraged but sometimes unavoidable practice. Best practice in arranging and describing such components creates subordinate components based on the arrangement, when possible. See Example 7 for a possible resolution to problem illustrated in Example 6.

Additional tagging examples:

Example 1: type attribute set; container numbers repeated

Text

Tagging

Display option 1: type attribute used to generate display label for container numbers in left column

Box 1

Folder 1 Reel 1

Correspondence, 1912-1962

<c02 level="file">
 <did>
 <container type="box">1</container>
 <container type="folder">1</container>
 <container type="reel">1</container>
 <unittitle>Correspondence
 <unitdate type="inclusive">1912-1962</unitdate>
 </unittitle>
 </did>
</c02>

Folder 2

Diaries, 1955-1962

<c02 level="file">
 <did>
 <container type="box">1</container>
 <container type="folder">2</container>
 <container type="reel">1</container>
 <unittitle>Diaries
 <unitdate type="inclusive">1955-1962</unitdate>
 </unittitle>
 </did>
</c02>

Note: display of repeated container numbers suppressed

Display option 2 of Example 1: type attribute used to generate display label for container numbers in left column

Box 1

Folder 1

Reel 1

Correspondence, 1912-1962

Box 1

Folder 2

Reel 1

Diaries, 1955-1962

Note: all container numbers displayed

Example 2: type attribute set for multiple container types

Text

Tagging

Box

Item 1

Diary, 1912

<c02 level="file">
 <did>
 <container type="box">5</container>
 <container type="item">1</container>
 <unittitle>Diary
 <unitdate type="inclusive">1912</unitdate>
 </unittitle>
 </did>
</c02>

Box 5

Item 2

Journal, 1924-1925

<c02 level="file">
 <did>
 <container type="box">5</container>
 <container type="item">2</container>
 <unittitle>Journal
 <unitdate type="inclusive">1924-1925</unitdate>
 </unittitle>
 </did>
</c02>

Box 5

Item 3

Scrapbook, 1917

<c02 level="file">
 <did>
 <container type="box">5</container>
 <container type="item">3</container>
 <unittitle>Scrapbook
 <unitdate type="inclusive">1917</unitdate>
 </unittitle>
 </did>
</c02>

Example 3: Box/folder numbers and oversize identified with less specific attribute value 'box'

Text

Tagging

Box 328/1-28

October 1983-October 1987

<c03 level="file">
 <did>
 <container type="box">328/1-28</container>
 <unittitle>
 <unitdate type="inclusive">October 1983-October 1987</unitdate>
 </unittitle>
 </did>
</c03>

Box OV 1

January 1988-December 1992

<c03 level="file">
 <did>
 <container type="box">OV 1</container>
 <unittitle>
 <unitdate type="inclusive">January 1988-December 1992</unitdate>
 </unittitle>
 </did>
</c03>

Example 4: type and label attributes set

Text

Tagging

Box 26 (Restricted)

Financial records, 1986-1995

<c02 level="file">
 <did>
 <container type="box" label="Restricted">26</container>
 <unittitle>Financial records
 <unitdate type="inclusive">1986-1995</unitdate>
 </unittitle>
 </did>
</c02>

Example 5: label attribute value displays where no container number given

Text

Tagging

Box 61

Reel 43-44

United States Post Office patronage, political and postmaster lists, 1860-1865

<c02 level="file">
 <did>
 <container type="box">61</container>
 <container type="reel">43-44</container>
 <unittitle>United States Post Office patronage, political and postmaster lists,
 <unitdate type="inclusive">1860-1865</unitdate>
 </unittitle>
 </did>
</c02>

Box 62

Not filmed

Financial papers

<c02 level="file">
 <did>
 <container type="box">62</container>
 <container label="Not filmed">
 <unittitle>Financial papers</unittitle>
 </did>
</c02>

Example 6: Contents of lowest-level component spans containers (preferred descriptive practice in Example 7)

Text

Tagging

Box 16-17

Reviews, 1955-1957, undated

<c04 level="file">
 <did>
 <container type="box">16-17</container>
 <unittitle>Reviews
 <unitdate type="inclusive">1955-1957</unitdate>
 </unittitle>

Box 16

(2 folders)

<container type="box">16</container>
 <physdesc>
 <extent>(2 folders)</extent>
 </physdesc>

Box 17

(3 folders)

<container type="box">17</container>
 <physdesc>
 <extent>(3 folders)</extent>
 </physdesc>
 </did>
</c04>

Example 7: Preferred practice to create subordinate component levels where container breaks occur

Text

Tagging

Reviews [Box 16-17]

<c04 level="file">
 <did>
 <container type="box">16-17</container>
 <unittitle>Reviews</unittitle>
 </did>

1955-1956 [Box 16] (2 folders)

<c05 level="file">
 <did>
 <container type="box">16</container>
 <unittitle>
 <unitdate type="inclusive">1955-1956</unitdate>
 </unittitle>
 <physdesc>
 <extent>(2 folders)</extent>
 </physdesc>
 </did>
 </c05>

1957 [Box 17] (3 folders)

<c05 level="file">
 <did>
 <container type="box">17</container>
 <unittitle>
 <unitdate type="inclusive">1957</unitdate>
 </unittitle>
 <physdesc>
 <extent>(3 folders)</extent>
 </physdesc>
 </did>
 </c05>
</c04>

Note: display subordinates container information by placement to right of text and smaller font

unitid

ID of the Unit

At the component level, <unitid> is used for unique logical identifiers associated with that component, such as a file number or lot number; it should not be confused with the <container> element, which is used to identify physical housing aspects such as boxes, folders, and reels of microfilm. Both container numbers and ID numbers may be used in a single container list.

Use the ID of the Unit <unitid> element to designate control numbers not associated with a physical container, for example, accession numbers.

Additional tagging examples:

Example 1 (adapted from LC): Lot numbers assigned by repository using <unitid> given at each component level

Text

Tagging

People and groups, circa 1884-1967
Call no.: LOT 13074

<c01 level="series">
 <did>
 <unittitle>People and Groups
 <unitdate type="inclusive" normal="1884/1967">circa 1884-1967</unitdate>
 </unittitle>
 <unitid label="Call no.:">LOT 13074</unitid>
 </did>

Identified individual portraits
Call no.: LOT 13074

<c02 level="file">
 <did>
 <unittitle>Identified individual portraits</unittitle>
 <unitid label="Call no.:">LOT 13074</unitid>
 </did>

Adams, A., Mr.
Call no.: LOT 13074, no. 1(F)

<c03 level="file">
 <did>
 <unittitle>Adams, A., Mr.</unittitle>
 <unitid label="Call no.:">LOT 13074, no. 1(F)</unitid>
 </did>
 </c03>

Adams, Oscar
Call no.: LOT 13074, no. 2(F)

 <c03 level="file">
 <did>
 <unittitle>Adams, Oscar</unittitle>
 <unitid label="Call no.:">LOT 13074, no. 2(F)</unitid>
 </did>
 </c03>

Addington, Wendell
Call no.: LOT 13074, no. 3(F)

<c03 level="file">
 <did>
 <unittitle>Addington, Wendell</unittitle>
 <unitid label="Call no.:">LOT 13074, no. 3(F)</unitid>
 </did>
 </c03>
 </c02>
</c01>

Example 2: Case numbers assigned by creator using <unitid> in Container List also having container elements

Text

Tagging

Box I: 267
Case Files, 1971-1975

<c02 level="subseries">
 <did>
 <container type="box">I:267</container>
 <unittitle>Case Files
 <unitdate type="inclusive" normal="1971/1975">1971-1975</unitdate>
 </unittitle>
 </did>

Opinions

<c03 level="file">
 <did>
 <unittitle>Opinions</unittitle>
 </did>

71-237
Mancusi v. Stubbs

<c04 level="file">
 <did>
 <unitid>71-237</unitid>
 <unittitle>Mancusi v. Stubbs</unittitle>
 </did>
 </c04>

71-244
In re Little

<c04 level="file">
 <did>
 <unitid>71-244</unitid>
 <unittitle>In re Little</unittitle>
 </did>
 </c04>
 </c03>
</c02>

unittitle

Title of Unit

Title of component materials being described. This may be the title of a series, of a folder, or of any intermediate level of description.

Recommended practice is to include unittitle information within each component <did>. Dates of component material are encoded as <unitdate> within the <unittitle>.

Tag example:

<unittitle>

Other Attributes:

id (use if the <unittitle> is the target of a link, e.g., from another component or from the Scope and Content note).

See Tag Library for full list of valid subelements, e.g., <title> for published works named in the <unittitle>.

Status:

Required

Comments:

Finding aids for collections largely comprised of published material may take advantage of the availability within <unittitle> of <title>, <edition>, <bibseries>, and <imprint> to more precisely encode bibliographic-style data.
Note that some <unittitle> elements consist solely of <unitdate> information. Where no <unittitle> content exists (or if a <unittitle> is meant to be "inherited" by succeeding entries), but dates are provided, include a <unittitle> element and place the date(s) inside <unitdate>. It is strongly recommended that titles be used at the component level. If a title is not provided because it has already been stated in a previous entry (and is meant to be "inherited" by succeeding entries), but dates are provided, a <unittitle> element is still required with dates stated inside <unitdate>. e.g., for a series entitled "Correspondence," subseries titles are not required if "Correspondence" is assumed to apply to all entries in the series.

However, dates or date spans would be encoded in <unittitle><unitdate> at the subseries level.
EAD permits the use of <unitdate> either as a subelement of <unittitle> or used at the same level as <unittitle>. Practice in the United States has been based on the cataloging guidance of APPM, which regards date information as part of the title. European and Canadian practice, following ISAD-G, regards <unitdate> as an independent element. It is important that these practices never be mixed in a single document.
Practice: <unitdate> should be stated within <unittitle>.

Additional tagging examples:

Example 1 (adapted from LC): <unittitle> for series includes ID attribute since links have been made to the series title

Text

Tagging

Series I. Office Files, 1933-1988, undated

<c01 level="series">
 <did>
 <unittitle id="cloffice">Series I. Office Files
 <unitdate type="inclusive" normal="1933/1988">1933-1988</unitdate>,
 <unitdate>undated</unitdate>
 </unittitle>
 </did>

Box 1

Abramovitz, Gerald, 1968-1975, 1985

<c02 level="file">
 <did>
 <container type="box">1</container>
 <unittitle>Abramovitz, Gerald,
 <unitdate type="inclusive">1968-1975</unitdate>,
 <unitdate type="inclusive">1985</unitdate>
 </unittitle>
 </did>
 </c02>
</c01>

Example 2 (adapted from LC): <imprint> and <bibseries> within <unittitle>

Text

Tagging

Eastern Asia 1:1,000,000. Canton

<c03 level="file">
 <did>
 <unittitle>Eastern Asia 1:1,000,000. Canton

Washington, D.C. : United States Army, 1945.

 <imprint>
 <geogname role="Place of Pub">Washington, D.C.</geogname>
 <publisher>United States Army,</publisher>
 </imprint>
 <unitdate type="inclusive">1945</unitdate>
 </unittitle>

Sheet NF 49, "Canton", 1st Edition-AMS 3 A.M.S. 5301

<bibseries>Sheet <num>NF 49</num>, "Canton", 1st Edition-AMS 3 A.M.S. 5301</bibseries>
 </did>
</c03>

unitdate

Date of Unit

Dates of the materials comprising each component; the dates may be given as inclusive, bulk, or both.

Best practice requires the inclusion of unitdate information at appropriate component levels within the Description of Subordinate Components.

Tag example:

<unitdate>

Other Attributes:

type="inclusive" or "bulk" Recommended
normal (normalize according to ISO 8601 in yyyy-mm-dd format) Recommended through subseries level

Comments:

Date information is important for good descriptive practice; while this information is not always readily available (especially in legacy finding aids), every effort should be made to include this information.
All material date information should be encoded as <unitdate>, no matter what the component level.
Normalization attributes should be set for dates through the subseries level to take advantage of date searching.
Note that some <unittitle> elements consist solely of <unitdate> information. Where no <unittitle> content exists (or if a <unittitle> is meant to be "inherited" by succeeding entries), but dates are provided, include a <unittitle> element and place the date(s) inside <unitdate>.
Set the type attribute of <unitdate> to "inclusive" by default, and to "bulk" as needed. Inclusive is considered appropriate even for single years, since it is assumed that the date includes materials from different times throughout the entire year.
A bulk <unitdate> element can be used in conjunction with an inclusive to further specify preponderance of materials. <unittitle>Correspondence<unitdate type="inclusive">(1956-1965), </unitdate><unitdate type="bulk">1961-1962</unitdate></unittitle>
Use of <unitdate> is strongly recommended if a more specific creation date can be provided for a component than given in its parent description. Such entries provide a fuller description of a unit for researchers and improve searching by date. If multiple date ranges are present, each should be encoded with its own <unitdate>. If no date is available or applicable for a particular component, use the term "undated" inside the <unitdate> tags.
EAD permits the use of <unitdate> either as a subelement of <unittitle> or used at the same level as <unittitle>. Practice in the United States has been based on the cataloging guidance of APPM, which regards date information as part of the title. European and Canadian practice, following ISAD-G, regards <unitdate> as an independent element. It is important that these practices never be mixed in a single document.
Practice: <unitdate> should be stated within <unittitle>.

Additional tagging example:

Example 1 (adapted from LC): <unitdate> encoded at all component levels; type and normal attributes set according to UB Practices ; (with id attribute used to enable internal linking)

Text

Tagging

Series I. Journals and Notebooks, 1908-1946

<c01 level="series">
 <did>
 <unittitle id="cljournals">Series I. Journals and Notebooks
 <unitdate type="inclusive" normal="1908/1946">1908-1946</unitdate>
 </unittitle>
 </did>

Box 2

1941

<c02 level="file">
 <did>
 <container type="box">2</container>
 <unittitle>
 <unitdate type="inclusive">1941</unitdate>
 </unittitle>
 </did>

Apr.-May, trip to England

<c03 level="file">
 <did>
 <unittitle>
 <unitdate type="inclusive">Apr.-May</unitdate>
 trip to England</unittitle>
 </did>
 </c03>

July-Aug., Roosevelt-Churchill Conference, Placentia Bay, Newfoundland

<c03 level="file">
 <did>
 <unittitle>
 <unitdate type="inclusive">July-Aug</unitdate>,
 Roosevelt-Churchill Conference, Placentia Bay, Newfoundland</unittitle>
 </did>
 </c03>
 </c02>
</c01>

physdesc

Physical Description

Statement of extent regarding an individual component, such as folder or volume count.

Best Practice recommends the inclusion of physical description information as appropriate to indicate when a single intellectual component includes more than one physical component. Include folder and volume counts within the <extent> subelement of <physdesc>.

Tagging example 1:

<c03 level="file">
 <did>
 <container type="box-folder">6.11-7.5</container>
 <unittitle>Curriculum Committee
 <unitdate>1965-1966;</unitdate>
 includes Phase I, II, III, resources used, correspondence.</unittitle>
 <physdesc>
 <physfacet>disassembled notebook</physfacet>
 </physdesc>
 <physdesc>
 <extent>9 folders</extent>
 </physdesc>
 </did>
</c03>

Example 2 (adapted from LC): Folder count and volume count both encoded as <physdesc><extent>

Text

Tagging

Correspondence, 1960-1965

<c02 level="file">
 <did>
 <unittitle>Correspondence
 <unitdate type="inclusive">1960-1965</unitdate>
 </unittitle>

(2 folders)

<physdesc>
 <extent>(2 folders)</extent>
 </physdesc>
 </did>
</c02>

Diaries, 1902

<c02 level="file">
 <did>
 <unittitle>Diaries
 <unitdate type="inclusive">1902</unitdate>
 </unittitle>

(3 vols.)

<physdesc>
 <extent>(3 vols.)</extent>
 </physdesc>
 </did>
</c02>

Subelements:

See descriptions under <physdesc> in high-level <did> above, as well as Tag Library for discussion of subelements <dimensions> and <physfacet>.

Comments:

Use <physdesc><extent>, since extent is a required element in ISAD-G.
The <physdesc> element may provide general and detailed information about the presence and nature of the formats of material present within a collection (i.e. photographs, nitrate film, computer disks, etc.). The tag may be used by itself for narrative description or in conjunction with further tags for more specific description of the materials. Of primary use are the <extent>, <dimensions>, and <physfacet> tags. Inclusion of this information is optional and will be determined by each institution based on time and resources, researcher needs, and preservation concerns. It is mostly likely to be used at the <c01 level="series"> component level for a group of materials.
Note that the <physdesc> element must be outside <unittitle> but within <did>. The <physdesc> is not the same as the information encoded within the <container> element.
The <physfacet> tag is used for more narrative descriptions of the appearance of an item or series of items. Although this can be handy, there is no need to use this tag if the material can be described within the confines of the other three tags.
Practice: note that <genreform> will only be used within <controlaccess> in University at Buffalo finding aids.

abstract

Abstract

Do not use <abstract> at the component level; restrict its use to the Collection Overview. Use <scopecontent> at the component level.

physloc

Physical Location Information

At the component level, <physloc> is used to specify a physical location for that component which differs from the rest of the collection (such as offsite storage, or housing in a separate custodial unit).

Tag example (adapted from LC): <physloc> indicates repository material physically housed elsewhere in Library

Text

Tagging

Series II: Sound Recordings

<c01 level="series">
 <did>
 <unittitle id="series2">Series II: Sound Recordings</unittitle>

The originals and preservation masters are located in Motion Picture, Broadcasting, and Recorded Sound (M/B/RS) at the Library of Congress. See Collection Concordance by Format.

<physloc>The originals and preservation Masters are located in Motion Picture, Broadcasting, and Recorded Sound (M/B/RS) at the Library of Congress. See Collection Concordance by Format.</physloc>
 </did>
</c01>

Expanded Description of Components

Elements which are available to describe the collection as a whole may also be used outside the <did> at the component level to which they best apply. Such elements include <scopecontent> and <arrangement>, as well as elements formerly subordinate to <admininfo> and <add>. Other <did> subelements not separately described in the Application Guidelines are also illustrated here. Use <arrangement> for statements about organization or arrangement within the component.

Comments:

Use <scopecontent> rather than <abstract> or <note> for summary descriptions of the contents of a component. Scopecontent may be very brief or may contain multiple paragraphs.
When <note> is appropriate, use inside the <did> rather than outside for convenience in generating displays.
Use <odd> for component information which does not correspond to another element's definition, for information of mixed content, when additional narrative description is included, and when more specific tagging would be too burdensome or costly.
Use <scopecontent> and <arrangement> at the series level to describe contents of the series and arrangement or organization therein. Although <arrangement> is available inside the <scopecontent>, encoding <arrangement> at the same level as <scopecontent> is recommended . Sometimes arrangement will be inextricably intertwined with scope information and cannot be marked separately.
The use of elements subordinate to <descgrp type="admininfo"> and <descgrp type="userinfo"> at the component level will usually be a supplement to general information already given at the collection level. For instance, the collection-level <descgrp> will have an <accessrestrict> statement that some material within the collection is restricted. At the appropriate component level (e.g., within <c01> for a restricted series), you may note within <accessrestrict> that the series is restricted.
Use <daogrp> and its subelement <daoloc> for one or more archival objects.
Use <daogrp> in components at the folder or item level when digitization has taken place selectively. Even if links are made to single intellectual items, the <daoloc> link will probably point to a presentation mechanism which allows options between various versions of the object (jpeg, tif, etc.), or navigation among the parts of an object (pages of a multipage document). Direct links to single digital files are possible but not encouraged: it is better to stay within the framework of digital file storage and navigation already established.
Use <daogrp> at the series (or subseries) level when most or all of a collection or series has been digitized and there are external navigational aids, which mirror the arrangement in the container list.
When multiple items in a folder are digitized and description stops at the folder level, the <daoloc> will probably point to a hit list whose links point to the items within the folder, probably not in the order found in the physical folder.

Tag examples:

Example 1 (adapted from LC): Component described with <scopecontent> (2 paragraphs)

Text

Tagging

998 NBC Network Affiliates, 1935-1989

<c02 level="file">
 <did>
 <container type="folder">998</container>
 <unittitle>NBC Network Affiliates
 <unitdate type="inclusive">1935-1989.</unitdate>
 </unittitle>
 </did>

Original, onionskin, mimeographed, and photocopied letters, memoranda, reports, maps, press releases, and telegrams related to the NBC network and affiliates.

 <scopecontent>
 Original, onionskin, mimeographed, and photocopied letters, memoranda, reports, maps, press releases, and telegrams related to the NBC network and affiliates.

Highlights: February 5, 1937, 42-page "Report on the Study for Improving National Broadcasting Company Network Facilities." April 17, 1939, NBC network facilities map. June 28, 1934, 3-page letter from WSYR of Syracuse, New York to NBC complaining of NBC's neglect of the Blue Network in favor of the Red Network. May, 1951 4-page report on the growth and development of the NBC television network.

Highlights: February 5, 1937, 42-page "Report on the Study for Improving National Broadcasting Company Network Facilities." April 17, 1939, NBC network facilities map. June 28, 1934, 3-page letter from WSYR of Syracuse, New York to NBC complaining of NBC's neglect of the Blue Network in favor of the Red Network. May, 1951 4-page report on the growth and development of the NBC television network.
 </scopecontent>
</c02>

Example 2 (adapted from LC): with <note> within <did>

Text

Tagging

Box 3

<c02 level="file">
<did>
 <container type="box">3</container>

Computer diskettes containing documents generated during collection processing, documents/files used to build the online presentation, and backup copies

<unittitle>Computer diskettes containing documents generated during collection processing, documents/files used to build the online presentation, and backup copies</unittitle>

Note: Disk directories can be found in Folder #1 with the Collection Guide.

<note>
 Note: Disk directories can be found in Folder #1 with the Collection Guide.
 </note>
 </did>
</c02>

Example 3 (adapted from LC): with <materialspec> and <odd> for map elements

Text

Tagging

Eastern Asia 1:1,000,000. Canton

<c03 level="file">
 <did>
 <unittitle>Eastern Asia 1:1,000,000. Canton</unittitle>

1 map; 660 x 710cm.

<physdesc>
 <extent>1 map</extent>
 <dimensions>660 x 710cm.</dimensions>
 </physdesc>

Scale: 1:100,000

 <materialspec type="scale">1:100,000</materialspec>

Projection: Modified Polyconic

 <materialspec type="projection"> Modified Polyconic</materialspec>
 </did>

Notes: Accompanied by graphic flight line index (incomplete).
Sortie 35PR 4MH 29. Height 30,000ft.

<odd type="notes">
 Accompanied by graphic flight line index (incomplete).
 Sortie 35PR 4MH 29. Height 30,000ft.
 </odd>
</c03>

Example 4 (adapted from LC): Includes <scopecontent>, <arrangement>, and <altformavail>

Text

Tagging

Box 1-3

Series I. Diaries, 1910-1945.

<c01 level="series">
 <did>
 <container type="box">1-3</container>
 <unittitle id="diary">Series I. Diaries
 <unitdate type="inclusive" normal="1910/1945">1910-1945.</unitdate>
 </unittitle>
 </did>

Holograph and typewritten diaries, bound and unbound.

 <scopecontent>
 Holograph and typewritten diaries, bound and unbound.
 </scopecontent>

Arranged in two groups, original and annotated transcripts, and therein chronologically.

 <arrangement>
 Arranged in two groups, original and annotated transcripts, and therein chronologically.
 </arrangement>

The diary for Sept. 24-Mar. 5, 1943, is available on microfilm. Shelf no. 20,613.

 <altformavail>
 The diary for Sept. 24-Mar. 5, 1943, is available on microfilm. Shelf no. 20,613.
 </altformavail>
</c01>

Example 5 (adapted from LC): Restricted container noted at component level and as container attribute

Text

Tagging

Box 50-56

Financial Papers, 1936-1969

<c02 level="subseries">
 <did>
 <container type="box">50-56</container>
 <unittitle>Financial Papers
 <unitdate type="inclusive" normal="1936/1969">1936-1969</unitdate>
 </unittitle>
 </did>

Correspondence, accounting statements, reports, and printed matter concerning financial contributions and other fund-raising activities as well as the general financial situation of the colony.

 <scopecontent>
 Correspondence, accounting statements, reports, and printed matter concerning financial contributions and other fund-raising activities as well as the general financial situation of the colony.
 </scopecontent>

Arranged alphabetically by subject.

<arrangement>
 Arranged alphabetically by subject.
 </arrangement>

Container 56 is restricted until 1999.

<accessrestrict>
 Container 56 is <emph render="bold">restricted</emph>until 1999.
 </accessrestrict>

Box 56 (Restricted)

Financial problems

<c03 level="file">
 <did>
 <container label="restricted" type="box">56</container>
 <unittitle>Financial problems</unittitle>
 </did>

Finance Committee, 1957-1967

<c04 level="file">
 <did>
 <unittitle>Finance Committee
 <unitdate type="inclusive">1957-1967</unitdate>
 </unittitle>
 </did>
 </c04>
 </c03>
</c02>

Example 6 (adapted from LC): <daogrp> link at folder level to hit list of digitized items

Text

Tagging

Photograph album

<c02 level="file">
 <did>
 <unittitle id="clgencorr">Photograph album</unittitle>

Items available online.

<daogrp>
 <daoloc href="mcc051">
 <daodesc>
 Items available online.
 </daodesc>
 </daoloc>
 </daogrp>
 </did>
</c02>

This ends the /dsc section

controlaccess

Controlled Access Headings

Tag Library Definition:

A wrapper element that designates key access points for the described materials and enables authority-controlled searching across finding aids on a computer network. Hundreds of names and subjects can appear in a finding aid. Prominence can be given to the major ones by bundling them together in a single place within the <archdesc> or within a large Component <c> and tagging them with <controlaccess>.

The <controlaccess> element designates terms comparable to those found in the 1xx, 6xx, and 7xx fields of MARC catalog records. Finding aid searches limited to the <controlaccess> element and its subelements will improve the likelihood of locating strong sources of information on a desired subject, because access terms will have been entered in a consistent form across finding aids, and also because only the most significant terms are likely to have been selected for encoding.

Although names and terms from locally controlled vocabularies are permissible, the <controlaccess> subelements (<corpname>, <famname>, <function>, <genreform>, <geogname>, <occupation>, <persname>, <subject>, and <title>) should come from national or international vocabularies whenever they are available to enable searches in information systems that include multiple finding aids, or finding aids and bibliographic records from many institutions.

These subelements have source attributes to specify the vocabulary tool from which the heading is taken and rulesattributes to specify the descriptive rules by which it has been formulated. The attribute authfilenumber can be used to identify an authority file record that provides additional information about a heading and includes cross references. The role attribute can be used to specify such factors as whether a heading is for the creator of the materials, the subject of the materials,or both.

Controlled vocabulary terms may be given in a single list of terms, or may be grouped according to the needs of the collection and the needs of the division by means of nesting <controlaccess> clusters within a single <controlaccess>.

Tag example:

<controlaccess>
 <head>Search Terms</head>
 <note>The following terms have been used to index the description of this collection in the Library's online catalog:</note>
 [List of terms - see specific tagging in examples that follow.]
</controlaccess>

Subelements:

All elements are repeatable except <head>. Inclusion of all subject and added entry terms from the collection-level catalog record is recommended.

<head>
<note>
<persname>: Personal Names
<corpname>: Corporate Names
<famname>: Family Names
<geogname>: Geographic Names
<name>: Personal, Corporate, Family, and Geographic Names
<genreform>: Form and Genre Terms
<function>: Function Terms
<occupation>: Occupation Terms
<subject>: Subjects
<title>: Titles

Status:

Required

Repeatable:

Comments:

Controlled access terms are an important means of providing uniform searchability of encoded finding aids. At a minimum, the same controlled access terms should be encoded in EAD as in the MARC record for the collection. Failure to include such terms will result in the omission of key names and subjects from browse lists for LC finding aids, and will hinder searching based on the presence of such terms.
Controlled access terms are most commonly used to describe the collection level in a finding aid. They may also be assigned to their most specific descriptive level, as multilevel description allows. For instance, subject access may be provided at the series level when that topic is represented in only that series. However, the added expenses in identifying these specific headings and maintaining them in multiple locations in a finding aid make this option less attractive than it might be from a purely intellectual standard.
An introductory note explaining the nature and source of the search terms will aid researchers in understanding this potentially confusing list. This note may be put directly within paragraph tags but preferred practice is to encode as a note, for better manipulation of its display.
Practice: University at Buffalo finding aids will not apply <controlaccess> at the series or component level, only at the collection level.

Grouping Controlled Vocabulary Terms

Practice: University at Buffalo Finding aids will use the following groupings:

Heading

Contents

MARC Fields

Contributors

all names (personal, family, corporate, and geographic names in one alphabetical ordering) of contributors to the collection; that is, entities responsible for content such as correspondence, images, scores, etc.

1XX and 7XX

Subjects

all topical subject headings, geographic names as subjects, and names as subjects

6XX with exception of 655, 656 (occupations), and 657 (functions)

Genres

all forms and genres of materials contained within the collection

655

Tag example:

Text

Tagging

Search Terms

<controlaccess>
<head>Search Terms</head>

The following terms have been used to index the description of this collection in the Library's online catalog.

<note>
The following terms have been used to index the description of this collection in the Library's online catalog.</note>

Contributors

<controlaccess>
<head>Contributors</head>

Anthony, Susan B. (Susan Brownell), 1820-1906

<persname source="lcnaf" encodinganalog="100" role="creator">Anthony, Susan B. (Susan Brownell), 1820-1906</persname>

Doubleday and Company, Inc. Records

<corpname source="lcnaf" encodinganalog="710">Doubleday and Company, Inc. Records</corpname>

Inter-American Conference for the maintenance of peace, Buenos Aires, 1936. Records

<corpname source="lcnaf" encodinganalog="711">Inter-American Conference for the maintenance of peace, Buenos Aires, 1936. Records</corpname>
</controlaccess>

Subjects

<controlaccess>
<head>Subjects</head>

Afro-Americans--Suffrage

<subject source="lcsh" encodinganalog="650">Afro-Americans--Suffrage</subject>

American Anti-Slavery Society

<corpname source ="lcnaf" encodinganalog="610" role="subject">American Anti-Slavery Society</corpname>

Blackwell family

<famname source="lcnaf" encodinganalog="600" role="subject">Blackwell family</famname>

Bloomer, Amelia Jenks, 1818-1894

<persname source="lcnaf" encodinganalog="600" role="subject">Bloomer, Amelia Jenks, 1818-1894</persname>

Lexington observer and reporter

<subject encodinganalog="630" source="lcnaf">Lexington observer and reporter</subject>

Lincoln, Abraham, 1809-1865--Assassination

<persname source="lcnaf" encodinganalog="600" role="subject">Lincoln, Abraham, 1809-1865--Assassination</persname>

Mott, Lucretia, 1793-1880

<persname source="lcnaf" encodinganalog="600" role="subject">Mott, Lucretia, 1793-1880</persname>

National American Woman Suffrage Association

<corpname source="lcnaf" encodinganalog="610" role="subject">National American Woman Suffrage Association</corpname>

Pan-American Conference (1933 : Montevideo, Uruguay)

<corpname encodinganalog="611" role="subject">Pan-American Conference (1933 : Montevideo, Uruguay)</corpname>

Temperance

<subject source="lcsh" encodinganalog="650">Temperance</subject>

United States--Politics and government--19th century

<geogname source="lcsh" encodinganalog="651">United States--Politics and government--19th century</geogname>

Women--Suffrage

<subject source="lcsh" encodinganalog="650">Women--Suffrage</subject>

Women's rights

<subject source=" lcsh" encodinganalog="650">Women's rights</subject>
</controlaccess>

Genres:

<controlaccess>
<head>Genres:</head>

Portraits

<genreform encodinganalog="655" source="gmgpc">Portraits</genreform>
</controlaccess>
</controlaccess>

Attributes in <controlaccess> subelements:

Using the source, encodinganalog, and role attributes will increase the precision and usability of information recorded in <controlaccess> subelements such as <persname>, <subject>, etc. by permitting better crosswalks and mapping of data between finding aids and MARC catalog records, as well as more precise indexing.

source (code list of values includes (See definitions for abbreviations in Appendix 13 - Source attribute values): aat, cdwa, gmgpc, lcnaf, lcsh, lctgm, local, mesh, mim, ncarules, nmc, rbgenr, tgn, ulan) required, except when rules are given instead
encodinganalog: Required
role (can use role="subject" to distinguish names used as subjects, i.e., 6xx fields, from names used as added entries, i.e., 7xx fields. Use role="collector" for names of originators acting as collectors and role="creator" for originators acting as creators, whether personal or corporate, and whether main or added entry) Recommended
rules (code list of values: aacr2, dacs, appm) Recommended in lieu of source as appropriate

Comments on use of attributes:

As the purpose of <controlaccess> is to enable searching by terms used nationally and internationally, make every effort to use controlled vocabulary as index terms.
If subject terms must be used which are not found in any extant thesaurus, set the value on the source attribute as "local."
The rules attribute can be used to specify the descriptive rules followed when formulating the term, such as "aacr2" or "dacs". This attribute is optional and should be used only when the term is not already found in a standard authority list or thesaurus identified with the source attribute, such as a term formulated following the provisions of AACR2 but not found in the LCNAF.
The role attribute may be set to indicate relationships expressed in relator terms (e.g., collector, contributor) as well as that for a name is functioning as a subject.
Note: since the relatedencoding attribute has already been set to "MARC21" at the <archdesc> level, it is not necessary to include "MARC21" as part of the encodinganalog attribute.

Personal, Corporate, Family, and Geographic Names

Personal names, corporate names, family names, and geographic names in their authorized form (as found in the LC Name Authority File, LCSH, or other sources) are encoded exactly as found in that source in the <controlaccess> section, whether in a single alphabetical list or grouped into categories. A nonspecific element, <name>, may also be used when a name seems particularly significant, but it is not known what kind of name is being described (e.g., personal, corporate, or geographic). Since a name being specifically encoded can be identified by type using the authority files, use of this element should be rare, especially within <controlaccess>.

Practice: As previously stated under the description of UB Practice for grouping controlled access terms, names are treated as either contributor or subject in University at Buffalo finding aids.

Tag example:

<controlaccess>
<head>Search Terms</head>
<note>
The following terms have been used to index the description of this collection in the Library's online catalog.
</note>
<controlaccess>
<head>Contributors:</head>
<persname source="lcnaf" encodinganalog="100" role="creator">Astin, Allen Varley, 1904-1984</persname>
<persname source="lcnaf" encodinganalog="700">Astin, John.</persname>
</controlaccess>

<controlaccess>
<head>Subjects:</head>
<famname source="lcnaf" encodinganalog="600" role="subject">Astin family</famname>
<persname source="lcnaf" encodinganalog="600" role="subject">Bunche, Ralph J. (Ralph Johnson), 1904-1971</persname>
<geogname source="lcsh" encodinganalog="651" role="subject ">Great Britain--Armed Forces</geogname>
<persname source="lcnaf" encodinganalog="600" role="subject">Sikorsky, Igor Ivan, 1889-1972--Correspondence
</persname>
<corpname source="lcnaf" encodinganalog="610" role="subject">United States. Dept. of State. Bureau of African Affairs
</corpname>
<corpname source="lcnaf" encodinganalog="610" role="subject">United States. National Bureau of Standards</corpname>
</controlaccess>
</controlaccess>

Comments:

Use the complete form of the name as it appears in the authority record (inverted order, birth and death dates if given, titles of address, etc.). Note also that titles of works associated with personal names are not separately encoded.
Repeat the main entry (1xx field) from <origination> to ensure that the browse list of names built from <controlaccess> includes all important terms. Use all the attributes specified for use in <controlaccess>, which will be more than are required within <origination>.
It is possible to use <subarea> within <corpname> for corporate names with subordinate units. Unlike the <repository> area, where use of <subarea> is required because of its immediate usefulness, this specific coding is an option in <controlaccess>.

Subjects and Titles

Topical subjects and titles of works in their authorized form (as found in the LCSH, the LC Name Authority File, or other sources) are encoded exactly as found in that source in the <controlaccess> section, whether in a single alphabetical list or grouped into categories. Remember that names when used as subjects are encoded as <persname>, <corpname>, etc., with the role attribute set to "subject."

Practice: As previously stated under the description of UB Practice for grouping controlled access terms, subjects in University at Buffalo finding aids include both topical subjects and name forms treated as subjects.

Tag example:

<controlaccess>
<head>Search Terms</head>
<note>
The following terms have been used to index the description of this collection in the Library's online catalog.
</note>
<controlaccess>
<head>Subjects</head>
<subject source="lcsh" encodinganalog="650">Afro-American newspapers--New York (State)--Rochester</subject>
<persname source="lcnaf" encodinganalog="600" role="subject">Bunche, Ralph J. (Ralph Johnson), 1904-1971</persname>
<subject source="lctgm" encodinganalog="650">Civil rights leaders</subject>
<title source="lcnaf" encodinganalog="630">North star (Rochester, N.Y.)</title>
</controlaccess>
</controlaccess>

Form and Genre Terms

Controlled vocabulary terms for describing collections by type of material or physical characteristics. Sources for these form and genre terms may come from specialized thesauri, such as those for graphic materials, or from LCSH.

Tag example:

<controlaccess>
<head>Search Terms</head>
<note>
The following terms have been used to index the description of this collection in the Library's online catalog.
</note>
<controlaccess>
<head>Genres</head>
<genreform source="gmgpc" encodinganalog="655">Group portraits--1860-1970</genreform>
<genreform source="gmgpc" encodinganalog="655">Photographic prints--1860-1970</genreform>
<genreform source="gmgpc" encodinganalog="655">Portrait photographs--1860-1970</genreform>
<genreform source="gmgpc" encodinganalog="655">Posters</genreform>
</controlaccess>
</controlaccess>

Function and Occupation Terms

Function terms <function>, describing the spheres of activities and organizational processes that generated the described records, are useful in corporate, government, and institutional archives, but have not been used at the Library. Occupation terms <occupation> identify the profession, business, or avocation of individuals in personal papers and are used at the Library.

Practice: University at Buffalo finding aids will not use <function> or <occupation> in <controlaccess>.

Tag example:

<controlaccess>
<head>Search Terms</head>
<note>
The following terms have been used to index the description of this collection in the Library's online catalog.
</note>
<controlaccess>
<head>Occupations and Functions</head>
<occupation source="itoamc" encodinganalog="656">Abolitionists</occupation>
><occupation source ="itoamc" encodinganalog="656">Diplomats</occupation>
<occupation source ="itoamc" encodinganalog="656">Journalists</occupation>
</controlaccess>
</controlaccess>

This ends the /controlaccess section

descgrp type="add" type="add"

Descriptive Group (Adjunct Descriptive Data)

Library of Congress Definition:

Adjunct Descriptive Data: This wrapper element, new in EAD 2002, can be used to assemble supplemental information that facilitates the use of the materials being described in the finding aid. These additional access tools, such as indexes, file plans, other finding aids, and descriptions of related and separated materials, may occur as" back-of-book" materials directly under <archdesc>, or may be used at the most appropriate component level. Adjunct data which does not fit into the major subelements below should be encoded as other descriptive data (<odd>).

Tag example:

<descgrp type="add">

Subelements in locally recommended order:

All elements are repeatable and may be used in any order. Do not use generic text formatting elements such as , <list> and <table> directly under <descgrp> except to supplement these subelements as appropriate.

<head>: Associated Material
<separatedmaterial>: Separated Material
<bibliography>: Bibliographies
<fileplan>: File Plans
<index>: Indexes
<otherfindaid>: Other Finding Aids
<relatedmaterial>: Related Resources

Status:

Optional

Repeatable:

Not as <descgrp type="add">

Comments:

Adjunct descriptive data that applies to a portion of the collection material may be given at that component level, but this is not a strict requirement. For instance, a lengthy index to a correspondence series might appear after the entire container list as long as it is labeled as such. This would prevent a break in the "flow" of the container list. Note, however, that there is tension between this practice and the principle of multi-level description as described in ISAD-G.
Adjunct descriptive data that applies to the entire collection (e.g., a bibliography or file plan) is considered "back-of-the-book" material but need not appear at the end of the finding aid. After the collection-level <did> (Collection Overview), the order of elements is not fixed and adjunct descriptive data may appear wherever needed. For instance, a description of related material might be as appropriately placed after <scopecontent> as at the end of the container list.
Practice: Although it is possible to use <descrgrp type="add"> without a collective heading for its contents, University at Buffalo finding aids will use the heading, Associated Material, for the entire <descgrp type="add"> section. The use of subelements <separatedmaterial>, <relatedmaterial>, and <bibliography> is recommended as appropriate at the collection level but discouraged at the component level.

separatedmaterial

Separated Material

Tag Library Definition:

Information about materials that are associated by provenance to the described materials but that have been physically separated or removed. Items may be separated for various reasons, including the dispersal of special formats to more appropriate custodial units; the outright destruction of duplicate or nonessential material; and the deliberate or unintentional scattering of fonds among different repositories. Do not confuse with <relatedmaterial>, which is used to encode descriptions of, or references to, materials that are not physically or logically included in the material described in the finding aid but that may be of use to a reader because of an association to the described materials. Items encoded as <relatedmaterial> are not related to the described material by provenance, accumulation, or use.

Tag example:

<separatedmaterial encodinganalog="544">
<head>Separated Material</head>
Published scores have been removed to the General Collection.
</separatedmaterial>

<separatedmaterial encodinganalog="544">
<head>Separated Material</head>
Two issues (vol. 1, no. 1 and vol. 1 no. 3, 1971), of the poetry journal<title render="italic">Earth's Daughters</title>, were removed from the collection and are available in University at Buffalo's Poetry Collection.
American Studies department records were removed to be processed with departmental records at a later date. These records include course catalogs, committee minutes, Native American Studies, and the Buffalo Unemployment Oral documentary.
</separatedmaterial>

Subelements:

<bibref>
<archref>

Generic text formatting elements such as <note>, <list> and <table> can also be used directly under <separatedmaterial>. See Tag Library for full list of valid subelements.

Status:

Optional

Repeatable:

Comments:

Separated material may consist of paragraphs or be in list or table format; it also may consist exclusively of <archref> elements which need no further formatting.

bibliography

Bibliography

Tag Library Definition:

Citations to works that are based on, about, or of special value when using the materials being described, or works in which a citation to or brief description of the materials is available. The works could be books, articles, television programs, unpublished reports, web sites, or other forms of information. The <bibliography> may be a simple <list>, a list of both Bibliographic References <bibref> and Archival References <archref >, or a series of Paragraphs .

The <bibref> element may be used to designate single citations within Paragraphs without opening the < bibliography> element.

Tag example:

Text

Tagging

Bibliography

<bibliography>
<head>Bibliography</head>

 Urban Blues, University of Chicago Press, 1966, revised edition, 1992.

<bibref>
 <title render="italic">Urban Blues</title>, University of Chicago Press, 1966, revised edition, 1992.
 </bibref>

 Tiv Song, University of Chicago Press, 1979.

<bibref>
 <title render="italic">Tiv Song</title>, University of Chicago Press, 1979.
 </bibref>

 (Written with Angeliki Keil and Richard Blau) Polka Happiness, Temple University Press, 1992.

<bibref>
 (Written with Angeliki Keil and Richard Blau)<title render="italic">Polka Happiness</title>, Temple University Press, 1992.
 </bibref>

 (Editor with Sue Crafts and Dan Cavicchi) My Music, Wesleyan University Press, 1993.

<bibref>
 (Editor with Sue Crafts and Dan Cavicchi)<title render="italic">My Music</title>, Wesleyan University Press, 1993.
 </bibref>

 (Written with Steve Feld) Music Grooves: Essays and Dialogues, University of Chicago Press, 1994.

<bibref>
 (Written with Steve Feld)<title render="italic">Music Grooves: Essays and Dialogues</title>, University of Chicago Press, 1994.
 </bibref>

 Bright Balkan Morning: Romani Lives and the Power of Music in Greek Macedonia, Wesleyan University Press (Middletown, CT), 2002.

<bibref>
 <title render="italic">Bright Balkan Morning: Romani Lives and the Power of Music in Greek Macedonia</title>, Wesleyan University Press (Middletown, CT), 2002.
 </bibref>
</bibliography>

Subelements:

<bibref>
<archref>

Generic text formatting elements such as <note>, <list> and <table> can also be used directly under <bibliography>. See Tag Library for full list of valid subelements.

Status:

Optional

Repeatable:

Comments:

The bibliography element can be used to group citations to works of any type, such as books, articles, sound recordings, etc., that are about, based on, or would be helpful to researchers using the described materials. Formatting subelements such as <list> and <table> can be used but are not necessary since formatting can be controlled using style sheets. As with other adjunct descriptive data elements, it can be used at the collection level as well as at the appropriate component level.
Bibliographies are most commonly composed of <bibref> and/or <archref> elements but may also contain explanatory notes or additional formatting.
A variety of elements are available in <bibref>. Generally speaking, the only one that should always be used is the <title> element which should be displayed in a typographically distinct fashion (i.e., in italics). See Example 1 in Appendix 11.
Additional subelements of <bibref> may be used if there is a reason based on searching or display for the elements to be rendered distinctly. For instance, if a bibliography is arranged chronologically, you may wish to separately encode the imprint date. See Example 2 in Appendix 11. Alternately, this could have been encoded without using <bibref> as a <chronlist> within <bibliography>. See Tag Library under <chronlist>.
Both <bibref> and <archref> can be used to link to the materials described if they are available online.
Practice: application of subelements <imprint>, <geogname>, <publisher>, and <date> are optional.

fileplan

File Plan

Tag Library Definition:

Information about any classification scheme used for arranging, storing, and retrieving the described materials by the parties originally responsible for creating or compiling them. A filing plan is usually identified by the type of system used, e.g., alphabetical, numerical, alpha-numerical, decimal, color-coded, etc. It is often hierarchical and may include the filing guidelines of the originating organization. Additional types include a drawing of a room layout or a scientific scheme.

Do not confuse with Other Finding Aid <otherfindaid> which contains references to additional descriptions of the material rather than descriptions of classification schemes by which the materials might still be arranged.

Tag example:

<fileplan>
<head>File List</head>
<note>The list below outlines the classification system used for the central files of Vice President Mondale's office. This structure assigned alpha-numeric codes to primary subjects and to secondary and tertiary subdivisions thereunder.</note>
<fileplan>
<head>Agriculture (AG)</head>
<list type="ordered">
<defitem> <label>1</label>
<item>Home Economics</item>
</defitem>
<defitem> <label>2</label>
<item>Horticulture</item>
</defitem>
</list>
</fileplan>
</fileplan>

Subelements:

Generic text formatting elements such as <note>, , <list> are used directly under <fileplan>. See Tag Library for full list of valid subelements.

Status:

Optional

Repeatable:

index

Index

Tag Library Definition:

A list of key terms and reference pointers that have been assembled to enhance access to the materials being described. The <index> can also serve as a helpful alphabetical overview of subjects, correspondents, photographers, or other entities represented in the collection. This back-of-the volume <index> may provide hypertext links, or it may note the container numbers useful for locating the position in the finding aid where the indexed material appears.

The <index> is assumed to be text that has to be tagged, not text generated automatically from the encoded finding aid. In some cases, the <index> repeats terms and names found elsewhere in the finding aid. In other cases, such as in some literary manuscript collections, the <index> may be the only place where a name is listed, and the references point to one or more files, which include letters from that person or corporate body, but which are described only in general terms, e.g., "Correspondents T-Z."

The <index> should contain <indexentry> elements, which consist of an access element, such as <name> or <subject>, followed by a Pointer <ptr>, Pointer Group <ptrgrp>, or Reference <ref> element. Plain text cannot be used in an <indexentry>. If the <indexentry> elements are expected to provide access points other than basic keyword retrieval, use authority file terms to facilitate access to the information within and across finding aid systems.

Tag example:

<index>
<head>Photographer Index</head>
Names of photographers and studios--and the cities and states in which they operated--are usually noted as they appear on the photographs (usually stamped or written on the versos). Corporate names appear in direct order; personal names in inverted order (i.e., filed by surname). Rectos and versos of photographs were microfilmed to capture information exactly as it appears on the photographs. To locate a specific photographer/studio, a user should consider all possible forms of entry (corporate and personal), browse the index under these forms, identify which LOT(s) contain photographs by that photographer/studio, then browse the relevant LOT on the microfilm to locate specific photographs that bear the markings of the specific photographer/studio.
<indexentry>
<name>12th Air Force Photo:</name>
<ref target="LOT13105" actuate="onrequest" show="replace">LOT 13105</ref>
</indexentry>
<indexentry>
<name>15th Air Force Command:</name>
<ref target="LOT13105" actuate="onrequest" show="replace">LOT 13105</ref>
</indexentry>
</index>

Subelements:

<indexentry>

Generic text formatting elements such as , <list> and <table> can also be used directly under <index>. See Tag Library for full list of valid subelements of <index>, <indexentry>, and <namegrp>.

Status:

Optional

Repeatable:

Comments:

The <index> element is used to encode any list of key terms and reference pointers compiled to facilitate access to the materials. The index enables linking to container numbers or other descriptors in the finding aid, but hypertext links are not required.
LC Practice encourages the encoding of pre-existing indexes which provide names and terms not found elsewhere in the container list, e.g., correspondents in a series arranged chronologically which does not list individual names. An index which links to page numbers of a paper register or one which simply lists alphabetically names easily found with a keyword search may not be worth the trouble to encode and may be omitted from the EAD finding aid.
Choose or formulate required <head> appropriate to content.
Indexes consist primarily of index entries, which are composed of a key term or terms and a reference pointer or pointers. Explanatory notes and additional formatting elements such as lists and tables may be included, but should not be used as a substitute for index entries.
Key terms in an index entry may be specific to its content, e.g. <persname>, <corpname>, <subject>, or <title>, or may be encoded as a nonspecific <name> element.
Whether or not a key term is under authority control, it will usually appear in a normalized (inverted order) form. Use <persname>, <famname>, etc. if these can readily be determined (see Examples 1, 3, and 4 in Appendix 12). If names are under authority control, set attributes for source and encodinganalog. See Example 4 in Appendix 12. One may also use the less specific <name> element, if it is not desired or easy to separate personal, corporate, and other names. See Examples 2 and 5 in Appendix 12.
The name group <namegrp> element can be used to bundle access element entries, e.g., several <famname> and < persname> elements, that share the same <ref>, <ptr>, or <ptrgrp> element. See Example 4 in Appendix 12.
However, if punctuation and connecting words must be included between the names, it is possible to tag multiple names in an index term within a single name tag and include a cross reference from the full form of the names. See Example 5 in Appendix 12.
An index entry can link using the <ref> element to surround the container numbers or other location information that the index entry references. Less commonly used at LC is the pointer <ptr> element, which contains no text; it is less clear to users where clicking on an arrow might lead them.
Use the pointer group <ptrgrp> element to bundle several <ref> or <ptr> links to a single access term. See Example 2 in Appendix 12.
Note: before using, check to see if there is some way to include the index online but have it optional within the print document. If keeping the index separate from the finding aid is preferable due to length, state it under <relatedmaterial> rather than <index>.

otherfindaid

Other Finding Aid

Tag Library Definition:

Information about additional or alternative guides to the described material, such as card files, dealers' inventories, or lists generated by the creator or compiler of the materials. It is used to indicate the existence of additional finding aids; it is not designed to encode the content of those guides.

Do not confuse with <fileplan>, which designates information about a particular type of access tool, known as a file plan, which explains the classification scheme used by the parties originally responsible for creating or compiling the described materials.

The <archref> element may be used to give a formal citation to the other finding aid or to link to an online version of it.

In EAD Version 1.0 <otherfindaid> was a subelement of Adjunct Descriptive Data <add>, which has been deprecated in EAD 2002 (see Appendix B). The new Description Group <descgrp> element, which can group any of the <did>-level elements (except the Description of Subordinate Components <dsc>), may be used to wrap elements where a group heading is desirable.

Tag example:

<otherfindaid encodinganalog="555">
<head>Additional Guides</head>
An annotated inventory describing each item in the collection, but in an order different from the current arrangement, and a negative photostatic copy of the inventory with fewer annotations may be found in the Manuscript Division Reading Room reference collection. Special card file indexes for the collection exist but are housed separately from the items themselves. A microfilm version of these indexes may be found on reel 15 of this series. To use the original indexes consult the reference staff in the Manuscript Division Reading Room.
</otherfindaid>

Subelements:

Generic text formatting elements such as , <list> and <table> are used directly under <otherfindaid>. See Tag Library for full list of valid subelements.

Status:

Optional

Repeatable:

Comments:

Links to, or lists of finding aids to other collections (related by subject or provenance) should not be encoded as <otherfindaid> but as <relatedmaterial> or <separatedmaterial>, respectively.
Create appropriate <head> such as Additional guides; Indexes; Other finding aids.

relatedmaterial

Related Material

Tag Library Definition:

Information about materials that are not physically or logically included in the material described in the finding aid but that may be of use to a reader because of an association to the described materials. Materials designated by this element are not related to the described material by provenance, accumulation, or use.

Do not confuse <relatedmaterial> with the element <separatedmaterial>, which provides information about materials that have been separated or physically removed from the described materials but that are related to them by provenance. Also, do not confuse with <altformavail>, which encodes information about copies of the described materials, such as microforms, photocopies, and reproductions in digital formats. Do not confuse with <originalsloc>, which encodes information regarding the existence and location of the originals when the unit being described consists of copies.

Practice: University at Buffalo finding aids will use "Related Resources" as the heading in <head> for <relatedmaterial>

Tag examples:

Example 1: encoded using simple list type; hyperlinks not activated in display

Text

Tagging

Related Resources

<relatedmaterial encodinganalog="544 1">
<head>Related Resources</head>

Related collections at the University at Buffalo include:

Related collections at the University at Buffalo include:

34/9/1071 Charles Haynie Papers, 1963-2002 Finding aid available online

<list type="simple">
<item>
<num>34/9/1071</num>Charles Haynie Papers, 1963-2002
<archref href="http://ublib.buffalo.edu/libraries/units/archives/ead/1071/1071.frame.html" show="new" actuate="onrequest">finding aid available online</archref>
</item>

16/8F/1064 Charles Keil Papers, 1965-1998, (bulk 1970-1990) Finding aid available online

<item>
<num>16/8F/1064</num>Charles Keil Papers, 1965-1998, (bulk 1970-1990)
<archref href="http://ublib.buffalo.edu/libraries/units/archives/ead/1064/1064.frame.html" show="new" actuate="onrequest">finding aid available online</archref>
</item>

MS 35 Buffalo Women's Center records, 1973-1978

<item>
<num>MS 35</num>Buffalo Women's Center records, 1973-1978
</item>
</list>

Other repositories with women's studies and women's rights collections include:

Other repositories with women's studies and women's rights collections include:

Arthur and Elizabeth Schlesinger Library on the History of Women in America at http://www.radcliffe.edu/schles/

<list type="simple">
<item>
Arthur and Elizabeth Schlesinger Library on the History of Women in America at
<archref href="http://www.radcliffe.edu/schles/" actuate="onrequest" show="new">http://www.radcliffe.edu/schles/</archref>
</item>

Sallie Bingham Center for Women's History and Culture at Duke University at http://scriptorium.lib.duke.edu/women/

<item>Sallie Bingham Center for Women's History and Culture at Duke University at
<archref href="http://scriptorium.lib.duke.edu/women/" show="new" actuate="onrequest">http://scriptorium.lib.duke.edu/women/</archref>
</item>
</list>
</relatedmaterial>

Example 2 (adapted from LC): encoded in definition list format (<list type="deflist">) using <defitem>

Text

Tagging

Related Resources

<relatedmaterial encodinganalog="544 1">
<head>Related Resources</head>

Related Archival Collections Beyond the Library of Congress

Related Archival Collections Beyond the Library of Congress

National Broadcasting Company Records at the Wisconsin State Historical Society

<list type="deflist">
<defitem>
<label>
<archref>National Broadcasting Company Records at the Wisconsin State Historical Society</archref>
</label>

The State Historical Society of Wisconsin in Madison maintains archival NBC records for 1929 - 1969: 564 boxes, 3,264 discs, 21 tapes and 72 reels of microfilm. The Wisconsin collection includes central files, office files and a library of scripts and recordings which complement the NBC Archives at the Library of Congress.

<item>The State Historical Society of Wisconsin in Madison maintains archival NBC records for 1929-1969: 564 boxes, 3,264 discs, 21 tapes and 72 reels of microfilm. The Wisconsin collection includes central files, office files and a library of scripts and recordings which complement the NBC Archives at the Library of Congress.</item>
</defitem>
</list>
</relatedmaterial>

Example 2 (adapted from LC): related material encoded in paragraph narrative with embedded linking archrefs (hyperlinks not activated in display)

Text

Tagging

Related Resources

<relatedmaterial encodinganalog= 544 1">
<head>Related Resources</head>

Collections in the Manuscript Division supplementing the Olmsted Papers include records of the Olmsted Associates, landscape architects, of Brookline, Massachusetts, the successor to the firm established by Frederick Law Olmsted and Calvert Vaux in 1858 and the files of Laura Wood Roper, Olmsted's biographer, which contain original Olmsted material and Olmsted Associates correspondence.

Collections in the Manuscript Division supplementing the Olmsted Papers include<archref href="http://hdl.loc.gov/loc.mss/eadmss.ms001018" show="new" actuate="onrequest">records of the<origination>Olmsted Associates, </origination></archref>
landscape architects, of Brookline, Massachusetts, the successor to the firm established by Frederick Law Olmsted and Calvert Vaux in 1858 and the files of <archref href="http://hdl.loc.gov/loc.mss/eadmss.ms001020" show="new" actuate="onrequest" >
<origination>Laura Wood Roper,</origination ></archref >Olmsted's biographer, which contain original Olmsted material and Olmsted Associates correspondence.
</relatedmaterial>

Subelements:

<bibref>
<archref>

Generic text formatting elements such as <note>, <list> and <table> can also be used directly under <relatedmaterial>. See Tag Library for full list of valid subelements.

Status:

Optional

Repeatable:

Comments:

Related material may consist of a list (see Example 2 ), a table, or paragraphs which include <archref> or <bibref> elements (see Example 3 ), as well as of <archref> or <bibref> elements. See the Application Guidelines for an example of <relatedmaterial> which consists of a list of <archref> elements without additional formatting.
Archival references (<archref>) may be encoded within any of these formatting elements. Since <archref> is a linking element, links to online finding aids or web sites for the archival resource being referenced may be easily made at the point of encoding or in the future.
Recommended local practice: references in <relatedmaterial> should chiefly be from local sources. When it is relevant to include references to materials in other institutions, the list should state the local and outside sources separately with headings as appropriate (ex.: Related Resources in the Music Library; Related Resources Online).

This ends the /descgrp section

This ends the /archdesc section

This ends the /ead section

Appendices

Appendix 1 - File Naming

Background:

Ead finding aids in xml exist as single files (not multiple files as in some HTML setups with frames). Unique file identity is essential, especially in a shared system. This unique identity should be created based on the file name alone and not be dependent upon a combination of folder name and file name. (ex.: .../Feldman/findingaid.xml may be unique in folder/file combination, but not based on file name alone. Archives is the only unit currently creating xml documents and they employ a system of file naming based on collection number which will presumably remain unique.

File Naming for Unit and Institutional Identity

It is recommended that a system for file naming be adopted that incorporates institutional, unit, and collection identity. Possibilities include:

Use of prefix "ub" for institutional identity
Use of a standard lexicon of abbreviations for unit identities - Archives - ar, Law - la, Music - mu, Poetry - po
Use of collection number rather than collection title in file name. Decimals used in collection numbers will be replaced by underscores in file names. EX.: Mus. Arc. 12.1 will be named ubmu12_1.xml

One possibility is to adopt a newer naming convention such as Uniform Resource Names (URN). If that practice is adopted, it may no longer be necessary or possible to embed collection, unit, or institutional names into the file name.
http://www.w3.org/Addressing/
http://www.benmeadowcroft.com/webdev/articles/urns-and-citations/

File Structure and Management

Background:

Decisions regarding this will effect whether we use absolute or relative path names, how we link to digital objects, how we coordinate collections in a consortium, and how we cite the locations for stylesheets and the ead.dtd file. We also have to consider software choice and where those associated local files reside (how NoteTabPro refers to an ead.dtd, Saxon files, etc.), how to best make use of our shared networks so that each PC doesn't have to be set up separately, what are local server environment will be short term and longer, etc.

The following is the University at Buffalo directory of EAD-related files as they can be created on either a desktop or network drive:

UB file structure

Relative path names to be used will follow the following patterns:

../shared/ead/ead.dtd
../shared/entities/addresses/musiclibrary.xml
../shared/entities/images/ublogo.jpg
../shared/styles/stylesheetname.xsl

Appendix 2 - Entities

Background:

Entities are retrievable files that can be used to store data and images that are commonly referred to in finding aids. The use of entities also makes correction of commonly used data easier because one entity file can be changed rather than the same data within several finding aids.

Common uses for entities:

Any boilerplate text
Addresses of institutions
University/Institution logos
Full forms of long names used within a document
Copyright statements
Preferred citation guide
Images

[<!ENTITY ublogo SYSTEM " -//State University of New York at Buffalo::Music Library//NONSGML (University at Buffalo logo)//EN" "../shared/entities/images/ublogo.jpg" NDATA jpeg> ]

[<!ENTITY [entityname] PUBLIC "State University of New York at Buffalo::Music Library//TEXT (Music Library address)//EN"
"..shared/entities/addresses/[entityname].xml"> ]

Corresponding encoding for use of Music Library address in <publicationstmt>:

<publicationstmt> &musiclibraryaddress; </publicationstmt>

Corresponding XML entity file for a text file, Music Library address:

<publisher>State University of New York at Buffalo. Music Library </publisher>
<address>
<addressline>112 Baird Hall</addressline>
<addressline>Buffalo, New York</addressline>
<addressline>14260-4750</addressline>
<addressline>USA</addressline>
<addressline>Phone: 716 645-2924</addressline>
<addressline>Fax: 716 645-3906</addressline>
<addressline>Email: musique@buffalo.edu</addressline>
<addressline>URL: http:ublib.buffalo.edu/libraries/units/music</addressline>
</address>

Corresponding encoding for use of an entity image file, UBlogo.jpg in <publicationstmt>:

<publicationstmt><extptr show="embed" entityref="ublogo"></publicationstmt>

Appendix 3 - Publicid

Creating a public identifier (FPI - Formal 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

-//[institution name]::[subordinate division]//TEXT (us::[main agency code]::[local reference code]::[title of resource])//EN

Leave all "/" and ":" punctuation as is, even if some of the above are blank.

From the Online Archive of California Best Practices:

The title of the archival unit should match exactly the wording (though not necessarily the punctuation or markup) of the <unittitle> in <archdesc>. The formal syntax for FPI entries specifies that in addition to numbers, and upper- and lowercase letters, only the following marks of punctuation may be used:

' (apostrophe)
( (left parenthesis)
) (right parenthesis)
+ (plus sign)
, (comma)
? (hyphen)
. (period)
: (colon)
= (equal sign)
? (question mark)
/ (forward slash)

Examples:

publicid="-//Stanford University::Hoover Institution Archives//TEXT (US::CSUZ::::Vasilii Sergeevich Il'in Papers)//EN"

publicid="-//University of California, Santa Cruz::University Library::Special Collections//TEXT (US::CU-SC::MS 74::John Cage Mycology Collection)//EN"

Appendix 4 - University at Buffalo Naming Conventions

Background:
The different forms of the name of the university must be reconciled in some way for use in finding aids. This includes visual identity (logo selection), choice of unit names in conjunction with the university, and use of the authoritative forms of the university and units (as established in NAF). The University maintains a website that states preferences for uses of the university name and logos: http://www.buffalo.edu/toolbox/vi_introduction.html

Name conflicts:
The name of the university as established by the Library of Congress (which is what should be used for all "access points" in the finding aid) conflicts with the name of the university preferred by the University itself. Also, Library of Congress has established names for the units as State University of New York at Buffalo. Unit name. This displaces unit identity to the end of statements.

Library of Congress authorized name: State University of New York at Buffalo

University authorized (preferred, formal) name: University at Buffalo, The State University of New York

Final Recommendations:

University finding aids will use the basic UB logo as approved by the University. No unit identity will be attached to or embedded in the logo.
All statements of the University name, with and without unit identity, shall be stated according to the form established by Library of Congress: State University of New York at Buffalo.
Statements that include unit names shall follow Library of Congress headings in all locations.
Locations requiring use of LC-authorized heading (State University of New York at Buffalo. Unit name):
- Entity statements
- <publicid> in <eadid>
- Copyright statement
- <creator>
- <controlaccess>, either as subject or responsible agency (7XX in MARC)
- <repository>
The authorized heading for the Law Library is Charles B. Sears Law Library. Therefore, this is the name form to be used in all locations that require use of controlled vocabulary as stated above.

Appendix 5 - Treatment of Dates

Background: dates can be encoded in one of two elements in EAD, depending upon the context: <date> or <unitdate>. The lists of attributes that can be used to qualify dates within the two elements are the same, except for the addition of id and datechar for <unitdate>. Other attributes include calendar, certainty, encodinganalog, era, normal, and type.

For detailed information on recording and formatting dates, see DACS 2.4. Note in particular that DACS recommends (but does not require) that names of months and terms reflecting estimation (such as "circa" or "approximately") be spelled out rather than abbreviated. DACS also recommends (but does not require) that the type of date be specified; this may be done through the datechar attribute. Values that may be recorded in datechar include "creation," "recordkeeping" (record-keeping activity), "publication," or "broadcast." Note however, that the datechar attribute is available only in <unitdate>, not <date>.

[Also note: DACS distinguishes between dates of creation (date a letter was written, a photograph taken, sound recording made, etc.) as opposed to recordkeeping, which it uses to record the dates that files or collections were created, compiled, or accumulated. Dates of publication are for commercially released items.]

<date>

Tag Library Definition: A generic element that contains a month, day, or year in any format. Use <date> to identify any dates that merit encoding, except for the creation and other relevant dates of the described materials, which are instead tagged with the <unitdate> element. Examples of dates that might merit encoding are a person's birth date, the date the materials were acquired, or the date of an event in a chronology. These dates may be entered in the form of text or numbers, and may consist of a single date or range of dates. <date> may contain calendar, certainty, encodinganalog, era, normal, and type attributes (not all-inclusive list).

Uses of <date> and Practice for application of attributes:

<titleproper> within <eadheader><filedesc> -- the <date> element is nested within the <titleproper> element. Type attribute can be bulk or inclusive (use inclusive for a single year). Apply attributes for encodinganalog, era, calendar, type, and normal.

<titleproper encodinganalog="title">Title,
<date era="ce" calendar="gregorian" type="inclusive" normal="1951/1969" encodinganalog="date">1951-1969</date>
</titleproper>
<publicationstmt> within <eadheader><filedesc> -- character entity for copyright symbol, use year only (no month) and use the date the finding aid was created. Use only the encodinganalog attribute.
<creation> within <eadheader><profiledesc>. UB will not apply the <date> element within <creation>.

<profiledesc><creation>Machine-readable finding aid derived from paper by means of scanning and OCR; OCR file edited for typographical errors before encoding, 1998</profiledesc>
<change> within <eadheader> <revisiondesc> -- optionally, apply normal attribute for dates with months.
<chronitem> within <bioghist> <chronlist> -- apply <date> element without attributes.
<imprint> within either <bibref> or <unittitle> -- apply attributes for encodinganalog, era, calendar, and type, but not normal.

NOTE: <date> is NOT applied to life/death dates in names, chronological subdivisions in subject headings, or dates stated within texted fields such as Scope and Content or Biographical Note.

<unitdate>

Tag Library Definition: The creation year, month, or day of the described materials. The <unitdate> may be in the form of text or numbers, and may consist of a single date or range of dates. As an important subelement of the Descriptive Identification <did>, the <unitdate> is used to tag only the creation and other relevant dates of the materials described in the encoded finding aid. Do not confuse it with the <date> element, which is used to tag all other dates.

Statement of <unitdate> in relation to <unittitle>:

<unitdate> can be stated within or outside <unittitle>. It is recommended international practice (ISAD(G)) that it be stated separately, outside of <unittitle>. However, local Practice will be to state <unitdate> within <unittitle>. At the component level this allows for a <unittitle> for every <did>.

Statement of <unitdate> in regard to <unittitle>: practices at other institutions:

RLG: US repositories following APPM practice normally include <unitdate> as part of <unittitle>, whereas British and Canadian practice, following ISAD(G)v2 use <unitdate> at the same level as <unittitle>. Given the likelihood of further international standardization, separate title and date is preferred but both practices are permitted. Repeat <unitdate> if both inclusive and bulk dates are given. This element is considered an essential element for data exchange by ISAD(G)v2.
OAC: The <unitdate> should be encoded outside of <unittitle>.
NWDA: To insure compliance with ISAD(G), do not nest <unitdate> inside <unittitle> .
EAD Cookbook: Current practice prefers that <unitdate> be recorded separately from <unittitle>...
LC: <unitdate> may be used outside the <unittitle>, but LC practice requires its inclusion within <unittitle>, as is done in APPM cataloging rules.
NCECHO: 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>.

Used within (not all-inclusive list):

<unittitle> within <archdesc><did> (Collection Summary) -- Type attribute can be bulk or inclusive (use inclusive for a single year). Apply attributes for encodinganalog, era, calendar, type, and normal.

<unittitle>Finding Aid for [title of collection],
<unitdatetype="inclusive" era="ce" calendar="gregorian" datechar="creation" encodinganalog="245$f" normal="1848/1950">1848-1950 </unitdate>
</unittitle>

<acqinfo>, <processinfo>, and other elements within <descgrp type="admininfo"> -- practice is varied on application of either <date> or <unitdate> elements for dates within these elements. These elements open with the element which is capable of containing either <date> or <unitdate>. Although examples can be found of both <

Text	Tagging
People and groups, circa 1884-1967 Call no.: LOT 13074	<c01 level="series"> <did> <unittitle>People and Groups <unitdate type="inclusive" normal="1884/1967">circa 1884-1967</unitdate> </unittitle> <unitid label="Call no.:">LOT 13074</unitid> </did>
Identified individual portraits Call no.: LOT 13074	<c02 level="file"> <did> <unittitle>Identified individual portraits</unittitle> <unitid label="Call no.:">LOT 13074</unitid> </did>
Adams, A., Mr. Call no.: LOT 13074, no. 1(F)	<c03 level="file"> <did> <unittitle>Adams, A., Mr.</unittitle> <unitid label="Call no.:">LOT 13074, no. 1(F)</unitid> </did> </c03>
Adams, Oscar Call no.: LOT 13074, no. 2(F)	<c03 level="file"> <did> <unittitle>Adams, Oscar</unittitle> <unitid label="Call no.:">LOT 13074, no. 2(F)</unitid> </did> </c03>
Addington, Wendell Call no.: LOT 13074, no. 3(F)	<c03 level="file"> <did> <unittitle>Addington, Wendell</unittitle> <unitid label="Call no.:">LOT 13074, no. 3(F)</unitid> </did> </c03> </c02> </c01>

Text	Tagging
Box I: 267 Case Files, 1971-1975	<c02 level="subseries"> <did> <container type="box">I:267</container> <unittitle>Case Files <unitdate type="inclusive" normal="1971/1975">1971-1975</unitdate> </unittitle> </did>
Opinions	<c03 level="file"> <did> <unittitle>Opinions</unittitle> </did>
71-237 Mancusi v. Stubbs	<c04 level="file"> <did> <unitid>71-237</unitid> <unittitle>Mancusi v. Stubbs</unittitle> </did> </c04>
71-244 In re Little	<c04 level="file"> <did> <unitid>71-244</unitid> <unittitle>In re Little</unittitle> </did> </c04> </c03> </c02>

Element	Name	Local Label	Local status
<head>	Heading	Information for Users	Required
<prefercite>	Preferred Citation	Preferred Citation	Required
<accessrestrict>	Conditions Governing Access	Terms of Access and Use	Required
<userestrict>	Conditions Governing Use	Copyright	Required

Text (without links highlighted)	Tagging
Arrangement	<arrangement encodinganalog="351$a"> <head>Arrangement</head>
The Blackwell Family Papers are organized in two series:	<p>The Blackwell Family Papers are organized in two series:</p>
Alice Stone Blackwell Papers, 1848-1957 Elizabeth Blackwell Papers, 1836-1946	<list type="simple"> <item> <ref target="clalice" show="replace" actuate="onrequest">Alice Stone Blackwell Papers, 1848-1951</ref> </item> <item> <ref target="cleliz" show="replace" actuate="onrequest">Elizabeth Blackwell Papers, 1836-1946</ref> </item> </list> </arrangement>

Text			Tagging
Container List			<dsc type="combined"> <head>Container List</head>
Series I. Recipient Files, 1946-1949			<c01 level="series"> <did> <unittitle>Series I. Recipient Files, 1946-1949 <unitdate type="inclusive" normal="1946/1949">1946-1949</unitdate> </unittitle> </did>
Scope and Content note: The Relief Project kept two files on relief recipients. Files from Subseries A (labeled "A") contain personal data and lists of package contents sent to the recipient. Files from Subseries B (labeled "B") contain correspondence, usually with English translations of letters written in foreign languages.			<scopecontent> <p>Scope and Content note: The Relief Project kept two files on relief recipients. Files from Subseries A (labeled "A") contain personal data and lists of package contents sent to the recipient. Files from Subseries B (labeled "B") contain correspondence, usually with English translations of letters written in foreign languages.</p> </scopecontent>
Arrangement: Files are arrange alphabetically by last name.			<arrangement> <p>Arrangement: Files are arrange alphabetically by last name.</p> </arrangement>
Subseries A. "A" Files			<c02 level="subseries"> <did> <unittitle>Subseries A. "A" Files </unittitle> </did>
1.1-1.2	Alpheus, Karl and Grete (Freiburg, Germany), undated		<c03 level="file"> <did> <container type="box/folder">1.1-1.2</container> <unittitle>Alpheus, Karl and Grete (Freiburg, Germany), undated</unittitle> </did> </c03>
1.3	Baldass, Ludwig and Pauly (Vienna, Austria), 1948		<c03 level="file"> <did> <container type="box/folder">1.3</container> <unittitle>Baldass, Ludwig and Pauly (Vienna, Austria) <unitdate type="inclusive">1948</unitdate> </unittitle> </did> </c03> </c02>
Subseries B. "B" Files			<c02 level="subseries"> <did> <unittitle>Subseries B. "B" Files </unittitle> </did>
1.4-1.8	Mannoury, S.D. (Amsterdam, Netherlands), 1946-1949		<c03 level="file"> <did> <container type="box/folder">1.4-1.8</container> <unittitle>Mannoury, S.D. (Amsterdam, Netherlands) <unitdate type="inclusive">1946-1949</unitdate> </unittitle> </did> </c03>
1.9-2.6	Zanasi, Lusiano (Modena, Italy), 1947-1948	[8 folders]	<c03 level="file"> <did> <container type="box/folder">1.9-2.6</container> <unittitle>Zanasi, Lusiano (Modena, Italy) <unitdate type="inclusive">1947-1948</unitdate> </unittitle> <physdesc> <extent>[8 folders]</extent> </physdesc> </did> </c03> </c02> </c01> </dsc>

Text			Tagging
Container List			<dsc type="in-depth"> <head>Container List</head>
Box 1	Diaries, 1843, 1849-1896	(4 folders)	<c01 level="file"> <did> <container type="box">1 </container> <unittitle>Diaries <unitdate type="inclusive" normal="1843">1843</unitdate>, <unitdate type="inclusive" normal="1849/1896">1849-1896</unitdate> </unittitle> <physdesc> <extent>(4 folders)</extent> </physdesc> </did> </c01>
Box 1-5	Family correspondence		<c01 level="file"> <did> <container type="box">1-5</container> <unittitle>Family correspondence</unittitle> </did>
Box 1	1803 May-1832 Apr.	(5 folders)	<c02 level="file"> <did> <container type="box">1</container> <unittitle> <unitdate type="inclusive">1803 May-1832 Apr.</unitdate> </unittitle> <physdesc> <extent>(5 folders)</extent> </physdesc> </did> </c02>
Box 2	1832 May-1835 Mar.	(6 folders)	<c02 level="file"> <did> <container type="box">2</container> <unittitle> <unitdate type="inclusive">1832 May-1835 Mar.</unitdate> </unittitle> <physdesc> <extent>(6 folders)</extent> </physdesc> </did> </c02> </c01> </dsc>

Text			Tagging
Description of Series			<dsc type="analyticover"> <head>Description of Series</head>
Boxes 1-16	Reels 1-8	Correspondence, 1800-1874	<c01 level="series"> <did> <container type="box">1-16</container> <container type="reel">1-8</container> <unittitle>Correspondence <unitdate type="inclusive" normal="1800/1874">1800-1874</unitdate> </unittitle> </did>
		Letters to Webster and letters by and about him.	<scopecontent> <p>Letters to Webster and letters by and about him.</p> </scopecontent>
		Arranged in groups as general correspondence, invitations, and selected transcripts and chronologically therein.	<arrangement> <p>Arranged in groups as general correspondence, invitations, and selected transcripts and chronologically therein.</p> </arrangement> </c01> </dsc>

Text			Tagging
Container List			<dsc type="analyticover"> <head>Container List</head>
Box	Reel	Contents	<thead> <row> <entry>Box</entry> <entry>Reel</entry> <entry>Contents</entry> </row> </thead>
Box 1	Reel 1	Correspondence, 1800-1874	<c01 level="file"> <did> <container type="box">1</container> <container type="reel">1</container> <unittitle>Correspondence <unitdate type="inclusive" normal="1898/1975">1800-1874, undated</unitdate> </unittitle> </did>
Box 1	Reel 1	General	<c02> <did> <container type="box">1</container> <container type="reel">1</container> <unittitle>General</unittitle> </did> </c02> </c01> </dsc>

Text	Tagging
Family Papers, 1872-1892	<c01 level="series"> <did> <unittitle>Family Papers <unitdate type="inclusive" normal="1872/1892">1872-1892</unitdate> </unittitle> </did>
Diaries, 1872	<c02 level="file"> <did> <unittitle>Diaries <unitdate type="inclusive">1872</unitdate> </unittitle> </did> </c02>
Notebooks, 1875-1892	<c02 level="file"> <did> <unittitle>Notebooks <unitdate type="inclusive">1875-1892</unitdate> </unittitle> </did> </c02> </c01>
Correspondence, 1938-1976, undated	<c01 level="series"> <did> <unittitle>Correspondence <unitdate type="inclusive" normal="1938/1976">1938-1976</unitdate>, <unitdate>undated</unitdate> </unittitle> </did>
General, 1938-1976	<c02 level="subseries"> <did> <unittitle>General <unitdate type="inclusive" normal="1938/1976">1938-1976</unitdate> </unittitle> </did>
Adams, John, 1944-1945	<c03 level="file"> <did> <unittitle>Adams, John <unitdate type="inclusive">1944-1945</unitdate> </unittitle> </did> </c03> </c02> <c02 level="subseries">
Organizations, 1943-1976, undated	<did> <unittitle>Organizations <unitdate type="inclusive" normal="1943/1976">1943-1976</unitdate>, <unitdate>undated</unitdate> </unittitle> </did> </c02> </c01>

Text	Tagging
Special Files: Public Service, 1918-1986	<c01 level="series"> <did> <unittitle>Special Files: Public Service <unitdate type="inclusive" normal="1918/1986">1918-1986</unitdate> </unittitle> </did>
World War II Files, 1941-1981	<c02 level="subseries"> <did> <unittitle>World War II files <unitdate type="inclusive" normal="1941/1981">1941-1981</unitdate> </unittitle> </did>
Harriman Mission, 1941-1946	<c03 level="subseries"> <did> <unittitle>Harriman Mission <unitdate type="inclusive">1941-1946</unitdate> </unittitle> </did>
Folder title, 1944	<c04 level="file"> <did> <unittitle>Folder title <unitdate type="inclusive">1944</unitdate> </unittitle> </did> </c04> </c03>
Moscow Files, 1943-1949	<c03 level="subseries"> <did> <unittitle>Moscow Files <unitdate type="inclusive" normal="1943/1949">1943-1949</unitdate> </unittitle> </did>
Folder title, 1943-1946	<c04 level="file"> <did> <unittitle>Folder title <unitdate type="inclusive">1943-1946</unitdate> </unittitle> </did> </c04> </c03> </c02>
Truman Administration, 1943-1963	<c02 level="subseries"> <did> <unittitle>Truman Administration <unitdate type="inclusive" normal="1943/1963">1943-1963</unitdate> </unittitle> </did> </c02> </c01>

Text	Tagging
Journal and diaries, 1843, 1849-1896	<c01 level="file"> <did> <unittitle>Journal and diaries <unitdate type="inclusive" normal="1843">1843</unitdate>, <unitdate type="inclusive" normal="1849/1896">1849-1896</unitdate> </unittitle> </did> </c01>
Correspondence	<c01 level="file"> <did> <unittitle>Correspondence</unittitle> </did>
May 1803-Apr. 1832	<c02 level="file"> <did> <unittitle> <unitdate type="inclusive" normal="1803-05/1832-04">May 1803-Apr. 1832</unitdate> </unittitle> </did> </c02> </c01>

Element	Name	Local Use
<container>	Container Information	Recommended
<unitid>	ID of Unit	Use the ID of the Unit <unitid> element to designate control numbers not associated with a physical container, for example, accession numbers.
<unittitle>	Unit Title	Required
<unitdate>	Unit Date	Required if available (nested within <unittitle>)
<origination>	Origination	Consider using <origination> at the series level when the creator/collector differs from that described in the Collection Summary, e.g., when the John Doe, Sr. papers comprise a series of the John Jay Doe Papers.
<physdesc>	Physical Description	Recommended if available
<materialspec>	Material Specifications	Use <materialspec> when material requires: Examples of material specific details include mathematical data, such as scale for cartographic and architectural records, jurisdictional and denominational data for philatelic records, and physical presentation data for music records.
<langmaterial>	Language Material	Use <langmaterial> at the component level only if the material being described is in a language different from that already specified at the <archdesc> level.
<abstract>	Abstract	Do not use at component level; use <scopecontent> instead
<physloc>	Physical Location of Materials	Use for information identifying the place where the described materials are stored, such as the name or number of the building, room, stack, shelf, or other tangible area.
<note>	Note	Use only when information does not fit into a better defined element.
<daogrp>	Digital Object Group	Use when required to identify digital objects or surrogates.

Text			Tagging
Display option 1: type attribute used to generate display label for container numbers in left column
Box 1	Folder 1 Reel 1	Correspondence, 1912-1962	<c02 level="file"> <did> <container type="box">1</container> <container type="folder">1</container> <container type="reel">1</container> <unittitle>Correspondence <unitdate type="inclusive">1912-1962</unitdate> </unittitle> </did> </c02>
	Folder 2	Diaries, 1955-1962	<c02 level="file"> <did> <container type="box">1</container> <container type="folder">2</container> <container type="reel">1</container> <unittitle>Diaries <unitdate type="inclusive">1955-1962</unitdate> </unittitle> </did> </c02>
Note: display of repeated container numbers suppressed

Box 1	Folder 1	Reel 1	Correspondence, 1912-1962
Box 1	Folder 2	Reel 1	Diaries, 1955-1962
Note: all container numbers displayed

Text			Tagging
Box	Item 1	Diary, 1912	<c02 level="file"> <did> <container type="box">5</container> <container type="item">1</container> <unittitle>Diary <unitdate type="inclusive">1912</unitdate> </unittitle> </did> </c02>
Box 5	Item 2	Journal, 1924-1925	<c02 level="file"> <did> <container type="box">5</container> <container type="item">2</container> <unittitle>Journal <unitdate type="inclusive">1924-1925</unitdate> </unittitle> </did> </c02>
Box 5	Item 3	Scrapbook, 1917	<c02 level="file"> <did> <container type="box">5</container> <container type="item">3</container> <unittitle>Scrapbook <unitdate type="inclusive">1917</unitdate> </unittitle> </did> </c02>

Text		Tagging
Box 328/1-28	October 1983-October 1987	<c03 level="file"> <did> <container type="box">328/1-28</container> <unittitle> <unitdate type="inclusive">October 1983-October 1987</unitdate> </unittitle> </did> </c03>
Box OV 1	January 1988-December 1992	<c03 level="file"> <did> <container type="box">OV 1</container> <unittitle> <unitdate type="inclusive">January 1988-December 1992</unitdate> </unittitle> </did> </c03>

Text			Tagging
Box 61	Reel 43-44	United States Post Office patronage, political and postmaster lists, 1860-1865	<c02 level="file"> <did> <container type="box">61</container> <container type="reel">43-44</container> <unittitle>United States Post Office patronage, political and postmaster lists, <unitdate type="inclusive">1860-1865</unitdate> </unittitle> </did> </c02>
Box 62	Not filmed	Financial papers	<c02 level="file"> <did> <container type="box">62</container> <container label="Not filmed"> <unittitle>Financial papers</unittitle> </did> </c02>

Text		Tagging
Box 16-17	Reviews, 1955-1957, undated	<c04 level="file"> <did> <container type="box">16-17</container> <unittitle>Reviews <unitdate type="inclusive">1955-1957</unitdate> </unittitle>
Box 16	(2 folders)	<container type="box">16</container> <physdesc> <extent>(2 folders)</extent> </physdesc>
Box 17	(3 folders)	<container type="box">17</container> <physdesc> <extent>(3 folders)</extent> </physdesc> </did> </c04>

Text	Tagging
Reviews [Box 16-17]	<c04 level="file"> <did> <container type="box">16-17</container> <unittitle>Reviews</unittitle> </did>
1955-1956 [Box 16] (2 folders)	<c05 level="file"> <did> <container type="box">16</container> <unittitle> <unitdate type="inclusive">1955-1956</unitdate> </unittitle> <physdesc> <extent>(2 folders)</extent> </physdesc> </did> </c05>
1957 [Box 17] (3 folders)	<c05 level="file"> <did> <container type="box">17</container> <unittitle> <unitdate type="inclusive">1957</unitdate> </unittitle> <physdesc> <extent>(3 folders)</extent> </physdesc> </did> </c05> </c04>
Note: display subordinates container information by placement to right of text and smaller font

Text		Tagging
Series I. Office Files, 1933-1988, undated		<c01 level="series"> <did> <unittitle id="cloffice">Series I. Office Files <unitdate type="inclusive" normal="1933/1988">1933-1988</unitdate>, <unitdate>undated</unitdate> </unittitle> </did>
Box 1	Abramovitz, Gerald, 1968-1975, 1985	<c02 level="file"> <did> <container type="box">1</container> <unittitle>Abramovitz, Gerald, <unitdate type="inclusive">1968-1975</unitdate>, <unitdate type="inclusive">1985</unitdate> </unittitle> </did> </c02> </c01>

Text	Tagging
Eastern Asia 1:1,000,000. Canton	<c03 level="file"> <did> <unittitle>Eastern Asia 1:1,000,000. Canton
Washington, D.C. : United States Army, 1945.	<imprint> <geogname role="Place of Pub">Washington, D.C.</geogname> <publisher>United States Army,</publisher> </imprint> <unitdate type="inclusive">1945</unitdate> </unittitle>
Sheet NF 49, "Canton", 1st Edition-AMS 3 A.M.S. 5301	<bibseries>Sheet <num>NF 49</num>, "Canton", 1st Edition-AMS 3 A.M.S. 5301</bibseries> </did> </c03>

Text		Tagging
Series I. Journals and Notebooks, 1908-1946		<c01 level="series"> <did> <unittitle id="cljournals">Series I. Journals and Notebooks <unitdate type="inclusive" normal="1908/1946">1908-1946</unitdate> </unittitle> </did>
Box 2	1941	<c02 level="file"> <did> <container type="box">2</container> <unittitle> <unitdate type="inclusive">1941</unitdate> </unittitle> </did>
	Apr.-May, trip to England	<c03 level="file"> <did> <unittitle> <unitdate type="inclusive">Apr.-May</unitdate> trip to England</unittitle> </did> </c03>
	July-Aug., Roosevelt-Churchill Conference, Placentia Bay, Newfoundland	<c03 level="file"> <did> <unittitle> <unitdate type="inclusive">July-Aug</unitdate>, Roosevelt-Churchill Conference, Placentia Bay, Newfoundland</unittitle> </did> </c03> </c02> </c01>

Buffalo Niagara Online Archive: Best Practice Guidelines for Encoded Archival Description

Encoded Archival Description

EAD Header

EAD Identifier

File Description

Title Statement

Title Proper of the Finding Aid

Author

Sponsor

Edition Statement

Publication Statement

Publisher

Date

This ends the </filedesc> section

Profile Description

Creation

Language Usage

Language

Descriptive Rules

This ends the </profiledesc> section

Revision Description

This ends the </eadheader> section

Frontmatter

Archival Description

Descriptive Identification

Title of the Unit

Date of the Unit

ID of the Unit

Origination

Physical Description

Genre/Physical Characteristic

Physical Facet

Dimensions

Material Specifications

Physical Location

Language of the Material

Repository

Abstract

Note

Digital Archival Object Group

descgrp type="userinfo"

Description Group (User Information)

Preferred Citation

Conditions Governing Access

Conditions Governing Use

This ends the /descgrp type="userinfo" section

descgrp type="admininfo"

Descriptive Group (Administrative Information)

Custodial History

Accruals

Alternative Form Available

Location of Originals

Processing Information

Appraisal Information

Physical Characteristics and Technical Requirements

This ends the /descgrp type="admininfo" section

Biography or History

Chronology List

This ends the /bioghist section

Scope and Content

This ends the /scopecontent section

Arrangement

This ends the /arrangement section

Container List

Description of Subordinate Components

What is a Component?

Descriptive Identification (Basic Description of Each Component)

Container Information

ID of the Unit

Title of Unit

Date of Unit

Physical Description

Abstract

Physical Location Information

Expanded Description of Components

This ends the /dsc section

Controlled Access Headings

Grouping Controlled Vocabulary Terms

Attributes in <controlaccess> subelements:

Personal, Corporate, Family, and Geographic Names

Buffalo Niagara Online Archive:
Best Practice Guidelines for Encoded Archival Description

Text	Tagging
Correspondence, 1960-1965	<c02 level="file"> <did> <unittitle>Correspondence <unitdate type="inclusive">1960-1965</unitdate> </unittitle>
(2 folders)	<physdesc> <extent>(2 folders)</extent> </physdesc> </did> </c02>
Diaries, 1902	<c02 level="file"> <did> <unittitle>Diaries <unitdate type="inclusive">1902</unitdate> </unittitle>
(3 vols.)	<physdesc> <extent>(3 vols.)</extent> </physdesc> </did> </c02>

Text	Tagging
Series II: Sound Recordings	<c01 level="series"> <did> <unittitle id="series2">Series II: Sound Recordings</unittitle>
The originals and preservation masters are located in Motion Picture, Broadcasting, and Recorded Sound (M/B/RS) at the Library of Congress. See Collection Concordance by Format.	<physloc>The originals and preservation Masters are located in Motion Picture, Broadcasting, and Recorded Sound (M/B/RS) at the Library of Congress. See Collection Concordance by Format.</physloc> </did> </c01>

Text	Tagging
998 NBC Network Affiliates, 1935-1989	<c02 level="file"> <did> <container type="folder">998</container> <unittitle>NBC Network Affiliates <unitdate type="inclusive">1935-1989.</unitdate> </unittitle> </did>
Original, onionskin, mimeographed, and photocopied letters, memoranda, reports, maps, press releases, and telegrams related to the NBC network and affiliates.	<scopecontent> <p>Original, onionskin, mimeographed, and photocopied letters, memoranda, reports, maps, press releases, and telegrams related to the NBC network and affiliates.</p>
Highlights: February 5, 1937, 42-page "Report on the Study for Improving National Broadcasting Company Network Facilities." April 17, 1939, NBC network facilities map. June 28, 1934, 3-page letter from WSYR of Syracuse, New York to NBC complaining of NBC's neglect of the Blue Network in favor of the Red Network. May, 1951 4-page report on the growth and development of the NBC television network.	<p>Highlights: February 5, 1937, 42-page "Report on the Study for Improving National Broadcasting Company Network Facilities." April 17, 1939, NBC network facilities map. June 28, 1934, 3-page letter from WSYR of Syracuse, New York to NBC complaining of NBC's neglect of the Blue Network in favor of the Red Network. May, 1951 4-page report on the growth and development of the NBC television network.</p> </scopecontent> </c02>

Text	Tagging
Box 3	<c02 level="file"> <did> <container type="box">3</container>
Computer diskettes containing documents generated during collection processing, documents/files used to build the online presentation, and backup copies	<unittitle>Computer diskettes containing documents generated during collection processing, documents/files used to build the online presentation, and backup copies</unittitle>
Note: Disk directories can be found in Folder #1 with the Collection Guide.	<note> <p>Note: Disk directories can be found in Folder #1 with the Collection Guide.</p> </note> </did> </c02>

Text	Tagging
Eastern Asia 1:1,000,000. Canton	<c03 level="file"> <did> <unittitle>Eastern Asia 1:1,000,000. Canton</unittitle>
1 map; 660 x 710cm.	<physdesc> <extent>1 map</extent> <dimensions>660 x 710cm.</dimensions> </physdesc>
Scale: 1:100,000	<materialspec type="scale">1:100,000</materialspec>
Projection: Modified Polyconic	<materialspec type="projection"> Modified Polyconic</materialspec> </did>
Notes: Accompanied by graphic flight line index (incomplete). Sortie 35PR 4MH 29. Height 30,000ft.	<odd type="notes"> <p>Accompanied by graphic flight line index (incomplete).</p> <p>Sortie 35PR 4MH 29. Height 30,000ft.</p> </odd> </c03>

Text		Tagging
Box 1-3	Series I. Diaries, 1910-1945.	<c01 level="series"> <did> <container type="box">1-3</container> <unittitle id="diary">Series I. Diaries <unitdate type="inclusive" normal="1910/1945">1910-1945.</unitdate> </unittitle> </did>
	Holograph and typewritten diaries, bound and unbound.	<scopecontent> <p>Holograph and typewritten diaries, bound and unbound.</p> </scopecontent>
	Arranged in two groups, original and annotated transcripts, and therein chronologically.	<arrangement> <p>Arranged in two groups, original and annotated transcripts, and therein chronologically.</p> </arrangement>
	The diary for Sept. 24-Mar. 5, 1943, is available on microfilm. Shelf no. 20,613.	<altformavail> <p>The diary for Sept. 24-Mar. 5, 1943, is available on microfilm. Shelf no. 20,613.</p> </altformavail> </c01>

Text		Tagging
Box 50-56	Financial Papers, 1936-1969	<c02 level="subseries"> <did> <container type="box">50-56</container> <unittitle>Financial Papers <unitdate type="inclusive" normal="1936/1969">1936-1969</unitdate> </unittitle> </did>
	Correspondence, accounting statements, reports, and printed matter concerning financial contributions and other fund-raising activities as well as the general financial situation of the colony.	<scopecontent> <p>Correspondence, accounting statements, reports, and printed matter concerning financial contributions and other fund-raising activities as well as the general financial situation of the colony.</p> </scopecontent>
	Arranged alphabetically by subject.	<arrangement> <p>Arranged alphabetically by subject.</p> </arrangement>
	Container 56 is restricted until 1999.	<accessrestrict> <p>Container 56 is <emph render="bold">restricted</emph>until 1999.</p> </accessrestrict>
Box 56 (Restricted)	Financial problems	<c03 level="file"> <did> <container label="restricted" type="box">56</container> <unittitle>Financial problems</unittitle> </did>
	Finance Committee, 1957-1967	<c04 level="file"> <did> <unittitle>Finance Committee <unitdate type="inclusive">1957-1967</unitdate> </unittitle> </did> </c04> </c03> </c02>

Text	Tagging
Photograph album	<c02 level="file"> <did> <unittitle id="clgencorr">Photograph album</unittitle>
Items available online.	<daogrp> <daoloc href="mcc051"> <daodesc> <p>Items available online.</p> </daodesc> </daoloc> </daogrp> </did> </c02>

Heading	Contents	MARC Fields
Contributors	all names (personal, family, corporate, and geographic names in one alphabetical ordering) of contributors to the collection; that is, entities responsible for content such as correspondence, images, scores, etc.	1XX and 7XX
Subjects	all topical subject headings, geographic names as subjects, and names as subjects	6XX with exception of 655, 656 (occupations), and 657 (functions)
Genres	all forms and genres of materials contained within the collection	655

Text	Tagging
Search Terms	<controlaccess> <head>Search Terms</head>
The following terms have been used to index the description of this collection in the Library's online catalog.	<note> <p>The following terms have been used to index the description of this collection in the Library's online catalog.</note>
Contributors	<controlaccess> <head>Contributors</head>
Anthony, Susan B. (Susan Brownell), 1820-1906	<persname source="lcnaf" encodinganalog="100" role="creator">Anthony, Susan B. (Susan Brownell), 1820-1906</persname>
Doubleday and Company, Inc. Records	<corpname source="lcnaf" encodinganalog="710">Doubleday and Company, Inc. Records</corpname>
Inter-American Conference for the maintenance of peace, Buenos Aires, 1936. Records	<corpname source="lcnaf" encodinganalog="711">Inter-American Conference for the maintenance of peace, Buenos Aires, 1936. Records</corpname> </controlaccess>
Subjects	<controlaccess> <head>Subjects</head>
Afro-Americans--Suffrage	<subject source="lcsh" encodinganalog="650">Afro-Americans--Suffrage</subject>
American Anti-Slavery Society	<corpname source ="lcnaf" encodinganalog="610" role="subject">American Anti-Slavery Society</corpname>
Blackwell family	<famname source="lcnaf" encodinganalog="600" role="subject">Blackwell family</famname>
Bloomer, Amelia Jenks, 1818-1894	<persname source="lcnaf" encodinganalog="600" role="subject">Bloomer, Amelia Jenks, 1818-1894</persname>
Lexington observer and reporter	<subject encodinganalog="630" source="lcnaf">Lexington observer and reporter</subject>
Lincoln, Abraham, 1809-1865--Assassination	<persname source="lcnaf" encodinganalog="600" role="subject">Lincoln, Abraham, 1809-1865--Assassination</persname>
Mott, Lucretia, 1793-1880	<persname source="lcnaf" encodinganalog="600" role="subject">Mott, Lucretia, 1793-1880</persname>
National American Woman Suffrage Association	<corpname source="lcnaf" encodinganalog="610" role="subject">National American Woman Suffrage Association</corpname>
Pan-American Conference (1933 : Montevideo, Uruguay)	<corpname encodinganalog="611" role="subject">Pan-American Conference (1933 : Montevideo, Uruguay)</corpname>
Temperance	<subject source="lcsh" encodinganalog="650">Temperance</subject>
United States--Politics and government--19th century	<geogname source="lcsh" encodinganalog="651">United States--Politics and government--19th century</geogname>
Women--Suffrage	<subject source="lcsh" encodinganalog="650">Women--Suffrage</subject>
Women's rights	<subject source=" lcsh" encodinganalog="650">Women's rights</subject> </controlaccess>
Genres:	<controlaccess> <head>Genres:</head>
Portraits	<genreform encodinganalog="655" source="gmgpc">Portraits</genreform> </controlaccess> </controlaccess>