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