CSV import¶

Determining import complexity¶

To quickly gauge the complexity of CSV data you wish to import, the csv:check-import command can be used in the command-line. This command displays the following:

• The number of rows of data (useful when estimating the amount of processing time needed to perform the import, and whether or not you can use the user interface to perform the import)
• The number of columns (useful when estimating the amount of developer time needed to map the columns to AtoM data - see: CSV Column mapping below)
• How many instances of pipe (|) characters are found in each column (pipe characters are used by some systems to put multiple values in a single cell of data)
• Sample column values

You will need access to the command-line of the server on which AtoM is installed, and you will need to know the file path where your CSV is currently located. Run the command from the root directory of your AtoM install.

Example use:

php symfony csv:check-import lib/task/import/example/rad/example_information_objects_rad.csv

CSV Column mapping¶

AtoM was originally built to encourage broad adoption and use of the ICA’s international standards, and expanded to support other recognized standards. Consequently, all of the description templates in AtoM correspond to a recognized content or metadata exchange standard, and many of the fields in our underlying database model are also inspired by ICA standards. For your data to import successfully into AtoM, you will first need to map it to one of our existing CSV templates, which are derived from the various standards-based templates available in AtoM for description.

Mapping your data to the supplied CSV templates below implies a familiarity with the standards used in AtoM, so you can make appropriate decisions on which fields in your data map to which fields in AtoM, and how to proceed if your data does not easily map 1:1 with the standard upon which our templates are based.

For further information and source links to the standards used in AtoM, see:

• Descriptive standards
• Data entry / templates

The cell values in the top row of a CSV data file conventionally name each column. The name indicates what kind of data the column contains. If the CSV data you wish to import doesn’t include a row like this, you should insert one. You should then make the names correspond to AtoM-friendly names using the top row of data in the example CSV file(s) appropriate to your import.

Available example files are:

• ISAD archival description CSV template
• RAD archival description CSV template
• Authority record CSV template
  • Authority record aliases CSV template
  • Authority record relationships CSV template
• Accessions CSV template
• Events CSV template

All CSV templates can be found on the AtoM wiki:

• https://wiki.accesstomemory.org/Resources/CSV_templates

You can also find all example CSV import templates included in your AtoM installation, in: lib/task/import/example.

The order of the columns in the example CSV files is the same as the order in the AtoM interface, and should be maintained. Having the correct names in the cell values of the first row of your CSV data enables AtoM to import values in each column to the correct AtoM fields.

Verify character encoding and line endings¶

For your CSV files to import properly, you will need to ensure two things prior to importing: that the character encoding of your CSV file is set to UTF-8, and that the end-of-line characters used in your CSV conform to the Unix/Linux style of newline character.

Data transformation¶

If you are working with a CSV export from another system (such a different database), you may need to do further pre-processing to prepare your CSV. If your previous system was designed for standards-compliance to a standard that AtoM supports (see: Descriptive standards), the mapping process might be simple - but if your system used custom data fields, mapping to one of the supported standards could be trickier.

You may, for example, want to combine multiple CSV column values, that don’t cleanly map conceptually to AtoM-compatible CSV columns, into single columns so they can be put into AtoM as notes. So ColumnA and ColumnB could be combined into a generalNote column. This requires you to transform the data before importing.

Depending on the size of your import data, this work can be done manually using a spreadsheet program - simply cut and paste your data into the corresponding cell in the provided import templates. However, for larger data sets, data transformation can be done with custom programming (for example, a Python script written by a developer), existing tools such as the open source Pentaho Data Integration application, or by use of a CSV transformation script.

We have included some guidelines for creating custom CSV transformation scripts. See:

• https://wiki.accesstomemory.org/Resources/CSV_transformation

Estimating import duration¶

Once you’ve mapped the columns names in your CSV export to the corresponding AtoM-compatible CSV column names you may wish to perform a test import.

A test import gives you an idea how long the import will take to complete on your hardware. To estimate how long it will take to import 20,000 rows of CSV data, for example, you could time the import of the first 1000 records and multiply that by 20.

If your test import proves to be too slow on your hardware, or you don’t have hardware to spare, you can consider using cloud computing resources, such as Open Hosting, Amazon EC2, or Rackspace Cloud.

