2014-07-07 Meeting Notes AtoM Evaluation

Date

07 July 2014

Attendees

Goals

  • Share feedback on the use of AtoM as an archival management system at the Briscoe Center 
  • Determine how we might customize AtoM to meet our need
  • Discuss the Finding Aid Masters directory

Discussion Items

ItemQuestions/Comments
To what extent can the multi-institutional instance be configured to exclude the option to select your repository? Can this be done by creating repository level permissions?
Other levels of customizations: fields, scope notes (it uses DACS standards but not Briscoe interpreted versions of DACS which we train new staff on - schema compliance issue); the instructions need to be not just DACS but more specific 
Eventhough the forms are intuitive, everyone had to have DACS open the whole time to make sure that the values being entered match the way prescribed by the XML formatting that we currently use. 
When entering the value into a title field: we have a way to enter the title into the finding aid one way, the holding record in one way and the citation - what do we use for the title in AtoM, especially if we were going to import the accession record database - the collection title is written in the accession record the same as 
We need to have a way to update our training to reflect. 
Can we customize the accession record - the accession record number is automated in the system - what about back imports. 
Paloma experimented with linking everything together (accrual, archival description) and you can only link on creation. You can't link an existing archival description to an existing accession record. You can create archival description from the accession record and the field that are common talk to each other. It would be great if you could create an archival description and have a field for accession number and it links directly to that. 
The EAD export did not validate - it doesn't look for typos. It puts attributes in the EAD that doesn't have in the DTD. We would definitely need to add our style sheet for the XSLT. 
The identifiers are required for every level of arrangement and that doesn't make any sense for us. Even if we did, it doesn't force you to create unique identifiers. 
For every child level of arrangement, you have the same fields as you do for the highest level of arrangement - that is clunky. 
The whole interface seems very collection-level focuses, it seems hard to see the inventories 
It would be good to have a feature that is a preview (like the TARO preview) because proofreading in AtoM is currently very difficult. There are so many fields and they are by default collapsed into sections. It creates the possibility that one could export the XML from AtoM and see many errors that you didn't catch before - the system does not do its own ead validation. 
The physical container is under "more". There is a physical storage taxonomy that is like "box" etc. It would be helpful to add some fields to the form that creates a new box such as "inches" of that collection material. It seems like physical storage is its own module in the tool so presumably its its own data table - so if we could combine our multi-page shelf lists on the server to import and use the physical storage feature. The scope and content for physical storage would be how many inches are left, and then you could search by box that has room left. 
Very limited print functionality within Atom (though having TARO does mitigate this) 

Action Items

  • Add your notes to this page and add any items that may have been missed by the meeting note-taker
  • Use the Google Doc "Briscoe Archival Description Task Force" to record FAQs that might be useful to refer to so that we can make a case for migrating our current documentation to a wiki (version control)
  • Consider strategies for whittling down the Finding Aid Masters directory