Catalogues, whether retro-converted from paper or from born-digital sources, are collated, processed, standardized to ISAD(G), quality assured, validated and held centrally (at The National Archives) as 100,000 XML files (EAD 1.0)

The depth and detail of each individual catalogue varies enormously:
From 1.5 kb per XML file up to 1.5 MB per XML file (3.3 GB of XML data in total).
From 1 level only per file (a fonds) up to 10 nested levels (fonds through item).

New EAD finding aids are created using modified versions of eadcorporateNT.xml and eadpersonNT.xml templates from the EAD 2002 Cookbook. Old finding aid container lists are converted from FileMaker Pro by exporting the container lists into XML, then using the "find and replace" tool in NoteTab to replace FileMaker XML tags with EAD XML tags. The front matter text from old finding aids is copied and pasted into the templates.

AIP separates the text into two files; the descriptive information and the container list. The descriptive information is cut-and-pasted into a template in the authoring software (oXygen). The container list is either imported from a Microsoft Excel document into a Microsoft Access database, or typed directly in to the database, which then prints the properly tagged boxlist. After joining the two parts, the finding aid is validated in oXygen and processed using Saxon. Once the XML has been converted to an HTML file, HTML content file and an HTML navigation frame file are uploaded to the server.

At the APS, the process usually begins with paper inventories, which were outsourced to Apex for conversion to rough EAD courtesy of the Delmas grant. Subsequently, some work has been done with a few finding aids that were available in html, some paper finding aids have been scanned into MSWord, and some have been rekeyed. In every case, though, it was necessary to provide a rather significant degree of augmentation to the records to make them even minimally acceptable as finding aids. Old descriptive practices did not include many of the most basic elements that are essential to a proper finding aid.

Other than the out-sourced files, finding aids are marked up in MSWord using a plain-text template and edited as need be, again in plain-text. Some experimentation has been done with extracting data from an MSAccess database directly into an EAD plain-text template using the printmerge function. For container listings (which tend to be stored in different databases), it's not quite as simple, but works adequately so far, at least on a case by case basis.

Files are proofed largely by attaching an IE-compatible stylesheet and viewing through the website. Once proofed for content, they are validated in XMetaL and transformed to html using Saxon using the Version-1.0 stylesheet.

Participating institutions send EAD-encoded descriptions to the central service team at the University of Manchester. There is an online ISAD(G)/EAD template at http://www.archiveshub.ac.uk/eadform2002.html or repositories can create their own EAD files, following the Archives Hub guidelines at http://www.archiveshub.ac.uk/arch/dcg.shtml . Institutions running the Spokes software create and upload their files locally, using whichever software suits them best.

After an initial conversion of approximately 50 legacy finding aids with a grant from RLG, using a contracted encoding service, several Archives of American Art (AAA) staff members were trained in the EAD markup process at the University of Virginia’s Rare Book School in 2001. AAA subsequently adopted the EAD Cookbook encoding protocol as the framework for it’s encoding, and we made some adaptations to the Cookbook templates and stylesheets to conform to our workflow and presentation preferences. This method uses NoteTab for encoding in XML, XSL stylesheets for presentation, and MSXSL to convert XML to HTML.

The majority of AAA’s processing staff have now received EAD training in-house and all new finding aids are created directly in EAD or encoded shortly after creation. Conversion of our legacy finding aids is ongoing.

EAD finding aids for digitized collections, known as "Collections Online," provide links from the folder headings to the digital files, thus serving as the metadata for those files and the primary navigational tool for viewing them, all within the context of the collection.

Two computer specialists on staff provide the technical support for software, stylesheets, Collections Online, and other programming. They are currently developing a Digital Collections Database which we hope will, in the future, store all our XML finding aids and generate HTML on the fly.

Legacy formats are mostly Microsoft Word or printed and there is little standardization of structure and content. Encoding is done in-house, using XMetal in conjunction with a template created using a CSS stylesheet (to give a basic encoding structure) to guide staff in the markup of finding aids using XMetal. Legacy finding aids are re-authored to bring them in-line with the new template and re-keyed or cut/pasted into the template. New finding aids are authored directly into XMetal. XMetal validates the finding aids against the EAD DTD each time it is saved and options for indexing and searching are currently being explored.

We import our Word, Excel and Access files into the application CALM, by means of import format files, and export them as EAD files.

Our legacy finding aids exist in a variety of formats - published catalogues and unpublished typescripts. Retrospective conversion began in 1998 with the unpublished finding aids which were converted into EAD (SGML) by a data conversion company, and subsequently transformed into XML in house. EAD 2002 is used for all current cataloguing. Existing EAD catalogues will be converted in due course. Perl scripts are used to automate repetitive aspects of encoding.

We have marked up finding aids from a variety of formats: Word and WordPerfect documents, our Inmagic database exported in ASCII text, and SGML files created from scratch.  We've tried different ways to automate the procedure but have yet to find one best way.  We do use a PERL program created by Alvin Pollock to create an HTML version of our SGML finding aid, and it's a wonderful program.  We currently don't have a search engine or other indexing retrieval method but are marking up our finding aids with the future in mind. We use Panorama's Author/Editor for markup, offer Panorama Free and the HTML versions for delivery methods.  We like Author/Editor for the most part.

New collections being processed are described directly in EAD. Legacy finding aids in paper format are being rekeyed and encoded in EAD, as are collection inventories represented by card sets. Some mainframe inventories have been converted to EAD components using Perl scripts. The finding aids on this site are marked up in EAD XML, using NoteTab Pro. The clip libraries and stylesheets used have been developed by the Center for Digital Initiatives staff at Brown University Library, and are available upon request.

The retroconversion program is done by a contratctor who deliveres them in EAD format. Data from the BASYS database can be exported into EAD. Direct encoding in EAD during description is done with the tools MidosaXML or MEX which is also used to encode legacy text files.

The current work on the finding aid is largely conceptual. The Newspaper Clippings collection is to be divided into two series: Comic Sections and Comic Clippings. I have created a tagging structure that can encompass these two rather different series. Both are organized first by title, then by date. "Title" means something different in each series: in the first, it is the title of the newspaper in which the comic section appeared, with description at the item level. In the second, it is the title of the comic strip, with description at the box level.

Problems of additional description also present themselves. Ideally, the Sunday sections would receive detailed description at an additional component level. Early Sunday sections, from the late 1890's to the early 1920's, were not so standardized as they are now. Comic features came and went, their titles changed weekly, and important comic artists did one-time features. Additional <c> wrappers with cartoon titles, and <persname> attribution, would provide a much-needed index of the early work of American comic artists--if time allows for this much encoding.

The problem of tracking dates for comic strip clippings, without making the finding aid too large, has been solved through the use of Excel spreadsheets, which contain a month-and-date grid of holdings for each comic feature. These will be converted to PDF and will reside on the server with the finding aid, accessible through <extref> links.

A representative image of each comic feature, consisting of a single cartoon panel, will be available as a <dao>.

Most of the collections, which have been encoded at the Center for Jewish History so far, were legacy finding aids; some of them existed only in hand-written or typewritten form. These were either keyed directly into XML in XMetal 2.0 or in to MS Word when substantial descriptive information had to be added. Some of the finding aids reside in WordPerfect or InMagic databases. These files were usually converted into MS Word where the descriptions and data formats were polished and modified, so they would comply with DA:CS or APPM, LC NAF, LC-ALA transliteration tables, and other standards. XML files are created in XMetal 2.0. and Altova XML Spy 2005 Home edition and increasingly in NoteTab using customized clip library file provided by Chris Prom.

