Digital Humanities

A Decade of the Digital Repository Service

Northeastern University Library’s institutional repository, the Digital Repository Service, is celebrating 10 years of caring for the university’s scholarly, archival, and administrative high-value materials. From day one, the mission of the DRS has been to provide a long-term, sustainable home for the born digital and digitized content being produced by members of the Northeastern community.

More than just a technical system, the DRS is a service provided by the library to help solve a common problem for faculty, staff, students, researchers, and project teams: where can I store the digital output from my work? The DRS allows these projects developed at Northeastern to be maintained and shared with a wider audience. In addition to maintaining the DRS system, services provided by DRS staff include running training sessions, answering questions, consulting, and depositing files for users.

Originally developed as a prototype in 2011, the system was created by a library team — three developers, the repository manager, a Northeastern co-op, and a library administrator — with the goal of constructing a completely realized system ready for production. The first version was ready to be used fully by the Northeastern community in June 2015.

The DRS was launched with some rough edges, which were slowly smoothed into the system users are familiar with today. We have received tremendous response from users about the usefulness of the system, as well as thoughtful and constructive feedback about how the system can be improved (e.g. faster page load times, better search functionality, and more control over files, among others).

The DRS homepage displayed on a laptop screen with a hand typing on the computer's keyboard
The DRS, as it appeared in 2015.

We have done our best to grow with the university community as its needs shift by increasing support for datasets, loading large batches of files on behalf of users and project teams, and tripling our original storage capacity, but there is always more to be done to meet the needs of our users.

The shape of the content stored in the DRS has shifted over the years, as well. Initially just for theses and dissertations, university photographs, and archival material, the DRS now fully supports various types of project materials for digital humanities research, datasets for researchers in various disciplines, oral histories, and many others.

Since its launch, DRS content has been viewed, downloaded, or streamed more than 1.1 million times, and we’ve had more than 13,000 members of the Northeastern community sign into the system. The DRS averages approximately 2,000 unique visitors and 4,000 views, downloads, and streams a day.

Screenshot of a DRS display of a research poster titled "Investigating and addressing the needs of research support staff"
The DRS provides a home for and access to research and projects by members of the Northeastern community.

The success of the system can be attributed to the combined efforts of staff in many library departments, including development and system administration from Library Technology Services and Digital Infrastructures; outreach and faculty support from Research and Instruction; data management support from Research Data Services; issue triage and metadata collaboration with Resource and Discovery Services; and continual support and advocacy from library administration. And, of course, Digital Production Services, the department primarily responsible for maintaining the system and supporting the service through digital production, metadata maintenance, and user support.

The DRS is not the first system of its kind supported by the library. It adopted its first repository system in the early 2000s, followed by IRis in 2007. The library’s commitment to maintaining the scholarly output of the university was formed during those early years, a commitment we have refined and strengthened over the more than 20 years of dedicated support for faculty, staff, and students working to help fulfill the university’s mission. It’s been a great pleasure to support the Northeastern community in this way, and we look forward to the next 10 years and beyond.

Celebrating more than 30 years of the Women Writers Project

On March 27, as part of a month-long celebration of Women’s History Month, the Women Writers Project hosted a screen of Always in Progress: Three Decades of the Women Writers Project, a documentary by John Melson.

Screenshot of a person with glasses speaking in front of a bookshelf. The person is identified as Julia Flanders, Director of the Women Writers Project & Professor of the Practice, Northeastern University
Julia Flanders, Director of the Women Writers Project, speaks in the Always in Progress documentary.

Work on this documentary began in 2018 as part of the WWP’s celebrations of the project’s 30th anniversary. This milestone marked an opportunity to reflect on the WWP’s decades of work bringing texts by pre-Victorian women writers out of the archive to make them accessible to a wide audience of teachers, students, and scholars. The documentary shares highlights from the WWP’s years at Brown University, where the project was founded in 1988, and Northeastern, where the project moved in 2013. We were delighted to have in the audience present and past members of the WWP community, including students, staff, and advisors—it was exciting to see familiar faces and remember the many important contributions people have made over the years.

