RDA Implementation

48 views
Skip to first unread message

Ronai Savegnago Ribeiro

unread,
Oct 10, 2017, 7:29:55 PM10/10/17
to AtoM Users
Hello, I am a Master's student, guided by PhD. Daniel Flores, Federal University of Santa Maria, Brazil. My goal is to implement a plugin that makes it possible to insert documents with the metadata of the RDA (Resource, Description and Access) cataloging standard.

Is there any focus I should take, be it changing code or changing the database to implement the new functionality?

Sincerely, Ronai!

Dan Gillean

unread,
Oct 11, 2017, 11:45:26 AM10/11/17
to ICA-AtoM Users
Hi Ronai, 

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! 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory

--
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-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/0cee5af9-81a1-48b9-868f-91f1fc1e25be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ronai Savegnago Ribeiro

unread,
Jan 3, 2019, 7:53:59 PM1/3/19
to AtoM Users
Hello Dan, I'm about to conclude my dissertation, and I wonder if I should request a ticket registration for it? My work is based on the support of the bibliographic standard RDA in AtoM.

Thank you,
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.

Dan Gillean

unread,
Jan 4, 2019, 11:01:29 AM1/4/19
to ICA-AtoM Users
Hi Ronai, 

Congratulations on successfully finishing your dissertation! I'm not exactly sure what you mean by a ticket, but if your plugin is available in a public repository with some instructions on how community users could incorporate it, I would be happy to add it to our wiki, in this section: 
You could also register for a wiki account and add it yourself!

 If you intend to share your work with the public AtoM project and have it incorporated into a future public release, please be sure to read the links included in the final part of my last response again: 

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.

Regards, and congrats! Let me know if I can answer any other questions for you! 

Dan Gillean, MAS, MLIS
Reply all
Reply to author
Forward
0 new messages