The Papyrological Editor

History

The history of Papyri.info is described in a variety of publications (Sosin 2010; Babeu 2011; Baumann et al. 2011; Baumann 2013; Reggiani 2017; Cayless 2019). This platform is the result of three Mellon Foundation-funded projects titled Integrating Digital Papyrology (IDP) which ran from 2008 to 2012. In 2010, both components of Papyri.info (PN and PE) were formally launched during the 26th Congress of the International Association of Papyrologists (Sosin 2010).^*

The IDP projects aimed to gather multiple databases with overlapping papyrological content and make them accessible and editable through one common online platform. The first databases integrated into Papyri.info were the Duke Databank of Documentary Papyri (DDbDP), a textual collection of edited documentary papyri encoded in TEI; the Heidelberger Gesamtverzeichnis (HGV), an XML collection of metadata pertaining to documentary papyri combined with a further database of XML translations into modern languages; the Advanced Papyrological Information System (APIS), a metadata repository for papyri collections primarily located in America. These were completed by the addition of the Digital Corpus of Literary Papyri (DCLP), collecting TEI-encoded text and metadata concerning literary and paraliterary papyri, and a bibliographical database building on a copy of the Bibliographie Papyrologique (BP).^* In addition, Papyri.info also displays data from Trismegistos, another database collecting metadata on texts from the ancient world, although the latter cannot be edited through the PE.^* The Trismegistos numbers attributed to papyri (Depauw and Gheldof 2014) serve as stable identifiers to crosslink the databases.

The model behind the conception of the PE is Suda On-Line (SOL), a project to crowd-source the translation to English of a 10th-century Byzantine encyclopedia called the Suda, pioneering in combining data openness with editorial vetting. The editing environment was therefore named Son of Suda On-Line (SoSOL). The PE is an instance of SoSOL (Baumann 2013, 104), and SoSOL is the ‘bundle of services’ conceived as a reusable environment. The reusability of SoSOL was demonstrated in the Digital Corpus of Literary Papyri, a project that terminated in the late 2010s and is now integrated into the Papyri.info environment.^*

Author(s)

Although the conceptual inspiration of SoSOL is clear, correct authorship attribution of the PE is not as straightforward. We have chosen to highlight Ryan Baumann, the main contributor of the SoSOL code in the GitHub repository and author of the peer-reviewed article describing SoSOL and its functionalities (Baumann 2013). He was not working alone, but it is less obvious who to credit as co-creators of SoSOL among the various collaborators of the IDP. The proposal for the IDP2 project mentions the University of Kentucky’s Center for Visualization and Virtual Environments (VisCenter) as the group responsible for SoSOL. The About page of the DDbDP gives the names of Charles Carpenter and John Fox as members of the VisCenter. The Digital Classicist Wiki entry for the PE lists Hugh Cayless as a co-author to Ryan Baumann. However, it is likely safe to assume that most scholars involved in IDP2 may have contributed more or less to the creation of SoSOL, whether from a technical or conceptual perspective.

Editorial Tasks

The creation of the PE was motivated by the need to maintain and keep up to date the databases gathered in Papyri.info, particularly the Duke Databank of Documentary Papyri, which lacked financial resources (Sosin 2010; Cayless 2019). Moreover, it aimed to democratize the management of a dataset that ultimately belongs to the community. The crowd is therefore involved in helping to maintain the material on Papyri.info and keeping it up-to-date with the scientific consensus.

The editorial tasks carried out vary in scope: correcting existing transcriptions and metadata, adding new material retrieved from academic publications, or directly publishing new scholarship. In the first case, the corrections may be relatively small, such as adding missing words to the transcription or updating the link to an online facsimile. Adding new material from academic publications includes incorporating a new conjecture from an article or creating new XML transcription files for newly edited papyri published in a volume or article. New scholarship in Papyri.info mainly takes the form of corrections to existing transcriptions, except that these corrections have not been published elsewhere.^* In the past, some experiences with native digital editions have also been made (Berkes 2018), but this practice is rare and will not be the subject of this review.^* All three forms of editorial tasks undergo peer review from a board of editors before being integrated.

Users of the PE

Although anyone can register to the PE, knowledge of Greek papyrology and either the EpiDoc standard in XML or the Leiden+ syntax (see below) are necessary to contribute to Papyri.info. The full list of PE users is available.^* There are 5,259 registered users as of June 21, 2024. However, this list contains roughly 1,200 suspected spam users whose names are composed of random letters, and many duplicates. Through the Git repository, we gain a better view. There have been a thousand active users since the inception of Papyri.info, and the 100 most active are responsible for over 97 % of the modifications. Again, there are duplicates in this list since scholars may have contributed from different accounts created at different times.^* In fact, the number of active users is rather small compared to the amount of work required to keep it truly up-to-date. New volumes of edited papyri are published each year.^* Moreover, additional corrections and editions regularly appear in journal articles. There can also be errors in the data due to the conversion to EpiDoc XML from the original DDbDP and HGV databases, and their correction also relies on the community of PE users.

Leiden+ and EpiDoc Syntax

Using Git is not the only innovation of the PE. The transcription interface for XML editing, based on the Leiden+ syntax developed expressly for the SoSOL, impacts users even more directly.

The Leiden+ is inspired by the Leiden conventions for editing ancient texts. Its developers aimed to offer a user-friendly alternative to XML editing for PE users, encourage participation in the crowdsourcing effort with an easier-to-learn system, and, therefore, bridge the gap between traditional and digital papyrology.

The original Leiden conventions provided guidelines for indicating special features of ancient texts in editions: for instance, lacunas, missing letters, additions, and abbreviation expansions; they are widely used in editions of papyri and are common knowledge for papyrologists who use print editions in their daily research.^* However, when these same texts are encoded in XML, they follow the standard EpiDoc, a subset of the TEI used for ancient documents. The Leiden+ syntax bridges the gap as it imitates the traditional Leiden while enabling an automated generation of the XML version of the data through XSugar.^* As the Leiden Conventions also encompasses other publications such as epigraphic editions, the Leiden+ syntax is reusable in other projects, and indeed, a subset of the Leiden+ has been reused for the online version of the Supplementum Epigraphicum Graecum. A comparison between a Leiden and a Leiden+ edition of a text makes the relationship between the two systems immediately visible (Fig. 1).

Nicola Reggiani (2017, 232–40) presents a more in-depth discussion of the main differences between Leiden+ and its XML equivalent: the Leiden Conventions and Leiden+ system consist of a descriptive syntax, while the XML markup is semantic. For example, a lacuna is always indicated with square brackets in Leiden systems, whereas in EpiDoc, it may be rendered with either <gap> or <supplied> element, depending on whether the editor attempted to render the text of the lacuna or not. Consequently, semantic errors are not detected in Leiden+. This difference means that users may produce valid Leiden+ syntax, for instance, for a lacuna, which the papyrological editor may not transform into the semantically correct XML.

The Leiden+/EpiDoc conversion is subject to minor bugs. For instance, correct XML indicating ancient diacritics over dotted letters (e.g., <hi rend="diaeresis"><unclear>ἀ</unclear></hi>) is not converted into correct Leiden+ indicating the same feature (e.g., “ἀ̣ (¨)”). This conversion problem results in broken documents that users can no longer edit in the PE Leiden+ interface. Editions with such combinations can only be properly edited in the XML version of the data.^*

Leiden+ and EpiDoc Transcription

The need for user-friendly interfaces for XML transcription is not limited to papyrology. Various solutions have been developed over the years, from the “author mode” of the oXygen XML Editor to the more recent editors LEAF-Writer^* or FairCopy^*. In New Testament research, the Transcription Editor^* plays a similar role to the Papyrological Editor, as a tool meant to facilitate the collaborative effort of transcribing a relatively homogenous corpus by a community of researchers. The Transcription Editor offers buttons to include XML elements in the text and pop-up windows to fill the metadata needed for the XML elements and attributes (Fig. 2).

The interface of the PE also offers buttons to include XML elements within the transcription (see Fig. 3); nevertheless, the main difference and innovation between the PE and other editors remains the use of the Leiden+ syntax in synchronization with EpiDoc XML. Once mastered, using Leiden+ facilitates the transcription process, making constant button clicks to include tags and attributes unnecessary. In that regard, the PE takes advantage of the existing formalized syntax well-known in the research community, the Leiden Conventions, to help create the XML transcriptions. Without this valued feature (Borcea 2022), it is unlikely that participation in the collaborative editing effort would be as high as it is (Sosin 2010).

Access and Home Page

The sign-in process requires the user to log in or register with a Papyri.info account or through a Google account. There is no assignment of rights or user agreement. Newly logged users may start contributing immediately.

Once the user has logged in, they will land on their home page or dashboard, which gives an overview of the user’s work (Fig. 4). Contributions to the database, called publications, are divided into four main categories: New, Editing, Submitted, Committed, corresponding to the various phases of the editing and reviewing process. Work in progress appears under “New” if it concerns an entry not yet existing in the PN and under “Editing” if it concerns an existing entry. In both cases, the entry will appear under “Submitted” after submission to the editorial board. The editorial board then takes the relay; if it approves a publication, it will integrate it into the system - the publication is now under “Committed”. If the board refuses the publication, it will send it back to the user, who will find it again under “Editing”. If the list of committed entries becomes too long, it is possible to archive them through the “archive all” button.^*

For each publication, the dashboard presents a row of links allowing access to the various parts of the related data. The first, “Publication”, leads to the overview page (Fig. 6), where it is possible to look at the comments that inform the editorial history of the entry, to delete, submit or withdraw from the editorial review the specific publication, and to download a copy of the XML data composing it. The other links lead to the respective database entry for the same papyrus — DDbDP Text, HGV Meta, DCLP Meta, DCLP Text, Translation, Biblio, and APIS. This specific data structure comes from the original aim to merge data originating from various projects. It informs not only the user dashboard but the entire structure of the Papyri.info website. Each of these corpora can be edited, but most users will focus on Text and Meta entries, so these will be at the core of this review.

Through the user page, accessible from the top right corner of the home page, one can edit user information and access the usage stats. Users with a Google account can create a password to switch to a username-password account.^* The activity statistics of all users is accessible through the “usage stats by user” link. For each user, it is possible to know whether they are a member of one or more editorial boards and which publications they have submitted, voted upon, or finalized. However, there is no list of the members of the various editorial boards who are allowed to vote upon individual submissions — such information would further increase the transparency of the peer review process.

Creating a Publication

Each papyrus in the PN has an “open in editor” button that creates a publication, i.e., a copy of the data retrievable through the user dashboard that can be modified and submitted to the editorial board for review. If the entry does not exist yet (for instance, if the user wants to add to the database the text of a papyrus recently published in a journal article), then the dashboard page includes an “Advanced create” button (Fig. 5) that leads to a “Start a Publication” page. This page offers the possibility to create a new publication from scratch (Fig. 5). Knowing the structure of the database facilitates the process: it is possible to create a DDB publication (an entry for a documentary text, which can include HGV metadata, DDbDP text, and translation), a DCLP publication (composed of DCLP Meta, Text, and possible translation), an APIS entry or a Biblio entry.

The newly created publication leads to the overview page (Fig. 6), which is the same overview page accessible from the dashboard (see above). The structure of the publication can be found at the top left of the page; a simple entry will only contain the tabs Overview – Text – Meta. APIS and Translation appear when relevant, and papyri that have been re-edited will include one Text + Meta combination for each of their re-editions.

The overview page also allows users to expand the existing entries to other IDP databases. For instance, it is possible to create a DDbDP textual entry for an existing HGV one or a translation for an existing DCLP or DDbDP. This is possible through the “create new” links at the bottom of the overview page (which is slightly ambiguous as they do not create a new entry, as with the Advanced create button, but an entry crosslinked to the one the user is working on; Fig. 6). At the bottom of the overview page, the user can download a copy or delete the publication; a deletion will only delete the user’s copy of that publication, and not the database entry of existing papyri.

Editing a Publication

Most of the work will be done in the “Edit” tab of the “Text” and “Meta” tab. The preview option gives the user an approximate idea of the final result and helps check the data before submission. For textual entries, the “Commentary” tab also allows for adding editorial comments to specific lines of text.

Every time the user saves their modifications, the save button parses the Leiden+ and converts it into an EpiDoc XML. If the text was correctly encoded, the PE will display a green bar, save the data and allow the user to submit the publication to the editorial board. If there are mistakes in the code, the PE will display a red bar and indicate to the user where in the text it could not correctly process the Leiden+ by marking it as “*POSSIBLE ERROR*” (Fig. 7). Until the problems have been solved, the user cannot submit the publication. Although intimidating, this function is essential in ensuring that only correctly encoded data enters the system. It also helps users by giving them feedback.

Submission and Review of a Publication

From the overview page, the user is able to submit the completed publication for review to the editorial board, with a comment explaining the proposed modifications and the reasons behind them. This comment will not only be available to the editorial board during the voting phase but also be integrated into the XML entry of the data and retrievable for every future user. It is always possible to delete a publication as long as no editor has voted on it. Afterwards, the user can only wait for the voting and committing process.

Each submission undergoes editorial scrutiny; the practice of the editorial board requires only one vote to send to finalization or reject proposals related to the maintenance of the database and at least two votes from two different editors for new scholarship. Each editor’s vote is associated with a comment that, in addition to guaranteeing the transparency of the editorial process, functions as a space for discussion among editors and as a source of feedback for users.

Learning Curve

The system is conceived to make machine-readable data entry as human-friendly as possible. For metadata, the users interact with a very standard form; an example may be the entry form for HGV data (Fig. 8).

For the text, however, users have to learn either the Leiden+ language or EpiDoc XML to fully engage with the PE. Papyri.info integrates a help page, accessible all the time on the top right of the website, and provides a menu bar to help users correctly code in the language (Fig. 3).

For textual entries, the Leiden+ help file furnishes reliable information on how to encode the data, and the POSSIBLE ERROR feature of the automated Leiden+ verification indicates where mistakes must be corrected. More generally, the editorial comments give feedback on the quality of the entry. For instance, when users do not know how to enter some data correctly, they can always mention it in their commentary field to leave the editorial board correctly encode the data; conversely, editor comments indicate corrections to be done to the entry that users can read to learn how to improve their future entries.^*

According to some feedback by colleagues, the comments field and Leiden+ help page are insufficient to build confidence in the user. The complex structure of the data and the website, with multiple interrelated databases each accessible through multiple paths, can be overwhelming for newcomers. The overview page, for instance, changes according to the status of the publication (New/Editing/Submitted/Commited). The help page concerns only one part of the system, and the comments arrive late in the process. Moreover, the EpiDoc encoding and the internal practice in the PE may evolve faster than the examples on the help page. This fact increases the difficulty of learning by example.

Therefore, the creation of online tutorials for beginners on how to approach the website would be much appreciated, and existing tutorials, such as the SunoikisisDC class (Bodard, Vannini, and Vierros 2022), could be better highlighted. FAQ or forum pages, where one could ask specific questions, may be helpful too, although they are resource-consuming. Moreover, some initial training from more knowledgeable users is often necessary. Trainers can introduce users to the syntax of Leiden+ and give hints on how to properly encode text. They can also share some insider knowledge on how to fill the entry forms. A typical learning curve, therefore, is composed of a first introduction to the system through formal training, followed by a phase of trial and error through which familiarity with it develops. It may take some time to fully grasp the system, and some users abandon the PE during the learning phase.

A special mention should be made of the form used to create a bibliographical entry. It is incredibly complex, to the point that without guidance, the average user cannot learn how to enter the information correctly. Even with training, it is easy to forget where each piece of information should go. Some fields tend to bug, such as the Publisher – Name and Publisher – Place entries, that systematically duplicate the information in the XML. Both reviewers have ended up directly editing the information in the XML file, as this is easier to understand. However, this is a minor criticism, as the addition of bibliographical data does not belong to the usual tasks of PE users and is mostly done by experienced users directly in the GitHub repository.