I was able to replace the default AT stylesheet with our own stylesheet by following the directions posted earlier. We have our own version of the eadcbs5.xsl stylesheet from the EAD Cookbook.

I had to add the dsc7.xsl file into the eadcbs5.xsl stylesheet so it was all in one file (we had separate as the 2 files, eadcbs5 calling dsc7 into action). Once that was done, the file parsed successfully and I had some html to look at.

However, I didn’t like the html I got — it was slightly different than how it looks when we do the EAD to HTML transformation in Oxygen.  For example,  in the container list portion, when running through AT,  it didn’t suppress repeating Box headings and #s  (<container type=”box” > labels).  So if my Box 1 had say 70 folders listed, it repeated the word “box” and the box # for each of those 70 folders, when normally my stylesheet suppresses that for readability.

There were a couple of other small things, but that one was the dealbreaker.

We decided to just use the AT default stylesheet and tweak the html output slightly to meet our needs. We always had to tweak things a little anyway before posting them, when we created our on-line finding aids by using Oxygen (handcoding EAD and transforming to html).

This is a finding aid we made solely in AT and using the default stylesheet, with a post-output tweak or two.: http://library.rice.edu/collections/WRC/finding-aids/manuscripts/0333.

After a brief rest from inputting data, we are now poised to enter information about (some of) our digital objects. Generally these are digi-surrogates of our photographs, letters, diaries, and other materials.

We have a few hundred digital objects in scholarship.rice.edu (Rice’s institutional repository, running DSpace). Most of those were treated at the item level with lots of descriptive metadata, but some new ones from this semester are testing out the Meissner-Greene minimal processing theory on digital materials. That means there is significantly less descriptive metadata and an “item” in our repository might be one PDF for an entire file of correspondence, for example. Whoa!

After spending some time pondering who I would need to harangue into helping me make a nice EAD schema compliant stylesheet so that I can post my EAD out from Archivists’ Toolkit —  scratching my head over why neither LC nor the EAD Roundtable offer schema compliant stylesheets — I made a humbling discovery.

I don’t need a schema compliant stylesheet if I’m using AT.

AT outputs html as a report, using a default stylesheet which looks like those from the EAD Cookbook by Micheal Fox. So it’s basic and bare, but clean and simple.

Sigh. Silly me.

Why did it take me this long to figure this out? Is this what I get for not reading the AT manual cover to cover? I just assumed that to get a web-worthy finding aid  out of AT you need to “Export EAD” from the Resource record. But no!

Page 194 of the version 1.1.1 AT User Manual (http://archiviststoolkit.org/ATUserManual/1_1/Chapter%2014.pdf) says how to use the Reports button to output html.

Then I saw that Christopher Curry had asked the AT list about putting your own stylesheet in so that it serves as the default instead. See https://mailman.ucsd.edu/pipermail/atug-l/2008/000983.html.  Apparently it’s just a matter of placing your stylesheet file in the right place, as AT’s Lee Mandell says in response to Curry: “To use your style sheet all you need to do is replace the file > eadcbs5.xsl with your own (using the same name of course). You can > find that file in the directory where the AT application is within > reports/Resources/eadToPdf. “

So that can be done, it just isn’t mentioned in the User Manual or FAQs.

Next step – harangue our super-cool IT staff into helping me put our stylesheet in to place since I don’t have the authority to do that kind of thing.

Then I can stop being sad about my lack of stylesheet editing skills (for now) and start spitting out some nice, pretty finding aids.

Next finding aids to import:

  • Manuscript finding aids that gave odd error messages when we tried importing them (just a few)
  • Huge manuscript finding aids currently broken into parts (we have several of these, which need to be brought back together into 1 file each)
  • University archives finding aids

And now, we need to start editing existing finding aids in AT if needed, so we don’t have multiple version of finding aids running around, and we need a STYLE SHEET for our fancy new schema-compliant EAD so we can actually post new finding aids!

We have more accession records in and more finding aids in!
Lee has entered accessions up through 1981.
I have imported pretty much all the rest of our manuscript finding aids – all except for the “problem children”. We have a few LARGE finding aids which were split up into parts for the sake of quicker loading time on the web, so those need to be put back together and imported, I suppose.

Thanks go out to our Gal Friday, Susan Meadows (volunteer, soon-to-be-library-school-student), for helping to transform our DTD-compliant finding aids to being schema-compliant, and then importing them.
ps – Gal Friday Susan has changed her “day” from Friday to Monday but I’ll still call her Gal Friday.



I have imported about 100 finding aids, which covers as many finding aids as we have for our manuscript call #s 1-200 (some collections don’t have finding aids yet). Mostly that has gone well, except for a few finding aids with pre-existing problems. . . That puts us at about 1/4 or maybe 1/3 done importing existing xml finding aids.

So now we have lots of names and subjects populated in our “names” and “subjects” modules – exciting!

Lee has entered accession records through 1979.

Lee entered over 300 accession records this week and we have imported over 20 finding aids. Progress! The Name and Subject modules are really filling up now so we’re beginning to see how we can really work with our data!

We used the instructions on the EAD Schema pages to transform our EAD.DTD compliant files to schema compliant files — and it worked! Hooray!

Then we were able to import that ead file with no errors.

Onward to checking how well the file was handled in AT. Did all the pieces of finding aid information go where they should?

Alrighty, our group met this morning and decided to start with entering our accessions information. Lee will be entering that from our handwritten log, which was started in 1975. Go, Lee!  Should be straightforward data entry except for a few deaccessioned items whose call #s were later re-used.

Meanwhile, Phil, Lauren and Amanda will be working on making our EAD files vaildate against the schema and then batch importing those. We’re doing that now because our test import failed. :( Then we read the manual (smart idea!) and realized we need to just move to the schema now and then import. The only down side of that is that our state EAD consortium (TARO) still only handles EAD files using the DTD. Bummer.

Hmm. Our 300 + exisiting EAD files use the EAD.DTD to validate against, but the new EAD schema is really the more future-looking method.

Should we update our EAD files to validate against the schema before loading them into AT?

Follow

Get every new post delivered to your Inbox.