Hi Katrina,
I will do my best to provide answers!
Cast, Credits, and Signatures
Unfortunately, I think you're right - they will import, but they will not export. These fields were added to AtoM via a community pull request. They were added to the user interface and to the CSV import, but the developer did not add them to the export, or to the EAD XML import/export. It would likely be a small piece of development to add them to CSV export, but so far no one has sponsored such development.
Appraisal
Nope! Sorry, I'm not sure how that snuck into our example CSV. AtoM's underlying data model was built against ISAD, and the CSV templates share many of the same fields. This one relates only to an ISAD(G) field, ISAD 3.3.2 appraisal, destruction and scheduling. The RAD standard has no equivalent field. As such, this column *would* import, but the data would only be visible on the ISAD template view, not in RAD!
Related materials
The RAD standard has a field called RAD 1.8B18 - Associated materials. In AtoM's CSV template, the CSV field is called relatedUnitsOfDescription (the name is drawn from the corresponding field in the ISAD template - AtoM was originally built around the ICA standards, and support for RAD was added later).
This is a free-text field, and is distinct from the autocomplete field available in the AtoM user interface called "Related descriptions," which can be used to link a description to another description held in the same AtoM instance. Unfortunately, there is no import for that field - though I imagine we could design one that would accept a slug as a parameter, and use pipe separators for multiple values. That would require development sponorship or a community-submitted code contribution for us to include in a future release, however.
Title and Statement of responsibility
In the CSV and AtoM's user inteface, there are several separate elements, rather than a combined one. CSV fields, with corresponding RAD standard field name and number:
- title
- alternateTitle (RAD Parallel title(s), 1.1D)
- radOtherTitleInformation (RAD other title infomration, 1.1E)
- radTitleStatementOfResponsibility (RAD statement of responsibility, 1.1F)
- radTitleStatementOfResponsibilityNote (RAD title notes - statement of responsibility, 1.8B5)
- etc (there are other title notes)
Digital objects and CSV imports
There are 2 fields you can add to the CSV for digital objects:
- digitalObjectPath
- digitalObjectURI
Both are used to link a single digital object to the current description. The digitalObjectPath column expects a file path to an object that you've added to your AtoM server. In this case, the objects must be on the same server as AtoM, in a directory accessible to you from there - so if your AtoM instance is installed at /usr/share/nginx/atom, you could create a temporary folder called images (for example) and add your digital objects there. In that case, if you had an image in that folder called image01.jpg and you wanted to link it to a new description via CSV import, then your digitalObjectPath value might be /usr/share/nginx/atom/images/image01.jpg. It's been a minute since I tested this, but it's also possible you can just drop the absolute path, and just reference the subdirectory - i.e. you could try adding just images/image01.jpg to the digitalObjectPath column and see if that works.
In contrast, the digitalObjectURI column is used to link to publicly accessible digital objects on the web. When this is done, AtoM will fetch the web version to create local derivatives (i.e. the reference display copy available on the description's view page, and the thumbnail in search/browse results), but it will not store a copy of the master object - instead, it will just save the URL pointing to it, and serve that link to users trying to access the master object via a browser.
AtoM's requirements for being able to link to remote digital objects using this method are: - They must be web-accessible without any barriers to access (no logins, firewalls, VPNs, etc)
- They must be HTTP or HTTPS links (FTP links won't work)
- They must end in the file extension of the digital object. You can't link to a landing page, unfortunately.
This last point means, for example, that you can't link directly to a YouTube video, for example - YouTube purposefully obfuscates direct access to the actual movie file (aka the .mp4 or .avi file) so you can't download it directly by right-click and saving. If you were looking at an image on a webage, you would generally want to right-click and select "View image" (or whatever your browser's equivalent option is) to see the direct path to the object that ends in .jpg, and this is the URL you'd want to use in the digitalObjectURI column.
The digitalObjectChecksum column is only used when a CSV is being used to update a description. If a checksum is present and it is identical to the current checksum stored with an associated description, then AtoM knows that, of the incoming updates in the CSV, a change to the digital object is not one of them, so it skip re-importing and replacing the current digital object.
I hope that helps! Let me know if you have further questions.
Cheers,