EAD export uses incorrect tag for RAD Associated Materials notes

[Creighton Barrett]

Hi everyone,

We're running AtoM v2.4.1 in Red Hat and have noticed what might be a bug with the data mapping from RAD to EAD. I'm filing this report on behalf of Dalhousie MLIS student Nicole Slipp, who first noticed some inconsistencies with RAD note labels in our PDF finding aids.

RAD has three notes for describing "allied material": Associated materials (1.8B18), related groups external to the unit being described (1.8B20) and related groups within the same fonds (1.8B20a).

According to the RAD to EAD crosswalk [1], associated materials notes are supposed to go in an <separatedmaterial> EAD tag, and the related groups notes are supposed to go in <relatedmaterial> EAD tags.. 

However, we are now noticing that AtoM exports associated materials and related materials notes into <relatedmaterial> tags. 

The AtoM RAD template uses the correct labels, but the EAD export does not include the correct tag for associated materials. I can see that the script for converting EAD to full-detail PDFs [2] looks for <separatedmaterial>, but it only receives <relatedmaterial> data, so the script re-labels the Associated materials notes Related materials.

Disclaimer: Our local practice is currently to enter all three types of RAD notes into the Associated materials field in the AtoM RAD template because the "Related materials" drop-down list is difficult to use when there are lots of records in the database. The result is that our Related materials notes are technically mislabeled in the AtoM RAD template but receive the correct label in the PDF. 

I didn't see anything in the Forum about this, but I see a related issue about how <separatedmaterial> is dropped during import: https://projects.artefactual.com/issues/5211

Thanks,

Creighton

[1] Canadian Committee on Archival Description: RAD to EAD Crosswalk: http://www.archivescanada.ca/uploads/files/CCAD/CrosswalkEN_Nov03.pdf. 

[2] AtoM GitHub repository, EAD to PDF full details script: https://github.com/artefactual/atom/blob/qa/2.5.x/lib/task/pdf/ead-pdf-full-details.xsl. 

[Dan Gillean]

Hi Creighton, 

Keen eye! I've taken an initial look at this, and I think the issue arises from the fact that at present, AtoM only has 1 field that doubles as both 1.8B18 and 1.8B20 - you will notice if you click into the AtoM Associated materials field that the tooltip contains quotes from both rules. I don't know why this decision was made (template design predates me!), but it's what we're working with at present. 

As you found in issue #5211, this meant that we were dropping <separatedmaterial> elements on import. Since the EAD tag library associates both <separatedmaterial> and <relatedmaterial> with ISAD 3.5.3 (Related units of description), the easiest short term fix for 5211 was simply to make sure it imported. We are also crosswalking the RAD Allied materials field to the ISAD Related units of description, which is likely why we defaulted to using the EAD <relatedmaterials> element on export for this field. The ISAD standard used Related units for both "descriptions in the same repository or elsewhere" while RAD has these 3 different elements in the standard, but only the one field in AtoM. 

It is also worth noting that at present, the RAD  "Related materials" autocomplete field (which you are not using) is not actually added to the EAD XML at all. 

So... I can file a ticket for this, but what is the desired outcome?

To me, it seems that the ideal outcome would probably be: 

• Add 2 new fields to the RAD template for 1.8B20 and 1.8B20a
• Rename the "Related materials" autocomplete field to "Related descriptions" (as it is in the ISAD template)
• Add separate EAD mappings for the 2 new RAD fields, and update the import / export, search index, CSV templates, and XSLTs

That quickly becomes a project that is beyond the scope of what Artefactual can do without community sponsorship, however. 

Barring that, what would you consider to be the best mapping for this field? Should it no longer crosswalk to the ISAD Related units field? Should we keep the crosswalk, but have the ISAD template use <relatedmaterials> on export, but RAD use <separatedmaterial>? Something else? I welcome your input! If we hit upon a good solution, I would be happy to file a bug report. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAHueW_VzvR30Zk7W2Vnbm1EvRKvrv8iY2hoLAdE7wbdAQyoy4g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Creighton Barrett]

Hi Dan,

Thanks for the quick response! To be honest, I'm not sure what is the desired outcome! The ideal outcome you describe makes sense, but it is a lot of development for a relatively minor issue. I didn't check to see whether the RAD "Related materials" autocomplete field exports to EAD, so thanks for clarifying that it does not. 

I guess my thought was that the RAD EAD export could be revised so that data in the field labelled "Associated materials" was exported to a <separatedmaterial> EAD tag. That would eliminate (I think) the need to update the CSV template or XSLT (which already looks for <separatedmaterial>. But, from what you describe, that would also mean that the ISAD(G) EAD export would end up using the wrong tag for "Related units" information, which I hadn't considered.

Cheers,

Creighton

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZJkfai9PW67xd%3DBc2LnS%2Bh7Rd3tXaXpiUch7B8iG6wTAg%40mail.gmail.com.