The documentary outlines the WWP’s long history as a project focused on early women’s writing and text encoding, and includes insights from current and past staff and students about representing texts using the Text Encoding Initiative markup language and publishing them on the Women Writers Online digital interface. The film also follows WWP staff and students as they work on several initiatives, including the Women Writers Vector Toolkit exploratory interface; the Women Writers in Review collection of periodical reviews; the Women Writers: Intertextual Networks interactive bibliography; and the Women Writers in Context scholarly exhibit series. Several scholars and experts in the digital humanities, including Dean of the Library Dan Cohen, also speak about the impact of long-term projects like the WWP on digital scholarship and discuss what the project can teach us about the history of the digital humanities.

Three people sit in an office setting chatting
Elizabeth Adams, Julia Flanders, and Carole Mah working in the early days of the Women Writers Project.

The documentary was made possible with support from the Northeastern University Humanities Center, the NULab for Digital Humanities and Computational Social Science, and the Northeastern University Library. It was directed by John Melson, with camera and sound by Melson and Colleen Nugent. To learn more about the WWP, see the project’s Welcome page.

One Run: Resilience in the Wake of the 2013 Boston Marathon Bombing

At 2:49 p.m. on April 15, 2013, two homemade bombs were detonated near the finish line of the Boston Marathon, just over four hours after the start of the race. The aftermath of this disaster, on what should have been a joyful occasion, was devastating. Three spectators were killed, and 281 other people were injured. Many people in Boston and surrounding communities were affected and sought to find ways of healing from this trauma.

Among those seeking to make sense of this event were Northeastern English professors Dr. Ryan Cordell and Dr. Elizabeth Maddock Dillon. They noted the strong reactions in their students, including those not directly impacted by the bombing, and decided to collect public stories of the larger Boston community. They hired a team of graduate students to gather and organize contributions, with the goal of creating an online community archive reflecting on this event. Two graduate students from this original team, Dr. Jim McGrath and Dr. Alicia Peaker, later became co-directors of this project. Along the way, collaborations were established with the NPR radio station, WBUR, the Boston Globe, and the Boston Public Library. The goal of this collection, later entitled Our Marathon: The Boston Bombing Digital Archive, was to construct a public memory to foster a better sense of community in the wake of this tragedy.

The Our Marathon collection includes nearly 8,000 items, with materials ranging from letters to collages to oral histories and other first-person accounts collected by those who founded the project. This archive bears some resemblance to other projects that used crowdsourced materials in response to a public trauma, such as the September 11 Digital Archive (created in 2001) and the Hurricane Digital Memory Bank (created in 2005 following hurricanes Katrina and Rita). All three of these projects also focus on the places where traumatic events have occurred. There is a strong emphasis in this collection on showing the implications of this attack for the local community, although materials also include letters sent to people in Boston from students around the world.

In this past year I have become familiar with these materials while adding to and editing some of the metadata for these items in the DRS to clarify the copyright status, associated names and subjects of these materials, as well as the languages used in certain items, for researchers. In surveying this collection, I was particularly intrigued by how the marathon community dealt with this trauma. This attack created a lot of fear and uncertainty around future marathons. In fact, the London Marathon was run six days later, and security was greatly increased there because of what had happened in Boston. But many marathoners in Boston and across the country defiantly raced again, and two of these races – both called “One Run” – are documented in the Our Marathon collection.

Several people run over the yellow and blue finish line of the Boston Marathon.
Runners at “One Run” event in Boston (May 2013). Photo courtesy of MarathonFoto Photographrs.

The first of these races, the “One Run” Boston Marathon event, took place on May 25, 2013. The bombings kept about 5,700 runners from finishing the original race on April 15, and so “One Run” was seen as a way for these runners to complete the final mile of the race. The Facebook post about the event also said “all are welcome to run – nobody will be turned away. This is a free event open to everyone. No registration is required.” This event was thus meant to be inclusive and healing, but it also allowed marathoners to re-experience the outcome of their race.

A video of the opening ceremony for “One Run” is available through the Our Marathon collection. During this ceremony, the national anthem is sung by the children’s choir of the St. Ann Parish, the church to which Martin Richard—an 8-year-old boy who was killed by the bombing—belonged.

