Up to now, Wolfram von Eschenbach’s Parzival, one of the most important texts of Middle High German literature, hasn’t been accessible but in one edition, which is over 170 years old and thus follows editorial principles that are by now outdated. Hence, in 2001, the Parzival-Project, currently settled at the University of Berne, was grounded to present a new edition that would visualize the plurality of manuscript transmission by applying modern computer technology. The edition is based on digital transcriptions that are annotated according to a specifically developed markup-system. Due to the fact that the guidelines of the Text Encoding Initiative (TEI) have become a standard for the annotation of digital editions it would be desirable to transform the Bernese project material into the TEI-code. The paper demonstrates what methods can be used to convert the data, and what problems might occur in the transformation process.

Die editorische Praxis in der germanistischen Mediävistik wurde lange Zeit von der klassischen Methode der Textkritik bestimmt, deren oberstes Ziel die Rekonstruktion eines in den allermeisten Fällen heute verlorenen oder nicht mehr greifbaren Autor-Originals darstellt, das aus der immer nur in Ausschnitten erhaltenen handschriftlichen Überlieferung rückerschlossen werden soll. Dies gilt zum Teil auch heute noch, obwohl die nach ihrem Gründungsvater benannte sogenannte ›Lachmannsche Methode‹ schon lange Gegenstand theoretischer Debatten war und die gegen sie vorgebrachten methodischen Bedenken – nach einigen Phasen überhitzter Diskussionen – zumindest in ihrer moderaten Form weitgehend Zustimmung gefunden haben. Das Spektrum der Einwände reicht vom Zweifel an einer intersubjektiv nachvollziehbaren Möglichkeit zur Rekonstruktion des Autortextes bis zur grundsätzlichen Frage, ob der Begriff des ›Originals‹ dem mittelalterlichen Literaturbetrieb überhaupt angemessen ist. [2]

Auch einer der wichtigsten Texte der mittelhochdeutschen Literatur überhaupt, der um 1200 / 1210 von Wolfram von Eschenbach verfasste Parzival, wird bislang noch immer in einer Ausgabe gelesen, die bereits 180 Jahre alt ist und geradezu zu den Gründungsdokumenten der klassischen Textkritik zählt, nämlich in der großen Wolfram-Ausgabe Karl Lachmanns aus dem Jahr 1833. Dies ist in der Forschung schon lange als Missverhältnis konstatiert worden. [3] Die Wolfram-Ausgabe stellt zwar sicherlich eines der Glanzstücke Lachmanns und seiner textkritischen Methode dar, dass sie aber heute weiterhin uneingeschränkt in Verwendung ist, ja dass es bis vor kurzem keinen wirklich ernstzunehmenden Versuch gab, sie zu ersetzen, ist angesichts des überlieferungsgeschichtlichen Paradigmenwechsels in der Methodendiskussion der mediävistischen Editorik einigermaßen erstaunlich. [4] Das vom Schweizer Nationalfonds geförderte, an der Universität Bern angesiedelte Parzival-Projekt unter der Leitung von Michael Stolz hat sich daher zum Ziel gesetzt, die erste Ausgabe von Wolframs berühmtem Gralsroman zu schaffen, die auf der gesamten Überlieferung basiert und die dieser Überlieferung auch in der editorischen Darstellung gerecht werden will.

Dass Versuche zu einer Neuausgabe des Textes lange unterblieben sind, ist wohl nicht zuletzt auf pragmatische Gründe zurückzuführen. Der mit circa 24000 Versen nicht gerade kurze Parzival ist nämlich für ein Werk der höfischen Literatur besonders reich überliefert worden. Heute sind noch sechzehn vollständige Handschriften, eine Frühdruckausgabe und 70 Fragmente bekannt. Unter diesen Textzeugen herrschen zudem die für die höfische Epik fast schon charakteristischen verworrenen Überlieferungsverhältnisse. Der Versuch, ein komplettes Stemma für den Parzival zu konstruieren, ist selbst in den ohnedies nur spärlich vorhandenen Untersuchungen, die der klassischen Textkritik verpflichtet sind, gar nicht erst unternommen worden, da die Handschriftenverwandtschaften von Abschnitt zu Abschnitt stark wechseln. [5]

