Adding more file versions to DO import templates?

[Olivia S Solis]

Hello all,

I am sketching out digital object creation workflows. Since we use a spreadsheet template for ingesting digitized objects into our digital repository, I was hoping we can repurpose the metadata in it for bulk creating and linking DOs using one of the available ASpace import templates. This so that staff doesn't have to know how to use the API to bulk create the objects after they are digitized, a use case I suspect isn't uncommon. Ultimately, we want to link to specific archival objects. 

The ingest spreadsheets we use to add objects to our digital repository include multiple collections (= multiple resource records). We want to create three file versions per ASpace DO: 1) direct link to the DO in repo, 2) the repo's thumbnail image for the DO, and 3) path to a separate storage location. I'm experimenting with the two DO import templates but it doesn't look like I'll be able to use them for my purposes unless I am missing something.

Bulk Import DO CSV

This is the spreadsheet that creates DOs and links them to AOs. My problems here include:

• You can't use it to link to AOs in multiple collections. I can solve this, it will just be messier, resulting in multiple ASpace spreadsheets per one repo spreadsheet
• More problematically, it only allows for 2 file versions. One file version plus one thumbnail. Is there a way to force a third file version?
• I tried forcing a thiird file version by adding columns digital_object_link_2, and digital_object_link_publish_2 like you can in the bulk AO importer but it didn't work

Digital Object CSV

This is the spreadsheet has a whole lot more fields, but doesn't link to AOs.

• It has the benefit of allowing us to create all the digital objects in the repo's ingest spreadsheet in one upload, but I would need a separate process to link to AOs. Not ideal, but solvable.
• Disappointingly, though, it only allows one file version. I similarly tried adding "_2" and "_3" to repeatable fields' headers, but it did not work.

Is there some trick I am missing to allow additional file versions for either template? I can create a process that works completely via the API. But ideally I wanted staff doing the day-to-day digitizing, most of whom don't have access to the API, to be able to use the existing spreadsheets to get at least part way there.

Thanks,

Olivia

--

Olivia Solis, MSIS (she/her)

Metadata Coordinator

Dolph Briscoe Center for American History

The University of Texas at Austin

2300 Red River St. Stop D1100

Austin TX, 78712-1426

(512) 232-8013

[Corey Schmidt]

Hey Olivia,

I believe you are correct that the bulk import template and digital object template do not let you add more than 1 (or 2 for a thumbnail for the bulk importer) file version. I can think of two ways to approach this issue.

The first would be to open a JIRA ticket with ASpace and ask that the bulk import digital object template be changed to enable multiple file versions per one digital object. There's been work done in the past to change that spreadsheet template, so it wouldn't be out of the question. You would still need to create multiple spreadsheets per repository, however.

The second is to use the API for the workflow, but use some sort of GUI interface or simple command line script for your staff to use instead of messing around with the API directly. I've done something tangentially similar to this with our ASpace > DLG spreadsheet workflow app. I could see a GUI app for this workflow looking something like that, except it would work to push data to ArchivesSpace, like the following:

1. Design your own spreadsheet template with all the metadata you/ArchivesSpace need for creating and linking digital objects (including multiple file versions and links to specific archival objects - I would recommend either grabbing the archival object URIs specifically, so it has the correct repository ID number and you would be able to have one spreadsheet for archival objects of any repository).
2. Deliver the spreadsheet template to your staff to fill out the digitization metadata - file versions, digital object titles, etc.. The GUI/script could do this part if you already know what archival objects you want to link - pre-filling some fields by pulling metadata from ArchivesSpace.
1. If you use barcodes, unique IDs or something for the archival objects, you could have your staff enter that as input in the GUI/script, fetch the metadata from ASpace, then fill out those rows in the spreadsheet template and give them a copy to fill out the rest of the info. This is very similar to the app we designed.
3. Once the staff are done digitizing and filling in all the metadata in the spreadsheet, they go back to the GUI/script and give it the updated spreadsheet. The GUI/script can then make all the appropriate API calls and error handling for them.

The above workflow is another spreadsheet template to track and a specialized script to maintain, but it could help make the process easier for staff.

Hope this helps in some way, I'm willing to chat more if you want to brainstorm ideas.

Sincerely,

Corey

---

