Table of Contents

Library of Congress

Recommended Best Practices for Encoded Archival Description Finding Aids at the Library of Congress

FINAL DRAFT

NOTE ABOUT PRINTING: The current document is a single html file which can easily be printed in its entirety. However, be forewarned that it is very long (over 200 pages!).

INTRODUCTION

The Library of Congress EAD Practices Working Group has drafted these proposed guidelines for the creation of EAD finding aids at the Library of Congress, a process which has included documenting current practices at the Library, examining other documented standards and practices, and addressing outstanding issues.

These guidelines are intended for use in conjunction with the EAD Tag Library Version 1.0 and EAD Application Guidelines, published by the Society of American Archivists and the Library of Congress and available online at //www.loc.gov/ead/. The LC Practices guidelines follow the order of the EAD Application Guidelines by using the same chapter and subordinate numbers to facilitate cross-consultation. The guidelines in this current draft accompany Chapter 3 of the Application Guidelines, "Creating Finding Aids in EAD." Although these guidelines have been written for the implementation of EAD version 1, changes required by the new version of the DTD, EAD 2002, have been noted.

Technical documents and other files supplementing the administration and publication of EAD finding aids at the Library of Congress are available at //www.loc.gov/ead/practices/technical/technical.html.

The guidelines were made available to the Library of Congress EAD Technical Group for review, and many suggestions for improvement have been incorporated into this final draft which is now available for use by Library staff. Other changes (most notably revisions to the numbering of practices and to the table of contents) will be implemented when then the document is revised in compliance with EAD 2002.

For further information about the creation or content of this document, please contact Mary Lacy, chair of the working group, at [email protected].

LC EAD Practices Working Group:

• Morgan Cundiff, Network Development and MARC Standards Office
• Margit Kerwin, Manuscript Division
• Mary Lacy, Manuscript Division (chair)
• Anne Mitchell, Prints and Photographs Division
• Belinda Urquiza, Automation Planning and Liaison Office
• Nora Yeh, American Folklife Center

Basic Conventions Used

The LC Practices guidelines follow the order of the EAD Application Guidelines by using the same chapter and subordinate numbers to facilitate cross-consultation. Individual numbered sections described below are referred to as "practices." Most practices here accompany Chapter 3 of the Application Guidelines, "Creating Finding Aids in EAD," although two practices from Chapter 7, "EAD Linking Elements", are included.

Name:

The topic of the individual practice (most often an EAD element name) given here usually matches the section heading for that table of contents number in the Application Guidelines

Table of Contents Number:

This number matches the one given in the Application Guidelines. Not all the sections of Chapter 3 are found in the LC Practices document, since local practices do not need to be defined for each topic. Occasionally a topic covered by one number in the Application Guidelines (e.g. "3.5.1.4.1, Acquisition Information and Custodial History, is split into two practices, "3.5.1.4.1a, Acquisition Information" and "3.5.1.4.1b, Custodial History").

Tag:

Tag names for the element or elements named in the "Name" section are provided if the practice concerns a specific element or elements and appear within angle brackets, e.g., <acqinfo>.

Description:

The description section provides brief summary of the content of the topic or nature of the element. Fuller descriptions are provided in the Tag Library and Application Guidelines. The second paragraph of the description usually gives LC recommended practice for the topic, for instance, that use of a particular element is required or recommended.

See also:

References provided here list other practices within this document related to the current topic. These references do not link to those topics at present, but such links are intended.

References to specific portions of the Tag Library or Application Guidelines are not provided in this section but will be made where appropriate.

Labels/Heads:

Suggested formulation of appropriate content for labels, which aid in clear displays, and for heads, which are important for navigation as well as displays. A particular element may use the LABEL attribute (such as <did> subelements); or, it may include <head> as a subelement, but both are never used for the same element.

Encoding Analog:

• Encoding analogs in the <eadheader> use Dublin Core as the encoding standard.
• Encoding analogs in the <archdesc> are using MARC21. All topics below refer to MARC21 encoding analogs.
• A specific subfield or subfields are given only when the element for which the encoding analog is given includes only the text of that subfield (e.g., 260$c for <unitdate>).
• When the element includes the entire content of the MARC field (e.g., 600 for <persname>, the examples given do not name all the subfields that are represented in that <persname>.
• Indicators are given only when necessary to distinguish among elements. For instance, the encoding analog for <relatedmaterial> is 544 1, and the encoding analog for <separatedmaterial> is 544 0.
• Optionally, all indicators and subfields may be given, but the cost of doing so should be weighed against probable utility and the ability to include such information accurately in a template.
• Follow the examples shown below in situations where both indicators and subfield codes are given. Use a single space to separate the tag number from the indicators, and from the indicators to the subfields. Use the graphic symbol # for a blank or undefined indicator, and use the graphic symbol $ for the delimiter portion of a subfield code.
• encodinganalog="222 #3 $a" (first indicator undefined; only one subfield)
• encodinganalog="245 04 $abc" (both indicators have values; multiple subfields)
• encodinganalog="544 1# $3abcden" (second indicator undefined; multiple subfields)

See the EAD Application Guidelines, Appendix B.4, for a crosswalk between MARC and EAD.

Other attributes:

Recommended attributes (except for ENCODINGANALOG, discussed above) for the element under discussion are listed here, sometimes with suggested values for those attributes. The Tag Library includes complete lists of all attributes and their possible content for each element, and are discussed at length in its "EAD Attributes" section.

One of these attributes, NORMAL, is recommended for all dates, both <date> and <unitdate>. This practice is new at LC. Date normalization will follow ISO 8601 in YYYYMMDD format.

Subelements:

Subelements are listed when the practice focuses on a broader parent element. For instance, elements used within the wrapper element <eadheader> are listed as subelements. If the order in which they are listed is the recommended order in which they should be used, this is noted. If use of the subelement is either required or recommended, that practice is noted here as well.

In many cases, individual practices exist for each subelement described; where this is true, references are given to the number and name of that practice. Since the order of practices follows that given in the Application Guidelines, the order of the practices associated with these subelements may not match the recommended order.

Examples:

Most practices include one or more examples of recommended markup. For each tagging example, there are one or more examples of a display that could be generated from the tagging example, depending on output specifications. Note that formatting features such as bold, italics, underlining, graphics, and font sizes and colors cannot be provided in the display examples in this version of the practices manual, although they form an important part of output specifications.

Comments:

Specific recommendations and discussions pertaining to LC implementation and issues arising from the practice topic are given here. The comments usually build on the initial description and refer specifically to the numbered examples provided.

Repeatable:

If an element is repeatable (may be used multiple times in the context described), this is noted as well as if the element is recursive (may be used within itself, e.g., <controlaccess> within a broader <controlaccess>).

Order:

If the practice concerns a particular element, either a specific order is recommended ("following <userestrict> and preceding <altformavail>"), or the parent element is noted ("within <add>").

Revision Date:

The date of the last revision to the individual practice provides version control to this regularly updated document.

Collection-Level Information (Archival Description)

Table of Contents Number:

Tag:

Description:

This wrapper element holds together the text of the archival finding aid, encompassing everything that is not included in the header or front matter. A required LEVEL attribute identifies the highest level of description represented by the finding aid, and other attributes may be set as well.

New in EAD 2002: the LANGMATERIAL attribute to <archdesc> will be replaced with the subelement <langmaterial>.

See also:

See also:

Labels/Heads:

n/a

Encoding Analog:

n/a

Other Attributes:

The most common attribute values are listed below:

• level="collection" (entire collection described in finding aid) REQUIRED BY DTD
• langmaterial="eng" (collection material in English). Required
• type="register" (for standard archival register) Recommended

• relatedencoding="MARC21" Recommended

Subelements:

These most significant subelements are listed in recommended order:

• <did> Required by DTD See 3.5.1.1, Basic Description: The High-level DID
• <controlaccess> Recommended See 3.5.3, Controlled Vocabulary Terms
• <admininfo> Required See 3.5.1.4, Administrative Information
• <bioghist> Recommended See 3.5.1.5, Biographical Sketches and Agency Histories
• <scopecontent> Required See 3.5.1.6a, Scope and Content Note
• <organization> and/or <arrangement> Recommended See 3.5.1.6b, Organization and Arrangement
• <dsc> Required See 3.5.2.5, Description of Subordinate Components
• <add> See 3.5.4, Adjunct Descriptive Data

Tagging Example 1.

All major subelements include head tags

Display of Tagging Example 1.

Table of Contents generated from headings of major archdesc subelements

Comments:

Attributes:

• The LEVEL attribute, required by the DTD, is usually set as level="collection", as when entire collection is described in the finding aid. If only one series of the collection is described in the finding aid, use level="series". See Tag Library for full list of values.
• Set the language material attribute as langmaterial="eng" (if collection material is in English). Record multiple languages as appropriate, e.g., langmaterial="eng fre ger". Note that the language of the finding aid itself is recorded in the <language> element in the eadheader. The source of the LANGMATERIAL attribute is ISO 639-2 maintained by the MARC Standards office and available at //www.loc.gov/standards/iso639-2/. (In EAD 2002, the LANGMATERIAL attribute to <archdesc> will be replaced with the subelement <langmaterial>.)
• Set the attribute type="register" for a standard archival register as created at LC. See Tag Library for full list of values.
• Set the related encoding attribute to relatedencoding="MARC21" when a different encoding analog, such as Dublin Core, has been set for the eadheader. This practice is new at LC. Previously the RELATEDENCODING attribute was set at the root element <ead>, where it applied to all parts of the finding aid.

Recommended order:

• Exceptions will occur in the recommended order, as listed above. For instance, most elements currently subordinate to <add>, such as indexes and bibliographies, are most commonly found at the end of a finding aid. Other such elements, like <relatedmaterial> and <separatedmaterial>, may be more appropriate to the front part of the finding aid, and can be used where most appropriate. The new version of the EAD DTD (EAD 2002) accommodates more flexible order by unbundling the <add> and <admininfo> subelements, but puts more demand on output specifications in handling a great number of element configurations.

Subelements:

• A number of elements are available at the <archdesc> level but are also commonly appropriate at the component level. These include <note>, <odd>, and <arrangement>.
• The <daogrp> element can also be used at the <archdesc> level. This might be an image concordance for all <dao>'s in the finding aid. An image sampler would be encoded at the Collection Summary level, and component-level archival objects would be encoded at the appropriate level. See 3.5.1.2.9 and 3.5.2.3.2 respectively for treatment of <daogrp> in these cases.

Repeatable:

no

Order:

follows <eadheader> and <frontmatter> (if used) as required by DTD

Revision Date:

08/08/02

Basic Description: The High-Level <did>

Table of Contents Number:

Tag:

Description:

This wrapper element contains the basic building blocks of description of archival components at any level. At the collection level (or <archdesc><did>), the content of these elements should enable a researcher to determine quickly the relevance of collection materials. It is important to include at least the first eight elements in any collection summary.

LC Practice requires the inclusion of the Collection Summary <did>, which is a mandatory element required by the EAD DTD.

See also:

Labels/Heads:

Recommended content of required <head>:

Collection Summary

Encoding Analog:

n/a

Other Attributes:

n/a

Subelements:

Listed in recommended order. Required elements must be included to conform with LC practice.

• <head> Required
• <unittitle> Required See 3.5.1.2.3, Title of the Unit
• <unitdate> Required See 3.5.1.2.4, Date of the Unit
• <unitid> Required See 3.5.1.2.7, ID of the Unit
• <origination> Required See 3.5.1.2.2, Origination
• <physdesc> Required See 3.5.1.2.8, Physical Description
• <repository> Required See 3.5.1.2.1, Repository
• <abstract> Required See 3.5.1.2.6a, Abstract
• <note> See 3.5.1.2.6b, Note
• <physloc> See 3.5.1.2.8, Physical Location
• <daogrp> See 3.5.1.2.9, Digital Archival Object Group

Tagging Example 1.

All subelements used

Display of Tagging Example 1.

All subelements used

Image sampler is part of Collection Summary although it appears to be a new section

Comments:

• Since the components of the high-level <did> are key features of indexing and display of LC finding aids, uniformity of practice in this area is particularly desirable in order to achieve the most predictable results.

Repeatable:

no

Order:

first element within <archdesc> (required by DTD)

Revision Date:

10/03/02

Repository

Table of Contents Number:

Tag:

Description:

The institution or agency responsible for providing intellectual access to the materials being described. At the Library of Congress, the repository usually will be the custodial unit or division where the material will be used.

LC Practice requires the inclusion of repository information within the Collection Summary <did>.

See also:

Labels/Heads:

Label="Repository"

Encoding Analog:

852

Other Attributes:

n/a

Subelements:

• <corpname>
• <subarea>

• <address>
• <addressline>

Tagging Example 1.

Illustrates single subarea within LC

Display of Tagging Example 1.

Illustrates single subarea within LC

Tagging Example 2.

Illustrates multiple terms within one subarea element

Display of Tagging Example 2.

Illustrates multiple terms within one subarea element

Tagging Example 3.

Multi-divisional finding aid

Display of Tagging Example 3.

Multi-divisional finding aid

Comments:

• Always use <subarea>, which is displayed as part of search results; this will facilitate the ordering of search results by <subarea> (i.e., which reading rooms must a researcher visit?) See Examples 1-2.
• Use <address> at its most general form (Washington, D.C.) for the convenience of users who may be searching a multi-national database. This practice is new at LC.
• Use of punctuation: include a comma and space between the closing </subarea> tag and "Library of Congress". Rely on stylesheets to supply a comma between the repository name and the address "Washington, D.C."
• For a multi-divisional finding aid, use a new repository tag for each section. See Example 3.

Repeatable:

yes

Order:

After <physdesc> and before <abstract> in Collection Summary

Revision Date:

08/08/02

Origination

Table of Contents Number:

Tag:

Description:

The origination element names, in authorized form, the individual/s or organization/s responsible for the creation, accumulation, or assembly of the described materials before their incorporation into an archival repository. There will in almost all cases be an <origination> element, whether or not a cataloging record for the materials uses main entry as a personal or corporate name or enters under title with added entries for the originator/s.

LC Practice requires the inclusion of origination information within the Collection Summary <did>, except in cases listed below.

See also:

Labels/Heads:

(choose as appropriate)

• Label="Creator"
• 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:

• Use role="collector" for <persname>, <famname>, or <corpname> when label="Collector" in <origination>
• Use the SOURCE attribute for <persname>, <famname>, or <corpname> in <origination> (value is usually "LCNAF")

Subelements:

• <persname>
• <famname>
• <corpname>

Tagging Example 1.

One origination (cataloging record has 1xx field for originator)

Display of Tagging Example 1.

One origination (cataloging record has 1xx field for originator)

Note: includes subfield e for role as collector

Tagging Example 2.

Multiple originators, but one predominates

Display of Tagging Example 2.

Multiple originators, but one predominates

Papers of Kermit and Belle Roosevelt; Belle Roosevelt (700) listed in <controlaccess> section.

Tagging Example 3.

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

Display of Tagging Example 3.

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

Tagging Example 4.

No <origination>; family names recorded in <controlaccess> only

Display of Tagging Example 4.

No <origination>; family names recorded in <controlaccess> only

Tagging Example 5.

No origination given (do not record LC as collector)

Display of Tagging Example 5.

No origination given (do not record LC as collector)

Comments:

• 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.
• 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.
• 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. 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 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.
• 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.

Repeatable:

yes

Order:

After <unitid> and before <physdesc> in Collection Summary

Revision Date:

08/08/02

Title of the Unit

Table of Contents Number:

Tag:

Description:

Title of materials being described, usually the collection title or title of highest level being described in the finding aid.

LC Practice requires the inclusion of unittitle information within the Collection Summary <did>.

See also:

Labels/Heads:

• Label="Title"

Encoding Analog:

245$a (include other subfields if they are part of the title transcription).

Other Attributes:

n/a

Subelements:

• <unitdate>

See Tag Library for full list of valid subelements.

Tagging Example 1.

Examples of collection titles

Display of Tagging Example 1.

Examples of collection titles

Tagging Example 2.

Inclusive dates given as subelement within <unittitle>

Display of Tagging Example 2.

Inclusive dates given as subelement within <unittitle>

Style sheet uses label from <unittitle> and supplies comma at end; suppresses display of unitdate label and displays both fields on one line

Tagging Example 3.

Inclusive dates given as subelement within <unittitle>

Display of Tagging Example 3.

Inclusive dates given as subelement within <unittitle>

Style sheet uses labels from <unittitle> and <unitdate> and displays each on separate line

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. If the collection consists of only one type of material, that format may be reflected in the title. See Example 1 for aggregated list of illustrative titles.
• <unitdate> may be used outside the <unittitle>, but LC practice mandates its inclusion within <unittitle>, as is done in APPM cataloging rules. The date may be displayed on the same line as the title (Example 2) or on different lines (Example 3) depending on the stylesheet used.
• 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 Summary varies considerably in Library and outside implementation, and omission of punctuation between the two elements is least likely to result in inappropriate display. See Example 2 and Example 3.

Repeatable:

n/a

Order:

First element after <head> in Collection Summary

Revision Date:

08/09/02

Date of the Unit

Table of Contents Number:

Tag:

Description:

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

LC Practice requires the inclusion of unitdate information within the Collection Summary <did>.

New in EAD 2002: the TYPE attribute will be used only to distinguish inclusive and bulk dates, and the value "single" will no longer be valid.

See also:

Labels/Heads:

Suggested content:

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

Encoding Analog:

260$c (for any type dates, according to visual material cataloging practice); 245$f (type="inclusive" or type="single"), according to APPM cataloging practice; or 245$g (type="bulk") according to APPM cataloging practice

Other Attributes:

• type="inclusive" or "bulk"
• normal (normalize according to ISO8601 in yyyy-mm-dd format)

Tagging Example 1.

Illustrates use of inclusive and bulk dates, encoded separately with encoding analogs from MARC record for APPM cataloging

Display of Tagging Example 1.

Style sheet displays <unitdate> on same line as unittitle without <unitdate> labels

Display of Tagging Example 1.

Style sheet displays each <unitdate> on separate line using label attribute

Display of Tagging Example 1.

Style sheet displays <unitdate> on separate line from <unittitle>, using label display for the first (inclusive) dates. This display cannot be achieved using Panorama.

Tagging Example 2.

Illustrates use of span and bulk dates; encoding analog follows visual material cataloging practice

Display of Tagging Example 2.

Style sheet displays <unitdate> on same line as unittitle without <unitdate> labels; parentheses are supplied around <unitdate type="bulk">

Tagging Example 3.

Illustrates use of inclusive attribute value and encodinganalog as 260

Display of Tagging Example 3.

Style sheet displays <unitdate> on separate line using label attribute

Comments:

• Always give span and bulk dates in separate <unitdate> fields in order to supply the appropriate TYPE, LABEL, ENCODINGANALOG, and NORMAL attributes. This is a change from current LC practice. It will still be possible to display the dates on the same line as the <unittitle> and without labels, and offers the broadest range of display and retrieval options. See Example 1 for practice using APPM and Example 2 for practice using visual material cataloging rules.
• Use only one <unitdate> when there is only one date (Example 3) 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 (not yet implemented at LC). This practice is new at LC. It may take some time to develop date normalization tools and macros.
• Normalize dates following ISO 8601 in yyyy-mm-dd format. Follow this normalization standard also for <date> elements normalized in the <eadheader> and elsewhere as appropriate. Note that examples in the current EAD Tag Library do not illustrate the use of this standard.

Repeatable:

yes

Order:

Following/within <unittitle> and before <unitid> in Collection Summary

Revision Date:

10/03/02

Physical Description

Table of Contents Number:

Tag:

Description:

Statement or series of statements of extent regarding holdings of the collection.

LC Practice requires the inclusion of physical description information within the Collection Summary <did>.

See also:

Labels/Heads:

• label="Extent"
• label="Physical Description"

Encoding Analog:

n/a

Other Attributes:

n/a

Subelements:

• <extent encodinganalog="300">

See Tag Library for full list of valid subelements.

Tagging Example 1.

Multiple views of one collection given as extents within one <physdesc>

Display of Tagging Example 1.

Multiple views of one collection given as separate extents within one <physdesc>; stylesheet displays on one line with label for <physdesc> and supplies semicolons and spaces dividing each <extent> (Possible in Panorama)

Tagging Example 2.

Separate descriptions of positive and negative elements comprising collections given as extents within <physdesc>

Display of Tagging Example 2.

Separate descriptions of positive and negative elements comprising collections given as extents within <physdesc>

Tagging Example 3.

Description of elements comprising collections given as single extent within <physdesc>

Display of Tagging Example 3.

Description of elements comprising collections given as single extent within <physdesc>

Comments:

• Information may be encoded within <physdesc> and its subelements at varying levels of complexity. If more specificity is desired for purposes of retrieval or display, follow the guidance of the Tag Library and Application Guidelines in the use of the additional subelements <physfacet>, <dimensions>, and <genreform>.
• Descriptive practice within physical description generally consists of multiple views of the collection as a whole (Example 1), or description of the types of material in the collection (Example 2 and 3).
• When presenting multiple views of the collection, the order and content of the statements will generally reflect that of the catalog record, where each statement is found in a separate 300 field. (Examples 1 and 2).
• The physical description and extent statements may be broken into separate categories, as for positive and negative photographic media, as in Example 2.
• The content of the ENCODINGANALOG attribute should be "300" without subfields, as the MARC subfields do not map precisely to subelements of <physdesc>.

Repeatable:

yes

Order:

Following <origination> and before <repository> in Collection Summary

Revision Date:

08/09/02

Abstract

Table of Contents Number:

Tag:

Description:

A brief statement about the creator or collector of the materials as well as a very general summary of their scope.

LC Practice requires the inclusion of abstract information within the Collection Summary <did>.

See also:

Labels/Heads:

• label="Abstract"
• label="Summary"

Encoding Analog:

Generally use 520$a, although some information may be also derived from 545.

Other Attributes:

n/a

Subelements:

n/a

Tagging Example 1.

Abstract for personal papers (Caleb Cushing)

Display of Tagging Example 1.

Abstract for personal papers (Caleb Cushing)

Tagging Example 2.

Abstract for organizational records (Leadership Conference on Civil Rights)

Display of Tagging Example 2.

Abstract for organizational records (Leadership Conference on Civil Rights)

Comments:

• Use for quick overview of contents of collection; when needed, use <note> for overview of contents of finding aid itself.
• The abstract may be drawn from the <bioghist> and <scopecontent>, or from the 545 and 520 fields of the collection-level catalog record.

Repeatable:

n/a

Order:

Following <repository> and preceding <note> in Collection Summary

Revision Date:

08/09/02

Note

Table of Contents Number:

Tag:

Description:

Generic explanatory text. In Collection Summary, 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.

See also:

Labels/Heads:

• label="Note"

Encoding Analog:

Generally use 500$a.

Other Attributes:

n/a

Subelements:

n/a

Tagging Example 1.

Note about finding aid as work in progress

Display of Tagging Example 1.

Note about finding aid as work in progress

Tagging Example 2.

Note about partial coverage of online finding aid

Display of Tagging Example 2.

Note about partial coverage of online finding aid

Comments:

• The note element should not be used when more specific elements are available.
• Although the encodinganalog for <note> is 500$a, not every 500 field in the catalog record need be repeated in the finding aid or may be appropriate to this particular element.

Repeatable:

yes

Order:

after <abstract> and before <physloc> in Collection Summary

Revision Date:

08/09/02

ID of the Unit

Table of Contents Number:

Tag:

Description:

Identifying number or alphanumeric string used for control or citation purposes. Supply according to divisional practices. When no such ID is appropriate, use this element to supply unique country and repository codes by means of attribute values; the element will have no other content.

LC Practice requires the inclusion of the unitid element within the Collection Summary <did>.

See also:

Labels/Heads:

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

• label="Call No."
• label="Collection No."
• label="ID No."

Encoding Analog:

050, 090, 099, or other MARC field as appropriate (see catalog record). Do not set an ENCODINGANALOG if element contains boilerplate language.

Other Attributes:

• countrycode="US" (Source: ISO 3166)
• repositorycode="DLC" (Source: MARC origination codes)

Subelements:

n/a

Tagging Example 1.

American Folklife Center ID number

Display of Tagging Example 1.

American Folklife Center ID number

Tagging Example 2.

Prints & Photographs 050 content

Display of Tagging Example 2.

Prints & Photographs 050 content

Tagging Example 3.

MSS ID number from 590 note

Display of Tagging Example 3.

MSS ID number from 590 note

Comments:

• Use this element in order to conform to the ISAD-G international archival standard in supplying required county and repository codes. This is a change in LC practice.
• If no identification number is given, use appropriate boilerplate language.

Repeatable:

n/a

Order:

following <unittitle><unitdate> and preceding <origination> in Collection Summary

Revision Date:

10/04/02

Physical Location

Table of Contents Number:

Tag:

Description:

Information identifying the place where the described materials are stored. Do not confuse with <container> or <repository>. Use of this element is optional. (It has not yet been used at LC).

See also:

Labels/Heads:

• label="Location"

Encoding Analog:

852$z, 090, or other MARC field as appropriate (see catalog record)

Other Attributes:

Audience: set to "internal" if not for public display (for instance, shelf number for staff retrieval)

Subelements:

n/a

Tagging Example 1.

Public note alerting readers to storage issues affecting their access to the material.

Display of Tagging Example 1.

Public note alerting readers to storage issues affecting their access to the material.

Tagging Example 2.

Note for staff use only giving shelving location of material for retrieval. AUDIENCE attribute set to 'internal.'

Display of Tagging Example 2.

Note for staff use only giving shelving location of material for retrieval. AUDIENCE attribute set to 'internal' resulting in blank display for public.

Comments:

• Since the <physloc> element is repeatable both the usages illustrated in Examples 1 and 2 may apply to a given finding aid.
• Use the <physloc> element at this level to note that all material in the custody of one division is in the physical custody of another division (i.e., should be used in another reading room than that of the repository). This information would more commonly be recorded at the component level; see section 3.5.2.3.1.4b for more information.

Repeatable:

yes

Order:

Following <note> and before <daogrp> in Collection Summary

Revision Date:

08/09/02

Digital Archival Object Group

Table of Contents Number:

Tag:

Description:

A wrapper element for two or more related digital archival objects which should be thought of as a group and share a common description. In the collection summary area, used 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>). The examples given illustrate one particular usage.

See also:

See also:

Labels/Heads:

Image Sampler

Encoding Analog:

n/a

Other Attributes:

n/a

Subelements:

• <daodesc>
• <head>
• <p>

• <daoloc>
• <daodesc>
• <p>

Tagging Example 1.

Representative images from NAACP visual materials collection

Display of Tagging Example 1.

Comments:

• Use <daogrp> and its subelement <daoloc> only for two or more archival objects. If only one is given, use <dao> instead. (Note: when EAD 2002 is implemented, LC will use <daogrp> instead in compliance with RLG Best Practice Guidelines.)

• See Section 7.3 for instructions on naming and declaring entities for external linking.

Repeatable:

n/a

Order:

Last element in Collection Summary

Revision Date:

08/09/02

Administrative Information

Table of Contents Number:

Tag:

Description:

This wrapper element assembles background information that users may need to gain access to the archival materials, place the materials in context, and make use of the information contained therein. This information also assists repositories in some aspects of collection management. Administrative information may have been recorded in multiple places in legacy finding aids but should be pulled together in the EAD finding aid.

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

• Where it came from: <acqinfo>, <custodhist>, <accruals>
• What the repository did with it: <processinfo>, <appraisal>
• What users can do with it: <userestrict>, <accessrestrict>
• Formats available for use: <altformavail>
• How to cite: <prefercite>

LC Practice requires the inclusion of administrative information in LC finding aids. Administrative information should be contained within subordinate elements in new finding aids and when possible in retrospective conversion. Although the current DTD permits administrative information to be tagged simply as paragraphs of text rather than contained within subelements, this practice should not be followed at LC.

New in EAD 2002: the <admininfo> tag will be deprecated; the new version of EAD (EAD 2002) will make administrative information subelements directly available within <archdesc> and within components. LC Practice recommends pulling these elements together within a generic descriptive group <descgrp> element.

See also:

Labels/Heads:

Recommended content of required <head>:

• Administrative Information

Encoding Analog:

n/a

Other Attributes:

n/a

Subelements:

Recommended order. Use of subelements should follow divisional policies. All subelements except <head> may be repeated.

• <head> Required
• <acqinfo> Required See 3.5.1.4.1a, Acquisition Information
• <custodhist> Recommended if applicable See 3.5.1.4.1b, Custodial History
• <accruals> See 3.5.1.4.5a, Accruals
• <processinfo> See 3.5.1.4.6, Processing Information
• <appraisal> See 3.5.1.4.5b, Appraisal
• <userestrict> Required if applicable/Recommended See 3.5.1.4.2b, Restrictions on Use
• <accessrestrict> Required if applicable/Recommended See 3.5.1.4.2a, Restrictions on Access
• <altformavail> Required if applicable See 3.5.1.4.3, Alternate Form of the Materials Available
• <prefercite> Recommended if applicable See 3.5.1.4.4, Preferred Citation of the Material

Tagging Example 1.

Heads provided for specifically encoded elements

Display of Tagging Example 1.

Heads provided for specifically encoded elements

Comments:

• <admininfo> can be used recursively. For instance, a multidivisional finding aid may include separate information about provenance, access and use restrictions, and preferred citations for each division's holdings. Separate <admininfo> sections could be encoded and enclosed within an overall "Administrative Information" Section.
• Subordinate <admininfo> elements may also be tagged separately within scattered <admininfo> wrappers, since <admininfo> is repeatable. For example, if there were a need for <accessrestrict> to appear after the collection summary but for the <custodhist> to appear after the <bioghist>, each of those elements could be wrapped within its own <admininfo> wrapper. In the EAD 2002 revision, these elements will be entered directly without the use of an <admininfo> wrapper.
• Administrative information subelements may also be used at the component level, for instance to indicate that a particular series is available on microfilm. See also 3.5.2.3.2, Expanded Description of Components.

Repeatable:

yes (and recursive)

Order:

following <did> and preceding <bioghist>

Revision Date:

08/09/02

Acquisition Information

Table of Contents Number:

Tag:

Description:

Information about the immediate source of collection materials and the circumstances (e.g., gift, transfer, purchase, deposit) under which materials were received.

LC practice requires the inclusion of acquisition information.

See also:

Labels/Heads:

Recommended content of required <head>:

• Provenance

Encoding Analog:

541

Other Attributes:

n/a

Subelements:

n/a

Tagging Example 1.

Materials acquired by various methods

Display of Tagging Example 1.

Materials acquired by various methods

Comments:

Do not confuse with <custodhist>, which describes the physical and intellectual custody of collection materials prior to their receipt by the repository.

Repeatable:

n/a

Order:

first subelement within <admininfo>

Revision Date:

08/09/02

Custodial History

Table of Contents Number:

Tag:

Description:

Information about the previous chain of custody of the collection materials described; this may describe both physical possession and intellectual custody of materials that may assist a researcher in determining the authenticity and interpretation of such materials. This description supplements information pertaining to the receipt of collection material at LC, which is recorded in <acqinfo>.

LC practice recommends the inclusion of custodial history where applicable.

See also:

Labels/Heads:

Recommended content of required <head>:

• Custodial History

Encoding Analog:

561

Other Attributes:

n/a

Subelements:

n/a

Tagging Example 1.

Illustrating relationship between <acqinfo> and <custodhist>

Display of Tagging Example 1.

Illustrating relationship between <acqinfo> and <custodhist>

Comments:

This element has not yet been used at LC.

Repeatable:

n/a

Order:

following <acqinfo> and preceding <accruals>

Revision Date:

10/04/02

Restrictions on Access

Table of Contents Number:

Tag:

Description:

Information about conditions that affect the availability of the materials described in the finding aid. Such restrictions may include those imposed by donors or by government security classification. This element can also be used to state the absence of any access restrictions.

LC practice requires the inclusion of information about the presence of restrictions on access. If there are no restrictions on access, it is recommended that this be noted.

See also:

Labels/Heads:

Choose or formulate required <head> appropriate to content, e.g.

• Access
• Security Classified Documents

Encoding Analog:

506

Other Attributes:

n/a

Subelements:

n/a

Tagging Example 1.

Security restrictions on access

Display of Tagging Example 1.

Security restrictions on access

Tagging Example 2.

Access is unrestricted

Display of Tagging Example 2.

Access is unrestricted

Comments:

This element should not be confused with <userestrict>, which deals with restrictions (or lack of restrictions) on the use a researcher may make of the papers once access has been obtained.

Repeatable:

yes

Order:

following <userestrict> and preceding <altformavail>

Revision Date:

08/09/02

Restrictions on Use

Table of Contents Number:

Tag:

Description:

Information about conditions that affect use of the described materials after access has been granted, such as limitations, regulations, or special procedures regarding reproduction, publication, or quotation of the materials. This element may also indicate the absence of restrictions, such as when copyright or literary rights have been dedicated to the public.

LC practice requires the inclusion of information about the presence of restrictions on use. If there are no restrictions on use, it is recommended that this be noted.

See also:

Labels/Heads:

Choose or formulate required <head> appropriate to content, e.g.

• Restrictions
• Copyright Status

Encoding Analog:

540

Other Attributes:

n/a

Subelements:

n/a

Tagging Example 1.

Generic statement of restrictions on use

Display of Tagging Example 1.

Generic statement of restrictions on use

Tagging Example 2.

Copyright notice (status of copyright is unknown)

Display of Tagging Example 2.

Copyright notice (status of copyright is unknown)

Tagging Example 3.

Copyright retained by creator

Display of Tagging Example 3.

Copyright retained by creator

Comments:

Do not confuse with <accessrestrict>, which deals with restrictions on gaining access to collection materials rather than the use that may be made of them once access is obtained.

Repeatable:

yes

Order:

following <appraisal> and preceding <accessrestrict>

Revision Date:

08/09/02

Alternate Form of the Materials Available

Table of Contents Number:

Tag:

Description:

Availability of all or part of the collection material in multiple formats for patrons to use, such as microform, digital, paper facsimile, or reformatted audio or video materials. Information about the material might include the format of the alternate form, its extent, identifying codes, and the source/procedure for ordering copies. This is not the place to record all forms of content contained within the collection.

If copies exist in more than one format, <altformavail> may be repeated with a head appropriate to its content.

LC practice requires the inclusion of information about alternate forms of material if such exist.

See also:

Labels/Heads:

Choose or formulate required <head> appropriate to content, e.g.

• Microform
• Microfilm

• Electronic Format

Encoding Analog:

530

Other Attributes:

n/a

Subelements:

n/a

Tagging Example 1.

Extent and terms of availability of microfilm edition of entire collection

Display of Tagging Example 1.

Extent and terms of availability of microfilm edition of entire collection

Tagging Example 2.

Availability of part of collection in digitized form

Display of Tagging Example 2.

Availability of part of collection in digitized form

location of digitized version given as hot link using <extref> tag

Tagging Example 3.

Link to Web includes information about availability of reproductions

Display of Tagging Example 3.

Link to Web includes information about availability of reproductions

location of digitized version given as hot link using <extref> tag

Comments:

• If a collection is available in multiple formats (for instance, microform and electronic), separate paragraphs with appropriate headings should be used. See Examples 1 and 2.
• 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 of a division's finding aids, it may be better to make a link to an external entity such as a web site where such information is available. See Example 3.
• Two scenarios may apply in the use of <altformavail> for electronic content:
• 1. Electronic forms of collection material are available in a separate presentation (e.g., Rael collection in 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

• 2. Electronic forms of collection materials are available in a separate presentation (e.g., Bernstein collection in 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."

Repeatable:

yes

Order:

following <accessrestrict> and preceding <prefercite>

Revision Date:

08/09/02

Preferred Citation of the Material

Table of Contents Number:

Tag:

Description:

Standard statement supplied by the repository to be used in citing its holdings. This may be a generic citation (which may be provided as an entity file) or a citation specific to the collection. If there are varying preferred citation formats for different original media or modes of publication, examples of all the citations relevant to the collection should be provided.

LC practice recommends the inclusion of information about the form of preferred citation.

See also:

Labels/Heads:

Recommended content of required <head>:

• Preferred Citation

Encoding Analog:

524

Other Attributes:

n/a

Subelements:

n/a

Tagging Example 1.

Manuscript Division citation form

Display of Tagging Example 1.

Manuscript Division citation form

Tagging Example 2.

American Folklife Center citation form

Display of Tagging Example 2.

American Folklife Center citation form

Comments:

• Do not use this element for bibliographic citations of published material (MARC encoding analog 510); these should be tagged using <bibref>.
• It is recommended that each custodial division in LC provide a preferred citation for its materials. This is particularly useful to ensure that researchers find cited material in the correct custodial division, and to distinguish similarly named collections (such as the multiple Walt Whitman collections).

Repeatable:

n/a

Order:

following <altformavail>; final element within <admininfo>

Revision Date:

08/09/02

Accruals

Table of Contents Number:

Tag:

Description:

Information about anticipated additions to the materials being described, such as date, frequency, or quantity of anticipated additions. Repositories may wish to indicate simply that future additions to a collection are expected, or conversely, that no further additions are expected.

See also:

Labels/Heads:

Recommended content of required <head>:

• Accruals

Encoding Analog:

584

Other Attributes:

n/a

Subelements:

n/a

Tagging Example 1.

Collection is complete (accruals not expected)

Display of Tagging Example 1.

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 materials is received on a regular basis.

Repeatable:

yes

Order:

following <custodhist> and preceding <processinfo>

Revision Date:

08/09/02

Appraisal

Table of Contents Number:

Tag:

Description:

Information about criteria for determining the archival value of documentary material for acquisition or retention by an archival repository. ("Appraisal" in this sense does not pertain to determining monetary value of collection material.) This element can be used to document both original appraisal decisions and reappraisals that resulted in significant weeding or deaccessioning.

See also:

Labels/Heads:

Recommended content of required <head>:

• Appraisal
• Retention Criteria

Encoding Analog:

583$a

Other Attributes:

n/a

Subelements:

n/a

Tagging Example 1.

Disposition of material not retained as result of appraisal decision

Display of Tagging Example 1.

Comments:

Used primarily for archival records; unlikely to be used at LC.

Repeatable:

yes

Order:

following <processinfo> and before <userestrict>

Revision Date:

08/09/02

Processing Information

Table of Contents Number:

Tag:

Description:

Information about accessioning, arranging, describing, preserving, storing, or otherwise preparing the described materials for research use. This information may include:

• who processed the original collection materials
• who created the finding aid (intellectual content)
• what sorts of data migration or reformatting took place

See also:

See also:

Labels/Heads:

Choose or formulate required <head> appropriate to content, e.g.

• Processing History
• Transfers
• Location of Materials
• Reformatted Materials

Encoding Analog:

583

Other Attributes:

n/a

Subelements:

n/a

Tagging Example 1.

Initial processing, additions, and published LC description

Display of Tagging Example 1.

Initial processing, additions, and published LC description

Tagging Example 2.

Transfers within LC divisions

Display of Tagging Example 2.

Transfers within LC divisions

Tagging Example 3.

Notes processing of collection and revision of finding aid; names processors

Display of Tagging Example 3.

Notes processing of collection and revision of finding aid; names processors

Tagging Example 4.

Identifies conversion of sound recordings unavailable for public use

Display of Tagging Example 4.

Identifies conversion of sound recordings unavailable for public use

Tagging Example 5.

Notes reformatting of electronic data via WordPerfect to paper form

Display of Tagging Example 5.

Notes reformatting of electronic data via WordPerfect to paper form

Comments:

• The data recorded in this element will vary according to divisional policies. For instance, Manuscript Division uses <processinfo> to record dates and types of major processing activities (e.g., additions to the collection) only after initial processing and guide creation has taken place. It also records information about LC publications that further describe the collection. See Example 1.
• If it is desired to record different types of processing information with appropriate heads, multiple <processinfo> elements may be used. It is recommended but not required that these elements occur sequentially. See Example 1 together with Example 2.
• 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. Follow local practice in what's recorded here. See Example 3.
• <processinfo> may include information about material transferred to other Library divisions; alternately, such information (especially a detailed listing of transferred material) would be coded elsewhere as <separatedmaterial>. This information may also be recorded in both places. See Example 2.
• 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. See Example 4 and Example 5. If original material is still available for public use, these newly formatted versions would be listed in <altformavail> instead.)

Repeatable:

yes

Order:

following <accruals> and preceding <appraisal>

Revision Date:

08/09/02

Biographical Sketches and Agency Histories

Table of Contents Number:

Tag:

Description:

Contextual information about the creation or formation of a body of archival materials in the form of a creator sketch which provides background information about the individual, family, or organization which created or collected the materials. The information may be presented as a narrative text and/or as a chronology.

LC practice recommends inclusion of biographical data about the originator/s (creator/collector) in the <bioghist> element.

See also:

Labels/Heads:

Choose or formulate required <head> appropriate to content, e.g.,

• Biographical Note
• Organizational History
• Genealogy Chart

Encoding Analog:

545

Other Attributes:

n/a

Subelements:

• <chronlist>
• <listhead>
• <head01>
• <head02>

• <eventgrp>
• <date>
• <event>

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

Tagging Example 1.

Narrative text for Rael Collection

Display of Tagging Example 1.

Narrative text

Tagging Example 2.

Chonological list for Shaker Collection (single <bioghist>)

Display of Tagging Example 2.

Panorama display with list headings suppressed

Tagging Example 3.

Chonological list for Papers of Wilbur and Orville Wright (multiple bioghist elements)

Display of Tagging Example 3.

Chonological list (multiple bioghist elements)

Tagging Example 4.

Genealogical chart with nested lists

Display of Tagging Example 4.

Genealogical chart with nested lists

Comments:

• Biographical information in <bioghist> may be expressed as a narrative text (Example 1), as a chronological list (Examples 2-3), or as a simple list (Example 4).
• When <chronlist> tagging is used, be sure to include list head tagging that are required for proper accessibility in a Web display. See <listhead> in Example 2.
• When multiple biographical notes/agency histories are appropriate to the content of a single finding aid (for example, the papers of Wilbur and Orville Wright, or the Herndon-Weik Collection of Lincolniana), <bioghist> elements may be created for each individual or organization which needs contextual information (e.g., Charles Eames, Ray Eames; or, William Henry Herndon, Jesse William Weik, Abraham Lincoln). It does not matter whether these are in narrative form, chronology form, or both. It is suggested that each <bioghist> be bundled under one overall <bioghist>. Within each <bioghist>, use a <head> which indicates the person or organization being described. See Example 3.
• If biographical information is neither narrative nor a chronological list, e.g., a genealogical chart, use appropriate text formatting such as <list> or <table>. See Example 4.
• LC practice recommends the inclusion of <bioghist>, as this element is required by ISAD-G. If little is known about an individual or organization, provide a brief description in the format desired (e.g., narrative or chronlist). Conversely, if the individual or organization is very well known and a full <bioghist> is not desired in the finding aid, provide at least the information available in the 545 field (Biographical/Historical Note) and cite a standard reference source if desired.

Repeatable:

yes (and recursive)

Order:

following <admininfo> and preceding <scopecontent>

Revision Date:

08/09/02

Scope and Content Note

Table of Contents Number:

Tag:

Description:

Summary overview of the range and topical coverage of the collection, often mentioning their form and organization, and naming significant individuals, organizations, events, places, and subjects represented in the materials.

LC Practice requires inclusion of a scope and content note. While a description of the organization or arrangement of the collection as a whole forms a natural part of the Scope and Content Note, LC practice recommends formally encoding this information separately in an <arrangement> or <organization> section in view of emerging community practice.

See also:

Labels/Heads:

Recommended content of required <head>:

• Scope and Content Note

Encoding Analog:

520

Other Attributes:

n/a

Subelements:

• <head>
• <p> (repeatable)

Tagging Example 1.

Scope and Content Note with head and paragraphs

Display of Tagging Example 1.

Scope and Content Note with head and paragraphs

Comments:

Summary overview information is also presented in a series-by-series description in the Description of Subordinate Components. Judgement should be used in determining the fullness of description in the overall Scope and Content Note with that given in the <scopecontent> for each series in the <dsc>.

The <scopecontent> is recursive; separate <scopecontent> elements may be nested within a single <scopecontent>, for example,

• for a multi-divisional finding aid with different discussions for holdings of each division
• for a collection organized and described in parts
• to enable the extraction of the first paragraph for use as content in a MARC record (see Application Guidelines for example).

While a description of the organization or arrangement of the collection as a whole forms a natural part of the Scope and Content Note, LC practice recommends formally encoding this information separately in an <arrangement> section. See Section 3.5.1.6b for further guidance.

Repeatable:

yes (and recursive)

Order:

following <bioghist> and preceding <dsc>

Revision Date:

08/09/02

Organization and Arrangement

Table of Contents Number:

Tag:

Tag:

Description:

The Organization and Arrangement elements record statements about the organization or arrangement of the collection as a whole. One or both elements should be used for each collection.

LC practice recommends encoding this information separately in an <arrangement> or <organization> section in view of emerging community practice. These elements may also be used at the component level to explain the organization or arrangment of papers within that component.

New in EAD2002: the <organization> element is deprecated. Instead, use the <arrangement> tag for descriptions of organization and/or arrangement.

See also:

See also:

Labels/Heads:

Choose or formulate required <head>, e.g.:

• Organization of the Papers (organization)
• List of Series (organization)
• Arrangement of the Papers (arrangement)

Encoding Analog:

Encoding analog 351$a (organization); encoding analog 351$b (arrangement); 351 if intermingled

Other Attributes:

n/a

Subelements:

• <head>
• <p>
• <list>
• <item>

Tagging Example 1.

Organization statement

Display of Tagging Example 1.

Organization statement

Tagging Example 2.

Arrangement statement

Display of Tagging Example 2.

Arrangement statement

Comments:

• Encode as <organization> the manner in which the collection has been ordered (e.g., organized into series; see Example 1), as <arrangement> the filing sequence of the material (e.g., alphabetical or chronological; see Example 2). Encode as <arrangement> is statements about organization and arrangement are intermingled.
• Organization and arrangement statements may also be encoded as such within <scopecontent>, although this option is not followed at LC.

• Information on the organization or arrangement of each subordinate component such as series or subseries should be encoded at the component level.
• 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.
• Consult the Tag Library for guidance as to whether <organization> or <arrangement> is the appropriate tag; do not rely on the language used in the finding aid (arranged, organized) to determine this.

Repeatable:

yes (and recursive)

Order:

Following <scopecontent> and preceding <dsc>

Revision Date:

09/19/02

Generic Text and Formatting Elements

Table of Contents Number:

Description:

Use judgment in deciding when to place punctuation in an encoded document and when to let a style sheet supply the punctuation; see the Application Guidelines for further guidance.

Remember that finding aids viewed externally using a different style sheet or HTML encoding scheme may not supply the punctuation your internal style sheet does, and determine whether this is an acceptable risk. Also remember that if some finding aids include the punctuation and others supply by style sheet, it will be difficult to program the HTML transformation consistently to avoid double punctuation where it is already present.

If container lists are created in a database, it is more logical to assume that commas don't need to be included. If the document already exists in a word processing format, the commas are already present and extra work is required to strip them out. If in doubt, omit punctuation.

See also:

Encoding Analog:

n/a

Other Attributes:

n/a

Subelements:

• <head> See Section 3.5.1.7.1, Heading
• <p> See Section 3.5.1.7.2, Paragraph
• <note> See Section 3.5.1.7.3, Note

Tagging Example 1.

Whitespace outside the element for inline title element

Display of Tagging Example 1.

Tagging Example 2.

Punctuation outside the element for inline emph element

Display of Tagging Example 2.

Tagging Example 3.

Period included at end of inline title element as required by editorial practice

Display of Tagging Example 3.

Comments:

• Put whitespace outside the element for inline element. See Example 1.
• Put punctuation outside the element for inline element. See Example 2.
• Include punctuation at end of inline element when editorial practice dictates. See Example 3.

Repeatable:

n/a

Order:

n/a

Revision Date:

08/09/02

Heading

Table of Contents Number:

Tag:

Description:

• Headings are used to identify blocks of text within a finding aid for display and navigation (where <head> is not available, the label attribute is used to identify text but not to aid in navigation).
• Heads always appear as the first subelement within a section of text, and should be used to ensure that a direct link to that section is included in the navigator or table of contents for the finding aid.
• Heads are not used within components in the <dsc>; in that instance, <unittitle> elements for components with LEVEL attribute set to "series" or "subseries" may be pulled into the navigation frame.

See also:

Labels/Heads:

n/a

Encoding Analog:

n/a

Other Attributes:

n/a

Subelements:

n/a

Tagging Example 1.

Heads provided for both Administrative Information Section and provenance paragraph

Display of Tagging Example 1.

Heads provided for both Administrative Information Section and provenance paragraph

Display of heads in navigator illustrated: provenance head is subordinate to that for <admininfo>

Comments:

Headings are illustrated for each element for which they are valid.

Repeatable:

no

Order:

first element within any section where valid

Revision Date:

08/09/02

Paragraph

Table of Contents Number:

Description:

The paragraph element is an important structural element within EAD. It must be used within many elements before text can be inserted, and can be used to format text within those elements into one or multiple units. Within paragraph, many other elements are available for use within text, including reference and linking elements, formatting elements, controlled access elements, and some <did> subelements.

See also:

Labels/Heads:

n/a

Encoding Analog:

n/a

Other Attributes:

n/a

Subelements:

n/a

Tagging Example 1.

Paragraph used within <separatedmaterial>; linking and controlaccess elements available within <p>

Display of Tagging Example 1.

Paragraph used within <separatedmaterial>; linking and controlaccess elements available within <p>

Tagging Example 2.

Less detailed tagging: published titles tagged with <title> and no attribute. Single and double quotes from keyboard used rather than <title> tagging for names of poems and <emph> for Hoosier poet.

Display of Tagging Example 2.

Display is identical with that of Example 3

Tagging Example 3.

More detailed tagging: published titles tagged with <title> and render attribute. Double quotes from keyboard deleted in favor of <title> tagging for names of poems and <emph> for Hoosier poet.

Display of Tagging Example 3.

Display is identical with that of Example 2

Comments:

• Although paragraphs can be used in many places on their own, be sure to encode the text as specifically as is appropriate for consistency in display and retrieval. For example, you may need to use <note><p> rather than <p> alone; or use <admininfo><altformavail><p> rather than <admininfo><p> .
• Titles (such as titles of published works) are among the data and elements found with paragraphs. By standard practice at LC and elsewhere, an encoded <title> displays as italic unless otherwise specified. See Example 2.
• Titles of unpublished works and other titles customarily given in double quotes may be handled in one of two ways: they need not be encoded as titles, and keyboarded double quotes ("") may be retained in the SGML document. (Single and double quotation marks may be keyboarded in rather than using the SGML entities such as &lsquo; and &rdquo;). See Example 2.
• Alternately, one may explicitly encode <title render="italic"> for published titles and <title render="quoted"> for unpublished or other quoted titles. See Example 3. Although the second alternative is most precise, it need not be considered if there is no anticipated use of the <title> tag for searching or building a browse list of titles.

Repeatable:

yes

Order:

n/a

Revision Date:

08/09/02

Note

Table of Contents Number:

Tag:

Description:

The note element is available in many places as explanatory text. This element is used for supplementary data such as footnotes and should not be used when more specific elements are available.

See also:

Labels/Heads:

n/a

Encoding Analog:

500$a

Other Attributes:

n/a

Subelements:

n/a

Tagging Example 1.

Note is short explanatory text; no special display required

Display of Tagging Example 1.

Note is short explanatory text; no special display required

Comments:

The display of notes as footnotes may be controlled by use of the actuate and show attributes which control linking behavior. Please note that this behavior has not yet been successfully implemented using the Panorama viewer or HTML display.

Repeatable:

yes

Order:

n/a

Revision Date:

08/09/02

What is a Component?

Table of Contents Number:

Tag:

Description:

Components are wrapper elements that designate a subordinate part of the archival materials being described. They may be used to designate common units such as series, subseries, file, and item, or any intervening levels of hierarchical arrangement. Components may be represented as nested <c> elements or components may be numbered (<c01>, <c02> etc.).

LC Practice mandates the use of components in the Description of Subordinate Components <dsc> and recommends setting the LEVEL attribute for all component levels.

See also:

Labels/Heads:

n/a

Encoding Analog:

n/a

Other Attributes:

• level="series"
• level="subseries"
• level="file"
• level="item"

See Tag Library for full list of valid attribute values for LEVEL.

Subelements:

• <did>
• <unittitle>Required See 3.5.2.3.1.1a, Unit Title
• <unitdate> Required if available See 3.5.2.3.1.1b, Unit Date
• <physdesc> Recommended if available See 3.5.2.3.1.2, Physical Description
• <abstract> See 3.5.2.3.1.3, Abstracts
• <unitid> Recommended if available See 3.5.2.3.1.4a, ID Numbers
• <physloc> See 3.5.2.3.1.4b, Physical Location Information
• <container>Recommended See 3.5.2.4, Physical Location and Container Information
• <note> See 3.5.2.3.2, Expanded Description of Components
• <dao> See 3.5.2.3.2, Expanded Description of Components

• <admininfo> See 3.5.2.3.2, Expanded Description of Components
• <bioghist> See 3.5.2.3.2, Expanded Description of Components
• <scopecontent> See 3.5.2.3.2, Expanded Description of Components
• <add> See 3.5.2.3.2, Expanded Description of Components
• <odd> See 3.5.2.3.2, Expanded Description of Components

Tagging Example 1.

Collection with series and some subseries

Display of Tagging Example 1.

Collection with series and some subseries

Tagging Example 2.

Collection with complex subseries arrangement

Display of Tagging Example 2.

Collection with complex subseries arrangement

Tagging Example 3.

Small collection with no series

Display of Tagging Example 3.

Small collection with no series

Comments:

• Set LEVEL attributes of "series" or "subseries" for components whose titles should be displayed in a navigator, e.g. series and subseries.
• Set LEVEL attributes of "file" or "item" for all other components. This is a change in LC Practice.
• 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. See Example 1, second series.
• Not all series have subseries; in series that do not, <c02> elements have attribute level="file" (or, in unusual cases, level="item"). See Example 1, first series.
• 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. See Example 2.
• If a collection is not arranged into series (small collections especially), set <c01 level="file"> and subordinate levels at file or item, as appropriate. See Example 3.
• 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. Consider supplying these post-encoding using search-and-replace, macros, or xsl stylesheets as possible.

Repeatable:

yes (and recursive)

Order:

within <dsc>

Revision Date:

10/04/02

Unnumbered Versus Numbered Components

Table of Contents Number:

Tag:

Description:

LC practice is to use 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 (see EAD Application Guidelines 3.5.2.2 for full discussion).

See also:

Labels/Heads:

n/a

Encoding Analog:

n/a

Other Attributes:

• level="series"
• level="subseries"
• level="file"
• level="item"

See Tag Library for full list of valid attribute values for LEVEL.

Subelements:

n/a

Comments:

• If a collection is arranged into series, set attributes <c01 level="series">
• The decision to use numbered components at LC is a pragmatic choice between two equally valid alternatives; one early finding aid was encoded using unnumbered components. Numbered and unnumbered components must never be mixed in a single finding aid.
• LEVEL attributes should be set whether are not components are numbered.

Repeatable:

n/a

Order:

n/a

Revision Date:

8/12/02

Unit Title

Table of Contents Number:

Tag:

Description:

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

LC Practice requires the inclusion of unittitle information within each component <did>. Dates of component material are encoded as <unitdate> within the <unittitle>.

See also:

See also:

Labels/Heads:

Encoding Analog:

245$a (include other subfields if they are part of the title transcription).

Other Attributes:

• id (use if the series title is the target of a link, e.g., from another component or from the Scope and Content note).

Subelements:

• <unitdate>

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

Tagging Example 1.

<unittitle> for series includes ID attribute since links have been made to the series title

Display of Tagging Example 1.

<unittitle> for series includes ID attribute since links have been made to the series title

Comments:

• EAD permits the use of <unitdate> either as a subelement of <unittitle> or used at the same level as <unittitle>. LC follows United States practice 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.

Repeatable:

yes

Order:

within <c><did>

Revision Date:

08/12/02

Unit Date

Table of Contents Number:

Tag:

Description:

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

LC Practice requires the inclusion of unitdate information at appropriate component levels within the Description of Subordinate Components.

New in EAD 2002: the TYPE attribute will be used only to distinguish inclusive and bulk dates, and the value "single" will no longer be valid.

See also:

Labels/Heads:

n/a

Encoding Analog:

260$a (for any type dates, according to visual material cataloging practice); 245$f (type="inclusive"), according to APPM cataloging practice; or 245$g (type="bulk") according to APPM cataloging practice

Other Attributes:

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

Subelements:

n/a

Tagging Example 1.

<unitdate> encoded at all component levels; TYPE, NORMAL, ENCODINGANALOG attributes set

Display of Tagging Example 1.

<unitdate> encoded at all component levels; TYPE, NORMAL, ENCODINGANALOG attributes set

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. This practice is new at LC. This may be readily incorporated when container list information is captured in a database, but may take a while to phase in in other conversion routines.
• All <unitdate> elements should have the LEVEL attribute set. As the most common value will be "inclusive", it may be possible to build this default into creation and conversion tools and modify where appropriate.
• Normalization attributes should be set for dates to take advantage of date searching (not yet implemented at LC). This practice is new at LC. It may take some time to develop date normalization tools and macros.
• Date normalization will follow ISO standard 8601. Follow this normalization standard also for <date> elements normalized in the <eadheader> and elsewhere as appropriate. Note that examples in the current EAD Tag Library do not illustrate the use of this standard.
• Note that some <unittitle> elements consist solely of unitdate information. See Example 1.

Repeatable:

yes

Order:

within <c><did><unittitle>

Revision Date:

10/04/02

Physical Description

Table of Contents Number:

Tag:

Description:

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

LC 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>.

See also:

See also:

Labels/Heads:

n/a

Encoding Analog:

n/a

Other Attributes:

n/a

Subelements:

• <extent encodinganalog="300">

Tagging Example 1.

Folder count and volume count both encoded as <physdesc><extent>

Display of Tagging Example 1.

Comments:

• Past practice varied among divisions as to whether extent information was included directly under the <physdesc> tag or within <extent> tags in <physdesc>. Future finding aids will be encoded using <physdesc><extent>, since extent is a required element in ISAD-G.

Repeatable:

yes

Order:

within <c><did>

Revision Date:

8/12/02

Abstracts

Table of Contents Number:

Tag:

Description:

In the past, <abstract> has been used in the container list for brief, summary information about the contents of a component, e.g., list of selected correspondents.

LC Practice now recommends using <scopecontent> for all description of component contents rather than distinguishing between <abstract> and <scopecontent>.

See also:

See also:

Labels/Heads:

n/a

Encoding Analog:

n/a

Other Attributes:

n/a

Subelements:

n/a

Comments:

• Past practice at LC attempted to distinguish between the uses of <abstract> and <scopecontent> for component-level description. The <abstract> element was added to the EAD DTD to allow for brief summary description of the collection as a whole; while it is valid at the component level, evolving community standards deprecate this use. Instead, <scopecontent>, an ISAD-G element, should be used in component descriptions.

Repeatable:

yes

Order:

n/a

Revision Date:

8/12/02

ID Numbers

Table of Contents Number:

Tag:

Description:

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.

LC Practice recommends the use of <unitid> for identifying numbers assigned either by the repository or by the creator of the collection materials. When numbers are assigned by the repository and used for the retrieval of collection material, repeat identification numbers at each component level. This is a change in LC Practice.

See also:

Labels/Heads:

label="Call no.:" (or another appropriate label; use no label if output display not desired)

Encoding Analog:

050, 090, 099, or other MARC field as appropriate (see catalog record). Creator-supplied identification numbers may have no encoding analog.

Other Attributes:

n/a

Subelements:

n/a

Tagging Example 1.

Lot numbers assigned by repository using <unitid> given at each component level

Display of Tagging Example 1.

Lot numbers assigned by repository using <unitid>

Tagging Example 2.

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

Display of Tagging Example 2.

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

Comments:

• In order to identify the location of components within a container list for retrieval purposes, some divisions use <unitid> predominantly in their container lists (e.g., P&P, for lot numbers) . When unitid is the identifier by which collection material is retrieved, repeat this information at every component level for better search results, data extraction, and navigation of long lists of headings. See Example 1.
• Other divisions use <container> predominantly (e.g., MSS, for box and reel numbers), depending on the nature of the retrieval system used. In some situations both <unitid> and <container> numbers will be appropriate within a single collection. See Example 2.
• See Tag Library and Application Guidelines for further clarification of the differences between <unitid> and <container>.

Repeatable:

yes

Order:

within <c><did>

Revision Date:

4/5/02

Physical Location Information

Table of Contents Number:

Tag:

Description:

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).

See also:

Labels/Heads:

n/a

Encoding Analog:

852$z, 090, or other MARC field as appropriate (see catalog record)

Other Attributes:

n/a

Subelements:

n/a

Tagging Example 1.

<physloc> indicates repository material physically housed elsewhere in Library

Display of Tagging Example 1.

<physloc> indicates repository material physically housed elsewhere in Library

Comments:

n/a

Repeatable:

yes

Order:

within <c><did>

Revision Date:

08/12/02

Expanded Description of Components

Table of Contents Number:

Tag:

Description:

Elements which are available to describe the collection as a whole (e.g., <scopecontent>, <arrangement>, <organization>, as well as <admininfo> and <add> and their subelements) may also be used outside the <did> at the component level to which they best apply.

New in EAD 2002: elements currently subordinate to <admininfo> and <add> can be used directly within components. Use <arrangement> for statements about organization or arrangement within the component.

See also:

See also:

See also:

See also:

See also:

See also:

See also:

See also:

See also:

See also:

Labels/Heads:

n/a

Encoding Analog:

520 (scopecontent), 500 (note, odd). See section 3.5.1.4 for encoding analogs of <admininfo> subelements

Other Attributes:

n/a

Subelements:

n/a

Tagging Example 1.

Component described with <scopecontent> (2 paragraphs)

Display of Tagging Example 1.

Component described with <scopecontent> (2 paragraphs)

Tagging Example 2.

<note> within <did>

Display of Tagging Example 2.

<note> within <did>

Tagging Example 3.

<odd> for miscellaneous component information

Display of Tagging Example 3.

<odd> for miscellaneous component information

Tagging Example 4.

Includes <scopecontent>, <arrangement>, and <altformavail> within <admininfo>

Display of Tagging Example 4.

Includes <scopecontent>, <arrangement>, and <altformavail> within <admininfo>

Tagging Example 5.

Restricted container noted at component level and as container attribute

Display of Tagging Example 5.

Restricted container noted at component level and as container attribute

Tagging Example 6.

<dao> link at folder level to hit list of digitized items

Display of Tagging Example 6.

Link leads to presentation page for navigable album of cartes des visites

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. See Example 1.
• When <note> is appropriate, use inside the <did> rather than outside for convenience in generating displays. See Example 2.
• 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. See Example 3.
• Use <admininfo> as a wrapper for appropriate subelements, e.g., <admininfo><altformavail> for a component's availability in microform format. See Example 4. These elements will be available directly in EAD 2002.
• The use of elements currently subordinate to <admininfo> at the component level will usually be a supplement to general information already given at the collection level. For instance, the collection-level <admininfo> 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 <admininfo><accessrestrict> that the series is restricted. See Example 5.
• Use <scopecontent> and <arrangement> or <organization> at the series level to describe contents of the series and arrangement or organization therein. Although <arrangement> and <organization> are available inside the <scopecontent>, we recommend encoding them at the same level as <scopecontent>. Sometimes arrangement will be inextricably intertwined with scope information and cannot be marked separately. See Example 4.
• Use <dao> in components at the folder or item level when digitization has taken place selectively. Even if links are made to single intellectual items, the <dao> 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 at the Library. See Example 6.
• Use <dao> at the series (or subseries) level when most or all of a collection or series has been digitized and there are external navigational aids, such as the American Memory interface, which mirrors the arrangement in the container list.
• When multiple items in a folder are digitized and description stops at the folder level, the <dao> 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.
• Note: when EAD 2002 is implemented, LC will use <daogrp> instead in compliance with RLG Best Practice Guidelines.

Repeatable:

yes

Order:

within <c> or <c><did>

Revision Date:

9/23/02

Physical Location and Container Information

Table of Contents Number:

Tag:

Description:

Container numbers and control numbers are used to identify physical housing aspects such as boxes, folders, and reels of microfilm. Setting the correct attribute type 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.

LC Practice recommends as minimum best practice 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. This is a change from current LC practice.

See also:

Labels/Heads:

Use only as appropriate, e.g.:

• label="Restricted"
• label="Not filmed"

Encoding Analog:

n/a

Other Attributes:

Choose required TYPE attribute from semiclosed list. Typical values would be:

• type="box"
• type="folder"
• type="reel"
• type="frame"
• type="box-folder"

Or, choose type="othertype" and set OTHERTYPE attribute, e.g.:

• othertype="item"
• othertype="mss"

See Tag Library for full list of valid attribute values.

Subelements:

n/a

Tagging Example 1.

TYPE attribute set; container numbers repeated

Display of Tagging Example 1.

TYPE attribute used to generate display label for container numbers in left column

Note: display of repeated container numbers suppressed

Display of Tagging Example 1.

TYPE attribute used to generate display label for container numbers in left column

Note: all container numbers displayed

Display of Tagging Example 1.

TYPE attribute used to generate display label

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

Tagging Example 2.

TYPE and OTHERTYPE attribute set

Display of Tagging Example 2.

TYPE and OTHERTYPE attribute set

Tagging Example 3.

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

Display of Tagging Example 3.

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

Tagging Example 4.

TYPE and LABEL attributes set