This interview with Karma Foley, Director of Library and Archives at the Smithsonian Channel, is part of an ongoing series of interviews with CollectiveAccess users. Foley got her start in media as a production assistant to ethnographic filmmaker John Marshall, and later worked as a stock footage and archival researcher. Realizing that archives was where she really wanted to be, Foley earned an MLS at the University of Maryland and processed 16mm film and analog video collections for the Smithsonian’s Human Studies Film Archives. She joined Smithsonian Channel and established an archival program there in 2011.
Q: Could you give us some background information about your institution? Does your institution have a public-facing CollectiveAccess site?
A: Smithsonian Channel is a joint venture between Showtime Networks, Inc and the Smithsonian Institution. The company was formed in 2005 and we began broadcasting in 2007, so our media collections are all very new and almost entirely digital. We are a private company, and do not have a public CollectiveAccess site (the front end of our database is only accessible from within our company network).
Q: Describe how CollectiveAccess functions at your institution: Why did you decide to use it? How many staff members use it? How does it contribute to the organizational mission?
A: We use CollectiveAccess for our internal footage and program database. Production teams use it to locate raw footage and public domain stock masters that they can re-use in new programs, and a wider range of staff use it to find information on our programs or view programs. There are five people on the Library & Archives team who use the CollectiveAccess database (called SCOUT) for cataloging and research. We are actually not sure how many staff in the rest of the company are using the system (we’d like to install some analytics tools on the front end to keep better track of this), but I estimate that we have about six regular users and somewhere between 10 and 20 occasional users.
Initially, SCOUT only contained records for our original raw footage and re-usable stock masters (e.g., public domain material), which is only of interest and use to production teams. We produce a small number of programs in-house and many more out-of-house; currently our in-house production teams can access the system, but when off-site teams need research done in SCOUT someone on the Archives team will do that research for them. Recently we began adding our completed broadcast programs to the database and have been doing outreach to let other staff know this resource is available—that’s why we don’t have a good handle on just how many users we have.
SCOUT contains descriptive, technical, and rights metadata for our assets, as well as low-resolution screeners. We do not make use of CollectiveAccess’s built-in media transcoding capabilities, but instead upload low-res screener files that we’ve created separately. We also use the database for collections management to an extent.
The database contributes to our company by saving production teams time and money, if they are able to re-use existing footage instead of shooting something new or licensing footage from a stock footage vendor, or if they need to screen an older program for research purposes. Teams are also able to access footage that may improve or enrich the storytelling of their program—that supports our mission to produce compelling documentary television.
Q: Tell us about a time you ran into a problem with something you wanted to do in CollectiveAccess. What was the problem and how did you solve it?
A: We had Whirl-i-Gig install and configure CollectiveAccess for us, both the back end and the front end. I make small tweaks to the back end when needed (adding values to controlled vocabularies, updating hover text, adjusting displays, etc) but we don’t touch the front end (Whirl-i-Gig handles the front end entirely). Each year we budget for some support hours from Whirl-i-Gig since our internal IT team is not able to support CollectiveAccess or the Linux server that it runs on.
I can’t think of any really “good” problems that we tackled and solved in-house, but there are some small things that come up somewhat regularly. For example, almost every time I need to update a display, a controlled vocabulary, or our Places hierarchy, I forget exactly where I need to go and I spend too much time hunting around. I nearly always find it, but it takes too much time. And I always forget to make myself a cheat sheet! There were one or two times when I had to ask Whirl-i-Gig, and learned that the list I wanted to edit was at the system level and not available via the UI [User Interface].
My usual method for attempting to fix or change things in CollectiveAccess is to hunt around, look at the documentation on the CollectiveAccess website, and hunt around some more. It’s not efficient, but I’m usually able to find and change what I need to, and it’s very satisfying when that happens.
Q: What’s one thing you wish you knew how to do (or do better) with CollectiveAccess?
A: Run reports and export stats like: number of records created in a certain time period, number of media representations uploaded in a certain time period. I’d also like to be able to get stats on front-end users and searches. I think we need to install some separate tools for this, but maybe the functionality is already there and I just don’t know!
Q: What’s your favorite back-end trick or feature? How has this trick or feature been helpful to your institution?
A: Duplicat[ing] items in a set is really useful for us when we have a group of videotapes that get digitized. Our data model is based on PBCore, and it allows us to create records for multiple Objects (instantiations) for a single Work, so for example we can have one record for the videotape of the program, “Seizing Justice: The Greensboro 4” and another record for the master digital file, both tied to a Work record for the program that has all the descriptive metadata. Once we digitize a batch of tapes, I can create a set and duplicate the Object records in that set, then do a batch edit and just a little hand cataloging to complete the records for the master digital files.
Delet[ing] all items [in a set] is rarely used but came in very handy a few times when we had issues with a metadata upload. We needed to scrap the records and re-upload, and I was very grateful to not have to delete the records one-by-one.
Also, batch edit is extremely helpful and we use it a lot. It’s a big time saver and also helps with consistency.
Q: Have you ever used resources or sought advice on CollectiveAccess from other institutions that use it? Have you ever participated in discussions with other members of the CollectiveAccess user community?
A: When considering using CollectiveAccess as our database, I talked with librarians at NPR and a couple of folks at Northeast Historic Film. This was to get their input on the system generally. I haven’t really reached out to other users for problem-solving or getting short-cut ideas, but would like to in the future.
A few years ago, at an Association of Moving Image Archivists (AMIA) conference, there was a meeting to assess interest in forming a CollectiveAccess users group within AMIA. The turnout was impressive, though I’m not sure how many people were current users and how many just wanted to learn more about the software. In any case, there was a lot of interest. But I didn’t hear anything more about it after the conference.
Q: What advice do you have for organizations who are considering adopting CollectiveAccess as a cataloging or digital collections platform?
A: Go for it! But make sure that you either have someone on staff who can provide technical support, or that you have a budget for support from Whirl-i-Gig or another vendor. Open source software doesn’t require licenses or subscriptions, but it’s not exactly free, either.