From: archivesspac...@lyrasislists.org <archivesspac...@lyrasislists.org> on behalf of Olivia S Solis <livs...@utexas.edu>
Sent: Tuesday, May 28, 2024 1:58 PM
To: Archivesspac...@lyrasislists.org <Archivesspac...@lyrasislists.org>
Subject: [ArchivesSpace Users Group] Adding more file versions to DO import templates?

 

You don't often get email from livs...@utexas.edu. Learn why this is important

[EXTERNAL SENDER - PROCEED CAUTIOUSLY]

--
You received this message because you are subscribed to the Google Groups "Archivesspace_Users_Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to Archivesspace_User...@lyrasislists.org.
To view this discussion on the web visit https://groups.google.com/a/lyrasislists.org/d/msgid/Archivesspace_Users_Group/CAKu%2Bi%3D33CJSxo%2B9jc2RwR66e8b3LH9mZ-KZKOWJ99jwYjptCqw%40mail.gmail.com.

[Olivia S Solis]

Wow, thank you so much, Corey! I will take a closer look at your tool. 

I'm wondering if others out there would like to see extended functionality of the existing spreadsheet. I'd be happy to start a ticket, incorporating any community input. I know the features I want to see, but we use very minimal fields in general since we're mainly pointing out to our repo and internally our storage system. I would think a reconsideration of the spreadsheets would be in order since there was just so much work on the DO module.

Since I didn't hear from anyone, I figured it wasn't possible to add multiple file versions and began working on a very sketchy process. I would probably initially be the one to do all posting, and was designing a spreadsheet that would make it a little easier on me. The idea is it pulls in the data from spreadsheets bound for our repo which we leverage to join to the associated AO. It forms the JSON in a cell for me to post:

https://docs.google.com/spreadsheets/d/1doiX8RclmaYwh13SStoQqKaRlvRZP4sKXPemdYbc7fM/edit#gid=1255122962&range=L3

The is really nascent, and based on an existing DO record I had used to model a JSON template from. Without really thinking about it, I was happy to see that the record I used included an AO and resource URI for the instance and thought it would add the DO instance, which is included in this JSON. It does not create an instance, as I should have immediately realized. I will need an additional step of linking the DO to the AO. 

But perhaps a tool like yours could change our approach.

Thanks again! If anyone else endorses a JIRA ticket let me know.

-Olivia

[Olivia S Solis]

Hello all,

For anyone interested, I created a couple of new JIRA tickets regarding the digital object import spreadsheet Digital Object CSV:

https://archivesspace.atlassian.net/browse/ANW-2050

https://archivesspace.atlassian.net/browse/ANW-2049

I deliberated on a reporting strategy since there are 2 separate spreadsheets you can use to bulk import DOs, neither of which do everything I want. I just picked one, the one that has the fuller fields, and added the feature requests in reference to that one. It seems like there should be one import spreadsheet for easier maintenance? In the feature request for multiple file versions, I also requested the ability to mark one as representative. Hopefully that isn't shoving too much in one issue, but that seemed to go hand in hand with the additional file versions.

Corey, thanks again for sharing your tool. After looking it over more closely with my team, I may have more questions.

Thanks,

Olivia

[Corey Schmidt]

Olivia,

 

Glad to help! Thanks for posting those JIRA tickets – I think they’ll bring valued enhancements to the Digital Object CSV importer for a number of folks.

 

If I understand the differences between the Bulk Import DO template and the Digital Object CSV, the latter was created before the former, since the Bulk Import DO template came from a Harvard plugin that was incorporated into the main code back in version 2.8. By adding the ability to link archival objects to the Digital Object CSV importer, that could make the Bulk Import DO template redundant, because as the Digital Object CSV currently exists, it doesn’t link to archival objects like the Bulk Import DO template does. However, the way you import is slightly different. Bulk Import DO imports via the “Load via Spreadsheet” option in the resource page, but that gets kicked to a background job from the “Load Spreadsheet” popup. Digital Object CSV imports via a background job directly.

 

There was a member discussion about expanding the capabilities of digital object importing (as well as bulk editing and exporting) – 2022-12-14 Digital Objects Member Discussion. I think this discussion fits neatly within that desire to expand functionality. The tricky part is figuring out how to adjust the background code and front-end interface if we want to condense the importers into one process.

 

Corey

To view this discussion on the web visit https://groups.google.com/a/lyrasislists.org/d/msgid/Archivesspace_Users_Group/CAKu%2Bi%3D09PqBGgXRx6YZfk9njB8J5yb4GBmoqvVPj0gvJp%2BSumw%40mail.gmail.com.