Responding to Liz's complaints about the diverse encoding practices of
archivists, I would just note that an EAD advisory group is presently
working with RLG staff to revise RLG's EAD encoding guidelines for finding
aids submitted to Archival Resources.  The advisory group intends to
promulgate a minimal set of EAD elements, attributes, content
recommendations, and related practices *in a very prescriptive way*, not
only to make the EAD instances in Archival Resources play well together, but
also to help us all move a little closer to articulating a real best
practices standard for EAD encoding.
Dennis Meissner, Archival Processing Manager
Minnesota Historical Society <>
Voice:  651-296-2496  |  Fax:  651-296-9961
E-mail:  [log in to unmask]

-----Original Message-----
From: Elizabeth Shaw [mailto:[log in to unmask]]
Sent: Wednesday, January 30, 2002 5:37 PM
To: [log in to unmask]
Subject: Re: component notes

Hi all,

This discussion again points out to me the problem with the EAD Tag
Library from the perspective of a systems person who wishes to either
develop tools that assist archivists in fully utilizing the potential of
well-structured mark-up or who wishes to put multiple archives' finding
aids in a union catalog. The lack of shared practice and common
understanding of a vague tag library means that each archives (and even
worse) each archivist makes these decisions to the best of their ability -
but somewhat in isolation of the larger community. Although this listserv
has provided some interaction and indeed the Cookbook has provided support
for a common way of doing things, there is still tremendous disparity.

When it comes to programming for searching or display of your finding
aids, the systems person must now account for no less than 3 ways (in this
example) of extracting the same information. Multiply this by all the
discussions that have happened over the last couple years on this listserv
alone and any true blue programmer might go screaming into the night into
a fit of agony because the rules set s/he must write becomes almost

My rants about this have often been countered with the argument that every
archivist has their own tradition to follow and that adoption of EAD
without the flexibility that has been imbedded in the DTD would not hae
happened. This may well be true. But a vague and variously used DTD leaves
little on which the systems person can build powerful tools.

OF course, each archives can go its own way on these issues. And many
archives have built good systems around their own encoding practices. The
cost however, is that that archive then incurs the cost of creating its
own stylesheets, own system, own tools that might aid in speeding encoding
processes. Or perhaps the cost it incurs is that it's finding aids can not
be used in creative and innovative ways because it cannot bear the costs
of doing all of its own technical work.

If on the other hand, common understandings and implementations in
markup of these elements can be determined, then the cost of development
of a wide variety of interoperable tools can be shared by the community.

EAD has been a marvelous step forward in thinking about access aids. But
EAD as a vocabulary of XML needs to be rethought if the archival community
is to take advantage of the vast potential of a markup language. And it
needs to start with the development of a common set of understandings of
the semantics of the elements(tags) themselves. That can only happen in
the archival community. But as long as there are 3 or 4 ways of encoding
essentially the same content then it will be difficult at best to build
the kind of exciting systems that others have using XML and its

Liz Shaw
Visiting Lecturer
Room 626 IS Building
Department of Library and Information Sciences
School of Information Science
University of Pittsburgh
Pittsburgh, PA 15260
Phone: (412)624-9455
Fax: (412)648-7001