Hi Clara,
I think we've reached agreement about the Place field in the RAD edit template - though changing the current behavior would require sponsorship, and careful analysis not to negatively impact existing user data when upgrading. I would love to hear from other users if they agree with this perspective!
Using the RAD template for published materials, and capturing details such as publisher etc, does present some challenges. I believe I understand what you're describing, but I'm not sure what to suggest!
Part of this stems from the history of the RAD standard itself, and the intended focus of AtoM.
There is an excellent history of the Canadian RAD standard written by Richard Dancy, available freely in Archivaria here:
The short version: RAD was created before the ICA had created international standards such as ISAD(G), and as such, was one of the first national archival description content standards. Lacking a model for creating such a standard, archivists at the time essentially copied the AACR2 library cataloguing standard, added a bunch of elements in a "Notes" section specific to archives, and left much of the rest mostly untouched.
As a consequence, there are a lot of elements in RAD that have to do with published materials, and that rarely apply to typical archival material (i.e. primary documents) - for example, Standard Number is generally an ISBN; and most archival documents don't have a "Statement of responsibility" etc...
In adding support for RAD, AtoM of course needed to cover all available core RAD fields. However, AtoM's intent has always been focused primarily on archival management, and not the management of published materials. Thanks to RAD we have all these fields related to published materials, but the user experience for them is not very great, because AtoM prioritizes workflows that help archivists (such as treating linked actors as authorities, so they can be reused and given standard forms of name, etc).
I think there are probably some good workarounds and strategies to make cataloguing work in AtoM, but it's true that some workflows are more challenging, because early design decisions made in the RAD implementation heavily favor archival workflows.
I would say that if you're using AtoM for cataloguing, then it would probably still make sense to treat the "publisher authorities" as true authorities and choose a standard form of name (that everyone will use for linking), and then capture variations in the names over the years in some of the other form of name fields. It's true that this contradicts part of RAD, which is not ideal... but remember, much of RAD, when its history is understood, doesn't really apply to archival materials as we think of them (as in unique primary records).
Using a notes field is also a fine idea if this makes the management easier for you - I think you'll just need to come up with some consistent internal policies and documentation so that all users are following the same process and rules, using the same notes field, etc.
In terms of development, I'm not clear how we could improve the situation for publishers without either a) making AtoM harder to use for archivists (i.e. no longer controlling authorities), or else b) trying to make AtoM cover a whole other domain (library-like cataloguing), for which there are many other applications better suited to this. Perhaps long term you might consider finding a good cataloguing solution in another program, and considering how best to link cataloguing entries created there to descriptions managed in AtoM when necessary? Otherwise, I'd probably suggest a custom plugin, so any custom templates or fields can be kept separate from the current data model and forms.
As you can tell, I'm not sure what the best course is. I would welcome input from other community members!
Cheers,