physical storage csv import w/o CLI

[Jarad]

Hi all,

Does anyone know if it's possible to do a CSV import for physical storage WITHOUT use of command line? All the documentation I've found is for CLI implementation and I don't see an option for physical storage on the front-end. Sadly, I lack CLI access.

Related question: when I link physical storage for a parent description, AtoM tells me it's updating child level descriptions, but as far as I can tell, no physical storage links are created for child-level descriptions.. What am I missing on that front?

My ultimate goal is to mass link storage to descriptions via CSV, or if that's not possible, on a folder-by-folder basis with child inheritance. Doing it item by item just ain't happening.

Thanks for any and all help!

Cheers,

Jarad

[Dan Gillean]

Hi Jarad, 

At this time, we don't have support for physical storage imports via the user interface. However, the archival description CSV templates do have physical storage columns, which offers you a few options. First, the obvious use - creating new containers or linking to existing containers while importing new descriptions. However, it sounds like you already have the descriptions, so let's talk about the second option. 

You can use AtoM's description import CSV to update existing descriptions - however, there are challenges to doing so when roundtripping in a single system, particularly if you can't get an import run from the command-line. See: 

• https://www.accesstomemory.org/docs/2.7/user-manual/import-export/csv-import/#update-existing-descriptions-via-csv-import
  
• https://www.accesstomemory.org/docs/2.7/admin-manual/maintenance/cli-import-export/#csv-import-descriptions-cli
  

AtoM's update import was designed rather rapidly on restricted budget, and its intended use case at the time was exporting from one system and importing updates into a different system. This is not how most people want to use the feature, and we haven't yet been able to overhaul its design to better accommodate the most desired use case - roundtripping descriptions in a single system. 

With update imports, you cannot remove or replace existing storage from a description, but you can append new data - either linking to existing containers (by adding the name, location, and type EXACTLY in the 3 CSV fields), or by creating new ones on import. The BEST way to go about this would be: 

• Use search and browse to try and narrow the results as much as possible to the subset of records you want to update
• Add these target records to the clipboard. Repeat these 2 steps until all the descriptions you want to update are on the clipboard
• Export them
• Open the exported CSV in a spreadsheet application like LibreOffice Calc - BEWARE of MS Excel, which might change your default character encoding and/or line ending characters on a save if you're not careful! 
• Add the container data to the 3 storage columns for each row
• Perform a match-and-update import, with the "skip unmatched" option selected 
• Using the CLI, you can use the --roundtrip option. This option ignores all other match criteria, and ONLY matches on the objectID - which is unique per record in AtoM, and happens to be what we populate the legacyId column with on export, so this method works very well with exporting, updating, and reimporting a single CSV (i.e. roundtripping)
• If you must use the UI, this matching option is not currently supported. Therefore AtoM falls back to trying for exact matches on title, identifier, and repository. In both cases - but especially this one - you can see why using the "skip unmatched" option is important - otherwise, by default, unmatched rows will import as new records, potentially creating duplicates. When used, if no match is found then the whole row is skipped. 

Related question: when I link physical storage for a parent description, AtoM tells me it's updating child level descriptions, but as far as I can tell, no physical storage links are created for child-level descriptions.. What am I missing on that front?

You're not missing anything, AFAIK. When we had a number of reports about timeouts in AtoM, several background processes were moved to the job scheduler so that not everything needed to happen in the browser. However, these processes were not applied SELECTIVELY as they should have been, running only when needed - instead, a number of them run in all cases, even when it shouldn't be required. The same thing happens if you update the Places field (or any field really) on an authority record - even though this field is never shown on related descriptions, the index still updates all relations  (unnecessarily). 

Hope this helps! 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/a65f950f-a163-435a-a2cb-5f9620e0f690n%40googlegroups.com.

[Jarad]

Hi Dan,

Thanks for this info and apologies for the delayed reply - I was away last week. I actually didn't realize that the fields in the description csv you mentioned referred to physical storage, so that's great to know. Looking back, I'm not really sure what I thought they were, but either way, great! I'll have to digest the rest a bit; I created some physical objects as you said and updated the descriptions via csv as described above. In some cases it created new ones even though I was 99% sure I matched them perfectly, but you never know, maybe there was an extra space or something I missed.

Either way, it's a way forward, so much appreciated for that.

Thanks!

Jarad