Four people stand on the side of a road in what looks like a desert holding a white banner reading "One Run Boston Relay" and displaying a blue map of the United States with a white trail from Los Angeles to Boston. There are signatures all over the sign. Three of the people are wearing blue t-shirts that say "One Run Boston."
Carrying the Banner at the #onerun for Boston. June 11, 2013

Numerous photographs, contributed to this archive by MarathonFoto, also display the joy of the participants and their families as they cross the finish line.

The second race highlighted in the Our Marathon collection occurred a month later. “One Run for Boston” was a non-stop running relay of 3,328 miles, starting in Los Angeles on June 7, 2013, and ending in Boston on June 30, 2013. This race, organized by Danny Bent, Kate Treleaven and Jamie Hay, was a fundraiser, collecting $550,000 for the victims of the bombing through Boston’s One Fund.

The “One Run for Boston” race had an emotional finish. John Odom was badly injured while watching his daughter run on April 15. On June 30, his daughter, Nichole Reis, handed the baton to him in his wheelchair and pushed him over the finish line.

A man sitting in a wheelchair wearing a yellow raincoat over a Boston Strong shirt is smiling and surrounded by cheering runners wearing One Run Boston shirts
John Odom and “Miles” the Baton. July 1, 2013. Photo courtesy of Kristi Girdharry

Both of the “One Run” races served first and foremost as an acknowledgement of the suffering caused by the marathon bombing. They also served as a unifying force, made clear by the obvious camaraderie displayed in the photos here. But finally, these races allowed marathoners a kind of therapeutic experience – they took hold of a situation in which they were vulnerable and transformed it into an active reclamation.

Library Digital Scholarship Group and NULab receive $500,000 NEH grant

The Northeastern University Library’s Digital Scholarship Group and the NULab for Texts, Maps, and Networks received a $500,000 grant from the National Endowment for the Humanities as part of the NEH’s American Rescue Plan program.

The American Rescue Plan aims to provide funding to organizations conducting humanities projects that were adversely affected by the coronavirus pandemic. The grant awarded to the DSG and NULab is specifically focused on supporting humanities organizations.

This grant will help fund a series of digital projects currently underway through the DSG and NULab, but that were delayed or postponed due to the COVID-19 pandemic. It will support efforts to conduct collaborative research, digitize and process archival materials, create metadata, increase web accessibility, and more, while creating many graduate and undergraduate student research positions to conduct this work.

The projects that will benefit from this grant all involve collaborative engagement with communities outside of Northeastern, with many of them focused on resources related to underrepresented groups and social justice efforts. These include:

The grant also includes funding for additional projects organized through the NULab.

Julia Flanders, the director of the Digital Scholarship Group, is excited to get started: “We are honored and energized by this award. It creates wonderful research opportunities for students and will help the entire digital humanities ecology at Northeastern.”

Using Functional Specification as a Tool for Project Communication

Digital projects involve complex collaborative networks, and they are at their strongest when they draw on the many different kinds of expertise that their participants have to share. At the same time, it can be challenging to draw together all of those different contributions of information, requirements, needs, and ideas in a single place. How do we bridge the differences in technical, cultural, and disciplinary knowledge within these teams, and create shared documentation that can evolve effectively during the project’s full life cycle?

In the past few months, the Digital Scholarship Group has been experimenting with adapting the functional specification—a writing genre that originated in software application and system development—to serve as a tool for project communication. As part of the Northeastern University Library’s recent LibCon event (a departmental sharing of projects and ideas among colleagues), members of the DSG presented a panel session that explored various aspects of this work from different perspectives. This post draws on those presentations to give an overview of the features, challenges, and possibilities of functional specifications in a digital humanities applied research group.

The genre of the “functional specification” in its original context covers several different types of terrain. As Senior DSG Developer Rob Chavez and Associate Director for Systems Patrick Murray-John described it, it captures important contextual information about the purpose and objectives of the project, the features and functions of the tool being developed (from the perspective of specific users and their needs), and the actors and entities (e.g. users, roles, and data) that are involved.

Functional specification definition flow chart

