Table of Contents
"Tag" refers to the XML markers (i.e., <...> and </...>) that enclose an element's data value.
"Element" refers to individual EAD datum, represented in mark-up by a start-tag <...> and end-tag </...>.
"Attribute" refers to named properties of an element that may have different values; attributes qualify elements. The OAC BPG EAD use small capital letters (e.g., LEVEL) for attribute names to distinguish them from element names.
"Data value" refers to the data content encoded within elements or attributes.
"Status" indicates whether an element is required or not. The following codes are used to represent element statuses:
Table 3.1.
| R | "Required." This EAD tag is required at this level. |
| M | "Mandatory if applicable." This EAD tag is required when the information is available at this level. |
| P | "Preferred." This EAD tag is optional at this level, but strongly recommended in order to facilitate user access to your collection. |
Use of all other EAD tags discussed is completely optional as allowed by the EAD TL. The statement "Use one ..." in the guidelines tables in Chapter 4 indicates that only one instance of that element should be used, not two or more.
The EAD DTD requires that certain elements be encoded in a particular sequence. Additionally, the OAC BPG EAD present EAD elements in a suggested sequence for finding aids submitted to the OAC. The OAC suggestion is not prescriptive, however, and another sequence can be used if desirable, providing it adheres at least to the sequence requirements of the EAD DTD.
Elements may be used recursively as allowed by the EAD TL.
While most elements may be repeated per the EAD DTD, certain elements may not be encoded more than once. The OAC BPG EAD also place further constraints on repeatability beyond the DTD for local processing purposes. The repeatability status of these particular elements is presented in a separate column in the guideline tables in Chapter 4. As with the order of elements, the constraints the OAC places on repeatability are not prescriptive.
The following codes are used to represent element repeatability status.
Institutions should ensure that all encoding conforms to XML encoding specifications. For general information on XML, see the World Wide Web Consortium (W3C) Website. For information about EAD in XML, see the EAD AG and EAD in XML by David Ruddy.
All <unitdate> Date elements above the <dsc> Description of Subordinate Components element must contain a NORMAL attribute for encoding normalized dates. Dates must be normalized according to the International Standard Organization (ISO) 8601 standard, using the following modified version of the W3C date and time formats profile.
Examples:
Date spans
<unitdate normal="1956-01/1956-07">Jan 1956 - July 1956</unitdate> [use ISO 8601 date intervals]
<unitdate type="bulk" normal="1900/1950">(bulk 1900-1950)</unitdate>
Broken date spans (e.g., "1924, 1956-1975")
<unitdate normal=1924>1924,</unitdate><unitdate type="inclusive" normal="1956/1975">1956-1975</unitdate> [encode dates in separate <unitdate> tags]
Open date spans
<unitdate normal="1911/9999">1911-[ongoing]</unitdate> [use an interval and set the end date to 9999]
Approximate dates (e.g., "ca. 1950")
<unitdate normal="1945/1955">ca. 1950</unitdate> [normalize as an interval to express an appropriate date range]
<unitdate normal="1980/1989">1980s</unitdate> [use an interval to indicate every year of the decade]
<unitdate normal="1801/1900">19th century</unitdate>
Undated material
<unitdate normal="1920/1957">undated</unitdate> [normalize as an interval (as with approximate dates), perhaps using the collection dates, or life of creator, etc.]
<unitdate normal="1935/1965">undated: ca. mid 20th century</unitdate> [if a document is undated this can be stated but provide an estimate if possible; normalize as an interval, perhaps using the collection dates, or life of creator, etc.]
Approximate dates should be normalized using an interval to express the earliest and latest dates in the range. In order to facilitate date searching on all collection items, supply normalized approximate dates for material even with unknown or undetermined dates. For unknown or undetermined dates, consider using collection inclusive dates.
Note that normalized dates do not display, but are utilized strictly for computer processing of date information.
This section provides guidelines for internal linking within a finding aid, and for external linking to digital resources or objects that are not part of the materials being described by the finding aid. For guidelines on linking from a finding aid to associated digital objects described by that finding aid, see Section 4.4.
All internal linking should be encoded using <ptr> Pointer or <ref> Reference tags with a TARGET attribute to establish a source for a link, with a corresponding ID attribute within a tag elsewhere in the same finding aid to establish a destination for that link. Note that whereas <ptr> is an empty internal linking tag, <ref> can include text and subelements that identify or describe the referenced object. See the EAD AG for more information.
All external linking should be encoded using <extptr> Extended Pointer, <extref> Extended Reference, <bibref> Bibliographic Reference, or <archref> Archival Reference tags with the HREF attribute. Note that whereas <extptr> is an empty external linking tag, <extref> can include text and subelements as part of its reference to an electronic object external to the finding aid. Do not use the ENTITYREF attribute with an associated entity declaration for establishing a destination for the link, such as a URL. See the EAD AG for more information.
For all internal and external linking elements, the default OAC stylesheet behavior will be to render links as SHOW="replace" (i.e., the linked resource will be displayed in the same browser window). The stylesheet will support SHOW="embed" for images only (i.e., the image will be displayed inline) and SHOW="new" (i.e., the linked resource will be displayed in a new browser window). Use of any other SHOW attribute will be rendered as the default SHOW="replace".
EAD uses a system of nested numbered <c0x> Component tags to capture the hierarchical organization and description of a collection. There is no fixed correspondence between a Component tag and the intellectual level; the component tag is merely a wrapper element used to encode hierarchically arranged, nested descriptions. For example, a <c02> tag may serve to encode a file in one section of a container list and an item in another section.
The OAC BPG EAD requires numbered Component tags, from <c01> up to <c12>; do not use unnumbered <c> Component tags. For each <c01> down to <c12> Component tag, a LEVEL attribute must also be used in order to distinguish the levels from each other. This encoding will facilitate computer processing, searching, style sheet manipulation, and ultimately, readability of finding aid data.
Note that there is logic to the nesting of levels. A series, for example, may contain subseries, files, or items, but not another series. For examples see:
Possible EAD <c0x> structures for University of Michigan Bentley Historical Library finding aids.
To clarify the level of each component part, finding aid contributors are required to use the LEVEL attribute at all component levels. Component levels must be numbered, as unnumbered component levels are not supported by the OAC. Use standard archival units to articulate levels (e.g., collection, record group, subgroup, series, subseries, file, and item). See: ISAD(G)
The record group may be divided into subgroups; series may be divided into subseries. EAD provides for further subdivision of subgroups and subseries through setting the LEVEL attribute to "otherlevel" and the otherlevel attribute data value to designate a succession of "subsub" levels as needed.
Similarly, file-level components may be subdivided with additional levels of hierarchy before reaching the item level. This may be done through setting the LEVEL attribute to "otherlevel" and the otherlevel attribute data value to "subfile" or another local term. In general, however (since there are not generally accepted terms for subdivisions of a file), a file should be nested within another file.
Internal and external entities should be encoded per the EAD AG. External entity data files (containing either parseable data, such as additional EAD content; or non-parseable data, such as an image file) should be locally hosted by contributing institutions: declarations must therefore refer to absolute URLs (as system identifiers) for those locally hosted files.
For all special characters encoded in XML, encode directly in UTF-8 Unicode or use Unicode decimal or hexidecimal character references. Note all decimal character references should begin with an ampersand and pound sign, and end with a semicolon (use the syntax "&#D;", where D is a decimal number). Note all hexidecimal character references should begin with an ampersand, pound sign, and lower- or uppercase "x", and end with a semicolon (use the syntax "&#xH;" or "&#XH;", where H is a hexadecimal number); see the Unicode Code Charts for hexidecimal character reference codes.
For more detailed information on XML, UTF-8, and special character encoding, see the W3C/Unicode Consortium document Unicode in XML and other Markup Languages .
Example using UTF-8 Unicode hexidecimal character references to express the term "émigrés":
... The papers also document trends in high school and university education among Russian émigrés...
[NOTE: "é" UTF-8 Unicode hexidecimal character reference used to encode the letter "é" in the word "émigrés," derived from the Unicode Latin-1 Supplement code chart]
Characters reserved for XML markup delimiters (ampersand, left angle bracket, and right angle bracket) need to be replaced with the following character entities:
Note that the OAC style sheet supports a standard, generic presentation, which may not accommodate local preferences. Use of headings, labels, punctuation, and white space is a matter of local choice and practice. In order to render local headings and labels, repositories may need to devise and implement their own style sheets for presenting their finding aids in their local systems.
Lists should be represented using the EAD <list> tag with nested <item> tags for each entry in the list. Set the <list> TYPE attribute accordingly to match the type of list. See the EAD TL for more information.
In certain cases, the CDL style sheets display certain types
of encoding as lists. CDL style sheets render <bibref>,
<extref> and <archref> data values in a list-type
format if those tags occur directly inside <bibliography>,
<otherfindaid>, <relatedmaterial> and <separatedmaterial>.
These elements will be rendered in a block paragraph format,
however, if they occur inside a <p> tag.
Similarly, CDL style sheets render <event>, <famname>,
<function>, <geogname>, <genreform>, <persname>,
<corpname>, <date>, <name>, <occupation>,
and <subject> data values in a list-type format if those
tags directly occur directly inside <controlaccess>, <namegrp>,
<index> or <origination>.
Bold, underline, italic, and other similar kinds of formatting should be represented using the EAD <emph> tag with RENDER attribute set accordingly. See the EAD TL for more information.
The OAC BPG EAD mandate encoding that is largely independent of a particular online presentation: the encoding can be manipulated and repurposed through the application of customized style sheets in order to achieve local and/or consortium display needs and formatting preferences. In order to provide a consistent user experience, the OAC style sheets support a standard presentation which may not accommodate local preferences.
Finding aid file names must adhere to the following specifications:
Examples of valid filenames:mss000261.xml
bay-pap004.xml
plen_session.xml
p23.xml
arequipa.xmlExamples of invalid filenames:
plen.session.xml
sntrecs:corr.xml
Hansen.xml
fogerty.XML