I began by marking up two finding aids available on diskette in Word in 1997 with the EAD Beta release using SoftQuad's Author Editor in Daniel Pitti's first Rare Book School course, Implementing Encoded Archival Description. With the release of EAD 1.0, I manually converted the first two finding aids to the new version and continued creating EAD finding aids with Author Editor. After I created the SGML document, I validated it with James Clark's NSGMLS, and converted to XML using James Clark's SX (both programs are part of the SP package) provided in Daniel's class. With the release of Microsoft's Windows XP, my computer would no longer run Author Editor so I switched to XMetaL 2.0 to create the finding aids. Windows XP wouldn't run the NSGMLS parser so I took Daniel's Rare Book School course, Publishing EAD Finding Aids, in 2003 and began using NoteTabPro, Saxon, and the XSLT stylesheets from that class to transform the XMetaL SGML documents in EAD 2002 into XML (for crawling), HTML (for viewing), and PDFs (for printing). We had both 1.0 and 2002 finding aids on our Web page until I discovered that the new version of RLG's Archival Resources, now called ArchiveGrid, wasn't displaying the 1.0 versions anymore. In July 2006, I manually converted the EAD 1.0 finding aids to EAD 2002, upgrading the descriptions (including new required fields) and updating them with additions to the collections since I created the EAD finding aid.
Our finding aids come in several formats:
Legacy finding aids only on paper: I manually key into a template I set up in XMetaL (a separate one for each of the three units in Special Collections--Historical Collections and Labor Archives, Rare Books and Manuscripts, and University Archives).
Legacy finding aids in Word on diskette: I copy and paste the parts (picking apart paragraphs to place sentences in their correct EAD tags) into the XMetaL template.
New collections that I process: I key the data directly into the appropriate XMetaL template.
New collections the staff in Special Collections processes: They create a Word document mirroring the fields in my XMetaL template and send it to me to proofread and put it in XMetaL.
Collections in our database: The last option is to run a report from our Cold Fusion database on an Oracle platform to create a well-formed EAD document in XML. We are still fixing the coding in the database to get a perfect EAD document; in the meantime, when I export the data there are a number of tagging errors so I need to do a lot of search-and-replace, search-and-delete, and cut-and-paste to get a final, validatable EAD document. Until this is functioning correctly, hopefully sometime in 2007, I prefer to work with the Word document. Our goal is to be able to generate an EAD document for each collection in the database no matter what level of processing--or lack of--it has received so that all collections will be discoverable.
While I am creating the EAD document, I cut-and-paste the appropriate fields into a MARC record in OCLC, and simultaneously apply or create new Library of Congress name authority headings, Library of Congress subject headings, and Art and Architecture (AAT) form/genre terms for both the finding aid and the catalog record.
I place the XML, HTML, and PDF files on a server to make the finding aids accessible in several ways. I include links to and collection abstracts for each individual collection with an EAD finding aid on a Special Collections Library Web page, "Selected Finding Aids," where users can choose to look at the HTML version online and/or print the PDF document. I have also provided links to the finding aids using the 856 field in our catalog records in OCLC's WorldCat and in our local SIRSI system. The XML files serve as the basis for RLG's spider to crawl the finding aids for inclusion in ArchiveGrid. In 2007, we hope to have a finding aids platform available for cross-collection searching.