The Research division works to create open-source tools and software to assist historians in researching and presenting their own findings, as well as engaging with the scholarship of others. During our four-week rotation in this division, we learned about and experimented with PressForward, primarily through working with DH Now, and RRCNHM’s newest tool, Tropy.

First, we took a closer look at Digital Humanities Now, a website that acts as a distribution platform for digital humanities based scholarly work in various formats from blog posts to white papers, as well as conference and job announcements from the field. Coming into the Research Division, we were somewhat familiar with DH Now as we had been using it all semester to stay current on what was happening in the DH field. However, I was less clear on the actual underpinning of how DH Now worked. I knew that multiple feeds were brought into the WordPress site and from there, DH Now staff and GRAs curated those feeds, choosing what to publish on the website.

In fact, as we learned, DH Now is powered by PressForward, a WordPress plugin created by the Research Division at RRCHNM that allows one to easily aggregate and share content from the web. DH Now is only one of multiple websites that use the plugin to aggregate and share scholarly web content.

We then were tasked with using our new knowledge of PressForward and DH Now to serve as the Editors-in-Chief for a week, reading through nominated content, choosing what would be the best material to publish, and even selecting the Editor’s Choice piece. Through this hands-on experience, we were able to get a sense of how DH Now worked from the editors’ perspective, instead of from more of a consumer’s view.

Finally, we worked with Laura Crossley, one of the Editors-in-Chief of DH Now, to install and use the PressForward plugin on our own scholarly websites. Laura uses PressForward, much like DH Now, to aggregate DH content on her own blog and share her own comments about what is happening in the field. After considering several options, I decided to use PressForward on my personal website in a less extensive, but still quite useful way. Up until this semester, my personal website has contained blog post updates about my coursework and progress through the Graduate Certificate in Digital Public Humanities. Now I have also begun publishing these posts on the RRCHNM Fellows Blog. It is likely that in the near future, I will also publish blog posts or other scholarly web content in places other than my personal website. Therefore, I am excited to be using PressForward on my own website to bring together a collection of my work in one location. This will allow me to do a better job of keeping track of my own work, while also offering a place for others to examine the various ways I have engaged in the scholarly conversation.

Secondly, we spent time experimenting with and learning about Tropy, the newest research tool built by RRCHNM. Tropy had been released just prior to the beginning of our rotation in the Research Division, so we were some of the first people outside of the Tropy team to really get to see what Tropy can do. Like many of the projects carried out in the Research Division that try to solve a current problem troubling historians, Tropy gives a solution for what to do with the thousands of pictures that scholars take during trips to the archives. We were challenged to experiment with Tropy by reading the documentation, downloading the software, importing some of our own research materials and finally, creating a metadata template for that material.

As a historian of Early America, dealing mostly with handwritten documents, I found that Tropy is extremely useful. It allows you to easily import images and group them into documents, which is helpful if you have a multi-page document and a separate image for each page. Next, there is special split screen view (document on top, space to type underneath), which allows you to transcribe the documents right in Tropy. Before Tropy, I had been keeping my transcriptions (as Word documents) and image files (in a photo editor) separately, but Tropy allows you to save them together, which is really helpful. Tropy also has a search feature, so that you can find every occurrence of a certain person or place’s name in the documents you have transcribed, instead of manually reading through text files to find what you are looking for.

A big part of Tropy, and the second part of our task, was to deal with the metadata associated with our documents. Tropy comes preloaded with a basic template and a few more specific ones (ex. for correspondence or photos). The templates differ in the metadata that they ask you to add for each item. For example, the generic one asks for information like title, date, item type, source, holding collection, etc. while the correspondence template asks for the title, author, recipient, date, location, archive it is from, etc. The metadata properties have to come from an established vocabulary (ex. Dublin Core) but users can import other vocabularies available through Linked Open Vocabularies (LOV). Users can also download templates that others have made or upload templates they had made.

For my experiment in creating a Tropy template, I used material from a previous research project about a rape case in Fairfax County, Virginia during the Civil War. While my research had been supplemented by government and prison records held at the Library of Virginia and newspaper records at the Fairfax County Library, the core of my research centered around the case file for the trial, which is held at the Fairfax Circuit Court Historic Records Center, in Fairfax, VA.

Originally, I thought that I might make a template that could be used for all material at the Historic Records Center, as that would be helpful to a larger group of people if uploaded and shared. My thinking was that I could add the Historical Records Center as the Default Value for the Source property, and that way, users would not have to type that in for every item. But as I tried to create a generic template that would encapsulate all the types of sources held at the Historic Records Center (wills, deed books, birth, death and marriage records, road petitions, as well as court documents), my template ended up being no different than the “Tropy Generic” template that comes with the software.

So I decided to take a different approach and focus on making a template just for the Term Papers at the Historic Records Center. This class of documents provides the legal  judgments for each case, and includes any court papers filed during the term of court. As I knew from my research, item properties like “creator” were less important than determining things like the plaintiff, defendant, and case type (murder, debt, trespass, assault, etc.). After a long search through the properties and vocabularies that came with Tropy, I found that I could use the Dublin Core property “Subject” to stand in for the case type, but that there were no good properties already in Tropy to describe the Plaintiff and Defendant. Therefore, I used Linked Open Vocabularies to find a vocabulary through the Library of Congress (MARC Code List for Relators) that included these two properties. Next, I downloaded the vocabulary and imported it into Tropy, where I could add the two properties to my template. Here is a sample of my template:

Overall, I enjoyed my time in the Research Division. It was really interesting to see how the team in this division had identified two problems common to the historical profession–namely, how to get more publicity/recognition for scholarly grey material and how to organize images of documents from archival research–and how they worked to create usable solutions to these problems. I also appreciated the chance to see how these tools could be incorporated into my own scholarly work and blog.

In my research, I tend to focus on structures and institutions and their real-life implications for everyday people. In my everyday digital life, I have just come to a place where I am more comfortable with examining the structure of digital tools. This was my starting point for my rotation in the Research Division. At RRCHNM, the Research Division creates open-source tools to promote both individual historical research and the development of collaborative digital communities.

We began the rotation with an overview of PressForward, a software plug-in which allows users to aggregate and share digital content using WordPress. Once installing the plug-in, content can be collected via both a feed reader and bookmarklet. Users can discuss, nominate and share items (including an attribution link and metadata) within WordPress. When I learned that you can also keep track of notes and discussions, I wished I had known about PressForward when I was teaching; it would have been great to have this tool to allow students to review and discuss media related to our curriculum. However, PressForward is more than a cool plug-in; it is a tool by which scholarship outside of the typical journal article or dissertation can be widely distributed. Digital Humanities Now (DH Now) is an example of how PressForward is put into practice.

DH Now is an experimental, edited publication that highlights scholarship in the digital humanities that drives the field forward. Additional items of interest, such as jobs, CFPs, conferences, funding announcements, reports and other resources are also posted–again, the point here is encourage scholars to share via the open web, and to amplify work and resources that might not get the attention they deserve. Potential content for DH Now is aggregated in multiple ways, whether its via RSS from a list of subscribed feeds, Twitter threads, or other sources. The content is reviewed, nominated, and discussed  in WordPress using PressForward by volunteer Editors-at-Large. Rotating Editors-in-Chief (faculty and graduate students here at the Center) select content for publication. Acting as Editor-in-Chief gives graduate students the opportunity to examine both content and practice in the digital humanities; it also provides us with experience in crowd-sourcing a DH project.

As a DH Fellow, I’ve been a volunteer Editor-at-Large all semester; that practice combined with a new and deeper understanding of PressForward prepared us for our first task: serving as Co-Editors-in-Chief. Together, we reviewed all of the nominated content (which came by way of the feeds as well as from Bookmarklet), discussed the pros and cons of each piece, and decided on what we’d publish on DH Now. Our Editor’s Choice piece was the white paper “Digital History and Argument,” a product of the Arguing with Digital History Workshop  held here at Mason in September. We also published announcements for conferences and Zotero workshops, two job postings, and new grant guidelines for the DH Advancement Grant from the NEH.

I also spent some time working with Tropy, a newly released tool for organizing research photographs. Users can organize and annotate their photos, as well as export them to share and collaborate with others. I downloaded Tropy to my laptop and used a folder of images from my M.A. research (which may become part of my dissertation) to experiment with it. I was able to combine images (photographs of multiple-page documents) to create consolidated items that were easier to view. Tropy also allowed me to easily add metadata to my photos, such as archive and collection information. Once we had some experience with the software, we were tasked with creating metadata templates. I designed several templates using the following questions as guides:

With the photos I already have, how might have wanted to organize them differently when I was in the archive last year? For the photos I had, I created a template for that archive, with fields for Collection, Box, Folder, and Subject. Box and Subject were the most important fields for that template, as I was examining multiple events, each with extensive incoming and outgoing correspondence.

What other repositories could I access as I develop my dissertation topic? This question led me to some quick research on a nagging question I’ve had for a few weeks…and behold, I got an unexpected answer that will help me expand my focus for my dissertation! I located three additional repositories that could be helpful in the near future.

If I have access to, say, a collection finding aid, could I develop specific templates for these different repositories? One of the repositories I located had a finding aid (albeit not as detailed as that of the other archive I visited last fall), and I was able to use that to help me develop a template; for the other two repositories, I created a template that was a combination of the first two. In general, creating the templates were easy (and in the instance of furthering my dissertation topic, extremely helpful!)

I appreciated having the opportunity to work in the Research Division, to experiment with tools that I might have previously overlooked, and to examine ways in which these tools might be refined to serve the needs to even broader audiences.

The Public Projects Division creates tools, projects and collections that encourage greater interaction with history among a popular audience. Some of the division’s projects are geared directly for public engagement while other tools help public history professionals more easily create collections, exhibits and projects of their own. During our four-week rotation in this division, we worked primarily on two projects, Omeka S and Mapping Early American Elections.

One of the most well-known and in-demand tools that RRCHNM has created, Omeka, comes out of the Public Projects Division. Omeka was released in 2008 as a web content publishing platform that would allow for the assembly, management, and exhibition of digital collections. Omeka S, the Public Project’s newest addition, builds on the popularity of Omeka Classic. Omeka S allows users to create and manage multiple Omeka sites on a single install. It also boasts new modules (plugins) for mapping and importing collections from other systems. Additionally, it allows users to share resources and collections among their multiple sites, and assign distinct privileges to different levels of users.

When we began our work with Omeka S, it was in its final phase of testing, but as of yesterday, Omeka S: 1.0 has officially been released. To start out, we worked with Megan Brett, the Omeka End User Outreach and Testing Coordinator. She taught us how to work with with GitHub and secure shell (SSH) via the command line to install themes and plugins on an Omeka install. Then we worked to simultaneously review the existing Omeka S documentation while testing the instructions on the dev site. We were asked to proofread, not only for spelling and grammar errors, but more importantly, for readability and usability. Did the directions make sense? Were there enough screenshots to help the user follow along with the text? Were the screenshots current? Did they display what a user would really see on his or her screen? Did the dev site respond in the ways that the documentation suggested that it should?

This process of reading and testing gave me firsthand experience with using Omeka S and provided me a more profound sense of the tool’s capabilities. It has enabled me to confidently describe Omeka S to others and explain how it differs from Omeka Classic. Finally, it has encouraged me to explore how I can use the new features of Omeka S in my own work.

During the second half of our rotation, we worked on the Mapping Early American Elections projects. As an Early Americanist, I was excited to work on a project in my favorite era. Although I normally focus on women, gender and social history in this period, looking at the early elections was really fascinating. At the time we (briefly) joined the project, the project team had already created a data set based on the information collected in A New Nation Votes (NNV). They were in the process of creating maps from that data set to represent each Congress in each state in order to help visualize the votes based on political parties.

In addition, they were adding brief interpretive text to each map to explain how each state’s election system worked and to call attention to any interesting aspects of the elections or trends from the previous election. To get a taste of this work, we were asked to write the interpretive text for all the states during the first three Congressional elections. Writing this text required us to look at each visualization (map), compare it to the chart devised from the data set, compare it to the data tables, footnotes and research notes provided by NNV, and then complete additional research for some of the more complicated elections. After we finished writing our interpretive text, Dr. Lincoln Mullen taught us how to use markdown and GitHub to add some of our text to the dev site for the project.

As a student of history, I really enjoyed the historical inquiry and analysis associated with this assignment, as well as the larger questions that the work forced us to discuss and try to answer. First of all, it reminded me how much I like the investigative and interpretive work of history–trying to sort through many different pieces of evidence in order to form one’s best (informed) guess or interpretation of what happened in the past. The more I found out about each election, the more digging I wanted to do.

Secondly, the work forced me to ask bigger questions like, what does it mean to be elected? In our original instructions, we were asked to mention in the text how many candidates from each political party were elected. While this at first sounded straightforward, we soon found out that it proved more difficult. For example, what about elections where one candidate received the most votes, but then the election was contested, votes were later ruled invalid, and the results were officially modified? What if a candidate received the most votes but died before he could take office or he declined to serve? Is there a difference between who was elected and who served in Congress? These and similar questions were discussed during the project meetings before settling on a more precise definition for the project.

Most of all, this project showed how me how digital history projects can make an argument and contribute to the historiographical conversation. Dr. Rosemarie Zagarri, the Lead Historian on the project, writes in the project’s blog in a post called “What Did Democracy Look Like? Voting in Early America” that “Early American elections subvert conventional notions that portray the development of early American democracy as an orderly or systematic affair.” Doing the research required to write the interpretive text really drove home this argument. Early American elections were, in fact, really messy. After the Constitution was ratified, elections didn’t just automatically happen in an organized and efficient manner that was consistent from state to state. As Zagarri asserts, it was an era of experimentation.

By looking at the voting practices and results for several different states during the same election, it was easy to see how the election systems varied state by state. For example in the First Congress, Delaware’s election law required voters in each of the state’s three counties to submit names of two persons they wished to elect. Of these two persons, one was required to be an inhabitant of the voter’s own county and the other needed to be from a different country. The person who received the most votes overall (at-large) would win the election. In the First Congressional election in New York, on the other hand, the state was divided into six districts and voters in each district elected one candidate to represent their own district.

The experimentation of the era, even within an individual state, was also evident by looking at change over time in a single state during the first three Congresses. A great example of this is Pennsylvania. For the First Congress, Pennsylvania held an at-large election where voters were allowed to vote for eight different candidates who could reside anywhere in the state. For the Second Congress, Pennsylvania created eight districts, and only allowed voters to elect one candidate who had to reside within their own district. For the Third Congress, Pennsylvania’s number of congressional seats increased from eight to thirteen (following the results of the 1790 Census) and consequently, the state discontinued its use of the district system, and instead switched back to an at-large system like they had used for the first congressional election. Examples like these provide strong evidence that supports the project’s historiographical argument.

Overall, I enjoyed the mix of technical and more traditional (research and analysis) aspects of working in the Public Projects Division. Even though I am leaving this division, it will be interesting to track both of these projects as they progress; I will be curious to see how users respond to Omeka S in its first few weeks post-launch, and to discover what findings come out of the Mapping Early American Elections project.

As a public history student at University of Maryland Baltimore County, I was part of the discussions that led to the creation of the Preserve the Baltimore Uprising 2015 Archive Project. Over the last two years, I have been interested in the ways public history projects–particularly community archives of contemporary events–are created by way of digital tools. As such, I was eager to begin my rotation in the Public Projects division.

The division works to develop digital tools, collections, and exhibits that facilitate public participation in history. Popular tools for online exhibitions and community transcription such as Omeka and Scripto are developed and maintained in the division. Several digital community archive projects are also housed in the division, such as the September 11 Digital Archive, a Digital Memory Bank commemorating Hurricanes Katrina and Rita, and the Bracero History Archive.

My first task was familiarizing myself with GitHub, a version control repository used primarily for code. Next, I worked through Omeka S as its version 1.0 release drew near. To clarify, Omeka S is different from Omeka Classic: it has a different code base, and gives individuals and organizations the ability to create multiple sites from a single install with shared resources; these resources can be shared as linked open data. I reviewed  documentation (which also introduced me to Markdown via MkDocs), and tested the tool by completing a variety of tasks.

The remaining time in Public Projects was focused on working on Mapping Early American Elections, a project which produces interactive maps and visualizations of elections from 1787 to 1825. I reviewed the election maps, visualizations, and election data from New Nation Votes to draft explanatory paragraphs for state elections for the first three Congresses (1788-1792). My historical research is firmly situated in the late nineteenth century, yet I thoroughly enjoyed examining eighteenth century elections, tracking electoral trends. The last day of my rotation, I was able to utilize GitHub and Markdown to pull my paragraphs into the dev site.

While my introductory rotation is over, I am looking forward to returning to the division next semester and further developing my skills as a digital public historian.