Existing word processing files were manually cut-and-pasted into a template in XMetaL. The archivist trained a student and a staff member to do this with good results. New finding aids are created directly in XML.

Direct input by processor into a database or creation of a Word document. We do some OCR.  If we start with a Word document we import the data into the database by supplying the appropriate number of tabs (fourteen at this point). Much of the insertion of the tab stops is accomplished using Find/Replace; however, we do need to watch what we are doing.

Once the data is in the database we can further edit using the editing features of the data base.  The database is configured so that all fields are optional and the output will still parse.  The database we use is Pro Cite, and the markup is an output style applied to each entry in the database.  We also use the Berkeley Template to encode all of the higher level information.  The template gives us a text file into which we insert the text file output from Pro Cite.

We validate the document with ParserPlus, the Windows-based version of Jim Clark's SP produced by CSW Informatics.

All finding aids existed in Microsoft Word, although most were also available as HTML files. Containing listings for many collections also existed in InMagic's DB/Textworks as databases.

We use the Home Version of XMLSpy for EAD markup, stylesheets, and file validation. A basic template was created in XMLSpy, and the text of the finding aid was cut and pasted into the appropriate portions of the template. Additional editing was completed in XMLSpy as necessary. As InMagic's DB/Textworks will export data in XML, we were able to automate the process of converting the container lists into EAD by using XSLT to transform the InMagic XML structure into an EAD XML structure.

The finding aids are subject-indexed, but there are currently no MARC records available for our manuscript collections in the library catalog. The finding aids are accessible from collections lists and abstracts available on our web site.

After considerable discussion and time spent developing an acceptable EAD markup template for Cornell's Division of Rare and Manuscript Collections, we have concentrated on the direct delivery and navigation of XML finding aids and on the development of a scalable XML system that can be easily maintained. We're also working to perfect high-quality print output from the XML instances. Our goal is to create XML masters and produce all derivatives (print, web, etc.) from these.

For test material, input thus far has been from word processing files (MS Word) and HTML versions. We're using various free conversion tools: Emacs (text editor), PSGML (SGML add-on to Emacs), PS (J.Clark's SGML parser+ toolkit), and Perl. These same tools will likely be used in any large scale retrospective conversion of finding aids in electronic format. For existing paper guides, we may try outsourced re-keying, with some added codes (but not full markup, which would be done in-house). For current finding aid production, we are experimenting with strictly enforced Word templates and styles, combined with Perl scripts for conversion. As we eventually want to treat the XML files as our masters and get away from this two-step procedure, we're also hoping that more affordable and user-friendly XML authoring solutions are developed.

We're beginning to explore alternative methods of indexing and searching our on-line guides.

The Denver Public Library received partial funding from the National Endowment of the Humanities for encoding the legacy finding aids. Legacy formats are Microsoft Word with a standard structure and content. Encoding is done in-house, using XMetal in conjunction with a template created using a XSLT style sheet (to give a basic encoding structure) to guide staff in the markup of finding aids using XMetal. Legacy finding aids are converted and/or cut/pasted into the template. New finding aids authored directly into XMetal. XMetal validates the finding aids against the EAD DTD each time it is saved. Additional options for indexing and searching are currently being explored.

The encoded finding aids are being publishing on the web using PLEADE enabling users to browse and then read the finding aids online. PLEADE is a highly configurable Web publication framework, including a search engine, for Encoded Archival Description documents. The appearance of the online finding aids is similar to the model provided by SGML and XML implementations, with a navigator that shows the structure of the document and functions as a hypertext table of contents to the file and a search engine.

With an initial phase of retrospective conversion of existing finding aids complete, Duke is now concentrating on two fronts. The first seeks to refine the process of creating new finding aids using XMetaL, an XML authoring software by Softquad, and web forms. The second involves participating in the North Carolina Encoded Archival Description (NCEAD) consortium to standardize EAD encoding practice. Duke is integrating the writing and encoding process for new finding aids using a combination of web-forms, XMetaL, and macros. The web form is used to enter information that is processed into the header and collection level description sections ofwsers as well as in the DynaWeb system.

The process of writing and encoding finding aids is performed by both students and professional staff. Student responsibilities include processing collections and writing container lists. Staff members complete the finding aids with header and collection level information and bibliographic records, as well as performing other quality control functions.

All finding aids are encoded according to a set of guidelines written by the members of the North Carolina Encoded Archival Description (NCEAD) consortia. At present, this consortia includes North Carolina State University, University of North Carolina at Chapel Hill, State Archives of North Carolina, and Duke University. The NCEAD AG seeks to standardize EAD encoding at the four institutions in order to present users with a set of consistently encoded finding aids.

For more information about Duke EAD see http://scriptorium.lib.duke.edu/findaid/ead

Durham's handlists tend to be highly detailed item level listings, done without any authority system or house style, only the most recent of which had been word processed.  This has precluded most automation of the markup process, although awk (a program that comes with UNIX (and LINUX) which treats text files like a database) has been useful for some sequences.  The results are highly unsatisfactory as electronic texts, stretch to (and beyond) the limits of EAD, and do not display the consistency that might be desired from using EAD, but nevertheless provide what was required of the project concerned (making existing lists available online) and establishes the skeleton which much future authority work can flesh out.