Testing your import¶

Once you’ve prepared your import, you may want to clone your AtoM site and test your import on the clone before importing to your production AtoM installation. This prevents you from having to delete any improperly imported data. During import testing if you want to delete all imported data you can use the command-line purge tool.

Back to top

Hierarchical relationships¶

Information objects often have parent-child relationships - for example, a series is a child of the fonds to which it belongs; it has a parent fonds. If you want to import a fonds or collection into AtoM along with its lower levels of description (i.e. its children - series, files, items, etc.), you will need a way to specify which rows in your CSV file belong to which parent description.

There are two basic ways to specify which information object is the parent of an information object being imported in your CSV - either through the use of the legacyID and parentID columns (generally used for new descriptions being imported, or from descriptions being migrated from another access system), or by using the qubitParentSlug column to import new child descriptions to an existing description in AtoM.

You can use a mix of legacyId/parentId and qubitParentSlug in the same CSV, just not in the same row. So, for example, if you wanted to import a series description as a child of a description already in AtoM, as well as several files as children of the series description, you could set a legacyID for the series, use the qubitParentSlug to point to the parent fonds or collection already in AtoM, and then use the parentID column for all your lower-level file descriptions. However, using both parentID and qubitParentSlug in the same row will cause a conflict, and AtoM will prefer the qubitParentSlug so the import does not fail.

Both methods of establishing hierarchical relationships are described below.

LegacyID and parentID¶

One way to establish hierarchical relationships during a CSV import involves the use of the parentId column to specify a legacy ID (referencing the legacyId column of a previously imported information object). This way is most often used for migrations from other access systems. Using this method, parent descriptions (e.g. fonds, collections, etc) must appear first (i.e. above) in your CSV and must include a legacyID - while child records must appear after (i.e. below) their parent records in your CSV, and must include the legacyID of the parent record in the parentID column.

Here is an example of the first three columns of a CSV file (shown in a spreadsheet application), importing a Fonds > Series > Item hierarchy:

Important

When the CSV is imported, it progresses row by row - meaning, if your CSV is not properly ordered with parent records appearing before their children, your import will fail!

qubitParentSlug¶

The other method of importing hierarchical data into AtoM enables you to specify an existing archival description that doesn’t have a legacyID (one, for example, that has been manually created using the AtoM web interface), and import descriptions as children of the target description(s).

To specify a parent that exists in AtoM, you must first take note of the parent information object’s slug. The “slug” is a textual identifier that is included in the URL used to view the parent description. If the URL, for example, is http://myarchive.com/AtoM/index.php/example-fonds then the slug will be example-fonds. This slug value would then be included in your import in the qubitParentSlug column in the rows of children of the parent description.

Alternately, if you are using the command-line to perform your import, you can use the --default-parent-slug option in the command-line to set a default slug value, that will be used when no qubitParentSlug or parentID values have been included for the row. For more information, see the details in the Command-line options section below.

Here is an example of the first few columns of a CSV file (shown in a spreadsheet application), importing a new series to an existing fonds, and importing two new file-level descriptions to an existing series:

If desired, you can mix the use of the qubitParentSlug column with the use of the parentID column in the same CSV - for example, you could attach a new series to an existing fonds by giving it a legacyID and the slug for the existing fonds in the qubitParentSlug column, and then including lower-level files attached to the new series by adding the legacyID of the new series to the parentID column of the new files.

Important

You should not add both a parentID and a qubitParentSlug to the same row - AtoM expects one or the other. When the import encounters both columns populated in a single row, AtoM will default to use the qubitParentSlug value. In general, each row must have only one or the other - either a parent slug, or a parent ID.

Creator-related import columns (actors and events)¶

The eventActors, eventActorHistories, eventTypes, eventDates, eventStartDates, and eventEndDates columns are related to the creation of actors and events. In AtoM’s data model, an archival description is a description of a record, understood as the documentary evidence created by an action - or event. It is events that link actors (represented in AtoM by an authority record) to archival descriptions - see Entity types for more information.

The most common use for these columns is to add creation dates associated with an actor via an authority record - in this case, the eventType is Creation, the eventActor is the creator, and the various eventDates fields are the dates of creation associated with the description.

