Working with Omeka(.org) and the IIIF Toolkit Plugin

After dabbling with setting up an install of on localhost, we decided that setting it up with a hosting service was a faster and more efficient way to go. We used reclaim hosting, which provides an easy install feature for Omeka Classic already built-in. After a little bit of initial setup we were ready to get started working with Omeka Classic with all the unrestricted functionality.

We knew we needed Plugins to make our Omeka look and behave the way we wanted so we checked out the Omeka documentation for Plugins ( to search for some that might be good. When we had a list of the plugins we wanted and had them downloaded, we had to send them to our file manager on reclaim hosting through our FTP software (I was using FileZilla on Ubuntu, Marc went with Cyberduck for Mac). How to download, install, transfer, and use Plugins is all well documented on the Omeka Classic User Manual and is what we used to get them up and running.

We ran into an issue when attempting to install the IIIF toolkit, one of the tools we were most eager to use. We transferred the plugin over, and when it appeared on the plugin page, clicked “install”. But we received this error message:

Omeka has encountered an error
To learn how to see more detailed information about this error, see the Omeka Codex page on retrieving error messages.

There was a link provided leading us to a page on how to send error messages, but gave no clues as to why the toolkit wasn’t installing properly.

So the first thing to do was find out what there error was, but Omeka disables error reports automatically. To enable error reports, I had to find the .htaccess file in the root directory of our Omeka install and edit the line:

#SetEnv APPLICATION_ENV development

By changing it from a comment (by removing the #) to a line.

I attempted the IIIF toolkit install again and received this error message:


The configured PHP path (/bin/php) does not point to a PHP-CLI binary.

Now it was just a matter of fixing the problem, which is that our plugin needs to execute code using the command-line version of PHP. I followed the instructions on this forum to fix this problem. 

Working with Omeka(.net)

Today my task was to install and begin to understand how to use Omeka Classic, a tool for creating digital collections and exhibitions. I was concerned about usability (would students be able to learn to use this quickly and efficiently?) and whether or not Omeka’s exhibit feature could easily display the information suited to medieval materials.

Which Omeka?

When you first decide to work with Omeka you are presented with a few different options. First, you are presented with two different versions of Omeka: Classic and S. The site describes Omeka S as “a shareable resource pool” that can be used by institution that want to manage their content across multiple sites. Since our task in the Medieval Book is to create a stand-alone digital catalogue project, I decided to use Omeka Classic.

The next question is or If you already have the available server space, is there to download for free and to start working with right away. If you’re not ready to jump in yet, (like I wasn’t, preferring to first see what potential this platform had) I would recommend the free trial 1-site option despite its limitations: you only have access to 500 MB of storage space and just a few choices of plugins.

Populating the Database

The first thing that is necessary to do is create your collections and begin to add items to them. To keep it simple I created two collections: Carleton University Archives and Research Collection and Carleton University Art Gallery Collection. To make sure I did not go over my space allocation I could not add all the items, but added two items to each collection for testing.

The Exhibition Plugin

Once my database had some items in its collections, it was time to figure out how to display my artifacts. The exhibition feature of Omeka is a plugin that must be installed in order to use. After entering some information on the Exhibit (Title, slug, credits, description) and selecting your Theme (I stuck with the default, Berlin) you’re ready to start creating Exhibit pages. This part was straight-forward. You simply click “Add Page” and it will bring you to a new page where you input the title and slug and get started on the content. Since I already uploaded my files, this part was simple.

You begin by selecting how you want your content to be displayed. Only two give you the option to display both text and images (File with Text and Gallery). I tried one of each to test out the differences. In the end, they essentially give you nearly the same result with the exception of how the images are displayed. In File with Text, the images are displayed quite large whereas Gallery displays them as thumbnails. I plan to explore the plugins that are available to see if there are more ways to display the information that are more intuitive to manuscripts.

My thoughts on Omeka so far

In Omeka I see a large capacity for growth. Although the trial website is limited, it allows you to create a database and exhibit in a fairly intuitive way. Anything that is not intuitive is well documented either by the creators of Omeka or through the user community. For the display of medieval materials however, I see several problems. For one, the Dublin Core metadata element set is very general. Few of the elements are important data for medieval content, and there are many key data elements for medieval content (location, script, and shelfmark, etc) that are absent. In an effort to fix this issue I explored plugins that might expand this restrictive element set. I found LC Suggestion plugin that expands on the default element set, but does not tailor well to medieval content.

There is still so much to learn about Omeka and loads of plugins and features to explore. My next task will be to find online exhibitions that used Omeka (and others that did not) that host medieval artifacts and understand what can be done to accomplish our exhibition.

See what I accomplished with the Omeka free-trial here.

What are we doing?

This blog is meant to provide a running commentary for what is a bit of an experiment for myself and Kate. But who knows how it will turn out.

With the generous support of Carleton University, Kate, an incoming MA student in History, and I, a professor of medieval History,  are working over the summer to create a new course to teach upper year students about how to read, describe and digitize medieval manuscripts (and archival material more generally). Our hope is that we use this blog to document our creative/ analytical process, as well as to leave a record (e.g. syllabus, course readings) to help others who might be in the process of developing similar courses. 

The Journey Begins…

It is your first day on the job at a small heritage site. You discover incredible artefacts in the basement of the site. Untouched for years, two medieval folios sit in a dark corner gathering dust. You are fortunate to find them in decent condition and know something must be done with these unique pieces. But you also understand the limitations of this small heritage site. To ensure these objects reach a wide audience you resolve to create a digital collection. But where to begin?

This kind of scenario was the basis for our brainstorming session today. We attempted to create a list of things one ought to know before jumping into a digital humanities project. We considered the sorts of digital tools that would lend themselves to the various components of manuscript studies: writing supports, codicology, genre, paleography, transcription, and cataloguing. We discussed many online tools and databases that would be helpful in the creation of a digital collection by a scholar at any technical skill level. We assessed sites such as:

  • The Cantus Database, for the study and cross-referencing of medieval chants.
  • T-PEN, a web-based transcription tool.
  • Mirador, an open-source image viewing and annotation platform.

These tools, that are used for the research, transcription, and description of medieval materials, seemed a logical place to begin linking the digital world and the physical. More challenging, however, was trying to understand which of the multitude of digital humanities tools out there can lend themselves best to the task of creating an online archive. We had to ask ourselves some unfamiliar questions on topics such as: copyright, collaboration, the value of open-source tools, the importance of transparency and longevity, and other potential roadblocks for researchers who do not necessarily know how to code.

  • Twitter, as a collaborative space for academics. (See Medieval Twitter)
  • Omeka, an open-source tool for creating a digital collection or online exhibition.
  • Humanity Commons, (You are Here) as a space to keep a manifest of our project.

These sorts of tools can be used across a variety of digital humanities projects and provide benefits to any discipline such as creating collaborative spaces and being easy to use at all experience levels.

In the end these tools are all about balancing the Digital Humanities aspect of creating an digital manuscript collection with Medieval Studies. There are still more exciting tools out there with tremendous pedagogical potential to explore and that may better answer our question, “But where to begin?”