Conversion has started with a basic keying of the text, then a combined proof reading and markup using WordPerfect SGML with macros on ASCII text which is saved and parsed as SGML.  While fine for conversion, WordPerfect does not deal reliably with finished EAD SGML files, so these are at present worked on using EMACS in PSGML mode with the NSGMLS parser, although development is currently underway on using Adobe Framemaker+SGML as the means of editing existing documents.  As mentioned, the lack of authority forms, etc., has meant leaving aside questions of indexing, etc., at present (the problem lying with the data rather than EAD).  The handlists are made available via Dynatext/Dynaweb etc, as indicated above ( http://flambard.dur.ac.uk:6336/ )

In 1997, GAMMA rekeyed approximately thirty-five paper finding aids from 17 different repositories (including Emory) and encoded them in the beta version of EAD using Author/Editor.

The SAGE Project (1997-2000) will develop a model digital archive. As a part of the project, we will rekey one finding aid and will encode two others from scratch. Initially, we used Author/Editor, but we have decided to switch to XMetaL. We create an HTML file from the SGML file by hand. Hyperlinks are added to the HTML file that allow the user to link to contents of the file, if they have been digitized. (This process hasn't been automated yet either.) The finding aids currently available through the site are in EAD beta, but we hope to convert them to EAD version 1 during the coming year.

Special Collections also participated in RLG-Apex Finding Aids Conversion Service , but has not yet made those files available.

Legacy finding aids were converted using a variety of tools. Most finding aids were in Microsoft Word or WordPerfect format. For these, Perl scripts were developed to automate encoding of the container lists. The rest of the information in the finding aid was converted by student encoders who entered data into a web-based interface that used CGI scripts to encode the data in XML. One institution's finding aids were in a MARC-compliant database. These finding aids were converted by exporting MARC binary files from the database, translating those files into MARC XML format using scripts available from the Library of Congress, then transforming the MARC XML to EAD using an XSLT stylesheet. New finding aids are being encoded using NoteTab Pro and a specially modified version of Chris Prom's EAD Cookbook tools for NoteTab.

Project participants are each encoding their own finding aids. In most cases, these exist in electronic form already (Microsoft Word or HTML), but some are being keyed in from printed guides. Most encoding is being done in-house, with XMetaL and NoteTab as the main tools being used. Some files are being outsourced for encoding to an Australian firm which specializes in SGML data creation and conversion.

The encoded files are submitted to the University of Western Australia for final proofing and Web publication. As part of this process, files are parsed again by the DynaText software. Indexing is also provided by the DynaText and DynaWeb suite.

The Guide is a national database of finding aids for more than 80 collections of Australian literary manuscripts. It brings scattered and hard-to-find information together in one place.

It contains detailed inventories of the manuscripts of 65 authors, including Peter Carey, Miles Franklin, Elizabeth Jolley, John Kinsella, David Malouf, Katharine Susannah Prichard, Kenneth Slessor and Christina Stead.

The contributing libraries are the National Library of Australia, the Australian Defence Force Academy Library, the State Library of New South Wales, the University of Queensland Library, the University of Sydney Library, and the University of Western Australia Library.

Each finding aid can be browsed or searched, and contains the following information: Summary, Biographical Note, Administrative Information, Access Notes, and Series List and Description.

OASIS is a project involving 22 Harvard repositories. With so many participating institutions, the procedure used for EAD markup is slightly different at each, although all follow the established Harvard guidelines (available at: http://hul.harvard.edu/ois/systems/oasis/eadguide.html ).

The legacy finding aids in OASIS were created using various word-processors; they have been converted to XML documents by a variety of manual and partially-automated methods, or by outside vendors. New EAD finding aids are being created in XML, using a variety of applications including WordPerfect and XMetaL.

Most of the finding aids from both repositories are in some electronic form. Long container lists are partially encoded using a perl script. The remainder of the finding aid is put into a standard template. Most finding aids are currently being prepared by students from the University of Pittsburgh School of Information Sciences. We use Emacs with psgml and Jade tools on our NT workstations. We are currently in the final phase of testing a web-based data entry form for collection level encoding so that those unfamiliar with EAD can automatically encode new finding aids.

We have started with converting some 500 WordPerfect 5.1 files. These files were first prepared for conversion by checking for consistency and adding extra information and codes required. Conversion to EAD is done automatically with OmniMark. EAD files were (and still are) validated with Author/Editor. After the WordPerfect 5.1 files we have also converted our paper finding aids to digital format using EAD. We didn=t do OCR, instead all documents were rekeyed en encoded according to EAD. At present, we try to develop a suitable procedure to mark up the new finding aids. Information on archives and collections can also be found in an online catalogue (GEAC-geoweb) and on separate webpages on the archives. At both places links to the finding aids will be made.

We use the original MsWord files, a template in the XMLSpy (in the future probably XMetal 2.0) software and, for the time being, the manual process of copy and paste into the template. We will soon try to automate the markup somehow by using EAD Stylus or some other suitable way of tagging. We will try to develop some templates that make tagging easier and more error-free.

All of our finding aids are in electronic form in Microsoft Word and are created using a template in WORD7. These finding aids are then marked up in SGML using Author/Editor. (When we do HTML finding aids, we use Claris Home Page, and follow the same procedure.) We have created macros in A/E that automatically insert the correct tags for genre, corpname, persname, geoname, title, etc.

We also have macros that insert the combination of tags for a new box list and a new series level, and signify if it is a series, folder, or file. The same sort of thing was done in CLARIS, where we created libraries that insert "&nbsp" multiple times to display the box list at a hierarchical level. So far we have not been marking dates, but have been marking all of the above mentioned genre terms as they appear in the Biography/History, Scope and Content, and Box list. The subject terms we are taking from our library catalog so they are LC subject headings.

The majority of participating repositories use an automated EAD ouput routine to produce files for publication on Janus. The output routine is part of a ISAD(G)compliant, hierarchical cataloguing tool developed locally using the Microsoft Access application. Others use an online form on the Janus website or markup their word processed catalogues 'by hand'. Index terms are included in each EAD instance and become part of the Janus database at upload. The Janus webserver includes parsing software among its suite of tools to check uploaded files are encoded in acceptable EAD before publication.

Rather than converting existing finding aids, our focus has been to get some standard information about all of our collections onto our Web site, and EAD seemed the most effective way to accomplish this. Thus we are undertaking an "EAD-lite" project, and using only a small subset of the codes. Each EAD entry presents brief collection information, a biographical note, a scope and content note, some administrative information, and (in most cases) a portrait of the individual. In 1997, Scott Leonard, a graduate student from the University of Maryland College of Library and Information Services, as part of an internship, developed the EAD site. He did the technical groundwork, did the initial coding, and worked out most of the "bugs" in the system (of which there were many). He also encoded the first batch of finding aids and wrote detailed instructions for encoders who would follow him. Since then, students, part-time workers, and one professional have done the encoding.

The project coordinator checks the encoding on each entry; several members of the Archives staff edit the entries for content and style. SGML markup was done using SoftQuad's Author/Editor program, and the SGML finding guides display in Panorama. (We offer the HTML version as the "default" option, as we don't expect most of our users to have Panorama.) The next phase will be to add folder listings. For these, we will be working with existing finding aids in a variety of formats: printed guides, typed inventories, and WordPerfect documents. We contracted with ArchProteus conversion service to convert a very large inventory which heretofore only existed as a published volume. They produced both an HTML and an SGML/EAD version, both of which will soon be available on our Web site. We plan to contract with ArchProteus to convert other inventories.

Local migrations from databases to construct container lists and then using the template generator to produce the finding aid markup down to the container list. When migrating from a database or Excel file, we devised export methods for globally introducing the majority of the tagging required for the container lists. Findaids are technically parsed twice, once by NSGMLs and a second time by the Dynaweb mkbook indexer/parser. We also outsourced the re-keying of ~17,000 pages of paper finding aids with APEX data services. We index the finding aids with Dynaweb's mkbook application.

Finding aids in various divisions within the Library created originally as word processed documents (primarily WordPerfect) or Access databases. Word processed files usually converted using templates and styles, although some are mapped to generic XML and thence to EAD DTD using XSLT. Access databases converted using XSLT. Indexing procedure: finding aid database still indexed using InQuery, used for other full-text applications at LC, pending development and acceptance of XQuery language by the W3C.

LSU Special Collections begins with WordPerfect 7.0 files (inventories), outputs the file to ASCII format, and manually tags the file with EAD tags. We initially used SoftQuad's Author/Editor, but found it to be very technical and hard to explain or troubleshoot. We are waiting for the next generation of improved SGML editors before we invest more money in authoring software. In the initial implementation, we have provided only the preliminary information, such as scope and content notes, biographical/historical notes, etc. In the second phase of our implementation, we will add the container list and location information  for each inventory. Currently, approximately fifty percent of our one hundred electronic inventories have been tagged as SGML files.

Since museum-type records are often detailed at the item level and are often exported in a structured form from museum collection management systems for inclusion in the EAD finding aid, automation is feasible and desirable. We mark up the EAD header and scopecontent/bioghist info manually using A/E. But for the container lists, we export records from the collection managment system and either use the database to mark up the records as they are exported, OR export the records as tab-delimited text and write Word Macros to automatically mark up the records. Container lists with complex hierarchical relationships then take some extra hand manipulation, but most of the markup is still done automatically.

The first step in preparing the instances is to prepare the information for the collection-level finding aid. This is done by making a skeletal version of the finding aid with the headings, "agency history," "index terms," and a few others, and printing it out. Sometimes, notes are made directly on the print-out, filling in the blanks. Sometimes notes are made long-hand on cards and note paper. These are then entered into an XMetal instance with the help of notes and handouts from the SAA workshop, the Application Guidelines and Tag Library, and marked-up examples such as the William Fonds Provenance. The only thing used to proof and parse the instances is XMetal, on a PC. The indexing procedure is to make notes about possible terms, look them up in the Library of Congress's online catalog, using LC's heading when possible, and when not, constructing the heading based on AACR2.

In 2002 we developed an MS Access database tool for 95% of our encoding for both and (and we offer it as freeware to any that ask). The output is a fully marked up xml file. We still use Daniel Pitti's Rare Books School Notetab/EAD set-up for specialized encoding, parsing, and XSL/HTML conversions for quality control, proofreading, and paper version transformation. XML is loaded into DLXS for search and display. John Rees, Curator, Modern Manuscripts History of Medicine Division National Library of Medicine reesj@mail.nlm.nih.gov Yes. http://www.malvine.org/ The MALVINE Project- Manuscripts and Letters Via Integrated Networks in Europe Date unknown

See description at website

The Minnesota Historical is currently revising its authoring process. For newly processed collections, separate techniques are used to create the collection level portion of the finding aid and the description of the components section. The collection-level data is harvested from the MARC record which is typically prepared before the rest of the finding aid. The MARC record is downloaded from the OPAC. Logos Research's marcxml.exe program then converts that file from the MARC transmission format into the MARC DTD format. The resulting XML file is then converted into an EAD instance using an XSL stylesheet and James Clark's xt.exe program. A single batch process executes all these steps. The resulting XML file is then loaded into the XMetaL application wherein the cataloger simply completes the <eadheader> data and/or augments the description with expanded scope and content, biographical, or organization information depending on the complexity of the materials. The description of the components section is created in either of two ways. For small collections with short contents listings, the cataloger adds the <dsc> portion directly to the file in XMetaL using a series of keyboard macros. For longer contents listings, we find it more flexible to create the text in Microsoft Word, convert that document into XML using the Microsoft SGML Author for Word software described below, and append it to the XML file. Using SGML Author for Word to encode the text involves the following tools:

Microsoft Word for Windows 95 Generic, off-the-shelf version. Microsoft SGML Author for Word A Microsoft application that is a generic tool for transforming Word documents into SGML instances (and visa versa). The converter works by associating a Word "style" in the source document with a corresponding SGML element. For example, the MHS inventory template includes a style called "BiogPara." During conversion, the text defined by that style is wrapped with the EAD string <bioghist><p>...</p></bioghist>. Microsoft Templates, Styles, and Macros Locally developed applications of standard Word features. Styles produce a consistent presentation by applying to document text standard, predefined font types, sizes, and weights, tabbing, indention, and line spacing. They are embedded within templates which carry standardized "boilerplate" text and which serve as the basis for the conversion to SGML process. Macros are used to facilitate the application of styles and reduce the number of keystrokes required. The creation and use of these functions are described in any comprehensive Word manual. SX A freeware SGML parser that also converts SGML files to XML syntax. Using SGML Author for Word to encode the text involves the following steps: Open a Word template and draft the contents listing. This is done by the processing archivist. Once the editorial review process is complete, the text is forwarded to the departmental conversion coordinator who completes the remaining steps. Create the EAD instance: run the SGML Author converter by selecting the Save As SGML option on the Word File menu. Run the sx.exe application to parse the resulting SGML document and convert it into XML syntax. Append the file to the end of the document create in XMetaL as described above.

Finding aids begin as either MS Word files or papers copies. In cases where OCR is necessary, we use OmniPage. Finding aids are marked up in EAD2002 using XMetaL 4 (Author) and locally developed templates. Macros are used to ensure regular mark up and provide consistent boilerplate text. A local XSL stylesheet is used to test each EAD instance for conformity with the MHS template and best practice. The Verity index must be repopulated after new files are added or changes are made to previously posted files.

Prior versions of our finding aids were equally divided between paper originals and electronic documents (Microsoft Word and Word Perfect) while a few had been previously encoded in EAD 1.0. Paper documents were scanned and run through OCR, and all files were then manually encoded in NoteTab according to a template developed by the Archives. Steps were taken wherever possible to bring description up to DACS standards. New finding aids are written and encoded directly in NoteTab.

Descriptions are being created directly in XML compliant EAD using the commercial editor XMetal. The EAD DTD was downloaded into the software directly from the EAD Cookbook. The Project then specified the EAD elements and attributes required for 6 levels of ISAD(G)2 description, informed by the crosswalk provided in EAD Guidelines. A data formats manual was then produced for cataloguers to follow.

An XMetal template was developed for completing the top level of description. This includes the comprehensive sequence of EAD tags specified, with default required attributes already completed. The template includes the areas <eadheader>, <frontmatter> and the <archdesc>. Any default text is already completed for the cataloguers. Tags indicating sections of the document are colour coded in the DTD for easy visual reference, as are tags required for incidental marking in paragraph text eg <date> and <persname>. In addition different sections of the template are given background colours corresponding to their ISAD(G) Areas, to enable a cataloguer fast identification of their position in the document. Areas where text has to be inserted are clearly marked using the XMetal <?xm-replace_text> command along with additional instructions and cross-referencing to the cataloguing manual. Comments in red font guide the completion of attributes.

Macros were programmed to automate the insertion of lower levels of description. These follow the same format as the top level template, but include progressively fewer ISAD(G)2 elements in compliance with the standard. Macros were also programmed to insert incidental tagging sequences, which could not be anticipated in paragraph text such as bibliographic references and lists of related material. These can be inserted as and when required.

Descriptions are automatically validated against the DTD by XMetal when the file is saved. Parsing is undertaken by Edina and any problems encountered revert to the NAHSTE team for editing. Subject, personal name, corporate name and geographic name are indexed, as separate index points, using 2 Microsoft Access databases to control which terms have already been inserted, their unique identifiers, normal form and their format. Subject and geographic names are chosen from Library of Congress Subject Headings, while personal and corporate names follow the UK National Council on Archives Rules for the Construction of Personal, Place and Corporate Names (1997). The unique identifiers are being used by Edina to generate the structured serach indices for the final website.

EAD guides are currently being created in XMetal 2.0 by manually entering data.

Most EAD files published by NYU were created using an MS Excel template in concert with a NoteTab clip. Troubleshooting and ongoing editing of EAD files is done with NoteTab utilizing Chris Prom's EAD configuration.

As collections are processed or updated, an EAD-encoded finding aid is constructed in XML using XMetal 3 in conjunction with NoteTab Pro. Sometimes the container information is entered straight into XMetal; most of the time the lists are created in Microsoft Word or Excel. We have a macro in NoteTab Pro, developed by consultant Christopher Prom, that converts our Word documents into EAD-tagged container lists.

The North Carolina State Archives uses a modified template based on the NCEAD standard template, NCEAD Best Practice Guidelines, and DACS, to encode its finding aids in NoteTab Pro.

At Old Dominion University finding aids are found in a variety of formats: print, word-processor files, and HTML files.  The finding aids in electronic format were largely derived from the print finding aids via scanning and OCR software--and finding aids for new collections are being created as Word files.  The finding aids that we have encoded to date have all been available previously in electronic format.  We began creating EAD 1.0/SGML files using MS Word and a template adapted from Duke University ( http://scriptorium.lib.duke.edu/findaid/ead/ ). Later, we replaced this process with a Web-based form to allow for consistent creation of the EAD files. We also have begun using Emacs/PSGML to encode those finding aids which differ from our template, and to edit already created SGML documents--and are exploring the use of SoftQuad's XMetal. After the SGML document is created, it is validated with James Clark's NSGMLS, and converted to XML using James Clark's SX (both programs are part of the SP package available from http://www.jclark.com/sp/ ). The XML document is then indexed using Perl's XML::Parser module ( http://wwwx.netheaven.com/~coopercc/xmlparser/intro.html ) into a freely available relational database called MySQL ( http://www.mysql.com ). Once created the indexes can be searched from a web-based interface which uses Perl to manipulate the MySQL database ( http://libstaff.lib.odu.edu/sgml/bin/ead/ead-search.cgi ). These processes (creation of SGML, SGML->XML, XML->MySQL, XML->Interpreted MARC record) are conducted via a web interface ( http://libstaff.lib.odu.edu/sgml/bin/ead/ead-toc.cgi ) Further information can be found at: http://libstaff.lib.odu.edu/projects/ead/

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.

Our process is completely automated. Collections are described fully in an MS Access database. Then, we use VB scripts to create valid XML files compliant with the EAD DTD version 2002.

Using Internet Archivist for encoding, which automatically generates HTML, SGML or XML docs, starting with legacy printed finding aids, and also preparing new finding aids. Legacy finding aids are rekeyed into INternet Archivist

Guides without electronic copy typically rekeyed or, if original is clean enough, through scanning and OCR. However, scanning typically proves to be unfeasible. Inventories are generally created in MS Word or in FileMaker Pro databases.  Information stored in database form is exported as tab-separated text and then marked up using MS Word macros written in house. Parsing is done using toolkit created by Alvin Pollock of the University of California at Berkeley, which includes various parsers that are EAD version 1 savvy.  Errors are then fixed using DeskEdit. Guides are listed by main topics from the Dept. of Special Collections home page and are indexed via the RLG Archival Resources program and through U.C. Berkeley's Sunsite2 server as part of the American Heritage Virtual Digital Archives Project.

With previously created finding aids we start at one of two places. Recently created finding aids, one to five years old, have the finding aid stored on computer in a .txt format that can be accessed by the "editor" component of the Internet Archivist - EAD software and can be "cut and pasted" into the appropriate input fields of the software. Older finding aids exist as paper finding aids only and everything must be typed into the correct software input fields.

Older finding aids exist as paper finding aids only and everything must be typed into the correct software input fields. The instances are marked up as the correct information is input into the correct fields of the Internet Archivist - EAD software.

Yes, the software allows and we use templates for most of the information that is generic to each of our finding aids.

Currently only manual observation and checking of the generated results in SGML and HTML exists.

No indexing necessary, there is a rudimentary search engine.  There is the option of adding search terms to the EAD document that will become terms searched by the search engine.

We entered the mark up world with little or no need for retrospective conversion so our documents are "born digital." We mark up our documents using the WordPerfect SGML editor and have been very pleased with it. We have automated many of the more complex nested tag arrangements required at the item level by creating Word Perfect macros. This has worked so well that we have student employees that can mark up large finding aids after only a short supervised training period.

Legacy finding aids (electronic): If a MARC record exists for the collection, a skeleton EAD template is generated from it using marcedit, a free product developed by Terry Reese at Oregon State; if not, we use XMetaL to create a skeleton EAD beginning with the pre-filled template and generate the necessary information, including appropriate controlaccess elements. Tagging of inventory is done through a combination of search/replace in Word, strategic use of Excel, cut-and-paste, etc. We are also, where applicable, identifying related collections and using extref elements within relatedmaterial to add links between them. XMetaL validates the document against the EAD 2002 DTD; we also run it through RLG's EAD Report Card. A final QA is done on the HTML output.

Legacy finding aids (paper): Text is OCR'd in-house, then same process followed as for electronic. See also outsourcing below.

New finding aids: Created directly in EAD using our template.

Entities: We use entities for a few items such as the name of the institution, the name of the library, the link to our OPAC, the link to our subject listing of collections, and a few other items, so when/if those change we will not need to revise the EAD files.

Outsourcing: We have contracted out one set of approximately 850pp to a local company, Amcon Research, for OCR and tagging to our specs, with very good results, and have identified another 550pp for them to do.

Conversion of existing finding aids from all ten repositories (ca. 46,000-50,000 pages) will be done by Apex Data Services before the end of 2000. Project participants have received EAD training and have agreed to a basic encoding scheme for new finding aids, for which XMetaL 1.2 software will be used.

After the successful completion of this initial phase, we hope to secure more funding and broaden participation to other Texas repositories. Digital images will be added.

We currently have around 200 finding aids on our site. Most of the information is entered into databases while the archival material is being processed. When we are ready to create a new finding aid we export the selected material out of our databases and assemble the final product using NoteTab. NoteTab is used to make final adjustments to the document, to parse it and to transform it.

Since 1995 the UC Library has employed a wide variety of techniques to encode our legacy finding aids into SGML. This reflects the wide variety of formats these documents were in. As we began our retrospective conversion with The Bancroft Library's electronic finding aids--authored originally in WordPerfect--we began by employing WordPerfect macros of varying sophistication. The lead programmer provided intensive training in the WordPerfect macro language in the form of a series of seminars. The original WordPerfect macro manual used within the unit (which is now somewhat out of date) can be found here.

Since the beginning of the project we have utilized the technique of stepwise refinement to encode legacy finding aids. A practice we have continued to this day. Stepwise refinement involves beginning the encoding process by adding "coarse" markup, essentially fitting the legacy information into a broad hierarchical structure consisting of little more than component information. The a variety of techniques are employed to add more markup of an increasingly finer granularity, e.g., next adding the unittitle information, then encoding unitdates, etc. Most of these subsequent passes were performed also using WordPerfect macros, but as the project progressed the perl programming language was employed.

Today, every member of the Digital Publishing Group has completed 5 week classes in perl programming through the University Extension program and perl has become part of our markup lives. We have created a small toolkit of simple perl programs which is available at: http://sunsite2..edu/oac/toolkit. The kit is composed of several small scripts useful for stepwise refinement including scripts to recognize and encode unitdates, persnames, and corpnames within unittitles. The toolkit also includes a preconfigured parser (nsgmls) used to validate each and every finding aid before it is submitted for publication on the OAC.

Before long we found that we could more efficiently encode a finding aid's "front matter"--that is, all of the information not occurring within the dsc--through a standard web template. This proved faster than trying to create macros or specialized programs to accomodate the wide variety of layouts in the finding aids produced by the eight contributing repositories at UC . The templates can be seen in action at: http://sunsite..EDU/FindingAids/uc-ead/templates and the cgi script we use is available for anybody else to use part of the toolkit.

Curiously, we have found that using commercial SGML editors such as AdeptEdit, Author/Editor, or XMetaL, was not an efficient way to convert legacy information into EAD. Although each member of the Digital Publishing Group has copies of XMetaL installed, we find it useful solely as a reference tool, particularly while bringing new encoders up to speed in EAD. It is far faster to programmatically convert text to EAD in broad strokes than to apply the copy and paste method required when using these editors. XMetaL may have a role in the authoring of new finding aids, but much customization--mainly in the form of targetted dialog boxes and refinement macros--needs to be done before finding aid authors can consider it a viable replacement for their trusted word processing program.

After we completed conversion of all of our word processing files for legacy information held by Berkeley and by many of the affiliates of the Online Archive of California, a process funded by a variety of grants, we turned our attention to all of the legacy finding aids available only on paper. These we contracted out to a conversion vendor, Apex Data Services, which keyed the data and generated EAD. This EAD was then further refined in house when the data was returned. Our experience with employing an outside vendor for the process was fairly good, far better than our earlier experience using scanning and OCR in-house. Most finding aids required very little editing and correction but a small few of the more complex variety required great deals of time to bring up to local standards.

We are investigating a variety of options for incorporating EAD directly into the authoring process, including a complete suite of MS Word templates and macros, dubbed "EAD Stylus", and available as part of the toolkit. Another option is to more fully integrate EAD into the Generic Digital Projects Database, developed initially for UC 's role in the Making of America II project. The Generic Database was designed to accomodate the workflow and data entry for 's variety of digitization projects including images, electronic text, sound files, moving pictures, etc. As it was intended to accomodate hierarchical description and produce arbitrarily generic output, it was easily adapted towards EAD.

Relational databases have taken on a larger role at in recent years. We now can easily import EAD-encoded finding aids into any arbitrary relational database--for enriching the data, adding item-level information for digitized surrogates, collection management, etc.--and exporting back out to EAD or serving out on the web. A tutorial and several sample programs written in perl are available at: http://sunsite..edu/ead/eaddb .

Now that conversion of our legacy finding aids is complete we are involved more and more in digitizing surrogates of the archival materials themselves: selected photographs, books, diaries, letters, both represented by images or sequences of images, and as searchable electronic text encoded in TEI. We are committed to using the emerging METS standard for encapsulating single and multipart digital objects in XML "wrappers." More information on these efforts is available on our Making of America II website.

Since the earliest days of the project, has realized the importance of developing and adhering to consortial standards. The EAD encoding standard allows a surprisingly divergent, and often distressing, variety of encoding methodologies. In 1996 four institutions, UC , Stanford University, Duke, and the University of Virginia, met to develop a uniform encoding standard for EAD finding aids. This standard, the American Heritage Retrospective Conversion Guidelines , was adopted and later developed upon and refined by the UC EAD consortial project which later grew into the Online Archive of California . Recently, the Online Archive of California has developed a standard for the encoding of new finding aids, the Best Practices Guidelines for the Encoding of New Finding Aids, which builds upon those guidelines layed out in the Retrospective Conversion Guidelines. Although intended for new finding aids, the BPG provides guidelines which are beneficial to all finding aids. Although we foresee difficulties applying the full BPG to our "legacy" EAD documents we are involved in a process of upgrading them to a subset of BPG programmatically. This involves, most importantly, stripping out the old style <drow>/<dentry> tabular markup employed in the early days of EAD at , and combining the separate Series Description and Container List into a single <dsc> of type "combined".

Finally, UC has no plans at the present time to begin encoding finding aids in XML. First, all of our current tools handle both XML and SGML so there is no reason for us to switch. Secondly, the XML standard lacks the robust entity management mechanism present in the SGML standard. We have found this entity management to be crucial, especially when interchanging finding aids with other institutions and consortia (hard-coding a specific path or URL in every entity declaration is onerous). If new tools become available for either authoring or publishing, which require XML and which we would find valuable, or if stronger entity managment is included in a future version of the XML standard, we would like to switch over.

All of our raw SGML files may be accessed in the SGML section of the Online Archive of California: http://www.oac.cdlib.org/sgml

In the Mandeville Special Collections Library, description of manuscripts and archival records is first entered into an in-house database application created with Microsoft's FoxPro 2.6 for Windows. Once the quality and integrity of the description is assured, the description is output, using pertinent database report forms, in the form of a printed finding aid or a digital finding aid in EAD, HTML, and ASCII modes.  The EAD output is validated using a parser designed by Alvin Pollock of the Text Encoding Unit at UC, .  It is then mounted onto a UCSD Libraries server as well as a California Digital Libraries server.  Once mounted on the UCSD Libraries server, the database of EAD finding aids is indexed using the Verity Query Software.  The parameters for this indexing are established by systems staff in accordance with the wishes of MSCL staff, but the process itself is done as part of the output process. Construction and use of the MSCL finding aids database relies on five software packages: A) 

A processing database application created from Microsoft's FoxPro 2.6 for Windows.  This application allows us to normalize finding aid structure and to output simultaneously three modes of digital finding aids.  It allows all of the encoding (EAD & HTML) and text formatting (paper and ASCII) to be predefined and executed automatically.  That means the generation of particular instances can be done more quickly and, if desirable, at a lower level staff. B)  EAD parser designed as part of the UC-EAD project. Every newly generated EAD instance is validated with the parser before being mounted on the server. C)  Verity Query Language used to index the EAD finding aids database and allow for cross collection searching. D)  Softquad's Panorama (or some parallel) that allows the client to access the native ead files. E)  An HTML browser which allows the client to access the HTML files.

Most guides are written using Notetab or Notetab Light. This application uses clip libraries adapted by Elizabeth Konzak from libraries originally created by Chuck Thomas. The arranger enters the content when prompted and the EAD markup is added automatically. The XML is transformed to HTML within Notetab Light by code developed by Chris Prom, which uses the Msxsl.exe utility that invokes the Microsoft XML Parser and a stylesheet adapted from the EAD Cookbook by Judith Beale. More complicated guides are written directly in XMetal using templates created by Judith Beale. The tranformation uses the same stylesheet and XMetal's internal transformer.

After a review of commercial sgml encoding products the University of Chicago Library decided to create an encoding program in-house. We decided that the best way to encode a finding aid was to separate it into sections. A finding aid can be conceptually split into two distinct parts, the front matter, which is information about the finding aid itself, and the container listings, which describe the actual contents of the collection.  In order to automatically markup finding aids using our program, the finding aid must first be in electronic form (Word file). This can be achieved by either scanning or re-keying the document. The front matter is marked up using an HTML form (template). The relevant information is cut-and-pasted into the template fields and then run through a cgi-script written in Python 1.5 which outputs marked-up text to a file. This part of the program takes cgi variables and marks them up, formatting them slightly and producing the first part of the finding aid. The second half of the finding aid (container listings) is marked up using a program designed especially for this project, which searches through a text file for patterns and keywords, and outputs marked-up text to a file.

When these two files are joined together, we have a completely encoded finding aid, viewable with an SGML browser. The program examines the text line by line, looking for an indicator we have inserted () to mark the beginning of relevant material. When it finds the indicator, it then starts scanning for keywords such as Folder, Box, Series, etc. Each keyword prompts an action, or subroutine. As the program can only really look for patterns, anomalies can cause problems. The program was written to do the bulk of the work, but hand editing before and after running the program may be necessary.

Currently, inventories as well as full scale finding aids are created in XML (NoteTab).

EAD XML finding aids are encoded using the Notetab Light application. Using a clip library created by John Nemmers (UF) and Chuck Thomas (FCLA), a staff member answers questions and enters data when prompted and the finding aid in marked up automatically. This method generally is not used to mark up the <dsc> section of the finding aids. Instead, box/folder contents lists are first input into MS Excel and then copy/pasted into the EAD file. Descriptions at the series, sub-series, etc., level are input using the Notetab clip library method. The XML instance is automatically transformed to HTML using Saxon and style sheets adapted from Michael Fox's EAD Cookbook.

Descriptions are created as word processor documents in Microsoft Word, using a template which structures the description according to the elements of ISAD(G). The document creator uses dialogues provided by Word macros to provide additional structuring of the text at the sub-paragraph level. (Where non-digital descriptions existed, they have been re-keyed). The SGML markup is provided by a Word macro which processes the (highly structured) Word document produced by using the template described in the previous paragraph. The Word conversion macro maps the ISAD(G) elements to the appropriate EAD element types, generates standard EAD header information, and outputs a complete valid EAD-encoded document. (N.B. the macro is *not* intended as a generic Word-to-SGML tool: it is designed specifically to process the structured document which is produced from using the template in a controlled manner.) Some limited checking of structure and content is performed by Word macros either at the time of document creation or at the point of conversion to SGML. That SGML document is then processed and validated by James Clark's NSGMLS parser. The SGML document is converted to an XML version using James Clark's SX, and that provides the input for the XSL(T) processing described above to generate HTML renditions. The document creator uses a thesaurus lookup procedure for all access point terms to ensure that occurrences of such terms (a) have a standard form and content, and (b) are associated with a unique identifier for the entity which acts as a pointer to an archival authority record for that entity. At the time of writing (October 1999), however, we do not have a search and retrieval tool which can fully exploit that markup. Some very basic static index pages for the descriptions are currently generated through the use of XSL(T) stylesheets. All the HTML renditions of our descriptions contain (as HTML meta elements) basic Dublin Core metadata derived from the content of the EAD header and archdesc-level controlaccess elements. We are also experimenting with the generation of RDF-based metadata for the finding aids. At present, this employs the semantics of Dublin Core, but we envisage that it could be extended to incorporate other metadata schemas as required.

We create all of our EAD finding aids from scratch using Xemacs Open Source Text Editor. Xemacs has proved to be an excellent tool for creating and editing EAD, it is very easy to use and incredibly stable.

Our legacy finding aids are primarily in Microsoft Word and follow a standard format. We have been rekeying finding aids when necessary, rather than using OCR.

We use a two-step process:

1) Microsoft Access database. This relational database, which was created by the staff of the Archives and Manuscripts Department, reduces workflow by also working as a collection management tool. Staff use the database for accessioning and record-keeping purposes. The finding aid is a natural end to this process. Fields in the Microsoft Access database are mapped to correspond with EAD tags

2) Conversion. Using a converter program written in Java that communicates with the Microsoft Access database using Java Database Connectivity (JDBC) staff are able to convert database records into XML files in a matter of seconds.

