As far as I can tell from your video, you're performing the import correctly. I haven't yet nailed down the specific source of the error message, but I suspect that this has more to do with supported EAC elements and mappings than anything else.
EAC-CPF XML, much like EAD 2002, is flexible enough that there are a number of different ways of serializing the same data within the standard - each valid, yet mapped differently. AtoM's EAC mappings were first implemented in 2010, and while they've received a few updates and corrections since, they haven't undergone major revision. They were also developed specific to what ISAAR-CPF fields AtoM supports, and how those are implemented, rather than as a generalized tool that can import any EAC-CPF file. Meanwhile, the EAC-CPF specification has been significantly revised since AtoM's main mappings were first implemented - meaning AtoM is due for some significant review and updating!
I ended up looking at the wrong file (this one
instead of the later sample), but at a glance, I can see some elements in the EAC export that AtoM doesn't support, or are mapped differently. Some examples:
- AtoM doesn't currently support the import of maintenance events. Everything in the maintenanceHistory elements would likely be ignored currently
- AtoM also doesn't currently import the structured <source> elements found in the SNAC EAC export.
- The SNAC EAC doesn't define what type of alternative name forms it includes - it just puts them in generic <part> elements, while AtoM will typically indicate whether it's the <authorizedForm> or an <alternativeForm> at minimum. I will have to test to see how AtoM handles mapping the name forms (and which ends up as the authorizedForm) when this information is not specified in the import file.
- In fact, it looks like the SNAC EAC uses custom attributes (such as snac:preferenceScore="99"), which are not part of the EAC specification, and will not likely be understood by any other application that can import EAC-CPF XML unless a specific custom mapping has been added
- The SNAC EAC file includes <citation> elements nested in <biogHist>. AtoM currently has no import support for these, so I suspect they would either be ignored, or their contents imported as plain text inside the biographical history
- The SNAC EAC file also embeds a lot of descriptive data from related collections in elements nested under <resourceRelation> elements. I suspect most of the nested elements (such as <physdesc> and <unittitle>) would be ignored, and may in fact be part of what's causing the import errors, as these are not actually EAC-CPF XML elements as far as I'm aware. I also don't see any namespacing in this file that indicates that EAD elements will be nested inside the EAC - I'm not sure if this is a common or accepted practice in an EAC-CPF file, but I haven't seen it done before
- Similarly, the SNAC file uses <cpfRelation> elements for relationships with other actors - but while the UI qualifies these relationships somewhat (associatedWith, etc), I see no indication of the relationship type in the export EAC. This too may be causing AtoM to throw errors, as it is unsure how to create the relationship between entities
- Note that AtoM will typically create local stub records (authorities or descriptions) when encountering related entities in an import file - AtoM's not able to follow any links provided and scrape further information, nor does AtoM's relationship module currently allow you to create links to external resources, so the name is used
Unfortunately, I suspect that the kind of bulk importing you hope to do from SNAC might not be possible without either some development work to enhance AtoM's current level of support for EAC elements and how flexible it can be with different serializations, or else spending some time to create a local XSLT or script of some kind that transform SNAC EAC exports into a format that AtoM can import.
As you may know, major development work in AtoM depends on community support for Artefactual to be able implement, either in the form of community code contributions, or via development sponsorship. You can learn more about the history of AtoM, as well as how we currently maintain and develop the project, here:
If you have in-house developers who would like to enhance AtoM's EAC-CPF support and contribute this back to the public project, we provide a number of development resources
on our wiki. Any local developers are also welcome to start a thread in our forum, and our team can offer some general suggestions and feedback. If, on the other hand, your institution might be interested in sponsoring work from our team to enhance AtoM's EAC support, or else would like our team to help develop a transformation script you could use, feel free to contact Artefactual off-list and we would be happy to discuss options and prepare estimates for you.
Finally, if it would be helpful, I'd be happy to try and recreate a SNAC authority in AtoM, and export it as EAC-CPF XML, so you can compare the output.