[Archivesspace_Users_Group] A Word Of Caution (was Re: Anyone making use of Harvard's aspace-import-excel plugin?)

Bobbi Fox bobbi at bobbifox.net
Mon Jan 14 14:35:25 EST 2019

Thank you, Olivia, for your kind words.

Please note that at the moment, downloading and initializing this plugin 
fails, apparently due to the release of  Bundler 2.0 

We are working on a fix, but unfortunately do not have an ETA for its 
delivery.  Once we have a working solution, we will make an announcement.

(No longer at Harvard, but still supporting aspace-import-excel)

On Mon, 14 Jan 2019, Olivia S Solis wrote:

> Hi Emily,
> We have been using the plugin (We're using 2.4.1 of ASpace and 2.1.13 of the
> Harvard plugin.), and as with for others, it is working great!!  Thank you Harvard,
> so much. The largest inventory we did was for a record with approximately 3500
> lines of inventory. I worked great, taking about 50 minutes to complete the job,
> but that would probably depend on your system specs.
> We made some modifications to the spreadsheet to suit our needs and uploaded the
> Excel spreadsheet as a Google Sheets doc, which processors make copies from. I am
> sharing below:
> https://docs.google.com/spreadsheets/d/1-hCN-1OZDctrRnWO8Hg_3SXbtPATTT9l6Z8CueWVPK
> Q/edit?usp=sharing
> Some of the changes:
>  *  I added data validation so that processors can only enter kosher dates for
>     begin and end dates.
>  *  Same for our EAD ID column, which requires a certain syntax.
>  *  You can only upload 1 date record through the spreadsheet, but you can add any
>     column you want. We added a column for processors to keep track of their dates
>     should they want more than one date record per archival object. They go back in
>     the GUI and manually add dates not uploaded through the spreadsheet.
>  *  We keep track of container profiles and locations for top containers. We added
>     columns for those so processors can document those and go back and add them
>     through top container/bulk updates in the GUI.
>  *  Added values in dropdown menus for the columns (container profiles, instance
>     type, etc.).
> One other thing we've found in our ongoing experiments with the plugin is that it
> is easy to make mistakes that ASpace would normally catch in the GUI if you just
> use the spreadsheet. (e.g. you might forget to enter the date type.. ASpace/the
> plugin will reject the date). Yes, the plugin will throw you an error, but it is
> much better to catch the mistakes up front. I am working on a workflow for checking
> for varied possible mistakes using Google Sheets filter views, which can be saved
> and copied over to the spreadsheets processors use. Those checks are described
> here, but disclaimer: this is very drafty! I'm not done with container checks and
> the things we need to check for grows. But I think filters are a good way to check
> that you've got all the required info to make an archival object record or
> subrecord within that archival object.
> A few other things. If you go Google Sheets (which I believe Harvard would
> discourage) and download as xslx, make sure all your columns are in Text (vs. auto
> or number mode) in your Sheets template. In fact, I feel it is risky to write in
> Google Sheets and open in Excel because it might (e.g.) mess with your dates and
> transform them to a syntax ASpace will reject ... mess with other formatted text.
> We sometimes have boxes reserved for oversize or restricted materials and these
> boxes already exist in ASpace as top containers. Processors sometimes add materials
> to them and need to refer to those top containers in their inventories. The barcode
> column is how you link to the existing top container record using the
> spreadsheet/plugin. But we are having problems doing that with barcodes that are
> strings of numbers, though not with anything that includes both numbers and letters
> works fine. This is also because we implemented this config fix (see also here). We
> don't totally understand the issue, but the linkage is not made when we have the
> config fix turned on. It does when we don't.
> At any rate, thank you again, Harvard! I strongly recommend your plugin.
> Best,
> Olivia
> On Tue, Jan 8, 2019 at 5:53 PM Peale, Anne <aep3 at williams.edu> wrote:
>       Hi Emily,
> We installed the plugin about a year ago and it's been working brilliantly.
> We have loaded several very large files (up to c. 1500 items), and the
> process is a little slow but it does complete. 
> However, we have also noticed that when we use the plugin in our sandbox
> environment, it is much less tolerant of large sets of items and can only
> cope with short lists. I'm not the administrator for ASpace at Williams and
> don't know much about the way our server is set up, but I wonder if the
> problem has something to do with server capacity and if the plugin will
> actually work fine when you try to load to your main ASpace system. If you'd
> like more information, I can ask our administrator for details.
> The plugin has been an absolute joy to work with, especially for importing
> legacy finding aids. We've also had good luck having student assistants enter
> data into a google form or sheet, then proofreading before importing -- much
> smoother than trying to proofread additions made directly by rapid data
> entry.
> All best,
> Anne
> On Tue, Jan 8, 2019 at 6:12 PM Emily Pyers <epyers at slv.vic.gov.au> wrote:
>       Link to it in GitHub here:
>       https://github.com/harvard-library/aspace-import-excel
>       We’re really excited about it (the 80% rule!) and have
>       implemented it on our test system (v2.4.0).  We’ve been testing
>       it and it’s mostly working fine, until we attempt to load
>       spreadsheets that have more than around 100 lines. Attempts to
>       load spreadsheets over this size are resulting in job timeouts
>       and overall system slowdowns, and we’ve tested pretty thoroughly
>       – it doesn’t seem to be an issue with the data.  Our tech team
>       have reviewed the system logs, but are unable to pinpoint the
>       source of the problem.
>       I was hoping someone out there might be able to confirm that a)
>       they have successfully used the plugin to load spreadsheets
>       greater than 100 lines (since this seems to be a point of
>       scepticism for some of our internal stakeholders), and that b) if
>       you might be able to point us towards any potential areas of
>       investigation?
>       I would be so appreciative for any help on this!
>       Cheers,
>       Emily 
> Emily Pyers | Metadata & Archival Systems Specialist | Collection
> Development & Description
> In the office Monday, Wednesday - Friday 9.30am-3pm
> State Library Victoria | 328 Swanston Street | Melbourne VIC 3000
> T +61 3 8664 7368 | epyers at slv.vic.gov.au
> slv.vic.gov.au
> [signature.jpg?6]
> follow us
> SLV facebook
> SLV twitter
> SLV youtube
> SLV instagram
> RACV logo
> This message and any attachment is intended only for the use of the
> Addressee and may contain information that is PRIVILEGED and
> CONFIDENTIAL. If you are not the intended recipient, you are hereby
> notified that any dissemination of this communication is strictly
> prohibited. If you have received this communication in error, please
> delete all copies of the message and its attachments and notify the
> sender immediately. Thank you.
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
> --
> Olivia Solis, MSIS
> 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

Bobbi Fox  bobbi at bobbifox.net
Database-driven and Web-enabled applications development

More information about the Archivesspace_Users_Group mailing list