Home > How We Did It

How We Did It

Dr. David Eastman, Associate Professor of Religion at Ohio Wesleyan University had been thinking for a few years about ways to visualize evidence of early Christian martyrdom, but it wasn’t until attending an introductory workshop on digital scholarship offered by the Ohio Wesleyan University Libraries, and led by Dr. Jacob Heil, the Mellon Digital Scholar for the Five Colleges of Ohio, that he began to think it might be possible to build a resource like this. It was this workshop in which Dr. Eastman learned about a three-year grant awarded by The Andrew W. Mellon Foundation to the Five Colleges of Ohio to strengthen the digital capabilities of the libraries and embed the use of digital scholarship practices into the liberal arts curriculum.

A discussion followed and ultimately turned into a proposal that was met with enthusiasm and approval by the Ohio Wesleyan University Mellon Committee charged with reviewing and approving faculty proposals for digital scholarship initiatives at OWU. The project was approved in the 2014 Fall semester.

Finalizing the Proposal

Following a process established for projects developing under the auspices of the Ohio Five’s Digital Scholarship initiative, Mellon Scholar Dr. Jacob Heil formed a project committee composed of librarians Ben Daigle and Emily Gattozzi and educational technologist David Soliday to discuss the idea and provide some guidance to Dr. Eastman on writing a compelling proposal.

During this process, the group began to share some examples of comparable digital humanities projects including HistoryPin, Literary New Orleans, Atlas of Early Printing, and Ancient Jewish Diaspora among others.

We also began sharing ideas for potential tools or platforms that we felt could be candidates for the project’s underlying website. Some early ideas included CartoDB, StoryMapJS, Kartograph, and Leaflet.

Based on a recommendation from one of Dr. Eastman’s colleagues, we began to look more seriously at Omeka as the underlying repository for the site’s content and Neatline to provide the site’s main map-based exhibit.

Assembling the Team

The initial team consisted of the following participants:

Mapping the Martyrs project team members Dr. David Eastman, Makenna Huff, and Ben Daigle in a project meeting

During early discussions about the vision for the project, we recognized that we needed a student assistant on the project to help develop a website and to help train the students in Dr. Eastman’s course, Martyrdom and Persecution in Early Christianity, on using Omeka to contribute their writing and research to the website.

Librarian Ben Daigle took the first stab at developing a job description for the student assistant position. The team briefly debated the qualifications for this position. Did we need a student with strong technical and web design skills who could follow directions, or did we need a student who had experience with basic research in the field of early Christianity who may also happen to have some basic web design experience? Ultimately, we agreed on the latter, believing that a student versed in the vocabulary of the field would be more likely to engage with the project and be better suited to provide technical guidance to classmates studying the material.

We began advertising for a Digital Scholarship Student Assistant. The official position advertisement was posted online and across the Ohio Wesleyan University campus during finals week at the end of the fall semester in hopes that we'd find someone who could start right away upon returning from the winter break. Given the timing of this first push, though, we didn’t receive any applicants.

We distributed another round of advertisements across campus at the start of the spring semester, and we received a few promising applications. One of the applicants was a student enrolled in Dr. Eastman’s honors course on Christian martyrdom. She also happened to be a double major in mathematics and religion with coursework in several of Dr. Eastman’s early Christian studies courses.

After a brief interview with Dr. Eastman and librarian Ben Daigle, Ohio Wesleyan University senior Makenna Huff joined the team and got started right away familiarizing herself with the Omeka platform we selected for this project. 

Learning & Experimentation

Early sketches of the Neatline map exhibit for the Mapping the Martyrs project.

Installation

We assembled a small team of four during the 2014 Fall semester to test the process of getting a basic Omeka site up and running.

Our first step was to spin up a basic Omeka sandbox installation to test the installation process. We downloaded the Omeka software (version 2.2 at the time) and installed it on a server hosted by Bluehost, a company with which we have other sites hosted for the Five Colleges of Ohio. We found it quite easy to get the basic site up and running simply by following the directions on the Omeka website.

 

Getting Familiar with Omeka

When our student assistant Makenna Huff joined the team in the 2015 Spring semester, we began looking more carefully at Omeka and figuring out how the content of our site would be structured, how it should look, and how it should function.

Librarian Ben Daigle supervised Makenna’s technical work on the project. Each worked independently, communicating through a shared Basecamp site, but they also met twice a week for one hour to share progress and discuss questions as they arose.

 

Defining Items in Omeka

One of the early conversations critical to the project was about how we were going to define an “item” in the site. Omeka has several units of organization, but the primary unit is the item. Items are composed of metadata elements (fields such as title, contributor, subject, etc.), they can be organized into collections, and they can presented in exhibits.

We struggled initially to define exactly what items we were going to be exhibiting because unlike traditional digital projects that take a defined collection of items and turn them into digital objects, we felt as though we were working in reverse, building a platform to house items that didn’t yet exist.

After discussions with Dr. Eastman, Ben Daigle and Makenna Huff, the team agreed that the items we were describing were instances of persecution. Out of the box, Omeka offers several default item types including text, still image, dataset, but strangely enough, it does not include an item type for instances of persecution. We created a new item type in Omeka called Instance of Persecution and then turned our attention to the metadata we wanted to capture for each of those instances. We thought carefully about this because we wanted to design this item in a way that would facilitate users of the site who may later want to make comparisons between these instances and discover connections between them.

Omeka includes a default set of Dublin Core metadata elements, but it also offers the ability to create custom elements. We convened another meeting during the first half of the Spring 2015 semester in which we discussed exactly what custom elements we wanted to capture for each instance.

The set of metadata elements we ultimately agreed upon were:

Dublin Core Metadata Elements:

Custom Item Metadata Elements

 

Exhibiting Items on a Map

Once we had a clear picture of what our items were going to be and how they were going to be described, we wanted to understand how they would interact with a map exhibit.

We installed the Neatline plugin, as well as the NeatlineWaypoints and NeatlineSIMILE sub-plugins and began experimenting. Our student assistant Makenna created a small set of fifteen test items in Omeka and populated them with test data so that we could import them into a Neatline exhibit and see how they would appear on the map. We continued working with these same fifteen test records through the entire project up until the point where the students in Dr. Eastman’s class were prepared to contribute their own original items.

One very important consideration in our project was how to map our entries onto geography of the ancient Greco-Roman world. We assumed, based on everything that we had read and learned about Neatline, that we would need to implement GeoServer to provide specialized historical map layers in our exhibit. One of our early experiments involved georectifying an historical map of Palestine using ArcGIS and following a three-part tutorial written by David McClure. We believed we would be able to overlay that map onto the default Stamen Watercolor base layer we were using in our Neatline exhibit at the time. This approach would have required us to georectify many historical maps to cover the area this project examines.

Dr. Eastman turned us onto the Pelagios Project, an effort to create a map of ancient places stored within the Pleiades linked open dataset. Unlike the maps we had been attempting to work with, which were high-resolution jpegs we planned to place over the existing base layer, the Pelagios map is a set of individual map tiles. It was initially unclear to us how we would go about incorporating this series of tiled images into our exhibit. However, after studying the tileset and some documentation on implementation details, we realized that what we needed was not individual georectified maps placed on top of a contemporary base layer. We needed an entirely new base layer.

Based on some helpful assistance from Wayne Graham at the University of Virgina’s Scholar’s Lab, we were able to easily add the Pelagios tileset as a brand new base layer to our exhibit. In our theme’s directory, we created a new folder called neatline/layers. Inside the layers directory, we added a JSON file called pelagios.json with the following contents: 

{
 "Pelagios": [
  {
   "title": "Pelagios Digital Map of the Roman Empire",
   "id": "Pelagios",
   "type": "XYZ",
   "properties": {
    "urls": [
     "http://pelagios.dme.ait.ac.at/tilesets/imperium/${z}/${x}/${y}.png"
    ]
   }
  }
 ]
}

Then, on the Exhibit Settings page of our Neatline exhibit, the new Pelagios layer appeared, and we set this new layer as our default base.

 

Designing Workflows for Contributors

While getting familiar with Omeka, we started thinking about how we were going to arrange for a group of students, along with Dr. Eastman, to contribute directly to the site. We identified a few workflows, or use cases, that we felt the site should support. For example:

We first looked at the student workflow and questioned how we would grant students access to the Omeka site so that they could post their entries. Would we have to create accounts for each one of them? What role should we give them? Would we have to revoke their access or delete their accounts at the end of the semester? These are the types of questions we were asking.

Omeka offers a plugin called Contribution. The Contribution plugin provides a simple web form that allows users of the site to contribute content without having to access the backend Omeka Administration interface. We were very intrigued by this module, and it seemed to be a perfect solution to our problem of having to manage dozens of accounts and worrying about students inadvertently making unwanted changes to the administrative side of things.

We installed the Contribution plugin and began testing it. Using the plugin, it is possible to allow anonymous contributions from the public. We didn’t want to allow just anyone to post to our site so we knew we would have to include an authentication page and a way for students to sign up for an account. The Guest User plugin provided the means for users to sign up for accounts. During testing, though, we realized that new account registrations would need approval from an administrator, and we were trying to minimize the amount of administrative work Dr. Eastman would have to perform in the system, not to mention that we would still be dealing with dozens of accounts which at some point would need to be managed by someone.

We also experienced quite a bit of trouble customizing the contribution form to include all metadata fields we had included in our Instance of Persecution item type.

Ultimately, we decided to abandon the Contribution plugin and look for an alternative method of providing access to student contributors. The approach we decided on was to create a single user account called spring15 and assign this account the “Contributor” role. Our student assistant Makenna developed a guide to the metadata elements the students would be using to describe their martyrs and distributed it several weeks ahead of time so that they could all become familiar with what they would be asked to contribute. She also developed documentation to help guide students through the process of logging into Omeka and adding a new item.

Initially, we questioned how we were going to get students to plot their entries onto a map. Would they have to know the GPS coordinates of their ancient city? Would they need access to the Neatline exhibit to draw points, or could they remain only in Omeka?

As it turned out, we were unable to get coverage data to import into Neatline when simply keying in the coded geometry into the Dublin Core Coverage field. We thought we had a hit a wall here, and it seemed that map data could only be effectively recorded using Nealine’s editing tools. Since our spring15 account would not allow student access to a single Neatline exhibit without special permissions hardcoded into Omeka, this did not seem like a sustainable solution, and we did not want to allow students to publish their work in Neatline without being reviewed first by their professor.

The NeatlineFeatures plugin solved this for us. The plugin allows contributors to simply click or draw on a map to enter a location. The coordinates are then transmitted to Neatline when the item is imported. This plugin truly simplified the process.

Next we examined the faculty workflows. In order to give Dr. Eastman the opportunity to review each student’s entry before publishing it to the site, we first created a collection called Needs Publishing. We set this as the default collection for any new Instance of Persecution item, and we set the status of each item as private which keeps an item hidden until it has been properly reviewed.

We created a second collection called Spring 2015. With this configuration, Dr. Eastman could log into Omeka, head straight to the Needs Publishing collection and work through the students’ entries one by one. After reviewing and editing an entry, he could move the item from the Needs Publishing collection to the Spring 2015 collection and designate the item “public”. Once the review and editing process was complete, Dr. Eastman could navigate to the Neatline exhibit and simply import each entry into the Neatline exhibit using the Neatline editor. Given the scale of items in this phase of the project (about 13 in total), we did not explore the bulk import option. Importing individual items one by one allowed Dr. Eastman to review how items were appearing on the map, and he could make adjustments as needed.

 

Plugins

We explored and implemented a number of Omeka and Neatline plugins throughout the course of the project. What follows is a list of the plugins we investigated and their significance:

Plugins implemented:

Plugins investigated but not implemented:

Next Steps

We intend for the site to grow, and we will be exploring ways to partner with other institutions or researchers, perhaps within the Five Colleges of Ohio, our local consortia such as the Great Lakes Colleges Association (GLCA), or perhaps more broadly, with the goal of producing more entries on the early martyrs and their stories.

Neatline and Omeka are scalable tools, but as the content within the site grows, the technical features of the project that facilitate comparative analysis and discovery of the connections between the martyrs will also need to scale. For example, the ability to toggle the pins on the map based on different themes or regions, the expansion of the ancient map to places beyond the Greco-Roman world, and the ability to display more detailed renderings of ancient places where there are dense clusters of martyrdoms are all features our team has discussed as potential future directions for the project.