Archived posts for crosswalks:

RAD/Archivists Toolkit/EAD Crosswalk

No Comments »

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.

Some observations on AT for RAD finding aids

No Comments »

A few more general observations about the AT based on our migration project:

  • AT does not allow for multiple titles, extent notes, and other kinds of information. It would be really nice if we could, for example, add two extent notes to one file-level description.  We have find clever ways to deal with files that have 2 cm of textual records and 3 photographs.  The same goes for dates and titles.  Brigham Young University has created a couple plug-ins that provide this kind of functionality, but when I installed them, the new data entry fields covered over the existing extent and date information.  Apparently ArchivesSpace will be providing something to this effect.
  • AT is not suitable for RAD item-level description. It doesn’t have a space for statements of responsibility, edition statements, publisher/manufacturer information, and the publisher’s series area.   Some of this information could be merged into another data field, or provided in a general note, but it wouldn’t export proper EAD.
  • A lot of EAD fields don’t export to the proper MARCXML field. Many of the most important fields crosswalk correctly, but the GMD, parallel title, other title information, statement of responsibility, material specific details, and other key information export to an incorrect MARC field.  This may not matter – we’ve apparently been able to import an AT generated MARCXML file with no problem, but we’re only doing fonds-level MARC records so the more complicated data just isn’t there.

We’re working on expanding this RAD crosswalk to include AT data entry fields and the actual EAD and MARCXML exported from the program.  So far, it’s been a big help identifying places where the program is not suitable for RAD finding aids (e.g., statements of responsibility).  But we’re not worried about what we’ve found so far because most of the issues deal with file-level description or obscure data.  I’ll post the crosswalk when it’s finished.