In which librarians offer a healthy serving of IIIF

After some some trial and error (mostly error), we did what we should have done much early and went to talk to a librarian. Being relatively new to the DH field (and as a medievalist), I don’t really pay much attention to much beyond books at Carleton University’s MacOdrum library. After a meeting with the University Systems gurus –Ed Bilobeau, Jennifer Whitney and Kevin Bowrin– they assured me that they could set up a IIIF server on shared digital infrastructure provided as part of the OCUL (Ontario Council of University Libraries). Long story short – they were amazingly helpful and we now have our manuscript images served up. We still need to create IIIF manifests to make them accessible to the Mirador viewer on our Omeka site so that they will be ready for use come September.

With this milestone passed, now back to the task of sorting out readings, scheduling speakers and creating the detailed instructions for the weekly assignments and major term projects.

Take a look here at what IIIF can do with images!

IIIF Toolkit: Trials and Tribulations

We’ve returned home to Ottawa and we’re ready to start uploading our IIIF content to our Omeka site. Nothing works, everything seems broken. With moral low, we began to frantically google our problems. We were missing one very important part to make the toolkit work:

We needed to install and host a IIIF image server.

We first attempted to host our images on an online server, the Internet Archive. With the API still in alpha and the documentation still in progress, our results we far from perfect. Our images had their default resolutions set to thumbnail size and we could not manage to create proper manifests through archivelab.org. Perhaps we need our own Image Server that we can point to our Omeka install?

The next IIIF image server I attempted to install was Loris. But without dedicated server space, the server would be run locally (and therefore not always accessible). This wasn’t a viable solution for our project. We needed server space.

After discussing it with others in the department, we realized that we should get server space through our institution and allow an experienced computer scientists from the university install our IIIF Image server for us. This means a lot less challenges in the Terminal for me, and less of a chance that the image server will cause us issues (due to my modest installation attempt) in the future.

Post DHSI brainstorming

After being at the DHSI at UVic last week, my idea of what we can accomplish over the course a two term class has changed. This realization comes in part from my own movement from someone who had never coded to someone increasingly comfortable with editing .json files and simple html. So, if a non-techy medievalist such as myself can learn it in a week (≈ 24 hours of instruction) I guess I can expect students to pick up a fair bit of it over two terms (in class, ≈ 24 x 3 hours = 72). We do have a lot of book history to learn, mind you.

If we structure the class correctly, I think, then we can lead students on a quest –starting with social media and ending with simple programming. Students will be expected to use #medievaltwitter (for networking, watching for calls for papers or finding ideas about what is joining on in medieval DH), to blog about their thoughts on the exercises and readings, before moving over to the relatively user-friendly CMS Omeka  as well as the more arcane worlds of GitHub and IIIF to display their work in progress.

The assignments are organized around a spiral curriculum, in which students address a topic and then return to it for at least one further pass. We will start by getting people used to the online environment by using familiar environments – Twitter and blogs. These platforms allow the students to share their experience using other tools. But the real focus is on the uncatalogued medieval material in the holdings of Carleton University. Over the course of the year , each student will work on a single folio to describe, transcribe and analyze it. Their folio then becomes the central focus of students’ work as they consider it from different perspectives and with different tools. What was it like, for example, transcribing a medieval document with pencil and paper? And then how did it differ when using a tool such as Recogito or Transkribus? What changed when inputting a catalogue record modelled on manuscript catalogues to putting that information into Omeka, which uses Dublin Core. By the end of the first term, students will have used Omeka to present a detailed description of the folio. In the second term, I will ask students to present much of the same information, but this time they will be encoding the information as a TEI file that they will make available through a Github Jekyll site.

As I think about all the possibilities, I realize that the key to teaching this course is having a lot of material prepared beforehand. Having templates created and tested beforehand, as well as workflow sorted out will mean that the class should run smoothly. To help with workflow, I created a slack group today for the class and integrated a google drive (where all the manuscript images are currently located), a google calendar (to keep track of deadlines and the presentation schedule) as well as other things I don’t know if they’re useful or not (such as Polly – to allow easy polling of the slack members, and Todo, to create todo lists).

And so, we march on.

Back to being a student

This week Kate and I are attending the Digital Humanities Summer Institute at UVic. I feel like I’m going back to being a first-year undergrad (with all the awkwardness and confusion that implies) while also attending a wonderfully nerdy and welcoming summer camp. The experience (and being confronted by the realms of my ignorance) have made me reflect a bit about why I have wanted to get involved in the digital humanities. I think I need to figure out what I was thinking when I signed up to learn about IIIF Image servers or presentation API’s…

Most of my early connection to computers was for entertainment – my parents got my brother and me a colecovision console in the early 80s and then sent us to mini-university computer camp to teach us how to program on a  Commodore 64 (which we then used exclusively to play games). Since both of my parents were teachers, we had a steady stream of early Apple computers intended to be educational. These were the first machines I did something other than play games on – learning (maybe?) from vaguely educational software (e.g. Where in the World is Carmen Sandiego) or writing up school assignments. And this is in essence how I have also used computers – for entertainment and for composing papers. Throughout grad school and to this day for my research, I have rarely used my computer as anything more than a word processor and, these days, increasingly a means to read pdf article and books. So, as my history shows, I really don’t have any background nor any reason why I should be trying to teach about Digital Archives.

In teaching, however, I have often sought to have students use digital environments to see historical practice from a new perspective. Almost a decade ago, I had my students in classes on medieval intellectual life edit wikipedia articles to get them used to the idea that others would see what they write or that their writing could impact how the Middle Ages is perceived (and also to improve the quality of scholarship of Wikipedia in those early days). More recently I’ve tried to incorporate smaller digital assignments to help student re-imagine their research process such as using Knightlab’s Timeline which was meant to provide a new structure for constructing historical chronologies. I’ve found that using these tools (which are really just new versions of tools long used by historians), students were able to better understand how and why scholars work the way they do.

It is with this in mind that I want to create a new course devoted to the process of digital archiving – even though I takes me far outside my comfort zone (reading and thinking about Medieval Latin texts), and into the terrifying world of Unix and command line editing. Thank goodness I have a graduate student to act as an Ariadne in this DH labyrinth.

 

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

After dabbling with setting up an install of Omeka.org 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 (https://omeka.org/classic/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:

RuntimeException

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.