Importar objetos digitales sin flash player

185 views
Skip to first unread message

Luis Fernando López Falagán

unread,
Jan 28, 2021, 5:42:04 AM1/28/21
to AtoM Users
Quisiera saber cómo importar varios objetos digitales en un único registro. Hasta ahora era muy sencillo. Por lo que he visto, sería posible desde la línea de comandos y quisiera saber con más detalle el procedimiento.
En la documentación se habla de un fichero CSV y me gustaría saber con más detalle el procedimiento: directorios, en qué descripción se añaden, etc...

Por otra parte, si existe alguna alternativa a flash player que permita hacer el proceso como hasta ahora sería muy sencillo.

Un cordial saludo

Dan Gillean

unread,
Jan 28, 2021, 2:03:40 PM1/28/21
to ICA-AtoM Users
Hola Luis, 

We are working on a replacement for the Flash-based multi-uploader. It will be included in an upcoming release - we are just finalizing the internal code review and testing now. I have just posted an update about our plans for upcoming releases here: 
We apologize for the delay! 

In the meantime, there are two different ways you can use imports to create multiple digital objects. However, both require access to your server, so you can place the original images there for AtoM to upload.

Method 1 is to use the archival description CSV import. There are actually two ways you could do this. 

The first way (let's call it 1A) is to create new archival descriptions and attach digital objects to them at the same time. This is closest to how the Flash based multiple digital object uploader worked, in that it can create new child descriptions under a parent, allowing you to add multiple new digital objects. 

The CSV import template for descriptions has two columns you can use for uploading digital objects - the digitalObjectPath column and the digitalObjectURI column. The URI column is for uploading images that are publicly available on the web, using a URL that points directly to the digital object. The digitalObjectPath column can be used to upload local digital objects, by providing the full directory path to the original files on your server. See: 
So, using this way would involve the following: 
  • Add the files you want to upload to a directory, and then place the directory on your server in the root AtoM installation directory (which is typically /usr/share/nginx/atom if you have followed our recommended installation instructions). Be sure to name the directory something unique that doesn't conflict with any existing directories in AtoM - don't use uploads for example, because AtoM already has its own uploads directory. You can name the directory tmp, or images, etc. 
  • Prepare an archival description CSV with the metadata of the descriptions you want to create - your digital objects will be attached to these. If you want to create child descriptions from an existing parent, you can use the qubitParentSlug column to create the CSV descriptions as children of an existing description in AtoM, by providing the slug of the target parent record. See: https://www.accesstomemory.org/docs/latest/user-manual/import-export/csv-import/#qubitparentslug
  • In the digitalObjectPath column, add in each row the full file path to the related digital object, ending in the extension. For example, if your file was named bunny.jpg, and you put it in a directory called images in AtoM's root installation directory, then in the related description row of your CSV you might add /usr/share/nginx/atom/images/bunny.jpg as the digitalObjectPath value. Repeat for each row in your CSV as needed
  • Now you're ready to perform your import! You can run the import either from the command-line, or via the user interface. 
__________________________________________________________________________________________________

The second way (1B) is to use the descriptions CSV import as an update to existing descriptions. 

It is theoretically possible to do this via the user interface - however, I strongly recommend using the command-line, as there is a CLI option on the CSV import task called --roundtrip that will make the matching and updating much easier. There is a long previous thread in the user forum that explains why using the CLI option is better, and how the user interface matching currently works. It also covers basic steps for using the --roundtrip option for a CLI import. See: 
You can read the CSV command-line import documentation here: 
If you want to try this method as a way to add digital objects to existing descriptions, I  would recommend something like the following: 
  1. Add the files you want to upload to a directory on your server in the root AtoM directory, as in the first step of 1A, above
  2. In AtoM, find the description(s) that you want to update with digital object links and add them to the clipboard. If you are working with hierarchies, remember that AtoM will give you the option to include descendants in an export. 
  3. Navigate to the clipboard, using the clipboard menu in the AtoM header bar
  4. Export the descriptions from the clipboard
  5. Open the resulting export CSV in a spreadsheet application - we strongly recommend using LibreOffice Calc over Excel, due to Excel's proprietary default line endings and character encodings (whereas Calc lets you set these every time you open a CSV)
  6. To avoid any risks of data duplication, I recommend deleting most non-essential columns from the CSV at this point. Keep only:
    1. legacyId
    2. parentId
    3. title
    4. identifier
    5. repository
    6. culture
  7. after the repository column, add a new digitalObjectPath column. 
  8. Add in the full file path to the digital object, ending in the file extension (e.g. /usr/share/nginx/atom/images/bunny.jpg) you would like to link to for each description row. Remember, only 1 digital object number per row!
  9. Save your CSV
  10. In the command-line, we have a --roundtrip option in the CSV import task. This ignores any of the complicated cascading matching options based on previous legacyID or title/identifier/repository exact matches. Instead, when used, it will ONLY match on the objectID value in AtoM's database - which is what you get in the legacyId column on export from AtoM, so as long as you haven't changed or removed that column in your CSV, then it's fine. This option is not currently supported via the user interface, but produces much better matching, which is why I suggest using it now.
  11. Import the CSV as an update. Your CSV import command should look something like the following - note the options being used: 
  • php symfony csv:import --update="match-and-update" --roundtrip --skip-unmatched /path/to/your/import.csv
Finally, don't forget to repopulate the search index afterwards - you may also want to clear the application cache:
  • php symfony cc
  • php symfony search:populate
  __________________________________________________________________________________________________ 

There is also Method 2, which is to use the Digital Object Load task. This task is used to attach digital objects to existing descriptions. Currently it is only supported via the command-line. You can read more about the task here: 
This method also requires you to place your digital objects on your AtoM server first, and then provide AtoM with the file paths via the CSV. Essentially, you create a new CSV file with 2 columns: 
  • column 1 should have a header named filename.  Add the full file path to your images in this column, 1 per description
  • column 2 can use several different criteria - If you are using 2.6, I strongly recommend naming this column slug, and then using the slug value of each description (the unique part of the URL for the description) as the target. 
You can review the rest of the documentation, and when your CSV is ready, run the task! Remember to repopulate the search index afterwards - you may also want to clear the application cache: 
  • php symfony cc
  • php symfony search:populate
I hope this helps! 

Cheers, 

Dan Gillean, MAS, MLIS

--
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/436c62af-5bab-4ed6-bec9-b3589e1a7bf7n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages