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.