Question about the flexibility of the modules

79 views
Skip to first unread message

Benjamin Janssens

unread,
Feb 28, 2020, 9:51:29 AM2/28/20
to AtoM Users

Hello all,


I’m new to AtoM and the forum and I couldn't find an answer to my question. So I’m trying here.


I’m currently working on a master thesis over the ability of ArchivesSpace and AtoM software to deal with the known implementation problems of the EAD (in Belgium). It’s maybe a question a bit naïve. But is there a way in AtoM to modify easily the description of the titles (and the titles themselves) in the modules and to change their order (without going through the software code)?


For instance, the module for the creation of a new archival description refers to the ISAD(G) rules. I would like to delete them and to reorder the structure of the module in a way closer to some of my original finding aids. The actual descriptions and titles pose also a problem in terms of language because they are unilingual. However in Belgium we must have bilingual titles and descriptions (in French and Dutch).


Thank you in advance!


Benjamin 

Dan Gillean

unread,
Feb 28, 2020, 11:04:29 AM2/28/20
to ICA-AtoM Users
Hi Benjamin, 

Welcome to the AtoM community! 

I'm not sure I completely understand your first question. You want to edit and rearrange the elements that appear in the ISAD(G) template - is that correct?

Unfortunately, that's not possible without development at the moment, and it is not something we are likely to add as a feature in future public releases. The AtoM project's original goal was to support standards-based description and access, and AtoM was originally built around the ICA standards, so the basic model of ISAD(G) is built into the archival description data model. It would require development to change, reorder, or remove fields from the templates. 

In general, while reordering or relabelling fields may not be as destructive, if you are thinking of adding new fields specific to your institution's needs, we highly recommend not adding custom fields to AtoM.  From our experience we believe using custom fields is a risk to the long term maintenance of your descriptive data.  We have done many data migrations to AtoM from legacy systems that allow the addition of custom fields and we've found custom fields are generally:

  1. Inconsistently used. Because they are not standards-based fields and there is usually no strong guidelines about how to use the custom fields, the fields are used in different ways by different users. Often a custom field is introduced by one member of an institution, is only used by that member, and then its use is abandoned after that member leaves the institution.

  2. Filled with inconsistent data. Once again, because there are usually no clear guidelines about what data should go in the field, custom fields often contain inconsistent types of data.  This makes mapping the data to a new descriptive system very difficult.

  3. Difficult to export.  Adding a custom field for AtoM does not automatically add that field to the export templates (EAD XML, DC XML, MODS XML, CSV, etc) so unless custom development work is done to allow export of this custom data it is effectively trapped in AtoM. Depending on the nature of your custom field, there may be no good mapping to an existing metadata standard that will allow you to export your data in a way that could be recognized and imported into another system at a future date. 

  4. Difficult to maintain. Artefactual, and by extension the AtoM project, is committed to standards-based description and access - AtoM was originally developed with support from the International Council on Archives, and its goal was to make standards-based description and access more easily achievable by small and medium-sized institutions without the resources for a proprietary solution. We remain committed to this vision of the application, and will not be accepting custom modifications of templates in the public project. This means that it will be up to your institution to maintain your custom fields over time - meaning you will likely need to have developers available every time you want to upgrade the application to the newest public release, to resolve conflicts, fix bugs, and successfully re-merge your customizations into your local instance. Many institutions do not have the resources to support this level of ongoing maintenance, which can leave you stuck on a legacy version of the application. 

We strongly believe that using open source software and descriptive standards are the best thing you can do for long term continuity of your institutional data.  Your descriptive metadata represents a significant investment of time and effort on the part of your institution. We urge all our AtoM users to protect that investment by making sure you have a plan to get your data out of AtoM if necessary.  We'd love you to use AtoM forever, but the reality is that your institution will probably outlast AtoM in its current form. :)

If you are mainly interested in relabelling and reordering (and perhaps hiding or removing some fields), it *may* be possible to do this via a custom theme plugin. At Artefactual we have successfully changed some of the view and edit template field labels this way. The advantage of this is that all the code to customize AtoM is kept in a separate plugin - making it easier to upgrade to newer versions and reapply your custom theme. 

It's possible to perform template overrides via the custom themes. We have some initial development resources available for custom themes here: 
A couple other thoughts on this: 
  • Don't forget that any field you don't populate won't show up on the view page of your descriptions. It might be inconvenient to have a bunch of edit fields you don't use, but I personally think this would be less inconvenient than having to maintain a custom fork of AtoM just to hide them!
  • If you are trying to describe legacy descriptions for which you already have finding aids, one approach might be to provide minimal descriptions in AtoM and simply upload the existing finding aid directly. See:  https://www.accesstomemory.org/docs/latest/user-manual/reports-printing/print-finding-aid/#generate-or-upload-a-finding-aid

Regarding translations: 

From AtoM’s initial planning and development, one of the core project goals has always been multilingual support at all levels of the application. In AtoM, both user interface elements and user data can be translated into multiple languages - this international design is built right into the data model itself. 


For user interface elements, Artefactual maintains an open source web-based translation platform (Weblate) and detailed documentation for our strong community of volunteer translators. Community translators supply translations, which are then reviewed by peers before being incorporated into subsequent public releases. Additionally, users can make local changes to the supplied translations via AtoM’s built-in translation bar


For user metadata, the same standards-based templates can be used to supply translations. Users with sufficient permissions simply use the Language menu to change the interface to the selected translation language, and then enter edit mode on a record. The original language source string is then displayed for context above the related edit field, and translators add their content directly to the same edit forms, without altering the source strings. Here are some example screenshots:


Adding a translation for a menu item:


translate-menu.png

Translating the term "Fonds" in the Levels of description taxonomy:

translate-terms.png

Translating the user interface labels available in Admin > Settings
translate-ui-labels.png


You can of course do the same with your descriptions. See: Translate content in our documentation for more information. 


A couple further notes on this:


As you'll notice from the screenshots, you may need to translate terms that appear in drop-down menus in the templates separately. For example, the levels of description terms shown above appear in the Level of description drop-down in the ISAD(G) template - so you'll need to translate the terms directly in the source taxonomy (which you can find by going to Manage > Taxonomies). The same is true for menu elements! 


Before you can translate locally, you need to make sure your language is added in AtoM. Navigate to Admin > Settings > i18n languages, and add your language via the autocomplete menu there. You will need to reindex the site after doing so. After that, your selected language will appear as an option in the global Language menu

Finally, it's also possible to change the default installation culture of AtoM. You can do so by modifying one of the installation configuration files - see: 

Hope this helps!

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/7030ed2b-7e05-4ecc-9623-a4cc0edb38dd%40googlegroups.com.

Benjamin Janssens

unread,
Mar 2, 2020, 4:57:04 AM3/2/20
to AtoM Users
Hi Dan,

Thank you very much for your answer.

It is very detailed and contains all the information I needed. It's perfect !

The flexibility of the modules is a very often request I'm facing from the archivists concerning the software.
So I hope that AtoM, one day, will have a such feature. 
But I fully understand the difficulty to implement that.

Thank you again for your help,

Benjamin

Rachael Gilg

unread,
Jul 9, 2020, 11:58:08 AM7/9/20
to AtoM Users
Hi Dan,

Would you mind providing a little more info about the following statement in your reply:

"If you are mainly interested in relabelling and reordering (and perhaps hiding or removing some fields), it *may* be possible to do this via a custom theme plugin. At Artefactual we have successfully changed some of the view and edit template field labels this way. The advantage of this is that all the code to customize AtoM is kept in a separate plugin - making it easier to upgrade to newer versions and reapply your custom theme."

I am developing a custom theme and know how to override the core Atom module templates by putting my modified templates in the /modules or /templates directories in the theme. Is it also possible to modify plugin templates? I want to override the editSuccess.php and indexSuccess.php templates in the arDacsPlugin plugin. Is there a way to include overrides to those in my theme and if so what is the file structure I should use? 

Thanks so much!
Rachael
To unsubscribe from this group and stop receiving emails from it, send an email to ica-ato...@googlegroups.com.

Steve Breker

unread,
Jul 13, 2020, 3:58:19 PM7/13/20
to AtoM Users
Hi Rachael

In researching your question I discovered this thread where the same question (overriding template files from other plugins from within a template) is discussed: https://groups.google.com/u/1/g/ica-atom-users/c/cG1sj9LOWR0/m/B4x0dD9XBwAJ

Unfortunately, it does not seem to arrive at a satisfactory result for this particular case. Since the DACS plugin and the new theme would both need to be activated, it seems research would be required to determine how to cause one plugin to take precedence over the other.

An alternative might be to customize the DACS plugin itself, but ongoing maintenance would be needed at AtoM upgrade time to merge any new AtoM arDacsPlugin modifications to your custom version. 

Steve
Reply all
Reply to author
Forward
0 new messages