[Archivesspace_Users_Group] Anyone making use of Harvard's aspace-import-excel plugin?

[Olivia S Solis]

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_3SXbtPATTT9l6Z8CueWVPKQ/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
<https://docs.google.com/spreadsheets/d/1-hCN-1OZDctrRnWO8Hg_3SXbtPATTT9l6Z8CueWVPKQ/edit?usp=sharing>,
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
<https://github.com/archivesspace/archivesspace/blob/master/common/config/config-defaults.rb#L81>
(see
also here
<http://lyralists.lyrasis.org/mailman/htdig/archivesspace_users_group/2018-February/005664.html>).
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
>>
>>
>> <https://www.slv.vic.gov.au/email_campaign>
>> [image: follow us]
>> [image: SLV facebook]
>> <http://www.facebook.com/pages/Melbourne-Australia/State-Library-of-Victoria/32256104331> [image:
>> SLV twitter] <http://twitter.com/Library_Vic> [image: SLV youtube]
>> <http://www.youtube.com/user/statelibraryvictoria> [image: SLV instagram]
>> <http://instagram.com/library_vic> [image: 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20190114/91c7f564/attachment.html>