1.1 Codierung von Unsicherheiten in der Lesart und von Lücken im Text

Die Text Encoding Initiative (TEI) bietet bei der Transkription von Texten verschiedene Möglichkeiten, zweifelhafte Lesarten auszuzeichnen und diese sowie damit in Zusammenhang stehende Informationen umfangreich zu dokumentieren. In diesem Beitrag werden zunächst die Elemente und Attribute zur Modellierung von Unsicherheit und Zweifel in der TEI dargestellt. Zentral ist in diesem Zusammenhang unseres Erachtens das Kapitel 11.3.3.2 Use of the gap, del, damage, unclear, and supplied Elements in Combination der TEI-Richtlinien,[1] wo deren kombinierte Verwendung erklärt wird. Im Folgenden liefern wir hier eine Zusammenfassung dieser speziellen Codierungsmöglichkeiten. Die Links in den Fußnoten am Ende jeder Einzelerklärung führen zum Grundeintrag des Elements in der Online-Dokumentation der TEI, worin dessen allgemeine Bedeutung und Verwendung beschrieben wird. Im Einzelnen gehen wir hier ein auf:

• <gap> ist ein leeres Element, das eine Lücke im Text kennzeichnet. Unter einer Lücke wird eine Stelle verstanden, an der durch Tilgung oder Schaden alles komplett unlesbar ist.[2]
• <supplied> umschließt einen editorisch ergänzten Teil, bei einer durch Tilgung oder Schaden komplett unlesbaren Stelle im Text (siehe <gap>).[3]
• <unclear> umschließt einen transkribierten Buchstaben oder Textteil an einer Stelle, wo noch etwas unsicher lesbar ist, aber ein Teil durch Tilgung oder Schaden unlesbar wurde.[4]
• <@cert> ist ein Attribut, das den Grad an Sicherheit bzw. Gewissheit bei der unsicheren Lesung (als Attribut von unclear) oder der ergänzten Stelle (als Attribut von <supplied>) beinhaltet.[5] In der Regel werden fixe Werte vorgegeben (high, medium, low, unknown).[6]
• <@resp> ist ein Attribut, das einen Verweis auf den oder die Edierende beinhaltet, der oder die für die Auflösung der unsicheren Lesart oder die Ergänzung verantwortlich zeichnet.[7]
• <@reason> ist ein Attribut, indem die Ursache für Schäden, Tilgungen oder Lücken dokumentiert werden kann.[8] Auch hier werden in der Regel fixe Werte vorgegeben.[9]

Da die TEI-Richtlinien die Verwendung von <gap>, <supplied> und <unclear> für den hier betrachteten Modellierungszusammenhang in Kombination mit weiteren transkriptionstypischen Elementen erklären,[10] seien diese hier ebenfalls kurz erläutert:

• <damage> umschließt einen beschädigten Teil, bei einer Stelle, an der noch etwas lesbar ist, aber ein Teil durch Schaden unleserlich wurde.[11]
• <subst> umschließt einen Ersetzungsvorgang, der beispielsweise mit add und del näher beschrieben werden kann.[12]
• <del> umschließt den getilgten Teil bei einer Stelle, an der noch etwas lesbar ist, aber ein Teil durch Tilgung unleserlich wurde.[13]
• <add> umschließt den ergänzten Teil bei einer Stelle, an der etwas verbessert bzw. ersetzt wurde.[14]

1.2 Codierung von allgemeiner Unsicherheit, Verantwortlichkeit und Genauigkeit

Neben der Möglichkeit, die Sicherheit einer editorischen Entscheidung, deren Begründung und Verantwortlichkeit zu dokumentieren, beinhaltet die TEI auch ein Modul, um Zweifel und Unsicherheit ob der richtigen Verwendung von TEI-Elementen selbst zu kodieren. Ebenfalls abgedeckt werden darin die Auszeichnung von Unsicherheiten bei der (vermeintlichen) Identifikation einer Entität, einer Textstruktur oder auch bei der Angabe und Auflösung numerischer Werte.

Erwähnt werden müssen hier daher auch die im Modul certainty auftretenden Elemente <precision>, <respons> und das mit dem Modul gleichnamige <certainty>:[15]

• <certainty> dient der Kodierung von Unsicherheiten bei der Verwendung von Elementen und Attributen bzw. damit ausgezeichneter Bereiche und zielt damit prinzipiell auf die Inhaltsebene. So können beispielsweise Zweifel daran dokumentiert werden, ob es sich um einen Orts- oder Personennamen handelt oder auch ob ein Absatz mit der Seite endet oder sich noch auf die nächste erstreckt.[16]
• <precision> ermöglicht die Exaktheit bzw. Genauigkeit von numerischen Aspekten des Markups (Datierungen, Einheiten, sonstige Zahlenwerte) graduell zu codieren bzw. näher zu beschreiben.[17]
• <respons> identifiziert den oder die Edierende, welche für bestimmte Aspekte von Inhalt und Auszeichnung verantwortlich zeichnet. Es ist gegenüber dem oben vorgestellten resp-Attribut angesichts verschiedener Attributionsmöglichkeiten deutlich feingranularer.[18]

Die genannten Elemente können mit zahlreichen Attributen versehen werden und bieten insgesamt sehr detaillierte Optionen, um Zweifel und Unsicherheit auf verschiedenen Ebenen in TEI-XML abzubilden. In der Praxis von mit TEI arbeitenden Projekten wie der Carl-Maria-von-Weber-Gesamtausgabe (WeGa),[19] dem Deutschen Textarchiv (DTA) und der noch in der Entwicklung befindlichen PROPYLÄEN. Forschungsplattform für Goethes Biographica spielt das Modul certainty keine Rolle. Die Ergebnisse einer 2010 durchgeführten und 2012 veröffentlichten Studie zur TEI-Benutzung[20] bei der Handschriftenkodierung lassen annehmen, dass die scientific community der TEI-Benutzenden die in den Modulen core (<unclear>, <gap>, <add>, core) und transcr (<supplied>, <damage>, <subst>) befindlichen Elemente für ausreichend hält, um das gewünschte Maß an Dokumentation von Zweifel und Unsicherheit zu erreichen. Die Attribute @resp und @cert gehören zur TEI-Infrastruktur, im Basis-Modul tei.

Abb. 1: TEI-Modules used in manuscript encoding projects (apart from the four basic ones: core, tei, header, textstructure). [Burghart / Rehbein 2012 , Fig. 11. CC BY-ND 3.0.]

Wie die obige Grafik zeigt, kommt das Modul certainty nur bei ca. 22 % der Vorhaben, die Handschriften auszeichnen, zum Einsatz. Gleichzeitig sehen nur sehr wenige TEI-Anwenderinnen und -Anwender Bedarf für eine Ausweitung oder Verbesserung der Richtlinien zur Verwendung der Elemente dieses Moduls, wie die folgende Grafik deutlich macht.

Abb. 2: In what areas do you wish the Guidelines to be improved? Figures are given in absolute numbers. [Burghart / Rehbein 2012, Fig. 18. CC BY-ND 3.0.]

Das entsprechende Kapitel der Richtlinien steht an letzter Stelle. Damit muss dieser Bereich als gut dokumentiert gelten. Interpretiert man dieses Ergebnis aber in Kombination mit der Aussage von Abbildung 1, so liegt die Annahme eines nur geringen Interesses der Fachwelt an einer sehr detaillierten Dokumentation von Zweifel und Unsicherheit nah. Zweifellos werden dabei arbeitsökonomische Aspekte eine Rolle spielen, aber auch Fragen nach dem Mehrwert solcher Informationen.

Nach dem kurzen Exkurs über die theoretische Tiefe der TEI hinsichtlich der Modellierung von Zweifel und Unsicherheit, ist der starke Eindruck entstanden, dass nur ein geringer Teil der Möglichkeiten genutzt wird. Im Folgenden richten wir den Blick auf zwei Beispiele aus der Praxis zum Umgang mit unsicheren Lesarten und Lücken im Text.

2.1 DTA-Basisformat-Realisierung

Das Deutsche Textarchiv (DTA) hat ein eigenes, sehr umfangreich dokumentiertes Datenformat etabliert, das DTA-Basisformat, welches ein subset[21] der TEI ist. Zu unsicheren Lesarten bzw. schwer lesbaren Zeichen heißt es dort:

»Ist die Leserlichkeit der Quelle eingeschränkt, sodass der Text rekonstruiert werden muss bzw. die Lesung des Editors nicht gesichert ist, kann dies durch die Elemente <unclear> und <supplied> wiedergegeben werden. Dabei wird <unclear> verwendet, wenn in der Quelle vorhandenes Material nur undeutlich lesbar ist. Der Grund für die Verwendung des <unclear>-Elements wird mit dem @reason-Attribut, der Grad der Sicherheit der Lesung kann im @cert-Attribut wiedergegeben werden. […] Die Verwendung des Attributs @reason in <unclear> ist dabei obligatorisch, die Verwendung von @cert ist fakultativ.[…] Wenn in der Quelle wahrscheinlich oder möglicherweise vorhandenes Material rekonstruiert wird, so ist dies mit dem Element <supplied> wiederzugeben. Der Grund für die Unleserlichkeit wird im @reason-Attribut wiedergegeben, die Sicherheit der Rekonstruktion steht im @cert-Attribut.«[22]

»Lassen sich die Zeichen nicht erkennen und nicht mehr rekonstruieren, wird das Tag <gap/> gesetzt, um die Lücke anzuzeigen. Innerhalb des <gap>-Tags kann mittels der Attribute @unit, @quantity und @reason der Bezug angezeigt werden, wie viele Zeichen die Lücke umfasst, so wie der Grund der Fehlstelle[.]«[23]

2.2 Aus der Entwicklung – PROPYLÄEN. Goethes Biographica

Im Projekt PROPYLÄEN werden die textkritischen Anmerkungen nicht direkt im Text codiert, sondern in einem per Referenz verknüpften Apparatbereich (in TEI-Code ausgedrückt: <variantEncoding method="location-referenced" location="external" />). Im Apparat und konstituierten Text werden in der Handschrift nicht eindeutig entzifferbare Buchstaben oder Zahlen ebenfalls mit <unclear reason="illegible"> codiert. In der Handschrift nicht entzifferbare Zeichen werden mit <gap reason="illegible" extent="ANZAHL DER ZEICHEN SOFERN ERMITTELBAR"> ausgezeichnet.

3.1 Die Kosmos-Vorträge von Alexander von Humboldt

Im zweiten Teil des Beitrags werden die Elemente <unclear> und <supplied> aus dem DTA-Basisformat näher betrachtet. Datengrundlage sind hierbei die Kosmos-Vorträge von Alexander von Humboldt, die dieser 1827/28 in Berlin einmal an der Universität und einmal an der Sing-Akademie gehalten hat. Zu diesen Vorträgen liegen Mitschriften vor, die im Rahmen eines Forschungsprojekts im Deutschen Textarchiv transkribiert wurden.[27] Humboldts eigene Manuskripte zu den Vorträgen sind nicht erhalten. Es gibt aber für beide Vortragsreihen Mitschriften von Zuhörenden, die aber voneinander abweichen. Vereinfacht gefragt, geht es also darum, was Humboldt wirklich gesagt hat.

Im Folgenden werden fünf der Mitschriften gemeinsam in eine Graphdatenbank eingespielt, die Verwendung der Elemente <unclear> und <supplied> untersucht und schließlich in Relation zu den Edierenden gebracht, die sie in der Transkription verwendet haben (also jenen, die im @resp-Attribut genannt sind). Graphdatenbanken sind sehr gut für die Darstellung stark vernetzter Daten geeignet und in diesem Fall wäre es ein Versuch wert, die Rolle von Editorinnen und Editoren über die Grenzen der Dateien hinweg auszuwerten.

3.2 Import von TEI-XML in eine Graphdatenbank

Für die Analyse von TEI-Unsicherheitsannotationen im Graphen müssen die XML-Daten zunächst in die Graphdatenbank Neo4j importiert werden. Hierfür hat Stefan Armbruster[28] die apoc-Bibliothek von Neo4j um die procedure apoc.load.xml erweitert. Prinzipiell können XML-Dateien ohne größere Probleme in einen Graphen importiert werden, da sie einen geerdeten, gerichteten azyklischen Graphen darstellen, der vielfache Elternbeziehungen verhindert. Damit stellen sie ein Ordered Hierarchy of Content Objects (OHCO) dar.

Der folgende query importiert eine der fünf Vorlesungsmitschriften:[29]

call

apoc.xml.import('http://www.deutschestextarchiv.de/book/download_xml/parthey_msgermqu1711_1828',{createNextWordRelationships:true})

yield node return node;

// URL von Dokument auf alle Wort-Knoten kopieren:

match (d:XmlDocument)-[:NEXT_WORD*]->(w:XmlWord)

set w.url = d.url;

// Knoten durchzählen

MATCH p =

(start:XmlDocument)-[:NEXT*]->(end:XmlTag)

WHERE NOT (end)-[:NEXT]->() AND start.url =

'http://www.deutschestextarchiv.de/book/download_xml/parthey_msgermqu1711_1828'

WITH nodes(p) as nodes, range(0, size(nodes(p))) AS indexes

UNWIND indexes AS index

