pulling together accession records (FMP database) and lots of other data from distributed materials/locations (Word docs, etc.) > processing > finding aid > TARO > MARC

• manage accession records, & use them to create archival descriptions (centralized, linked data)
• display standards in help text for fields (currently DACS, could be customized for our local needs)
• customizable taxonomies, system saves previously entered subject terms, auto-suggests during data entry
• manage and link to container list (although not searchable)
• provide visual reference via digital object links (single or set)
• export to EAD with one click (although issues with stylesheet & validation need to be worked out)
• granular permissions and workflow settings to accommodate items in progress/not yet published.

• field requirements not currently enforced
• sequence of adding series & sub series is not intuitive if you want nesting … series and sub-series fields are same as collection level, which is not typically needed
• accession number field value generated by system - how to deal with legacy records/numbers?

Canadian company Artefactual's model is similar Drupal community (open source software freely available for deployment, but you can contract with company for customizations, support, hosting; new features are integrated into subsequent releases of the software).

Dunbarton Oaks, a DC repository affiliated with Harvard has been using AtoM for awhile: relatively small set of data for migration; positive experience with tech support/forum; contracting for image cataloging tool/VRA core module

SAA AtoM interest group is in the works

Recommendation that we compile our questions and post them to the forum so that the wider community benefits from the answers/convo

• How would AtoM use align with the TARO planning grant?
  • Amy said grant plans include more defined standards, and will include EAD 3 release - these should probably be settled before an implementation of AtoM
• What would legacy finding aid migration to AtoM look like among our group?
  
  • Amy asked about importing from Excel or Word files and whether container level structure expressed in formatting will translate to AtoM (AtoM accepts csv imports, so preliminary conversion would be required.)
  • Planning to import from a wide variety of doc formats would be crucial
  • Jessica suggested breaking existing practice into two streams: 1) new workflow for new activities, and 2) legacy migration. Each unit's needs will be different.

EAD export needs to use our TARO stylesheet. Also, current output doesn't necessarily validate.

Accession record numbering is automated and doesn't adhere to our numbering system-can the number field be made editable?

If under "Manage Physical Storage" we could add searchable information such as "3 in. space for photos" or "Shelf space for 3 oversize boxes," we could replace our current shelflist with Atom

Archival descriptions must be linked to accession records upon creation. You can't link descriptions to accessions after the fact.

Scope notes that appear on the data entry fields are not terribly helpful. Can this text be customized?

Every child level of arrangement has the same data entry fields. Can this be streamlined and duplicative fields removed?

Each level in the hierarchy demands a unique identifier, but the uniqueness isn't enforced. Similarly, "required fields" aren't actually enforced.

Some kind of preview/print functionality within Atom would be nice so that we can spot errors before uploading our files to TARO.

There isn't a one to one relationship between some Atom fields and TARO template. Where do we enter OCLC # and preferred citation? Can those fields be added to Atom?