Rick, itematically:
~~~~~~~~~~~~~~~~~~~~
Clay Redding
Automation/Systems Archivist
American Institute of Physics
Center for History of Physics
Niels Bohr Library
One Physics Ellipse
College Park, MD 20740
Phone: (301)209-3172
Fax: (301)209-3144
~~~~~~~~~~~~~~~~~~~~
>>> I guess I don't understand why people say EAD is "complex". It contains exactly what archivists asked for doesn't it?
Yes and no. Some like the flexibility of being able to dump any legacy data into it. Similarly, the flexibility means that the standard can be used internationally to incorporate variant rules of description. Others, however, think it needs to be stricter in its syntax to ensure the predictablity of data across finding aids and even across institutions. Doing so would increase the likelihood that software tools could be developed to help with creation and dissemination. If archivists asked for the flexibility, then we are to blame for the resulting complexity and low rate of adoption.
>>> If you know what to put in a finding aid, you know what to put in an ead document -- you just have to understand how the tags relate to the traditionally provided data
I see what you're getting at, and you're largely correct. I think alot of the complexity of EAD arises not from the time the encoder sits down to tag, but at the time when the finding aid is drafted. Not to start an education debate, but not all archivists know what (and where) to put in a finding aid during its creation. And they have proven so by adhering not to national or international data content standards, but to their own local institution's rules for creating finding aids. Seemingly, it's only been in the last few years that emphasis has been placed on descriptive standards when creating finding aids. Before that (and even to a large extent currently), the only standard was to adhere to the localized templates.
The introduction of EAD to many beginners is a two-pronged approach: 1) Learn XML/SGML and 2) learn how to describe records according to accepted data content standards (which, in most cases of doing retrospective conversion, means that some tidying or "re-engineering" must take place before the data can be tagged). In terms of the difficulty of the education process, number 1 is tough for some, but probably not for most. Number 2 is expensive not only in terms of many archivists having to learn the basics of content standards like RAD or AAPM, but also in the money and time it takes to then re-engineer the data in their finding aids (although I suspect this is not being done in some EAD projects). I also think it's the latter, not the former, that presents the largest roadblock to implementation and successful adoption (e.g., "How do I create a standard encoding procedure when we have all this non-standardized data in many different formats?").
You are correct that most archivists could recognize where to put the data in the document. It's just the time and effort of learning both of these prongs, and then training them to others (students, etc.), that seems to cause most people to balk before implementation.
>>> If I had data needing to be xml-ified, I would rather encode it with the parts of EAD that I understood -- than do nothing.
I agree, if you understand some level of EAD (e.g., the collection level description), then use it. I responded to Wayne in this manner because I inferred that he was looking for any possible alternative to EAD. My response was getting at the notion that many smaller archives want to delve into EAD in order to stay ahead of the technology curve. Or, perhaps they (mistakenly) feel that they are behind the technology curve because they haven't adopted it. If they don't have the resources, and there is no pressure to XML-ify, then don't rush it. If they have to XML-ify, and and they aren't comfortable with EAD, then look elsewhere, but keep EAD in your rear view mirror for implementation when the simplicity is achieved.
Clay
|