However, some standards support other types of events as well. For example, the ISAD(G) template in AtoM also supports Accummulation as an event type, while the Canadian RAD template allows direct association between actors and events, and includes many other event types, such as contribution, broadcasting, manufacturing, and more.

A brief summary of the fields is included below, followed by a longer discussion of their use:

• eventActors: Add the associated creator or other actor name here. AtoM will link to an existing authority record or create a new one. For details on linking behavior, see below: On Authority records, archival descriptions, and CSV imports.

• eventActorHistories: Add the associated creator or other actor’s administrative or biographical history here. Equivalent to ISAD(G) 3.2.2, RAD 1.7B, and/or DACS 2.7 - Administrative/Biographical history. This will be mapped to the related authority record.

• eventTypes: Type of event. Values include:

  • ISAD: Creation, Accumulation
  • RAD: Creation, Accumulation, Contribution, Collection, Broadcasting, Manufacturing, Custody, Publication, Reproduction, Distribution

• eventDates: Display dates shown in public user interface for event on

  archival description view page. May use free-text, including typographical conventions to express approximation or uncertainty (e.g. [190-?]; [ca. 1885]).

• eventStartDates: Internal ISO-8601 formatted (e.g. YYYY, YYYY-MM,

  YYYY-MM-DD) start date of event

• eventEndDates: Internal ISO-8601 formatted (e.g. YYYY, YYYY-MM,

  YYYY-MM-DD) end date of event

• eventDescriptions: Only in RAD CSV template. Adds a note to the event
• eventPlaces: Only in RAD CSV templates. Associates a place with the event.

If multiple actors/events exist for an information object, the values in these fields can be pipe-separated (e.g. using the | pipe separator between values).

On Authority records, archival descriptions, and CSV imports¶

AtoM tries to support the reusability of actor information through the maintenance of authority records that can be linked to archival descriptions and other entities. This, and the rationale for this, is outlined in greater detail in the following sections:

• AtoM, Authority records, Biographical histories, and Name access points
• On Name vs. Subject Access Points

This also affects how actor names are handled during a CSV import. Some of the key behaviors are outlined below:

Creating new actor records on import