Erst mit den neuen technischen Möglichkeiten, die der Computer bietet, hat sich eine vielversprechende Perspektive geöffnet, wie man der umfangreichen Überlieferung des Parzival gerecht werden kann. Im Berner Parzival-Projekt wurde ein am Aufbau von Frame-basierten Webseiten orientiertes Editionsmodell entwickelt, das sich insbesondere die Möglichkeit der Verlinkung von Texten zu Nutze macht, um die Zusammenhänge der einzelnen Handschriften in den Blick zu bekommen. [6] Die Grundidee bestand zunächst darin, eine Online-Edition zu bieten, die einen Basistext enthält, dessen Apparat mit der Transkription und den Faksimiles der Einzelhandschriften verlinkt ist. [7] Nach umfangreichen Studien zur Struktur der Parzival-Überlieferung [8] wurde dieses Modell weiter entwickelt zu einer Fassungsedition, bei der statt einem Basistext mittlerweile vier Fassungen im Mittelpunkt stehen, zu denen sich die gesamte Überlieferung gruppieren lässt. [9]

Das Grundgerüst des aktuellen Editionsmodells nach Fassungen stellt ein vertikal viergeteilter Bildschirm dar. In den vier Haupt-Frames werden die Texte der vier Fassungen *D, *m, *G und *T, die jeweils auf der Basis eines moderaten Leithandschriftenprinzips erstellt wurden, in synoptischer Darstellung wiedergegeben. Varianten zwischen diesen Fassungen sind mit Fettdruck markiert. Gibt es darüber hinaus auch innerhalb einer Fassung Abweichungen in den Einzelhandschriften, wird dies durch eine blau eingefärbte Verszahl angezeigt. Diese Abweichungen sind im Frame unterhalb des entsprechenden Fassungstextes in einem eigenen Apparat verzeichnet, wobei der Fassungstext so mit dem Apparat verlinkt ist, dass bei einem Mausklick auf die blau eingefärbte Verszahl der Apparat auf den entsprechenden Eintrag springt. Hier sind die Lesarten der Einzelhandschriften in der aus konventionellen Editionen bekannten Art notiert (Anführung des Lemmas, der Lemmaklammer und der Einzellesart sowie der Sigle der Handschrift). Die elektronische Darstellungsform bietet darüber hinausgehend jedoch noch weiterführende Möglichkeiten, denn mit einem weiteren Mausklick auf die Handschriftensigle kann eine Transkription der Einzelhandschrift samt einem Faksimile der entsprechenden Handschriftenseite aufgerufen werden. Die Edition verbindet damit die Vorteile beider kontroversen Richtungen, die die theoretischen Debatten in der Editionswissenschaft bestimmt haben, nämlich der klassischen Rekonstruktionsphilologie und einer (im weitesten Sinne) überlieferungsgeschichtlichen Methode: Einerseits bietet sie vier gebündelte, relativ übersichtliche Basistexte, andererseits aber auch einen Zugriff auf die Gesamtüberlieferung.

Die Bündelung der Überlieferung in vier Fassungen hat zudem den Vorteil, dass sich die zugehörigen Apparate trotz der großen Zahl der erhaltenen Handschriften relativ übersichtlich gestalten lassen. Dies ist die Grundlage dafür, dass die Edition nicht auf eine Online-Darstellung beschränkt werden muss, sondern auch eine Ausgabe für den Druck als wesentliche Komponente hinzutreten kann. Diese Druckausgabe bringt die vier Fassungen auf einer aufgeschlagenen Buchseite zur Darstellung. Die Abweichungen zwischen den Fassungen sind wie in der elektronischen Darstellungsform durch Fettdruck kenntlich gemacht, jede Fassung ist mit einem eigenen Apparat versehen.

Sowohl die Druck- als auch Online-Ausgabe gehen gemäß dem Single-Source-Prinzip auf dieselbe Kerndatei zurück, die mit anwendungsneutralen Tags annotiert ist und mittels geeigneter Skripte leicht in beide Darstellungsformen konvertiert werden kann. [10]

