Library of Congress

Recommended Best Practices for Encoded Archival Description Finding Aids at the Library of Congress (EAD Version 2002)

DRAFT

December 9, 2004

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

Table of Contents

List of Practices

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 2002 and EAD Application Guidelines, published by the Society of American Archivists and the Library of Congress and available online at http://lcweb.loc.gov/ead/. The guidelines in this current draft accompany Chapter 3 of the Application Guidelines, "Creating Finding Aids in EAD." They also conform to the Research Library Group's "RLG Best Practice Guidelines for Encoded Archival Description" (August 2002), available online at http://www.rlg.org/rlgead/bpg.pdf.

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

The guidelines for version 1.0 of the EAD DTD were made available to the Library of Congress EAD Technical Group for review, and many suggestions for improvement have been incorporated into a final draft which is available for use by Library staff. This document has been revised in compliance with EAD 2002, and includes revision of the numbering of practices in the table of contents.

For further information about the creation or content of this document, please contact the working group at lcead@loc.gov.

LC EAD Practices Working Group:

• Morgan Cundiff, Network Development and MARC Standards Office
• Mike Ferrando, Music Division
• Margit Kerwin, Manuscript Division
• Mary Lacy, Manuscript Division (chair)
• Anne Mitchell, Prints and Photographs Division
• Belinda Urquiza, Automation Planning and Liaison Office

Basic Conventions Used

The LC Practices guidelines are based on the EAD Application Guidelines and cite its chapter and subordinate numbers to facilitate cross-consultation. Each of the individually numbered sections described below is referred to as a "practice." 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. The order of practices reflect the recommended order of elements in an EAD finding aid.

This section of the guidelines describe the contents of each section of an individual practice.

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 locally assigned number follows the order recommended or required by the LC Best Practice Guidelines and the EAD DTD.

Guidelines Number:

This number matches the one given in the Application Guidelines (version 1.0). 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 elements under discussion are provided in the tag section. Tag names appear within angle brackets, e.g., <acqinfo>. No tag is given if the practice does not concern a specific element or elements.

Description:

The description section provides a 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. For some practices a third paragraph, "new in EAD 2002", describes changes in the new EAD DTD.

See also:

References provided here list other practices within this document related to the current topic. These references are not active links in this version of the document.

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:

• All encoding analogs used are MARC21.
• 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 Tag Library, Appendix A.3, for a crosswalk between MARC21 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.

Set the SCRIPTCODE attribute for <language> within <langusage> and <langmaterial> using ISO 15924 only if nonroman script needs to be noted.

The most common values for the SOURCE attribute on controlled access elements are those listed in the semiclosed list from EAD version 1.0. These values are: aat, aacr2, cdwa, dot, gmgpc, lcnaf, lcsh, lctgm, local, mesh, mim, ncarules, nmc, rad, rbgenr, tgn, ulan.

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. The order of the practices associated with these subelements follows 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 <descgrp>").

Revision Date:

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

Implementing XML in EAD 2002

The Library of Congress implemented EAD version 1 as an SGML DTD. Implemention of the new EAD DTD (EAD 2002) will incorporate migration of SGML files to XML files. All new EAD finding aids will be created in XML using EAD 2002; legacy finding aids will be converted to XML and migrated to EAD 2002. The LC Practices describe encoding changes throughout the document and highlight these with the label, "New in EAD 2002". This section discusses the features of XML which differ from SGML as found in EAD finding aids; further information about XML is widely available and may be found at http://xml.coverpages.org/xml.html.

XML is Case Sensitive

Because XML is case sensitive (upper- and lower-case characters are not interchangeable), the EAD 2002 XML DTD requires that all element names, attribute names, and enumerated attribute values be in lower case.

In particular, the following must be in lower case for the document to validate:

• the XML declaration (<?xml version="1.0" encoding="utf-8"?>)
• the XML doctype declaration root element (ead) and DTD file name ("ead.dtd")
• the XML entity declaration NDATA literal (file format, e.g., "jpeg")

XML Character Encoding

The default character encoding for XML is UTF-8 or UTF-16. Character encoding transformations are included in the conversion from EAD version 1 to EAD 2002. The W3C strongly discourages use of the character entity references found in SGML documents (such as &eacute;), and not all XML tools support these entity references. While valid in XML, these entity references should be replaced using the graphic character displays or numeric character references, as appropriate. For basic information on character encoding issues related to Unicode and XML, see the RLG DigiNews article on Character Sets and Character Encoding: A Brief Introduction at: http://www.rlg.org/en/page.php?Page_ID=17068&Printable=&Article ID=992

Differences between SGML Prolog and XML Prolog

1. XML declaration required: Use the following:

<?xml version="1.0" encoding="utf-8"?>

2. Public identifiers: XML syntax and values are different from the SGML public identifer. Use the following:

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

3. System identifiers: XML requires the use of a system identifier. Use the following:

"http://lcweb2.loc.gov/xmlcommon/dtds/ead2002/ead.dtd"

4. Processing instructions: SGML applications such as Panorama required processing instructions such as <?ATTLINK EXTPTR HREF URI> to resolve external entities. While these are permitted in XML, they are no longer necessary and should not be added to newly encoded finding aids.

Examples of the full XML prolog may be seen in Section 2.2.2, External Linking, Examples 1 and 2.

Converting from SGML EAD Version 1

LC finding aids encoded using EAD Version 1 will be converted from SGML to XML and transformed into EAD 2002 using conversion routines available at http://lcweb2.loc.gov/music/eadmusic/eadconv12/ead2002_r.htm. In addition to converting to the new DTD, all elements, attributes, and most attribute values will be converted to lowercase. Notation of empty elements is changed into XML (e.g. line breaks are now appear as "<lb/>). SGML character entities will be converted to UTF-8 values. A few additional changes will need to be done to the XML files after they have been converted:

1. After validating the XML instance on the local PC and before uploading the file to the server change the system identifer to include the full path to the location of the DTD on the server; in other words, change

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

to

<!DOCTYPE ead PUBLIC "+//ISBN 1-931666-00-8//DTD ead.dtd (Encoded Archival Description (EAD) Version 2002)//EN" "http://lcweb2.loc.gov/xmlcommon/dtds/ead2002/ead.dtd">

2. In Collection Summary, move <langmaterial> element from the end of the <did> to immediately follow <repository> as specified in Section 3.3.1.6, Language of the Material.

3. Look at the conversion report to make sure that all data has been migrated success; in addition, review the encoding of the finding aid to make sure that the finding aid is in major compliance with the current version of the LC Practices.

Differences Between Converted Finding Aids and New EAD 2002 Encoding:

Processing instructions: processing instructions such as <?ATTLINK EXTPTR HREF URI> which were present in the SGML finding aids have been converted to XML format, e.g. <?ATTLINK EXTPTR HREF URI?>. These may be retained in a converted XML document but should not be added to newly encoded finding aids.

Parsed entity declarations: LC Practice recommends in Section 2.2.2, External Linking, that entity declarations for external entites linked to from the finding aid appear in either the document prolog or in a separate ".ent" file in the same directory as the finding aid. In the process of document conversion, the values of the declared entities are extracted from the declarations and appear as the value of the HREF attribute, and the entity declaration is no longer present (i.e., HREF="&arendthome;") will be changed to HREF="http://memory.loc.gov/ammem/arendthtml/". This result for converted finding aids is acceptable, but newly encoded finding aids should continue to implement the practice concerning use of external entities.

Library of Congress EAD Practices

Generic Text and Formatting Elements

Table of Contents Number:

2.1

EAD Guideline:

3.5.1.7 (Ver. 1.0)

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:

n/a

Encoding Analog:

n/a

Other Attributes:

n/a

Subelements:

• <head> See Section 2.1.1, Heading
• <p> See Section 2.1.2, Paragraph
• <note> See Section 2.1.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:

05/07/03

Heading

