Very interesting and helpful to have an overall reaction to EAD.  (That's
a hint; if other early implementors have general comments, it'd be great
to hear them.)

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

On Sat, 13 Apr 1996, Richard Gartner wrote:

> Hello all, > > Here at the Bodleian we've been trying out the EAD on a
couple of finding aids - here > are some comments based on our findings so
far:- > > 1) I think a reg attribute (rather like the TEI equivalent) is
necessary for <persname>, > <geogname> and <famname> to allow the
construction of name indexes using > a name authority file. > > 2) I think
an attribute (similar to the general n attribute in TEI) would be useful
for > the component elements to allow shelfmarks etc for individual items
to be recorded, > more elegantly than is possible using the <did> and then
<unitid> elements. > > 3) I don't think the current way of constructing
indexes is at all useful - I think > the facility to generate indexes
automatically is vital, and the tagging of a > hand-generated index is
going to be laborious and less than useful. > > 4) On the whole I think
the DTD tends to take the look of a printed finding aid > too much as a
model - hence the extensive table formatting codes,etc.  I think the >
problem with taking this approach is that we could end up with something
like > HTML, ie great for formatting but less useful for expressing
descriptive content. > We are using the <did> element within components,
rather than the table options, > and this seems the most useful approach
so far. > > 5) Also I would suggest using attributes rather more, for the
sake of greater > concision and readability. > > Despite these minor
quibbles, a tremendously useful tool - we're certainly going > to be using
it for all our finding aids in future. > > Best wishes, > Richard Gartner
> Bodleian Library, Oxford