2. Text
2.1. Introduction
Thank you to the organizers and all of you for being present. I look forward to the discussion and questions. Let me begin by introducing myself, my resources, my project, and my goals as relevant for the ideas I describe below. I teach theology at a teaching-focused small liberal arts college in San Antonio, Texas. My formal training is in early Jewish literature, especially the books preserved among the Dead Sea Scrolls. I could be described as curious about technology, but I do not have formal training in computer languages. My University does not have a Center for Digital Humanities or any advanced technical support. My research schedule is irregular around teaching and service, so my collaborations tend to be informal with colleagues of similar technical ability. I can see why large, well-funded teams would make different decisions, but that is not my situation.
My project is the Jubilees Palimpsest Project. The Book of Jubilees is attributed to Moses and preserved partially among the Dead Sea Scrolls. The next earliest witness is a Latin Translation copied in the fifth century and erased in the eighth century to copy a new text. The erased text is only partially legible today with the human eye, so I have relied on Multispectral Imaging to improve legibility. Legibility remains challenging and often ambiguous. The current stage of the project is to produce scholarly editions tailored to print and digital media.
The print edition will foreground the edited text and relegate scribal oddities to the apparatus. It will favor readability with modern judgments of concepts such as paragraph divisions. While I recognize the place for such an edition, my own heart is in steering the reader to facsimile images and a hypertext edition that foregrounds the manuscript as an object of scribal culture, not just a text container. On a practical level, I would also like readers to be able to check the certainty of our readings given the state of preservation of the manuscript.
The complexity of the facsimile images demands a powerful viewer such as Mirador. It is essential to be able to zoom in and out of high resolution images and switch layers between various color and texture visualizations.
It is also important for the reader to be able to navigate by chapter and verse, or the fifth-century page sequence, or the modern page numbers.
Because legibility is often difficult, it is helpful to the reader to see annotations for each line with our proposed reading.
We also want those annotations to link to a hypertext edition that presents readable digital text in the same column and line format as the manuscript.1 The hypertext edition uses hover, click, and apparatus to help the reader while foregrounding the witness of the manuscript.
1 Abbreviations and Nomina Sacra are visualized as seen in the manuscript, with hover text helping the reader with the expansion.
2.2. Why Integrate TEI and IIIF?
Unsurprisingly, my use case led me to the Text Encoding Initiative (TEI). The advantages of TEI for the production of critical editions has been thoroughly studied. The modules on manuscript description and critical apparatus prompt us to think about our categories and information we should be including. We can describe the text on an abstract level of semantics and defer questions of visualization that may differ from publisher to publisher. LaTeX modules produce beautiful pre-print renditions with apparatus and facing page text and translation. All the desiderata for the hypertext edition can be encoded in the same source and different visualizations can render or ignore as desired.
Similarly, my goals for viewing facsimile images and annotations led me to Mirador and the IIIF Presentation API. At this point I could have moved forward with two technologies for different goals of the project. Today I would like to say more about why I integrated TEI and IIIF, how I did it (facing what challenges), and why I favored a streamlined approach.
When I say I integrated TEI and IIIF, I mean I created a workflow that puts TEI at the head and derives everything else from that one source. For each visualization there is a different eXtensible Stylesheet Language Transformation (XSLT) that renders the different visualizations (although there are other ways of doing it). One of the main advantages of the single-authority model for us is that we can make changes in one file that will automatically cascade to the print edition, hypertext edition, and IIIF Annotations. Our edition is a work in progress.
It is also a benefit to do the editing work in XML and not have to use JSON on a regular basis. I often think about what it is reasonable for my students and colleagues to learn. It is easier to learn one language than two, and of the two I think XML is much more human-readable. At any rate, it is possible to code all the information in XML and derive JSON, but not vice versa. It seems to me that whether one loves or hates TEI correlates with whether one is able to embrace thinking semantically about texts. Personally, I have found this to be a fun and thought-provoking challenge. I can say more about my experience with this challenge in the discussion if there is interest.2
2 A deeper challenge is in how we think about texts. It seems to me that whether one loves or hates TEI correlates with whether one is able to embrace thinking semantically about texts. Personally, I have found this to be a fun and thought-provoking challenge. The physical description of a manifestation of that text is separate and secondary. Coming from Biblical Studies, I thought of biblical books as divided into a hierarchy of book, chapter, and verse. TEI taught me to think of those secondary markers as milestones, that were added centuries later by people who did not necessarily understand the literary structure. Similarly, a manifestation of a text in a codex divided into page, column, and line is not the essential nature of the text. The XML necessarily follows a single hierarchy, which in literary semantics might be division-paragraph-sentence, or division-stanza-line. It is true that the semantic hierarchy creates challenges when one does wish to visualize the physical manifestation of a text in pages, columns, and lines. Those features can be coded with non-hierarchical elements and rendered as one wishes by way of XSLT.
2.3. How Integrate TEI and IIIF?
If we can agree that TEI XML is the most capable format for a single-authority workflow
and that a humanist can be reasonably expected to use it, the next question becomes
how to derive IIIF from TEI.
Some parts of this are surprisingly easy, while others might be surprisingly challenging.
The part I found surprisingly easy is that the TEI Guidelines already include fundamentally
equivalent categories under different names.
Almost all one would want for a IIIF Presentation Manifest falls under teiHeader or facsimile.
Under facsimile, TEI calls a surface what IIIF calls a canvas.
Each surface can be described by many graphic elements, which is essential for the layers functionality.
All the annotations I would want to link to the Presentation can be expressed with
the elements line and media.
Because I want to draw from the text transcription for the annotations, I use the
xml:id, facs, and corresp attributes to link text and facsimile.
Conceptually we’re off to a good start in drawing from the TEI Guidelines to populate
a IIIF Presentation manifest without any loose interpretations of the guidelines.
So the next question is how to translate the TEI concepts to the IIIF concepts. The main categories are the “homecooked” options and the platforms and virtual research environments I will address following. By “homecooked” I mean relatively short bits of code that a humanist or collaborator might adapt for a specific project, without trying to anticipate every possible use case. I could say more about Python in the discussion if there is interest. Overall, I would say that XSLT is more approachable for my students and the average humanist. It is particularly elegant for rendering HTML, and plain text and JSON output is also available. XSLT is sufficiently capable of translating a single TEI XML authority into quite a few visualizations. My code, which is available on GitHub, has one transformation for PDF by way of Latex, another for the hypertext edition, another for the Presentation Manifest, and another for the Open Annotations in Mirador.
3 An example of a powerful but intimidating implementation of XSLT to TEI is the TEI Consortium’s Stylesheets.
2.4. Why Streamline?
The alternative to the homecooked approach is the approach of building a platform or research environment. The homecooked approach modifies simple recipes as needed for a specific project. The platform approach tries to anticipate the needs of many projects. The homecooked approach uses the simplest tool possible with the hope that a humanist can tinker directly with simple code. The platform approach requires a clear separation between a complex backend and a graphical user interface. I very much appreciate that different approaches may be suitable for different people and different projects. My preference for the homecooked approach, what I think of as streamlining, is connected to my broader interests in minimal computing. As I said last year at the meeting of the Association for Computers and the Humanities, as a teacher I am less concerned with what is hard or easy to learn, but what is most worthwhile to learn. The tools and skills most worthwhile are those that are reusable. Learning how to use a text editor, TEI XML, and XSLT has been very useful to me on many projects. Learning a new platform strikes me as much less reusable, even if it does accomplish the immediate task. In my experience, the platforms that try to anticipate every use case do not succeed.4 Customization is either impossible or more complicated than it would have been to modify a simple recipe. I praise open source software on all scales, but not all open-source software is open to me to adapt using the resources available to me.5 Taking a minimal computing, streamlined approach has benefits in control, sustainability, and accessibility.
4 For example, one major platform that boasts support for TEI and IIIF makes the assumption that a facsimile of a page is a graphic. That does not work for me because many graphics contained within a surface element are necessary to represent a page.
5 Marjorie Burghart’s TEI Critical Apparatus Toolbox exemplifies how a project can both have ambition to serve users without exposing code and also make code available for customization. While the web interface she developed does not suffice for my needs, I borrowed greatly from her XSLT code for transforming TEI to Latex.
2.5. Conclusions
I will close with reiterating three conclusions I have drawn from my journey. First, TEI is my friend. I believe its complexity is justified and most humanists should be able to learn the portion of it that applies to their work. However, it is important to embrace the fundamental concept of a semantic hierarchy.
Second, in order to fully embrace the distinction between semantic description and visualization, it is helpful to learn XSLT at least enough to modify the visualizations of others.
Third, I believe my use case illustrates the value of minimal computing. A habit of seeking the most reusable tool for the job gave me control to apply a concept to my use case, a use case that I would not have expected others to anticipate. I completely understand that other projects may have different resources and needs. I hope others will be able to learn from my journey.
Thank you.