Um für dieses Editionsmodell eine materielle Grundlage zu schaffen, war es zunächst nötig, die einzelnen Handschriften digital zu fotografieren und zu transkribieren. In einer ersten Projektphase (ab 2001) wurden anhand ausgewählter Abschnitte Probetranskriptionen vorgenommen und in intensiven Diskussionen Richtlinien für die digitale Abschrift der Texte entwickelt. Schon 2001 war klar, dass eine solide, weiterentwickelbare Transkription sich der Markup-Technik zu bedienen hat. Die beiden Hauptgrundsätze der Projektrichtlinien lauten daher – aus heutiger Sicht wenig überraschend –, dass die Handschriften erstens buchstabengetreu zu transkribieren sind und dass zweitens alle weiteren handschriftlichen Besonderheiten, die über den bloßen Text hinausgehen, mit Tags ausgezeichnet werden sollen. [11] Zur damaligen Zeit noch nicht sicher abschätzbar schien uns, ob und inwiefern sich die Richtlinien der TEI als übergreifender Standard für die Erfassung digitaler Texte durchsetzen werden. [12] Daher wurde im Projekt nicht auf TEI-Kodierung zurückgegriffen, sondern ein proprietäres Markup entwickelt, das zwar ähnlich wie XML aufgebaut ist, aber doch einige Eigenheiten hat, wie im Folgenden deutlich werden wird.

Rückblickend betrachtet lässt sich sagen, dass sich der aufwendige Diskussionsprozess, in dem die Richtlinien geformt wurden, durchaus gelohnt hat. Das Markup hat sich als praktikabel und gut anwendbar erwiesen, mittlerweile wurde schon eine beträchtliche Menge an Daten generiert. Nachdem nun aber seit einigen Jahren die Richtlinien der TEI als Standard für die Textdigitalisierung immer gefestigter erscheinen und nachdem nach der umfangreichen Pionierarbeit, die im Parzival-Projekt geleistet wurde, Fragen der Austauschbarkeit und insbesondere der Langzeitsicherung der Daten verstärkt in den erweiterten Fokus der Projektarbeit gerückt sind, erschien es uns doch unabdingbar, sich auch mit einer möglichen Kodierung der Daten im TEI-Format zu befassen.

Eine vollständige Umstellung auf die ausschließliche Verwendung der TEI-Richtlinien ist im Fall des Parzival-Projekts jedoch nicht sinnvoll: Da bereits umfangreiche Datenmengen im proprietären Projektformat vorliegen und die Mitarbeiter auf seine Verwendung eingeschult sind, war es von vornherein klar, dass die eigens entwickelten Richtlinien nicht völlig aufgegeben und zur Gänze durch TEI-Auszeichnungen verdrängt werden können. Stattdessen soll die Abstimmung auf die TEI-Normen mit Hilfe von automatischen Konvertierungsroutinen bewerkstelligt werden, die das Markup der bestehenden Transkriptionen vom proprietären Format in jenes der TEI übertragen. Welche Probleme und Besonderheiten sich dabei ergeben, soll im Folgenden anhand einiger ausgewählter Beispiele gezeigt werden. [13]

Die Projekttranskriptionen wurden mit TUSTEP erstellt, einem Programm, das sich insbesondere durch ballastfreie Datenhaltung, hohe Praktikabilität für geisteswissenschaftliche Textverarbeitungsaufgaben und große Stabilität auszeichnet. [14]

Abbildung 1

Abbildung 1 zeigt eine TUSTEP-Transkription zum 15. Buch aus dem Parzival, und zwar in der Version der Handschrift D, der berühmten Sankt Galler Epenhandschrift aus der 2. Hälfte des 13. Jahrhunderts, die sicher eine der sorgfältigsten Abschriften darstellt und bereits von Lachmann letztlich als Grundlage für seine Ausgabe herangezogen wurde. [15]

Abbildung 2
St. Gallen, Stiftsbibliothek, Cod. Sang. 857, S. 262

Abbildung 2 zeigt das entsprechende Digitalfaksimile der Handschrift. Wie bei den meisten Parzival-Handschriften der Zeit üblich, ist das Layout zweispaltig angelegt, wobei die Verse in der Regel abgesetzt geschrieben sind. Nur gelegentlich kommen Unregelmäßigkeiten im Zeilenfall vor, und zwar zumeist dort, wo ein den Textbeginn schmückender Initialbuchstabe zu viel Platz einnimmt, so dass notwendigerweise ein Zeilenumbruch erfolgt, wie dies in Abbildung 2 in der linken Spalte (Spalte a) zu sehen ist. [16]

