Hi Krista,
The short answer is that for maintenance reasons going forward, I would suspect that adding a new taxonomy and all the required pieces to get what you want from that (e.g. integration with the EAD import/export, the CSV import export, the taxonomy browse pages, etc) will be easier to maintain in a separate plugin than an attempt to bend an existing taxonomy to this new purpose. Either way, this sounds like a lot of development, and I suspect that not all of it will be changes you can easily keep isolated in a plugin - meaning that no matter what, doing this much custom work will make future upgrades difficult, requiring developers to manually reapply a lot of customizations, and even rewrite parts where the base code may have changed.
There are still more alternatives you might consider. First, without any development, here are some more browsing options you may not have come across:
There's a treeview option that exists for the entire holdings that can be turned on or off - here is the example from our demo site:
You can expand top-level records with descendants, and it will show all the immediate levels below, and so forth all the way down. The second you click on any record in the tree, you go to that view page, where you then have a treeview just for that archival unit. A user browsing from here could easily go here from Record Group to the Subgroups, to the Series, etc.
There's also a configurable Inventory List, as a way of browsing lower level records in an archival unit - here is an example from the demo site again:
Administrators can configure what levels are included in the Inventory list. By default, the Inventory list will be available in the right-hand context menu (i.e. the sidebar) of an archival description view page if the levels below it include records that would appear in the inventory list.
Finally, to set up my suggestions below, I will also point out that if you use Record Group as your top descriptive levels, then these will be available for browsing by users on the archival description browse page. AtoM includes a number of facets, filters, and sort options, as well as an advanced search panel. See:
As for an alternative suggestion:
If you customize the levels of description in AtoM (i.e. so you have Record Group, Subgroup, Series, etc - all the levels you currently use as levels in AtoM), and you look at the facets on AtoM's search / browse page, you will see that you can facet results by level of description. If you navigate to the View page of a fonds / collection / record group in AtoM and look in the right-hand context menu, you'll see a "Browse as list" link, which will take you to a search/browse page already filtered to just the records of the current archival unit. All of AtoM's search / browse criteria are passed via URL - i.e. when you view a browse page for a particular record group, and then further filter it to just series-level records in that record group, looking at the page URL you will see that an ID for the collection / record group and and ID for the level of description are both part of the URL. Each description's view page will also have a treeview if it is part of an archival hierarchy, giving users another way to explore the structure of the record group. Given these facts:
What if you added some custom code that would use JavaScript to insert some special browse buttons wherever you'd like on the view page of your Record Group descriptions? Using the URL parameters, a little JS widget could generate and insert links to browse pages that are pre-filtered to just the subgroup records, or just the series, etc. The advantage of something like this would be that:
- If it uses JavaScript inserts on page load, then it could sit alongside AtoM, and the only code changes you would need directly in AtoM would probably be a small amount of modifications to the view page, to inject the buttons. Otherwise, it could query the AtoM database for the relevant IDs, and then use existing search/browse URLs filtered by those IDs (to the current Record Group, to the Subgroup level, etc...) for the link used by the inserted button. This means that the level of changes you need to make in AtoM directly are greatly reduced, making future upgrades much easier.
- If you're otherwise using the existing functionality, then you don't need to mess around with import/export mapping for EAD and CSV support, for example.
- If a JavaScript sidecar application doesn't work for this approach, this level of changes could probably be done in a custom plugin - again helping with ongoing maintenance. You would just need overrides for the description view templates, to add your custom buttons.
Your custom theme could also make some of the existing view page browse options (like the Inventory list, the "Browse as list" and "Browse digital objects" sidebar links, even the Finding aid download button, etc) more prominent as well, if desired. Given that you can upload your own custom finding aids (docs
here), that is yet one more way you could be providing users with customized exploration tools without development.
Anyway, just trying to think of some less intensive ways to achieve similar outcomes.
One word of warning: the AtoM Maintainers are working on a significant upgrade of AtoM's dependencies for the 2.9 release. Most importantly will be changes to the search index. As you may know, Elasticsearch (the library we use for search) changed their license after one of their 7.x release s, to something that we at Artefactual (and many others in the open source development community) consider potentially a risk for the ongoing use of ES in an open source application like AtoM. This is one of the reasons we have not upgraded ES in some time. Two community forks appeared almost immediately, and new rival projects popped up. The Maintainers have been observing this for some time, running tests, and deciding how to move forward with AtoM - either replace Elasticsearch with something new, move to one of the community forks, or upgrade to the last open ES version and delay any final decisions for another major release. I do not know what they will decide.
All this to say: it's a challenging time to do significant AtoM development customization, because the underlying code is likely to change significantly in the next major release! At minimum, be sure to develop against our qa/2.x development branch, update your local environments frequently, and keep your custom code abstracted and separated as much as possible.
If you are committed to the approach you've outlined, then I would recommend using previous commits and pull requests in AtoM's GitHub history as guides - searching for PRs etc related to the Genre taxonomy, the addition of the DACS template, etc. Here is the most recent PR I could find that includes the addition of a new taxonomy:
Good luck!