Print

Print


> One thing came to mind for point (3) "indexes," and perhaps the DTD
> overall.  There's a lot in EAD to help with converting data in existing

> finding aids, e.g., indexes that can't be built automatically because the
> data only appears in the index.  Imagine literary manuscript collections,
> for which the container list says "Correspondence "A through An"; only in
> the index are the individual correspondents listed.
>
> Also, could you elaborate on how an index might be made automatically in
> the future, if authoring a finding aid from scratch?  (I've been assuming
> that the container list grow long; each correspondent's name would be
> listed for each pertinent "folder" and tagged to ID the surname/forename
> portions for inversion in a browseable index.  But then, is the index
> generated by Database or Word Processing software, SGML authoring
> software, a browser?  Is it built "on the fly" (for those users who want
> alphabetically browseable indexes rather than keyword retrieval), or built
> once, to become part of the finding aid?
>
>
> Helena Zinkham                          phone: (202) 707-2922
> Prints & Photographs Div.               fax: (202) 707-6647
> Library of Congress                     email:  [log in to unmask]
> Washington, DC  20540-4840
>

I was thinking of something along the lines of the <index> element in TEI,
which is placed at the relevant division in the text, and contains a level attribute
and the index term to be used.  In the example you give above, you'd need
multiple entries, each recording the correspondent referred to, in the relevant
<c> element.

Generating an index is easily done using PAT or similar software, probably
using a scripting language like Perl or Tcl to tidy it up.

All the best,
Richard Gartner
Bodleian Library