New Tools and Database Models for the Study of the Architecture of Complex Manuscripts

Patrick Andrist, University of Munich

Structural codicology is the name recently given to a branch of codicology focusing on the structure of ancient and medieval codices using a holistic approach.* It was founded by Peter Gumbert, who theorised this approach around the now often used (and sometimes abused) concepts of “codicological unit” and “bloc.” Although Gumbert was certainly not the first scholar to be interested in the structure of the codices, [1] he first proposed a method for describing codices around their historical “building blocs” and established a complete system and terminology to analyse them along these lines in 2004. [2] In the years following this publication, I had the pleasure to work with the late Paul Canart and Marilena Maniaci to build on Gumbert’s work (in dialogue with him) and to publish our Syntaxe du codex in 2013. [3]

One of the ambitions of structural codicology is to create manuscript book descriptions which reflect both the historical layer and the internal architecture of codices. Several projects of printed catalogues have (directly or indirectly) shown awareness of the work done by Gumbert and ourselves and produced so-called syntactical descriptions of manuscripts, i.e. organised around the main historical layers of the codex. [4] For electronic manuscript descriptions, several websites do allow for (for example, e-codices) or encourage (Pinakes, Beta maṣāḥǝft to name but two) the creation of descriptions organised along these lines. [5] The recently released web site Manuscripta Biblica of the Paratexts of the Bible project is, to my knowledge, the first public interface where all the full descriptions strive follow “syntactical” principles. [6] However, as explained below, none of these platforms are presently able to represent the internal architecture of codices, not to mention the possibility of visualising them in different ways, or to exploit the information about their structure using other tools or functions. [7]

Since overcoming these limits, not just in order to visualise more meaningful descriptions but also to develop dynamic tools around them, has been one of my preoccupations for a long time, I took the preparation of an interdisciplinary project on antique and medieval biblical manuscripts as an opportunity to discuss some of my ideas with a working group of manuscript and digital humanity specialists, which met at the LMU University of Munich in 2019. [8] Our intention was to think about a new database with which we hope, among several goals, to compare codices from various cultural areas by taking into account not only their contents but also their physical makeup and their overall architecture.

This paper continues the reflection on some of the points discussed in our working group. It presents some of the goals for new features and tools and their functioning (potentially in a public Virtual Research Environment). It advocates for the development of a new generation of databases whose data model allows for developing these descriptions and tools. We will frame our paper by outlining four “theses” concerning this new generation of databases on ancient manuscripts.

All these programmatic reflections are presented as a contribution to the realisation of the database aspect of the above-mentioned comparative project once it has received the requested funding. [9] However, ultimately, such tools may be of interest for anyone studying the materiality and the structures of ancient manuscripts.

Today, most manuscript databases allow for descriptions to be visualised in only one way, which corresponds to the decisions of whoever conceived the database, the public interface designers and sometimes also the cataloguers. If the designers decide that the information about the content of a codex is displayed first and the quires are described at the end (or not at all), there is not much the user of the database can do to change this.

What’s more, in most cases, the way the information about the manuscript is organised in a description (i.e., the description model) is simply a reflection of the way the data is organised internally in the database (i.e., the internal data model). For example, if for a single manuscript, a database has all the texts described in one dedicated table (or under the same <ms_contents> tag), and at the same time, it groups together all the scribes in another dedicated table (or under a <handDesc> tag at the same level as the content tag), the readers will usually see a description in which all the texts are displayed together, then all the scribes and so forth.

The solution we envision for this limitation builds on the ability of computers, contrary to printed material, to differentiate to a large extent between the data itself and the way this data is visually organised. Thus, there are no reasons why a new generation of databases should limit the display of a manuscript to one unique description model per set of internal data. It should rather provide the users with the option of choosing between various models, based on the same set of internal data, and leave the door open for creating and integrating new or improved ones, such as the ones that will be presented below. [10] To continue with the example from the preceding paragraph, the user should be able to choose to display the texts according to their scribes (or the inverse), or to go back to the traditional model in which the information about each feature is presented separately.

Secondly, within each description model, users should also be able to decide which information is displayed, and in which order, and also in which order the entries should be arranged. This is already possible in many applications outside the realm of manuscript studies. For example: if, to begin with, users see a description in which the contents of the manuscript are displayed in a tabular form (e.g., author, title, incipit etc.), they should be able to decide which columns are displayed and which ones remain hidden, their size and their order. The presence of these types of functions might seem rather basic and self-evident (to the extent that one might wonder why they are not available in current database interfaces) but it is a regrettable fact that many database projects operate on small budgets that limit how much they can offer users.

The first theoretical implication of this goal is that the description models should, as much as possible, remain disconnected from the data model. The internal data model should be designed in such a way that it is easy to generate differently structured descriptions based on various description models.