For about ten years Bentley finding aids have been created in Microsoft Word (currently WORD 6.0) using a WORD stylesheet to control formatting. Some older finding aids have been OCRed and then formatted and updated using the WORD stylesheet.  The stylesheets identify most elements of the finding aid  in a way that can be used for automated conversion to EAD. 1) Finding aids are created/edited in WORD to conform to the latest version of the stylesheet. 2) Several WORD macros employing the stylesheet codes are run on the container list portion of the finding aid to convert it to an EAD document. Macros insert proper <C0x><did><unittitle><unitdate><physdesc>and<note> tags. Other macros convert MARC controlled access terms, various lists and indexes to appropriate EAD tags.

In the current conversion process, the data from legacy finding aids is input into a DACS-compliant MS Word template, and macros are used to apply appropriate EAD tags. Simultaneously with the retrospective conversion, new finding aids are being authored in MS Word and converted to EAD.

The bulk of retrospective encoding was accomplished during a year-long project (2004-2005) funded by an internal grant. Project staff primarily used XMetaL along with a template developed to encode all finding aids. A number of basic finding aids were created from existing MARC records by the Libraries' Technical Services staff using a macro developed in-house. To encode new finding aids, staff are using a combination of approaches, including converting from Access and Filemaker databases and Excel spreadsheets, as well as the XMetaL template. Details on the progress of the encoding can be found in the reports and other documentation available at http://wiki.lib.umn.edu/Staff/FindingAidsInEAD

