Hello,
I would not disagree with anything Elizabeth has said but might offer a
slightly different spin. The fault and therefore the solution does rest in
EAD or the EAD Tag Library. The fault lies with us, individually and
collectively. What we need is a common vision of what information needs to
be included in finding aids, a common conceptualization and description of
the nature and meaning of that data, and a shared nomenclature for talking
about it. We have a half century of finding aids created on an ad hoc basis
and are surprised that we cannot agree as to what information ought to be
included or even how we think and talk about what is there. Rectifying
that problem is our first step and fundamental step. Without resolving
that muddle, there can be no agreement on encoding. How can you encoded
something when you can't say what it is?
The most interesting and telling aspect of this whole conversation
to me has been the fact that it has spun around our inability to fully
articulate what constitutes a scope and content statement. To say nothing
of an abstract. Is it and abstract of the contents of the collection (a
mini-surrogate) or an abstract of the scope and content statement (a
mini-surrogate of a mini-surrogate)? How basic! A descriptive Tower of
Babel.
Bill Landis finds no guidance in ISAD(G); I would not have expected
any because ISAD(G) is no more a content standard than the EAD Tag Library
was meant to be. I'm surprised that no one seems to have mentioned looking
at APPM or RAD for direction. To blame either ISAD(G) or the Tag Library
for not being what they were not intended to be is unfair and has us looking
in the wrong direction for solutions.
Perhaps the CUSTARD project will help, at least those of us in North
America, shape the answers to these questions.
Our pragmatism has caught up with us.
Michael
-----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
infinite.
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
applications.
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
|