Die Gliederung der digitalen Transkriptionen orientiert sich jedoch nicht in erster Linie an diesem handschriftenspezifischen Layout, sondern an der in der Forschung etablierten Verszählung der Ausgabe Karl Lachmanns. [17] Der transkribierte Abschnitt beginnt bei Vers 734.01, also dem ersten Vers des 734. Dreißiger-Abschnitts. Diese Zählung bietet somit das Grundgerüst für die Transkriptionen: Jede Text-Zeile setzt mit der Angabe ›$<L‹ ein, [18] gefolgt von der Versnummer und einer schließenden Spitzklammer. [19] Nach einem Unterstrich wird der entsprechende Vers wiedergegeben.

Wie wohl bei den meisten Handschriften-Transkriptionen üblich, zeigen sich hier also zwei divergierende Struktur-Hierarchien: einerseits das Seitenlayout der Handschrift mit ihren Spalten- und Zeilenumbrüchen, andererseits die sinnzentrierte Lachmannsche Versgliederung. Das Problem wird in den proprietären Projektrichtlinien ähnlich wie in TEI-konformen Transkriptionen gelöst, indem die übergreifende Struktur durch die sinnzentrierte Verszählung gebildet wird (jede Zeile beginnt mit der entsprechenden Lachmann-Versnummer), Layout-Aspekte der Handschrift hingegen lediglich mit Milestones angedeutet werden. [20] Ein Beispiel bietet Vers 734.02, der in der Handschrift umbricht. Der Umbruch wird in der Transkription durch den Milestone [z] angezeigt, der keinen Bereich, sondern nur einen Punkt markiert. [21]

Anhand dieser Annotationen zur Textstrukturierung werden bereits erste formale Unterschiede des proprietären Projektsystems zu XML ersichtlich. Die Tags des Parzival-Projekts sind in der Regel mit eckigen Klammern umschlossen. In Spitzklammern stehen lediglich die Lachmannschen Versnummern; und auch hier weicht das Projekt-Markup von den XML-Konventionen ab, da es kein explizites Schließtag gibt. [22]

Trotz dieser Unterschiede handelt es sich funktional gesehen letztlich um ein Tag-basiertes Markup, das relativ leicht nach XML konvertiert werden kann. Abbildung 3 zeigt eine aus der TUSTEP-Transkription generierte XML-Datei des entsprechenden Abschnitts, die bereits den Richtlinien der TEI entspricht. [23]

Abbildung 3

Die Zeilenzählung ist zu einem <l>-Tag transformiert worden, das Attributangaben zur Zeilennummer enthält. Der Zeilenumbruch [z] erscheint als Milestone <lb/>, der Spaltenumbruch als <cb/>. Für die Transkriptionspraxis von Relevanz könnte der Umstand sein, dass der mit einem <l>-Element eingeleitete Vers nunmehr XML-konform mit einem Schließ-Tag versehen werden musste, der ganze Vers also von Tags umschlossen ist. Demgegenüber gehört es wohl zu den Vorteilen unseres proprietären Projektsystems, dass der Transkribent nach dem Ende der Zeile nicht mehr das Schluss-Tag zu berücksichtigen braucht und fortlaufend schreiben kann. Davon abgesehen bestehen bei diesen Auszeichnungen jedoch keine grundsätzlichen konzeptionellen Unterschiede zwischen den beiden Systemen.

Größer werden die Differenzen bei einigen weiteren handschriftlichen Eigenheiten, die mit Tags gekennzeichnet werden, so z.B. bei den Initialen. Wie auf Abbildung 2 zu sehen, treten in Handschrift D zwei unterschiedliche Initialtypen auf, zum einen aufwendig gestaltete Prachtinitialen (z.B. die große ›U‹-Initiale in der linken Spalte), zum anderen einfachere Lombardinitialen (z.B. die blaue ›S‹-Initiale in der rechten Spalte). Die Kennzeichnung dieser Initialen darf natürlich in einer auf Vollständigkeit bedachten Digitaltranskription nicht fehlen, zudem sollen auch Informationen über das unterschiedliche Aussehen im Markup festgehalten werden, da anzunehmen ist, dass die Unterschiede Aufschluss über die hierarchische Stellung dieser Gliederungszeichen geben. [24]

