Converted from an OASIS Open Document
Collaborative editorial projects creating new text corpora from digital images face a problem directly relevant to the conference theme of interdisciplinary perspectives on data: how can we simultaneously support the widest possible range of contributing editors with minimal technical demands, and thereby draw on the expertise of diverse participants, while ensuring the quality of the resulting edition? We identify requirements for a rigorously curated digital edition, and present a new solution using Pluto notebooks to provide a configurable system for automated validation and verification.
We illustrate validation using Pluto notebooks in the Homer Multitext project, a decades-long initiative involving hundreds of contributors; one- and two-year undergraduate research projects on Latin manuscripts and Lycian epigraphic texts; and a one-day “manuscripts hackathon” where scores of secondary-school students and teachers with no prior experience of editing successfully produce a machine-validated edition of part of a Latin manuscript.
The projects we illustrate share demanding assumptions about digital editing. Teams of collaborators create editions canonically citable by CTS URN. All projects require that editions be backed by canonically cited visual evidence. But each project has specific requirements that need to be machine validated and verified by human reviewers using machine-generated visualizations.
1. Citation and markup scheme. While the projects we
discuss all encode their texts in TEI-compliant XML, differences in their
content dictate that they each use a different subset of the TEI, with canonical
citation encoded differently. We must support arbitrary markup schemes (not
limited to TEI vocabularies), and validate that editions in any specific markup
scheme can be transformed into an independent model of an ordered hierarchy of
citation objects.
2. Indexing citable texts to citable images. Projects associate a CTS URN for each text passage with a CITE2 URN for an image illustrating the passage. The syntax of URN notation and the referential integrity of the indexing must be validated, a task that can only be reliably done by machine. The accuracy of the indexing can be assessed with a computer-generated visualization juxtaposing transcribed text with the associated region of the image; the completeness of the indexing can be evaluated with a visualization highlighting indexed regions on the source image.
3. Character set and classified tokenization. All projects
explicitly define an orthographic system identifying a valid set of characters,
a valid set of token types (e.g., punctuation or lexical tokens, but Akkadian
might include types for determinatives or Sumerograms), and a method for
analyzing a text as a sequence of classified tokens. Texts in different
alphabets obviously require different orthographic systems (Latin, Greek,
Lycian), but we can more specifically tailor systems for texts in the same
alphabet (Latin texts using distinct u/v and i/j for vocalic/consonantal values
vs. texts using a single u and i, or Greek texts with mathematical or
astronomical symbols that do not appear in literary works).
4. Multivalent sources to analyzable editions. Any XML document using the TEI choice element is multivalent. We generate multiple univocal editions appropriate to different contexts of use or analysis. We compare cited images to a pure diplomatic text for example (above, no. 2), but use a normalized text when projects analyze morphology.
5. Other project-specific requirements. Projects may need to validate project-specific information. Some identify particular categories of named entities using specific authority lists. Others relate texts to non-textual or graphic features of their documents. We require a system that can be readily extended to support the further prerequisites of individual projects.
Since 2014–2015, the Homer Multitext project has used project-specific software (Mandatory On-going Maintenance, or MOM) to address these needs. Rapid iterations of editing-evaluation cycles let teams quickly identify problems. They can immediately test whether their attempts to resolve issues are correct. Especially for newcomers with no prior background, MOM accelerates the learning process, at the same time that it guarantees that editions meet specified standards.
MOM’s effectiveness has been limited by technical requirements, however. It was first distributed using virtual machines, and later via Docker images. These are resource hungry, and not always easy to install on older hardware. Virtualization further imposes on editors the cognitive shift of managing multiple environments, with editing in one OS, and validation in another. Modifying the software and getting updates into the hands of editors was burdensome. MOM was not easily extended to other projects.
These obstacles vanish in cross-project Pluto notebooks for validation due to three features of Pluto: (1) its minimal technical prerequisites, (2) reactive architecture and (3) flexible configuration through metaprogramming.
Pluto requires only the Julia programming language (available in simple package installers) and a web browser to interact with notebooks. Like Jupyter notebooks, Pluto lets you mix text and executable code, but instead of linear execution from top to bottom, cells are related in a dependency graph. Like a spreadsheet, when a cell is changed, related cells instantly update. Editors keep a validating notebook open in a web browser next to a text editor; as they revise their work, clicking a “refresh” button in the notebook recalculates for any changes. Since Pluto notebooks are just Julia scripts, updating a notebook is as straightforward as updating an old script to a new version.
Julia’s metaprogramming makes it easy to plug in project-specific solutions to the prerequisites listed above. To tokenize a text, for example, teams list in a configuration file an implementation of a Julia OrthographicSystem appropriate for their text. Their Pluto notebook evaluates and executes the expression when tokenizing their text. The flexibility and power of metaprogramming are the reason why we can use identical but individually configured notebooks to validate projects with very different requirements.
Our presentation will illustrate our use of Pluto notebooks in a work flow we have developed for collaborating remotely during the pandemic. We will show how using only Visual Studio Code and a Pluto notebook, we can fully satisfy the requirements discussed above across the full range of projects we illustrate.