There are numerous benefits from gathering this level of detailed information at the inception of a project. At the level of practical planning, it provides concrete information that in turn makes it easier to develop design specifications, technical specifications, development plans, and tests to determine when a project has been successfully completed: if the functional specification describes a search function that returns results ranked by relevance, we know we’re not done until that is working. Perhaps equally important for the DSG, the process of creating a functional specification fosters participatory collaboration among the project’s constituents and prompts deep thinking about what the project is really seeking to accomplish, and helps the project agree on what it really needs before putting effort into building a working version. It also pulls together information that may be helpful for other purposes (such as grant-writing or publicity).

The functional specification also sits within a wider network of tools. Patrick Murray-John showed how the written document provides detail on specific features (such as searching, or viewing a map, or uploading a new file) which then gets translated into specific programming or design tasks which are stored in project management tools such as an issue tracker. While the functional specification provides a road map, the issue tracker provides a view of progress being made and enables the daily coordination of tasks and effort that are so necessary within a collaborative team. When a given feature is prototyped and eventually completed, the functional specification can then be used again as a confirmation that the real needs of the project have been met, and it can also serve as a place to record unfinished work that may have been out of scope—which in turn might feed into a future phase of the project’s development, or support future fund-raising efforts.

Functional specifications, in their original context in the software development industry, typically operate within a fairly uniform technical team with a lot of shared skills and knowledge. As a result, the common practices and familiar features of this genre mostly focus on its practical and technical aspects: a data inventory, user stories, use cases, preconditions, the logical flow of operations from step to step within a given functional context. For the DSG, experimentation with functional specifications has focused on building out the genre in a few different directions. First, as DSG Director Julia Flanders described through the example of the Digital Archive of American Indian Languages Preservation and Perseverance (DAILP) project, the functional specification can function more effectively as a bridge between different parts of the project team if it includes deeper contextual information: not only user stories, but also detailed information about the motivations and investments of specific user communities, which in turn help the team understand how the project’s data is shaped and why. In the case of the DAILP, understanding the differing needs of language learners, academic researchers, and language experts within the Cherokee tribes is crucial to technical design and decision-making at every level. As the DSG develops templates and guidance for project teams in writing functional specifications, we are putting greater emphasis on those topics and urging projects to use the functional specification as a prompt for early conversation. The DSG has also been experimenting with involving project teams more fully with creating the functional specification itself, rather than treating it as a purely technical genre. DSG Associate Director Amanda Rust discussed her work with the project team for the Civil Rights and Restorative Justice Project (CRRJ) to develop detailed accounts of the project’s working processes and research, a process that has empowered the group to imagine the functional possibilities more concretely, and intensified their sense of involvement and investment in the development process.

As Senior Digital Library Developer David Cliff pointed out in his contribution to the panel, one of the important roles of the functional specification is to bring clarity and consensus about project scope, and to avoid miscommunication or the dreaded “scope creep” that can occur when functional requirements aren’t clearly laid out at the outset. At the same time, as he and others noted, research projects like these are by their nature prone to change as they explore new possibilities. And similarly the DSG, as an applied research group, is always venturing into unfamiliar territory where precise time estimates are difficult.

10-panel description of the design process.

The functional specification must therefore tread carefully between attempting to pin things down too closely or prematurely, on the one hand, and leaving things so underspecified that a project is never done, on the other. Iteration plays an important role here: sometimes a project team needs to see a prototype of a search results display before they can imagine the full set of facets and options that will make it truly useful. To be most useful, the functional specification needs to be able to establish achievable interim goals while also keeping track of the project’s largest vision. It is thus always a living and evolving document, and as one audience member pointed out in the panel discussion, it needs to make that evolution possible.

The Digital Scholarship Group has thus far developed three draft functional specifications and a draft template which also documents our emerging practices in this area. In the coming year, there are several areas where further research and experimentation will be needed. First, we want to create a fuller template and more detailed documentation of how and when different parts of the functional specification are most useful, situationally. Second, we want to continue to experiment with involving project teams in the authoring process. Third, we need to develop effective means for translating specific functions from the specification into concrete development tasks (to be tracked via GitHub). And finally, we need to tackle the question of versioning, and create transparent mechanisms for allowing the specification to evolve without losing its documentary value or creating confusion.