Day 2 - Applying IIIF, Thinking About The Real Thing
The workshop begins with a hands-on session with manuscripts from the Beinecke collection before moving into hands-on work with using local images, annotation, and applying IIIF to projects.
Compare manuscript & facsimile to current Yale environment
What do you see in your physical manuscript that can't be experienced in the digital?
Conversely, what does the digital enable that is difficult with the physical object?
Section 2: Configuring Mirador to tell a Story
We're going to work from the Mirador downloads we edited yesterday. If you remember, you opened the example.html file in your text editor in order to update which manuscripts were pre-loaded in your Mirador instance. Today, we're going to configure Mirador to start with a side-by-side comparison.
First: We're going to make a copy our example.html file. We can do this by saving example.html as comparison.html , for instance.
Now, working in your text editor with comparison.html, we are going to edit a few lines in the configuration. As we start, you should see a part of the html that looks like this:
We want to first change the layout. In the example above, 1 x 1 means we have a single window when Mirador opens. Let's change that so that we have a side-by-side comparison by editing layout: "1x1" to layout: "1x2". Save your file, and open it in your browser. You should see something like this:
While that is a lovely page, it would be even better if you had a comparison set up in advance like this:
In order to do this, we have to add some additional code at the bottom of the html file. In your comparison.html file, somewhere around line 72, you should see something like this:
the windowObjects: [ ], section is what we're going to edit. In order to get the Chaucer example above, we'll edit that line so that it looks like this:
We're not quite done yet, because we have asked Mirador to open two manifests it doesn't know about yet - that is, the loadedManifest manifests are not in our general list of manifests for this Mirador instance. Let's add those in as well:
data: [
{ "manifestUri": "https://dms-data.stanford.edu/data/manifests/huntington/el26c9/manifest.json", "location": "The Huntington Library"},
{ "manifestUri": "http://dams.llgc.org.uk/iiif/2.0/4628556/manifest.json", "location": "The National Library of Wales"},
{ manifestUri: "https://iiif.lib.harvard.edu/manifests/drs:48309543", location: "Harvard University"},
{ manifestUri: "https://iiif.lib.harvard.edu/manifests/drs:5981093", location: "Harvard University"},
{ manifestUri: "https://iiif.lib.harvard.edu/manifests/via:olvwork576793", location: "Harvard University"},
Save your file, and let's look at it in the browser again, you *should* see this (if you don't, shout!):
You can experiment on your own with different aspects of configuration (try setting up a 3 or 4 object comparison, for instance, or compare pages from within the same manuscript).
Section 3: Annotations
To save annotations, you need to have an annotation server OR you need to be able to create static annotation lists and serve them (like you did with manifests).
Annotations Step 1: Understanding Regions of Interest
Make a test annotation on an image from your manuscript
Open the Chrome Developer Tools
6. Now we're going to look the Application tab and the local storage information
7. Each one of these annotations contains information about the region of interest, the text of the annotation, and the canvas to which the annotation belongs.
In the list above, we have a container with an @id similar to the manifest we created yesterday. Within that container is a list of resources each of which is an annotation, like the one you saw in Mirador above. To manually create your annotation list, copy an annotation from Mirador and paste into the resources section, then update the @id to be the location where your file will live (again, just as we did with manifests yesterday).
The final step is to point to your annotation list from your manifest using the otherContent property as here:
While it is perfectly possible to create lots of annotations this way, it is certainly not a lot of fun or an efficient use of your time. Instead, it is preferable to use an annotation server.
Section 3: Annotation Servers
I'm going to be honest - this can be a bit of a pain. There are two approaches we will look at: the first is a SimpleAnnotationServer developed by Glen Robson, the IIIF Technical Director; the second is a suite of tools for annotation developed by Niqui O'Neill at North Carolina State University.
These can be copied into a AnnotationList using the template we looked at above, stored, and then added to a manifest.
Glen has also provided a script to allow you to download pre-cooked Annotation Lists. More on that here. If we have time, we may cover this in the workshop.
Now you're getting fancy
If you have successfully created a bunch of annotations and want to
The NCSU Annotation Suite
If you are wanting to explore more in this vein, the NCSU Annotation Suite is a powerful set of tools for telling stories with your annotations. We may not have time to cover this in the workshop, but the tools and installation instructions can be found here: https://github.com/dnoneill/annotate