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:
Dr. David Eastman - Associate Professor, Department of Religion, Ohio Wesleyan University
Dr. Jacob Heil - Mellon Digital Scholar, Five Colleges of Ohio
Catherine Cardwell - Director of Libraries, Ohio Wesleyan University
Ben Daigle - Liaison Librarian to Department of Religion, Ohio Wesleyan University
Emily Gattozzi - Digital Initiatives Librarian, Ohio Wesleyan University
David Soliday - Educational Technologist, Ohio Wesleyan University
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
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:
Title - For our purposes, this is the name of the martyr(s) or confessor(s).
Date - This is when the persecution or martyrdom occurred, or the best estimate.
Coverage - This is where the martyrdom/persecution took place, or the best estimate. This field provides a map on which the contributor can plot the location of the martyrdom.
Contributor - The name of the student contributor
Custom Item Metadata Elements
Location - The textual name of the location of the martyrdom, or the best estimate.
Type of Persecution - How the martyr was persecuted or martyred.
Nature of Conflict - A larger group conflict under which an instance can be classed (eg. Romans against Christians, Jews against Christians, etc.).
Participants - Names of individuals or groups participating in the martyrdom.
Primary Sources - List of primary sources used for the summary.
Historical Context - Background information and/or explanation about the context of this event. What does the reader need to know in order to understand this martyrdom account? What was happening in the Christian world at this time and place?
Summary - A detailed but concise summary of the martyrdom account based on the primary source(s) used.
Significance - A brief answer to the question: Why is this martyr/confessor important?
Bibliography - Sources consulted.
Image Credit - Link to image permissions (if there is an image file).
Image - An attached image file.
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:
"title": "Pelagios Digital Map of the Roman Empire",
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:
As a student, I need to be able to post my own entries so that they appear on the website.
As a professor, I need to be able to review student entries before they are made public so that they are properly vetted before publication.
As a professor, I need to be able to publish student entries to the website after I have reviewed them.
As a professor, I need to be able to add reviewed student entries to the map.
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.
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:
Neatline - Provides the map and map editor for the primary map exhibit.
NeatlineFeatures - Provides a visual map on the Add Item page in Omeka with which contributors can specify a geographic location for their entries. This same map also appears when viewing the item’s detailed record in Omeka.
NeatlineSIMILE - Provides the timeline at the base of the map exhibit.
NeatlineWaypoints - Provides an additional option for navigating the exhibit that permits exploration by themes, such as Apostles or Female Martyrs, for example.
Search by Metadata - Turns metadata into hyperlinks. When clicked, Omeka launches a search for the metadata terms and provides the user with results that match those terms. We felt this was a great way to discover connections between the martyrs.
Simple Vocab - Allows administrators to establish a controlled vocabulary for specific metadata fields. In our project, we used this plugin for the Type of Persecution and Nature of Conflict elements. This helped to ensure that there would be some consistency in those fields in order to, again, facilitate connections between entries that share those same elements.
Plugins investigated but not implemented:
Contribution - Provides a simple web form for end-users to contribute content to the site without having to login to the Omeka administration backend. While we thought this could be a useful plugin for sites seeking simple contributions from the general public, we did not feel it was going to work as a method of collecting student entries, given that we wanted entries to be reviewed before being published. We also had trouble customizing the form to include all the metadata elements we needed students to contribute.
Facet by Metadata - Provides a method of limiting results by clicking on checkboxes that correspond to matching metadata elements. We explored this when we were investigating ways of presenting options for users to navigate the exhibit by different themes, such as Nature of Conflict, Type of Persecution, Region, etc. However, when installed, this plugin places facets at the bottom of an Omeka item page, not the Neatline exhibit, where we were hoping to facilitate this kind of navigation.
Geolocation - Allows users to plot entries onto a Google map. This was the first plugin we considered as a means of allowing students to specify the locations of their martyrs. However, this was another field that seemed to be displayed only in Omeka and did not transmit to Neatline. The NeatlineFeatures plugin filled this need.
Guest User - The Contribution plugin is dependent on the Guest User plugin. It provides the means of authentication for contributors who must sign up for an account before submitting their contributions. Since we abandoned the Contribution plugin, we ultimately abandoned this one, too.
Item Relations - Provides the ability for administrators to specify relationships between items on the site. This was another plugin we investigated when exploring alternative ways to navigate the map. We still feel that this plugin has promise and may be more useful as the site grows.
NeatlineText - Provides the ability to create visual lines between textual elements in the narrative panel and points on the map when hovering over specific bits of text. Since our map exhibit is not textually heavy, this plugin did not offer a lot of value to us.
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.