Early in our NDSR cohort chats, each resident agreed that our host site’s current metadata collecting and organizing practices could be improved. Many of us sought to find a database tool that could help our staff manage their data effectively.
KBOO is like many other organizations that keeps its archives information in multiple spreadsheets. Tapes that were digitized by a vendor were sent back with magnificent details on the digitization process—yet these details were not consolidated with the inventory. The original inventory did not document which items had digital files, or where the files were stored. File location information was not in any spreadsheet and had to be determined by asking staff. If anything happened to the preservation master files, there would have been no way to restore them or get them back, and perhaps nobody would have noticed. This is obviously a tragic example that nobody wants. It demonstrates what could happen if an archive doesn’t know how to maintain digital files.
Audiovisual archivist and technologist Dave Rice reminded me that the important work is for an archive to protect its media and metadata, regardless of a database system or not. Spreadsheets are perfectly acceptable since repositories of a range of sizes need solutions in a range of sizes. At KBOO, the spreadsheet system was not efficient. Excel doesn’t allow more than one person to edit the file at the same time to control versioning so new information would be created by volunteers and not folded into the master spreadsheet. The master record wasn’t kept up to date, and the proliferation of Excel sheets would have continued. Yes, Excel sheets work but KBOO’s use of them was not working. Google Sheets and Excel Online didn’t handle KBOO’s large single spreadsheet very well. Could an easy to use database encourage staff to control and protect its metadata? I kept researching for a system that could make things better.
Kara Van Malssen, Partner & Senior Consultant at AVPreserve, gave our first NDSR webinar (it was excellent!). In a follow-up, I asked for some advice in my database search and she suggested that I prepare for comparing database systems by creating business requirements, functional requirements, and use cases. This information is necessary whenever an organization is thinking of engaging a tech developer or vendor. Small repositories often don’t have the time or archival perspective to ask useful questions about how it wants its data to be stored and accessed. Some developer/vendors work with the organizations (at cost) to determine what the needs are. I suggested that KBOO could determine their needs in-house, it would take time, but no additional cost (contact me if you’re curious to see them).
So, after documenting the requirements, the question was “Is there something that does it all?”
My perspective is that it is possible to do almost everything with technology. So the answer is yes, multiple people and companies could develop the system. However, the requirements are only one thing an organization has to document. KBOO also needed to document the availability of financial resources (up-front and ongoing) and commitment of staff time and knowledge (up-front and ongoing) required for ongoing maintenance of a system.
This is where the database comparison work began. I decided to research and compare several open-source and non-open source systems that support audiovisual records and archival metadata: systems as column headers and KBOO requirements as row headers (contact me if you’re curious to see it). I also gathered notes about up-front and ongoing costs and reached out to staff at institutions to get comments about their experience installing and maintaining their chosen system—this relates directly to up-front and ongoing costs. For open-source I looked at the activity level of the user base in finding solutions.
KBOO’s immediate needs are for managing its audio metadata in-house, preparing records for public searching, and opening up the records so that multiple staff and volunteers can see what we have and fix records with correct or additional information. I proposed ResourceSpace (on a Bitnami stack) installed on a network server for in-house use for several reasons that fit KBOO’s needs:
* Records can be imported and exported to/from csv
* Different security/access levels for administrator and volunteer/staff data entry
* More than one person can view and edit at a time
* Batch upload of media can associate files with existing records
* Database fields can be defined based on my PBCore data model
* Installation and set up is easy to understand
* Great documentation and very active user group
* More reasons (contact me if you’re curious)
Time will tell if KBOO will use and maintain the system into the future. Exporting back to csv actually is the most important from my perspective—the data is still flat. I will only be at KBOO until the end of May for the NDSR program, and KBOO does not have an archivist. The set-up of ResourceSpace is uncomplicated enough to set up with clear directions (which I’m writing), and if anything happens, KBOO can always turn the data back into the Excel format it is familiar with. ResourceSpace can be used for other potential archiving needs as determined by KBOO and a future archivist, but for now I’m keeping it simple to meet their current requirements.
So can ResourceSpace do it all? Well, it can do the specific things KBOO needs it for. ResourceSpace is still just a tool that a human uses. As such, it is a tool that a human needs to understand and take care of. I said earlier that almost anything can be done with technology. Human work can’t be replaced with computers. But—human work can be simplified with technology and computers. I hope this tool encourages work to be done more easily by many people.
This post was written by Selena Chau, resident at KBOO Community Radio.
blog.americanarchive.org 