No college is an island: Amherst College chooses Islandora

Behind the letters, images, photographs, and other treasures on display in Amherst College Digital Collections is software. To the public, this software is largely invisible, with our user interface showcasing the discovery and display of the digital objects from Archives and Special Collections. Our underlying software infrastructure requires ongoing maintenance, upkeep, and upgrade as technology changes and our needs change. I’m here today to share a choice we’ve made for the future of our digital collections software, which is that we are going to start using Islandora in our software stack.

island and lighthouse
Mitchell Lighthouse on Long Island, Edward and Orra White Hitchcock Collection

This month we are beginning the process to migrate to Islandora. This software is only one piece of the complex network of tools we use to manage our digital collections, but it is an important piece. We use a few different key pieces of software to maintain our online digital collections, one of which is the Fedora repository software, an open source software platform maintained by many institutions in the cultural heritage and educational sector. We are, for the foreseeable future, going to continue to use Fedora, and participate in the development and code contribution to the Fedora open source software. It is a bit unusual to have small liberal arts college contributing code to an open source software project, and it is also fortuitous for Amherst and for the larger academic community. Having input in the governance and technical direction of the software helps us to ensure the needs of liberal arts colleges are realized in the repository software, which benefits our direct needs, and also means we can help surface the needs of many other smaller liberal arts colleges.

map of cuba
Mapa de la Isla de Cuba y plano de la Habana, Manuscript Collection

Up until the past year, we’ve been on our own for the most part in supporting our digital collections repository software. It is an achievement that we are proud of, because of the talented software developers in the library and information technology at Amherst, and for the vision of our library leadership in seeing a place for Amherst at the table of Fedora, which is largely governed by large research institutions.  Being at the table with Fedora has given us something else besides advocacy – it has provided us with a community of colleagues across the globe, who act as peers, sounding boards, and supporters. And the community has given us a much broader reward – because we are a small liberal arts college, we are a small team supporting digital collections. Participating in the Fedora community gives us so many more colleagues and resources, as well as professional growth opportunities.

In our geographical neighborhood, several of our Five College Consortium colleagues have recently developed their own collaborative digital collections platform in Compass, utilizing Fedora as well as the Islandora software. Down the road while visiting with colleagues at Williams, we’ve learned about efforts to bring together members of a group of mostly liberal arts colleges that are part of the Islandora Collaboration Group (ICG) to create shared development projects for Islandora, namely the ISLE and LASIR projects. What stands out from our conversations with colleagues is the power of collaboration, and of aggregation of resources, to create necessary change and development in digital repository software.

title page for book
David Cusick’s sketches of ancient history of the Six Nations: comprising, first, a tale of the foundation of the Great Island (now North America), Native American Literature Collection

We’ve been thinking about Islandora for years at Amherst. Before I arrived about two years ago, it was on the table, as a possible alternative to our custom user interface for our digital collections. In the time I’ve been at Amherst, we’ve had two cycles of planning for our next iteration of our digital collections software. At first, we were holding out for Islandora CLAW, which is the next phase of Islandora, and will include native linked data support, something we are strongly interested in seeing in a future repository.  And while we are still awaiting CLAW as a viable option, as time has gone on it became clearer to us that in the meantime we should start using the current Islandora.

One reason we’ve been reluctant to move to Islandora is because we’ve also been waiting for Fedora 5, which is the version of Fedora that will be based on the Fedora API specification. Fedora’s API aligns with our hopes of moving in the direction of linked data, and using common standards that allow for more flexibility in our application development in the future. We currently run a 3.x version of Fedora, which isn’t actively being supported by Fedora at this point. Based on timing of when Fedora 5 is released, we’ll end up skipping over Fedora 4 entirely, until we upgrade to CLAW in the future.

Steam boat inventory with maps, Nelson Family Juvenilia Collection

Our plan to start using Islandora, while still running an old version of Fedora, felt at first like we were making some kind of U-turn, as we hope in the long run to be off of deprecated software and using linked data more fully in our digital collections repository. As we’ve talked with our colleagues from other Islandora institutions, joined the Islandora Foundation as members, and watched the developments of our colleagues at Fedora institutions, it seems clear that this is just a bend in the road that we need to follow. We’ve learned a lot about the Islandora software and community in our explorations and planning thus far.  We hope to be better advocates for our colleagues in our work with Fedora as a result of our Islandora work, and we hope to align ourselves more closely with our neighbors so that we can start working together more in the future.

We will be installing and configuring Islandora over the next year, with the hopes of having at least a full copy of our current digital collections in place by summer 2019 for testing. We still have many questions about how we will use Islandora, such as whether or not we’ll use Islandora as the user interface. What we do know is that this feels like the right time to make this change, and it will allow us to continue to advocate for the needs of Amherst, and all liberal arts colleges, in the open source software communities of Fedora, and now Islandora. And best of all, we will grow our community of practice, our collaborators, and by aggregating, expand the reach and scope of what we are able to accomplish with our digital collections.

rikers island drawing
View of the East River or Sound taken from Riker’s Island with a distant view of the seat of Joshua Waddington Esq., Edward and Orra White Hitchcock Collection

 

Images in this post are from the Archives & Special Collections in Amherst College Digital Collections, all found by searching for “island”.

Este Pope is the Head of Digital Programs in the Amherst College Library. She can be contacted at epope at amherst.edu.

Digitizing Negative Collections – The College Photographers Records Collections

This month the Digital Programs Group began digitizing the College Photographers Records Collection. The collection includes more than 400,000 negatives taken by the official photographers of Amherst college from 1962-2005; A visual history of the college for the second half of the twentieth century.

Using negative collections housed in archives tends to be a challenge. Generally, negatives enter the archive housed in some sort of vessel—glass plates stacked in a cigar box, a disintegrating yellow envelope or an archival glassine sleeve. Each envelope may have a description and contain a couple frames of film or many rolls of film of various formats. The jumping off point for access may be date or description of the negatives. Once you think you might have found what you are looking for, a staff member needs to view the negatives on a light table in order to find something that might fit a specific purpose. Then comes the evaluation; is the image you want in focus, properly exposed, damaged by light leaks, scratched, or covered in dust? Before the advent of digital photography, a copy negative would be created to preserve the original and prints would be made in the darkroom. With the advent of digital photography scanners are now used instead of the darkroom.

A project of this scale is a massive undertaking, and rather then try to digitize the entire collection we are looking to digitize around 10%, or about 40 thousand images, in the next three years. Currently archive staff is prepping negatives for digitization by selecting, organizing, re-housing, and transcribing any pertinent information.

Fortunately we were given the funds to purchase a new digital imaging system. Manufactured by Phase One this new camera captures about ten times the detail as a cell phone. Up until now, the library had utilized Epson flat bed scanners. While they do a fairly good job at scanning negatives, they are very slow; capture time can be a couple of minutes per image. The Phase One system will enable us to photograph a negative in a fraction of a second at a quality that surpasses the quality of a flatbed scanner. When photographing tens of thousands of images the time saved by switching to a camera system quickly adds up.

Over the years I’ve been fortunate to work on several mass digitization projects of negative collections; Leslie Jones Negative Collection at the Boston Public Library, MotorBinder ( a book focusing on the history of road racing in Northern California), and a collection of glass plate negatives of the 1919 international Panama Pacific Exhibition held at the Bancroft Library at UC Berkeley. Between these three projects I worked with many forms of photographs; 11×14 glass plate negatives, autochomes (one of the first color negative process), 100-year-old negatives that looked brand new, and 30-year-old negatives that looked like they had been peeled off the floor of a darkroom.

Each project brings its own technical and workflow challenges; different cameras and scanners, varying levels of student staff training, and developing unique workflows. All the work allows us to—in the end—look at thousands of images from a variety of sources. I find the real excitement comes from what photography does best. We’ll call it describing and suggesting. ‘This is a picture of that’ ’That happened here and this is an image of it happening’ Most of the things and people in these archives are long gone but the images are moments that have happened that I get to experience through my job. I now feel as though I have a visual connection to the 1919 Boston molasses flood , and what it was like to race cars in the San Francisco Bay Area in the early 1960’s.

I’ve been working as the Digitization Coordinator for a little less than a year now, and have limited context for the images we are digitizing. We are now in the third week of the project and still working through some technical challenges, but I’ve already seen some interesting images though my firsthand knowledge about their contents are limited. The labels provide a bit of context. Other times, they add to the puzzle.

Other examples of folder descriptions.

Sit-in Westover – Bill Ward

Day of Concern for Blacks

ABC House

 What I find especially interesting are those digitized images without context;

 

Timothy Pinault is the Digitization Coordinator for the Frost Library at Amherst College. He can be contacted @ tpinault at amherst dot edu.

 

Bring your own viewer?

Lately I’ve been focusing on replacing/upgrading our zoomable image viewer in our digital repository.  The current version of the tool lacks a few features which folks have been asking for – one of which is rotation.  In an instance where you have a manuscript that has writing in two directions, being able to rotate the image is a highly desired feature.

An image of a manuscript showing text written in two directions

Having heard about this set of standards for image viewing, I started researching the International Image Interoperability Framework (IIIF).  I’ll share a little bit of my learning with you here.

Honestly, looking at IIIF made me start to dream.  We craft websites with our (limited) view of the world and our (limited) view of the data.  Users are subjected to the limitations of the tools we choose, for better or for worse.  And as time moves on, even the best website gets outdated and the once super cool tool is no longer as interesting, especially next to its shiny new, more feature rich, replacement(s).  Generally there’s no way of getting around that and to some degree, that’s just how it is.  But what if a user who is viewing images in your digital repository could bring their own viewer?  What if they could pull in separate image data sets from different places and compare them with a single tool of their choosing?

Granted the number of “tools of their choosing” is fairly limited at this point.  However, the more that IIIF takes off, the more options users will have.   IIIF is made up of four specifications – one specifying what an IIIF image server should do, one specifying a presentation API, one for a IIIF searching service, and one for authentication API (for those times when your data can’t be open access).

That’s a lot of specifications and for the sake of this post, I’m only going to talk about the IIIF Image API and IIIF Presentation API specs.  Simply put, the IIIF Image API defines how a IIIF server should serve images over the web – a IIIF image server handles all the image manipulations requested and is able to produced zoomed in and rotated images.   That in and of itself is not a new thing, but the fact that it follows a standard means you can replace one IIIF Image Server with another and you won’t have to change the client code.   As a developer, that’s a thing to be appreciated. 

Providing a IIIF Image server alone will allow you to plug in any image client that can interact with a IIIF Image Server.  A client like Open Sea Dragon. Chances are you’ve seen that around before and it’s a great javascript tool for working with high-resolution, zoomable images.  It happens to be able to speak IIIF. 

You can stop there with the IIIF Image server and client or you can add a tool that implements the IIIF Presentation API – the playing field really opens up then.  This API specification details how one would produce configuration documents for a digital resource.  A configuration document describes how to get the images associated with the resource, some descriptive and technical metadata about the images, and any other services (like maybe a search service) associated with the resource.  Tools that implement the IIIF Presentation API are what make it possible to grab information about data sets from different institutions and compare them with one tool.   I’ll explain by example: Mirador demo site.

Mirador is able to talk to IIIF Presentation API compliant servers and pull in configuration files for resources.  These files are known as ‘manifests’ and are formatted in JSON.  The beauty of Mirador is that you, the user, can pull in any image data set you choose, so long as the publisher of that data set has generated a manifest for it.

There are a few ways to pull in a new manifest in Mirador – one way to do it is to click on the “Change Layout” link in the upper right hand corner.  Add a few more boxes (say a 2×2 grid).  Then click on “Add Item”  – that will show you the list of manifest that the Mirador demo knows about.   If you’re learning how to develope manifests yourself, it’s very handy to pull down a few of these manifests to study them.

You’ll also see that these resources come from all different institutions.  To pull in a manifest file implies that the institution also has a publicly available IIIF image server somewhere ready to serve up images detailed in the manifest.

Within seconds a user can be comparing images from different institutions, all within one tool.

When a IIIF Image server and a IIIF Presentation server are supplied a user can then make the choice – do they use the presentation layer we provide on our website or do they want to grab a manifest and view the data in their own favorite IIIF viewer? 

In the Digital Programs group here at Amherst College, our long term goal is to provide a IIIF Image server as well as a service that implements the IIIF Presentation API.   While there are many IIIF Image servers available, it’s not clear to me (yet) how many IIIF Presentation API implementations there are and we may end up writing out own.   For now, we’ll start with a new client (Open Sea Dragon) and eventually integrate a IIIF Server and maybe someday even use Mirador.


Bethany Seeger is a software developer working in the Amherst College library, focusing mainly on the Amherst College Digital Repository.  She can be reached at bseeger@amherst.edu.

Repositories, repair, and system migrations

Innovation and disposability…

Technology innovation is a given in our fast-moving culture of social media and disposable devices, yet innovation isn’t all that drives the technology infrastructure underlying the systems we use everyday. In the library, we us many online resources driven by databases that organize, track, and deliver the content we need, when we need it. In some ways, a database is a lot like a library – books are on shelves, and we have a catalog that tells us where to find those books, and when someone comes looking for one we can help them find it.

toaster
https://en.wikipedia.org/wiki/Toaster#/media/File:Toaster.jpg

At Amherst College, we are in the midst of a long process of improving our database system that manages our digital collections. And while innovation is a central factor in our migration planning, another theme is emerging around the notion of repair. If you think about it, repair is a necessary function of the world. We repair our heating systems when they stop working, sometimes it is a small fix, sometimes it requires a completely new system. We also repair less and less as our culture seems to move in the direction of disposability – it is often easier to replace things like toaster ovens than to repair them.

poem written on part of envelope
Emily Dickinson Envelope Poem, Amherst College Archives & Special Collections

In the digital library world, we don’t have a lot of cheap, easily replaceable toasters. Most of what we are dealing with involves very fragile (yes!) digital objects that represent physical objects in our collections, like the envelopes that Emily Dickinson wrote poems on, or the first course catalogs in our college’s history. We can’t easily replace these digital objects and all the hours of work that goes into photographing and describing. We are reliant upon a stalwart digital system to keep things running smooth.

Digital preservation and digital repositories

We use the term digital preservation to point at what we hope to achieve, which is some kind of digital stasis of the objects we are storing and serving up online. Increasingly, the objects don’t have a physical surrogate, they are what we have labelled “born digital” and these are especially tenuous and fragile, to the point where we talk half-jokingly about printing things out just to have a backup physical copy. And it is our database systems, or digital repositories, that we entrust a good deal of our hopes for digital preservation. If we have a good system, we expect digital objects to persist over time without degradation.

fedora repository logo
Fedora is a robust, modular, open source repository system for the management and dissemination of digital content.

At Amherst, we use the Fedora repository to manage our digital collections. Fedora is, in the landscape of digital repositories, kind of a like a star quarterback, at least in my mind. Everyone knows about it, knows it does what you will expect it to, and maybe also, everyone wonders when it will retire, because it is getting a little old. Fedora is a perfect example to me also of the idea of innovation mixed with repair. There are many things about Fedora that work well, and help us to steer in the direction of digital preservation.

But Fedora needs some updates, modernization, and reinvention. Fortunately, the community of Fedora users has been working over the past few years to conduct these innovations/modernizations and tweaks to the underlying infrastructure. One of the beauties of Fedora is that it is an open source repository, and is maintained by a community of users who have a stake and an interest in seeing it sustained and continuing to flourish. This is where repair meets innovation in my mind – because Fedora is also not like a quarterback. I like to think of Fedora as more like a barn – something that can continue to serve a purpose, and be repurposed, while also leveraging the type of thing it is and how identifiable it is in our culture.

Repair and innovation

pencil drawing of house and barn
Sketch of House and Barn, Nelson, Elmer H., 1878-1930, Amherst College Archives & Special Collections

I was exposed to this idea of repair as a corollary to innovation by way of Bethany Nowviskie, the director of the Digital Library federation, who wrote about the work of Steven Jackson, a information science researcher at Cornell, in her 2014 talk “Digital Humanities in the Anthropocene.” She relates his discussion of the notion of repair to resilience and to establishing communities of care, both of which concepts are critical if we are to engage in digital preservation and stewarding digital content for the long term. Steven Jackson brings many ideas to his chapter, “Rethinking Repair,” with a central idea of repair being way to prevent or prolong decay, while also being a mode of reinvention or innovation. Applying this notion to the work of the Fedora community, it is clear to me that Fedora is encapsulating ideas of repair in the work of the Fedora specification, and implementation of new features that interact more with the broader web while aiming towards sound digital preservation. Fedora is kind of ‘old’ in terms of a technology, having been around for twenty years, but it is still reinventing itself and evolving, and with the specification it will likely continue to evolve.

The future of the digital repository is being developed, and we won’t know exactly how it will be implemented, or what repairs and innovations will be required to make it shine the way the Amherst College community requires. One of the ways I’m assured that we will embody repair and innovation is because of the community – between our team of developers and librarians working to ensure a sound system here at Amherst College, and the larger Fedora community that we are a part of. We think of technology often as a lonely and isolated aspect of our modern world, but for those of working the digital library systems at Amherst College, it indeed embodies a dynamic community of care, and a set of tools we care deeply about, because they preserve our culture, our history, and help us to create the future we hope for.  Barn-raisings were a common way to build a barn at one point in the history of the United States, and served as a way of leveraging all the skills of the community to help out a neighbor. I see the work we are involved in with Fedora as a kind of barn-raising, or a barn-renovating, and one that will help us out, but will help out countless other libraries and cultural heritage organizations preserve their treasures. The recent release of the Fedora API Specification is a testament to this effort to work together and make something even more people can use. To preserve things, it isn’t just the technology, it is the people doing the technology, that is going to give us a modicum of trust that things will survive in this digital age.

Este Pope is the Head of Digital Programs for the Frost Library at Amherst College. She can be contacted @ epope at amherst dot edu.