Amanda came in 2002
from hand encoding to AT (past 5 years)
They migrated all of their data to their AS test instance from disparate sources:
everything they wanted to migrate was in AT
the migration path from AT to AS is robust
it took about 8-10 hours for the migration script to run
importing the xml files you already have shouldn't be too bad
they did the hand entry into AT over a series of months - the head of the department did the manually data entry to dump additional context knowledge into the record
one of the reporting features of AT and other ADMS is to sort by finding aid status
controlled access terms - before getting material into AT, they had all these legacy files with terms all over teh place - in the system they can see all variations and merge on an authoriative version
AS and AT don't connect to online authorities yet - there is an AS plugin for LCNAF but they aren't working right now
they haven't used the DR api yet, but they are testing with some digital objects within AS collections -
not a digital asset management system - you can see the image if you give the full filepath to the asset in DSpace
DSpace is their trusted digital repository - curation, authoritative metadata, etc.
whatever they have in archivesspace as a digital object is a pointer to the DSpace instance
the surprising thing was: they wanted to be members to access documentation, they paid and started testing. when they went to reference the documentation they found that it wasn't ready for prime time
AS came to Rice to do their basics workshops to fill in the gaps of the documentation
Amanda's evaluation process:
they showed IT that they had researched AtoM, ArchivesSpace or XTF
they looked at AtoM but the US presence wasn't big enough
Search for collection names gives you everything including folder titles
the workshop doesn't cover Solr configuration
tech support - you will get an answer, they have had a positive experience with internal IT support
there is an underlying assumption that there will be an IT staff to interpret/translate whatever comes back
they will host internally
internally they did some UI and discoverable metadata feild changes
estimated time IT spent on the cutomizations - less than a day BUT getting familiar enough with the system to know what and where to make changes - that takes time/getting familiar with Ruby on Rails
for installation and configuration on internal servers - couple of hours or days depending on how familiar you are with the software and the language its written in
one thing they want to do is allow folks to download a PDF finding aid that is formatted in a more intuitive way
it could use some usability testing - labeling of buttons that export in different formats was EAD->XML
preview functionality - you can see your container list laid out with box and folder numbers at the top of the collection. in terms of final PDF-style preview would require you to make it live real quick - export on user side
it would be a pain but they have a stylesheet that they are using to clean up the XML that is exported from ArchivesSpace
it exports schema-compliant EAD but TARO only takes DTD compliant EAD so we would have to backtrack the EAD to DTD compliance
ArchivesSpace - it wouldn't hurt to wait on that but also needing to do something
it wasn't time, it was "here are the value adds from using this systems", focusing on functionality that doesn't exist outside of the system
systematic edits
bird-eye view/reporting
marc record creation - AS exports MARC XML and they now provide that marc xml to the catalogers and they create a marc record out of it (this model Amanda estimates to be a 50% increase in speed in terms fo creating MARC records
she does have to delete one of the scopecontent/abstract feilds
she wouldn't trade her added value functionality now
there are user defined fields for stuff it doesn' naively track