Table of Contents Number:

2.1.1

EAD Guideline:

3.5.1.7.1 (Ver. 1.0)

Tag:

<head>

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:

n/a

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

Comments:

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

Repeatable:

no

Order:

first element within any section where valid

Revision Date:

05/07/03

Paragraph

Table of Contents Number:

2.1.2

EAD Guideline:

3.5.1.7.2 (Ver. 1.0)

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:

n/a

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.
• 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 XML document. Single and double quotation marks may be keyboarded in rather than using the Unicode numeric character references such as &#x0027; (left single quote) and &#x201D; (right double quote.) See Example 2.
• Alternately, one may explicitly encode <title render="italic"> for published titles and <title render="doublequote"> 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:

05/24/04

Note

Table of Contents Number:

2.1.3

EAD Guideline:

3.5.1.7.3 (Ver. 1.0)

Tag:

<note>

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:

Section 3.3.1.9, Note (within high-level <did>)

Labels/Heads:

n/a

Encoding Analog:

500$a

Other Attributes:

Use as appropriate when notes should appear as footnotes, endnotes, or linked notes:

• actuate="onload" or "onrequest"
• type="footnote" or "endnote"
• show="embed" or "new"

See Tag Library for full list of attributes and their values.

Subelements:

• <p>

See Tag Library for full list of valid subelements.

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 or endnotes may be controlled by use of the ACTUATE and SHOW attributes which control linking behavior. Setting the TYPE attribute as "footnote" or "endnote" may facilitate the placement of the notes by the stylesheet used for printing.

Repeatable:

yes

Order:

n/a

Revision Date:

05/07/03

Linking Elements

Table of Contents Number:

2.2

EAD Guideline:

7.1.2 (Ver. 1.0)

Tag:

n/a

Description:

There are seventeen elements in EAD that can be used to establish links: fifteen manage links directly, while two (<daogrp> and <linkgrp>) are wrapper elements that consolidate multiple, related links. Linking elements are discussed here under the general categories of internal links (with the EAD document) and external links (to other documents.)

New in EAD 2002: linking elements <arc> and <resource> have been added.

See also:

Section 2.2.1, Internal Linking

See also:

Section 2.2.2, External Linking

Labels/Heads:

n/a

Encoding Analog:

n/a

Other Attributes:

n/a

Subelements:

• <arc> See 2.2.1 Internal Linking and 2.2.2, External Linking
• <archref> See 2.2.2, External Linking
• <bibref> See 2.2.2, External Linking
• <dao> See 2.2.2, External Linking
• <daogrp> See 2.2.2, External Linking
• <daoloc> See 2.2.2, External Linking
• <extptr> See 2.2.2, External Linking
• <extptrloc> See 2.2.2, External Linking
• <extref> See 2.2.2, External Linking
• <extrefloc> See 2.2.2, External Linking
• <linkgrp> See 2.2.1, Internal Linking
• <ptr> See 2.2.1, Internal Linking
• <ptrloc> See 2.2.1, Internal Linking
• <ref> See 2.2.1, Internal Linking
• <refloc> See 2.2.1, Internal Linking
• <resource> See 2.2.1 Internal Linking and 2.2.2, External Linking
• <title> See 2.2.2, External Linking

Comments:

• Extensive information about linking can be found in Chapter 7 of the EAD Application Guidelines. Remember to check the EAD 2002 Tag Library for current values of attributes.

Repeatable:

n/a

Order:

n/a

Revision Date:

05/07/03

Internal Linking

Table of Contents Number:

2.2.1

EAD Guideline:

7.2 (Ver. 1.0)

Tag:

n/a

Description:

Internal linking enhances the ability to navigate a finding aid via explicit links between related information appearing in different places in the finding aid. Extensive information about linking can be found in Chapter 7 of the EAD Application Guidelines.

LC Practice requires the use of the TARGET, ACTUATE, and SHOW attributes with internal linking elements, and recommends the use of <ref> over <ptr> for internal linking.

New in EAD 2002: linking elements <arc> and <resource> have been added. Values for the ACTUATE attribute have changed.

See also:

Section 3.3.8.3, Indexes

See also:

Section 2.2.2, External Linking

Labels/Heads:

n/a

Encoding Analog:

n/a

Other Attributes:

• target (value of id assigned to target of link) Required
• actuate="onrequest" (means user needs to click on link for target to be displayed) Required
• show="replace" (target is displayed in place of the text just viewed) Required

See Tag Library for full list of attributes and their values.

Subelements:

Simple linking within the finding aid:

• <ref> (links with text)
• <ptr> (empty links --no text) may be bundled using <ptrgrp>

Additionally, <indexentry> may be used within the index to bundle <ref>, <ptr>, or <ptrgrp>.

Extended linking within the finding aid (must be bundled using <linkgrp>)

• <arc> (rules for traversal among resources in extended link)
• <refloc> (locator links with text)
• <ptrloc> (empty locator links --no text)
• <resource> (local resource participating in extended link)

Tagging Example 1.

Cross-reference from Hart linked to target (Rodgers)

Display of Tagging Example 1.

Cross-reference from Hart linked to target (Rodgers)

Comments:

• All links must have targets. Set the TARGET attribute for a reference with a brief unique alpha or alphanumeric identifier for the object of the link; id's must begin with an alphabetic character. For example, a container list cross reference, "See Container 17, Smith, Anna" might have attribute target="smith17". To make the link work, set the attribute id="smith17" for the <unittitle> in Container 17 to which the link should go. See Example 1.
• See Section 3.3.8.3 for a discussion of <ptrgrp>, <ptr>, and <ref> in relation to indexes.
• See the Application Guidelines, 7.2.3 for an explanation of the extended linking and elements <refloc> and <ptrloc>. Remember to check the EAD 2002 Tag Library for new elements <arc> and <resource>, and for current values of attributes for linking elements.

Repeatable:

n/a

Order:

n/a

Revision Date:

11/03/03

External Linking

Table of Contents Number:

2.2.2

EAD Guideline:

7.3 (Ver. 1.0)

Tag:

n/a

Description:

External linking refers to links from a finding aid to another electronic resource, which may be another encoded finding aid, a digital archival object (<dao>), an external image or file not from the archival collection (e.g., the LC seal or an illustration), or a web page. Extensive information about linking can be found in Chapter 7 of the EAD Application Guidelines.

LC practice requires the use of the HREF, ACTUATE, and SHOW attributes with external linking elements.

New in EAD 2002: linking elements <arc> and <resource> have been added. Values for the ACTUATE attribute have changed.

See also:

Section 2.1.2, Paragraph (use of linking elements within)

See also:

Section 2.2.1, Internal Linking

See also:

Section 3.1.2, File Description (<extptr> to LC seal)

See also:

Section 3.3.1.11, Digital Archival Object Group

See also:

Section 3.3.3.8, Alternate Form of the Materials Available (examples of <extref> to URLs, discussion of <daogrp>)

See also:

Section 3.3.7.4, Expanded Description of Components (<daogrp> at component level)

See also:

Section 3.3.8.1, Bibliographies (<bibref> and <archref> as linking elements)

See also:

Section 3.3.8.5, Related Material (<bibref> and <archref> as linking elements)

See also:

Section 3.3.8.6, Separated Material (<bibref> and <archref> as linking elements)

Labels/Heads:

n/a

Encoding Analog:

n/a

Other Attributes:

Simple linking:

• href (target of link) Required
• actuate="onrequest" (means user needs to click on link for target to be displayed) or "onload" (means target displayed automatically, e.g., LC seal) Required
• show="new" (target resource displayed in a new browser window) or "embed" (target resource displayed at point of link) Required

See Tag Library for full list of attributes and their values.

Extended linking (<daoloc>):

• href (target of link) Required
• role (MIME type of target)

See Tag Library for full list of valid attributes and their values for this and for other extended linking elements.

Subelements:

Simple linking:

• use <extptr> for the LC seal (in <eadheader>) or any illustrative matter which should be displayed inline and is not from the collection described
• use <extref> for external links such as to a Library web page
• use <archref> to link to other archival collections. For instance, this may be another finding aid (preferably EAD), or to a web page, database, or catalog record for the archival collection.
• use <bibref> to link from a bibliographic citation to an online version of the work
• use <title> to link to a title to an online version of the work

Extended linking:

• use <arc> to specify rules for traversal among resources in an extended link
• use <daoloc> for an object within <daogrp>. <daogrp> is used as a wrapper for one or more archival objects.
• rather than using <dao> for a single archival object, use <daoloc> within <daogrp> instead. This is a change in LC Practice recommended by the RLG Best Practice Guidelines.
• use <extrefloc> for external reference extended references
• use <extptrloc> for external pointer extended references
• use <resource> to specify local resources participating in an extended link

Tagging Example 1a.

XML prolog with entity declarations, linking elements for Hannah Arendt Papers

Tagging Example 1b.

<daoloc> has href value as an entity declared in prolog for Arendt

Display of Tagging Example 1b.

<daoloc> link goes to American memory presentation of series contents

Tagging Example 2a.

XML prolog with entity declarations and link to external 'bell.ent' entity file for Bell papers

Tagging Example 2b.

Partial content of external 'bell.ent' entity file; handle registered for each entity

Tagging Example 2c.

Shows <daoloc> with href value an entity declared in external entity file for Bell

Display of Tagging Example 2c.

<daoloc> link resolves via handle server to search results linking to contents of partially digitized folder

Comments:

EAD linking elements

• Use the HREF attribute to set the target of the link from each linking element.
• Declare and use an entity for each link target rather than just embedding the URL in the HREF attribute of the linking element. For instance, in Example 1a, name the home page for the Hannah Arendt home page in American Memory as "arendthome". In the link from the <daoloc> in Example 1b, the name of the entity is preceded by an ampersand and followed by a semicolon. The entity declaration in the prolog (at the top of the finding aid) in Example 1a contains the information that the entity named "&arendthome;" is found at the URL "http://memory.loc.gov/ammem/arendthtml/".

XML prolog

• All finding aids should have information included in the XML prolog (the portion of the document which precedes the opening <ead> tag) in order to permit external linking. This information is included in the templates, and the full text of the prolog is provided in Examples 1a and 2a.
• The entity declaration, "<!ENTITY lcseal SYSTEM ...> enables linking to the LC seal, which is stored in the ITS file system and is displayed with every LC finding aid. The location of the LC seal has been revised to fit into the new ITS XML file system, and the seal has been transformed into JPEG format. This is a change in LC practice.
• If links are made to nine or fewer external entities, include the entity declarations in the document prolog. If there are ten or more entities, they will comprise a separate file to be stored in the same directory as the finding aid and its helper files, named with a .ent extension. See the EAD Technical Web page for further information on file structure and helper files.

Handles and external entities:

• If the target of a link is another EAD finding aid, a handle will be registered for the finding aid as part of standard procedures. See the EAD Technical Web page for an example of batch handle files for finding aids.
• If the target of a link is a stable web page, the entity declaration will include its URL, and there is no need to register a handle.
• If the target of a link is not a stable URL, for instance the response to a cgi-bin query, consider registering a handle. In Example 2b, handles should be registered for each entity, which would resolve to a URL that sends a search to InQuery, e.g., "http://lcweb2.loc.gov/cgi-bin/query/S?ammem/magbell:@field(DOCID+@range (magbell37500200+magbell37500299))".

Conversion from SGML to XML:

• In converting existing SGML finding aids to XML, processing instructions such as <?ATTLINK EXTPTR HREF URI> which were present in the SGML finding aids to enable external linking in the Panorama application have been converted to XML format in those finding aids, e.g. <?ATTLINK EXTPTR HREF URI?>. These instructions may be retained in a converted XML document; however, they should not be added to newly encoded finding aids.
• In the process of document conversion, the values of the declared entities are extracted from the declarations and appear as the value of the HREF attribute, and the entity declaration is no longer present (i.e., HREF="&arendthome;" will be changed to HREF="http://memory.loc.gov/ammem/arendthtml/".) This result for converted finding aids is acceptable, but newly encoded finding aids should continue to implement the practice described above concerning use of external entities.

Repeatable:

n/a

Order:

n/a

Revision Date:

05/27/04

EAD Header

Table of Contents Number:

3.1

EAD Guideline:

3.6.1 (Ver. 1.0)

Tag:

<eadheader>

Description:

The <eadheader> comprises a set of metadata about the finding aid that serves to identify each EAD instance, and is based on the TEI header.

LC Practice requires the inclusion of <eadheader> and its subelements; <eadheader> and two of its subelements, <eadid> and <filedesc>, are required by the EAD DTD. Consistent formulation of its information is essential.

New in EAD 2002: required attributes LANGENCODING, SCRIPTENCODING, REPOSITORYENCODING, COUNTRYENCODING, and DATEENCODING.

See also:

Section 3.2, Title Page and Prefatory Matter

Labels/Heads:

n/a

Encoding Analog:

n/a

Other Attributes:

• relatedencoding="MARC21" Required
• langencoding="iso639-2b" Required
• scriptencoding="iso15924" Required
• repositoryencoding="iso15511" Required
• countryencoding="iso3611-1" Required
• dateencoding="iso8601" Required

See Tag Library for full list of attributes and their values.

Subelements:

Listed in order required by DTD. Required elements must be included to conform with LC practice.

• <eadid> Required by DTD See 3.1.1, Unique File Identifier
• <filedesc> Required by DTD See 3.1.2, File Description
• <profiledesc> Required See 3.1.3, Profile Description
• <revisiondesc> Required if applicable See 3.1.4, Revision Description

Tagging Example 1.

Fully encoded <eadheader> element

Display of Tagging Example 1.

If header used to generate display, header should not be set to audience='internal'

Note: display of series statement and language code suppressed

Comments:

• The predominant practice for finding aids at the Library of Congress has used data from the <eadheader> to generate a title-page display, although some divisions have encoded a separate <titlepage> element in <frontmatter> in order to present elements in an order not permitted by the DTD. Future LC finding aids should discontinue use of <titlepage>. At present, LC HTML displays are generated from the <eadheader> rather than the <titlepage>, and title page formatting will not display to most users. When XSLT stylesheets are implemented, it will be easy to reorder the display of elements and to insert textual formatting that need not be included in <eadheader>; but at present, continue to include the LC seal within the <publisher> element in <eadheader>.
• Set the RELATEDENCODING analog both at the <eadheader> and <archdesc> levels, since different encoding schemes may be used for the two major sections in future. Past practice has been to set RELATEDENCODING at the parent <ead> element alone. This is a change in LC practice.

Repeatable:

no

Order:

first element within <ead>

Revision Date:

05/26/04

Unique File Identifier

Table of Contents Number:

3.1.1

EAD Guideline:

3.6.1.1 (Ver. 1.0)

Tag:

<eadid>

Description:

The <eadid> is an element required by the DTD that includes a unique alphanumeric identifier for each separate EAD finding aid. The <eadid> for a finding aid remains constant no matter how many times the finding aid may be revised or expanded.

LC Practice requires the <eadid>, which should be formulated according to the scheme described below.

New in EAD 2002: attributes COUNTRYCODE, IDENTIFIER, MAINAGENCYCODE, and others (attributes SYSTEMID, SOURCE, and TYPE are no longer valid).

See also:

n/a

Labels/Heads:

n/a

Encoding Analog:

856$u

Other Attributes:

• countrycode="us" Required
• mainagencycode="dlc" Required
• identifier=LC handle preceded by "hdl:" (do not include the LC handle proxy server address "http://hdl.loc.gov") Required

Tagging Example 1.

<eadid> for the fourth Manuscript Division finding aid created in 2001

Display of Tagging Example 1.

<eadid> for the fourth Manuscript Division finding aid created in 2001

Note: display of <eadid> is usually suppressed in HTML and XML versions

Comments:

Assumptions:

• The <eadid> identifies the "work" (i.e., the intellectual content), whether fixed or dynamic in nature. Finding aids are by nature dynamic works; they can reflect additions to collections they describe, increased granularity of descriptions (especially with digital collections), and for encoded finding aids, increased levels of tagging.
• A new <eadid> is assigned only for a new work, not simply when the finding aid is updated.
• The <eadid> is a published identifier; it is not functionally similar to a PIN.
• Even if only part of a collection is initially processed and described, the EAD finding aid reflects the complete collection (in the header, scope and contents, etc.). The finding aid content should skeletally describe the complete collection and more completely describe the part of the collection being worked on. This should allow the finding aid to be expanded without requiring the <eadid> to change.
• If a finding aid is subdivided into physical parts, a unique <eadid> will not be assigned to each separate physical part (this whole/part information will be incorporated into "structural metadata" associated with EADs stored in a repository)

EAD ID structure:

• The Library of Congress bases its <eadid> practice on the persistent identifier naming scheme used for LC handles. The <eadid> is used by LC divisions when they register handles for finding aids.
• An LC <eadid> consists of two parts: the naming authority and the finding aid item identifier.
• The naming authority identifies the LC division maintaining the finding aid (which may or may not be the LC division which created the finding aid). Because an LC <eadid> is also a persistent identifier, the naming authority is assigned at the time the <eadid> is created -- and will not change if the maintaining division changes its name. The naming authority is unique within LC. (Example: loc.pnp.eadpnp or loc.mss)
• The finding aid item identifier is a two-part name. The first part is a stable "aggregate" name beginning with "ead." Each LC division uses the same aggregate name for all finding aids it maintains. (Example: eadrbc or eadmbrs). The second part is an eight-character number assigned by the maintaining division. This number is structured as follows: the first two characters (lower case) identify the maintaining division, the next three digits identify an abbreviated date of creation for the finding aid, and the last three digits are a one-up ID number assigned to finding aids created within that year (Example: ms001004 is the fourth finding aid created by the Manuscript Division in 2001).