We have used NoteTab for several years to mark up all new and all modified finding aids in EAD. We're doing some legacy work on word-processed finding aids that are not marked-up in EAD and on paper finding aids, but, like most everyone else, only when time and funding permit. So we have MANY paper-only finding aids, but no ongoing project aimed at making EAD-encoded versions of these documents. These legacy finding aids are keyed in as with EAD markup when the collections they represent are reprocessed under special projects or because of additions or other changes that warrant finding aid revision. Processors produce EAD marked-up finding aids in NoteTab using templates that we developed in cooperation with NC EAD, a subgroup of NC ECHO (North Carolina ECHO, Exploring Cultural Heritage Online, the state�€™s doorway to the special collections of North Carolina's libraries, archives, museums, historic sites, and other cultural institutions). Completed finding aids are reviewed by the processing supervisor (most of our finding aids are written by graduate students). The departmental cataloger does the final editing, adding the controlled access terms; creates the HTML version; mounts the versions on the web; and does the MARC cataloging, which includes an 856 linking field to the finding aid. Through the abstract and controlled access fields, we include all information from the MARC record in the EAD-encoded finding aid. We do name and subject markup in the EAD-encoded finding aid (content tags) within the scopecontent at the collection level only (we call it a Collection Overview).

We have had computerized finding aids since 1983 maintained in a database system which we developed ourselves. Early in 1994 we made public finding aids available via the World Wide Web as HTML files with a facility to search our databases interactively. Before the development of EAD we put paper finding aids into our database system. Since we have been using EAD, we have done some scanning and optical character recognition of finding aids that had not been previously included in the database system. We experimented with various specialized tools available (the usual suspects) but ultimately preferred to use plain text editors, macros, and programs we developed ourselves, along with freely available parsing software. EAD Javascript: http://classic.archives.nd.edu/ead/ead.htm EAD control Javascript: http://classic.archives.nd.edu/ead/dsc.htm Eadit - Java applet: http://classic.archives.nd.edu/ead/

The Javascripts seem to work better with a greater variety of computers and browsers than the Java applet. They are also easier to modify, since the source code is always available to make changes appropriate for different repositories with their different policies. We wrote programs to automate most of the markup of finding aids we had in our database system. We use James Clark's NSGMLS and his other programs to parse EAD finding aids. We have also used Larry Robertson's SP Wizard as an means of invoking NSGMLS and fixing mistakes and Eric G.V. Fookes' NoteTab for markup, invoking the parser, and fixing mistakes. We have found all of this (free) software to be excellent -- highly reliable and easy to use. James Clark: http://www.jclark.com/sp/ SP Wizard: http://www.eccnet.com/sgmlug/spwizard/ NoteTab: http://www.notetab.com/

Presently we use programs we wrote ourselves to index every word in the finding aids and make them searchable via the Internet. We expect to keep improving our indexing system, which is presently only a little better than what we had before EAD.

We are in the very beginning stages of doing anything with EAD. So far, we have sent IN HARD COPY all of our registers (save one) to Pacific Data for conversion to SGML. We did one register from an existing WordPerfect file in house. Both processes have been time consuming: the former because of corrections and review, the latter just because it was horrible to cut and paste and do a first one. Nothing we do here has an automated quality to it.

Our EAD project began with the New Australia Newspaper collection (a unified digital collection created from sources shared between the State Library of N.S.W. and the University of Sydney Library.)   The finding aid created for this collection (which will expand to include other resources in 19th century and early 20th century Australian labour history and incorporate other holding institutions) was created from scratch, ie straight to mark-up.  We have also worked on previously created print indexes to non-catalogued manuscript collections in the University of Sydney's Rare Book and Special Collections library.  An EAD template was created for the conversion of these indexes from simple ASCII files to EAD-compliant finding aids. Creating the files has been with Author Editor, but also and increasingly with the non-SGML-aware text editor available on our main server.

We begin with WordPerfect files -- we've had to rekey or scan virtually all we've done. We then cut and paste our front matter text into templates we've had developed for us following the model. We also have a utility that marks our container lists by responding to embedded characters. Therefore, in the rekeying of container lists, we add certain characters which the program turns into appropriate mark-up. For example, a file that reads #b 1 #1 Folder title *date #2 Folder title *date  will come through the utility marked up as <c02><did><container type="carton">Carton 1</container><container type="folder">Folder 1</container><unittitle>Folder title</unittitle><unitdate>Date</unitdate></did></c02> <c02><did><container type="carton">Carton 1</container><container type="folder">Folder 2</container><unittitle>Folder title</unittitle><unitdate>Date</unitdate></did></c02> When both the front matter and the container list have gone through the utilities, we merge them by hand in an ASCII editor and tweak the mark-up. Then we move the merged file to WordPerfect and tweak it some more. We use WordPerfect only at the end because it's not as flexible as an ASCII editor. For example, WordPerfect won't let us work with one part of a tag set at a time, the way an ASCII editor will. Thus, we find inserting large wrappers not included in the template takes a long time in WordPerfect, and is fairly simple in an ASCII editor. After we parse it through WP, we move it to our DynaText software for publication, and from there it goes into the web.

See: Virginia Heritage

