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:

• No

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:

• No

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:

• No

---

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:

• No

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:

• No

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:

• No

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:

• No

---

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:

• No

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:

• Yes

---

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 <p> element for narrative statements.

Tag example:

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

Status:

• Optional

Repeatable:

• No

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 <p>, 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:

• No

---

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:

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

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:

• Yes

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 <p> 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:

• No

---

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:

• No

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:

• No

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:

• Yes

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:

• No

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:

• No

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

Status:

• Required; with level attribute

Repeatable:

• No

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 <p> 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

Status:

• Required; with <head> subelement

Repeatable:

• Yes

---

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:

• Yes

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:

• Yes

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:

• Yes

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:

• Yes

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:

• Yes

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 <p>. 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:

• Yes

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:

• Yes

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:

• Yes

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:

• Yes

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:

• Yes

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:

• Yes

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:

• Yes

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:

• Yes

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"> <p>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.</p> </note>

Status:

• Optional

Repeatable:

• Yes

Comments:

• Use only where necessary to explain exceptional circumstances.