[Archivesspace_Users_Group] Digital objects import with incorrect Published value
Corey.Schmidt at uga.edu
Tue Jan 11 12:14:24 EST 2022
I believe there is a JIRA ticket about adding the File Version publish column to the spreadsheet importer: https://archivesspace.atlassian.net/jira/software/c/projects/ANW/issues/ANW-1158
It looks like it’s being worked on by the team and has gone through testing. I posted the ticket awhile back because we found this to be a frustrating experience for us as well, except not with the PUI but with EAD.xml exports. It doesn’t solve Julie’s original issue of logical vs. text based TRUE/FALSE inputs, but if there isn’t a JIRA ticket for that already, we can put one in.
From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> On Behalf Of Wendy Scheir
Sent: Tuesday, January 11, 2022 11:49 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Digital objects import with incorrect Published value
[EXTERNAL SENDER - PROCEED CAUTIOUSLY]
I wanted to clarify and expand upon the email I sent yesterday regarding our current (proposed) use of Digital Objects in ArchivesSpace and the related issues that we've encountered when importing DOs using the importer. My thought is that perhaps there are others out there who are working on a similar or related workflow issue who may have some suggestions for us.
When we have a digital object publicly available on our external digital collections site and we wish to provide a link to that object from the component (archival object) level in the ASpace PUI:
We leave Publish? unchecked (that is Publish? = FALSE) in the Basic Information section, but we do click Publish? in the File Version section:
In the PUI, the above looks like this:
Here, what we wanted was the link out to the digital object on the external site. The reason we do not click Publish? in the Basic Information section is because we believe users find it confusing when there are two disconnected references to digital objects within the component record.
This is what the PUI looks like if both Publish? fields are clicked (both are TRUE):
Clicking FALSE under Basic Information suppresses the link to the Digital Object record in ASpace.
However, the import spreadsheet has a single field for Publish and the File Version field inherits the imported selection for the Basic Info field, and does not provide the option to mark the Basic Information field FALSE and the File Version field TRUE:
This means that we don't have the option to import a batch of digital objects in the same way that we want them to display, which results in having to manually edit DOs after import.
Feel free to email me independently with any questions or if you'd like to continue this conversation offline.
THE NEW SCHOOL ARCHIVES & SPECIAL COLLECTIONS
66 FIFTH AVENUE, NEW YORK, NY 10011
scheirw at newschool.edu<https://email@example.com>
Explore the Archives<http://archives.newschool.edu> | Digital Collections from the Archives<http://digitalarchives.library.newschool.edu/> | New School Histories<http://newschoolhistories.org/> | @tnsarchives<https://twitter.com/tnsarchives>
[THE NEW SCHOOL]
On Mon, Jan 10, 2022 at 7:15 PM Wendy Scheir <scheirw at newschool.edu<mailto:scheirw at newschool.edu>> wrote:
I think a related or adjacent issue to this is that there are 2 separate Publish? fields for each Digital Object record, but the import spreadsheet has the option to select TRUE/FALSE for only 1 of them.
The way we're using DOs, sometimes (often, actually) we want one=TRUE and the other=FALSE within a single record.
The New Archives and Special Collections
On Mon, Jan 10, 2022, 5:11 PM Wetherill, Julie M. <julie_wetherill at harvard.edu<mailto:julie_wetherill at harvard.edu>> wrote:
In August 2021, a list message<http://lyralists.lyrasis.org/mailman/htdig/archivesspace_users_group/2021-August/008619.html> from Benn Joseph at Northwestern UL described their trouble getting incorrect Publish values when importing digital objects via spreadsheet. Harvard migrated to v3.0.2 in Fall 2021 and we also have this problem. It seems like the ASpace code that interprets the incoming spreadsheet data is being extra picky about the Type value of the “publish” (Publish Digital Object Record) attribute that is supplied in the spreadsheet.
If the archivist uses the TRUE/FALSE controlled values provided in the official template on github (bulk_import_DO_template.xlsx), digital objects load with the correct “publish” values and their PUI display looks good. When I run the TYPE function on these values, I get type 4 (logical value).
But sometimes, an archivist will paste in TRUE/FALSE values copied from another file (especially true in high volume automated workflows). At a glance these TRUE/FALSE values look identical but they aren’t. I noticed that these values are left aligned in the cell, rather than centered as Excel does to indicate a logical TRUE or FALSE. And when I run the TYPE function on a cell with these values I get type 2 (text). Seems like ASpace wants only the logical TRUE/FALSE. An imported digital object that has the text value TRUE for “publish” will be set to the default FALSE (unpublished). When this happens in high volume it’s a mess to clean up. And despite being marked Published=FALSE in staff mode, in the PUI, these digital objects are partially displaying. By that I mean, there is no digital link but the DO’s are labeled DIGITAL and display in the PUI list of digital objects.
I guess the work-around is user education (warn users to only supply logical TRUE/FALSE). But I’d prefer we tweaked ASpace code to accept either the logical or text value of TRUE/FALSE as I suspect used to be the case when spreadsheet import was plugin-based.
HUIT Library Technology Services
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 56793 bytes
More information about the Archivesspace_Users_Group