I received your file, and got a different error message when I first tried to import it - my error message said: "Unable to resolve host: undefined."
So, I opened your EAD file, and tried searching for "undefined" and sure enough - I found that listed as the base URL every time your site is reference, whether in the header, or when pointing to a digital object. An example:
Have you set the Base URL setting in your AtoM instance? This setting is found in Admin > Settings > Site information, and there should have been a big orange banner reminding you to do so when you first installed AtoM. See:
The base URL is used to create absolute URLs included in XML exports (e.g. MODS and EAD exports). For example, your AtoM site is made up a series of web pages. Each page has a full Uniform Resource Locator (URL) something like http://www.your-atom-site.com/your-description. The Base URL is the part of this URL that does not change - in this example, http://www.your-atom-site.com.
Setting this value will ensure that links included in your XML exports will be properly formed. Do not include a slash / at the end of your base URL - AtoM will automatically add this when building the absolute URLs.
I would try doing a find/replace in your EAD XML document to add any valid URL to this path - e.g. find "undefined" and replace it with "www.example.com
" and then try your import again.
One thing to note about roundtripping like this: the EAD XML file includes file path links to digital objects you'd uploaded in your original description... but if you've purged your data, then you've also purged these objects, so they will not be automatically pulled in and linked your your description. Instead, AtoM will go look for the object at the given URL, find it missing or inaccessible, note it in the log, and continue the import.
The CSV export will also provide a URL as the default path for a digital object. However, with the CSV, you can also optionally add a digitalObjectPath column. This column can point to a local file path on your AtoM server, and can upload your digital objects from there. Since it looks like your digital object file names are unique (based on the related reference code), this should be fairly simple to do.
This means you could create temporary subdirectory below the root AtoM directory and put a copy of all your digital objects in it, and then use this to re-link them once you re-import. For example, the default installation directory for AtoM (if you followed our recommended instructions) is generally /usr/share/nginx/atom. You could add a subdirectory here called "images", and then add your images there - e.g. A065600-16-001_141.jpg. You would then reference the full file path in your import CSV, in the digitalObjectPath column - e.g. /usr/share/nginx/atom/images/A065600-16-001_141.jpg
So, if you wanted to roundtrip with CSV instead of EAD, you could:
- Export your descriptive hierarchy as CSV
- Add a copy of all your digital objects into a local folder on your AtoM server - "images"
- Open the file in a spreadsheet application
- Find the digitalObjectURI column
- Change the header from digitalObjectURI to digitalObjectPath
- update each value in this column to include a file path instead of a URL
- Save the CSV and reimport
For example, this upload in your EAD file:
http://[BASE URL HERE]/uploads/r/clifton-suspension-bridge-archives/9/2/d/92df8a8fb4bb9ca1c404ee0e1065d9bde47a52a93435c03f39c9bad8373946d2/A065600-16-001_141.jpg
Anyway, let's see if we can get roundtripped imports working for you. Let me know if:
- doing a find/replace in your EAD file to add a proper URL value (even if it is example.com) will allow you to import the file, and
- if adding or updating your base URL will allow you to export and re-import an EAD file properly without manual edits