ArcLight has three preliminary objectives:
- It will support discovery of physical and digital objects, including finding aids described using Encoded Archival Description (EAD) and, for the latter, presentation and delivery of digital materials.
- It will be compatible with Hydra and ArchivesSpace.
- It will be developed, enhanced and maintained by the Hydra/Blacklight community.
With regard to the second objective, compatibility with Hydra and ArchivesSpace is exactly what we need (although not necessarily in that order). We'll be going live with ArchivesSpace (fingers crossed!) sometime between now and March 31st, 2016, and, as part of a MLibrary-wide effort we'll be moving to a Hydra-based implementation of Deep Blue in the "medium-term" (two to three years). In case you don't know the back story on that latter point, shortly after the grant was awarded, MLibrary decided to adopt Hydra as a repository platform. In light of this development, we hope to fulfill grant requirements by integrating DSpace into the workflow, but will give care to ensure that solutions for sharing data and metadata between systems will also be appropriate in a Hydra environment (and, in general, repository agnostic).
We're also excited about the fact that ArcLight could be integrated with ArchivesSpace. The process now to add or update EADs in our online display is rather cumbersome, involving at least three versions of a finding aid, two versions of the EAD, and up to four people (including one that's doesn't even work at the Bentley!) to get them up and make them live. Integration with ArchivesSpace would cut all of those numbers down to one.
ArcLight Design Process
|Discovery >>> Information Architecture >>> Interaction & Visual Design (and Development)|
The second phase of "Discovery," which kicked off their user-centered design process to produce documentation to guide development, and which we have been contributing to, is just now coming to a close. Stanford hopes to start the actual development of ArcLight by 2016, and I for one can't wait to see what happens!
What It Isn't
Needless to say, we got very excited about all the things that ArcLight might be. But before I go any further, I need to be upfront about three very important things that ArcLight is not:
|Three of the things that ArcLight is not.   |
In fact, I think Andrew Berger, Digital Archivist at the Computer History Museum, said it best (in reference to yet another thing that ArcLight is not):
Uniquely naming things is hard: Hydra/Blacklight's ArcLight https://t.co/bhOCjkvVp8 Project Arclight http://t.co/XnqFEmmfcj— Andrew Berger (@andrewjbtw) June 14, 2015
In All Seriousness, What It Isn't
We did actually get very excited about ArcLight, which is why we began contributing to the project in the first place. We see a lot of synergy with what their doing and what we're doing. In fact, sometimes we get so excited thinking about all the things ArcLight and, for that matter, Hydra, could be that we forgot one of their more important characteristics: that they aren't actually anything, at least not yet, at least not for us in a tangible way.
And the danger about that, of course, at least for [over?]eager archivists like ourselves, is that we end up wanting these systems to be everything! As a result, our Stakeholder Interest and Goals document, which I'll discuss in further detail below, is a bit pie-in-the-sky; we can only hope that our high expectations won't set us up for disappointment!
How We've Contributed
We've contributed in two significant ways to the ArcLight project, by conducting some user interviews and by contributing the aforementioned Stakeholder Interest and Goals document. I'll spend a little bit of time talking about the user interviews, but the rest of the post will mostly be devoted to the Stakeholder Interest and Goals document.
First, doing these user interviews was fun! It was especially interesting to hear from the perspective of both archivists (two from Curation and one from Reference) and researchers. It was also a good reminder that, from a usability standpoint, we probably should have been doing interviews (or something like them) all along.
These interviews have been transcribed and will feature heavily in the next stage of the ArcLight design process. In fact, I just received an email this week that they need to comb through the transcripts and note common issues raised, relevant user scenarios, good quotes that indicate user goals, etc. According to Gary Geisler at Stanford, they will likely share some summary/distillation of the interviews with the broader ArcLight design collaborator group later.
Stakeholder Interest and Goals document
Basically, this document gives an overview of our access stack (is that a thing?), the grant project and our interest in ArcLight, as well as an acknowledgement that we are ignorant about some parts of how this whole thing will work, that some of functionality we're about to describe may in actuality reside in a repository rather than in ArcLight.
Attractive, best-in-class discovery interface for archival content, flexible enough to change as quickly as best practices for web design change.
Support and recognize EAD elements for search and disambiguation. At the same time, move away from presenting EAD finding aids as static objects.
Support and recognize PREMIS rights and conditions governing access/use so these metadata are acted upon in conducting and presenting search results. Limit access to archival components and digital objects in a range of ways based on PREMIS statements, including full embargo of highly sensitive content (such that this content would not display in public search results).
Integration with other platforms, like Aeon, Mirlyn (local catalog), HathiTrust, Archive-It, Archivematica, search engines and metadata aggregators such as ArchiveGrid and DPLA.
Assessment through search logs, analytics, download reports, etc.
Ensure that any updates, revisions, or additions to ASpace descriptive, administrative, and rights metadata are immediately reflected in the ArcLight interface.
Integrate discovery and display/streaming of digitized/born-digital content, so that researchers don’t have to switch from a discovery layer to a repository.
- Provide full-text search of indexable content (including OCR’d scans, plain text, PDFs, Word documents, and/or other relevant file formats).
- Limit searching/browsing/faceting to particular collections
- Permit fuzzy searching/approximation so that researchers do not need to know the exact spelling of subjects, names, or other keywords.
Communicate relationships between physical and born-digital/digitized components of collections in a usable and meaningful way.
For complex digital objects, display files/groups of content/archival components in a meaningful way. Allow researchers to view all the files in a folder without (or files in a finding aid) without having to go back and forth to the finding aid.
Library Information Technology
We're currently working this out! As a stakeholder, they represent many other stakeholders, so their task is a bit more daunting!