Tools for the DigitalSEL

Tools for the DigitalSEL

Conflabunt gladios suos in vomeres 1

In passus VI of Piers Plowman appears Langland’s famous allegorical description of utopian labor—the plowing of the half-acre. Here, Piers the Plowman describes the purpose of his work and, notably, the tools with which he does it:

I wil worschip þer-with · treuthe bi my lyue
And ben his pilgryme atte plow · for pore mennes sake
My plow-[p]ote shal be my pyk-staf · and picche atwo þe rotes
And helpe my culter to kerue · and clense þe forwes2

After I finished writing my last post, as I was making a new project directory and started looking around in the Ruby Toolbox to compare libraries, it occurred to me that I should probably offer some sort of description of the tools I plan to use to develop the project. Though I don’t really plan to make this a “how to program” blog, it would probably be useful to outline the technologies I will be talking about and why I think they will be effective for building the project.

Readers of this blog are doubtless aware of the degree of excitement right now in Medieval Studies for using digital technology in academic work. Though there are some really impressive digital manuscript projects and reference materials, there is opportunity for innovation in an old fashioned corner of philology: textual studies. I plan to write much more about the theoretical underpinnings of what I am up to later, but suffice it to say now that I am building a digital critical edition, and so I am fundamentally interested in storing, retrieving, and parsing texts. Although digital tools for making editions of Middle English texts don’t really exist, it should be possible to recast existing technologies for my purposes.

Our Field to Plow: Some Basics

It sort of goes without saying that the internet is a great platform for a project like the DigitalSEL. It is widespread, does a great job of handling text, and is stable enough that you can watch live video on the subway, for goodness sake. What is less clear, however, are which tools and software would be appropriate for building this kind of digital edition. This is made more complicated because the computation for the internet happens at different stages and in different places: the browser and the server.

How the Internetz Works:

Cat surfing the web


The work that is done in a web browser like Chrome, Safari, Firefox, or (shudders) Internet Explorer deals with a how a webpage looks and “acts.” The browser renders content and structure on the page (HTML), implements the page’s style (CSS), and determines the sort of behavior you might notice when a button changes color when you drag your mouse over it (JavaScript). The fact that this work happens on your personal computer or phone accounts for the fact that webpages look different in different browsers, like Chrome or Safari.


Daamn Checking your bank account after the book fair

Most of the data-heavy computing determining what information is sent to your browser occurs on a server. When you log into your bank account, you are communicating with a server in order to fetch your specific information. Since your bank’s server is basically a special, big computer that you communicate with remotely, the programmer who set it up could install and use whatever software she thought would be good for the project. You can run whatever computer language or software you might like on one. Common server-side programming languages are Java, C++, PHP, Ruby, and Python.

Model View Controllers

Over the years, a number of software frameworks written in these languages have emerged that make it easy to build a new web application complete with server-side components. For the most part, they include elements that constitute a popular pattern called a Model View Controller (MVC):

  • Model: The model, as you could guess from last week’s post, is the part of the application that maps onto and deals with objects in the database. When I wrote about how Aquinas belongs_to the Dominicans, I was talking about logic that is written in the model.

  • Controller: The controller makes the decisions about the requests that it gets from users. When the cat above requested information about Julian of Norwich, it was the controller that decided what to do with the request. After that, it sends the appropriate response back to the user.

  • View: The view section of a MVC includes all of the code that gets sent to your browser so that you can “view” the information you requested. This includes all of the code that makes up the structure, style, and behavior discussed above.

So, for example with the DigitalSEL, if you were to choose to look at the “Life of Mary of Egypt,” the controller would decided whether that was a reasonable request (it is!), and it would send that information along to the model. The model would then figure out if you had made any other special requests about the text you wanted to look at, and then it would retrieve Mary’s life from the database and send it back to the controller. After the controller heard from the model, it would then determine which views it needed, queue them up, and send them back to your browser which would display them for you to take a look at.


In a medieval bread-meme, Mary of Egypt is famous for bringing three loaves with her into desert-exile.

The DigitalSEL on Rails


There are a number of good MVC frameworks that could work for a project like the DigitalSEL, but I’m using Ruby on Rails (Rails). It is perfectly suited for what I want to do, is actively supported, has a ton of libraries, is easy to get running, and it has the strong advantage of being the tool I have and know. Additionally, Rails is completely free and open source, meaning it is a distributed and community-supported framework that anyone can use.

Caveat Lector

As I suggest above, I probably won’t spend time explaining basic programming concepts (though I will link to them). Nevertheless, I do plan to document every single step I take on the project so it will be possible to follow along and learn from and build upon my work. If you are just interested in tracking my progress, some terminology will be helpful for understanding basic concepts in Rails development:

  • Command line: It is ironic, but a great deal of modern web and software development takes place in an operating system developed in the 1970s called Unix. Programs like Unix or Linux are commonly called the “command line,” sometimes abbreviated “CLi.” On a Mac, the program that runs a born-again version of Unix is called Terminal.

  • Ruby: Ruby is a programming language that was developed in the 1990s by a developer called “Matz,” who, by all accounts, is a really nice fellow. Ruby is the language upon which Rails, the framework, runs.

  • Gem: A gem is the Ruby term for a package of code that you can download and include in your own project. Gems are generally all free and community supported. They are called “modules” or “libraries” in other languages. For example, the Prawn gem is a PDF generator that I plan to use in my project.

  • Git: Git is a command line application for version control. Basically, it allows you to take a snapshot of your project so that if you mess everything up, you can go back and recover previous versions of your work. It is an extremely powerful tool, but is also very confusing. For example, Git is the program and GitHub is a website where people store Git repositories. I plan to blog about it in the future.

  • Text editor: A text editor is just that: a program on your computer that reads and writes text documents. This is different from a document editor, like MS Word, in that a text editor will only save files in the format you tell it to. I use Sublime Text, but there are many others, including Vi or its younger cousin “VIM,” which, believe it or not, you probably already have installed on your computer if you are currently reading this on a Mac. We will talk more about VIM when we have to do programming on the server.

Next up, I plan to walk through the first steps of building the project, explain what comes in a Rails app, and explain how to fire up the server so we can start building the database. I am hoping that the posts get shorter as I plan to get down to brass tacks and just talk about building the app and what to do about mark-up.

  1. The header image is from London, British Library, Additional 42130 (The Luttrell Psalter), fol. 170r.

  2. BX.6.105-107. Text from the Piers Plowman Electronic Archive. A Modern English translation is available from Harvard

Transcription and Programmatic Markup for the DigitalSEL

Medieval writers were keenly aware that their basic mode of textual reproduction, scribal transmission, introduced all sorts of variation...… Continue reading

Data Modeling for the DigitalSEL

Published on April 09, 2016

Using Jekyll for the DigitalSEL Blog

Published on April 03, 2016

William E. Bolton, PhD

William E. Bolton, PhD
William is a software developer and independent scholar living and working in Philadelphia. My academic work focuses on the lives of saints written in England between 850 and 1350.