How to link existing Child records to newly created Parent?

69 views
Skip to first unread message

Tracey

unread,
Apr 15, 2019, 7:02:41 PM4/15/19
to AtoM Users
Hello all,

I am trying to link existing child records (file level) to a newly created parent record (subseries) for clearer accessibility to the information. I inherited over 300 individuals records at the file level under one series. Ideally, I would like to arrange these files into their respective subseries. How do I link from the bottom up? 

Thanks in advance for your assistance,
Tracey

Dan Gillean

unread,
Apr 16, 2019, 1:32:13 PM4/16/19
to ICA-AtoM Users
Hi Tracey, 

Unfortunately, it's a lot more difficult in AtoM to work from the bottom up than the other way around. 

Via the user interface, your options are limited - you can use the Move module, but would have to do this individually for all 300+ of your records. See: 
There is a way that you can do this via a CSV import, but it may not be easy. AtoM has the ability to update existing records via CSV import - but the feature was not designed with the use case of doing these updates in a single system in mind. Instead, its intent was to help users managing portal sites receive updates from other local AtoM users, and update them over time. Because of this, matching and updating in a single system can be tricky.

If you would like to better understand why this is, and how matching works, and why it doesn't currently work well when roundtripping (i.e. exporting records, updating them, and then re-importing them in the same system as updates), please see the following previous forum post: 
All this to say, if you choose to try this method, I strongly recommend that you back up your data first, so you can roll back to the previous version if you don't end up getting the results you intend. 

That said, you can use the qubitParentSlug column to indicate an existing record in AtoM should be the parent of a current description row in your CSV. You can read more about this CSV column in our documentation here: 
  • Export the records you want to update in CSV format. You can either add them all to the Clipboard and export that way, or you could perform a bulk CSV export from the command-line, and remove any rows you don't need. You could also try to narrow a search results page to just the records you need, and export that way. The Clipboard allows you to export all lower-levels if you add a parent description, so if all the records you want to update are in the same fonds/collection, that might be the easiest way. Remove any rows that will not be part of the update from the resulting CSV. Remember, because Microsoft Excel tends to use its own custom character encoding (Win-Latin) and line endings, and AtoM expects unix style line endings and UTF-8 encoding, we recommend using LibreOffice Calc as your spreadsheet program over Excel. 
  • Some columns in the CSV don't work well for updates - mainly those that are not actually stored on the same table in AtoM's database. To avoid accidentally creating duplicates in these areas, I recommend deleting any notes, access points, and event/actor (e.g. creators and dates of creation etc) related columns from the CSV. AtoM will treat any empty cells as "no update" so a missing column or blank cell in a row will not overwrite your existing data by deleting it. There are some notes on this in the documentation for using the CSV import as an update in this section. 
  • For each file record you want to move, add the slug of the parent (aka the unique part of the URL - for example, if your AtoM site is available at www.example.com and the description is listed at www.example.com/description-1, then description-1 is the slug) series to the qubitParentSlug column. Save the CSV when you are done. 
  • Now we can try importing it as an update: 
    • Select "Update matches ignoring blanks fields in CSV"
    • Select "Skip Unmatched Records"
    • Limit matches to your repository
    • Add your updated CSV to the import and start the import! 
By selecting the "Skip unmatched records" option, this will hopefully ensure that if a match can't be found, nothing will happen (so you don't end up accidentally creating duplicate records). I still recommend making backups first, however! As explained in the docs, and the other forum threads I linked above, AtoM's first criteria for matching (based on source_name and keymap value) will fail, since this is a roundtrip - so it will be relying on an exact match on the identifier, title, and repository name for matching. 

Good luck, and let us know how it goes!

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


--
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 post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/08102bb9-d26d-4195-82d8-9a1ca0c1e5aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Tracey Krause

unread,
Apr 16, 2019, 6:20:02 PM4/16/19
to ica-ato...@googlegroups.com

Hello Dan,

 

Thank you for this thorough and intimidating explanation. I shall do my best and let you know the results.

 

Cheers,

Tracey

--
You received this message because you are subscribed to a topic in the Google Groups "AtoM Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ica-atom-users/Lhd3h1PAumE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ica-atom-user...@googlegroups.com.


To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

Reply all
Reply to author
Forward
0 new messages