Overview: To deliver high quality images from a repository to any third-party consumer, three components are required

• A machine-queried manifest of the repository contents (M3) – also known as the “Resource Map” in various documentation.
• Image services: A large-image-streaming server and a suite of web services to facilitate delivery of the images out of the repository
• Some viewing environment to demonstrate the functional components above. Any third-party viewer should be able to consume the data in the first two points above, though Stanford will also host a viewing environment as part of the image stacks work.

Details:

“The Medieval Manuscript Manifest (M3)”

The manifest of repository contents combines a model of the physical structure of the manuscript object with a list of all available images in the repository for that object. It is used by content consumers to find and display images from the repository in a machine-actionable way. The data model is the subject of the Stanford-hosted technical meeting in December 2010, and will continue to be refined over the course of the project. This data model, in addition to representing aspects of the physical object and its relationship to associated facsimiles, must also be able accommodate pointers to rich descriptive metadata and any annotations and transcriptions that exist.

The current version of the Medieval Manuscript Manifest can be found on the DMSTech wiki.

In the model below, the “Seq” or sequence of the object represents a state of the structure of the object (the bound codex at a given point in time, for instance) which contains a certain number of constituent parts or “Views” (this includes, for example, the front and back boards, all flyleaves, edges, and surface of each folio). The “Rng” or “range” component allows sub-groupings between the page and object level. Each “view” can be associated with any number of images (for instance, spectral imaging of a page, full page view, detailed photography, etc.).

A simple graphic representation of the current data model summary:

“Image Viewer”

In general, this is the tool that allows a user to view the image file. Two familiar models are: the “page-turner” viewer that purports to model the experience of flipping through a physical book; the “thumb-nail view” which displays the contents of an object as a series of clickable thumb-nails. A third model may also be familiar: the Zoom-Pan-Rotate (zpr) view, that allows viewing and some manipulation of high-resolution images.

Additional viewers are imaginable (multi-up viewers, separately addressable frames, etc.), but Stanford will not be building these as part of the current project. We expect third-party tool makers will create these.

“Image Services”

• Load-balanced Djatoka Server
• Web services

To actually deliver high-quality image files from the repository over the internet, an image server is necessary that can handle the high volume of data traffic typical of a digital library, along with the various file types and special requirements needed to work with material from a repository. Stanford has chosen the open-source Djatoka server which supports the JPEG 2000 image format, and also allows URI-addressability of regions of interest within each image. This means that large images can be delivered over the web without major performance issues, and that annotations and transcriptions can be linked to specific sections within each image.

In the diagram below, which represents the full set of Image Stack components, the bottom box represents the actual image service suite – a combination of hardware for storage, software for service to the web, and (unseen) the suite of small programs (web services) which allow programs and users to access the data.

From the repository side, those web services include the following functions:

• Allow selection from a catalog of image files
• Provide a requested file of specified dimensions (as allowable)
• Provide access to additional descriptive metadata

Overview diagram of the Image Stack: