[Archivesspace_Users_Group] File Version HREF Attribute Incorrectly Assigned from EAD Exports

Corey Schmidt Corey.Schmidt at uga.edu
Fri Aug 21 16:05:39 EDT 2020


All,

I was able to fix this issue with Mark Custer's help. Huge shoutout to him for spotting the issue.

It turned out that the Solr Index was out of sync with the database. In Mark's words: "the EAD exporter will use the Solr index when it can....  [T]he index might actually be out of sync with the database, which could explain why you see those file URIs as published, but they are not being exported in the EAD because they aren't showing up as published in the Solr index." Since the EAD exports were being generated through the data stored in the Solr Index and the Index hadn't caught the updated File Versions (Publish = True), the export DO (Digital Object) href's were assigned the DO identifier.

A very similar issue can be found on this post in the ArchivesSpace listserv: Importing from AT to AS - File Versions left unpublished (http://lyralists.lyrasis.org/mailman/htdig/archivesspace_users_group/2019-April/006725.html)

Again, thank you Mark for your help!

Sincerely,

Corey
________________________________
From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Corey Schmidt <Corey.Schmidt at uga.edu>
Sent: Wednesday, August 19, 2020 11:27 AM
To: archivesspace_users_group at lyralists.lyrasis.org <archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] File Version HREF Attribute Incorrectly Assigned from EAD Exports

Dear all,

Hello, this is Corey Schmidt, ArchivesSpace Project Manager at the University of Georgia Libraries. I hope everyone is staying safe, happy, and healthy.

I'm having a problem with EAD exports from ArchivesSpace, particularly related to digital objects. When exporting EAD files, the digital object ID is assigned to the href attribute when in fact the File URI should be assigned to the href attribute. The converter is saying IF file_versions[0] != NULL THEN href="file_versions[0].file_url" ELSE href="digital_object_id". For our case, it is defaulting to ELSE, even though there are file versions attached to our digital objects and they are published. I confirmed this by making a get request for some digital objects and saw that the list of file versions for each one has at least 1 file version. Attached is a screenshot (because I'm from the "Show-Me" state).

When exporting records, we normally include digital objects, but we exclude unpublished components. However, when I tried including unpublished components, the File URIs are assigned correctly to href attributes. I checked the MySQL database and all the file versions for the field publish = 1 (which I assume means Publish = True). Within the staff interface, it also shows Publish = True, so I don't think it's an issue with either the database or Solr Index. I should note that this behavior is inconsistent, where some (usually smaller) finding aids will export with the file URI assigned to the href attribute without including unpublished components. However, the vast majority do not.

Any clarification and/or help would be greatly appreciated. Thanks!

Sincerely,

Corey

Corey Schmidt
ArchivesSpace Project Manager
University of Georgia Special Collections Libraries
Email: Corey.Schmidt at uga.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20200821/9a5c0d27/attachment.html>


More information about the Archivesspace_Users_Group mailing list