It's possible that AtoM can meet your needs, but it will depend mainly on:
- How relevant archival content standards are to your project
- How granular the different access rights need to be
On point 1:
AtoM was originally developed in partnership with the International Council on Archives (ICA
), as a way to allow small and medium-sized archival institutions to describe their holdings in accordance with ICA archival standards (such as ISAD(G)
, etc), and make them publicly available on the web. This has two implications for you:
All of the forms and labels in AtoM relate to archival concepts and terminology. If your project does not have any archivists involved, then some of the language and interface elements may not be intuitive to you or your end users. We do include detailed descriptions and a glossary of terms in the AtoM documentation,
but if you are looking for a general solution for storing and sharing digital objects such as PDFs, you may want to look into Digital Asset Management
Systems (DAMS) instead. These applications are specifically tailored for storing, sharing, tagging, and adding access rules for digital objects. One open source example that looks strong to me would be ResourceSpace
- though there are many others!
B) While you can certainly deploy AtoM behind a firewall for internal use only, AtoM was designed for use as a public-facing archival catalog, available to researchers on the web. This also means the application is intended to be deployed on a server, not run locally on a personal computer. If you're looking for something that will just be used internally for a small subset of people, it's possible that AtoM may not be the best solution.
On point 2:
AtoM was first developed over 10 years ago. We depend on community support for major feature development - you can learn more about the history of the AtoM project, and how we currently maintain and develop AtoM, here:
One part of the application that has not received a major overhaul in this time is the Permissions module, which controls the access rights that can be applied to descriptions and their attachments, such as digital objects (e.g. PDFs).
Because of this, there are some known issues when you start adding very granular permissions (per user and per description). So: if you intend to apply very specific access rights, there may be limitations to what AtoM can support.
I've previously written many longer thread responses in the forum about the permissions module in AtoM, if you'd like more details. See for example:
While it should NOT be used for the long term storage of data you wish to retain, we do provide a simple development environment that can be installed on a laptop or personal computer for testing. This Vagrant box is intended for developers and those who would like to test out the application - we don't recommend you use it as a production instance! In your case, it might be useful to test out AtoM's upload and permissions to see if they will meet your needs. For information on setting up the AtoM vagrant box, see:
We do have a public demo site, but uploads are disabled there for security reasons, which is why setting up a local test instance may be a better way to evaluate if it will meet your needs. However, to get a general sense of AtoM, playing around with the demo site might be a good first introduction. The site will automatically refresh every hour - login details are on the homepage. See: