This paper proposes to detach TEI semantics - a widely accepted standard for the description of textual phenomena - from its hierarchical XML framework in order to integrate its descriptive structures into a digital scholarly edition (DSE) of Hildegard von Bingen's Liber epistolarum based on a knowledge graph enriched with provenance information.
The search for origins is a quintessential human activity. Scholars in the
humanities – especially historians – engage in this activity by examining
cultural artefacts such as texts, objects, and images. In so doing, they make use
of consensus-based techniques and methods, which enable a common
understanding of their findings once they are published, for example, in the
form of a critical edition. And yet these scholarly standards are themselves
subject to a constant process of alteration and development: historical
research is now increasingly permeated by digitization and the possibilities that
come with it. Digital technology has significantly extended the
methodological repertoire of researchers in the humanities, and the fact that scholars
are no longer bound to paper as a medium means that a rich variety of new
interpretative approaches have emerged – a state of aafirs that is clearly at
odds with Barbara Bordalejo’s contentious assertion that “there is no such
thing as digital scholarly editing”
The majority of today’s digital scholarly editions (DSEs) use the Text
Encoding Initiative (TEI) standard in combination with XML and its
inherent hierarchies, as it is widely considered to be “a well-documented format
for archival long-term preservation” which allows researchers to describe “a
large number of textual phenomena in general ways”
What I would like to propose instead is to model a DSE as a provenance knowledge graph which contains the entire critical apparatus, one or more transcription(s) and, if applicable, details concerning the relationships among them, as well as information on the origin of every statement. Describing textual phenomena (including the actions of the editor or editors) by means of TEI semantics has the advantage of maintaining semantic interoperability, as TEI is the established standard in the field. Moreover, TEI renders the connection between researchers and their work transparent. Made available in the form of a provenance knowledge graph, this crucial information in eefct turns research data into a collection of subjective decisions made by researchers – it is then up to individual users to decide how much they trust these decisions based on the expertise and academic profile of the scholar(s) in question. To manage this highly connected trove of research data, a labeled property graph (LPG) database can be used. With this groundwork in place, the next step will be to connect individual knowledge graphs either in part or in their entirety to a broader system of concurring and/or diverging statements and interpretations. 2
To better understand the desideratum articulated in this paper, let us consider the process of digitization in the field of medieval history, a development that has taken place in at least two distinct stages. 2.1
The first stage, which lasted until the end of the 1990s, was characterized by a
strong focus on image digitization. In Germany, one important protagonist
in the field was the dMGH project, in the course of which the volumes of
the Monumenta Germaniae Historica (MGH) were scanned, saved as image
ifles, and made accessible on the internet
By way of example, Figure 1 shows the scan of a page from the MGH with a transcription of a charter of Emperor Frederick Barbarossa. In most cases, these early attempts at digitization did not allow for text to be copied out of the images, but they were still a step in the right direction: a large amount of research material was made available to researchers even if the paper copies were absent from their library.
3On OHCO, see
With the advent of full text digitization, large-scale computer-based text retrieval from historical documents became a possibility, and this major improvement brought with it entirely new ways of scholarly exploration. 2.3
Today, we are facing the next important step: it is now time to focus on the entities in the text.
Identifying, annotating, and connecting these entities with data from authority files like GND or Wikidata enables the interconnection of individual research projects. It also becomes possible to model scholarly interpretations and the various steps of the research process in machine-readable statements – Section ?? will describe this process by example of a project dedicated to Hildegard von Bingen’s correspondence. 3 “Myths and Misconceptions
In a recent article,
“XML is broken or dead”
The first of these myths is that “the TEI is XML (and XML is broken or
dead).” As Cummings points out,
[t]he TEI Guidelines were first expressed in SGML as a markup
language and only as of TEI P4 moved to recommending XML, but even
this recommendation may change in the future
With SGML, there had been no problems with overlapping markup –
only with the shift to XML did overlap create the need for various
workarounds.4 On the other hand, however, the use of XML gave access to its
entire ecosystem, and XML was the rising star in the field of markup at the
time. Yet there is no reason why this arrangement has to be permanent:
4https://www.tei-c.org/release/doc/tei-p5-doc/en/html/NH.html
[A]s new languages, technologies, and methodologies for text
encoding emerge in future, the TEI Guidelines may move to them or include
them as one of a set of ways to serialize digital text, so as long as they
meet the basic requirements for easy long-term preservation,
expressiveness, validation, integration, and mass adoption that is seen with XML.
And this is precisely where our DSE of Hildegard von Bingen’s letters comes into play: its core principle is to employ TEI semantics without the hierarchical structure of XML. 3.2
At this juncture, I would like to share a personal observation regarding the
future of XML. When we started using the format in our project Regesta
Imperii Online in the early 2000s
There is a good reason why, in the broader field of software technology, XML is employed for purposes such as data exchange and the structuring of data in configuration files, but not for the sophisticated annotation of texts. Of course, publishers do use XML for their books, but these texts are nowhere near as deeply annotated as the ones that we are dealing with in the digital humanities today.
In fact, one could argue that the TEI community is in real danger of hitting a dead end, unless viable alternatives to XML are found in a timely fashion. 3.3
“XML (and TEI) cannot handle overlapping hierarchies”
Another myth discussed by Cummings is that “XML (and TEI) cannot
handle overlapping hierarchies”
To give an example, our graph-based DSE environment Codex
Customized annotation layers can easily be added to this list by the user. The substantial benefits of flexible, multidimensional annotation hierarchies in a DSE will be explained in detail in the following section. 4
In March 2020, a project based on the idea of using TEI semantics without the accompanying XML hierarchy was inaugurated under the title The Book of Letters of Hildegard von Bingen. Genesis – Structure – Composition.7 4.1
The transmission history of Hildegard von Bingen’s (1098–1179) letters has taken many twists and turns. Within this complex and convoluted story, the so-called Riesen-Codex [’giant codex’]8 – a book of letters (Liber epistolarum) which consists of brief epistolary texts arranged to form a cohesive theological whole (see Figure 4 – the beginning of each letter is marked with larger characters and red ink) – assumes a particularly prominent position. The reason for this can be explained by two separate, albeit closely related, aspects of its reception history: first, both medieval and modern audiences are unanimous in their verdict that the Liber epistolarum is of equal importance to Hildegard’s works of visionary theology; second, the Riesen-Codex can lay claim to the special status of a last hand edition, as it was compiled by Hildegard’s staf from the entirety of her correspondence during her own lifetime and in accordance with her wishes.
7The project is funded by the Deutsche Forschungsgemeinschaft (DFG) https://gepris. dfg.de/gepris/projekt/429863245?language=en 8https://tudigit.ulb.tu-darmstadt.de/show/Hild_R_Riesencodex
Our project is the first to present the Liber epistolarum in the form of a
digital scholarly edition. As opposed to the existing critical edition of
Hildegard’s letters
Our edition of the Liber epistolarum is designed to be as media neutral as possible, allowing parts of it to be printed in book form. The changes that the text underwent over time can be traced by means of a graph model, in which the genesis of the individual letters – from the oldest known version to the form that appears in the Liber epistolarum – is modeled on the basis of the pertinent manuscripts. By way of example, Figure 5 shows the interdependencies of the various versions of letter #52 found in manuscripts Z, W, M, Wr, and R.
While information concerning the evolution of the Liber epistolarum over
time is stored in a graph model, the texts of the letters themselves will be
transcribed in a standof property editor with the project name hildegraph.9 For
our purposes, standof property (SPO) means that the texts are annotated
on an index base, whereas TEI-based XML markup is mainly inline. The
technical outline of SPO is explained in detail in
The project began in April 2020 with a critical transcription of the text of the Riesen-Codex. As hildegraph was not yet operational at that point, the task was initially undertaken using an adapted version of the Leiden Conventions,10 a system that employs various types and combinations of brackets to express textual phenomena in plain text. Currently, we are working on the transfer of these transcriptions into the hildegraph environment with the aid of TEI semantics.
As noted above, our DSE uses TEI semantics without XML hierarchies
– in hildegraph, multiple annotation hierarchies can coexist in one system.
Table 1 shows a preliminary list of annotation types based on TEI semantics.
Here it is important to keep in mind that an annotation can be assigned to
multiple semantic spaces – Hildegraph is capable of managing several
indexing systems at once. For example, the first line in Table 1 shows that text
between lines can be identified both by Leiden annotation
leiden/supralin9hildegraph is derived from the Codex system described in
As the following example demonstrates, the process of translating annotations based on the Leiden Conventions into the SPO format by means of TEI semantics is not without its challenges. Figure 6 shows the end of one letter and the beginning of another:
This is the transcription of the corresponding passage according to the Leiden Conventions (transcription by Sr. Maura Zatony): ... neq(ue) odiu(m) alicui(us) p(er)sonę adtendemus! sed | solius iusticię respectu equitate(m) iudicare | proponimus. Description between lines margin note belonging to text extratext taedxdtitional
TEI <add place="above"> <add place="margin"> <add place="margin"> Explanation supra lineam in margine recensi manu start and end of column a-b corr. original spelling (transcription) in rasura (text located in an place where prior text has been erased) text is in another line
Type text text text text text text interpr. erased text (erased, text crossed out) rubricated text (words, text letters) resolution of abbrevi- interpr. ations empty space with missing text text start of line text Coding leiden / supralineam: orange text leiden / marginalia: purple text leiden / additional-text: ZPA leiden / column: EOC “//” leiden / correction: red underline leiden / sic: green underline leiden / rewritten: yellow underline leiden / transposition: pink underline leiden / strikedout: strike through line leiden / emphasis: styled in red leiden / expansion: styled in blue leiden / gap: ZPA: underlined white space : EOL “/” column visible correction corrected to/sic! <cb> <corr> <corr> <sic> <del @rend @reason><gap added on de- reason="rasure" leted text unit="line" quantity="2"/> <add @place> <del transposition cause=“moved“>
<supplied> sotrrusicmkilarout <rodeuentld”=>”striked
and rubrum expansion gap line <emph rend=”red”> <expan> <abbr> </abbr><ex> </ex></expan> <gap reason=“not readable“> <lb> \#52\# [ru[friderico imp(er)atori hildeg(ardis).]ru] | [ru[A]ru] summo iudice. hęc uerba diriguntur | ad te. Ualde admirabile est q(uo)d hanc || p(er)sona(m) homo habet necessaria(m)! scilicet quę | tu rex es. Audi. Quida(m) uir stabat in excel The manuscript’s red, or rubricated, characters and the capitalized ‘A’ are a signal to the reader that a new letter is about to begin. In the transcription, these parts of the text are represented by square brackets and the siglum ru: [ru[A]ru] (for Rubrum), whereas the characters in round brackets spell out the abbreviations used by the original scribes. As this system of annotation unequivocally marks which start element belongs to which end element, overlapping markup is possible.
But what is the best way to represent rubricated text by means of TEI elements? Which of the several options provided by TEI is the most promising? In an eofrt to find an answer to this question, we reached out to two TEI experts.
One suggestion was to use the <emph> element11 to highlight “words or
phrases which are stressed or emphasized for linguistic or rhetorical eefct,” 12
while the <rend> attribute could be employed to convey the information
that the text’s color is red. Here is what this approach would look like:
<emph rend="red">friderico imp(er)atori hildeg(ardis)</emph>
11https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-emph.html
12The rhetorical aspect reminds me of Zundert’s idea of a computational edition with
performative texts
In long discussions with various colleagues, no convincing arguments in support of the need for containment were put forward. There is simply no plausible need for it when it comes to accommodating diefrent annotation layers like layout or rhetoric: as our Hildegraph environment attests, all of these layers can be combined in various ways without the application of hierarchies. 4.3
“So what’s the text, then?” The brief transcription from the Liber epistolarum discussed in the previous section contains several expansions of scribal abbreviations employed in the original text. The use of abbreviations in manuscripts was a very common practice in the Middle Ages and posed few obstacles to contemporary readers. A modern critical DSE, on the other hand, is expected to provide an expanded and normalized version of the text for convenience and ease of reference.
But which version of the text should be displayed in Hildegraph’s plain text field? As a medievalist, I am inclined to argue that the version of the text that is as close as possible to the original should be shown in this prominent location; on the other hand, the expanded versions are much easier for casual users (and also for persons charged with maintaining the database) to read and understand. In the end, there are good arguments in favor of each of the two alternatives, and one of the major advantages of using SPO is that it does not force us to make a choice: as all versions can easily be converted 13https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-hi.html into one another, there is simply no need to decide once and for all whether the plain text to be indexed in SPO is the original or the normalized version – this decision can be made according to the specific requirements of the individual use case. 5
If we continue along this line of thought, the whole DSE can be conceptualized as a provenance knowledge graph, in which every piece of information is stored together with information on where it comes from, who made which statement and when, etc.
Broader scholarly interest in knowledge graphs began to arise when
Google discussed their own approach to the issue in a blog post, which
essentially described an enhancement of their search engine through semantics
without going into the technical details
At times, the term has simply been used as a synonym for ontology.
According to
Another common definition 14 is that a knowledge graph represents a collection of interlinked descriptions of entities (real-world objects, events, situ14See, for what-is-a-knowledge-graph.
example, https://www.ontotext.com/knowledgehub/fundamentals/ ations, or abstract concepts), while other scholars use the term to refer to any knowledge base modeled as a graph.
As if this confusion was not enough, none of these definitions say
anything about the technical specifications of a knowledge graph: some
explicitly mention RDF (Resource Description Framework)
The various concepts of knowledge graphs discussed in the previous section do have one thing in common: they treat information as objective truth. But in the field of the (digital) humanities, the ‘truth’ is always a matter of interpretation. The interpretative process begins the moment the very first characters of a text are transcribed. Each of the editor’s decisions is open to discussion and constitutes a subjective statement – and that is precisely the point where provenance comes into play. Once we begin to model a DSE as a knowledge graph that includes comprehensive provenance information, we end up with a huge amount of statements. Expressing all of this information in RDF would produce a huge and completely unmanageable graph, which is why we have opted to use labeled property graphs (LPGs) in our DSE. 5.3
LPG vs. RDF
RDF is a W3C standard for data exchange in the web that represents data
as a graph, and this is the most important point of commonality it shares
with LPGs. RDF structures information in triples in the form of
subjectpredicate-object, with the subject, predicate, and object being identified by
Uniform Resource Identifiers (URI)
The statement that Emperor Frederick Barbarossa was a human being would look like this: (Emperor Frederick Barbarossa)-(INSTANCE_OF)-(human)
Here is the same statement translated into URIs: Adding his place of death – Weingarten – would involve another triple:
In principle, RDF understands the world as a network of connected
entities and literals. Its popularity surged with the rise of the Semantic Web15,
which operates on the basic idea that users should publish data in structured
formats with well defined semantics so that this data can be ‘understood’ by
machines. Originally, this structured information was to be contained in
RDF triple stores16, a vision that soon evolved to quad stores which added
a named graph to each RDF triple. Today, the product of this evolution is
commonly referred to as “semantic graph database”
In LPGs, each node and edge not only has a unique and distinctive ID, but also a set of key-value pairs (or properties) that characterize it. Our example of Emperor Frederick Barbarossa and his place of death could be expressed like this: (e:Entity{type:'human', wikidataId:'Q79789'}) -[r:PLACE_OF_DEATH {wikidataId:'P19'}]-> (p:Place {label:'Weingarten', wikidataId:'Q572427');
When comparing RDF triples with an LPG, it is important to keep in mind that in the latter, nodes and relationships have an internal structure. In RDF, on the other hand, a triple is composed of two nodes connected by an edge (subject-predicate-object); the subject and the relationship are each identified by a URI, and the object can be another node or a literal, so that neither nodes nor relationships have an internal structure – they are merely unique labels. It is evident from this that an RDF graph could easily reach ten times the size of an LPG containing the same amount of information.
Another important diefrence is that RDF does not uniquely identify instances of relationships of the same type, nor does it allow instances of relationships to be qualified. In an LPG, the information is stored in the graph structure and in the internal structure of nodes and relationships. In RDF, all of this must be expressed in simple RDF triples.
In light of this, Hildegraph uses an LPG to store all of the information contained in the DSE as a statement, which allows us to explore and compare diverse (and potentially competing) interpretations. The provenance information – who made what statement when and where – is stored in the properties. Here, the versioning of graphs as discussed in Martina Bürgermeister’s contribution to this volume plays an important role.
The physical structure of the manuscript (and its relationship to its digital descendants) can also be modeled as a graph. In Figure 7, the main manuscript R is represented by the image in the upper part of the picture. This node is then connected to the folio nodes, which correspond to the individual folios that make up the manuscript, and which are connected by IS_FOLLOWED_BY edges that model the order of the folios within the manuscript. This part of the graph – or in other words, this subgraph – contains the information about the physical structure of the manuscript. One example of the usefulness of this information is a manuscript in which the order of the folios has been changed at some point – in a graph, both the original order and the new order can easily be modeled.
A TEI/XML-based transcription aims at expressing the layout structure of a manuscript with inline markup in one XML document. In Hildegraph, every distinct unit of text is assigned its own SPO node. The relationships between the diefrent text blocks are represented by means of IS_NEIGHBOUR_OF edges, which encode the visual impression of vicinity in the graph. In addition, the individual passages of text are linked to a corresponding image of the folio in question.
Figure 8 shows two lines of text (initium libri Epistolarum et orationum Sanctae Hildegardis) added by a later hand in the upper margin of fol. 328r.
With XML/TEI, this text would be contained in the main body of the letter in the XML document. In Hildegraph, the added text receives its own SPO node, and the two SPO nodes are connected with an IS_NEIGHBOR_OF edge (Figure 11). While textual information is thus stored separately from its visual arrangement on the folio page with all the benefits such an approach entails, the combination of text and layout can easily be examined if and when this is needed. Figure 9 shows the entire data model of Hildegraph. 5.6
Given the continuing lack of technical solutions for managing text directly
as a graph
Since SPOs are index based, one must select a base text for indexation. In practice, however, every version of a text can be used as base text because they can all be converted into one another. Indexing the base text makes every character of the text addressable – they are strung out like pearls in a long row, forming a chain of nodes in the graph which is given order by the direction of the text. All additional information is then connected to these indexed characters in a process that builds a bridge between the more transcriptionrelated sphere of the text and the predominantly semantic and interpretative sphere of the graph. In this regard, Hildegraph goes well beyond Witt’s above quoted proposition to model text as an ordered hierarchy of content objects (OHCO). 5.7
Another SPO is created whenever a user adds an annotation, which can then
be annotated again (most likely by another user) with yet another SPO, and
so on. With standof properties, every annotation is stored together with a
Globally Unique Identifier (GUID) and can be traced back to the user who
added it
Figure 10 shows the subgraph concerned with transcription and interpretation. The manuscript consists of letters from and to Hildegard. These letters are assigned one SPO node each, which are connected with IS_PART_OF edges to the corresponding folio nodes. A letter can belong to one or more folio pages, and may have a predecessor or a successor connected with IS_FOLLOWED_BY edges (See Figure 9). The red, blue, and green circles on the right represent metadata, layout, and semantic content of the letters. 5.8
Figure 11 shows how provenance is stored. Every information is connected to a node which represents the user who created the statement.17 In our example, the user Andreas Kuczera has transcribed a margin note. This 17Using TEI semantics, this information can be stored with <respStmt> ( https://www.tei-c. org/release/doc/tei-p5-doc/en/html/ref-resp.html, and <revisionDesc>. transcription is not stored in the SPO node of the corresponding letter, but rather in a separate SPO node which is then connected with an IS_NEIGHBOUR_OF edge to a zero point annotation in the letter text – it is this separate storage of transcription and allocation that makes the modeling of multiple interpretations possible. 6
By way of conclusion, I would like to return to the brief epigraph of my essay: “To which problem is digitization the solution?” From my point of view, digitization enables researchers to publish their findings with a maximum of lfexibility and transparency. Ideally, hierarchies should only be involved in this process when they are actually needed, and not because they are forced upon us by technological limitations. One of the fundamental properties of research data in the (digital) humanities is that it is highly connected, and I would argue that scholars should be granted the capacity to store every bit of information concerning these connections even if, for the time being, a standard or suitable ontology to express them might still be lacking. From a technical perspective, graph technologies can provide us with the capability to model multiple and multidimensional layers of information. TEI semantics could be another important piece of the puzzle, but their practical utility is dramatically reduced by the limitations of the XML hierarchies with which they are currently yoked together. As the Hildegraph environment shows, there is no reason why the problematic coupling of TEI semantics and XML should continue.
Epistolarivm.