• AtoM looks for creator names in the eventActors column in the RAD and ISAD CSV import templates, as well as access point names (used as subjects) in the nameAccessPoints column during a CSV import of archival descriptions.
• Similarly, any Administrative / biographical history data in an archival description CSV import (i.e. data contained in the eventActorHistories CSV column will be mapped to the “History” field (ISAAR-CPF 5.2.2) in the related authority record (generated from the data contained in the creators column of the CSV), and then is presented in AtoM in any related descriptions where the entity is listed as a creator.
• Where multiple creator names and histories are included in an import, eventActors and eventActorHistories elements are matched 1:1 in the order they appear in the CSV, divided by pipe elements (e.g. | ). For example, if the eventActors column contains name 1|name 2, the eventActorHistories should also include history 1|history 2 to match on import. If there is no history for the first actor, you can include NULL, and AtoM will ignore the imput - e.g. name 1|name 2 should be matched with NULL|history 2 to include only a history for name 2.
• This same NULL approach can be used for any matched date values where multiple actor names are included for import - eventDates, eventStartDates, eventEndDates can all include NULL if you wish to leave these blank when associating multiple actors with an event. An example, using the RAD template:

• If a creator history element is included in a CSV import, but no creator name is included, AtoM will still automatically generate a stub authority record and map the history data to the “History” field (ISAAR-CPF 5.2.2) - the authority record will be left untitled, until the user manually adds the appropriate name to the authority record. Similarly, if there are more eventActorHistories elements included in an import than creator names included in the creators column, the final biographical/administrative history will be mapped to an untitled authority record. Because the slug is normally based on the title of the authority record, AtoM will generate a random alphanumeric string to use as the slug - and you will not be able to edit this through the user interface.

Attempting to match to existing authority records

Important

If you are attempting to import both an archival description CSV and an authority record CSV to supplement the actor data that is linked to your descriptions, you must import the authority record CSV first. On import, the description CSV code will look for exact matches to which it can link - but the authority record CSV import code does not currently have similar logic. If you import your authority record CSV template after the description CSV, you might end up creating duplicate authority records!

• AtoM will attempt to find matches for current authority records. However, to avoid collisions, or situations in which multiple imports overwrite the same authority record in a multi-repository system, the approach is conservative - for a match to be made and a link to an existing record added instead of a new record being created, the authorized form of name must be an exact match.
• Note that if biographical/administrative history included in the CSV will be ignored - it will not update an existing history when a match is made.
• If there is no exact match on the authorized form of name, then AtoM will create a new actor record. Since AtoM does not currently have the capacity to suspend the import and ask the user whether to update an existing authority record or ignore it and create a new one, this method was chosen as the least destructive. However, this means that currently, administrative or biographical histories CANNOT be updated via an import.
• This also means that users should be careful to double check authority linking behaviors in AtoM following an import, and manually perform any desired adjustments where needed.

See also

• On Authority records and EAD imports

Digital object-related import columns¶

As of AtoM 2.1, two new columns have been added to the ISAD and RAD CSV import templates: digitalObjectPath and digitalObjectURI. These columns will allow you to link or upload a digital object and attach it to the new information object being created in that row of the CSV.

In AtoM, a 1:1 relationship is maintained between information objects and digital objects - meaning that for every archival description, you can only attach one digital object. If you wish, you can create new child records - a number of item descriptions as children of a file-level description; a number of part descriptions as children of an item (for multiple views of a single object, for example, or individual pages of a single book uploaded separately, etc), and so on.

In the CSV templates, the digitalObjectPath and digitalObjectURI columns are positioned after the publicationStatus column, and before the physical object-related import columns.

The digitalObjectPath column can be used to upload local digital objects - simply provide a complete path and filename to the digital object.

The digitalObjectURI column can be used to link to externally hosted, publicly available digital objects, such as those available at a specific URL on the web. You must have a path directly to the digital object which includes a file extension, and not just to a web page with a digital object located on it somewhere - it is often the equivalent of right-clicking on a digital object in your browser and selecting “View image”.

You can use a mixture of the digitalObjectPath and digitalObjectURI columns throughout your CSV (linking some information object rows to locally uploaded digital objects, and others to web-based resources), but you cannot use both columns in the same row. If AtoM encounters a CSV row where both the digitalObjectPath and digitalObjectURI columns are populated, it will favor the digitalObjectURI value, and ignore the digitalObjectPath value.

Physical object-related import columns¶

The physicalObjectName, physicalObjectLocation, and physicalObjectType columns are related to the creation of physical objects and physical storage locations related to an archival description.

For more information on working with physical storage in AtoM, see: Physical storage.

Standards related fields¶

Most fields in the CSV template have been named in a fairly obvious way, translating a simplified version of the field name in our data entry templates into a condensed camelCase. For example, the Rules for Archival description’s General Material Designation is rendered in the CSV header as radGeneralMaterialDesignation. In both the RAD and ISAD templates, the Scope and Content field is marked by the CSV header scopeAndContent. However, for users seeking a full mapping of fields, consult the RAD template and ISAD template pages for further details.

The culture column indicates to AtoM the default language of the descriptions being uploaded. This column expects two-letter ISO 639-1 language code values - for example, “en” for English; “fr” for French, “it” for Italian, etc. See Wikipedia for a full list of ISO 639-1 language codes.

Other data entry notes¶

• language and languageOfDescription, like culture, expect two-letter ISO 639-1 language code values - for example, “en” for English; “fr” for French, “it” for Italian, etc. See Wikipedia for a full list of ISO 639-1 language codes. Unlike the culture column, however, these two fields will accept multiple values separated by a pipe character - for example, en|fr|it.
• The script and scriptOfDescription columns expect four-letter ISO 15924 script code values - for example, “Latn” for Latin-based scripts, “Cyrl” for Cyrillic scripts, etc. See Unicode for a full list of ISO 15924 script codes.
• Alternative identifiers and their display labels can be imported using the alternativeIdentifiers and alternativeIdentifierLabels columns. Use pipe (|) separators to add multiple values. There should be a 1:1 relationship between the number of identifier values in the alternativeIdentifiers column and corresponding labels in the alternativeIdentifierLabels column.
• An accessionNumber column can be added to create a link between an existing accession record and an archival description being imported via CSV. See the section on Accession CSV import below for more information.

Using the user interface¶

For small imports (i.e. CSV files with less than 100 records), imports can be performed via the user interface.

If you have double-checked the above, you should be ready to import your descriptions.

To import a CSV file via the user interface:

1. Click on the Import menu, located in the AtoM header bar, and select “CSV”.

2. AtoM will redirect you to the CSV import page. Make sure that the “Type” drop-down menu is set to “Archival description”.

3. Click the “Browse” button to open a window on your local computer. Select the CSV file that you would like to import.

4. When you have selected the file from your device, its name will appear next to the “Browse” button. Click the “Import” button located in the button block to begin your import.

5. After your import is complete, AtoM will list the amount of time the import took, and provide a link to the archival description browse page. Unlike the XML import, a link directly to your import is not provided, because a CSV upload may contain multiple descriptions; instead, a link to the browse page is given, so users can locate their descriptions.

Tip

Use the sort button located in the top-right hand side of the browse page to change the results display to be ordered by “Most recent” if it is not already - that way, the most recently added or edited descriptions will appear at the top of the results. If you have come directly here after importing your descriptions, they should appear at the top of the results.

6. If any warnings or errors are encountered, AtoM will also display them on the import page. Some warnings will cause an import to fail (and some will not - they will alert the user, but the import will still complete), while all error messages mean that the import has failed, and a link to the archival description browse page will not be provided. - instead, the CSV upload page will reappear below the error message. Errors can occur for many reasons - please review the checklist above for suggestions on resolving the most common reasons that CSV imports fail.

Using the command-line interface (CLI)¶

For larger CSV imports (e.g. those with 100 or more records), we recommend using the Command-line interface to import your descriptions.

Example use (with the RAD CSV template) - run from AtoM’s root directory:

php symfony csv:import lib/task/import/example/rad/example_information_objects_rad.csv

Command-line options¶

By typing php symfony help csv:import into the command-line from your root directory, without specifying the location of a CSV, you will able able to see the CSV import options available (pictured above). A brief explanation of each is included below.

The --application, --env, and connection options should not be used - AtoM requires the uses of the pre-set defaults for symfony to be able to execute the import.

The --rows-until-update option can be used for a simple visual representation of progress in the command-line. Enter a whole integer, to represent the number of rows should be imported from the CSV before the command-line prints a period (e.g. `` . `` ) in the console, as a sort of crude progress bar. For example, entering --rows-until-update=5 would mean that the import progresses, another period will be printed every 5 rows. This is a simple way to allow the command-line to provide a visual output of progress. For further information on the --rows-until-update option and an example of the command-line option in use, see also the section below, Display the progress of an upload via the command-line interface (CLI).

You can use the --skip-rows option to skip X amount of rows in the CSV before beginning the import. This can be useful if you have interrupted the import, and wish to re-run it without duplicating the records already imported. --skip-rows=10 would skip the first 10 rows in the CSV file, for example. Note that this count does not inlcude the header column, so in fact, the above example would skip the header column, and rows 2-11 in your CSV file.

The --error-log option can be used to specify a directory where errors should be logged. Note that this option has not been tested by Artefactual developers.

Use the --source-name option (described above to specify a source when importing information objects from multiple sources (with possibly conflicting legacy IDs). This will ensure that multiple related CSV files will remain related - so, for example, if you import an archival description CSV, and then supplement the authority records created (from the creators field in the description CSV templates) with an authority record CSV import, using the --source-name option will make sure that matching names are linked and related, instead of duplicate authority records being created. You can also use this option to relate a large import that is broken up into multiple CSV files. See the Legacy ID mapping: dealing with hierarchical data in a CSV section above for further tips and details on the uses of this option.

The --default-legacy-parent-id option will allow the user to set a default parentID value - for any row in the CSV where no parentID value is included and no qubitParentSlug is present, this default value will be inserted as the parentID.

Similarly, the --default-parent-slug option allows a user to set a default qubitParentSlug value - wherever no slug value or parentID / legacyID is included, AtoM will populate the qubitParentSlug with the default value. If you are importing all rows in a CSV file to one parent description already in AtoM, you could use the --default-parent-slug option to specify the target slug of the parent, and then leave the legacyID, parentID, and qubitParentSlug columns blank in your CSV. Note that this example will affect ALL rows in a CSV - so use this only if you are importing all descriptions to a single parent!

By default, AtoM will build the nested set after an import task. The nested set is a way to manage hierarchical data stored in the flat tables of a relational database. However, as Wikipedia notes, “Nested sets are very slow for inserts because it requires updating left and right domain values for all records in the table after the insert. This can cause a lot of database thrash as many rows are rewritten and indexes rebuilt.” When performing a large import, it can therefore sometimes be desirable to disable the building of the nested set during the import process, and then run it as a separate command-line task following the completion of the import. To achieve this, the --skip-nested-set-build option can be used to disable the default behavior.

NOTE that the nested set WILL need to be built for AtoM to behave as expected. You can use the following command-line task, from the AtoM root directory, to rebuild the nested set if you have disabled during import:

php symfony propel:build-nested-set

Tip

Want to learn more about why and how nested sets are used? Here are a few great resources:

• Mike Hyllier’s article on Managing Hierarchical data in MySQL
• Evan Petersen’s discussion of nested sets
• Wikipedia’s Nested set model

Similarly, when using the user interface to perform an import, the import is indexed automatically - but when running an import via the command-line interface, indexing is disabled by default. This is because indexing during import can be incredibly slow, and the command-line is generally used for larger imports. Generally, we recommend a user simply clear the cache and rebuild the search index following an import - from AtoM’s root directory, run:

php symfony cc && php symfony search:populate

However, if a user would like to index the import as it progresses, the --index option can be used to enable this.

Back to top

Using the user interface¶

For small imports (i.e. CSV files with less than 100 records), imports can be performed via the user interface.

To import an events CSV file via the user interface:

1. Click on the Import menu, located in the AtoM header bar, and select “CSV”.

2. AtoM will redirect you to the CSV import page. Make sure that the “Type” drop-down menu is set to “Event”.

3. Click the “Browse” button to open a window on your local computer. Select the events CSV file that you would like to import.

4. When you have selected the file from your device, its name will appear next to the “Browse” button. Click the “Import” button located in the button block to begin your import.

Using the command-line interface (CLI)¶

For larger CSV imports (e.g. those with 100 or more records), we recommend using the Command-line interface to import your descriptions.

Example use - run from AtoM’s root directory:

php symfony csv:event-import lib/task/import/example/example_events.csv

There are also various command-line options that can be used, as illustrated in the options depicted in the image below:

By typing php symfony help csv:event-import into the command-line from your root directory, without specifying the location of a CSV, you will able able to see the CSV import options available (pictured above). A brief explanation of each is included below.

The --application, --env, and connection options should not be used - AtoM requires the uses of the pre-set defaults for symfony to be able to execute the import.

The --rows-until-update, --skip-rows, and --error-log options can be used the same was as described in the section above on importing descriptions. For more information on the --rows-until-update option, see also the section below, Display the progress of an upload via the command-line interface (CLI).

Use the --source-name to specify a source importing to a AtoM installation in which information objects from multiple sources have been imported, and/or to associate it explicitly with a previously-imported CSV file that used the same --source-name value. An example is provided above in the section on legacy ID mapping.

The --event-types option is deprecated, and no longer supported in AtoM.

Back to top

CSV columns¶

• The uploadLimit column allows a user to set a default upload limit for a repository at the time of import. This value should be a number, representing Gigabytes. For more information on the use of respository upload limits in AtoM, see: Set digital object upload limit for an archival institution.
• Almost all other fields are drawn directly from the archival institution edit template in AtoM, which is based upon the International Council on Archives’ International Standard for Describing Institutions with Archival Holdings (ISDIAH). For more information on the use of each field, see: International Standard for Describing Institutions with Archival Holdings.
  • Most fields in the CSV template have been named in a fairly obvious way, translating a simplified version of the field name in our data entry templates into a condensed camelCase. For example, ISDIAH 5.3.2, Geographical and cultural context (in the Description Area) becomes geoCulturalContext in the CSV template. Consult the ISDIAH for further help with fields.
• The culture column indicates to AtoM the language of the descriptions being uploaded. This column expects two-letter ISO 639-1 language code values - for example, “en” for English; “fr” for French, “it” for Italian, etc. See Wikipedia for a full list of ISO 639-1 language codes.

Using the command-line¶

Example use - run from AtoM’s root directory:

php symfony csv:repository-import lib/task/import/example/example_repositories.csv

There are also various command-line options that can be used, as illustrated in the options depicted in the image below:

By typing php symfony help csv:repository-import into the command-line from your root directory, without specifying the location of a CSV, you will able able to see the CSV import options available (pictured above). A brief explanation of each is included below.

The --application, --env, and connection options should not be used - AtoM requires the uses of the pre-set defaults for symfony to be able to execute the import.

The --rows-until-update, --skip-rows, and --error-log options can be used the same was as described in the section above on importing descriptions. For more information on the --rows-until-update option, see also the section below, Display the progress of an upload via the command-line interface (CLI).

The --merge-existing option may be used to avoid the creation of duplicate repositories. That is - if, during import, any rows in the CSV contain the same authorized form of name as a repository already in the database, those rows will be ignored (i.e. not imported).

You can use the --upload-limit option to specify the default upload limit for repositories which don’t specify their uploadLimit in the CSV file. That is, if for example you performed a CSV import with the command-line option of --upload-limit=5, then for every repository in the CSV that does NOT have a value in the uploadLimit column, the default value of 5 GBs will be assigned.

Back to top

CSV Columns¶

A brief explanation of the main fields in each CSV template is included below.

Using the user interface¶

To import authority records via the user interface:

1. Click on the Import menu, located in the AtoM header bar, and select “CSV”.

2. AtoM will redirect you to the CSV import page. Make sure that the “Type” drop-down menu is set to “Authority record”.

3. Click the “Browse” button to open a window on your local computer. Select the authority record CSV file that you would like to import.

4. When you have selected the file from your device, its name will appear next to the “Browse” button. Click the “Import” button located in the button block to begin your import.

Using the command-line interface (CLI)¶

Example use - run from AtoM’s root directory:

php symfony csv:authority-import lib/task/import/example/authority_records/example_authority_records.csv

There are also various command-line options that can be used, as illustrated in the options depicted in the image below:

By typing php symfony help csv:authority-import into the command-line from your root directory, without specifying the location of a CSV, you will able able to see the CSV import options available (pictured above). A brief explanation of each is included below.

The --application, --env, and connection options should not be used - AtoM requires the uses of the pre-set defaults for symfony to be able to execute the import.

The --rows-until-update, --skip-rows, --error-log, and --index options can be used the same was as described in the section above on importing descriptions. For more information on the --rows-until-update option, see also the section below, Display the progress of an upload via the command-line interface (CLI).

The --alias-file and --relation-file options are used to import accompanying alternate name (aka Alias data) and relationship CSV files at the same time as the authority record CSV import. An example of each will be given below, though they can be used together.

php symfony csv:authority-import lib/task/import/example/authority_records/example_authority_records.csv \
--alias-file=lib/task/import/example/authority_records/example_authority_record_aliases.csv

php symfony csv:authority-import lib/task/import/example/authority_records/example_authority_records.csv \
--relation-file=lib/task/import/example/authority_records/example_authority_record_relationships.csv

Using the user interface¶

For small imports (i.e. CSV files with less than 100 records), accession record imports can be performed via the user interface.

To import an accessions CSV file via the user interface:

1. Click on the Import menu, located in the AtoM header bar, and select “CSV”.

2. AtoM will redirect you to the CSV import page. Make sure that the “Type” drop-down menu is set to “Accession”.

3. Click the “Browse” button to open a window on your local computer. Select the authority record CSV file that you would like to import.

4. When you have selected the file from your device, its name will appear next to the “Browse” button. Click the “Import” button located in the button block to begin your import.

Using the command-line interface (CLI)¶

For larger accession record imports (e.g. those with 100 or more records), we recommend using the command-line task to import your CSV file.

Example use - run from AtoM’s root directory:

php symfony csv:accession-import /path/to/my/example_accessions.csv

There are also a number of options available with this command-line task.

By typing php symfony help csv:accession-import into the command-line from your root directory, without specifying the location of a CSV, you will able able to see the CSV import options available (pictured above). A brief explanation of each is included below.

The --application, --env, and connection options should not be used - AtoM requires the uses of the pre-set defaults for symfony to be able to execute the import.

Use the --source-name to specify a source importing to a AtoM installation in which accessions and information objects from multiple sources have been imported, and/or to associate it explicitly with a previously-imported CSV file that used the same --source-name value. An example is provided above in the section on legacy ID mapping.

The --rows-until-update, --skip-rows, --error-log, and --index options can be used the same was as described in the section above on importing descriptions. For more information on the --rows-until-update option, see also the section below, Display the progress of an upload via the command-line interface (CLI).

Back to top

Finding the information_object_id¶

The information_object_id is not a value that is accessible via the user interface - it is a unique value used in AtoM’s database. You can, however, use SQL in the command-line to determine the ID of an information object. The following example will show you how to use a SQL query to find the information_object_id, if you know the slug of the description:

1. First, you will need to access mysqlCLI to be able to input a SQL query. To do this, you will need to know the database name, user name, and password you used when creating your database during installation. If your database is on a different server (e.g. if you are trying to SSH in to access your database server), you will also need to know the hostname - that is, the IP address or domain name of the server where your database is located.

2. The following is an example of the CLI command to enter to access mysqlCLI:

   mysql -u root -pMYSECRETPASSWORD atom
   

   • -u = user. If you followed our installation instructions, this will be root
   • -p = password. Enter the password you used during installation right after the -p. If you did not enter a password, include the -p on its own. If you are prompted later for a password and didn’t use one, just press enter.
   • -h = hostname. If your database is on a different server, supply either an IP address, or the domain name, where it is located.
   • atom = your database name. If you followed our installation instructions, this will be atom; otherwise enter the database name you used when installing AtoM.

3. You may be prompted for your password again. If so, enter it. If you did not use a password during installation, simply press enter.

4. Your command prompt should now say something like mysql>. You can now enter a SQL query directly.

5. The following example SQL command will return the information_object_id for a desription, when the information object’s slug is known:

   SELECT object_id FROM slug WHERE slug='your-slug-here';
   

6. The query should return the object_id for the description. Here is an example:

7. Enter quit to exit mysqlCLI.

Using the digital object load task¶

Before using this task, you will need to prepare:

• A CSV file with 2 columns - EITHER information_object_id and filename, OR identifier and filename
• A directory with your digital objects inside of it

Here is a sample image of what the CSV looks like when the identifier is used, and the CSV is prepared in a spreadsheet application:

You can see the options available on the CLI task by typing in the following command:

php symfony help digitalobject:load

The --application, --env, and connection options should not be used - AtoM requires the uses of the pre-set defaults for symfony to be able to execute the import.

By default, the digital object load task will not index the collection as it runs. This means that normally, you will need to manually repopulate the search index after running the task. Running without indexing allows the task to complete much more quickly - however, if you’re only uploading a small set of digital objects, you can choose to have the task index the collection as it progresses, using the --index (or -i) option

The --path option will allow you to simplify the filename column in your CSV, to avoid repetition. If all the digital objects you intend to upload are stored in the same folder, then adding /path/to/my/folder/ to each object filename seems tedious - your filename column will need to look something like this:

filename
/path/to/my/folder/image1.png
/path/to/my/folder/image2.jpg
/path/to/my/folder/text1.pdf
etc...

To avoid this when all digital objects are in the same directory, you can use the --path option to pre-supply the path to the digital objects - for each filename, the path supplied will be appended. Note that you will need to use a trailing slash to finish your path prefix - e.g.:

php symfony digitalobject:load --path="/path/to/my/folder/" /path/to/my/spreadsheet.csv

TO RUN THE DIGITAL OBJECT LOAD TASK

php symfony digitalobject:load /path/to/your/loadfile.csv

NOTES ON USE

• If an information object already has a digital object attached to it, it will be skipped during the import

• Remember to repopulate the search index afterwards if you haven’t used the --index option!

  php symfony search:populate
  

Regenerating derivatives¶

Sometimes the digitalobject:load task won’t generate the thumbnail and reference images properly for digital objects that were loaded (e.g. due to a crash or absence of convert installed, etc.). In this case, you can regenerate these thumbsnail/reference images using the following command:

php symfony digitalobject:regen-derivatives

For more information on this task and the options available, see: Regenerating derivatives.

Back to top