SET (nodes[index]).DtaID = index;

Für den Import der weiteren Mitschriften muss in dem Befehl die DTA-URL entsprechend geändert werden.

Beim Import werden die XML-Knoten in Graphknoten umgewandelt und verschiedene Arten von Kanten erstellt, welche die Baum-Hierarchie des XMLs im Graphen abbilden. Mit der Option createNextWordRelationships:true wird darüber hinaus festgelegt, dass die im XML vorhandenen Textknoten über NEXT_WORD-Kanten miteinander verknüpft werden. Zu beachten ist hierbei, dass es in TEI-XML zwei verschiedene Arten von Elementen gibt. Die eine Klasse dient der Klassifizierung von Text, die zweite Art bringt Varianten und zusätzlichen Text mit, der beim Import in seiner Serialität eingelesen und mit NEXT_WORD-Kanten verbunden wird. Dies kann dann zur Sinnentstellung des Textes führen.[30] Mit dem zweiten cypher-Befehl wird jedem XmlWord-Knoten die URL des XML-Dokuments als property mitgegeben. Damit behält man im Graphen beim Betrachten der Ergebnisse den Überblick und kann die XmlWord-Knoten einem XML-Dokument zuordnen. Der dritte query nummeriert die Knoten pro Datei durch und macht sie damit innerhalb des Dokuments eindeutig referenzierbar.

3.3 Das XML-Element <unclear> im Graphen

Mit dem folgenden query wird eine Stelle im importierten XML aufgerufen, an der ein <unclear>-Element verwendet wurde:

// unclear-Beispiel

MATCH

(t1:XmlTag {_name:'lb'})<-[:NEXT_SIBLING]-(t2:XmlTag {_name:'unclear'})<-[:NEXT]-(w3:XmlWord {text:'auß'}),

(w1:XmlWord)-[:NEXT_WORD]->

(w2:XmlWord)-[:NEXT_WORD]->

(w3:XmlWord)-[:NEXT_WORD]->

(w4:XmlWord)-[:NEXT_WORD]->

(w5:XmlWord)

RETURN *;

Abb. 3: Beispiel zur Graphmodellierung eines unclear-Elements. [Kasper / Kuczera 2019.]

Die entsprechende Stelle sieht in XML wie folgt aus:[31]

Abb. 4: Das unclear-Beispiel in der XML-Ansicht des DTA. [Kasper / Kuczera 2019.]

Das für den Grad des Zweifels maßgebliche @cert-Attribut befindet sich in den properties des unclear-Knotens.

Abb. 5: Die properties des unclear-Knotens. [Kasper / Kuczera 2019.]

Wie im Beispiel aufgezeigt, können mit dem Import alle Informationen des XMLs verlustfrei in den Graph überführt und abgebildet werden.

3.4 Die Zweifel der Edierenden

Die objektive Gewichtung von Zweifeln im Hinblick auf die Interoperabilität ist schwierig. Ermöglicht man den Edierenden feingranularere Abstufungen, um Zweifel zum Ausdruck zu bringen (z. B. in 10er-Schritten von 0 % bis 100 %) führt das oft zu Verunsicherung. Gibt es nur zwei Stufen, wie im DTA-Basisformat mit high und low, bleibt die Gewichtung grob, Vergleiche fallen aber leichter. Der hier vorgestellte Ansatz verzichtet auf eine objektive Vergleichbarkeit und ordnet die von den Edierenden vergebenen gewichteten Zweifeln den Personen zu. Stehen genügend Daten zur Verfügung, könnte aus den Annotationen ein persönlicher Fingerabdruck des jeweiligen Edierenden erstellt werden.

Zunächst wird mit folgendem cypher query abgefragt, welcher Edierende in welchem Dokument welche XML-Elemente genutzt hat, wobei die XML-Elemente sowohl das @cert- als auch das @resp-Attribut haben müssen:

// Zweifelsattribute in der TEI pro Dokument

MATCH (n:XmlTag)

WHERE n.resp IS NOT NULL

AND n.cert IS NOT NULL

RETURN n.url, n._name AS Element, n.resp AS Person, n.reason, n.cert, count(n.resp) AS Anzahl

ORDER BY Anzahl DESC

Abb. 6: Die gekürzt wiedergegebene Tabelle zeigt die häufigsten Ergebnisse des obigen Querys. Die Angaben in der ersten Spalte der Tabelle wurden aus Gründen der Übersichtlichkeit um den URL-Teil gekürzt, der bei allen Mitschriften gleich ist. [Kasper / Kuczera 2019.]

Mit Abstand am häufigsten wurde bei der Transkription der Vorlesungsmitschriften das <unclear>-Element verwendet, mit einigem Abstand gefolgt vom <supplied>-Element.

3.4.1 Die Identifizierung des Edierenden

Die Spalte Person in der Tabelle gibt den Inhalt der resp-property an, in der die Person des Edierenden mit einem Kürzel wiedergegeben wird. Im XML-Header werden diese Kürzel auf folgende Personen aufgelöst:

Abb. 7: Aufschlüsselung der Edierendenkürzel. [Kasper / Kuczera 2019.]

Es sind Personen, die mit der Transkription der Humboldt-Vorlesungsmitschriften befasst waren. Im nächsten Schritt werden nun alle in den resp-properties genannten Edierenden explizit als Personenknoten erstellt und mit jenen unclear- und supplied-Knoten verknüpft, für die sie verantwortlich sind. Mit folgendem query werden die Personen erstellt:

// Edierende Personenknoten erstellen

MATCH (n:XmlTag)

WHERE n.resp IS NOT NULL

AND n.cert IS NOT NULL

MERGE (p:Person {name:n.resp})

RETURN *;

// Alle XML-Elemente mit resp-Attribut den erstellten Personen zuordnen

MATCH (n:XmlTag), (p:Person {name:n.resp})

WHERE n.resp IS NOT NULL

AND n.cert IS NOT NULL

MERGE (p)<-[:RESPONSIBLE {cert:n.cert}]-(n)

RETURN *;

und mit den entsprechenden unclear- und supplied-Knoten im Graphen über RESPONSIBLE-Kanten verknüpft.

Abb. 8: unclear- und supplied-Knoten, die von #CT erstellt worden sind. [Kasper / Kuczera 2019.]

3.4.2 Statistik zur Zweifel im Graphen

Mit dem folgenden cypher query fragen wir die Häufigkeit der unclear- und supplied-Knoten im Graphen ab und ordnen sie den Edierenden zu:

// 1 Elementanzahl pro Person

MATCH (n:XmlTag)-[:RESPONSIBLE]->(p:Person)

RETURN n._name AS Elementname, p.name AS Editorname,

count(n._name) AS Elementanzahl ORDER BY Elementanzahl DESC;

Abb. 9: Häufigkeit der unclear- und supplied-Knoten der jeweiligen Edierenden. [Kasper / Kuczera 2019.]

Der Editor #BF hat in den fünf in der Graphdatenbank enthaltenen Dokumenten insgesamt 337 <unclear>- und nur zwei <supplied>-Elemente eingefügt, während der Editor #CT nur für 134 <unclear>- und für 7 <supplied>-Elemente verantwortlich ist.

Der folgende cypher query nimmt noch den Inhalt des @cert-Attributs hinzu.

// 2 Zweifel pro Person über alles

MATCH (n:XmlTag)-[:RESPONSIBLE]->(p:Person)

RETURN n._name AS Elementname, n.cert AS Zweifel, p.name AS Editorname, count(n._name) AS Elementanzahl ORDER BY Elementanzahl DESC;

Abb. 10: Häufigkeit der unclear- und supplied-Knoten mit Angabe des cert-Attributs. [Kasper / Kuczera 2019.]

Damit differenziert sich das Bild etwas, jedoch sind die Anteile von high- und low-Werten bei den jeweiligen Editoren im Durchschnitt gleich.[32]

Abb. 11: Verteilung von high- und low-Werten sind beim cert-Attribut bei den Edierenden etwa gleich verteilt. [Kasper / Kuczera 2019.]

Mit dem nächsten query wird das Raster auf Dokumentenebene verfeinert:

// 5 Dokumente mit Bearbeitern, Elementen und Zweifeln

MATCH (n:XmlTag)-[:RESPONSIBLE]->(p:Person)

RETURN n.url AS Dokument, p.name AS Editorname, n._name AS Elementname, n.cert AS Zweifel, count(n._name) AS Elementanzahl ORDER BY Dokument, Elementname, Zweifel, Elementanzahl;

Abb. 12: Verteilung der unclear- und supplied-Knoten mit Angaben zum Zweifel auf Dokumentebene. [Kasper / Kuczera 2019.]

Es ist zu erkennen, dass #BF die Vorlesungsmitschrift von Patzig ediert hat und dabei die meisten <unclear>-Elemente vergeben hat. #CT hat in der Vorlesungsmitschrift von Parthey dagegen nur 94 <unclear>-Elemente verwendet. Dies könnte daran liegen, dass die Parthey-Vorlesungsmitschrift besser lesbar ist. Eine kurze Nachfrage beim Projekt Humboldt-Kosmos ergab aber, dass #BF wissenschaftliche Hilfskraft, #CT aber wissenschaftlicher Mitarbeiter ist. Die Ergebnisse der Tabelle könnten also auch zeigen, dass #CT die Handschriften besser lesen kann und deshalb weniger <unclear>-Elemente vergeben hat.

3.5 Verfeinerung des Profils

Im Folgenden wird die o. a. Auswertung in Kreisdiagrammen dargestellt. Die Farben der Legenden sind über alle Grafiken gleich. Im äußersten Ring werden die Anteile der Bearbeitenden an den in einem Dokument vergebenen <supplied>- und <unclear>-Elemente gezeigt.

Abb. 13: Unsicherheitsverteilung auf Editorenebene bei Patzig. [Kasper / Kuczera 2019.]

Patzig

Bei der Transkription der Mitschrift von Patzig hat Benjamin Fiechter (BF) den größten Teil der <supplied>- und <unclear>-Elemente erstellt, ein kleinerer Teil wurde von Christian Thomas eingegeben. Im zweiten Ring ist zu erkennen, dass überwiegend <unclear>-Elemente vergeben wurden und dass Christian Thomas von den (wenigen) <supplied>-Elementen im Vergleich den größeren Teil eingetragen hat. Schließlich bleibt anzumerken, dass Benjamin Fiechter bei der Vergabe der <unclear>-Elemente im Verhältnis wesentlich öfter Zweifel hatte.

Abb. 14: Unsicherheitsverteilung auf Editorenebene bei Parthey. [Kasper / Kuczera 2019.]

Parthey

In der Mitschrift von Parthey zeichnet ganz überwiegend Christian Thomas für die <supplied>- und <unclear>-Elemente verantwortlich, verwendet aber fast nur das <unclear>-Element. Die folgenden Kreisdiagramme zeigen noch die Verteilungen der Vorlesungsmitschriften NN1, NN2 und Hufeland.

Abb. 15: Unsicherheitsverteilung auf Editorenebene in NN2. [Kasper / Kuczera 2019.]

NN1

Die Mitschrift NN1 wurde überwiedend von Benjamin Fiechter ausgezeichnet, der kein unclear-Element verwendet. Christian Thomas annotiert dagegen zwei Stellen mit supplied-Elementen.

Abb. 16: Unsicherheitsverteilung auf Editorenebene in NN2. [Kasper / Kuczera 2019.]

NN2

Ein ähnliches Bild ergibt sich für die Mitschrift NN2. Auch hier verwendet Benjamin Fiechter nur unclear-Elemente, während Christian Thomas auch einen Anteil an supplied-Elementen vergibt.

Abb. 17: Unsicherheitsverteilung auf Editorenebene bei Hufeland. [Kasper / Kuczera 2019.]

Hufeland

Interessant scheint vor allem die Mitschrift Hufeland (Abbildung 17), bei der Christian Thomas fast alle <unclear>-Elemente eingetragen hat, während Benjamin Fiechter alle <supplied>-Elemente vergeben hat.[33] Eine sehr interessante Art von Arbeitsteilung, die sich so in keiner anderen Transkription findet. Ein kleiner Anteil der Bearbeitung wurde bei dieser Mitschrift auch von Tina Krell vorgenommen.

Abb. 18: Unsicherheitsverteilung auf Editorenebene insgesamt. [Kasper / Kuczera 2019.]

Gesamt

In der letzten Grafik wurden alle Angaben noch einmal über alle Handschriften zusammengefasst. Es zeigt sich, dass Benjamin Fiechter einen großen Teil der <unclear>-Elemente vergeben hat, Christian Thomas einen kleineren, dafür aber fast alle <supplied>-Elemente.

Für die Erstellung eines persönlichen Auszeichnungsprofils von Edierenden wäre es am besten, verschiedene Edierende unabhängig voneinander die gleiche Quelle annotieren zu lassen und die Ergebnisse zu vergleichen. Liegen ausreichend Daten vor, wäre es denkbar, über Dokumentengrenzen hinweg persönliche Auszeichnungsprofile der Edierenden zu erstellen. Mit diesen Profilen könnten die verschiedenen, in der TEI möglichen Werte für die Attribute von Unsicherheit, näher bestimmt und möglicherweise auch vereinheitlicht werden.