We’ve been busy working to get our Archivists’ Toolkit set up to produce RAD finding aids.  A key criteria for us was to have AT-exported EAD that more or less conformed to existing RAD/EAD matrices.  We wanted to know that EAD exported from the AT is EAD that can be manipulated into a RAD multi-level finding aid.  The Canadian Committee on Archival Description released this crosswalk in 2003.  Artefactual Systems, the developers of ICA A-to-M software, have an excellent crosswalk between RAD, EAD, ISAD(G), Dublin Core, MARC, and MODS (also available here).

These crosswalks make it easy enough to see how each RAD rule should be mapped to an EAD element.   What we didn’t know was how the various AT data entry fields exported to EAD.  I came across a couple AT import and export maps, which were really helpful, but they didn’t link the EAD elements to RAD.  We still needed to determine what AT data entry field or note area should be used for a given RAD rule.

And to complicate things even further, AT is built using terminology derived from DACS, the US archival description standard.  Many types of information are the same (e.g., a title is a title) as RAD, but many of the note fields in the AT are by default labelled differently than you might find in a truly RAD-based archival information system.  For example, the Physical Characteristics and Technical requirements note exports to the <phystech> element.  But the RAD/EAD matrices show that RAD Rule 1.8B9a for “Physical condition” should be mapped to the <phystech> element.  The Physical Facet note exports to the <physdesc><physfacet> element – the same element prescribed for RAD Rule 1.5C for “Other physical details.”

Once we got a handle on the terminology, we were easily able to edit the labels for the notes and a few other fields where it seemed like it would be helpful.  The note labels can be edited by using the Setup > Notes, Etc. box and the labels for other fields can be edited by using the Setup > Configure Application box and selecting the table that contains the fields you wish to edit.

The next step was to experiment with the EAD export.  I created a dummy resource record where all the fields were filed out.  It had dummy fonds-level notes, dummy file-level descriptions, dummy names and subjects, etc.  The data was just placeholder text so I could easily see in the HTML or PDF reports how the information was being displayed.

By comparing the EAD exported by the AT with the RAD/EAD crosswalks we began to get a sense of where the exports were mapped properly and where there might be potential issues.   Fond-level descriptions go into our OPAC as MARC records so we did the same with the MARCXML exports.  We needed a way to keep track of our findings so I copied the Artefactual Systems crosswalk into Excel, added a few columns for pertinent AT information:

  1. Description of the RAD rule – Usually cobbled from RAD itself
  2. Archivists’ Toolkit Data Entry Form – Indicates what AT data entry field, note area, or method of encoding should be used for a given RAD rule
  3. AT Export EAD – Indicates how the EAD actually looks when it is exported from AT (helpful to see when AT adds attributes, refs, etc. and to see if it deviates from the crosswalk)
  4. AT MARCXML Export – Indicates how the MARCXML actually looks when it is exported from AT (again, helpful to see where the AT deviates from the crosswalk)
  5. MARCXML Export Issues – Indicates any potential issues with using the AT to export MARCXML records in a RAD context
  6. EAD Export Issues – Indicates any potential issues with using the AT to export EAD records in a RAD context

I also added some rows to describe the areas of description that the AT allows for but are not prescribed in RAD (e.g., abstracts, legal status, etc.).

Anyway, I posted back in June about some of our findings as we were getting started with that project and I’m happy to say now that we’ve mostly finished updating Artefactual Systems’ RAD crosswalk with guidelines about how descriptive information should be added to the AT [1]. It is rough and will definitely be updated as we continue moving forward, but it is already helping us understand where we’ve been making mistakes and to develop procedures for data entry that avoids those mistakes.

So, in summary, here’s what we did to configure AT to generate EAD more in line with the Rules for Archival Description (lists of edited field labels are included in the RAD/AT/EAD crosswalk):

  1. Edit note labels to use language found in RAD
  2. Edit field labels in Resource table
  3. Construct a resource record where (a) every note is used at least once, (b) names and subjects are linked, and (c) every field in the finding aid data tab is filled out [2]
  4. Check AT exported EAD against existing RAD/EAD crosswalks and note errors, anomalies, etc.

[1] RAD/AT/EAD Crosswalk with lists of edited field labels and potential import/export errors for RAD users

[2] I can’t upload XML, ZIP, or TXT files but if anyone wants the dummy EAD record, I can send it by email.

Our next step is to customize the AT XSL sheets so the data is grouped according to RAD.  For example, AT groups the custodial history note under an “Administrative Information” section but we want to group it under an “Archival Description” section.  We’re making good progress with that, and will post the new stylesheets when they are finished.