Import - match and update not working

[Meg Travers]

Hi all - we recently upgraded a system to AtoM v2.9 and find that the function to Import using 'match and update' is not working. 

The existing records in the system were all lovingly hand-typed in so there is no source_name value to use for matching, so instead we planned to use matching on Title, Identifier, and Repository (as detailed in the online manual), but this is failing to match and instead creating new records rather than updating the existing ones. 

Can anyone shed some light on getting the 'match and update' import to work when the option to use --roundtrip in the CLI is not an option as there is no source_name value?

Any suggestions gratefully received!

Meg

[Meg Travers]

I should add that this is working on a v2.4 system, so I assume the functionality is still there in later versions... 

[Dan Gillean]

Hi Meg, 

I think you might have gotten that accidentally inverted, though I fully understand why - the current import matching logic is confusing! 

From what you've described, I think the --roundtrip option actually is likely your best bet! It's actually importing without using the roundtrip option that relies more often on the source_name being present. 

Let me try and resummarize: 

Normally (i.e. without the --roundtrip option - so whenever importing via the user interface for example), AtoM attempts to infer a match by looking for matches in: 

• the source_name value used during import, and the related legacyId values stored in the keymap table - comparing these against the same values found in the import CSV
• If no match can be found using those criteria, THEN AtoM falls back to looking for exact matches in:
• the related repository value in the related CSV row
• the identifier in the related CSV row
• the title in the related CSV row

However, when the import is run from the command-line and the  --roundtrip option is used, all of this logic is ignored. Instead, AtoM assumes that you are first exporting a CSV, updating it WITHOUT changing the exported legacyId values, and then re-importing it as an update (hence the "roundtrip" part of the task option).  When this --roundtrip method is used:

• AtoM ignores any legacyID and source_name values in the keymap table
• AtoM will also ignore any other matching criteria (like matches on the CSV title, repository and identifier values), and
• AtoM will ONLY look for exact matches by comparing the legacyID value in each CSV row against AtoM's objectID values. 

Meaning: so long as you export first (in which case, AtoM adds the internal object_id values to the exported CSV's legacyId column for each row) and you don't change the legacyId values in your exported CSV, then it won't matter if all the descriptions were created by hand and have no source_name values. Further, this method allows you to update more fields in the CSV, since it doesn't rely on exact matches on title, identifier, and repository. 

This means you could:

• Add the records you want to update to the clipboard, and export it as a CSV
• Make updates to the CSV as needed, and save
• Import using the command-line CSV import task, with the --roundtrip option and the --skip-unmatched option (that way, any records that don't match are skipped and reported in the console, rather than coming in as new duplicate records)

For more details on importing from the command-line, including the --roundtrip option, see: 

• https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/cli-import-export/#importing-archival-descriptions

I recognize that the current behavior is confusing, and that the roundtrip option should be added to the user interface, since this is in practice how most people want to use the update functionality. This is something I hope the AtoM team might add in future releases. In the meamtime, if you want to know a bit more background about the current logic, I've written about it previously here:

• https://groups.google.com/g/ica-atom-users/c/HMoN4tEuJ10/m/n4e1gqftBQAJ
• Similar info, but another version: https://groups.google.com/g/ica-atom-users/c/bCWYFIkLCRs/m/7QTPfLnQAQAJ

As a final note: 

If you do intend to keep trying to get things working via an import in the user interface, the "skip unmatched" option IS supported there, so be sure to use it. This way, if no match is found, at least it won't create a new record, it will just skip the row instead. 

Cheers, 

Dan Gillean, MAS, MLIS
Business & User Experience Analyst
Artefactual Systems, Inc.
604-527-2056

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 visit https://groups.google.com/d/msgid/ica-atom-users/c6b4687c-6b20-4f67-ac08-cb7ada1f56abn%40googlegroups.com.