In den Projekttranskriptionen sind diese Initialen mit einem eigenen Tag annotiert (vgl. Abbildung 1, Vers 734.01, ›[6pinit]U[/init]il‹). Das Schluss-Tag der Kodierung lautet [/init], und auch das Anfangs-Tag enthält die Zeichenfolge ›init‹, der jedoch zusätzlich noch eine Zahl und ein Buchstabe vorangestellt wurden. Start- und Schließtag stimmen also anders, als dies in XML gefordert ist, nicht überein. Der Grund hierfür liegt darin, dass die Informationen zum Aussehen und zur Größe der Initiale, die in XML normalerweise in Attributen wiedergeben werden, in unserem Projektformat direkt in den Elementnamen eingesetzt sind. Die Zahl 6 gibt die Zeilenhöhe der Initiale an, der Buchstabe ›p‹ steht für ›Prachtinitiale‹, beschreibt also den Initialtyp. Entsprechend lautet das Starttag bei der kleineren Initiale in der rechten Spalte (Vers 736.01) [2Lbinit], dieser Elementname verweist also auf eine zweizeilige Lombard-Initiale. Zudem ist hier noch der Buchstabe ›b‹ mit angegeben, der die Farbe der Initiale, nämlich blau, indiziert.

Auch diese Auszeichnungen können noch relativ unproblematisch in den TEI-Standard konvertiert werden. Mittels eines geeigneten Skripts werden die Informationen aus dem Elementnamen ausgelesen und einem neu eingefügten Attribut zugewiesen. Da es in der Grundausstattung der TEI-Richtlinien kein eigenes Element für Initialen gibt, werden diese mit dem Tag <hi> (für ›highlighted‹) ausgezeichnet. Ein Beispiel für die Umsetzung bietet Vers 734.01 in der XML-Version in Abbildung 3. Die entsprechende Kodierung lautet:

<hi rend="Initiale Typ(Prachtinitiale) Zeilenhöhe(6)">U</hi>il 

Die umfangreichen Zusatzangaben müssen in das einzig dafür vorgesehene Attribut ›rend‹ eingeschrieben werden und sind in der Datei sehr explizit und möglichst strukturiert wiedergegeben. Eine solch hoher Grad an Ausdrücklichkeit ist natürlich nur bei einer automatischen Konvertierung der Daten angezeigt, bei der Ersterfassung der Daten nach TEI-Richtlinien würde man sich wohl auch hier einer abgekürzten Schreibweise bedienen, die im Datei-Header aufgelöst wird. Da die Integration aller Angaben zum Aussehen und zum Typ der Initiale in ein einziges Attribut ein maschinelles Auslesen der Datei umständlich macht, wäre es darüber hinausgehend erwägenswert, ob in diesem Fall das TEI-Grundset um ein eigens angefertigtes Initial-Element erweitert werden sollte. Vorstellbar wäre etwa eine Notation <init type=’p’ size=’6’>. Selbst bei einer solchen Auszeichnung stellt sich jedoch unter transkriptionspragmatischem Gesichtspunkt gesehen die Frage, ob die projektspezifische Schreibweise, die nicht zur Aufteilung von Elementname und Attributinformation verpflichtet ist, in diesem Fall nicht leichter handhabbar und übersichtlicher zu lesen ist als der XML-Code. [25]

Eine weitere handschriftliche Eigenheit, die sehr häufig in den Transkriptionen auftritt, sind Abkürzungszeichen. Ein Beispiel bietet etwa Vers 734.01 im Wort »v[7](er)[/7]drozzen«: Hier ist die Buchstabenfolge ›er‹ der Vorsilbe als Abkürzung, nämlich als r-Haken ausgeführt. Gemäß den Projektrichtlinien wird in einem solchen Fall an der Position des Kürzels ein Tag gesetzt, das lediglich aus einer Zahl besteht. Diese Zahl gibt den Typ der Abkürzung an; um welche es sich handelt, wird in der Projektdokumentation aufgelöst. Die Zahl ›[7]‹ zeigt beispielsweise wie im vorliegenden Fall einen r-Haken an, ›[1]‹ steht für einen Nasalstrich, ›[4]‹ für ein durchgestrichenes p, das die Vorsilbe ›per‹ vertritt und so weiter. Innerhalb dieser Nummern-Tags wird in runder Klammer die Auflösung der Abkürzung wiedergegeben. Auf diese Weise können den gleichen Kürzungstypen unterschiedliche Auflösungen zugeordnet werden. [26]

Im TEI-Format stehen gleich mehrere Möglichkeiten zur Kennzeichnung von Abkürzungszeichen zur Verfügung: Zunächst das Element <abbr>, in dem auch das Attribut ›type‹ zulässig ist, mit dem wie in unserem Markup der Typ der Abkürzung markiert werden kann. Dennoch eignet es sich nicht zur Konvertierung, denn <abbr> muss das ganze abgekürzte Wort umschließen. Da im Projektformat nur die Abkürzung selbst gekennzeichnet wird, nicht aber das ganze Wort, wäre eine Transformierung in den meisten Fällen zumindest aufwendig. So gut wie unmöglich wird sie dann, wenn ein Wort gleich zwei Abkürzungszeichen unterschiedlichen Typs enthält, da diese Information in dem einen, für das ganze Wort gültigen ›type‹-Attribut nur schwer unterzubringen ist.

Die TEI-Richtlinien halten jedoch noch eine Alternative zur Kennzeichnung von Abbreviationen bereit, nämlich die Tags <am> (›abbreviation marker‹) und <ex> (›editorial expansion‹), die um die Abkürzung selbst gesetzt werden können. Bei Verwendung dieser Tags lässt sich die Projektkonvention lückenlos umsetzen; die Struktur, die dabei entsteht, ist allerdings wieder ziemlich komplex, wie etwa in Abbildung 3 an Vers 734.01 ersichtlich wird:

»v<choice><am><g ref="#a7"/></am><ex>er</ex></choice>drozzen«

Als äußerstes Tag um die Abkürzung wird ein <choice>-Element gesetzt, um anzuzeigen, dass die beiden folgenden Elemente <am> und <ex> als Alternativen zu verstehen sind. In den <am>-Tags ist ein so genanntes gaiji-Element eingeschlossen. [27] Dieses <g>-Element steht für den r-Haken, also die Abkürzung selbst, die eigentlich ein Sonderzeichen ist. Das <g>-Element besitzt ein ref-Attribut, das auf eine genauere Beschreibung in der Character Declaration im Header verweist. Auf <am> folgt schließlich <ex>, also die aufgelöste Lesart.

Das Spektrum der gliederungsrelevanten und damit auszeichnungswürdigen handschriftlichen Phänomene erweitert sich, wenn man den Blick von der relativ frühen St. Galler Handschrift D auf die Spätüberlieferung des Parzival im 15. Jahrhundert wendet. So gehört es etwa zu den Charakteristika der um 1430–1450 in der elsässischen Werkstatt des Diebold Lauber entstandenen Parzival-Handschriften, dass in ihnen der althergebrachte Text mit Hilfe der Einbeziehung von Überschriften und Bildern gegliedert wird. Die Reichweite und Funktion dieser Überschriften ist ganz unterschiedlich und lässt sich nicht genau festlegen. In einigen Fällen wirken die Rubriken wie heutige Kapitelüberschriften, die einen Ausblick auf das kommende Geschehen geben, manchmal beschreiben sie aber nur eine punktuelle Szene. [28] Letzteres dürfte etwa der Fall sein bei einer Überschrift-Bild-Kombination aus der Wiener Lauber-Handschrift m, die in Abbildung 4 wiedergegeben ist. [29]

Abbildung 4
Österreichische Nationalbibliothek, Cod. 2914, Fol. 495v

Überschrift und Illustrationen thematisieren ein eher singuläres Ereignis aus dem Text, die Aufnahme von Parzivals orientalischem Halbbruder Feirefiz am Artushof. Man könnte in diesem Fall annehmen, dass die Rubrik rein als Titel für das nachfolgende Bild zu verstehen und nicht als Kapiteleingang angelegt ist, aber eindeutig lässt sich dies nicht sagen, denn in den meisten Fällen changieren diese Überschriftenfunktionen, die im Mittelalter offensichtlich noch nicht so festgelegt waren wie in der Neuzeit. [30]

In den Projekttranskriptionen erhalten die Überschriften eine eigene Zeilennummer und werden mit dem Tag [tit] gekennzeichnet. Der TUSTEP-Satz, der die Rubrik in Abbildung 4 beschreibt, lautet demnach: [31]

 $<L 764.05-0>_[rtit]Al#.so gawan vnd die #.sch%=onen frowen
gingent [z] f%=ur den heiden pontgefar mit einem gro#.s#.sen
ge#.schele[/tit]

				

In diesem Fall findet sich im Start-Tag erneut eine Erweiterung des Elementnamens, nämlich ein ›r‹, das indiziert, dass die Überschrift in roter Tinte ausgeführt wurde.

Der intuitive Weg, diese Überschrift im TEI-Format zu kodieren, wäre wohl der gewesen, sie in das TEI-Tag <head> einzuschließen, jedoch führt hier die beschriebene Unschärfe der Überschriftenfunktion zu einem Problem: Die TEI-Richtlinien erlauben nämlich <head> nur zu Beginn von Textbereichen und nicht innerhalb einer Reihe von mit dem <l>-Element markierten Versen, wie das hier der Fall wäre. Ein möglicher Ausweg wäre, den Text in <div>-Bereiche zu segmentieren, wobei mit dieser Zwischenüberschrift ein neuer Abschnitt beginnen müsste. Aber wie weit ist dieser <div>-Bereich zu führen? Nur bis zu der folgenden Illustration oder weiter bis zur nächsten Überschrift? Beides scheint aufgrund des Changierens der Funktionen dieser Zwischentitel nicht angemessen zu sein. Das <head>-Konzept ist hier vielleicht etwas zu neuzeitlich gedacht, und nicht adäquat auf die mittelalterlichen Überschriften mit ihren vielfältigen Funktionen anzuwenden.

Statt auf <head> muss also einmal mehr auf <hi> zurückgegriffen werden, der entsprechende Eintrag in der XML-Datei lautet daher:

Abbildung 5

Alternativ wäre auch eine Einbeziehung der Information, dass es sich bei der Zeile um eine Überschrift handelt, in ein type-Attribut des entsprechenden <l>-Elements denkbar oder die Erweiterung des TEI-Grundwortschatzes durch ein eigenes Element.

Während alle bisher besprochenen Annotationen zwar mitunter mit etwas Aufwand, aber letztlich doch automatisch in TEI-Format umsetzbar sind, ohne dass wesentlich vom Grundset der TEI-Elemente abgewichen werden muss, gibt es eine letzte handschriftliche Besonderheit, bei der die projekteigenen Richtlinien konzeptionell derart verschieden sind, dass leichte Modifikationen vorgenommen werden müssen. Bei Korrekturen, die vom Schreiber der Handschrift oder einem späteren Leser vorgenommen wurden, hat das Parzival-Projekt ursprünglich einen Wort-für-Wort-Zugang gewählt. Wenn etwa wie in Vers 746.29 der Handschrift m im Wort ›strittes‹ der letzte Buchstabe, das ›s‹, vom Schreiber aus einer heute nicht mehr lesbaren Graphie korrigiert wurde, wird dies nach den Projektrichtlinien folgendermaßen notiert: [k]stritte*[sr]strittes[/sr][/k]. Die ganze Korrektur ist in [k]-Tags eingeschlossen, auf das [k]-Start-Tag folgt die ursprüngliche Fassung. Da der Buchstabe, aus dem der Schreiber nachträglich das ›s‹ korrigiert hat, heute nicht mehr bestimmbar ist, befindet sich an seiner Stelle der Platzhalter ›*‹, der für beliebig viele unlesbare Zeichen einstehen kann. Danach wird ein inneres Tag [sr] gesetzt, um anzuzeigen, dass die Korrektur vom Schreiber, und nicht etwa von einem späteren Benutzer ausgeführt wurde. [32] In diese [sr]-Tags eingeschlossen ist das Wort, wie es sich nach der Korrektur liest.

Gemäß den Projektrichtlinien ist also nicht nur der korrigierte Buchstabe in Tags gefasst, sondern das ganze Wort. Eine solche Notation ist in der Grundausstattung der TEI nicht vorgesehen. Hier werden ausschließlich die durch die Korrektur betroffenen Zeichen in Tags eingeschlossen. Eine Umschrift der beschriebenen Korrektur könnte demnach folgendermaßen aussehen:

&#x017F;tritte<subst><del><gap reason="getilgt"/></del><add hand='#mk_sr'>s</add></subst>

Zunächst erfolgt die Transkription des Wortanfangs bis ›stritte‹. Erst danach wird die Korrektur angezeigt, eingeleitet mit <subst> für ›substitution‹, gefolgt von <del>-Tags, die eine Tilgung anzeigen. Da nicht mehr ersichtlich ist, was genau getilgt wurde, besteht der Inhalt des <del>-Tags aus einem leeren <gap>-Element. [33] Nach den <del>- folgen <add>-Tags, in denen der hinzugefügte Buchstabe ›s‹ eingeschlossen ist.

