Actually Michael you are exactly right, and I think I implied that. The
Tag Library is only a manifestation of the lack of agreement and
definition in the archival community. Ironically, it models the community
understanding of descriptive practice rather well. The problem is that the
model is a muddied and conflicting one. That makes the DTD, a muddied and
conflicting tag set, which then limits its usefulness as an XML
vocabulary.
So, the real solution to the problem is to develop a common, coherent
content standard. A more useful content model, as expressed in an XML
vocabulary would naturally flow from such a standard and I would stop
whining about inconsistencies, redundancies and infinite rules
sets. :)
Liz Shaw
On Thu, 31 Jan 2002, Fox, Michael wrote:
> 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
>
|