• The content of the <eadid> contains an LC handle resolved through LC’s handle proxy server (http://hdl.loc.gov). The actual LC handle is recorded in the <eadid> IDENTIFIER attribute.
• Set the <eadid> IDENTIFIER attribute to the LC handle (Example: "hdl:loc.afc/eadafc.af999001"). RLG Best Practice Guidelines state that <eadid> should include at least one of the following attributes: PUBLICID, IDENTIFIER, or URL. URN has been added as an option in EAD 2002. However, because handles are not yet valid type of URN, LC believes that IDENTIFIER is the attribute best suitable for handles. ("URI" is not a valid attribute in EAD 2002).
• Set the content of the <eadid> to the URL for the LC handle resolved through LC’s handle proxy server (Example: http://hdl.loc.gov/loc.afc/eadafc.af999001)
• Examples of <eadid> content are:
• AFC: http://lcweb.loc.gov/hdl/afc/eadafc.af999001
• G&M: http://lcweb.loc.gov/hdl/gmd/eadgmd.gm001001
• MBRS/RS: http://lcweb.loc.gov/hdl/mbrsrs/eadmbrsrs.rs000001
• MSS: http://lcweb.loc.gov/hdl/mss/eadmss.ms001028
• MUSIC: http://lcweb.loc.gov/hdl/music/eadmusic.mu999001
• P&P: http://lcweb.loc.gov/hdl/pnp/eadpnp.pp996001
• RBC: http://lcweb.loc.gov/hdl/rbc/eadrbc.rb998001
• Other institutions and consortia assign <eadid> values using a variety of schemes. Many use the <eadid> PUBLICID attribute. EAD 2002 permits use of multiple types of identifiers; see Tag Library, <eadid>, for an example setting both PUBLICID and URL attributes.

Repeatable:

no

Order:

first element within <ead>

Revision Date:

05/18/04

File Description

Table of Contents Number:

3.1.2

EAD Guideline:

3.6.1.2 (Ver. 1.0)

Tag:

<filedesc>

Description:

Bibliographic information about the intellectual content of the encoded finding aid is bundled in the required element <filedesc>, in which elements such as the finding aid's title, subtitle, author, and publisher are encoded in a series of subelements.

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

See also:

n/a

Labels/Heads:

n/a

Encoding Analog:

n/a

Other Attributes:

n/a

Subelements:

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

• <titlestmt> Required by DTD
• <titleproper encodinganalog="245$a"> Required by DTD
• <subtitle>
• <author encodinganalog="245$c"> Recommended

• <editionstmt>
• <edition>

• <publicationstmt> Required
• <publisher encodinganalog="260$b"> Required
• <extptr> Required
• <address> Required
• <date encodinganalog="260$c" normal="(ISO 8601 normalized date)"> Required

• <seriesstmt>
• <titleproper>
• <num>

• <notestmt>
• <note>

Tagging Example 1.

File description including series statement

Display of Tagging Example 1.

Title display generated from file (series statement display suppressed)

Comments:

• Remember that the finding aid title will be different from the name of the collection.
• Each division should follow its own guidelines for the formulation of titles and in deciding whether series titles are to be used (for instance, the Manuscript Division has discontinued use of series titles). Finding aid titles may be formulated without subtitles, as is done by Music Division and American Folklife Division.
• Date normalization will follow ISO standard 8601. Follow this normalization standard also for <unitdate> elements normalized in the <did> and component levels.

Repeatable:

no

Order:

first element within <ead> following <eadid>

Revision Date:

05/09/03

Profile Description

Table of Contents Number:

3.1.3

EAD Guideline:

3.6.1.3 (Ver. 1.0)

Tag:

<profiledesc>

Description:

The <profiledesc> element bundles information about the creation of the encoded finding aid.

LC Practices requires the inclusion of <profiledesc>, as it establishes initial version control for the finding aid.

New in EAD 2002: attribute LANGCODE in <language>.

See also:

n/a

Labels/Heads:

n/a

Encoding Analog:

n/a

Other Attributes:

n/a

Subelements:

• <creation> Required
• <date> (set normal attribute) Required

• <langusage encodinganalog="546"> Required
• <language langcode="eng" encodinganalog="041"> Required

Set the SCRIPTCODE attribute for <language> using ISO 15924 only if nonroman script needs to be noted.

Tagging Example 1.

Creation description explicitly naming encoder/s; multiple languages in finding aid

Display of Tagging Example 1.

Title display generated from creation description (language statement display suppressed)

Tagging Example 2.

Finding aid initially encoded by vendor

Display of Tagging Example 2.

Finding aid initially encoded by vendor (language statement display suppressed)

Comments:

• Each division should follow its own guidelines on giving names of encoders. It will be useful to record conversions performed in whole or part by outside agencies.
• Use natural language for a statement of the language or languages in which the finding aid is written; use the LANGCODE attribute with value taken from ISO 639-2 for the language code in <language>, which will normally be "eng".
• Use the ENCODINGANALOG attribute "546" for <langusage> and "041" for <language>; the latter maps most precisely to the LANGCODE attribute on <language>. Note that this differs from the current version of RLG Best Practice Guidelines for Encoded Archival Description, which sets "546" as ENCODINGANALOG for <langusage>.

Repeatable:

no

Order:

follows <filedesc> and precedes <revisiondesc>

Revision Date:

6/6/03

Revision Description

Table of Contents Number:

3.1.4

EAD Guideline:

3.6.1.4 (Ver. 1.0)

Tag:

<revisiondesc>

Description:

The <revisiondesc> element contains information about substantial changes that have been made to the encoded finding aid.

LC Practice requires the inclusion of <revisiondesc> when applicable.

See also:

n/a

Labels/Heads:

n/a

Encoding Analog:

n/a

Other Attributes:

n/a

Subelements:

• <change encodinganalog="583">
• <date> (set normal attribute)
• <item>

Tagging Example 1.

Finding aid revised and expanded (first revision of encoded finding aid)

Display of Tagging Example 1.

Finding aid revised and expanded (first revision of encoded finding aid)

Tagging Example 2.

Multiple revisions in reverse chronological order

Display of Tagging Example 2.

Multiple revisions in reverse chronological order

Comments:

• Remember that revisions to finding aids that take place before first conversion to EAD are listed in <filedesc><authorstmt> and <processinfo> rather than in the <eadheader>.
• There is no need to record minor changes or corrections in <revisiondesc>. File dates (in the short term) and repository management software (in the long run) will be used to track such changes.
• 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>. See Example 1.
• Give year and month, or year, month, and date for each change; list the date before the change. List changes in reverse chronological order. See Example 2.
• When finding aids are converted from version 1.0 to EAD 2002, the <change> element will automatically be added to an existing <revisiondesc> (see Example 2) or as a new <revisiondesc> for a finding aid which has not previously been revised.

Repeatable:

yes

Order:

follows <profiledesc>

Revision Date:

5/24/04

Title Page and Prefatory Matter

Table of Contents Number:

3.2

EAD Guideline:

3.6.2 (Ver. 1.0)

Tag:

<frontmatter>

Description:

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. The <div> element is a generic textual element that can be used to encode a forward, acknowledgements, introduction, or other prefatory material which does not pertain to the content of the specific finding aid or collection.

LC Practice discourages use of <titlepage> in favor of generating title page displays from the EAD header. A <div> may be used for common generic information, but such data which may pertain to repository policies, access, and reproduction is usually available on the division's Web site and may be linked to from the appropriate part of the finding aid instead.

See also:

Section 3.1, EAD Header

Labels/Heads:

n/a

Encoding Analog:

n/a

Other Attributes:

n/a

Subelements:

• <titlepage>
• <div>

Tagging Example 1.

Generic introduction to finding aids and contact information using external entity

Note: the full text of "contactinfo.sgm", commented out here, is stored externally to the finding aid

Display of Tagging Example 1.

Generic introduction and contact information using external entity

Tagging Example 2.

Contact information within <div> (no entity used)

Display of Tagging Example 2.

Contact information within <div> (no entity used)

Comments:

• Title page displays at the Library of Congress are generated using <eadheader>. When XSLT stylesheets are implemented, it will be easy to reorder the display of elements and to insert textual formatting that need not be included in <eadheader>, such as line breaks and external pointers to display the institutional seal.
• The use of <div> as generic text, illustrated above, is not recommended for online finding aids. If such data must be included, care should be taken to distinguish generic introductory text from that belonging in more specific elements such as <userestrict> or <prefercite>.
• A special situation may exist for brief contact information that would be helpful in a copy of the finding aid printed from the Web. On the other hand, this additional information is repetitive from finding aid to finding aid, and occupies screen real estate which may be at a premium when frames are used for display.
• If contact information is desired in the <frontmatter><div>, it may be generated by means of an external entity, as illustrated in Example 1, or keyed directly into the <div>, as in Example 2. External entities are a more efficient way of storing the information, so that it need only be updated in one location. However, use of external entities is problematic in XML. In any case, however, entities should be resolved before finding aids are exported to an outside system.

Repeatable:

no

Order:

following <eadheader> and before <archdesc>

Revision Date:

2/5/03

Collection-Level Information (Archival Description)

Table of Contents Number:

3.3

EAD Guideline:

3.5.1 (Ver. 1.0)

Tag:

<archdesc>

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> has been replaced by the subelement <langmaterial>.
• New subelements <originalsloc> and <phystech> are described in the Tag Library and may be used where appropriate.
• Elements formerly subordinate to <admininfo> and <add> are now available as separate elements under <archdesc> as well as within <descgrp>, as described below.

See also:

Section 3.3.1.6, Language of the Material

See also:

Section 3.3.1.11, Digital Archival Object Group

See also:

Section 3.3.9, Other Descriptive Data

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
• 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.3.1, Basic Description: The High-level <did>
• <controlaccess> Recommended See 3.3.2, Controlled Vocabulary Terms
• <descgrp type="admininfo"> Required See 3.3.3, Administrative Information
• <bioghist> Recommended See 3.3.4, Biographical Sketches and Agency Histories
• <scopecontent> Required See 3.3.5, Scope and Content Note
• <arrangement> Recommended See 3.3.6, Arrangement
• <dsc> Required See 3.3.7, Description of Subordinate Components
• <descgrp type="add"> See 3.3.8, Adjunct Descriptive Data

See Tag Library for full list of valid subelements.

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 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". 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 formerly 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. This 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> elements 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 Sections 3.3.1.11, Digital Archival Object Group, and 3.3.7.4, Expanded Description of Components for treatment of <daogrp> in these cases.

Repeatable:

no

Order:

follows <eadheader> and optional <frontmatter>

Revision Date:

7/31/03

Basic Description: The High-Level <did>

Table of Contents Number:

3.3.1

EAD Guideline:

3.5.1.1 (Ver. 1.0)

Tag:

<did>

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.

New in EAD 2002: the subelement <langmaterial> has been added within <did>. This element replaces the LANGMATERIAL attribute formerly used with <archdesc>.

See also:

n/a

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.3.1.1, Title of the Unit
• <unitdate> Required See 3.3.1.2, Date of the Unit
• <unitid> Required See 3.3.1.3, ID of the Unit
• <origination> Required See 3.3.1.4, Origination
• <physdesc> Required See 3.3.1.5, Physical Description
• <materialspec> See Tag Library
• <langmaterial> Required See 3.3.1.6, Language of the Material
• <repository> Required See 3.3.1.7, Repository
• <abstract> Required See 3.3.1.8, Abstract
• <note> See 3.3.1.9, Note
• <physloc> See 3.3.1.10, Physical Location
• <daogrp> See 3.3.1.11, 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:

4/15/03

Title of the Unit

Table of Contents Number:

3.3.1.1

EAD Guideline:

3.5.1.2.3 (Ver. 1.0)

Tag:

<unittitle>

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

New in EAD 2002: <bibseries>, <edition>, and <imprint> may be used within <unittitle>.

See also:

Section 3.3.1.2, Date of the Unit

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:

05/13/03

Physical Location

Table of Contents Number:

3.3.1.10

EAD Guideline:

3.5.1.2.8 (Ver. 1.0)

Tag:

<physloc>

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:

n/a

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.3.7.3.6, Physical Location Information, for more information.

Repeatable:

yes

Order:

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

Revision Date:

7/31/03

Digital Archival Object Group

Table of Contents Number:

3.3.1.11

EAD Guideline:

3.5.1.2.9 (Ver. 1.0)

Tag:

<daogrp>

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:

Section 2.2.2, External Linking

See also:

Section 3.3.7.4, Expanded Description of Components

Labels/Heads:

Image Sampler

Encoding Analog:

n/a

Other Attributes:

n/a

Subelements:

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

• <daoloc> (set attribute HREF; fixed attribute LINKTYPE has value "locator")
• <daodesc>
• <p>

See Tag Library for full list of attributes and their values.

Tagging Example 1.

Representative images from NAACP visual materials collection

Display of Tagging Example 1.

Comments:

• Use <daogrp> and its subelement <daoloc> for one or more archival objects. Former LC practice was to use <dao> instead for a single digital archival object. This change conforms to the RLG Best Practice Guidelines.

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

Repeatable:

n/a

Order:

Last element in Collection Summary

Revision Date:

7/30/03

Date of the Unit

Table of Contents Number:

3.3.1.2

EAD Guideline:

3.5.1.2.4 (Ver. 1.0)

Tag:

<unitdate>

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 is used only to distinguish inclusive and bulk dates; the value "single" is no longer valid
• New attributes added: CALENDAR, DATECHAR, ERA

See also:

n/a

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" Required
• normal (normalize according to ISO8601 in yyyy-mm-dd format) Required
• calendar="gregorian" Default value
• era="ce" Default value for common/Christian era
• datechar="creation" Recommended

See Tag Library for full list of valid subelements and their attributes.

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.

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.
• It is not necessary to set attributes CALENDAR and ERA explicitly for <unitdate> elements at the Collection Summary level, as default values arer supplied by the DTD. Set these attributes if their values differ from the defaults of Gregorian calendar and common/Christian era.
• 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.

Repeatable:

yes

Order:

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

Revision Date:

09/30/03

ID of the Unit

Table of Contents Number:

3.3.1.3

EAD Guideline:

3.5.1.2.7 (Ver. 1.0)

Tag:

<unitid>

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:

n/a

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, 590, 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) Required
• repositorycode="DLC" (Source: ISO15511, which accommodates codes used in MARC Code List for Organizations) Required

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

09/17/03

Origination

Table of Contents Number:

3.3.1.4

EAD Guideline:

3.5.1.2.2 (Ver. 1.0)

Tag:

<origination>

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:

Section 3.3.2.1, Use of Attributes in <controlaccess> Subelements

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:

Use of one of the following subelements is required:

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

09/17/03

Physical Description

Table of Contents Number:

3.3.1.5

EAD Guideline:

3.5.1.2.5 (Ver. 1.0)

Tag:

<physdesc>

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:

n/a

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 and their attributes.

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>

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 (Examples 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 (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 <langmaterial> in Collection Summary

Revision Date:

09/30/03

Language of the Material

Table of Contents Number:

3.3.1.6

EAD Guideline:

n/a

Tag:

langmaterial

Description:

Use the <langmaterial> element with its subelement/s <language> to indicate the language or languages of the material represented in the collection.

LC Practice requires the use of <langmaterial> at the <archdesc> level.

This element, new in EAD 2002, states in natural language information formerly recorded in language codes in the LANGMATERIAL attribute to <archdesc>.

See also:

n/a

Labels/Heads:

Choose as appropriate:

• Language:
• Languages:

Encoding Analog:

546

Other Attributes:

n/a

Subelements:

• <language encodinganalog="041" langcode="eng"> (or appropriate language code) Required

Tagging Example 1.

Multiple languages found in papers

Display of Tagging Example 1.

Multiple languages found in papers

Comments:

• Use the ENCODINGANALOG attribute "546" for <langusage> and "041" for <language>; the latter maps most precisely to the LANGCODE attribute on <language>.
• Set the SCRIPTCODE attribute for <language> within <langusage> and <langmaterial> using ISO 15924 only if nonroman script needs to be noted.
• Do not confuse <langmaterial> with <langusage>, the <eadheader> element describing the language of the finding aid.

Repeatable:

no

Order:

After <physdesc> and before <repository>

Revision Date:

05/24/04

Repository

Table of Contents Number:

3.3.1.7

EAD Guideline:

3.5.1.2.1 (Ver. 1.0)

Tag:

<repository>

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 is available for use.

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

See also:

n/a

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 encode as <subarea> the reading room where the material is available. This information is displayed as part of search results, and its correct encoding will facilitate the future ordering of search results by <subarea>. See Examples 1-2 for encoding of <subarea>.
• 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: do not include a comma between elements. Rely on stylesheets instead to needed punctuation and spaces between the elements. See Examples 1-3.
• For a multi-divisional finding aid, use a new repository tag for each section. See Example 3.

Repeatable:

yes

Order:

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

Revision Date:

7/31/03

Abstract

Table of Contents Number:

3.3.1.8

EAD Guideline:

3.5.1.2.6a (Ver. 1.0)

Tag:

<abstract>

Description:

A brief statement about the creator or collector and the scope of the materials.

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

See also:

Section 3.3.1.9, Note

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:

07/11/03

Note

Table of Contents Number:

3.3.1.9

EAD Guideline:

3.5.1.2.6b (Ver. 1.0)

Tag:

<note>

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:

n/a

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

Controlled Vocabulary Terms

Table of Contents Number:

3.3.2

EAD Guideline:

3.5.3 (Ver. 1.0)

Tag:

<controlaccess>

Description:

A wrapper element that groups key access points for the described materials and enables authority-controlled searching across finding aids in a computer network. These elements can be provided in a single list or be grouped into categories as appropriate. Discussion of attributes, groupings, individual <controlaccess> subelements, and the use of these subelements elsewhere within the finding aid will be found in Sections 3.3.2.1-3.3.2.7.

LC Practice recommends inclusion of controlled vocabulary terms to promote resource discovery when searching the finding aid database and in browsing name and subject lists generated from these terms.

See also:

Section 3.3.1.4, Origination

See also:

Section 3.3.1.5, Physical Description

See also:

Section 3.3.4, Biographical Sketches and Agency Histories

See also:

Section 3.3.5, Scope and Content Note

Labels/Heads:

Choose appropriate <head> for overall section, such as:

• Selected Search Terms
• Key Subjects
• Key Subjects and Formats
• Search Terms

Encoding Analog:

n/a

Other Attributes:

n/a

Subelements:

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

• <head> Required
• <note> Recommended
• <persname> See 3.3.2.2, Personal, Corporate, Family, and Geographic Names
• <corpname> See 3.3.2.2, Personal, Corporate, Family, and Geographic Names
• <famname> See 3.3.2.2, Personal, Corporate, Family, and Geographic Names
• <geogname> See 3.3.2.2, Personal, Corporate, Family, and Geographic Names
• <name> See 3.3.2.2, Personal, Corporate, Family, and Geographic Names
• <genreform> See 3.3.2.3, Form and Genre Terms
• <function> See 3.3.2.4, Function and Occupation Terms
• <occupation> See 3.3.2.4, Function and Occupation Terms
• <subject> See 3.3.2.5, Subjects and Titles
• <title> See 3.3.2.5, Subjects and Titles

Tagging Example 1.

Single list of <controlaccess> terms at collection level

Display of Tagging Example 1.

Single list of <controlaccess> terms at collection level

Comments:

• Controlled access terms are an important means of providing uniform searchability of encoded finding aids. At a minimum, the same controlled access terms should be encoded in EAD as in the MARC record for the collection. Failure to include such terms will result in the omission of key names and subjects from browse lists for LC finding aids, and will hinder searching based on the presence of such terms.
• Controlled access terms are most commonly listed at the collection level in a collection-level finding aid. They may also be assigned to their most specific descriptive level, as multilevel description allows. For instance, subject access may be provided at the series level when that topic is represented in only that series. However, the added expenses in identifying these specific headings and maintaining them in multiple locations in a finding aid make this option less attractive than it might be from a purely intellectual standard.
• Consider the order of terms used within a single list or a grouped list. See 3.3.2.6 for discussion of grouped access terms. Terms might be sorted alphabetically, in order by MARC encoding analog and alphabetically therein, or by preponderance within the collection. Listings should not be confusing to researchers in having no apparent order. On the other hand, major manipulation of order given in the MARC catalog record adds to encoding overhead.
• An introductory note explaining the nature and source of the search terms will aid researchers in understanding this potentially confusing list. This note may be put directly within paragraph tags but preferred practice is to encode as a note, for better manipulation of its display. See Example 1.

Repeatable:

yes (and recursive)

Order:

following <did> and preceding <descgrp type="admininfo">

Revision Date:

2/26/03

Use of Attributes in <controlaccess> Subelements

Table of Contents Number:

3.3.2.1

EAD Guideline:

3.5.3.1 (Ver. 1.0)

Tag:

n/a

Description:

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

New in EAD 2002:

• The semiclosed list of thesauri codes used as values for the attribute SOURCE has been eliminated and the OTHERTYPE attribute is no longer valid.
• A RULES attribute has been added to record descriptive rules used to formulate the content of the element.

See also:

Section 3.3.1.4, Origination

Labels/Heads:

n/a

Encoding Analog:

n/a

Other Attributes:

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

See Tag Library for full list of attributes and their values.

Subelements:

n/a

Tagging Example 1.

Attributes used are SOURCE, ENCODINGANALOG, ROLE, and RULES

Display of Tagging Example 1.

Attributes used are SOURCE, ENCODINGANALOG, ROLE, and RULES

Comments:

• As the purpose of <controlaccess> is to enable searching by terms used nationally and internationally, make every effort to use controlled vocabulary as index terms.
• In most cases, the value of the SOURCE attribute will come from the standard authority sources listed above. If subject terms must be used which are not found in these sources, set the SOURCE attribute to name the other thesaurus, which may be locally maintained. Please report such values to the EAD Technical Group to be added to LC templates and other local tools.
• If subject terms must be used which are not found in any extant thesaurus, set the value on the SOURCE attribute as "local."
• The ROLE attribute may be set to indicate relationships expressed in relator terms (e.g., collector, contributor) as well as that a name is functioning as a subject. See Section 3.3.1.4 for discussion of using the ROLE attribute in for creators and collectors in <origination> in conjunction with or in place of recording the relator terms as PCDATA.
• The RULES attribute (new in EAD 2002) can be used to specify the descriptive rules followed when formulating the term, such as "aacr2" or "rad". This attribute is optional and should be used only when the term is not already found in a standard authority list or thesaurus identified with the SOURCE attribute, such as a term formulated following the provisions of AACR2 but not found in the LCNAF.
• Note: since the RELATEDENCODING attribute has already been set to "MARC21" at the <archdesc> level, it is not necessary to include "MARC21" as part of the ENCODINGANALOG attribute.

Repeatable:

n/a

Order:

n/a

Revision Date:

1/03/03

Personal, Corporate, Family, and Geographic Names

Table of Contents Number:

3.3.2.2

EAD Guideline:

3.5.3.2 (Ver. 1.0)

Tag:

<persname>

Tag:

<corpname>

Tag:

<famname>

Tag:

<geogname>

Tag:

<name>

Description:

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

See also:

Section 3.3.2.1, Use of Attributes in <controlaccess> Subelements

Labels/Heads:

n/a

Encoding Analog:

100, 600, or 700 with <persname> or <famname> (main, subject, or added entry); 110, 610, or 710 with <corpname> (main, subject, or added entry); 611 with <corpname> (conference or meeting subject entry); 651 with <geogname>

Other Attributes:

• source="lcnaf" (in most cases) Required
• role="subject" (if 6xx field) Recommended
• role="creator" or "collector" (if originator) Recommended
• rules

See Tag Library for full list of attributes and their values.

Subelements:

n/a

Tagging Example 1.

Attributes used are SOURCE, ENCODINGANALOG, and ROLE

Display of Tagging Example 1.

Attributes used are SOURCE, ENCODINGANALOG, and ROLE

Tagging Example 2.

Corporate names with subdivisions encoded using <subarea>

Display of Tagging Example 2.

Corporate names with subdivisions encoded using <subarea>

Comments:

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

Repeatable:

yes

Order:

within <controlaccess>

Revision Date:

3/5/03

Form and Genre Terms

Table of Contents Number:

3.3.2.3

EAD Guideline:

3.5.3.3 (Ver. 1.0)

Tag:

<genreform>

Description:

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

See also:

Section 3.3.2.1, Use of Attributes in <controlaccess> Subelements

Labels/Heads:

n/a

Encoding Analog:

655

Other Attributes:

source="aat", "gmgpc", "lcsh", or other as appropriate Required

See Tag Library for full list of attributes and their values.

Subelements:

n/a

Tagging Example 1.

Genre terms taken from Thesaurus for Graphic Materials II

Display of Tagging Example 1.

Genre terms taken from Thesaurus for Graphic Materials II

Comments:

n/a

Repeatable:

yes

Order:

within <controlaccess>

Revision Date:

09/17/03

Function and Occupation Terms

Table of Contents Number:

3.3.2.4

EAD Guideline:

3.5.3.4 (Ver. 1.0)

Tag:

<function>

Tag:

<occupation>

Description:

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

See also:

Section 3.3.2.1, Use of Attributes in <controlaccess> Subelements

Labels/Heads:

n/a

Encoding Analog:

656 for <occupation>; 657 for <function>

Other Attributes:

• source="lcsh", "itoamc" (an occupation thesaurus locally maintained by the Manuscript Division), or other as appropriate Required
• rules

See Tag Library for full list of attributes and their values.

Subelements:

n/a

Tagging Example 1.

Occupations of originator listed using local Manuscript Division thesaurus

Display of Tagging Example 1.

Comments:

n/a

Repeatable:

yes

Order:

within <controlaccess>

Revision Date:

7/11/03

Subjects and Titles

Table of Contents Number:

3.3.2.5

EAD Guideline:

3.5.3.5 (Ver. 1.0)

Tag:

<subject>

Tag:

<title>

Description:

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

See also:

Section 3.3.2.1, Use of Attributes in <controlaccess> Subelements

See also:

Section 3.3.2.2, Personal, Corporate, Family and Geographic Names

Labels/Heads:

n/a

Encoding Analog:

630 with <title>; 650 with <subject>

Other Attributes:

• source="lcsh", "lctgm", "gmgpc", "lcnaf" for <subject> Required
• source="lcnaf" for <title> or other as appropriate Required
• rules

See Tag Library for full list of attributes and their values.

Subelements:

n/a

Tagging Example 1.

Attributes used are SOURCE and ENCODINGANALOG

Display of Tagging Example 1.

Attributes used are SOURCE and ENCODINGANALOG

Comments:

n/a

Repeatable:

yes

Order:

within <controlaccess>

Revision Date:

7/31/03

Use of Grouped Controlled Vocabulary Terms

Table of Contents Number:

3.3.2.6

EAD Guideline:

3.5.3.6 (Ver. 1.0)

Tag:

n/a

Description:

Controlled vocabulary terms may be given in a single list of terms, or may be grouped according to the needs of the collection and the needs of the division by means of nesting <controlaccess> clusters within a single <controlaccess>. Each division may choose a usual pattern of grouping, or may modify the groups at need for each finding aid. Explanatory notes may be attached to each grouping to explain its contents and purpose.

See also:

Section 3.3.2.1, Use of Attributes in <controlaccess> Subelements

Labels/Heads:

Use the <head> elements appropriate to each grouping under the parent <controlaccess> which has its own head, (e.g., "Selected Search Terms"). The two examples below illustrate how headings may be used with particular groupings.

Example 1:

• Names (100, 600, 610, 611, 700, 710, 711)
• Subjects (630, 650, 651, 655)
• Occupations (656)

Example 2:

• Personal Names (100, 600)
• Organizations (110, 111, 610, 611)
• Subjects (650)
• Locations (651)
• Related Names (7xx)
• Genres (655)
• Occupations (656)

Encoding Analog:

n/a

Other Attributes:

n/a

Subelements:

n/a

Tagging Example 1.

Controlled access terms alphabetically listed as names, subjects, and occupations

Display of Tagging Example 1.

Controlled access terms alphabetically listed as names, subjects, and occupations

Tagging Example 2.

Controlled access terms alphabetically listed in numerous groups

Display of Tagging Example 2.

Controlled access terms alphabetically listed in numerous groups

Comments:

• When grouping access terms, consider whether a smaller or larger group is most appropriate. For instance, one may use a small number of groups where access terms are not numerous or are of relatively few types. See Example 1.
• If the list is longer and more complex, and if considerable work might be needed to move terms into an understandable order within a few groups, consider using more groups. See Example 2.
• The examples of groupings given are illustrative rather than prescriptive and care should be taken in determining divisional practice for such groupings.
• Consider the order of terms within each group. They might be sorted alphabetically by term, in order by MARC encoding analog and alphabetically therein, or by preponderance within the collection. Listings should not be confusing to researchers in having no apparent order. On the other hand, major manipulation of order given in the MARC catalog record adds to encoding overhead.
• An introductory note explaining the nature and source of the search terms will aid researchers in understanding this potentially confusing list. This note may be put directly within paragraph tags, but the preferred practice is to encode as a note, for better manipulation of its display. See Example 1 and Example 2. There might be one note at the beginning of the section, and a note about the contents of each group within that group, if desired.

Repeatable:

yes

Order:

n/a

Revision Date:

2/26/03

Use of Controlled Vocabulary Outside of <controlaccess>

Table of Contents Number:

3.3.2.7

EAD Guideline:

3.5.3.7 (Ver. 1.0)

Tag:

n/a

Description:

It is possible to encode names and subjects (i.e, <persname>, <geogname>, <subject>) in context in portions of the finding aid beyond the special <controlaccess> section provided for their use.

LC Practice recommends that key access terms need not be encoded as such outside the <controlaccess> section; see comments below. Exceptions are to encode repository as <corpname> and originator as <persname>, <famname> or <corpname> in Collection Summary.

See also:

Section 3.3.8.3, Indexes

Labels/Heads:

n/a

Encoding Analog:

n/a

Other Attributes:

n/a

Subelements:

n/a

Tagging Example 1.

ROLE attributes given for <geogname> exported from a database to the Container List

Display of Tagging Example 1.

ROLE attributes given for <geogname> exported from a database to the Container List

Comments:

• If names and subjects are already identified as such in the source data (e.g., a database with fielded data easily mapped to <persname>, <corpname>, or <geogname>), this data may be exported using the appropriate tags. In these cases, access terms are tagged and NORMAL attributes are supplied, if needed. No other attributes need be given in circumstances where it is easy to identify names as such but harder to provide authorized forms. Example 1 illustrates a container list of material organized geographically which has been exported from a database; other databases may contain personal names and corporate names as fielded data.
• Names may also be encoded in indexes when circumstances warrant. See Section 3.3.8.3.
• Most but not all significant names and subjects should already be included in the catalog record and encoded in <controlaccess>. If desired, additional names and subjects can be added to <controlaccess> in their authorized forms with SOURCE and ENCODINGANALOG attributes set. Remember that current browse lists are one form of output of <controlaccess>; in a print version, indexes might be generated from the normalized tagged data.
• Past practice in some divisions at the Library has been to tag access terms in front portions of the finding aid in natural language and direct order without normalizing. This practice is discontinued as there is no community consensus on the usefulness of this kind of encoding. Library of Congress searching does not put these additional terms in name or subject browse lists or handle these terms separately from keyword searching.

Repeatable:

n/a

Order:

n/a

Revision Date:

7/11/03

Administrative Information

Table of Contents Number:

3.3.3

EAD Guideline:

3.5.1.4 (Ver. 1.0)

Tag:

<descgrp type="admininfo">

Description:

This wrapper element, new in EAD 2002, 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 within the generic grouping element <descgrp type="admininfo"> bundle in LC finding aids. Although EAD 2002 makes these elements available directly within <archdesc>, we have found it useful to hold this key information together in a labelled section of the finding aid.

New in EAD 2002: the <admininfo> tag, formerly used to bundle administrative information subelements, is deprecated. These subelements are available directly within <archdesc> as well as within components. The new elements <originalsloc> and <phystech> may be grouped within this <descgrp> as well as used within components.

See also:

See also 3.3.7.4, Expanded Description of Components

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.3.3.1, Acquisition Information
• <custodhist> Recommended if applicable See 3.3.3.2, Custodial History
• <accruals> See 3.3.3.3, Accruals
• <processinfo> See 3.3.3.4, Processing Information
• <appraisal> See 3.3.3.5, Appraisal
• <userestrict> Required if applicable/Recommended See 3.3.3.6, Conditions Governing Use
• <accessrestrict> Required if applicable/Recommended See 3.3.3.7, Conditions Governing Access
• <phystech> See Tag Library
• <altformavail> Required if applicable See 3.3.3.8, Alternate Form of the Materials Available
• <originalsloc> See Tag Library
• <prefercite> Recommended See 3.3.3.9, Preferred Citation of the Material

Tagging Example 1.

Heads provided for subelements

Display of Tagging Example 1.

Heads provided for subelements; colons following heads supplied by stylesheet

Comments:

• Administrative information elements, normally enclosed within the <descgrp> wrapper, may also be tagged separately. 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 entered directly or included in a <descgrp> wrapper which includes any elements except those subordinate to <dsc> or <did>.
• Similarly, other elements such as those formerly subordinate to <add> may be included in the <descgrp> wrapper used for administrative information. For example, <separatedmaterial> describing transfers to other Library divisions could be included in this wrapper.
• Administrative elements may be repeated to provide appropriate heads for each paragraph, such as a copyright statement and other restrictions on use. It is recommended but not required that these elements occur sequentially. See Example 1.
• 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.3.7.4, Expanded Description of Components.

Repeatable:

yes (and recursive)

Order:

following <did> and preceding <bioghist>

Revision Date:

9/30/03

Acquisition Information

Table of Contents Number:

3.3.3.1

EAD Guideline:

3.5.1.4.1a (Ver. 1.0)

Tag:

<acqinfo>

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 within <descgrp type="admininfo">.

See also:

n/a

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 <descgrp type="admininfo">

Revision Date:

03/05/03

Custodial History

Table of Contents Number:

3.3.3.2

EAD Guideline:

3.5.1.4.1b (Ver. 1.0)

Tag:

<custodhist>

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 within <descgrp type="admininfo">.

See also:

n/a

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:

3/5/03

Accruals

Table of Contents Number:

3.3.3.3

EAD Guideline:

3.5.1.4.5a (Ver. 1.0)

Tag:

<accruals>

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.

LC practice requires that if this element is used, it should be bundled within <descgrp type="admininfo">.

See also:

n/a

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:

3/05/03

Processing Information

Table of Contents Number:

3.3.3.4

EAD Guideline:

3.5.1.4.6 (Ver. 1.0)

Tag:

<processinfo>

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

LC Practice requires that if this element is used, it should be bundled within <descgrp type="admininfo">.

See also:

3.3.3.8, Alternate Form of the Materials Available

See also:

3.3.8.6, Separated Materials

Labels/Heads:

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

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

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

Display of Tagging Example 2.

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

Tagging Example 3.

Identifies conversion of sound recordings unavailable for public use

Display of Tagging Example 3.

Identifies conversion of sound recordings unavailable for public use

Tagging Example 4.

Notes reformatting of electronic data via WordPerfect to paper form

Display of Tagging Example 4.

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.
• 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 2.
• In the past, <processinfo> was used to describe the transfer of material to other Library divisions. New LC practice is to encode such information as <separatedmaterial>; a brief listing may still be included in the administrative <descgrp> (see Section 3.3.3, Administrative Information, Example 1) while a detailed listing of transferred material might be listed elsewhere with other adjunct information (see Section 3.3.8.6, Separated Material, 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 3 and Example 4. 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:

7/15/03

Appraisal

Table of Contents Number:

3.3.3.5

EAD Guideline:

3.5.1.4.5b (Ver. 1.0)

Tag:

<appraisal>

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.

LC Practice requires that if this element is used, it should be bundled within <descgrp type="admininfo">.

See also:

n/a

Labels/Heads:

Recommended content of required <head>:

• Appraisal
• Retention Criteria

Encoding Analog:

583$a

Other Attributes:

n/a

Subelements: