Encoded Archival Description
Retrospective Conversion Guidelines

Australian Research Council RIEF Project:
Australian Literary Manuscript Collections: an Electronic Database of Finding Aids

        Toby Burrows
        Project Director
        Scholars' Centre
        University of Western Australia Library

Updated 13 June, 2000

The original version of these Guidelines was developed for consortia in California, Virginia and New Mexico, and is maintained by:

Daniel V. Pitti
Project Director
Institute for Advanced Technology in the Humanities
University of Virginia

Table of Contents

Introduction

I. EAD HEADER <eadheader>

A. Template

B. Instructions.

EAD Identification <eadid>
File Description <filedesc>
Profile Description <profiledesc>
Revision Description <revisiondesc>

II. Front Matter <frontmatter>

A. Template.

B. Instructions.

III. Archival Description <archdesc>

A. Attributes

B. Overview

Head elements
Subdividing DID-level Elements

C. Descriptive Identification <did>

1. Template.
2. Instructions.

D. Scope and Content <scopecontent>

1. Template.
2. Instructions.

E. Biography/History <bioghist>

1. Template.
2. Instructions.

F. Administrative Information <admininfo>

1. Template.
2. Instructions.

G. Adjunct Descriptive Data <add>

1. Template.
2. Instructions.
Bibliography <bibliography>, Related Material <relatedmaterial>,
and Separated Material <separatedmaterial>
Index <index>

H. Other Descriptive Data <odd>

1. Template.
2. Instructions.

I. Controlled Access <controlaccess>

1. Template.
2. Instructions.

J. Description of Subordinate Components <dsc>

1. General Instructions.
2. Series Description.
3. Nontabular <dsc>
4. Tabular <dsc>
5. Correspondence Lists

IV. General Encoding Instructions

Block and Inline Elements

Attribute Values

<emph> and <title>

Names, Topics, and Dates

<list>

<table>

<note>

V. Hypertext and Hypermedia.

References and Pointers.

External References and Pointers.

VI. Naming and Declaring Referenced External Entities

A. Naming Entities.

1. Naming Finding Aids.
2. Naming Entities Referenced by Individual Finding Aids.
a. Naming <dao>s.
b. Naming Related Digital Information.
3. Naming General Entities.

B. Declaration of Entities.

Appendices

Appendix I. Referencing External File Entities.

Appendix 2. Standards for <controlaccess> Access Points.


Introduction

The Encoded Archival Description Retrospective Conversion Guidelines (EAD/RCG) 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 original EAD/RCG represented the consensus of three consortia: the Online Archive of California, Virginia Heritage, and the Online Archive of New Mexico. This version also incorporates modifications agreed by the Australian RIEF Literary Finding Aids Project partners. Each consortium has as its objective the development of a union database of finding aids contributed by participating repositories.

The EAD/RCG is a supplement to the EAD Tag Library and the EAD Application Guidelines, both published by the Society of American Archivists. As a supplement to the Tag Library and Application Guidelines, the EAD/RCG is intended to be a compatible subset of them. Discrepancies in guidance should be reported to Toby Burrows.

EAD is based on Standard Generalized Markup Language (ISO 8879) and EXtensible Markup Language (W3C), and is in the form of a Document Type Definition (DTD). SGML and XML permit a great deal of flexibility in the representation of information. In order to design a machine-readable representation archival description based on SGML and XML that would meet the needs of the archive and library communities, the developers of EAD first developed design principles for the DTD and related supporting documents.

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 must accommodate a diverse past, it has to be flexible in allowing many different possible types, sequences, and quantities 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 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.

These guidelines attempt to provide predictability and stability through an "acceptable range of uniform practice."



I. EAD HEADER <eadheader>


A. Template

<eadheader audience="internal" langencoding="ISO 639-2"
  findaidstatus="unverified-full-draft"> 
  <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> 
  <filedesc> 
    [SEE BELOW]
  </filedesc> 
  <profiledesc>
    [SEE BELOW]
  </profiledesc> 
  <revisiondesc> 
    [SEE BELOW]
  </revisiondesc> 
</eadheader>


B. Instructions.

<eadheader audience="internal" langencoding="ISO 639-2"
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-2." [required]

Language encoding in the EAD instance will subscribe to the three letter bibliographic ISO 639-2 language codes.. A language code is entered 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:

  • "unverified-partial-draft"
  • "unverified-full-draft"
  • "edited-partial-draft"
  • "edited-full-draft."

The adjectives "partial" and "full" can be confusing. "Partial" and "full" do not refer to the depth of analysis, but to whether the intended analysis, whatever its depth, has been "partially" or "fully" completed. 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.


EAD Identification <eadid>
<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> 

As a conforming SGML Open Catalog entry, the <eadid> can be used directly in an SGML catalog file.

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 consortium site should have the same name.


File Description <filedesc>
<filedesc> 
  <titlestmt> 
    <titleproper>[Guide to the]
      REQUIRED TITLE PROPER 
     </titleproper> 
    <author>Prepared by [staff/name]</author> 
  </titlestmt> 
  <publicationstmt> 
    <publisher>[Name of repository]</publisher> 
    <address> 
      <addressline>[Address of repository]</addressline> 
    </address> 
    <date>&copy;[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 ..." or "A Guide to the ..." If the finding aid is not a register or inventory or guide, then use an appropriate descriptive phrase is appropriate.

<author> is required if available. The content of the <author> element in <titlestmt> should be the name of the individual responsible for the intellectual content of the finding aid. Encode the name of the individual responsible for the SGML encoding within <creation>.

Note: 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 encode the person's name within the <author> element and again within the <creation>.

The name and address of the repository are required. The name and complete address must be entered in the <publicationstmt>. A complete address includes the following: postal address, phone and fax numbers, email address, and optional URL for the repository homepage.

The name and address of the repository will be stored as a separate referenced file that can be shared by all finding aids of one institution. Please see Appendix I. Referencing External Entity Files.
 

The formal copyright statement for the finding aid is given in the <publicationstmt><date> and the <p> following the <date>. The "&copy;" is the ISO character entity for the copyright symbol.

 


Profile Description <profiledesc>
<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] 
  [Text converted and initial EAD tagging provided by Apex Data
   Services, 
   <date>[Date received from Apex]</date>] [Date of source: 
   <date>.</date>]. Machine-readable finding aid created by
   [staff/name]</creation> 
 <langusage>Description is in <language>English.</language> 
 </langusage> 
</profiledesc>

The <profiledesc><creation> element provides information concerning the format of the original, the method or methods of conversion, the date of the conversion, and the individual responsible for 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.


Revision Description <revisiondesc>
<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.



II. Front Matter <frontmatter>

A. Template.

<frontmatter> 
 <titlepage>
  <num>Reference number: </num>  
  <titleproper>[Guide to the]
    REQUIRED TITLE PROPER 
    </titleproper> 
  <publisher>Repository name 
  	<lb><extptr actuate="auto" show="embed" 
         entityref="[your logo entity]">
    	<lb>Additional element of repository name 
	<lb>Place of publication
  </publisher> 
  <date>Publication date</date> 
  &[your address entity]; 
  <list type="deflist"> 
    <defitem> 
     <label>Prepared by: </label> 
     <item>[name of person or staff unit]</item> 
    </defitem> 
    <defitem> 
     <label>Date completed: </label> 
     <item> 
      <date>2000</date></item> 
    </defitem> 
    <defitem> 
     <label>Encoded by: </label> 
     <item>[name of person or staff unit]</item> 
    </defitem> 
  </list> 
    <p>This finding aid is published as part of the Australian Literary   
    Manuscript Collections Project, which has received funding from the 
    Australian Research Council's Research Infrastructure Equipment and 
    Facilities (RIEF) Scheme.</p>
  <p>&copy;2000 [Copyright holder.] All rights reserved.</p> 
 </titlepage> 
</frontmatter>


B. Instructions.

While the <frontmatter> is an optional element in EAD, it is required for the consortium participants.

The following are required, and in the order presented: <titlepage>, <num> ,<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>. The contributing repository  will include its institutional logo,which will be placed at the top of the title page. A referenced graphic must be declared in the declaration subset of the EAD instance. For this project, the entity reference must be the same as the stem of the filename (ie, minus the '.gif'). Please see the section Naming and Declaring Referenced External Entities for instructions concerning the declaration of entities. The <extptr> element should be used for referencing the graphic file of the logo. The ACTUATE and SHOW attributes should have the values "auto" and "embed" supplied, respectively, to signal the software that the graphic is to be present and 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. 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 repository's Home Page may also be given.

The name and address of the repository will be stored as a separate referenced file that can be shared by all finding aids from one institution. Please see Appendix I. Referencing External Entity Files.

The funding credit is required. The funding credit wording was approved in August 2000.



III. Archival Description <archdesc>


A. Attributes

The LEVEL attribute on <archdesc> is required by the DTD and thus must be set for the document to parse. Select one of the following available values:

  • collection
  • file
  • fonds
  • item
  • recordgrp
  • subgrp
  • subseries
  • series

Alternatively, if none of the values are appropriate, select "otherlevel" and provide the appropriate value in the OTHERLEVEL attribute.

The LANGMATERIAL (language of the archival materials) values should be set using the three letter bibliographic codes for the appropriate language from ISO 639-2, Code for the representation of names of languages.

Examples:

<archdesc level="collection" langmaterial="eng">

<archdesc level="otherlevel" otherlevel="class" langmaterial="fre">


B. Overview

The following elements are directly available in <archdesc>:

<did> Descriptive Identification
<scopecontent> Scope and Content
<arrangement> Arrangement
<organization> Organization
<bioghist> Biography/History
<admininfo> Adminstrative Information
<add> Adjunct Descriptive Data
<controlaccess> Controlled Access
<odd> Other Descriptive Data
<dsc> Description of Subordinate Components

<did> is required and must occur before the other elements. The other elements are collectively referred to as the "did-level elements." They technically can occur in any order and as many times as necessary.

All did-level elements except <odd> represent distinct categories of archival description. Each contains subelements representing specific, logical components of the parent element's descriptive category. Guidance in use of the subelements specific to or primarily used in each did-level element will be given under each parent element.

All did-level elements also contain general structural elements such as p, list, and table. Guidance in use of these elements is provided in General Encoding Instructions.


Head elements

<head> is required on all <admininfo>, <bioghist>, <controlaccess>, <scopecontent>, <organization>, <arrangement>, <add>, and <odd>, and on all major subdivisions within each element. However <head> may be omitted within an <add> if each of its subcomponents contain their own <head>s.


Subdividing DID-level Elements

Under some circumstances, it may be necessary to subdivide the did-level elements into sections. For this purpose, each of these elements can contain itself. An example of such subdivision is provided under <bioghist>. The <head> element should be used on all did-level elements used to subdivide their parent into sections.


C. Descriptive Identification <did>


1. Template.
<did>
  <head>Summary</head>
  <origination label="[Creator or Collector]">
  </origination>    
  <unittitle label="Title"></unittitle> 
  <unitdate label="Date range"> </unitdate>
  <unitid label="Reference number"></unitid>
  <physdesc label="Extent"></physdesc>
  <repository label="Repository">
    <corpname>Repository name</corpname>
    <address>
     <addressline>Repository address</addressline>
    </address> </repository>
  <physloc label="Location"></physloc>
  <abstract label="Abstract"></abstract>
</did>


2. 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 Comments
<head> R Summary  
<origination> R Creator  or
Collector
Use AACR2 for form of name
<unittitle> R Title  
<unitdate> RA Date Range  
<unitid> R Reference number  
<physdesc> R Extent  
<extent> NR    
<repository> R Repository Use AACR2 for form of name
<physloc> NR Location  
<abstract> NR Abstract Recommended
<note> NR [as appropriate to descriptive content]  

<unitdate> should be used as an element directly within <did>, not within the <unittitle>. Set its TYPE attribute to the appropriate value: "bulk", "inclusive", or "single". Optionally, dates may also be included in <unittitle>, either as text or by using the <date> tag.

In <origination> within <archdesc>, personal names (<persname>), corporate names (<corpname>), and family names (<famname>) are to be encoded. Use catalogue entry (AACR2) form.

Within <repository>, encode the corporate name (<corpname>) of the repository in catalogue entry (AACR2)  form. If the name is preceded by an article, encode as follows: <repository>The <corpname>Repository Name</corpname></repository>

Use <physloc> to describe the physical location of the materials within the repository or within a storage facility. Examples include shelf locations, locked vaults or specific or generic text which describes locations in external storage facilities.

If describing physical containment information, such as a range of specific box or folder numbers, use <container>. Within a <container> element the TYPE attribute must be set to an appropriate value selected from the following list:

  • carton
  • box
  • folder
  • reel
  • frame
  • oversize
  • reel-frame
  • volume
  • map-case
  • box-folder
  • page
  • folio
  • othertype

Give the value "othertype" if none of the given values is appropriate, and provide the appropriate value in the OTHERTYPE attribute.


D. Scope and Content <scopecontent>

1. Template.
<scopecontent>
  <head>Scope and Content</head>
  <p></p>
  <organization>
    <head>Organization</head>
    <p></p>
  </organization>
  <arrangement>
    <head>Arrangement</head>
    <p></p>
  </arrangement>
</scopecontent>


2. Instructions.

Use <head> on <scopecontent> and, if they are supplied, <organization> and <arrangement>.  Use 'Organization' for <organization> and 'Arrangement' for <arrangement>, bearing in mind the distinction between them (see Tag Library and USMARC standard for field 351).


E. Biography/History <bioghist>

1. Template.
<bioghist>
  <head>Biographical Note</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>


2. Instructions.

Use <head> on <bioghist>.

For family papers and for complex agency histories it may be desirable to subdivide <bioghist> into separate sections, each with its own <head> element. The following is a truncated example of subdivision for a family history.

Example:

 
<bioghist>
  <head>Family History</head> 
  <p>The Jefferson family originally settled in 
     Virginia in .... </p> 
  <bioghist> 
    <head>Peter Jefferson</head> 
    <p>Peter Jefferson ....</p> 
  </bioghist> 
  <bioghist> 
    <head>Thomas Jefferson</head> 
    <p>Thomas Jefferson ....</p> 
  </bioghist> 
</bioghist>


F. Administrative Information <admininfo>

1. Template.
 
<admininfo> 
  <head>Administrative Information</head> 
  <accessrestrict> 
    <head>Access</head> 
    <p>Collection is open [closed] to research 
       [until <date> </date>].</p> 
  </accessrestrict> 
  <userestrict> 
    <head>Restrictions on Use</head> 
    <p>Copyright ....</p> 
  </userestrict> 
  <prefercite> 
    <head>Preferred Citation</head> 
    <p>[Identification of item], [collection name], 
       [collection number], [repository name].</p> 
  </prefercite> 
</admininfo>


2. Instructions.

Note that only <accessrestrict>, <userestrict>, and <prefercite> are given in the template above. Each of these elements is required, even if the content of <accessrestrict> and <userestrict> is the same for all finding aids from a given repository. The following is a complete list of the subelements representing specific categories of administrative information are availble directly in <admininfo>. Use of each, with the exceptions noted above, is optional.

element heading
<accessrestrict> Access
<accruals> Accruals
<acqinfo> Provenance
<altformavail> Alternative Form Available
<appraisal> Appraisal Information
<custodhist> Custodial History
<prefercite> Preferred Citation
<processinfo> Processing Information
<userestrict> Restrictions on Use

Replace all bracketed information in <prefercite> except the "identification of item" with the approriate information for the unit being described.


G. Adjunct Descriptive Data <add>

1. Template.
<add> 
  <head>Additional Information</head> 
  <relatedmaterial> 
    <head>Related Material</head> 
    <p></p> 
    <archref> 
     <unittitle>[Title], 
      <unitdate> [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> 
        <addressline>[Repository address 2].
        </addressline> 
      </address> </repository> </archref> 
    <archref> 
     <unittitle>[Title], 
      <unitdate> [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> 
        <addressline>[Repository address 2].
        </addressline> 
      </address> </repository> </archref> 
  </relatedmaterial> 
  <separatedmaterial> 
    <head>Separated Material</head> 
    <p></p> 
    <bibref> [Author]. 
     <title>[Title]. </title>[Place]: 
      [Publisher name], [Date]. [page numbers]. 
    </bibref><bibref> [Author]. 
     <title>[Title]. </title>[Place]: [Publisher 
      name], [Date]. [page numbers]. </bibref> 
  </separatedmaterial> 
  <bibliography> 
    <head>Bibliography</head> 
    <p></p> 
    <bibref> [Author]. 
     <title>[Title]. </title>[Place]: 
       [Publisher name], [Date]. [page numbers]. 
    </bibref> 
    <bibref> [Author]. 
     <title>[Title]. </title>[Place]: [Publisher 
      name], [Date]. [page numbers]. </bibref> 
  </bibliography> 
  <fileplan> 
    <head>File Plan</head> 
    <p></p> 
  </fileplan> 
  <otherfindaid> 
    <head>Other Finding Aid</head> 
    <p></p> 
    <archref> 
     <unittitle>[Title], 
      <unitdate> [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> 
        <addressline>[Repository address 2].
        </addressline> 
      </address> </repository> </archref> 
  </otherfindaid> 
  <index> 
    <head>Index</head> 
    <p></p> 
    <indexentry> 
     <persname>[Surname, Forename]</persname> 
     <ref target="idoftarget">[location]</ref> 
    </indexentry> 
  </index> 
</add>


2. Instructions.

The following descriptive subelements are available directly in <add>:

<bibliography> Bibliography
<fileplan> File Plan
<index> Index
<otherfindaid> Other Finding Aid
<relatedmaterial> Related Material
<separatedmaterial> Separated Material

Bibliography <bibliography>, Related Material <relatedmaterial>, and Separated Material <separatedmaterial>

Two special referencing elements, <bibref> and <archref>, are directly available in <bibliography>, <relatedmaterial>, and <separatedmaterial>. They are also indirectly available in the general textual elements in these elements as well. <bibref> and <archref> should be used directly within <bibliography>, <relatedmaterial>, and <separatedmaterial> when the intention is to provide a list of references. Specific instructions on the use of <bibref> and <archref> are given under General Encoding Instructions.


Index <index>

<index> is used to supply access point not otherwise provided in the description. Each <indexentry> provides a means to "point" specific entries in a series description or container list. If material related to a particular access point can be found in more than one location, use <ptrgrp> to group them together: Example:

 
<index>
  <head>Index</head>
  <indexentry>
    <persname>Albright, Horace Marden, 1890-</persname>
    <ptrgrp>
      <ref target="c1925>Correspondence, 1925-1930, </ref> 
      <ref target="c1931>Correspondence, 1931-1945</ref> 
    </ptrgrp> 
  </indexentry> 
  <indexentry> 
    <persname>Alcott, Louisa May</persname> 
    <ptrgrp> 
      <ref target="c1925>Correspondence, 1925-1930, </ref> 
      <ref target="c1946>Correspondence, 1946-1950</ref> 
    </ptrgrp> 
  </indexentry> 
</index>


H. Other Descriptive Data <odd>


1. Template.
<odd>
  <head>Abstract [use for mixed content description]</head>
                 [use other heading as appropriate to content]
  <p></p>
</odd>


2. Instructions.

<odd> provides for encoding descriptive data that is not classified easily in one of the other did-level elements and for encoding mixed data that is not easily or efficiently segregated into one of the other did-level elements.

In existing finding aids, the specific kinds of descriptive data that logically would be contained in one of did-level descriptive elements may be difficult to identify and encode separtely. Finding aids predating MARC AMC frequently mixed descriptive information of different types in one descriptive block, or even in one sentence.

In order to facilitate efficient conversion of existing finding aids, such mixed descriptive blocks should be encoded using the <odd> element, without further distinction of content elements. Where significant blocks of descriptive information are easily identified as falling into a particular descriptive element, such blocks should be encoded using the appropriate element.


I. Controlled Access <controlaccess>


1. Template.

Undifferentiated List

<controlaccess>
  <head>Access Terms</head>
  <famname>[name] Family</famname>
  <persname>[surname, forename]</persname>
  <subject>[subject]</subject>
  <title>[title]</title>
  <corpname>[corporate name]</corpname>
  <function>[function]</function>
  <genreform>[genre or form term]</genreform>
  <geogname>[geographical name]</geogname>
  <occupation>[occupation]</occupation>
</controlaccess>

Differentiated List

<controlaccess> 
  <head>Access Terms</head> 
  <controlaccess> 
    <head>Family Names</head> 
    <famname>[name] Family</famname> 
    <famname>[name] Family</famname> 
  </controlaccess> 
  <controlaccess> 
    <head>Personal Names</head> 
    <persname>[surname, forename]</persname> 
    <persname>[surname, forename]</persname> 
  </controlaccess> 
  <controlaccess> 
    <head>Topical Subjects</head> 
    <subject>[subject]</subject> 
    <subject>[subject]</subject> 
  </controlaccess> 
  <controlaccess> 
    <head>Titles</head> 
    <title>[title]</title> 
    <title>[title]</title> 
  </controlaccess> 
  <controlaccess> 
    <head>Corporate Names</head> 
    <corpname>[corporate name]</corpname> 
    <geogname>[government name]</geogname> 
  </controlaccess> 
  <controlaccess> 
    <head>Functions</head> 
    <function>[function]</function> 
    <function>[function]</function> 
  </controlaccess> 
  <controlaccess> 
    <head>Genre and Form Terms</head> 
    <genreform>[genre or form term]</genreform> 
    <genreform>[genre or form term]</genreform> 
  </controlaccess> 
  <controlaccess> 
    <head>Geographical Names</head> 
    <geogname>[geographical name]</geogname> 
    <geogname>[geographical name]</geogname> 
  </controlaccess> 
  <controlaccess> 
    <head>Occupations</head> 
    <occupation>[occupation]</occupation> 
    <occupation>[occupation]</occupation> 
  </controlaccess> 
</controlaccess> 


2. Instructions.

The following elements are directly available in <controlaccess> for the purpose of creating lists of names, titles, and terms:

<corpname> Corporate name
<famname> Family name
<function> Function
<genreform> Genre/Form terms
<geogname> Geographic name
<occupation> Occupation
<persname> Personal name
<subject> Subject terms
<title> Uniform title

<name> is also directly available, though its use is discouraged because of its lack of specificity.

Lists of corporate names, family names, personal names, etc., can be given as one undifferentiated list. For short lists, this is the recommended method. Each category can also be given its own section with <head> element. This method is recommended for longer lists. A combination of the two approaches is also possible. For example, a finding aid may have long lists of personal names and subject terms, but only a few functions, occupations, etc. The first two can be grouped in their own sections using a <controlaccess> subelement for each, with the remainder grouped in one <controlaccess> subelement with the <head> "Other Terms."

Introductory text or instructions on interpretation and use of <controlaccess> can be given before the list using <p> and other general structural elements.<.p>

Note: The <list> element should not be used to create lists of names, titles, and terms in <controlaccess>. Use <list> only for other lists that may occur in <controlaccess>.

Standards for access points in <controlaccess> are given in Appendix 2.


J. Description of Subordinate Components <dsc>

1. General Instructions.

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>), and descriptions that intermix series description and container lists. Templates for each use of the <dsc> are provided below.

Attributes

The TYPE attribute in the <dsc> is used to specify each type of description. The TYPE attribute offers four values:

analyticover series descriptions
in-depth container lists
combined mixed series descriptions and container lists
othertype other analytic descriptive types, enter type in OTHERTYPE attribute

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 additional types to the community for discussion. There must be community-wide consensus before new types are added to the list.

Authorized OTHERTYPE values:

correspondence partial lists of correspondents

<head>

The <head> element is required on all <dsc>s.

<c01> ... <c12>

While either the enumerative <c01> ... <c12> or the recursive <c>s can be used for the description of subordinate components, all component descriptions in the consortium project 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.  A better rationale is for use in searching.


Use of <c01> ... <c12>

<unittitle> 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]

<container> When using <container> to describe the physical containment of components within the container list, the TYPE attribute must be set to an appropriate value from the list below:

  • carton
  • box
  • folder
  • reel
  • frame
  • oversize
  • reel-frame
  • volume
  • map-case
  • box-folder
  • page
  • folio
  • othertype


Tabular versus Non-Tabular <dsc>

Both tabular or non-tabular <dsc>s are possible when creating Container Lists and combined Series Descriptions and Container Lists. A tabular <dsc> makes use of the elements <tspec> and <drow> and enables a highly controlled tabular layout. <drow> is used instead of <did> and <did>-level elements; <drow> contains all of the <did> and <did>-level elements. The nontabular <dsc> does not use either of these two elements. It is possible to render the most common types of container lists as tables when using the nontabular approach, though complex renderings are difficult to achieve in individual instances, and even more difficult to maintain for a large body of finding aids. With the emergence of XML and XSL, the need to use <tspec> and <drow> for complex layout is likely to disappear, though some modifications of EAD will probably be necessary.

Most Consortial participants will use nontabular <dsc>s. The following instructions are for the nontabular <dsc>. For specific instructions on nontabular-<dsc>, see Nontabular-<dsc> below. For specific instructions on tabular-<dsc>, see Tabular-<dsc> below.


2. Series Description.

Template

<dsc type="analyticover"> 
  <head>[Series Description]</head> 
  <c01 level="series"> 
    <head>[Series Head]</head> 
    <did> 
     <unittitle>[Title], 
      <unitdate> [Date or date
        range]</unitdate>
     </unittitle> 
    </did> 
    <scopecontent> 
     <p>...</p> 
    </scopecontent> 
    <c02 level="subseries"> 
      <head>[Subseries Head]</head> 
      <did> 
        <unittitle>[Title], 
          <unitdate> [Date or date
           range]</unitdate>
        </unittitle> 
      </did> 
      <scopecontent> 
        <p>...</p> 
      </scopecontent> 
    </c02> 
  </c01> 
</dsc>


3. Nontabular <dsc>

Nontabular Container List Template

<dsc type="in-depth"> 
  <head>[Container List ]</head> 
  <c01 level="series"> 
    <head>[Series Head]</head> 
    <did> 
     <unittitle>[Title], 
      <unitdate> [Date or date
        range]</unitdate>
     </unittitle> 
    </did> 
    <c02 level="subseries"> 
     <head>[Subseries Head]</head> 
     <did> 
      <unittitle>[Title], 
        <unitdate> [Date or date
         range]</unitdate>
      </unittitle> 
     </did> 
     <c03> 
      <did> 
        <container type="box"></container> 
        <container type="folder"></container> 
        <unittitle>[Title], 
         <unitdate>[Date or date range]</unitdate>
        </unittitle> 
      </did> 
      <c04> 
        <did> 
         <container type="box"></container> 
         <container type="folder"></container> 
         <unittitle>[Title], 
          <unitdate>[Date or date range]</unitdate>
         </unittitle> 
        </did> 
      </c04> 
     </c03> 
     <c03> 
      <did> 
        <container type="box"></container> 
        <container type="folder"></container> 
        <unittitle>[Title], 
         <unitdate>[Date or date range]</unitdate>
        </unittitle> 
      </did> 
      <c04> 
        <did> 
         <container type="box"></container> 
         <container type="folder"></container> 
         <unittitle>[Title], 
          <unitdate>[Date or date range]</unitdate>
         </unittitle> 
        </did> 
      </c04> 
     </c03> 
    </c02> 
  </c01> 
</dsc> 

Nontabular Series Description/Container List

<dsc type="combined"> 
  <head>[Series Description/Container List ]</head> 
  <c01 level="series"> 
    <head>[Series Head]</head> 
    <did> 
     <unittitle>[Title], 
      <unitdate> [Date or date
        range]</unitdate>
     </unittitle> 
    </did> 
    <scopecontent> 
     <p></p> 
    </scopecontent> 
    <c02 level="subseries"> 
     <head>[Subseries Head]</head> 
     <did> 
      <unittitle>[Title], 
        <unitdate> [Date or date
         range]</unitdate>
      </unittitle> 
     </did> 
     <scopecontent> 
      <p></p> 
     </scopecontent> 
     <c03> 
      <did> 
        <container type="box"> </container> 
        <container type="folder"></container> 
        <unittitle>[Title], 
         <unitdate>[Date or date range]</unitdate>
        </unittitle> 
      </did> 
      <c04> 
        <did> 
         <container type="box"></container> 
         <container type="folder"></container> 
         <unittitle>[Title], 
          <unitdate>[Date or date range]</unitdate>
         </unittitle> 
        </did> 
      </c04> 
     </c03> 
     <c03> 
      <did> 
        <container type="box"></container> 
        <container type="folder"></container> 
        <unittitle>[Title], 
         <unitdate>[Date or date range]</unitdate>
        </unittitle> 
      </did> 
      <c04> 
        <did> 
         <container type="box"></container> 
         <container type="folder"></container> 
         <unittitle>[Title], 
          <unitdate>[Date or date range]</unitdate>
         </unittitle> 
        </did> 
      </c04> 
     </c03> 
    </c02> 
  </c01> 
</dsc>


4. Tabular <dsc>

Tabular Container List Template

<dsc type="in-depth">
  <head>[Container List]</head>
  &cutspec;
  <c01 level="series">
    <head>[Series Head]</head>
    <did>
     <unittitle>[Title],
      <unitdate> [Date or date
        range]</unitdate>
     </unittitle>
    </did>
    <c02 level="subseries">
     <head>[Subseries Head]</head>
     <did>
      <unittitle>[Title],
        <unitdate> [Date or date
         range]</unitdate>
      </unittitle>
     </did>
     <thead>
      <row>
        <entry spanname="c1-3">Box</entry>
        <entry spanname="c4-6">Folder</entry>
        <entry spanname="c7-20">[Contents]</entry>
      </row>
     </thead>
     <c03>
      <drow>
        <dentry spanname="c1-3">
         <container type="box"></container>
        </dentry>
        <dentry spanname="c4-6">
         <container type="folder"></container>
        </dentry>
        <dentry spanname="c7-20">
         <unittitle>[Title],
          <unitdate>[Date or date range]</unitdate>
         </unittitle>
        </dentry>
      </drow>
      <c04>
        <drow>
         <dentry spanname="c1-3">
          <container type="box"></container>
         </dentry>
         <dentry spanname="c4-6">
          <container type="folder"></container>
         </dentry>
         <dentry spanname="c8-20">
          <unittitle>[Title], 
            <unitdate>[Date or date range]</unitdate> 
          </unittitle>
         </dentry>
        </drow>
      </c04>
     </c03>
     <c03>
      <drow>
        <dentry spanname="c1-3">
         <container type="box"></container>
        </dentry>
        <dentry spanname="c4-6">
         <container type="folder"></container>
        </dentry>
        <dentry spanname="c7-20">
         <unittitle>[Title], 
          <unitdate>[Date or date range]</unitdate>
         </unittitle>
        </dentry>
      </drow>
      <c04>
        <drow>
         <dentry spanname="c1-3">
          <container type="box"></container>
         </dentry>
         <dentry spanname="c4-6">
          <container type="folder"></container>
         </dentry>
         <dentry spanname="c8-20">
          <unittitle>[Title], 
            <unitdate>[Date or date range]</unitdate>
          </unittitle>
         </dentry>
        </drow>
      </c04>
     </c03>
    </c02>
  </c01>
 </dsc>

Tabular Series Description/Container List Template

<dsc type="combined">
  <head>[Series Description/Container List]</head>
  &cutspec;
  <c01 level="series">
    <head>[Series Head]</head>
    <did>
     <unittitle>[Title], 
      <unitdate> [Date or date
        range]</unitdate></unittitle>
    </did>
    <scopecontent>
     <p>...</p>
    </scopecontent>
    <c02 level="subseries">
     <head>[Subseries Head]</head>
     <did>
      <unittitle>[Title], 
        <unitdate> [Date or date
         range]</unitdate></unittitle>
     </did>
     <scopecontent>
      <p>...</p>
     </scopecontent>
     <thead>
      <row>
        <entry spanname="c1-3">Box</entry>
        <entry spanname="c4-6">Folder</entry>
        <entry spanname="c7-20">[Contents]</entry>
      </row>
     </thead>
     <c03>
      <drow>
        <dentry spanname="c1-3">
         <container type="box"></container>
        </dentry>
        <dentry spanname="c4-6">
         <container type="folder"></container>
        </dentry>
        <dentry spanname="c7-20">
         <unittitle>[Title], 
          <unitdate>[Date or date range]</unitdate> </unittitle>
        </dentry>
      </drow>
      <c04>
        <drow>
         <dentry spanname="c1-3">
          <container type="box"></container>
         </dentry>
         <dentry spanname="c4-6">
          <container type="folder"></container>
         </dentry>
         <dentry spanname="c8-20">
          <unittitle>[Title], 
            <unitdate>[Date or date range]</unitdate> </unittitle>
         </dentry>
        </drow>
      </c04>
     </c03>
     <c03>
      <drow>
        <dentry spanname="c1-3">
         <container type="box"></container>
        </dentry>
        <dentry spanname="c4-6">
         <container type="folder"></container>
        </dentry>
        <dentry spanname="c7-20">
         <unittitle>[Title], 
          <unitdate>[Date or date range]</unitdate> </unittitle>
        </dentry>
      </drow>
      <c04>
        <drow>
         <dentry spanname="c1-3">
          <container type="box"></container>
         </dentry>
         <dentry spanname="c4-6">
          <container type="folder"></container>
         </dentry>
         <dentry spanname="c8-20">
          <unittitle>[Title], 
            <unitdate>[Date or date range]</unitdate> </unittitle>
         </dentry>
        </drow>
      </c04>
     </c03>
    </c02>
  </c01>
</dsc> 


5. Correspondence Lists

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> 



IV. General Encoding Instructions


Block and Inline Elements

For formatting purposes, all elements in <ead> that are intended for display can be classified as either "block" or "inline" elements. "Block" and "inline" describe display characteristics. Block elements are characterized by have a linebreak before and after them (and sometimes additional space) to separate them from the elements that precede and follow them. For example, all of the did-level elements when they occur directly within the <archdesc> are separated from one another by linebreaks and spacing. <head> elements are always treated as block elements, in order that each occupies its own line. Inline elements are characterized by not having linebreaks before and after them, that is, they occur "inline" with text and elements that precede and follow them. For example, most of the elements within <p> are displayed inline. Note that some elements may be treated as inline or block, depending upon the element which contains them. For example, <persname>, when it occurs inside of a <p> is treated as an inline element, but when it occurs directly inside <controlaccess>, it is treated as a block element in order that the controlled access headings can be displayed as a list. Understanding the contexts when elements are inline and block has important implications word spacing.

Word Spacing and Inline Elements

For all inline elements within block elements, spacing may be supplied either within the preceding element or following the element with two exceptions: when using the <emph> and <title> elements with the RENDER attribute set to "quoted", always place the space separating the word from the word that follows after the <emph> or <title> element.

Inline and Block Quotes

[Text description and template to be supplied]


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 usually supplied automatically.


<emph> and <title>

Both the <emph> and <title> elements have a RENDER attribute with a controlled list of styles. To facilitate economic encoding, all <emph> will be rendered as bold and <title> elements will rendered as italic when the RENDER attribute is not set to a specific value.

The RENDER attribute values are given in the following list:

  • altrender
  • bold [implied for <emph> ]
  • bolditalic
  • boldquoted
  • boldsmcaps
  • boldunderline
  • italic [implied for <title>]
  • nonproport
  • quoted [use keyboard double quotes (")]
  • smcaps
  • sub
  • super
  • underline

Quoted Titles

It is highly recommended that quoted titles are encoded using <title render="quoted"> to to facilitate searching of titles. Note: If the encoded text has double quotes (") in the text, this will need to be removed, otherwise it will lead to two sets of quotes around the title. Search and replace can be used to accomplish this, if done carefully.

Alternatively, if removing the double quote (") is deemed too time consuming, then simply leave double quotes and forgo encoding the title using the <title> element.


Names, Topics, and Dates

Names, topics, and dates are to be encoded where specified in these guidelines. More detailed tagging of names, topics, and dates is at the discretion of individual repositories.


<list>

<list> can be used in four ways, each use being specified in the TYPE attribute according to one of the following values:

simple list of words or phrases
deflist definition list: list of labels paired with words or phrases
marked list with a bullet
ordered enumerated or alphabetically arranged list of words or phrases

Simple List

<list type="simple">
  <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>

Definition List

<list type="deflist">
  <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>

Marked List

[Template to be supplied]

Numbered or Alphabetic List

[Template to be supplied]


<table>

The <table> element is a subset of the CALS table DTD.

<table> 
  <tgroup cols="3"> 
   <thead> 
    <row> 
      <entry>[head 1]</entry> 
      <entry>[head 2]</entry> 
      <entry>[head 3]</entry> 
    </row> 
   </thead> 
   <tbody> 
    <row> 
      <entry>[text]</entry> 
      <entry>[text]</entry> 
      <entry>[text]</entry> 
    </row> 
    <row> 
      <entry>[text]</entry> 
      <entry>[text]</entry> 
      <entry>[text]</entry> 
    </row> 
   </tbody> 
  </tgroup> 
</table>


<note>

The <note> element should only be used as follows:

The <note> needs much more work, especially on use as a footnote

  • Notes about the finding aid, as opposed to information describing the archival material. Typically these notes will be intended for internal use only, and when so used, set the AUDIENCE attribute to "internal". Structurally, all displayed <note>s are treated as block elements.
  • <note> should only be used to wrap archival description (as opposed to annotations about the text or internal control notes not intended for the public) in the top level <did> (directly in the <archdesc>), e.g., for information that is not logically contained in another element in the <did>. When used in the top level <did>, use the LABEL attribute to supply a label or head for the descriptive information given in the note. Use of <note> in the <did> should be limited.
  • Do not use <note> in <c01>...<c12> except for annotations or internal control notes. Use instead the appropriate descriptive element, e.g. <scopecontent>, or when the information is mixed or ambiguous, use <odd>.



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 share the attributes ACTUATE and SHOW. There are two possible values for ACTUATE:

  • auto
  • user

This attribute must be set to "auto" for references that the author wants displayed automatically; and to "user" for references that will be represented by an icon or thumbnail image.

There are three possible values for SHOW:

  • embed
  • new
  • replace

This attribute must be set to "embed" for references that appear at the point of the link, to "new" for references that appear in a new window, and to "replace" for references which replace the local resource which initiated the link.

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

NOTE: In the RIEF project, the Entity Name must be the same as the file name, without '.gif' on the end, as in the following example:

Declaration:

<!ENTITY genlogo PUBLIC "-//Name of owner::subordinate named 
    division of owner//NONSGML (Unique name of the graphic)//EN" 
    "genlogo.gif" NDATA GIF>

Element:

 <extptr actuate="auto" show="embed" entityref="genlogo">

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

<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. When such multiple resolutions of the viewing files are used, encode each resolution using a separate <daoloc> element within a parent <daogrp>. Do not use <dao>. Additionally include an <!ENTITY> declaration for each resolution of the viewing file within the DTD subset at the beginning of the finding aid.

Use <unittitle> to encode caption information instead of <daodesc>. <daodesc> should be used to encode visual descriptions of the images to be used by the vision-impaired.

Tabular display.

Note that more than one <dao> or <daogrp> may be encoded within a <dentry>, for example, if a <c0#> describes a folder containing two pictures.

<dsc type="in-depth"> 
  <head>[Container List]</head>
  &cutspec;
  <c01 level="series"> 
    <head>[Series Head]</head> 
    <did> 
     <unittitle>[Title], 
      <unitdate>[Date or date
        range]</unitdate>
     </unittitle> 
    </did> 
    <c02 level="subseries"> 
     <head>[Subseries Head]</head> 
     <did> 
      <unittitle>[Title], 
        <unitdate> [Date or date range]</unitdate>
      </unittitle> 
     </did> 
     <thead>
      <row>
        <entry spanname="c1-3">Box</entry> 
        <entry spanname="c4-6">Folder</entry> 
        <entry spanname="c7-20">[Contents]</entry>
      </row> 
     </thead> 
     <c03> 
      <drow> 
        <dentry spanname="c1-3">
         <container type="box"></container>
        </dentry> 
        <dentry spanname="c4-6">
         <container type="folder"></container>
        </dentry> 
        <dentry spanname="c7-20"> 
         <unittitle>[Title], 
          <unitdate>[Date or date range]</unitdate>
         </unittitle>
         <daogrp> 
          <daoloc entityref="Thumbnail_entity_name" 
             role="thumbnail">
          </daoloc> 
          <daoloc entityref="Medium_resolution_entityname"
           role="med-res">
          </daoloc> 
          <daoloc entityref="High_resolution_entity_name"
           role="hi-res">
          </daoloc> 
         </daogrp> 
        </dentry> 
      </drow> 
     </c03> 
     <c03> 
      <drow> 
        <dentry spanname="c1-3">
         <container type="box"></container>
        </dentry> 
        <dentry spanname="c4-6">
         <container type="folder"></container>
        </dentry> 
        <dentry spanname="c7-20"> 
         <unittitle>[Title], 
          <unitdate>[Date or date range]</unitdate>
         </unittitle> 
         <daogrp> 
          <daoloc entityref="[Thumbnail entity name]" 
             role="thumbnail">
          </daoloc> 
          <daoloc entityref="[Medium resolution entity name]"
           role="med-res">
          </daoloc> 
          <daoloc entityref="[High resolution entity name]"
           role="hi-res">
          </daoloc> 
         </daogrp> 
         <daogrp> 
          <daoloc entityref="[Thumbnail entity name]" 
             role="thumbnail">
          </daoloc> 
          <daoloc entityref="[Medium resolution entity name]"
           role="med-res">
          </daoloc> 
          <daoloc entityref="[High resolution entity name]"
           role="hi-res">
          </daoloc> 
         </daogrp>
        </dentry> 
      </drow> 
     </c03> 
    </c02> 
  </c01> 
</dsc> 

Non-tabular display.

<dsc type="in-depth"> 
  <head>[Container List ]</head> 
  <c01 level="series"> 
    <head>[Series Head]</head> 
    <did> 
     <unittitle>[Title], 
      <unitdate> [Date or date
        range]</unitdate>
     </unittitle> 
    </did> 
    <c02 level="subseries"> 
     <head>[Subseries Head]</head> 
     <did> 
      <unittitle>[Title], 
        <unitdate> [Date or date
         range]</unitdate>
      </unittitle> 
     </did> 
     <c03> 
      <did> 
        <container type="box"></container> 
        <container type="folder"></container> 
        <unittitle>[Title], 
         <unitdate> [Date or date range]</unitdate>
        </unittitle>
        <daogrp> 
         <daoloc entityref="Thumbnail_entity_name" 
           role="thumbnail">
         </daoloc> 
         <daoloc entityref="Medium_resolution_entity_name]"
          role="med-res">
         </daoloc> 
         <daoloc entityref="High_resolution_entity_name" 
           role="hi-res">
         </daoloc> 
        </daogrp> 
      </did> 
     </c03> 
     <c03> 
      <did> 
        <container type="box"></container> 
        <container type="folder"></container> 
        <unittitle>[Title], 
         <unitdate> [Date or date range]</unitdate>
        </unittitle> 
        <daogrp> 
         <daoloc entityref="Thumbnail_entity_name" 
            role="thumbnail">
         </daoloc> 
         <daoloc entityref="Medium_resolution_entity_name"
            role="med-res">
         </daoloc> 
         <daoloc entityref="High_resolution_entity name]" 
            role="hi-res">
         </daoloc> 
        </daogrp>
        <daogrp> 
         <daoloc entityref="Thumbnail_entity_name" 
            role="thumbnail">
         </daoloc> 
         <daoloc entityref="Medium_resolution_entity_name"
          role="med-res">
         </daoloc> 
         <daoloc entityref="High_resolution_entity_name" 
            role="hi-res">
         </daoloc> 
        </daogrp>
      </did> 
     </c03> 
    </c02> 
  </c01> 
</dsc> 

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

  • the TYPE attribute is not used; all "see" and "see also" text is explicit.
  • the TARGET attribute and corresponding ID attribute are optional. Many TARGET and ID attributes may one day be set programmatically.
  • all referencing text is to be encoded

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 >[Title of target]</ref> 
        </unittitle></did> </c0#> 

Example 2:

 <c0#><did> <unittitle>[Title ] See: [See also: ] 
         <ref>[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 titles to another can be done in three ways:

Example 1:

 <c0#><did> <unittitle>[Title ] 
          See: <ref>[Title of target 1], </ref> 
          <ref>[Title of target 2]. </ref> 
          </unittitle></did> </c0#> 

Example 2:

 <c0#><did> <unittitle>[Title ]<lb> 
          See: <ref>[Title of target 1], </ref> 
          <ref>[Title of target 2]. </ref> 
          </unittitle></did> </c0#> 

Example 3:

 <c0#><did> <unittitle>[Title ]<lb> 
          See:<lb> <ref>[Title of target 1], </ref>
          <lb> <ref>[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].



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 OAC projects; and SGML declaration standards.


A. Naming Entities.

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

  • PUBLIC 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.
  • Name of owner::subordinate named division of owner. 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.
  • Public Text Class 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.
  • Public Text Description 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.
  • Public Text Language 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.

The following Public Text Classes may be used in <ead> instances contributed to the union database:

TEXT an SGML document or fragment
DOCUMENT a complete SGML document
NONSGML data not in SGML (the declaration should include
NDATA

Name of Owner.

The name of the owner is based on the AACR2 (chapter 24) catalogue 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, San Diego::Mandeville Special Collections Library University of California, San Diego::Scripps Institution of Oceanography Archives

2. Categories of Union Finding Aid Database Entities: Naming Conventions

There are three categories of entities comprising the union finding aid database : (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.


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

PUBLIC "-//Name of owner::subordinate named division of owner//TEXT

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:

(Country code (ISO 3166)::National repository code::local repository reference code::Title of archival unit)

The entire string is contained in parentheses.

  • ( ) left parenthesis indicates the opening of the finding aid/archival unit identifier; a right parenthesis indicates the close of the identifier.
  • Double colons (::) are used to separate hierarchical elements of the identifier or reference code.
  • Country code country code , column A2. The country code for the United States is "US".
  • National repository code. for repositories located in the United States, use the National Union Catalog or NUC symbol.
  • Local repository reference code. 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.
  • Title of archival unit. the title of the archival unit should match exactly the wording (though not necessarily the punctuation or markup) of the <archdesc><did><unittitle>. The formal syntax for Formal Public Identifier entries specifies that in addition to numbers, and upper- and lower-case letters, only the following marks of punctuation may be used:
' (apostrophe)
( (left parenthesis)
) (right parenthesis)
+ (plus sign)
, (comma)
- (hyphen)
. (period)
: (colon)
= (equal sign)
? (question mark)
/ (forward slash)
  • Either delete all other marks of punctuation or convert them to the nearest equivalent from the list above. Do not retain diacritical marks. Convert these to their nearest Latin equivalents. Be aware that an SGML parser will not flag incorrect <eadid>s as errors.

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)//EN"


2. Naming Entities Referenced by Individual Finding Aids.

Responsibility. Responsibility for naming all 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.

PUBLIC "-//Name of owner::subordinate named division of owner//TEXT

If the referenced entity is not encoded in SGML, but uses another notation, then the public text class is NONSGML.

PUBLIC "-//Name of owner::subordinate named division of owner//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.


a. 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//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"


b. Naming Related Digital Information.

Responsibility. Reponsibility for digital files that are not part of the archival material being described in a finding aid but are referenced for other reasons (for example, <eadheader> and <titlepage> name and address files,; pictorial materials used to illustrate biographies or histories; or biographies in digital form) should be based on the provenance of the materials.

Naming Conventions.

Text files with the name and address of contributing respositories will use the Public Text Description (eadheader: name and address) for the <eadheader> name and address information, and (titlepage: name and address) for the <titlepage> contact information.

Examples:

PUBLIC "-//University of California, Berkeley::Music Library//TEXT (eadheader: name and address)//EN"

PUBLIC "-//University of California, Berkeley::Music Library//TEXT (titlepage: name and address)//EN"

PUBLIC "-//University of California, Irvine::University Archives//TEXT (eadheader: name and address)//EN"

PUBLIC "-//University of California, Irvine::University Archives//TEXT (titlepage: name and address)//EN"


3. Naming General Entities.

Some general entities will be referenced by several finding aids, for example, the address for the University of Queensland will be shared between all the UQ finding aids.

Responsibility. Responsibility for naming and maintaining general entities will reside with the  University of Western Australia.


B. Declaration of Entities.

External entities referenced by finding aids must be declared in the Declaration Subset of each encoded finding aid. The declaration for general entities referenced by many if not all finding aids and text files for the header and titlepage contact information will be included in the template for each institution as appropriate. Declarations for <dao>s and other external entities referenced by individual finding aids must be added to the declarations in the Declaration Subset in the template.

Declaration Subset.

The Declaration Subset of an EAD document is an area delimited by square brackets ([]) and located within the DOCTYPE declaration. The DOCTYPE declarations is immediately followed by the encoded document itself: <ead> ... </ead>).

<!DOCTYPE EAD PUBLIC "-//Society of American Archivists//DTD ead.dtd (Encoded Archival Description (EAD) Version 1.0)//EN" [

Declaration Subset Area

 ]> <ead> ... </ead> 

Each External Entity Declaration is formulated with the following components and in the order given:

The following notations are declared in the <ead> DTD

JPEG PUBLIC "ISO/IEC 10918:1993//NOTATION Digital Compression and Coding of Continuous-tone Still Images (JPEG)//EN"

MPEG1vid PUBLIC "ISO/IEC 11172-2:1993//NOTATION Information technology - Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s - Part 2: Video//EN"

MPEG1aud PUBLIC "ISO/IEC 11172-3:1993//NOTATION Information technology - Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s - Part 3: Audio//EN"

MPEG2vid PUBLIC "ISO/IEC 13818-2:1995//NOTATION Information technology - Coding of moving pictures and associated audio: Part 2. Video//EN" MPEG2aud PUBLIC "ISO/IEC 13818-3:1995//NOTATION Coding of moving pictures and associated audio: Part 3. Audio//EN"

PCX PUBLIC "+//ISBN 0-7923-9432-1::Graphic Notation//NOTATION ZSoft PCX bitmap//EN"

GIF PUBLIC "+//ISBN 0-7923-9432-1::Graphic Notation//NOTATION CompuServe Graphic Interchange Format//EN"

TIFF PUBLIC "+//ISBN 0-7923-9432-1::Graphic Notation//NOTATION Aldus/Microsoft Tagged Interchange File Format//EN"

EPS PUBLIC "+//ISBN 0-7923-9432-1::Graphic Notation//NOTATION Adobe Systems Encapulated PostScript//EN"

PICT PUBLIC "+//ISBN 0-7923-9432-1::Graphic Notation//NOTATION Apple Computer Quickdraw Picture//EN"

XML PUBLIC "ISO 8879:1986//NOTATION Extensible Markup Language (XML) 1.0//EN"

HTML PUBLIC "-//W3C//NOTATION HTML 4.0//EN"

EMAIL PUBLIC "-//Society of American Archivists//NOTATION EMAIL//EN"

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) Version 1.0)//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>



Appendices


Appendix I. Referencing External File Entities.

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 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>
  <publisher>The Bancroft Library.</publisher> 
  &hdr-cu-banc; <date>&copy; 2000</date>
  <p>Regents of the University of California. All rights reserved.</p>
</publicationstmt>

File:

<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>
  <addressline>URL: http://www.lib.berkeley.edu/BANC/</addressline>
</address>

 

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

Declaration:

<!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>
  <item>URL: http://www.lib.berkeley.edu/BANC/</item>
</list>
 

Appendix 2. Standards for <controlaccess> access points.

<corpname> Kinetica (NBD)
<famname> Kinetica (NBD)
<geogname> Kinetica (NBD)
<persname> Kinetica (NBD)
<title> Kinetica (NBD)


By "Kinetica (NBD)" we mean the rules used in Kinetica / NBD to construct
these headings - not necessarily the actual forms of the headings used in
Kinetica / NBD, where the latter are incorrect (e.g. date of death not included).


<subject>

EAD allows for any number of different subject thesauri to be used, indicated by the attribute "source", e.g. <subject source="lcsh">

Thesauri not specifically listed in the Tag Library  can be included by using:
    <subject source="othersource" othersource="mythesaurus">

For <subject source="lcsh"> the standard will be Kinetica (NBD).


<function>

No standard specified as yet.


<genreform>

EAD allows for any number of different genre/form lists to be used, indicated by the attribute "source", e.g. <genreform source="aat">

Genre/form sources not specifically listed in the Tag Library  can be included by using:
    <genreform source="othersource" othersource="mythesaurus">

For <genreform source="lcsh"> the standard will be Kinetica (NBD).


<occupation>

RAAM is the best source. See:
http://www.nla.gov.au/raam/browseoccupation.html


Awards (Literary prizes)

Use <name> and follow AUSTLIT practice.


General note:
At this stage, we see no need to make the "source" attribute mandatory, except perhaps for <genreform> and <subject>.