[Archive copy mirrored from: http://sunsite.berkeley.edu/amher/upguide.html]
American Heritage Virtual Archive
Project
Funded in part by a grant from the National Endowment for the Humanities
University of
California Encoded Archival Description Project
Funded in part by a grant from the University of California Office of the President
Participants:
Introduction
Appendix One: Introduction to the EAD Table Model
| Back to Table of Contents |
|
Introduction
The Encoded Archival Description Retrospective Conversion Guidelines are intended to represent an "acceptable range of uniform practice" in the application of Encoded Archival Description (EAD) to converting existing finding aids from disparate institutions for contribution to a union database. The Guidelines have been developed for the American Heritage Virtual Archive Project, which has as its objective the development a prototype union database of finding aids contributed by four universities: Duke University, Stanford University, University of California, Berkeley, and University of Virginia, and the University of California Encoded Archival Description Project (UCEAD), which has as its objective development of a union database of finding aids to collections in the repositories on the nine campuses of the University of California. The demonstration database will explore political, intellectual, technical, and economic issues related to building a union finding aid database.
The Encoded Archival Description Retrospective Conversion Guidelines are a supplement to the EAD Tag Library and EAD Guidelines. EAD is based on Standard Generalized Markup Language (ISO 8879) in the form of a Document Type Definition (DTD). SGML permits a great deal of flexibility in the representation of information. In order to design a machine-readable representation archival description based on SGML that would meet the needs of the archive and library communities, the developers of EAD first developed guidelines and design principles for the DTD and related supporting documents. These principles are known as the Ann Arbor Accords.
One principle found in the Accords recognized that an encoding standard would have to accommodate both a great diversity of existing finding aids and future finding aids based on more rigorous content standards. Because the DTD had to accommodate a diverse past, it had to be flexible in allowing many different possible type, sequence, and quantity of descriptive information. At the same time, in anticipation of the need for a more standardized future in a shared information environment, the DTD mildly constrains the most important information in finding aids, namely that information needed to locate, retrieve, and identify an archival unit, and to make a reasonable evaluation of its relevance to an interest or need.
Given the flexibility of EAD, the choices with respect to type, sequence, and quantity of information, as well as varying levels of detail of encoding, it does not in and of itself ensure that machine-readable finding aids will be easily communicated between repositories, nor facilitate the building of union database. Finding aids in union databases will need to share a degree of uniformity, both to make them easily intelligible for users as they navigate from a finding aid from one institution to that of another, and to make them manageable in a computer environment. This uniformity applies to both the intellectual content, and the machine-readable representation or encoding of that content. Predictability and stability are essential for the existence of communities.
Retrospective conversion is much more complex than original creation of finding aids, given the great diversity of existing information in content and format. Existing finding aids in typical repositories frequently vary in content in format that reflect both changing intellectual fashions in archival description, and changing technology used in the creation of finding aids. Older finding aids in The Bancroft Library, for example, frequently have a minimum of identifying information, followed by a paragraph or two in which biographical or historical information is intermixed with administrative and scope and content information. This information may or may not be followed by a container list or lists of important correspondents. More recent finding aids generally have more detailed identifying information, and administrative and scope and content information is differentiated.
[to be continued]
| Back to Table of Contents |
|
I. <eadheader> EAD HEADER
| Back to Table of Contents |
|
B. Instructions.
<eadheader audience="internal" langencoding="ISO 639" findaidstatus="unverified-full-draft">
AUDIENCE value is "internal". The <eadheader> is intended for access and control of the EAD instance by repository staff. It is not intended for display and use by public users of the finding aid. [required]
LANGENCODING value is "ISO 639." [required]
Language encoding in the EAD instance will subscribe to ISO 639 language codes. A language code is entered for the language of the description in the LANGUAGE attribute on <archdesc> and <c>s, and for the language of the material in the LANGMATERIAL attribute on <archdesc> and <c>s. See <archdesc> and <c>'s for details concerning appropriate usage of the code.
FINDAIDSTATUS value is initially set to "unverified-full-draft" or "unverified-partial-draft"
FINDAIDSTATUS specifies the editorial status of the finding aid. Four values are possible:
The adjectives "partial" and "full" distinguish between finding aids that describe only part of an archival unit and those that describe the entire archival unit. For example, if only three of four series in a manuscript collection are analyzed and described, the finding aid would be either an "unverified-partial-draft" or "edited-partial-draft". The adjectives "unverified" and "edited" refer to editorial review of the finding aid for accuracy and completeness. Finding aids that are initially converted and contributed to the union database are either "unverified-partial-draft" or "unverified-full-draft". After editorial review by the contributing repository, the status is changed to "edited-partial-draft"or "edited-full-draft" by the editor, and resubmitted for publication in the union database.
| Back to Table of Contents |
|
<eadid> EAD Identification
<eadid type="SGML catalog">PUBLIC "-//Name of owner::subordinate named division of owner//TEXT (Country code (ISO 3166)::National repository code::local repository reference code::Title of archival unit)//EN" "filename.sgm"</eadid>
The <eadid> [required] is in the form of an SGML Open Catalog specification, that is, the content of the <eadid> can be used directly in an SGML catalog file as an entry.
TYPE value is always "SGML catalog".
The text of the <eadid> should be formulated according to the specifications in Naming Finding Aids in section VI. Naming and Declaring of Entities.
The local filename, that is, the name of the file in the contributor's archive should be appended to the end of the FPI within double quotes: "filename.sgm" The file submitted to the Berkeley FTP site should have the same name.
| Back to Table of Contents |
|
<filedesc> File Description
<filedesc>
<titlestmt>
<titleproper>[Register of the ] [Inventory of the ]
REQUIRED TITLE PROPER</titleproper>
<author>Processed by [staff/name]; machine-readable
finding aid created by [staff/name]</author>
</titlestmt>
<publicationstmt>
<publisher>[Name of repository]</publisher>
<address><addressline>[Address of
repository]</addressline></address>
<date>©[Copyright date] </date>
<p>[Copyright holder.] All rights reserved.</p>
</publicationstmt>
</filedesc>
The <filedesc>, <titlestmt><titleproper>, and <publicationstmt><publisher> are required.
The <titleproper> is the title of the finding aid, not the archival unit described in it. The <titleproper> of the finding aid must be distinguished from the <unittitle> of the finding aid by the addition of a prefatory phrase such as "Inventory of the ..." or "Register of the ...." If the finding aid is not a register or inventory, then use what ever descriptive phrase is appropriate.
Author. <author> is required if available. The content of the <author> element in <titlestmt> depends upon the context of creation.
If the person or staff responsible for creation of the intellectual content of the finding aid and the encoding are one and the same, which frequently may be the case with finding aids originally encoded using EAD markup, then the markup should be as follows:
<titlestmt> <titleproper>[Register of the ] [Inventory of the ] REQUIRED TITLE PROPER</titleproper> <author>Processed by and machine-readable finding aid created by [name of person or staff unit name]</author> </titlestmt>
If the person or staff responsible for creating the intellectual content of the finding aids is distinct from the person or staff creating the machine-readable finding aid, which frequently may be the case with retrospective conversion of finding aids, then the markup should be as follows:
<titlestmt> <titleproper>[Register of the ] [Inventory of the ] REQUIRED TITLE PROPER</titleproper> <author>Processed by [name of person or staff unit name]; machine-readable finding aid created by [name of person or staff unit name].</author> </titlestmt>
Publication statement.
<publicationstmt> <publisher>[Name of repository]</publisher> <address><addressline>[Address of repository]</addressline> </address> <date>©[Copyright date]</date> <p>[Copyright holder.] All rights reserved.</p> </publicationstmt>
The name and address of the repository are required. It is highly recommended that the name and address of the repository be stored as a separate referenced file that can be independently maintained. The name and complete address must be entered in the <publicationstmt>. A complete address includes the following: postal address, phone and fax numbers, and email address.
The repository name/address file must be declared in the declaration subset of each EAD instance referencing the file in the <eadheader>. Please see the section below on Naming and Declaring Referenced External Entities for an explanation of the declaration subset and a general description of entity declarations.
The following is an example of the entity declaration for the referenced file containing the name and address of the repository, the <publicationstmt> element with the name and address represented by an entity reference, and a copy of the content of the referenced file:
Declaration: <!ENTITY hdr-cu-banc PUBLIC "-//University of
California, Berkeley::Bancroft Library//TEXT
(eadheader: CU-BANC name and address)//EN" "hdrbanc.sgm">
Element: <publicationstmt>
&hdr-cu-banc;
<date>© 1997</date>
<p>Regents of the University of California. All
rights reserved.</p>
</publicationstmt>
File: <publisher>The Bancroft Library.</publisher>
<address>
<addressline>University of California, Berkeley.</addressline>
<addressline>Berkeley, California 94720-6000</addressline>
<addressline>Phone: 510/642-6481</addressline>
<addressline>Fax: 510/642-7589</addressline>
<addressline>Email: bancref@library.berkeley.edu</addressline>
</address>
Copyright statement. The formal copyright statement for the finding aid is
given in the
<publicationstmt><date> and the <p> following the <date>. The
"©" is the ISO character
entity for the copyright symbol in ISO 8879-1986
Numeric and Special Graphic character entity set.
| Back to Table of Contents |
|
<profiledesc> Profile Description
<profiledesc>
<creation>Machine-readable finding aid derived from
[paper by means of scanning and OCR; OCR file edited for
typographical errors before encoding] [word processing
program. [version number if known]] [typescript by rekeying]
[[database name] database [version number if known] by means
of machine processing]. [Date of source: <date>.</date>]
</creation>
<langusage>Description is in
<language>English.</language>
</langusage>
</profiledesc>
The <profiledesc><creation> element provides the information concerning the format of the original, the method or methods of conversion, and the date of the conversion. The precise date, if known, should be given. If the date can be estimated from what is known without further research, then give the date in the form <date>ca 19__.</date>", supplying the decade, and if possible, year. If the date is not known and can not be estimated easily, then enter <date>unknown.</date>.
<langusage> is the language of the description, not the language of the material.
| Back to Table of Contents |
|
<revisiondesc> Revision Description
<revisiondesc>
<change>
<date>[date of change]</date>
<item>[brief textual description of significant change,
name of editor]</item>
</change>
</revisiondesc>
<revisiondesc> should only be used after the initial cycle of creation and editorial
review for
significant changes to the content of the description. Minor changes to correct encoding and
typographical errors are not significant changes. Judgements concerning what constitutes a
"significant change" are the responsibility of individual archives.
| Back to Table of Contents |
|
II. <frontmatter> Front Matter
A. Template.
<frontmatter>
<titlepage>
<titleproper>[Register of the ] [Inventory of the ]
REQUIRED TITLE PROPER INCLUDING DATE(S)</titleproper>
<num>Collection number: </num>
<publisher>Repository name
<lb><extptr displaytype="present"
entityref="name-of-seal">
<lb>Additional element of repository name
<lb>Place of publication
</publisher>
<list type="simple">
<head>Contact Information:</head>
<item>[Repository Name]</item>
<item>[Repository Address]</item>
<item>Phone: [Phone number]</item>
<item>Fax: [Fax number]</item>
<item>Email: [Email address]</item>
</list>
<list>
<defitem>
<label>Processed by: </label>
<item>[name of person or staff unit]</item>
</defitem>
<defitem>
<label>Date Completed: </label>
<item><date>199_</date></item>
</defitem>
<defitem>
<label>Encoded by: </label>
<item>[name of person or staff unit]</item>
</defitem>
</list>
<p>© 1996 [Copyright holder. ]All rights reserved.</p>
</titlepage>
</frontmatter>
| Back to Table of Contents |
|
B. Instructions.
While the <frontmatter> is an optional element in EAD, it is required for the participants in the American Heritage Virtual Archive and UCEAD Projects. The following are required, and in the order presented: <titlepage>, <titleproper>, <publisher>, <date> (of publication), contact information (in <list>), and <p> including copyright statement. All other information is optional, though recommended.
The <titleproper> should match exactly the <titleproper> given in the <eadheader>.
Publisher. Use the name of the repository for <publisher>. If the contributing repository would like to include its institutional seal, it is recommended that it be placed either after the name of the respository, if the name consists of one component, or between name components, if the name is compound and in inverse hierarchical order, or after the last name element. A referenced graphic must be declared in the declaration subset of the EAD instance. Please see the section Naming and Declaring Referenced External Entities below for instructions concerning the declaration of entitites in general, and the section NonSGML Entities for instructions on specific characteristics of the declaration and referencing of NonSGML entities. The <extptr> element should be used for referencing the graphic file of the seal. The DISPLAYTYPE should have the value "present", to signal the software that the graphic is to be present or displayed inline. Please see the section Hypertext and Hypermedia for instructions on the use of the <extptr>.
Contact Information. The full name and address of the repository is required on the title page. It is highly recommended that the name and address of the repository be stored as a separate referenced file that can be independently maintained. The name and complete address must be entered in the <list> element.
A complete address includes the following: name of repository, postal address, phone and fax numbers, and email address. Optionally, a URL for the repositories Home Page may also be given.
The name and address must be declared in the declaration subset of each EAD instance referencing the file in the <titlepage>. Please see the section below on Naming and Declaration of External Referenced Entites for an explanation of the declaration subset and a general description of entity declarations.
The following is an example of the entity declaration for the referenced file containing the name and address of the repository, the <publisher> element with the name and address (and graphic) represented by an entity reference, and a copy of the content of the referenced file:
Declarations: <!ENTITY tp-cu-banc PUBLIC "-//University of
California, Berkeley::Bancroft Library//TEXT (titlepage:
CU-BANC name and address)//EN"
"tpbanc.sgm">
Element: <titlepage>
... [elements omitted]
&tp-cu-banc;
... [elements omitted]
</titlepage>
File: <list type="simple">
<head>Contact Information:</head>
<item>The Bancroft Library</item>
<item>University of California, Berkeley</item>
<item>Berkeley, California 94720-6000</item>
<item>Phone: 510/642-6481</item>
<item>Fax: 510/642-7589</item>
<item>Email: bancref@library.berkeley.edu</item>
</list>
| Back to Table of Contents |
|
III. <findaid> Finding Aid
A. <archdesc> Archival Description
Template.
Instructions.
<archdesc language="en" level="collection" langmaterial="en">
The LEVEL attribute should always be set. The values are as follows:
Give the value "otherlevel" if none of the given values is appropriate, and provide the
appropriate
value in the OTHERLEVEL attribute.
The LANGUAGE (of the archival description) and LANGMATERIAL (language of the
archival
materials) values should be set using the two letter codes for the appropriate language from
ISO
639, Code for the representation of names of languages.
<findaid>
<archdesc language="en" level="collection" langmaterial="en">
| Back to Table of Contents |
1. <did> Descriptive Identification
Instructions.
The following table gives the <did> elements in prescribed order; whether they are required (R), not required (NR), or required if available (RA); and the recommended LABEL attribute value or values:
| Element | Required? | LABEL |
| <unittitle> | R | Title |
| <unitdate> | NR | [No label] |
| <unitid> | NR | Collection number |
| <origination> | RA | Provenance |
| Creator | ||
| Collector | ||
| <physdesc> | R | Extent |
| Size | ||
| Physical Characteristics | ||
| <repository> | R | Repository |
| <unitloc> | NR | Shelf Location |
| Location | ||
| Storage Location | ||
| <note> | NR | [as appropriate to descriptive content] |
While the <unitdate> can be used as an element directly within <did>, <unitdate> is to be used within the <unittitle>. Set its TYPE attribute to the appropriate value: "bulk", "inclusive", or "single".
In <origination> within <archdesc>, personal names (<persname>), corporate names (<corpname>), and family names (<famname>) are to be encoded. Use catalog entry form if it is readily available.
Within <repository>, encode the corporate name (<corpname>) of the repository in catalog entry form. If the name is preceded by an article, encode as follows: <repository>The <corpname>Repository Name</corpname></repository>
The LOCTYPE attribute must be set to "repository" or "container". If LOCTYPE is set to "container", you must also set the CONTAINERTYPE attribute to an appropriate value selected from the following list:
Give the value "othercontainertype" if none of the given values is appropriate, and provide
the
appropriate value in the OTHERCONTAINERTYPE attribute.
| Back to Table of Contents |
|
2. Descriptive Context Elements within <archdesc>
Template.
Note: Only commonly used elements and subelements are given. If other elements
or
subelements are used, then the same conventions with respect to the <head> element and
other structural features should follow the same pattern.
<admininfo>
<head>Administrative Information</head>
<accessrestrict>
<head>Access</head>
<p>Collection is open [closed] to research [until <date>
</date>].</p>
</accessrestrict>
<userestrict>
<head>Publication Rights</head>
<p>Copyright ....</p>
</userestrict>
<prefercite>
<head>Preferred Citation</head>
<p>[Identification of item], [collection name], [collection number],
[repository name].</p>
</prefercite>
</admininfo>
<bioghist>
<head>Biography [History]</head>
<p>[prose biography or history]</p>
<chronlist>
<listhead>
<head01>Date</head01>
<head02>Event</head02>
</listhead>
<chronitem><date></date><event></event>
</chronitem>
<chronitem><date></date><event></event>
</chronitem>
</chronlist>
</bioghist>
<odd>
<head>Abstract [use for mixed content description; use other heading as
appropriate to content]</head>
<p></p>
</odd>
<scopecontent>
<head>Scope and Content</head>
<p></p>
</scopecontent>
| Back to Table of Contents |
|
Instructions.
The following elements are available in <archdesc> following the <did> but preceding the <dsc>: <admininfo>, <bioghist>, <controlaccess>, <scopecontent>, <organization>, and <arrangement>. They can occur in any order, and as many times as is necessary. And additional element, <odd> or Other Descriptive Data, provides for encoding descriptive data that is not classified easily into one of these elements, and for encoding mixed data that is not easily or efficiently segregated into one of the other descriptive context elements.
In existing finding aids, the specific kinds of information that would logically be contained in one of these elements may or may not be easily identified and encoded. For example, early finding aids in the Bancroft Library frequently contain one or two paragraphs of descriptive introductory information that mixes administrative information including acquisitions, provenance, and access and use restrictions, as well as biographical or historical and brief scope and content information.
In order to facilitate efficient conversion of exiting finding aids, such blocks of information will be encoded using the <odd> element, without further distinction of content elements. Where blocks of descriptive information are easily identified as falling into a particular descriptive element, such blocks are encoded using the appropriate element.
<odd> should also be used for blocks of descriptive text that are not logically one of the other descriptive context elements.
<admininfo>, <bioghist>, <controlaccess>, <scopecontent>, <organization>, <arrangement>, and <odd> generally share many generic structural text features, head element, paragraphs, and simple lists; as well as some special appropriate subelements. Each of these elements can be subdivided into distinct sections recursively using itself.
The <header> is required on all of these elements, and on all major
subdivisions within each
element.
| Back to Table of Contents |
|
3. <dsc> Description of Subordinate Components
General Instruction.
The <dsc> or Description of Subordinate Components is used for Series Descriptions,
Container
Lists (and other descriptive lists (as opposed to indices. See section on <index> below)), and
descriptions that intermix series description and container lists. Templates for each use of the
<dsc>
are provided below.
The TYPE attribute in the <dsc> is used to specify each type of description. The TYPE
attribute
offers four values:
The OTHERTYPE attribute is to be selected from a controlled list of other types of analytic
description. The following are the other types currently authorized. Repositories must submit
requests for addition types to the community for discussion. There must be community-wide
consensus before new types are added to the list.
Authorized OTHERTYPE values:
The <head> element is required on all <dsc>s.
Use of <c01> etc. in <dsc>. While either the
enumerative <c01> ... <c12> or the recursive <c>s
can be used for the description of subordinate components, all component descriptions within the
UCEAD and American Heritage Projects must use the enumerative <c01> ... <c12>.
The LEVEL
attribute on the <c01> ... <c12> must be set when the component
being described is a series or
subseries, <c01 level="series"> and <c02 level="subseries">. The LEVEL attribute
below
subseries is optional. Note: the reason for setting the LEVEL attribute is to inform the SGML
software to use the <head> or <unitititle> in the table of contents/navigator when the
component
being described comprises a significant unit of material.
Use of <dentry> and <entry>. The SPANNAME attribute on
<dentry> and on the <entry> in
<thead> must always be set using a value from the Berkeley defined and maintained
<tspec>. See
Appendix One: Introduction to the EAD Table
Model for specific instruction on the use of
<tspec> and <dentry>.
Use of <unitloc> in <dsc>.
Use of <unittitle> in <dentry>. Frequently descriptive titles in
container lists are not differentiated
from other descriptive text. When other descriptive text, including scope and content
information, is
given "inline" with the descriptive title, include the other descriptive text in the <unittitle>
element.
If the other descriptive text is given as a block of text separated from the title by a linebreak or a
linebreak and additional line spacing, however brief the block may be, encode the distinct block
with
the appropriate element, e.g. <scopecontent> or <odd>. If an extent statement is
embedded within
the descriptive title block, it cannot be encoded as a distinct element. However, if the extent
statement comes at the end of the title block, encode it using the <physdesc> element.
Example of title block [to be supplied]
Example of title block followed by one or more blocks of other descriptive information. [to
be
supplied]
analyticover series descriptions
in-depth container lists
combined mixed series descriptions and container lists
othertype other analytic descriptive types, enter type
in OTHERTYPE attribute
correspondence partial lists of correspondents
segregated container lists segregated into sections (using
nested <dsc>s. Note: "segregated lists" are
lists that are divided into two or more sections and
the division is not based on an intellectual analysis.
| Back to Table of Contents |
|
Series Description
Template:
<dsc type="analyticover">
<head>[Series Description]</head>
<c01 level="series">
<head>[Series heading]</head>
<did>
<unittitle>[Title], <unitdate type="inclusive">
[Date or date range]</unitdate></unittitle>
</did>
<scopecontent>
<p>...</p>
</scopecontent>
<c02 level="subseries">
<head>[Subseries heading]</head>
<did>
<unittitle>[Title], <unitdate type="inclusive">
[Date or date range]</unitdate></unittitle>
</did>
<scopecontent>
<p>...</p>
</scopecontent>
</c02>
</c01>
</dsc>
| Back to Table of Contents |
|
Container List
Template (with tabular layout):
<dsc type="in-depth">
<head>[Container List]</head>
&cutspec;
<c01 level="series">
<did>
<unittitle>[Title], <unitdate type="inclusive">
[Date or date range]</unitdate></unittitle>
</did>
<c02 level="subseries">
<did>
<unittitle>[Title], <unitdate type="inclusive">
[Date or date range]</unitdate></unittitle>
</did>
<thead>
<entry spanname="c1-3>Box</dentry>
<entry spanname="c4-6>Folder</dentry>
<entry spanname="c7-20>[Contents]</dentry>
</thead>
<c03>
<drow>
<dentry spanname="c1-3"><unitloc loctype="container"
containertype="box"></unitloc></dentry>
<dentry spanname="c4-6"><unitloc loctype="container"
containertype="folder"></unitloc></dentry>
<dentry spanname="c7-20"><unittitle>[Title],
<unitdate>[Date or date range]</unitdate>
</unittitle></dentry>
</drow>
<c04>
<drow>
<dentry spanname="c1-3"><unitloc loctype="container"
containertype="box"></unitloc></dentry>
<dentry spanname="c4-6"><unitloc loctype="container"
containertype="folder"></unitloc></dentry>
<dentry spanname="c8-20"><unittitle>[Title],
<unitdate>[Date or date range]</unitdate>
</unittitle></dentry>
</drow>
</c04>
</c03>
<c03>
<drow>
<dentry spanname="c1-3"><unitloc loctype="container"
containertype="box"></unitloc></dentry>
<dentry spanname="c4-6"><unitloc loctype="container"
containertype="folder"></unitloc></dentry>
<dentry spanname="c7-20"><unittitle>[Title],
<unitdate>[Date or date range]</unitdate>
</unittitle></dentry>
</drow>
<c04>
<drow>
<dentry spanname="c1-3"><unitloc loctype="container"
containertype="box"></unitloc></dentry>
<dentry spanname="c4-6"><unitloc loctype="container"
containertype="folder"></unitloc></dentry>
<dentry spanname="c8-20"><unittitle>[Title],
<unitdate>[Date or date range]</unitdate></unittitle>
</dentry>
</drow>
</c04>
</c03>
</c02>
</c01>
</dsc>
Template (without tabular layout):
<dsc type="in-depth">
<head>[Container List (non-tabular)]</head>
<c01 level="series">
<did>
<unittitle>[Title], <unitdate type="inclusive">
[Date or date range]</unitdate></unittitle>
</did>
<c02 level="subseries">
<did>
<unittitle>[Title], <unitdate type="inclusive">
[Date or date range]</unitdate></unittitle>
</did>
<c03>
<did>
<unitloc loctype="container" containertype="box">
</unitloc>
<unitloc loctype="container" containertype="folder">
</unitloc>
<unittitle>[Title], <unitdate>[Date or
date range]</unitdate></unittitle>
</did>
<c04>
<did>
<unitloc loctype="container" containertype="box">
</unitloc>
<unitloc loctype="container" containertype="folder">
</unitloc>
<unittitle>[Title], <unitdate>[Date or
date range]</unitdate></unittitle>
</did>
</c04>
</c03>
<c03>
<did>
<unitloc loctype="container" containertype="box">
</unitloc>
<unitloc loctype="container" containertype="folder">
</unitloc>
<unittitle>[Title], <unitdate>[Date or
date range]</unitdate></unittitle>
</did>
<c04>
<did>
<unitloc loctype="container" containertype="box">
</unitloc>
<unitloc loctype="container" containertype="folder">
</unitloc>
<unittitle>[Title], <unitdate>[Date or
date range]</unitdate></unittitle>
</did>
</c04>
</c03>
</c02>
</c01>
</dsc>
| Back to Table of Contents |
|
Series Description/Container List
Template (with tabular layout):
<dsc type="combined">
<head>[Series Description/Container List]</head>
&cutspec;
<c01 level="series">
<head>[Series heading]</head>
<did>
<unittitle>[Title], <unitdate type="inclusive">
[Date or date range]</unitdate></unittitle>
</did>
<scopecontent>
<p>...</p>
</scopecontent>
<c02 level="subseries">
<head>[Subseries heading]</head>
<did>
<unittitle>[Title], <unitdate type="inclusive">
[Date or date range]</unitdate></unittitle>
</did>
<scopecontent>
<p>...</p>
</scopecontent>
<thead>
<entry spanname="c1-3>Box</dentry>
<entry spanname="c4-6>Folder</dentry>
<entry spanname="c7-20>[Contents]</dentry>
</thead>
<c03>
<drow>
<dentry spanname="c1-3"><unitloc loctype="container"
containertype="box"></unitloc></dentry>
<dentry spanname="c4-6"><unitloc loctype="container"
containertype="folder"></unitloc></dentry>
<dentry spanname="c7-20"><unittitle>[Title],
<unitdate>[Date or date range]</unitdate>
</unittitle></dentry>
</drow>
<c04>
<drow>
<dentry spanname="c1-3"><unitloc loctype="container"
containertype="box"></unitloc></dentry>
<dentry spanname="c4-6"><unitloc loctype="container"
containertype="folder"></unitloc></dentry>
<dentry spanname="c8-20"><unittitle>[Title],
<unitdate>[Date or date range]</unitdate>
</unittitle></dentry>
</drow>
</c04>
</c03>
<c03>
<drow>
<dentry spanname="c1-3"><unitloc loctype="container"
containertype="box"></unitloc></dentry>
<dentry spanname="c4-6"><unitloc loctype="container"
containertype="folder"></unitloc></dentry>
<dentry spanname="c7-20"><unittitle>[Title],
<unitdate>[Date or date range]</unitdate>
</unittitle></dentry>
</drow>
<c04>
<drow>
<dentry spanname="c1-3"><unitloc loctype="container"
containertype="box"></unitloc></dentry>
<dentry spanname="c4-6"><unitloc loctype="container"
containertype="folder"></unitloc></dentry>
<dentry spanname="c8-20"><unittitle>[Title],
<unitdate>[Date or date range]</unitdate>
</unittitle></dentry>
</drow>
</c04>
</c03>
</c02>
</c01>
</dsc>
Template (with non-tabular layout):
<dsc type="combined">
<head>[Series Description/Container List (non-tabular)]</head>&cutspec;
<c01 level="series">
<did>
<head>[Series heading]</head>
<unittitle>[Title], <unitdate type="inclusive">
[Date or date range]</unitdate></unittitle>
</did>
<scopecontent>
<p></p>
</scopecontent>
<c02 level="subseries">
<did>
<head>[Subseries heading]</head>
<unittitle>[Title], <unitdate type="inclusive">
[Date or date range]</unitdate></unittitle>
</did>
<scopecontent>
<p></p>
</scopecontent>
<c03>
<did>
<unitloc loctype="container" containertype="box">
</unitloc>
<unitloc loctype="container" containertype="folder">
</unitloc>
<unittitle>[Title], <unitdate>[Date
or date range]</unitdate></unittitle>
</did>
<c04>
<did>
<unitloc loctype="container" containertype="box">
</unitloc>
<unitloc loctype="container" containertype="folder">
</unitloc>
<unittitle>[Title], <unitdate>[Date
or date range]</unitdate></unittitle>
</did>
</c04>
</c03>
<c03>
<did>
<unitloc loctype="container" containertype="box">
</unitloc>
<unitloc loctype="container" containertype="folder">
</unitloc>
<unittitle>[Title], <unitdate>[Date
or date range]</unitdate></unittitle>
</did>
<c04>
<did>
<unitloc loctype="container" containertype="box">
</unitloc>
<unitloc loctype="container" containertype="folder">
</unitloc>
<unittitle>[Title], <unitdate>[Date
or date range]</unitdate></unittitle>
</did>
</c04>
</c03>
</c02>
</c01>
</dsc>
| Back to Table of Contents |
|
Correspondence List
Template.
<dsc type="othertype" othertype="correspondence">
<head>[Partial List of Correspondents]</head>
<c01>
<did>
<unittitle>[Title], <unitdate>[Date or
date range]</unitdate>
</unittitle>
</did>
<scopecontent>
<p></p>
</scopecontent>
</c01>
<c01>
<did>
<unittitle>[Title], <unitdate>[Date or
date range]</unitdate>
</unittitle>
</did>
<scopecontent>
<p></p>
</scopecontent>
</c01>
</dsc>
| Back to Table of Contents |
|
Segregated Lists
Template.
<dsc type="othertype" othertype="segregated">
<head>[Key to Arrangement][Container List]</head>
<dsc type="in-depth">
<head>Part I</head>
</dsc>
<dsc type="in-depth">
<head>Part II</head>
</dsc>
</dsc>
| Back to Table of Contents |
|
B. <add> Adjunct to Descriptive Data
Template.
<add>
<head>Additional Information</head>
<bibliography>
<head>Bibliography</head>
<p></p>
<bibref>
[Author]. <title>[Title]. </title>[Place]:
[Publisher name], [Date]. [page numbers].
</bibref>
</bibliography>
<div>
<head>[Heading]</head>
<p></p>
</div>
<fileplan>
<head>File Plan</head>
<p></p>
</fileplan>
<index>
<head>Index</head>
<p></p>
<indexentry>
<persname></persname>
<ref></ref>
</indexentry>
</index>
<relatedmaterial>
<head>Related Material</head>
<p></p>
<archref>
<unittitle>[Title], <unitdate type="inclusive">
[Date or dates].
</unitdate></unittitle>
<unitid>[Collection id]. </unitid>
<origination>[Origination]. </origination>
<physdesc>[Extent]. </physdesc>
<repository>
<corpname>[Repository name], </corpname>
<address><addressline>[Repository address 1],
</addressline></address>
<address><addressline>[Repository address 2].
</addressline></address>
</repository>
</archref>
</relatedmaterial>
<separatedmaterial>
<head>Separated Material</head>
<p></p>
<archref>
<unittitle>[Title], <unitdate type="inclusive">
[Date or dates].
</unitdate></unittitle>
<unitid>[Collection id]. </unitid>
<origination>[Origination]. </origination>
<physdesc>[Extent]. </physdesc>
<repository>
<corpname>[Repository name], </corpname>
<address><addressline>[Repository address 1],
</addressline></address>
<address><addressline>[Repository address 2].
</addressline></address>
</repository>
</archref>
</separatedmaterial>
</add>
| Back to Table of Contents |
|
Instructions.
<index>. If there is more than one <ref> within a <indexentry> use <ptrgrp>
Example:
<add><index>
<head>Index</head>
<indexentry><persname>Albright, Horace Marden, 1890- </persname>
<ptrgrp>
<ref>p. 17, </ref>
<ref>p. 18</ref>
</ptrgrp>
</indexentry>
<indexentry><persname>Alcott, Louisa May</persname>
<ptrgrp>
<ref>p. 5, </ref>
<ref>p. 9</ref>
</ptrgrp>
</indexentry>
</index></add>
| Back to Table of Contents |
|
IV. General Encoding Instructions.
Word Spacing. For all inline elements within block elements, spacing should be provided within each element to separate it from the following word. Exception, when using the <emph> and <title> elements with the RENDER attribute set to "quoted", place the space separating the word from the following word following the <emph> or <title> element.
Attribute Values. When supplying attribute values, always surround the value with double quotation marks ("value or values"). When using SGML authoring software, the double quotation marks are supplied automatically.
<emph> and <title>. All <emph> will be bold and all <title> elements will be italic unless the RENDER attribute is set to a specific value. For quoted titles, use the double quote (") on the keyboard rather than the <title> element. Specific values available are as follows:
Names, Topics, and dates. Names, topics, and dates are to be encoded where specified. More detailed tagging of names, topics, and dates is at the discretion of individual repositories.
<list>. <list> can be used in two ways: definition lists that pair a word or phrase with another word or phrase; or a simple list of individual words or phrases.
Template for definition list:
<list>
<head>[Optional head for list]</head>
<listhead>
<head01>[Heading for column 1]</head01>
<head02>[Heading for column 2]</head02>
</listhead>
<defitem>
<label>[Word or phrase in column 1]</label>
<item>[Word or phrase in column 2]</item>
</defitem>
<defitem>
<label>[Word or phrase in column 1]</label>
<item>[Word or phrase in column 2]</item>
</defitem>
</list>
Template for simple list:
<list>
<head>[Optional head for list]</head>
<item>[Word or phrase]</item>
<item>[Word or phrase]</item>
<item>[Word or phrase]</item>
<item>[Word or phrase]</item>
</list>
<table>. The <table> element is a subset of the CALS table DTD. [to be completed after there are enough representative examples]
<blockquote> and inline quotes.
<note>
The <note> element should only be used as follows:
| Back to Table of Contents |
|
V. Hypertext and Hypermedia.
References and Pointers.
References and pointer elements are used to refer or point from one place in a finding aid to another place in the same finding aid, or to point from a finding aid to another finding aid, or to a related text or graphic file. The internal reference and pointing elements are <ref> and <ptr>. The external reference and pointing elements are <bibref>, <title>, <extref>, <archref>, <extptr> and <dao>.
The pointer elements <ptr> and <extptr> cannot contain text; they simply indicate that a link is to be made from the location of the element to a location indicated in an attribute. Pointer elements are represented by a hyperlinked icon.
The <dao> is a pointer element. It cannot contain text directly, though it can contain the <daodesc> element, which can contain text. The <daodesc> element, though is intended to contain a text description of a graphic image for the visually impaired.
The reference elements may contain text and subelements. The text in the reference element is used to identify the referenced object. The text in the reference element will be highlighted if there is an active hypertext link.
All internal and external references and pointers (except <ptr>) share the attribute DISPLAYTYPE. There are two possible values for this attribute:
This attribute must be set to "present" for references that the author wants displayed inline; and to "reveal" for references that will be represented by an icon or thumbnail image.
Internal References and Pointers.
Internal references and pointers use formal SGML features to accomplish identifying the target of a link and the TARGET attribute on the <ptr> or <ref> element to refer to the target. The attribute for identifying the target of a link is the ID attribute. Almost all elements in <ead> have an optional ID attribute. A value unique to each element must be used as the ID for an element that is to serve as a target. The SGML parser will enforce the uniqueness of the value; if more than one element has the same ID value, a warning message will be given when the <ead> instance is parsed. The TARGET attribute on the <ptr> or <ref> element will use the same value as the ID on the targeted element. The SGML parser will check to make sure all TARGET attribute values resolve to an ID in a targeted element; if there is no corresponding ID attribute on an element, a warning message will be given at the time an <ead> instance is parsed.
Simple Examples:
<p ID="p1">This is simple paragraph that might occur anywhere a
paragraph can in the finding aid. It serves as the target
of the reference or pointer.</p>
<ptr target="p1">An icon will appear that will take the user to
the targeted paragraph when clicked.
<ref target="p1">This is a textual reference to the targeted
paragraph.</ref> The text will be highlighted
and will take the user to the targeted
paragraph when clicked.
External References and Pointers.
The external reference and pointing elements are <bibref>, <dao> <title>, <extref>, <archref>, and <extptr>.
The external and pointing elements employ formal SGML features. Reference elements may only refer to external objects intellectually, which is to say, by presenting descriptive text that identifies and perhaps describes an external object. If such objects exist in digital form (text, images (including images of text), sound files, etc.), then they must be declared in the declaration subset of the <ead> instance. Please see the section Naming and Declaring Referenced External Entities for instructions concerning the declaration of different types of entities. To reference a declared entity using an external pointer or reference, supply the Entity Name in the declaration in the ENTITYREF attribute of the pointer or reference.
Simple example:
Declaration: <!ENTITY genseal PUBLIC "-//Name of owner::subordinate
named division of owner//NONSGML (Unique name of the
graphic)//EN" "genseal.gif" NDATA GIF>
<ptr displaytype="present" entityref="genseal">
| Back to Table of Contents |
|
Instructions.
<archref>
The <archref> allows both text and, as subelements, the <did> elements of the finding aid/collection to which it is referring. The <archref> will be treated as a block element when it occurs directly inside <bibliography>, <relatedmaterial>, and <separatedmaterial>. When it occurs within a <p>, it will treated as an inline element. Special care should be taken with respect to spacing and punctuation with respect to the authoring of the <archref> element. Please see the following example of typical formatting:
<archref>
For a related collection, see the following:
<unittitle>[Title], <unitdate type="inclusive">[Date or dates].
</unitdate></unittitle>
<unitid>[Collection id]. </unitid>
<origination>[Origination]. </origination>
<physdesc>[Extent]. </physdesc>
<repository>
<corpname>[Repository name], </corpname>
<address><addressline>[Repository address 1], </addressline>
</address>
<address><addressline>[Repository address 2]. </addressline>
</address>
</repository>
</archref>
The display will be formatted as follows:
For a related collection, see the following: [Title], [Date or dates]. [Collection id]. [Origination]. [Extent]. [Repository name], [Repository address 1], [Repository address 2].
<bibref>
The <bibref> allows both text and, as subelements, some generic bibliographic descriptive elements (<name>, <title>, <imprint>, <num>) for describing the published object to which it is referring. The <bibref> will be treated as a block element when it occurs directly inside <bibliography>, <relatedmaterial>, and <seperatedmaterial>. When it occurs within a <p>, it will treated as an inline element. Special care should be taken with respect to spacing and punctuation with respect to the authoring of the <bibref> element. Please see the following example of typical formatting. Also please note that the internal subelements, except for the <title> subelement, are optional.
<bibref>
Please see the following [published material]:
<name>[Author]. </name>
<title>[Title]. </title>
<imprint>
<geogname>[Place]: </geogname>
<publisher>[Publisher name], </publisher>
<date>[Date]. </date>
</imprint>
<num>[page numbers]. </num>
</bibref>
or optionally:
<bibref> [Author]. <title>[Title]. </title>[Place]: [Publisher name], [Date]. [page numbers]. </bibref>
The display will be formatted as follows:
Please see the following [published material]: [Author]. [Title]. [Place]: [Publisher name], [Date]. [page numbers].
| Back to Table of Contents |
|
<dao>
The <dao> is a special form of external reference that is to be used exclusively for referencing digital representations of archival materials. Such externally referenced objects must be declared in the declaration subset of the EAD instance. Please see the section Naming and Declaring Referenced External Entities and Naming Conventions for instructions concerning the naming and declaration of different types of entities.
<dao> may only be used in <archdesc>, and then only within constrained environments. Currently <dao> is being used exclusively within the <c0#>s. Placement and use of the <dao> will differ according to whether a tabular or non-tabular <dsc> is used.
Note that it is always assumed that a thumbnail image representing will appear inline. As such, at least two files will represent each archival object: a file containing the thumbnail, and a file containing the viewing file. The intellectual object, however, will have only one name.
Tabular display.
Note that more than one <dao>, for example, if a <c0#> describes a folder containing two pictures.
<dsc type="in-depth">
<head>[Container List]</head>
&cutspec;
<c01 level="series">
<did>
<unittitle>[Title], <unitdate type="inclusive">[Date
or date range]</unitdate></unittitle>
</did>
<c02 level="subseries">
<did>
<unittitle>[Title], <unitdate type="inclusive">
[Date or date range]</unitdate></unittitle>
</did>
<thead>
<entry spanname="c1-3>Box</dentry>
<entry spanname="c4-6>Folder</dentry>
<entry spanname="c7-20>[Contents]</dentry>
</thead>
<c03>
<drow>
<dentry spanname="c1-3"><unitloc loctype="container"
containertype="box"></unitloc></dentry>
<dentry spanname="c4-6"><unitloc loctype="container"
containertype="folder"></unitloc></dentry>
<dentry spanname="c7-20">
<unittitle>[Title], <unitdate>[Date or
date range]</unitdate></unittitle>
<dao entityref="[Entity name]"></dao>
</dentry>
</drow>
</c03>
<c03>
<drow>
<dentry spanname="c1-3"><unitloc loctype="container"
containertype="box"></unitloc></dentry>
<dentry spanname="c4-6"><unitloc loctype="container"
containertype="folder"></unitloc></dentry>
<dentry spanname="c7-20">
<unittitle>[Title], <unitdate>[Date
or date range]</unitdate></unittitle>
<dao entityref="[Entity name]"></dao>
<dao entityref="[Entity name]"></dao>
</dentry>
</drow>
</c03>
</c02>
</c01>
</dsc>
| Back to Table of Contents |
|
Non-tabular display.
<dsc type="in-depth">
<head>[Container List (non-tabular)]</head>
<c01 level="series">
<did>
<unittitle>[Title], <unitdate type="inclusive">
[Date or date range]</unitdate></unittitle>
</did>
<c02 level="subseries">
<did>
<unittitle>[Title], <unitdate type="inclusive">
[Date or date range]</unitdate></unittitle>
</did>
<c03>
<did>
<unitloc loctype="container" containertype="box">
</unitloc>
<unitloc loctype="container" containertype="folder">
</unitloc>
<unittitle>[Title], <unitdate>
[Date or date range]</unitdate></unittitle>
<dao entityref="[Entity name]"></dao>
</did>
</c03>
<c03>
<did>
<unitloc loctype="container" containertype="box">
</unitloc>
<unitloc loctype="container" containertype="folder">
</unitloc>
<unittitle>[Title], <unitdate>
[Date or date range]</unitdate></unittitle>
<dao entityref="[Entity name]"></dao>
<dao entityref="[Entity name]"></dao>
</did>
</c03>
</c02>
</c01>
</dsc>
| Back to Table of Contents |
|
<title> and <extref>
Both the <title> and <extref> elements are treated as inline element.
<ref>
The <ref> element is used for general textual references within the finding aid. While the use of the <ref> element within paragraphs and in other general contexts has been covered, its use in the the <dsc> element to refer from within one <c#> to another <c#> or to another location in the finding aid involves special instructions.
The following rules apply to all uses of the <ref> within the <dsc>:
References from one unused series title to another can be done in two ways:
Example 1:
<c0#><did>
<unittitle>[Title]
<lb>
See: [See also: ]
<ref displaytype="present">[Title of target]</ref>
</unittitle></did>
</c0#>
Example 2:
<c0#><did>
<unittitle>[Title ]
See: [See also: ]
<ref displaytype="present">[Title of target]</ref>
</unittitle></did>
</c0#>
The difference between the two examples is the <lb> element. The display format for each element will appear as follows:
[Title]
See: [See also: ][Title of target]
[Title] See: [See also: ][Title of target]
References from two or more unused series title to another can be done in three ways:
Example 1:
<c0#><did>
<unittitle>[Title ]
See:
<ref displaytype="present">[Title of target 1], </ref>
<ref displaytype="present">[Title of target 2]. </ref>
</unittitle></did>
</c0#>
Example 2:
<c0#><did>
<unittitle>[Title ]<lb>
See:
<ref displaytype="present">[Title of target 1], </ref>
<ref displaytype="present">[Title of target 2]. </ref>
</unittitle></did>
</c0#>
Example 3:
<c0#><did>
<unittitle>[Title ]<lb>
See:<lb>
<ref displaytype="present">[Title of target 1], </ref><lb>
<ref displaytype="present">[Title of target 2]. </ref><lb>
</unittitle></did>
</c0#>
The difference between the three examples is the use of the <lb> element. The display format for each element will appear as follows:
| Example 1: | [Title ] See: [Title of target 1], [Title of target 2]. |
| Example 2: | [Title ] |
| See: [Title of target 1], [Title of target 2]. | |
| Example 3: | [Title ] |
| See: | |
| [Title of target 1], | |
| [Title of target 2]. |
| Back to Table of Contents |
|
VI. Naming and Declaring Referenced External Entities
A variety of external entities may be referenced from within an <ead> encoded finding
aid. The
following are typical examaples: another <ead> encoded finding aid for a related
collection; a
repository seal on the title page; graphics and sound files for illustrating the history of an agency
or
the biography of an individual; and digital representations of primary resource material
themselves.
Managing individual finding aids and externally referenced entities in a union database will
require
a robust system for naming individual objects (finding aids and the collections they describe as
well
as other objects referenced by the finding aids) and the use of these names in formal declarations
in
the encoded finding aids. This section documents the naming system to be used in the American
Heritage and UCEAD projects; and SGML declaration standards.
A. Naming System.
1. General Naming Conventions.
The naming system in the union database is based on the SGML specification for Formal
Public
Identifiers (ISO 9070), AACR2 chapters 24 and 26, and ISAD(G).
Formal Public Identifiers or FPIs are a formal structure for identifying naming authorities
and
named entities that is independent of the physical format or location of the named entity. A
formal
public identifier has the following elements. Each element of the FPI is specified as to whether it
is
CONSTANT (same in all FPIs) or VARIABLE (changes from naming institution to naming
institution and/or from individual named entity to entity):
The following Public Text Classes may be used in <ead> instances contributed to the
union database:
the word "PUBLIC" in capital letters that indicates to the SGML processor that a
FPI follows. CONSTANT.
a set of double quotation marks indicating the beginning and end of the FPI.
CONSTANT.
a minus sign (-) followed by two forward slashes indicating
that the naming authority
is not registered with an official registering agency. (If the participating institutions
apply to formally register as naming authorities, the minus sign will change to a plus
sign (+). CONSTANT.
the name of the owner or the agency assigning a name to the entity. Double colons
(::) are used to separate hierarchically distinct elements of the name. The subordinate
named division is repeatable. VARIABLE, from one naming agency to another.
separator between name of owner of text and unique name or identifier for the entity.
CONSTANT.
a formal keyword that indicates the text class of the entity. Here the word "text" is
being used in the broad sense that SGML uses it, which is to say, "information
intended for human communication." VARIABLE, depending upon the class of text.
TEXT an SGML document or fragment
DOCUMENT a complete SGML document
NONSGML data not in SGML (the declaration should include an NDATA
specification to describe the data format)
the public text description contains an assigned name or identifier for the entity.
VARIABLE (from unique entity to unique entity).
separator between Public Text Description and Public
Text Language.
CONSTANT.
the language in which the entity is encoded. The two letter language code is to be
taken from ISO
639. VARIABLE, though most frequently "EN" for English.
| Back to Table of Contents |
|
Name of Owner.
The name of the owner is based on the AACR2 (chapter 24) catalog entry form of the name for the repository. If the repository is part of a larger named body, then the name of the parent institution will be prefixed to the name if the name of the parent body is not already part of the catalog entry form of the name. Elements of the name are separated by double colons (::).
Examples:
Duke University::Special Collections Library
Stanford University::Libraries::Dept. of Special Collections
University of California, Berkeley::Library
University of California, Berkeley::Bancroft Library
University of California, Berkeley::Music Library
?University of California, Davis::Library::Dept. Of Special Collections
University of California, Irvine::Library::Dept. of Special Collections
University of California, Irvine::University Archives
University of California, Los Angeles::Library::Dept. of Special Collections
University of California, Los Angeles::Louise M. Darling Biomedical Library::History and
Special
Collections Division
?University of California, Riverside::
University of California, San Diego::Mandeville Special Collections Library
University of California, San Diego::Scripps Institution of Oceanography Archives
?University of California, San Francisco::
?University of California, Santa Barbara::
?University of California, Santa Cruz::
| Back to Table of Contents |
|
2. Categories of Union Finding Aid Database Entities: Naming Conventions
There are three categories of entities comprising the union finding aid database at Berkeley: (1) finding aids; (2) entities referenced by individual finding aids; and (3), general entities referenced by more than one finding aid. Conventions for naming each type of entity will vary, as will responsibility for assigning names.
(a.) Naming Finding Aids.
Responsibility. Responsibility for naming each finding aid will reside with the
individual
institution contributing it to the database. The responsible institution is given in the
Name of
owner::subordinate named division of owner portion of the FPI.
The Public Text Class will always be TEXT for finding aids:
Naming Conventions for the Public Text Description
Note: The unique name or identifier for a finding aid and the archival unit it
describes
will be the same. The identifier is based on International Standard Archival Description
(General) (ISAD(G)).
The identifier will have the following form:
The entire string is contained in parentheses.
Note: The reference code or identifier must be unique within the naming domain of
the
owner of the text, that is, no other finding aid and archival unit can have the same identifier.
The identifier is based on International Standard Archival Description (General) (ISAD(G):
3.1.1). It has been extended in the following way because the local repository reference code
may not be unique or some repositories do not assign reference codes: the title of the archival
unit is appended as a final element.
If no reference code is assigned, the title of the archival unit must be unique in the
repository. If the reference codes are not unique, then the reference code and the title
combined must be unique. If no unit title is given, then the reference code must be unique.
A one-to-one correspondence between the EAD instance and the archival unit is assumed. In
other words, the unique identifier for the EAD instance and the archival unit are one and the
same. If more than one archival unit shares the same identification number and title, or more
than one EAD instance is used to describe one archival unit, then distinguishing information
should be added to the local identification number and/or title.
With the addition of the separator and the language code, the complete FPI will have the
following form:
PUBLIC "-//Name of owner::subordinate named division of
owner//TEXT
(Country code (ISO 3166)::National repository code::local
repository
reference code::Title of archival unit)
left parenthesis indicates the opening of the finding aid/archival unit identifier;
a right parentheis indicates the close of the identifier.
(::) are used to separate hierarchical elements of the identifier or
reference code.
country code ISO
3166 Codes
for the representation of names of countries,
column A2. The country code for the United States is "US". [link to country
code list: http://www.lib.uwaterloo.ca/country_codes.html]
for repositories located in the United States, use the National Union Catalog or
NUC symbol.
typically this will be the local call number or shelf mark, though it may be a bar
code or unique key supplied by a local archival management system.
the title of the archival unit should match exactly the content (though not the
markup) of the <archdesc><did><unittitle>PUBLIC "-//Name of owner::subordinate named division of
owner//TEXT (Country
code (ISO 3166)::National repository code::local repository reference code::Title of
archival unit)//EN"
| Back to Table of Contents |
|
(b.) Naming Entities Referenced by Individual Finding
Aids.
Responsibility. Responsibility for naming all entity or entities referenced
exclusively in an
individual finding aid will reside with the repository contributing the finding aid, provided the
digital referenced entity is under the control of the repository. If one repository's finding aid
references a related finding aid (or digital archival object) from another repository, then naming
responsibility resides with the owner of the referenced entity. The responsible institution is given
in the Name of owner::subordinate named division of owner portion of the
FPI.
If the referenced entity is an SGML encoded document, then the public text class is
TEXT.
If the referenced entity is not encoded in SGML, but uses another notation, then the public
text
class is NONSGML.
Entities referenced by individual finding aids will be of two types: digital archival objects or
related
digital information. Name conventions for the two types of objects will vary.
(1.) Naming <dao>s.
The names of digital archival objects that are items in an archival collection will be based on
the
name of the collection. The Public Text Description for each <dao> name will be expanded
with two
additional elements: the Local repository reference code for the archival
entity; and, optionally,
the Title of archival unit. Note: Because more than one object in a collection
may share the same
title, the Local repository reference code for the item is required, and it is
absolutely essential that
it be unique. The two elements will be separated by double colons (::).
With the addition of the Local repository reference code and
Title of archival unit, the
complete FPI will have the following form:
PUBLIC "-//Name of owner::subordinate named division of
owner//TEXT
PUBLIC "-//Name of owner::subordinate named division of
owner//NONSGML
PUBLIC "-//Name of owner::subordinate named division of
owner//NONSGML
(Country code (ISO 3166)::National repository code::local repository reference
code::Title of archival unit::local respository reference code for item::Title of
item)//EN"
| Back to Table of Contents |
|
| Back to Table of Contents |
|
The following Declaration Subset provides examples of declarations for external entities, including those of Public Text Class TEXT and NONSGML:
<!DOCTYPE EAD PUBLIC "-//Society of American Archivists//DTD ead.dtd
(Encoded Archival Description (EAD))//EN" [
<!ENTITY cutspec PUBLIC "-//University of California,
Berkeley::Library//TEXT (CU union table specifications)//EN">
<!ENTITY genseal PUBLIC "-//Name of owner::subordinate named
division of owner//NONSGML (Unique name of the graphic)//EN" NDATA
GIF>
<!ENTITY hdrnmadd PUBLIC "-//Name of owner//TEXT (eadheader:
name and address)//EN">
<!ENTITY tpnmadd PUBLIC "-//Name of owner//TEXT (titlepage:
name and address)//EN">
]>
<ead> ... </ead>
| Back to Table of Contents |
|
Appendix One: Introduction to the EAD Table Model
The EAD table model used to represent tabular layout in container lists and series descriptions is based on the successful CALS table dtd widely used throughout the publishing industry. This model allows for great flexibility and precision in specifying table geometries. The same table may actually be defined in a number different ways under the EAD (and the CALS) table model. This document will describe the method followed at UC Berkeley, chosen because of its relative ease of use with existing SGML software.
The Berkeley table approach divides the screen into 20 equally spaced columns (the number 20 is somewhat arbitrarily chosen). It is important to note at this point that these 20 columns have no relationship whatsoever to the actual number of "intellectual" columns present in the finding aid. This columnar layout specifies a physical geometry only. It represents a convenient unit of measurement for specifying the widths of the "true" columns found in a finding aid. E.g., a 3-column finding aid may be defined as having a first column which is 3 "widths" wide, a second column which is also 3 "widths" wide and a final column which is 14 "widths" wide.
The screen is divided into 20 equally-spaced columns
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The logical table is then overlayed atop this physical 20-column grid
|
Box |
Folder |
Contents |
|||||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The <tspec> element contains all of the information for laying out this physical grid. It does this through the use of two types of tags: the <colspec>, which defines the underlying physical grid, and the <spanspec>, which defines how the actual table overlays this grid.
Within the Berkeley table model, a <colspec> is defined for each of the twenty columns. Each <colspec> has a name and a width expressed as percentages of total screen width. The name is entered in the colname attribute, the width in the colwidth attribute. The order of the particular column, calculated from left to right, is entered as an integer in the colnum attribute.
<colspec colname="c1" colnum="1" colwidth="5"> <colspec colname="c2" colnum="2" colwidth="5"> etc...
The name of the column needn't be of the form "c1", "c2", etc. You can call them whatever you like. You can also set the widths of the columns to any value you choose:
<colspec colname="column1" colnum="1" colwidth="5"> <colspec colname="secondcolumn" colnum="2" colwidth="14"> <colspec colname="numero3" colnum="3" colwidth="28">
In practice we have found it convenient to adhere to a single naming convention for all finding aids, naming each column with a lower-case "c" followed by the column number, and to make each column of equal width.
Together, these 20 <colspec> tags define the geometry for our invisible table foundation. A corresponding set of <spanspec> tags define how our actual table overlays this foundation. In table terminology, a span is a cell which extends across more than one column.
| c1 | c2 | c3 | c4 | c5 | c6 |
|
|
This cell spans 3 columns |
|
|
||
|
|
|
This cell spans 4 columns |
|||
|
|
|
|
|
|
|
In the EAD table model, each spanning cell is defined in terms of the left-hand column where the cell begins, and the right-hand column where it ends (a cell can span rows as well as columns, but this is not discussed in this document). This information is recorded in the namest and nameend attributes of the <spanspec> tag, respectively. Thus, in our first example of a spanning cell in the previous figure, the 3-column cell begins with column 2 and ends with column 4. The spanspec is expressed as:
<spanspec namest="c2" nameend="c4" spanname="c2-4">
The namest and nameend attributes must refer to colnames previously defined in a <colspec>. However the spanname may be any name you choose:
<spanspec namest="column1" nameend="Numero3" spanname="box">
As with the <colspec>, we have found it convenient to adhere to a single naming convention with respect to all <spanspec>s used in Berkeley finding aids, i.e., a lower-case "c" followed by the spanned column numbers. In this manner, every possible way a cell can span multiple columns (there are over a hundred different possible configurations for a 20-column table) can be identified and assigned a unique name in a <spanspec> tag. In practice, one is likely to find only a couple of dozen different spans within all finding aids.
Once the geometry is specified within the <tspec> element, a container list or series description may refer to specific spanspecs to determine the widths of its various elements. For the 3-column container list presented earlier, one may decide to define the first column (Box) as requiring 15% of the available screen width, the second column (Folder) also as 15%, and the remaining column (Contents) much wider at 70% of total screen width. Each of these three columns is considered a span whose geometry (width, starting point, ending point) is determined in the <spanspec> element having the same spanname. Hierarchical arrangements are expressed as spans with decreasing widths and starting points which shift further and further to the right.
|
Box 3 |
Folder 16 |
Letters to various family member (spanname="c7-20") |
||||||
|
|
|
|
|
|
|
|
Uncle Arthur (spanname="c8-20") |
|
|
|
|
|
|
|
|
|
Aunt Esmeralda (spanname="c8-20") |
|
|
|
|
|
Folder 17 |
|
|
6 letters (1961-1963) (spanname="c9-20") |
||
|
|
|
|
|
|
|
|
|
2 letters (1964-1969) (spanname="c9-20") |
|
|
|
|
|
|
|
|
Endora (spanname="c8-20") |
|
The appropriate spanname is specified within the <dentry> element, thus:
<c02><drow> <dentry spanname="c1-3"> <unitloc>Box 3</unitloc></dentry> <dentry spanname="c4-6"> <unitloc>Folder 16</unitloc></dentry> <dentry spanname="c7-20"> <unittitle>Letters to family members</unittitle> </dentry></drow> <c03><drow> <dentry spanname="c8-20"> <unittitle>Uncle Arthur</unittitle> </dentry></drow></c03> <c03><drow> <dentry spanname="c8-20"> <unittitle>Aunt Esmeralda</unittitle> </dentry></drow> <c04><drow> <dentry spanname="c3-6"> <unitloc>Folder 17</unitloc></dentry> <dentry spanname="c9-20"> <physdesc>6 letters (1961)</physdesc> </dentry></drow></c04> <c04><drow> <dentry spanname="c9-20"> <physdesc>2 letters (1962-1969)</physdesc> </dentry></drow> </c04></c03> <c03><drow> <dentry spanname="c8-20"> <unittitle>Endora</unittitle></dentry> </drow> </c03> </c02>
The corresponding <tspec> would consist of the following:
<tspec> <colspec colname="c1" colnum="1" colwidth="5"> <colspec colname="c2" colnum="2" colwidth="5"> <colspec colname="c3" colnum="3" colwidth="5"> <colspec colname="c4" colnum="4" colwidth="5"> <colspec colname="c5" colnum="5" colwidth="5"> <colspec colname="c6" colnum="6" colwidth="5"> <colspec colname="c7" colnum="7" colwidth="5"> <colspec colname="c8" colnum="8" colwidth="5"> <colspec colname="c9" colnum="9" colwidth="5"> <colspec colname="c10" colnum="10" colwidth="5"> <colspec colname="c11" colnum="11" colwidth="5"> <colspec colname="c12" colnum="12" colwidth="5"> <colspec colname="c13" colnum="13" colwidth="5"> <colspec colname="c14" colnum="14" colwidth="5"> <colspec colname="c15" colnum="15" colwidth="5"> <colspec colname="c16" colnum="16" colwidth="5"> <colspec colname="c17" colnum="17" colwidth="5"> <colspec colname="c18" colnum="18" colwidth="5"> <colspec colname="c19" colnum="19" colwidth="5"> <colspec colname="c20" colnum="20" colwidth="5"> <spanspec spanname="c1-3" namest="c1" nameend="c3"> <spanspec spanname="c4-6" namest="c4" nameend="c6"> <spanspec spanname="c7-20" namest="c7" nameend="c20"> <spanspec spanname="c8-20" namest="c8" nameend="c20"> <spanspec spanname="c9-20" namest="c9" nameend="c20"> </tspec>
This markup contains all of the information needed for the SGML software to go through the many levels of indirection necessary to arrive at values for the final width and location of the dentry element.
|| Home || Project Description || Browse Finding Aids || EAD Home Page || Papers & Documents || SGML Tools || FTP Site || Go to SunSite ||
Copyright ©
1997 UC Regents.
All rights reserved.
Document maintained at http://sunsite.berkeley.edu/amher by gmontoya@library.berkeley.edu
Graphics Credit: Image Map designed and created by Mary Scott.
Last update 04/09/97. SunSITE Manager: manager@sunsite.berkeley.edu