New lists at the Centre are being prepared using EAD version 1.0. The catalogues of the Trades Union Congress archives 1960-70 and 1920-60 supplement have now been converted from word processed files to EAD via the RLG's APEX conversion project. A one year project launched in August 1998 to encode the Modern Records Centre's 'Summary guide' into EAD has now been completed. Approximately three quarters of all entries in the 'Summary guide' now have links to EAD encoded collection level descriptions, which now total some 500 files in number. We have had a project to compile collection-level finding aids since last March [1999]. A simple template was designed as the basis for all our EAD encoded finding aids to ensure consistency. This is regularly reviewed and improved, such as the addition of file entities in the version 1.0 template. The Modern Records Centre uses Softquad's Author/Editor 3.5 for creating and editing EAD encoded finding aids. The Softquad Panorama browser is used to display the SGML files. The initial development of a template in EAD and early attempts to display SGML files did prove difficult and documentation relating to the programs was found to be wanting. However, once these problems had been ironed out, experienced staff could teach the use of the programs to others quickly and easily.

Our EAD methodology is available at http://www.archives.state.ut.us/referenc/ead.htm but may be summarized as follows. Our finding aids had been in a Folio infobase for a number of years. Prior to that they were partly on paper and partly in WordPerfect, but were scanned and added to the Folio infobase. The contents of the Folio infobase were then extracted to Rich Text Format files, one file per finding aid, after which we ran search and replace commands (using HomeSite 4.5 because one command would update all the hundreds of documents at once) to replace the Rich Text formatting codes with EAD codes. The container lists were converted to WordPerfect tables. When in a table, they were then saved as merge files, which were then merged using forms that wrapped the XML markup around each table cell. The finished finding aids were then validated against the EAD DTD using XMetaL. Currently, all new markup is being done in XMetaL. When a finding aid is complete, staff looks at it using XMetaL's "page preview" feature, which uses one of our stylesheets to convert the document to HTML. That copy is printed and used as a draft for editing. After editing, the XML document is run through another stylesheet using XT on a command line, and the resulting HTML document (with its associated XML master document) is placed on the web. If an HTML document is large and would be troublesome for downloading to a browser, the contents are broken up into multiple HTML documents but the full finding aid is also then converted to PDF to make it easier to print. To create the PDF file, two stylesheets are used (the first one creating the other one) using XT and FOP.

In 1999, the Historical Society received an LSTA grant from the Utah State Library Division to convert its finding aids to EAD. We completed over 700 finding aids during the course of the project-virtually all the legacy finding aids (many of those not yet converted are for collections that need to be reprocessed). We continue to add finding aids as we process additional collections. We had earlier scanned and OCR's all typewritten registers and inventories describing the Society's manuscript and photograph collections. We published these, along with more recent WordPerfect documents, as text files on the Internet.

Our collection's catalog, found on RLIN and on our own web site, includes catalog entries for each collection. Those with finding aids have a link to these legacy finding aids. Using grant funds, we hired two consultants experienced in EAD theory and practice. They advised us about how to implement EAD and suggested work processes. We then developed processes that fit our requirements. A computer-literate project archival technician, with little training, carried out these steps.

The processes include MARC to EAD and additional conversions (to generate a narrative skeleton), Word or WordPerfect tables and merges (to structure the container list), and BASIC programs to add EAD coding for the container lists and to merge the narrative with the container list. We used XmetaL to complete the finding aid, cutting and pasting when necessary from the legacy documents, and to produce the final XML files. Our cataloger reviewed, proofread, and edited each completed XML file. We used James Clark's XT and stylesheets to convert each XML file to HTML.

Began with word processing files (Word and WordPerfect), html, database files (Dbase), and paper files. Re-keyed and OCR'ed in-house. Used web forms for all (header, frontmatter, etc.) except <dsc> The <dsc> is most frequently marked up using Note Tab. All guides are reviewed for quality-control through the central processing unit at the University of Virginia.

EAD files published by WCSU were created using an MS Excel template in concert with a NoteTab clip. Troubleshooting and ongoing editing of EAD files is done with NoteTab utilizing Chris Prom's EAD configuration.

As of February 2007 our site contains approximately 3050 finding aids comprising the equivalent of roughly 25,000 paper pages. 1150 of these were encoded from paper originals by Apex in 2000. The remainder have been encoded in-house, some from paper and some from word processing documents. Until recently we were encoding finding aids in SGML in Version 1.0 of the DTD, through the use of webforms, macros, cutting and pasting, and a series of find and replaces. The mark-up was completed in Microsoft Word and then validated in Author-Editor.

In preparation for the upgrade of our finding aid site to Version 2002, we now do encoding in NoteTab Pro using the EAD Cookbook 2002. We use templates for the narrative portion of the finding aid. For container lists, we use the auto box list feature included with the EAD Cookbook as well as manual mark-up using customized clips. For the few finding aids for which we do not have electronic copies, or for which we cannot create cleanly scanned copies, we use the forms provided in the EAD Cookbook 2002 or mark them up manually. Often a combination of these methods are employed on a single finding aid.

Prior to mark-up, finding aids are cleaned up in Microsoft Word and macros are run that insert entity codes for non-XML characters and clean up some formatting issues in preparation for mark-up. After mark-up, a final clip is run in NoteTab Pro that deletes unused tags in the template and ensures that component levels are nested properly. So far all of our mark-up is retrospective; we hope to begin applying EAD encoding to newly created finding aids within the next couple months. EAD work is done through a portion of my time; by my predecessor, Karen Baumann, who has stayed on part-time to work on the EAD project; and by part-time students who do most of the scanning and mark-up. Because our mark-up is generally not very deep and because we made the decision not to employ <controlaccess> since we already have a MARC catalog with these controlled terms, our EAD site's indexing is limited to three choices: keyword, collection title, and repository. We will be adding to this list title of work (play, movie, book, etc.) when the site is upgraded.

For Beinecke Library and the Divinity Library: Source files (ASCII for Beinecke; Wordperfect for Divinity) are run through a series of macros, developed in-house, which add markup. Some manual editing is required in all files, to add links, etc. . Instances are checked against IE. After corrections are made, instances are saved in UNIX format. Two-part HTML equivalents are made to accompany the XML instance (explained above). After this, they are ready to be indexed.

For Manuscripts and Archives: OpenOffice [ http://www.openoffice.org ] based template, which is then processed using XSLT and Perl to create EAD v1.0. For additional information contact stephen.yearl@yale.edu

The Yale Music Library has contracted with ArchProteus to convert WordPerfect or typewritten finding aids into EAD. ArchProteus supplies the Music Library with an XML instance (used for indexing in the Yale finding aid database) and an HTML version for end users.