Environmental Scan: Services and Technology =========================================== About ----- This document attempts to define and document the various services that inform the workings of the digital library. While specific microservices may be covered or explored, this document attempts to center on the functions of the various software rather than the software themselves. Digital Assets Management ------------------------- Digital assets management, or the process of using software to store, organize, share, find, and retrieve digital assets for an organization is done with more than one system. Minimally, some files are stored in Fedora and others are stored in DSPACE. **Questions / Things to Answer** 1. How do works and files get into either system programmatically? 2. In DSPACE, what is the process for generating RDF? 3. In DSPACE, how is sequence determined? 4. Does Avalon use Fedora or a separate assets management system? 5. What does Internet Archive Book Reader use? IIIF ---- ========== IIIF Image ========== The `IIIF (International Image Interoperability Framework) Image Service `_ is a standard and a set of APIs designed to facilitate the sharing, accessing, and viewing of images from various repositories in a consistent and interoperable way. It provides a standard API for accessing image content, which allows different systems to retrieve images in a consistent manner and supports dynamic delivery of images, enabling users to request images at different sizes, qualities, and formats without needing to store multiple versions of the same image. While the API has many features, its most important features and purposes are related to image manipulation, interoperability, deep zooming, and scalability and efficiency. Currently, we use `Cantaloupe `_ as our IIIF Image Server. It is available online `here `_. Our image server uses IIIF Image 2.0 and adheres to level 2 of the specification. While level 2 is not complete, it is defined as desirable. Currently, Cantaloupe serves images from Fedora and DSPACE. The most important outcome of an image server is that it adheres to the things defined in its response in a performant way. Here are the results of several requests and processing times with an image from DSPACE. * `Get image response `_: 58 milliseconds * `Get full image as jpg on largest size `_: 4.36 seconds * `Get next lower resolution version `_: 3.54 seconds * `Get mid `_: 2.00 seconds * `Get lowest in original state `_: 1.47 seconds * `Grab full image with 516 width, rotate it 90 degrees, return as GIF `_: 1.93 seconds * `Grab full image, rotate it 180 degrees, return as PNG, and grayscale `_: 6.16 seconds * `Grab image at 50 pct `_: 3.24 seconds * `Grab a small region `_: 1.45 seonds ------------ Load Testing ------------ The tests above are useful, but they don't really test the performance and scalability of our image server. We can use something like `Locust `_ to do that. Luckily, there is a community project with specific IIIF tasks that mimic what a series of users might do in an application leveraging an image server. ########################################################### Scenario 1: Test Images from Exhibits Using Files in Fedora ########################################################### To perform this small test, let's use the images from these manifests: .. code-block:: text https://library.tamu.edu/iiif_manifests/houstonoilmanifest.json https://api.library.tamu.edu/iiif-service/fedora/presentation/3b/6f/c3/25/3b6fc325-f6ca-41d8-b91e-8c5db3be8c13/berger_cloonan_objects/2 https://api.library.tamu.edu/iiif-service/fedora/presentation/3b/6f/c3/25/3b6fc325-f6ca-41d8-b91e-8c5db3be8c13/time_of_resolve_objects/2 https://api.library.tamu.edu/iiif-service/fedora/presentation/3b/6f/c3/25/3b6fc325-f6ca-41d8-b91e-8c5db3be8c13/time_of_resolve_objects/69 https://api.library.tamu.edu/iiif-service/fedora/presentation/3b/6f/c3/25/3b6fc325-f6ca-41d8-b91e-8c5db3be8c13/time_of_resolve_objects/3 https://api.library.tamu.edu/iiif-service/fedora/presentation/3b/6f/c3/25/3b6fc325-f6ca-41d8-b91e-8c5db3be8c13/time_of_resolve_objects/5 Other test params are `10 users` spawning `3 users` per second and we'll run for 10 minutes. Here are the results: .. raw:: html ########################################################### Scenario 2: Test Images from Exhibits Using Files in DSPACE ########################################################### To perform this small test, let's use the images from these manifests: .. code-block:: text https://api.library.tamu.edu/iiif-service/dspace/presentation/1969.1/2808 https://api.library.tamu.edu/iiif-service/dspace/presentation/1969.1/2491 https://api.library.tamu.edu/iiif-service/dspace/presentation/1969.1/2809 https://api.library.tamu.edu/iiif-service/dspace/presentation/1969.1/2810 https://api.library.tamu.edu/iiif-service/dspace/presentation/1969.1/2811 https://api.library.tamu.edu/iiif-service/dspace/presentation/1969.1/2822 https://api.library.tamu.edu/iiif-service/dspace/presentation/1969.1/3690 https://api.library.tamu.edu/iiif-service/dspace/presentation/1969.1/3041 https://api.library.tamu.edu/iiif-service/dspace/presentation/1969.1/2933 https://api.library.tamu.edu/iiif-service/dspace/presentation/1969.1/128905 https://api.library.tamu.edu/iiif-service/dspace/presentation/1969.1/128911 Other test params are `10 users` spawning `3 users` per second and we'll run for 10 minutes. Here are the results: .. raw:: html A quick note. Some problems here might be related to image sizes: :code:`https://api.library.tamu.edu/iiif/2/bb864ab1-84ce-340d-8198-5e4c7bb87ca2;1/info.json` That's right, a color text page is nearly 20K pixels on the long edge. Cantaloupe can't even build it. ############################################################################### Scenario 3: Test Images from IRIIIF Resources from DSPACE but not in an Exhibit ############################################################################### To perform this small test, let's use the images from just this manifest: .. code-block:: text https://api.library.tamu.edu/iiif-service/dspace/presentation/1969.1/92826 Note. I've played with this manifest alot today so it's possible this performs well. Other test params are `10 users` spawning `3 users` per second and we'll run for 10 minutes. Here are the results: .. raw:: html ########################################################## Scenario 4: Test Images from My Custom Generated Manifests ########################################################## To perform this test, let's use `all these manifests `_. Other test params are `10 users` spawning `3 users` per second and we'll run for 10 minutes. .. raw:: html ============================================ Presentation of Works with IIIF Presentation ============================================ The IIIF (International Image Interoperability Framework) `Presentation API `_ is a specification designed to enable the structured presentation of digital objects in a way that supports rich user interactions and interoperability between different systems. The API supports advanced viewing capabilities, such as zooming, panning, and page-turning and builds upon the IIIF Image API to do this. While primarily focused on images, the IIIF Presentation API can also support other media types, such as audio and video, enabling the presentation of diverse digital objects. It is also designed to integrate with the W3C Web Annotation framework so that resources can be annotated and displayed to tell unique stories about a work. IIIF Presentation is enabled by a manifest that describes how a viewer should display a work. Because the API is interoperable, IIIF viewers are interchangeable. For instance, here is the :code:`Geological Survey (United States)` manifest from our repository in 4 different viewers: * `Clover `_ * `Theseus `_ * `Mirador `_ * `Universal Viewer `_ * `Glycerine `_ IIIF Presentation and manifests are provided by `IRIIIFService `_. This application works with resources hosted in either DSPACE or Fedora and adheres to IIIF Presentation 2.0. This version of the API only supports images. IIIF Presentation 3.0 allows resources to include AV. For instance, here is: * `An audio work with a transcript from my previous institution `_ * `A video work with a closed captioning in Spanish and English from my previous institution `_ * `A compound work from my previous institution with an image in the first canvas and a video with closed captions in the second canvas `_ Like with images, there are many IIIF viewers that support video. For instance, here is: * `A video work from my previous institution with closed captioning in Spanish and English and segmented interview questions `_ Ideally, all works served via digital collections would have a corresponding manifest that is informed by its work type. Doing so ensures the best presentation of our resources and encourages the reuse of digital collections in research and other creative activity. It also allows us to easily reuse an asset from any digital collection in an exhibit. For instance, let's look at the Galston Studienbuch exhibit from my previous institution by clicking the :code:`Explore the Volume` button and launching the modal. .. raw:: html These are annotations added by researchers that allow users to explore the multiple Works and see specific information. This helps tell an important story about this unique collection and does so without changing the underlying work. Additionally, let's look at the `Letter, Dom Lynch in New York N.Y. to Ebenzer Hazard.,1793 July 5 `_. This resource has accompanying annotations of the handwritten text that is searchable and displayable. ------ IRIIIF ------ IRIIIF is a Spring backend for the Institutional Repository International Image Interoperability Framework (IRIIIF) Service developed and maintained by Texas A&M University Libraries. This service provides IIIF manifest generation for works in OakTrust and from Fedora. IRIIIF supports single and multicanvased works, but since it is based of IIIF Presentation v2, does not support AV. One interesting thing that this service seems to be able to do is build canvases in a manifest from pages in a PDF. This means that an ETD and other PDF works should be able to be served in a IIIF viewer with a modern viewing experience. Redis is used for manifest cache and resource URL caching. There are still many things I need to learn about this service including: 1. When a Manifest is generated, how long is it cached for in Redis? 2. Can a Manifest be regenerated on demand via a HTTP get parameter ( :code:`?update=true` )? 3. How are manifests from DSPACE RDF informed? For instance, how does IRIIIF know sequence order? 4. Does IRIIIF assume all files on a work need to be delivered as canvases? In other words, if a work has a PDF, jp2s, and jpgs, do all get rendered as canvases? 5. When a new collection goes online, are manifests generated and cached or is that done on demand? If the latter, what if the work has 2000 pages? 6. If an item in DSPACE has no RDF, who can generate that so that the work has a corresponding manifest? For example, this item from `Primeros Libros `_. -------------- OCR and Search -------------- OCR is important for the discovery of text resources. **Questions**: * How is OCR utilized in SAGE or Spotlight? * How is OCR used for used in the viewer (IIIF Search)? --------------------------------- Transcription of Handwritten Text --------------------------------- Handwritten text is present in some works found in our repositories. Historically, handwritten text has been costly for Libraries, Archives, and Museums to transcribe in order to make works more searchable, understandable, and useful. At previous institutions I have worked at, there was a history of text encoding with TEI. This required humans to interpret the text, transcribe it, and encode it as well formed XML and valid TEI. This was a costly process but it provided an easy approach to present the work with IIIF annotations: .. raw:: html At Texas A&M, a different approach has been taken. Rather than transcribe the resources in house, pilots with `From the Page `_ have been pursued. FromThePage is an open-source tool that allows volunteers to collaborate to transcribe handwritten documents rather than having all the work be done in house. With From the Page, a work or collection is imported as IIIF Manifests. Each page is then loaded from the providing institution as IIIF Image resources and volunteers transcribe the work according to guidelines created by the providing institution. At any point after the transcription begins, the providing institution can export a project as HTML, plain text, CSV, TEI, IIIF, or another export format. The export format chosen greatly affects the interoperability of the resource. For instance, `TEI from the Houston Oil Minutes Project `_ easily provides the transcription in a format that many TEI powered platforms (like TEI Publisher) can import and use. The `IIIF export `_ includes an annotation list that can be opened in viewers like `Mirador `_ or `Theseus `_. .. code-block:: json "otherContent": [ { "@id": "https://fromthepage.com/iiif/1692120/list/transcription", "@type": "sc:AnnotationList", "label": "Transcription" } ]