Sounds like a very interesting project! Since RDA is much more library focused than archival, I expect this will be a lot of work - you'll have to make a number of changes to the database for new fields, for example. Here are some resources that you might find useful to get started.
First, we have some slides on developing for AtoM that are available here:
All of the AtoM code is available on GitHub, here:
I suggest that you familiarize yourself with git
for distributed version control, if you are not already familiar. There are many many free resources out there (and even a free book
) You can read a bit more about AtoM's GitHub code repository on our wiki, here:
We also have a number of other development resources on our wiki, here:
AtoM was originally developed using the Symfony 1.x framework, and the Propel 1.x ORM. You might want to familiarize yourself with Symfony before beginning:
I would suggest you start by looking into Symfony's plugin architecture, as you will want to build any new template you create as a plugin. Studying the code and looking at how the RAD template is implemented is a good idea as well - it reuses existing ISAD-related fields wherever possible, but then adds new fields to a different database table where the data model needed to be extended. You should consider following a similar design. In fact, Since the Canadian RAD standard was derived from AACR2 (the precursor to RDA), you may be able to reuse many of the RAD database fields. Here is where you can find the RAD plugin code:
We maintain a Vagrant box that can be used for local development - see:
I strongly suggest that you work of our most recent code, and that you are pulling in changes regularly, so your work is up to date, and easier to merge in the future. We have a new Vagrant box that will install using our qa/2.5.x branch, but be aware - this branch is under active development and undergoing a LOT of dramatic changes at the moment, as we are upgrading AtoM's Elasticsearch version from 1.7 (in the current 2.4 release) to version 5.5, which will be included with AtoM 2.5. This means a huge amount of changes, and some regressions - we are currently trying to find and fix them as quickly as we can. However, if you develop against 2.4 or earlier, then when you upgrade your work may no longer function properly, since ES 5.5 will change many things. For this reason, please be sure you are working against the most recent qa/2.5.x branch, and pulling in changes (so you can resolve conflicts, etc) regularly.
Finally, if you are intending to share your code back with the community, and you hope to someday see it merged into a public AtoM release, please read the following pages:
This means - share your work early; keep your commits small, clean, and atomic; follow the coding standard recommendations; make sure the work is generalized enough to be useful to the broader AtoM community; make it configurable where possible (e.g. can people disable the plugin if they don't use RDA? etc); and most importantly, be sure to budget time and resources for a final code review, testing, merging, and documentation. This is unpaid work for us and it can take a lot of time to review large pull requests. If you want Artefactual to take on the maintenance of your work going forward, be sure to plan for this.
Best of luck!