Before presenting this central tool for the study of complex manuscripts, it is useful to recall some concepts about the architecture of the ancient codex by considering, as a single example, the codex Vaticanus of the Bible. [11] Diagram 1 below presents my interpretation of this codex (i.e. the way I understand its main historical layers and its architecture), [12] but I would like to note that other people, focusing on other aspects of the codex, might come up with other ways to understand its architecture. In this codex, I see four main structural levels:

• two main Production Units (UniProds) consisting of all the folios copied in the 4th cent.
  on the one hand (= UniProd A), and on the other hand, all the folios copied when the codex was restored in the 15th cent. (in yellow on the diagram; = UniProd B); [13]
• inside the original UniProd:
  a. two modular discontinuities (the red lines in the diagram [14] ) dividing the codex into three Modular Units;
  b. six Unbroken Series determined by formal anomalies in the transition between two biblical books (the green lines);
  c. two minor discontinuities (the blue lines).

As Diagram 1 below illustrates, one of the main results of this analysis is the identification of a major discontinuity, just before quire 49, between two Modular Units, two Unbroken series, two hands as well as two traditional collections of books of the Old Testament. This can hardly occur by chance, especially since the last quire of the ending of the Modular Unit (= quire 48) is irregular. In contrast to modern assertions which state that the codex Vaticanus is one of the two earliest Bible in one volume, the producers clearly made a book which could be bound into two volumes, and there is no evidence that it was not first organised in this way.

There are two other results worth mentioning: the first relates to the transition between the Old and the New Testament; it was important enough for the producers to stop an Unbroken Series at the end of Daniel, with two unusual empty columns, in order to begin Matthew on a new recto, but in the middle of the quire. It was not important to them to start the Gospel of Matthew at the beginning of a new quire. As a result, there was no possibility to bind the New Testament into a separate volume, or to insert paratexts before Matthew (such as the canon tables of Eusebius of Caesarea) without damaging a quire.

The second interesting result has to do with a similar discontinuity between Mark and Luke, which are separated with an unusual empty column. The research asks if this extra space should not be put in relation with the fact that the Vaticanus has the short ending of Mark. [16] Did the producers leave some space in order to copy a longer ending, in case the patron or a future owner wished to do so? It is not impossible, but it is also relevant to remark, on the one hand, that there is not enough space to copy the traditional longer ending and, on the other hand, that a similar unusual extra empty column is found at the end of Mark also in codex Alexandrinus [17] which has the traditional long ending. The reason for the empty space still awaits a better explanation, maybe in relation with some book producing traditions.

Today, as explained in the introduction, in spite of several progresses, no electronic description model exists that would allow for these structural layers to be shown, and much less any tool that would help in finding and defining them.

In order to describe how such a tool could work, I would like to explain how one arrives at such an understanding of the architecture of a codex in the traditional way. Methodologically, the best chances to obtain these results is by drawing a table in which the various features of the codex (and more specifically, the places where each feature changes) are set out in the columns. Then, one can analyse the concomitant discontinuities.

Let us take codex Bernensis 469 [18] as an example, because the table for codex Vaticanus would be too long for this article. In Diagram 2, each column contains information about one feature of the codex. Most importantly, it indicates where changes in the observed features are located; they are marked with a slash and an acronym: [19]

• the quires, which are the most important features for studying the architecture of any codex; [20] each quire is represented and numbered;
• the writing support, including changes in the types of paper (acronym “Mat”);
• the quire marks, including signatures and catchwords (acronym “Mq”);
• the quire types, i.e., series of quires with the same number of leaves, including the last quire, which may be shorter or longer (acronym “Ch”);
• the content, indicating where each piece of content begins and ends, and where fully or partially blank leaves are located (acronym “Ct”);
• the hands, including the scribes (if known; acronym “Mn”);
• the writing systems, for example, if all the titles are written in special characters and red ink, then suddenly they are written in normal characters and ink (acronym “Ec”);
• the ruling, in terms of its material execution (technique, system, method; acronym “Rg”);
• the layout, understood as both the grid which results from ruling (the ruling pattern), and the way it is used (acronym “Mp”).

These features constitute a significant part of the basic data about the codex and of its description.

Horizontally, the rows represent places in the codex. As a result, feature changes occurring at the same place are mentioned in the same row.

One quickly notices that all the features change between quires six and seven, as well as between quires seven and eight. Moreover, there are also some concomitant changes between quire three and four. It is important to note that the table does not directly show the architectural layers, but it points to where one ought to look for the relevant discontinuities between the layers, ideally directly in the codex. In this case, we find that Bern. 469 is made of three parts, which previously circulated separately from each other.

Preparing such a table by hand is a lot of work. But drawing a table and finding concomitant discontinuities, this is exactly the kind of thing a computer is very good at, provided it can access the relevant information.

I envision a process in three steps:

Additionally, the user should be able to display, use, publish or privately share the data according to any of their saved interpretations, or to the standard interpretation, as they wish.

Users would be able to “activate” one interpretation and see the new structure within the already existing description models (at least in the models that are able to show something of the structure of a codex); this also requires the creation of new models, in which all the discontinuities and all the layers can be visualised.

It also implies that structure-sensitive searches (for example, when there are dates involved) take the “active” interpretation into account instead of the standard one.

As a result, the process of visualising a description (or “using” the codex in any number of other ways) always occurs through the “lens” of a specific interpretation whether this be the “standard” one issued by the cataloguer or a new one developed by the user.

To facilitate these goals, the internal data model should be structured in two separate classes of data: on one side, the data which concerns the structure of a codex (the structure data) and, on the other side, the data describing the various features of that codex (the basic data; see Diagram 6).

Only when a user requests to visualise or use a description, are both sets of data joined in order to present the manuscript in a structured way. As a result, the users can be given the possibility to organise the description in various ways, potentially very different from the one of the cataloguer, to save their new perspective—i.e. to record a new set of structure data internally for the same manuscript without altering its internal basic data—then display the data, or use it, according to any recorded perspective.

As explained above, in these databases, the structure data (provided by the cataloguer or the user) act as a necessary lens between the internal basic data and the way this data is visualised and used. Thanks to these structure data, users can present their own vision of a manuscript and save it for later use and possible revision.

Moreover, the data model must allow for each user to create, save, and use many sets of structure data for the same set of basic data. We will return to this point below (see § 6 and the Diagram 6).

A first example of a tool our group discussed, though briefly, would help compare the content and the main structure levels of several codices. We take as our example here the Old Testament portions of three well-known biblical pandects, with an explanation of the diagram following:

The diagram presents the (main) pieces of content of each codex in the order they appear. The first particular feature of this diagram’s tabular presentation is that it shows whether a piece of content can be found in the other codices or not (marked with a cross « X »), and, if so, whether it is at the same relative position or elsewhere in the codex (marked with an arrow « ↓ », « ↑ » pointing to where it can be found).

The second particular feature consists of showing the possible physical discontinuities of each codex according to a given interpretation. In this case, it shows my interpretation of possible volume breaks (triple lines) as well as modular units (single lines) and unbroken series (dotted lines). Naturally, such a tool would be particularly interesting for any type of manuscripts containing the same series of texts, and not just for codicologists working on biblical pandects; one can think, for example, of manuscripts of Plato, or medieval fabliaux.

Again, it took a lot of time to prepare this diagram by hand, but it could have been done much more efficiently and precisely (and possibly interactively) if prepared by a computer using a database.

As another example of the possible uses of saved interpretations, our working group supported the idea, already mentioned among the objectives of the StruViMan project (see below), of a tool that would make it possible for a user to establish a graphic reconstruction of a lost manuscript, or of previous stages of a preserved manuscript.

As an example, let us think of two current codices (see diagram 5 below):

• codex A, which, according to a given user’s interpretation, is made of three parts: one part containing the Gospels of Matthew and Mark and produced in the 14th cent.; the second part containing the Gospel of Luke and produced in the 12th cent.; the third part, containing the Gospel of John, also copied in the 14th cent. by the same hand and in the same layout as part 1. The user thus identifies two UniProds:

• codex B, in which the same user also identifies three parts which can be analysed as two UniProds:

In this example, the user could reasonably think that UniProd 2 of codex A and UniProd 1 of codex B were originally produced together and were also part of the same original codex. The tool that I envision would then make them able:

1. to display both codices according to a description model in which the main parts of the codex and their main features are represented graphically;
2. to “create” an empty new codex C within the graphic environment;
3. to drag and drop the 12th cent. parts of Codex A and B into codex C (thus creating a hypothetical reconstruction of a codex) and to assign the empty spaces within codex C to whatever other content they may think was also part of it (and annotate these spaces if they wish). In this example, it could be two empty spaces at the beginning of C for the lost Gospels of Matthew and Mark;
4. to save the reconstructed codex in the database (basic and structure data) and use it like any other codex, including the possibility to modify it or define various interpretations.

Needless to say, the tool would not be limited to working with two manuscripts: theoretically, any number of manuscripts (including a single one, for exploring other possible stages of development in a codex’s history) could be used as a “source” for the reconstructed codex.

As far as the graphic visualisation of a codex is concerned, it is worth mentioning the tool called StruViMan, which is being developed at the LMU University of Munich with the specific purpose of both visually relaying the various UniProds of a codex on a single screen, as well as each of their respective contents. StruViMan generates a graphic representation on demand, on the basis of an underlying database description. [22]

As my “theses” above have underlined, the flexibility needed to build such tools implies not only that the data model should be disconnected from the description model, but also that there is a need to develop a new data model in which the data for a manuscript falls into two categories:

1. The basic data—the raw data, if you will—recording the plain facts about the manuscript; for example, this text begins on f. 20r and ends on f. 60v, the first scribe is Ephrem and he worked from f. 1r until f. 51r etc.
   I speak here of descriptive data, which should be as objective, precise and complete as possible, even though ultimately any recording of data about a manuscript or any description is always interpretative to some extent. [23]
2. The structure data, through which users can visualise their own interpretation of the basic data, according to their understanding of the historical layers and the production discontinuities of the codex.

As seen above, there is a one-to-many relation between a set of basic data and a potentially large number of corresponding sets of structure data, since (as we have said) every user should be able to create and save as many interpretations as they wish using the same basic data. Incidentally, an interpretation of a codex can thus be seen as the single result of a specific relation between a set of basic data and a set of structure data.

But let us take it one step further. As I just mentioned, basic data is always interpretative to some extent. We can now add that describing a codex is always a work in progress. There are times when a user has more and better information than the initial cataloguer, and there are other times when the user does not agree with the data given by the cataloguer, for example if they do not recognise the same scribe, do not agree on the dating, or read a detail differently.

Since my vision is built on giving the users as much flexibility as possible, it naturally leads to a further thesis:

The new data model must also allow each user to be able to enter their own basic data, as a complement or correction to the standard data (or any public data), but without replacing it, and to save, use and share their basic data if they wish.

The following diagram summarises the overall data model according to my fourth thesis:

Instead of a conclusion, I would like to briefly address three questions among the many that this essay leaves open. Firstly, as the reader may have noticed, this article does not make any recommendation about what kind of underlying database technology should be used. Should it be an XML/TEI database? A relational one? An RDF technology? Or should one try to mix the technologies, for example relational database with XML/TEI tolerant fields?

Our working group concluded that, from a strictly technical point of view, it is probably possible to build the tools based on any of these database systems, but the cost for building the tools, then using them efficiently, will not be the same. This is why we advocated a “scientific” approach or research-based approach towards finding the most appropriate technology: testing possible data model solutions on small-scale databases; considering other aspects such as the speed and potential of errors when inputting data, or the ease of sharing data and communicating them to other computers and so forth. An informed decision can then be made on the basis of these observations.

Secondly, how realistic is it to think these tools can be built? My answer considers only some aspects. The tools can only be created in the framework of a larger project with a secure source of funding. But they do not need to be created all at once. As we have seen, the tools to compare and reconstruct manuscripts are built on the tool that analyzes their architecture. Thus, the first step would be to set up a database according to the new principles and create this last tool, then the other tools, one after the other. The projects currently being planned at the LMU University of Munich represent a good opportunity to realize this first step.

The data model is new, but the data does not need to be new or newly inputted. Many descriptions in existing databases, based on standard description models, already contain the required data; and descriptions based on structured models not only contain basic data, but also information about the structure of the codex. Above all, it is a matter of being able to convert the data, if not permanently for a complete database, then at least temporarily for the data required for a given tool. Since computers are usually good at converting data when correctly programmed, this step seems also achievable.

Furthermore, once they are up and running, these tools do not need to remain at the local level. As a long-term goal and further step in the development, these tools (and other tools that could be developed by other people or in order to address other needs) could be integrated into a public Virtual Research Environment that could be used by any service or database, providing they can send their data in an interpretable format. The development of this VRE would be the main goal once the two first steps have been completed. But it might require a new project or a joint effort between various projects.

Overall the integrated database and tool might look like the following diagram:

Finally, let us remember that, no matter which cutting-edge new models and software are developed, the main challenge in any manuscript database is a human one, which will not disappear any time soon: there is only so much one can do with subpar extant data. As is to be expected, it’s a database, not an alchemical process that turns leaden data into golden ones. The maxim GIGO always applies: some might think this means “Garbage in – Gospel out.” But in reality, as you know, it means “Garbage in – Garbage out.”

This is why our efforts should not be concentrated only towards developing new software and electronic tools, but also into teaching, researching, critical reading, exchanging and tirelessly studying the manuscripts.

Having worked extensively with databases in the past, I am certainly not unfamiliar with the logistical and structural challenges involved in getting a project like this off the ground. Nevertheless, I am convinced this is achievable within a reasonable time span. Finally, I also hope this paper was enough to communicate my enthusiasm for what could be a big step forward into making manuscript databases active instruments, that are even more useful to the humanities.

(All the links mentioned below were accessed on June 2021.)