Da die projektspezifische Wort-für-Wort-Auszeichnung der Korrekturen zumindest in komplexeren Fällen nicht automatisch in das bevorzugte TEI-Format konvertiert werden kann, [34] stellt die Transformierung hier ein Problem dar. Zwei Lösungsmöglichkeiten sind denkbar: Zum einem könnten die Korrekturstellen in den bereits vorhandenen Transkriptionen nochmals aufgesucht und das Markup dahingehend modifiziert werden, dass auch die einzelnen korrigierten Zeichen erfasst und einander zuordenbar werden. [35] Damit entsteht gleichsam eine Kompromisslösung, die mittels geeigneter Skripte ins reine TEI-Format konvertiert werden kann. Da die Korrekturstellen bereits nach den proprietären Richtlinien eindeutig ausgezeichnet wurden, ließe sich eine solche Nachbearbeitung mit Hilfe von Suchbefehlen mit noch einigermaßen vertretbarem Aufwand bewerkstelligen, dennoch wäre bei Einsatz einer solchen Methode Mehrarbeit aufzubringen.

Weniger zeitintensiv ist demgegenüber zum anderen die Möglichkeit, die TEI-spezifischen Tags zu modifizieren. Eine solche Modifikation wäre bei ausreichender Dokumentation (etwa im Header der Datei) immer noch nachvollziehbar genug, um die projektübergreifende Austauschbarkeit und die Langzeitverständlichkeit der Daten zu gewährleisten, auch dann, wenn die Annotation nicht mehr exakt der ursprünglich intendierten Semantik der TEI-Richtlinien entspricht.

Nach diesem Überblick über ausgewählte Probleme der Datenkonvertierung ergibt sich folgendes Fazit: Aufgrund der Geschichte des Parzival-Projektes war die Frage, ob die Handschriften für die Erstellung der Berner Neuedition mit proprietärem Markup oder nach den TEI-Richtlinien transkribiert werden sollen, schon von vornherein zu Gunsten der ersten Möglichkeit entschieden. Für die Abstimmung auf die standardisierte Auszeichnung ist daher die nachträgliche Datenkonvertierung das Mittel der Wahl. Wollte man die durch die Konvertierung entstandenen Dateien mit den Ausgangsdaten vergleichen, somit Vor- und Nachteile der beiden Formate gegeneinander abwägen, so zeigt sich, dass das proprietäre Markup mitunter flexibler und leichter handhabbar erscheint als die XML‑ beziehungsweise TEI‑Kodierung; dies insbesondere, da Zusatzinformationen im Projekt-Markup unmittelbar in den Elementnamen aufgenommen werden können und nicht in eigene Attribute eingebunden werden müssen. Dieser Eindruck scheint mir auch dann bestehen zu bleiben, wenn man in Rechnung stellt, dass beim nachträglichen Konvertieren der Projektdaten in die TEI-Kodierung auf den Aspekt der Praktikabilität nicht Rücksicht genommen werden musste, und daher manche Auszeichnungen in der TEI-Datei expliziter gestaltet wurden, als dies der Fall wäre, wenn man von Beginn an in diesem Format arbeitet.

Gerade diese Möglichkeit zur Abstufung des Explikationsgrades dürfte sogar zu den über die unmittelbare Notwendigkeit ihrer Anwendung hinausgehenden Vorteilen der Konvertierungsmethode gehören: So wäre es etwa möglich, beim Transkribieren abgekürzte Kodierungen zu verwenden, die mit wenig Aufwand erstellt, danach aber beim Konvertieren automatisch in eine expliziter beschreibende Form gebracht werden können, die wie im Fall der TEI-Kodierung die intersubjektive und dauerhafte Nachvollziehbarkeit der Auszeichnung garantiert. Ob eine solche Vorgehensweise sinnvoll ist, hängt jedoch von den jeweiligen Projektanforderungen ab.

Für den speziellen Fall des Parzival-Projekts stellt die Methode der Konvertierung jedenfalls einen letztlich unumgänglichen, dabei jedoch praktikablen Weg dar, um die Abstimmung auf den TEI-Standard zu gewährleisten. Natürlich erfordert sie einen gewissen Mehraufwand, der aber doch in Grenzen zu halten ist und durch die Vorteile wieder wettgemacht wird, die sich zum einen bei der täglichen Arbeit mit dem leicht zu handhabenden proprietären Markup, zum anderen aber auch durch die unbestreitbaren Vorzüge der TEI-konformen Datenhaltung für deren Langzeitsicherung und Wiederverwertbarkeit ergeben.