Importing Translation of Authority Records

43 views
Skip to first unread message

Carolyn Sullivan

unread,
Feb 23, 2023, 11:52:06 AM2/23/23
to AtoM Users
Hello,

We were trying to import a csv file of translated archival descriptions with authority records included to our database.  However, we ended up with the authority records duplicated in our database.  I believe this happened because:

(1) the csv was translated.  The field 'eventActor', which I think maps to the name of an Authority Record, isn't supposed to be valid for importing translation, so separate English and French authority records were created.
(2) The authority records didn't already exist, so every time an authority record was mentioned in the csv, it created a new authority record whether or not one with the name actually existed.

I think the way to solve this issue is to upload the authority records first and separately, and then upload the archival descriptions, but I'm not sure how to create the relationship between the archival descriptions and the authority records on import if the field 'eventActor' is removed from the archival descriptions.  I don't see any other field on the allowed fields for importing translations that would allow a linkage: https://www.accesstomemory.org/en/docs/2.7/user-manual/import-export/csv-import/#csv-description-translations

IS it possible to link authority records to archival descriptions when importing translated archival descriptions?  If so, which field would it be linking on?

Thanks for your help,
Carolyn.

Dan Gillean

unread,
Feb 23, 2023, 1:07:01 PM2/23/23
to ica-ato...@googlegroups.com
Hi Carolyn, 

I would have to test it to confirm, but I believe the way to do this would be: 
  • If you're translating both authorities and descriptions, make sure the way you prep the CSVs follows the same pattern of which language is source and which is translation row
    • i.e. if your archival materials are in English and you're adding descriptions and authority info in both English and French, then in BOTH CSVs make sure that the English row is first (i.e. the source), and French is second (i.e. the translation)
  • Upload the authorities and their translations first
  • Prep your CSV of descriptions with translations
  • Only add the related actor name in the eventActor field on the SOURCE record, not the translation
    • i.e. if English is the source row and French is the translation, put the SOURCE creator name in the eventActor field of the English row, and leave the French translation row's eventActor field blank
This is similar to the example and tip at the end of the Import translations section in the CSV import docs: 

import-translations.png
Look for example at the levels of description. This is a separate linked entity - a taxonomy term - meaning we can't translate it via an import, we need to go to Manage > Taxonomies > Levels of Description, find "Item" and add a French translation there. As soon as one is added, then it is used on your linked French description. If on the other hand we try to put "Pièce" in this CSV as a translation for Item, we would likely end up creating a duplicate term in our Levels of Description taxonomy instead. 

Let us know if this helps (and works as hoped!),

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/4b821760-5d30-4404-a5f6-9d936327d27bn%40googlegroups.com.

Carolyn Sullivan

unread,
Feb 23, 2023, 1:42:07 PM2/23/23
to AtoM Users
Hello,

Thanks!  So just wondering about importing translations of authority records, the Authority Record CSV template given here doesn't have a legacyId column on which to match translations of a given record.  Is there a variable on which to match translations for authority records?

Thanks,
Carolyn.

Dan Gillean

unread,
Feb 23, 2023, 3:23:36 PM2/23/23
to ica-ato...@googlegroups.com

Hi Carolyn, 

My apologies, I misspoke! To be honest I haven't been working on the AtoM project for a little while, so my on-hand knowledge is getting rusty! 

Translation import is not yet supported for authorities. So you generally follow the steps I described for descriptions, but authorities will need to be translated via the user interface, either before or after. So long as you are linking based on the source language and not trying to add a name in the eventActor field of the translation row, I think the general approach should work. 

Sorry again for tempting you with a feature not yet supported!

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.

Carolyn Sullivan

unread,
Feb 23, 2023, 3:57:30 PM2/23/23
to AtoM Users
No worries!

I was curious though... would you happen to know in which of the mysql tables the authority records are kept?  I've wanted to see what I could get done in the backend with SQL and a script in a few cases, but I'm not always sure which tables/fields correspond to which entities in the interface.  Is there documentation on this anywhere, maybe a database schematic?

AtoMTables1.pngAtomTables2.pngAtomTables3.png
Thanks,
Carolyn.

Dan Gillean

unread,
Feb 23, 2023, 4:09:52 PM2/23/23
to ica-ato...@googlegroups.com
Hi Carolyn, 

I haven't fired up my dev instance, loaded Workbench, and generated a new one for 2.7 yet, but previous Entity Relation Diagrams can be found on the wiki, here:
I provided a little bit of an overview in this recent forum response: 
I believe that most authority record information should be found in the actor and actor_i18n tables. i18n by the way is a long-standing developer shorthand for internationalization (i.e. translatable fields in this case) - because that's a long word, they cut out the middle 18 characters and replace it with the number instead. In any case, this means the fields you will want to focus on mostly will be those found in the i18n tables - these are free-text fields that are designed to be translated, whereas those found in the base tables generally aren't, like identifiers. 

As you explore keep in mind that: 
  • All major entities start with an entry on the object table, and this is where they get the object ID value from, which is often used as a key on other tables
  • Notes have their own tables, so some fields might be in note and note_i18n
  • Some other entities are a subset of actors - including repository records, donors, possibly rightsholders, etc.
Cheers, 

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

Reply all
Reply to author
Forward
0 new messages