TEI in der Praxis

Die Vorzüge elektronischer Editionen[1] als Hilfsmittel für Literaturwissenschaftler sind evident: die schnelle Suche von Zeichenketten über große Textkorpora und die Visualisierung komplexer Textbeziehungen z.B. in historisch-kritischen Ausgaben sowie die Möglichkeit einer weiteren Optimierung der Edition ohne Neusatz des Textes.[2] Allerdings haben elektronische Editionen, die ebenso aufwendig in der Erstellung sind wie ihre gedruckten Gegenstücke, den Nachteil, daß sie längst nicht so lange zur Verfügung stehen.[3] Die schnelle Entwicklung des Hard- und vor allem des Software-Marktes führt dazu, daß Betriebssysteme und Anwendungsprogramme, die zur Präsentation und Auswertung des Textes notwendig sind, nach einiger Zeit nicht mehr oder nur eingeschränkt lauffähig sind. Hauptursache dafür ist die enge Koppelung von Text und Präsentationsprogramm, die bislang üblich und notwendig war. Will man bei der elektronischen Wiedergabe eines Textes nicht nur die bloße Buchstabenfolge festhalten, sondern auch semantische Strukturen, z.B. Überschrift - Text, und typographische Informationen, dann mußte man dazu auf ein Programm zurückgreifen, das diese Informationen wiedergeben kann. Dieses Programm bestimmte dann auch, wie der Text kodiert werden mußte, welche Auszeichnung etwa vor einem Text einzugeben war, damit das Programm diesen als Überschrift behandelt und darstellt.[4] Diese Programme aber können, gerade wenn sie auf die wenig ertragversprechenden Bedürfnisse von Philologen zugeschnitten sind, nur selten den schnellen Produktzyklen des Marktes folgen und verschwinden meist wieder.[5]

In dieser Situation war es ein naheliegender und notwendiger Schritt, sich nach einem Standard umzusehen, der unabhängig von Betriebssystem oder Programm die Kodierung von Texten erlaubt.[6] Gefunden wurde er in der Standard Generalized Markup Language (SGML), die Grundlage der Entwicklung eines Auszeichnungssystems für Philologen, der Text Encoding Initiative (TEI),[7] wurde. Die TEI ist 1987 entstanden als internationale Initiative von Philologen.[8] Da Textwissenschaftler ganz unterschiedlicher Provenienz und Ausrichtung an der Entwicklung von TEI mitgearbeitet haben und in die Version 3 zahlreiche Rückmeldungen von Anwendern eingegangen sind, zeichnet sich der Standard durch Vielseitigkeit und Praxisnähe aus und vor allem ist er gekennzeichnet, von dem Bemühen ein Regelwerk zu bestimmen, daß dem Anwender möglichst viel Freiheit überläßt und möglichst wenige Vorentscheidungen trifft. Der TEI-STandard ist nicht fehlerfrei, aber die Ergebnisse der erneut tagenden Arbeitsgruppen und die Rückmeldungen der Anwender werden auch in Zukunft dahin wirken, durch Anpassungen von TEI Probleme zu beseitigen und die Anwendbarkeit zu erhöhen.

Interessant sind die TEI-Richtlinien für jeden, der einen elektronischen Text in einem dauerhaften Format speichern will. Insbesondere Textwissenschaftler aller Art, z.B. Literaturwissenschaftler oder Linguisten, werden in TEI eine Möglichkeit finden, sich von proprietären Systemen der Textspeicherung (wie z.B. MS-Word) oder von offenen Standards, deren Komplexität den gestellten Aufgaben nicht gewachsen ist (z.B. HTML), frei zu machen.

Die Vielseitigkeit von TEI bedingt eine gewisse Komplexität. Im Rahmen eines Aufsatzes kann der Standard nicht in seinem ganzen Umfang dargestellt werden. Deshalb beschränke ich mich im nachfolgenden auf den Bereich von TEI, der für einen Editor von besonderem Interesse ist. Ausgehend von den typischen Schritten bei der Erstellung einer Computeredition soll die Bedeutung und Relevanz von TEI für jeden einzelnen Schritt untersucht werden. Der Produktionsweg verläuft von der Dokumentenanalyse und Digitalisierung des Materials über die Auszeichnung zur Publikation. Es sollte betont werden, daß nur der letzte Schritt, die Produktion, für eine Druckedition anders aussieht als für eine elektronische. Auch Buch-, Zeitungs- und Zeitschriftenverlage haben in den letzten Jahren festgestellt, daß ihr eigentliches Produkt nicht das Druckerzeugnis ist, sondern die abstraktere Entität Text, die gedruckt oder elektronisch publiziert werden kann. Um eine Mehrfachverwertung des Texts zu ermöglichen, muß dieser in einem Format vorliegen, aus dem sich die möglichen Publikationsformen ohne großen Aufwand generieren lassen. Daher gibt es ein großes Interesse von Verlagen an portablen Textkodierungsformaten wie SGML.

Zwei Arten von Problemen werden im nachfolgenden diskutiert werden: eher allgemeine Fragen, z.B. wie man einen Text mit unscharfer Struktur auszeichnet, ohne allzuviele Informationen zu verlieren, und recht spezielle Fragen, z.B. wie man einen Parser[9] verwendet. Die Diskussion von Fragen der zweiten Art kann manchmal den Anschein erwecken, als ob man nicht nur den Inhalt eines Textes analysiere, sondern auch noch die Probleme thematisieren wolle, die man hatte, als man das Werk aus der Bibliothek ausleihen wollte. Das ist wohl auch prinzipiell richtig. Aber wir benutzen, um im Bild zu bleiben, alle die gleiche Bibliothek und haben deshalb auch ähnliche praktische Schwierigkeiten, deren Lösung darzustellen vielleicht manche Stunde vor dem Computer unnötig machen wird.[10]

Voraussetzungen

Ebenso wie die Arbeit an germanistischen Editionen eine gewisse Bekanntschaft mit den Praktiken der Erstellung solcher Ausgaben voraussetzt, sollte zumindest ein Mitarbeiter in einer Arbeitsgruppe auch für die Arbeit mit TEI einige Vorkenntnisse mitbringen. Eine gewisse Grundkenntnis des SGML-Standards ist erforderlich, um zu verstehen, was die Begriffe Entity, Doctype, Attribut usw. genau bedeuten. Die Kenntnisse müssen im Normalfall allerdings nicht derart sein, daß man selbst die Grammatikdateien (DTDs) schreiben kann, sollten aber die Lektüre einer solchen Datei ermöglichen, da das TEI-Handbuch zur Definition der Auszeichnungselemente (Tags), deren DTD-Definition heranzieht. Stellt sich heraus, daß die TEI-Tags nicht für die Belange des eigenen Projekts ausreichen, so lassen sich die TEI-DTDs erweitern.

Programmierkenntnisse sind zur Erstellung einer elektronischen Edition nicht erforderlich, allerdings lohnt sich bei größeren Projekten sicherlich das Erlernen einer Skriptsprache wie Perl, die speziell für die Textbearbeitung konzipiert wurde und schon nach kurzer Einarbeitungszeit erste Arbeiten ermöglicht. Selbst wenn man vor diesem Schritt zurückschreckt, lohnt es sich zumindest, sich mit den Grundbegriffen von regulären Ausdrücken vertraut zu machen. Sie dienen zur Beschreibung abstrakter Textmuster und lassen sich bei der Textrecherche, vor allem aber bei Suche/Ersetze-Läufen anwenden, um damit die Textauszeichnung wenigstens teilweise zu automatisieren.

Da das TEI-Handbuch, das auch sparsam gedruckt über tausend Seiten umfaßt, etwas abschreckend wirken kann, sei darauf hingewiesen, daß nur die einleitenden Kapitel, die Aufbau und Arbeitsweise erläutern, von allgemeinem Interesse sind, während der große Rest ganz den speziellen Modulen gewidmet ist, von denen jeder Anwender meist nur eins oder zwei benötigt.

Insgesamt sollte die Einarbeitungszeit aber nicht unterschätzt werden. Für kleinere Projekte, insbesondere wenn sie nur mit relativ unkomplizierten Textauszeichnungen arbeiten, sei TEI lite empfohlen, eine abgespeckte Version des Auszeichnungssystems. Diese Version hat viele Vorteile von TEI, ohne den Anwender gleich mit seiner ganzen Komplexität zu konfrontieren.[11]

Einige Grundbegriffe von SGML und TEI

SGML (Standard Generalized Markup Language) ist ein ISO-Standard, mit dem Textauszeichnungssysteme definiert werden.[12] SGML-Konformität eines Auszeichnungssystems garantiert, daß damit aufbereitete Texte von jeder SGML-Software verarbeitet werden können. Beispiele für solche Systeme sind HTML (Hypertext Markup Language), mit der die Dateien im World Wide Web ausgezeichnet werden, und eben auch TEI.

Alle SGML-konformen Systeme bestehen aus drei Teilen, die in eine Datei zusammengefaßt werden können oder aber - was häufiger der Fall ist - separat vorliegen: 1. die SGML Deklaration. Sie enthält eine Reihe von Grundeinstellungen. Unter den Dateien, die das TEI-Projekt zusammengestellt hat, befindet sich auch eine auf die Bedürfnisse des Projekts zugeschnittene Deklaration (TEI.DCL). 2. Eine DTD (Document Type Definition). Sie enthält gleichsam die Grammatik der jeweiligen Auszeichnungssprache. Die TEI-DTD besteht aus mehreren Teilen, die jeweils nach den besonderen Bedürfnissen aktiviert oder deaktiviert werden können.[13] 3. Eine oder mehrere Dateiinstanzen, die entsprechend den Regeln, die in der DTD festgelegt wurden, ausgezeichnet worden sind.

Eine SGML-konforme Auszeichnung besteht im wesentlichen aus einem Element-Wort, das (meistens) in spitze Klammern gesetzt wird:

Die beiden TEI-Elemente im Beispiel, P (für paragraph, also Absatz) und EMPH[14] (für emphasis, Betonung), werden jeweils vor dem so ausgezeichneten Text geöffnet und danach mit einer Wiederholung des Elementnamens, die durch einen Querstrich eingeleitet wird, wieder geschlossen. Die DTD legt fest, an welcher Stelle eines Hierarchie-Baumes welche Elemente verwendet werden dürfen und müssen.

Neben diesen nicht-leeren Elementen gibt es leere Elemente, zu denen kein schließendes Gegenstück existiert:

Das leere TEI-Element <LB> wird zur Markierung eines Zeilenwechsels in Prosatexten einer besonderen Edition verwendet. Wie bei allen leeren Elementen können auch die Korrektheit der Verwendung des Elements <LB> und seine Beziehung zu den anderen Elementen nicht überprüft werden.

Elemente können durch die Angabe von Attributen spezifiziert werden. Im folgenden Beispiel wird durch das Attribut ‘n’ mit dem Attributwert 1 das Element NOTE gezählt:

<P>Auch dieses Kind wurde also am 28. August geboren <NOTE n=1>Anspielung auf Goethes Geburtstag </NOTE>, doch sein Stern ...</P>

Attributangaben werden bei der Schließung des Elements nicht wiederholt. Ein Element kann mehrere Attribute haben; Attributwerte müssen, wenn sie aus Zeichenketten mit Leerzeichen bestehen, in Anführungszeichen gesetzt werden (z.B. <DIV1 type="Kapitel eins">. Die TEI-Richtlinien definieren einige Standard-Attribute, die alle Elemente haben, z.B. ‘id’, mit dem jeden Element eine eindeutige Bezeichnung zugewiesen werden kann. Außerdem haben einige Elementklassen besondere Attribute, so bekommen z.B. alle Elemente nach Aufruf von TEI.transcr die Attribute ‘cert’ und ‘resp’.[15] Attributwerte können entweder optional sein oder notwendig. Welche Attributwerte vergeben werden können, ist zumeist frei, kann aber durch die TEI-Regeln ebenfalls festgelegt sein.

Am Anfang einer Dokumentinstanz verweist man auf die verwendete DTD. Dazu kann man zwei Verfahren wählen, die in der Praxis beide verwendet werden. Erstens kann man den Dokumenttyp angeben und ihn einer Datei auf der Festplatte zuordnen:

Das hat den Vorteil, daß diese Schreibweise einfach zu verwalten ist, hat aber Nachteile. Zum einen wird die Position der DTDs im System festgelegt. In diesem Beispiel muß die DTD etwa im gleichen Verzeichnis sein wie die Dokumentinstanz. Wechselt man auf einen anderen Computer, muß man dieselben Bedingungen erhalten. Außerdem können sich so nur mit einigem Aufwand mehrere Dokumente in verschiedenen Unterverzeichnissen dieselbe DTD teilen. Dazu kommt, daß einige Anwendungsprogramme diese Schreibweise nicht verarbeiten können. Deshalb wird man in diesem Fall eine Schreibweise wie im nachfolgenden Beispiel vorziehen:

Das Schlüsselwort „PUBLIC“ legt fest, daß die Zeichenkette "-//TEI//TEI P3 //EN" die DTD identifiziert. In der Praxis setzt das voraus, daß man auf seinem Rechner eine Datei namens „catalog“ hat, in der dann die Zuordnung von public identifiern und Systemdateien geschieht, z.B.:

Da mehrere SGML-Anwendungen diese Katalogdatei auswerten, kann auf diese Weise die Arbeit vereinfacht werden. Alle Instanzen verweisen auf den public identifier. Wechselt man nun den Rechner mit seinen SGML-Dateien, muß in der Katalog-Datei lediglich der neue Systemstandort festgehalten werden.

Das Regelwerk der TEI besteht aus mehreren DTDs, die nach Bedarf eingesetzt werden können. Die Angaben, welche DTDs man wählt, müssen zum Element DOCTYPE hinzugesetzt werden. Diese Ergänzung der DOCTYPE-Angabe ist faktisch eine Ergänzung der DTD.[17] Will man z.B. das Tag Set für Prosa und das für Textkritik verwenden, muß der Kopf der Datei so aussehen:

<!DOCTYPE TEI.2 SYSTEM "tei2.dtd" [
<!ENTITY % TEI.prose 'INCLUDE'>
<!ENTITY % TEI.textcrit 'INCLUDE'> ]>

TEI regelt mit dieser Verwendung von Entities, welche DTDs für die nachfolgende Dokumentinstanz Geltung haben sollen. Im SGML-Standard wird mit Entities die Verwendung von Platzhaltern definiert, mit denen Zeichen, Zeichenketten oder ganze Dateien mit einem Kürzel repräsentiert werden können. Unterschieden wird zwischen General Entities und Parameter Entities. Die Parameter Entities werden in der DTD definiert und können auch dort nur verwendet werden. Beispielhaft dafür ist das Einbinden der TEI-DTDs. Auf eben diese Weise wird auch ein Zeichensatz gewählt, der die Kodierung deutscher Umlaute unterstützt:

<!DOCTYPE TEI.2 SYSTEM "tei2.dtd" [
<!ENTITY % TEI.prose 'INCLUDE'>
<!ENTITY % isolat1 PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN">
%isolat1; ]>

Die Parameter Entity ‘isolat1’, die auf eine Datei mit einer Reihe von Zeichendefinitionen verweist, wird zuerst aufgerufen und dann durch die Zeichenkette %isolat1; in den Text der DTD eingefügt.

General Entities müssen ebenfalls in der DTD definiert werden, sind aber zur Anwendung in der Dokumentinstanz gedacht. So kann man in der DTD bzw. in der Ergänzung der DTD nach der DOCTYPE-Definition z.B. eine Abkürzung definieren:

General Entities im Text werden mit dem Zeichen & eingeleitet, Parameter Entities dagegen mit %. Beide werden mit einem Semikolon abgeschlossen.

Die Parameter Entity 'isolat1' lädt außerdem einen Zeichensatz, der die Kodierung der deutschen Umlaute erlaubt. Einmal geladen, können nun die deutschen Sonderzeichen als General Entities im Text kodiert werden:[18]

Die Kodierung der deutschen Sonderzeichen beruht auf dem ISO SGML Zeichen Entity Set ISOlat1, das übrigens auch zur Kodierung von HTML-Seiten verwendet wird.[19]

Einrichten einer SGML-Arbeitsumgebung: Damit die verschiedenen Programme gemeinsam auf die DTDs, die Katalogdatei und die Zeichensatz-Entities zugreifen können, müssen Sie die Umgebungsvariable SGML_SEARCH_PATH setzen und dort die verschiedenen Unterverzeichnisse angeben. Z.B. (unter DOS):
set SGML_SEARCH_PATH = c:\tei;c:\tei\dtd;c:\tei\entities
Sowohl der SGML-Parser nsgmls als auch die Softquad-Programme werten diese Umgebungsvariable aus.

Arbeitsschritte zur Herstellung einer TEI-Edition

In den folgenden Abschnitten soll ein Überblick über den Produktionsweg einer elektronischen Edition und die Rolle der TEI-konformen Auszeichnung dabei gegeben werden. Die typischen Arbeitsschritte zur Erstellung einer elektronischen Edition lassen sich - sehr grob - folgendermaßen schematisieren:

1. Dokumentenanalyse. Vor der Erstellung einer Edition auf dem Computer sollten die Editoren aufgrund theoretischer Vorentscheidungen und einer Sichtung des Materials sich möglichst explizit klar darüber werden, welche Textmerkmale durch eine Kodierung erfaßt werden sollen.

2. Digitalisierung. Damit ist sowohl das Erstellen elektronischer Bilder durch Scannen als auch die Textgewinnung durch OCR (Optical Character Recognition) bzw. manuelle Eingabe gemeint.

3. Textauszeichnung. Die Textauszeichnung versieht den gewonnenen Text mit den notwendigen Auszeichnungen, um die Elemente in TEI zu kodieren, die aufgrund der Dokumentenanalyse als bewahrenswert gelten.

4. Publikation. Anpassung des elektronischen Textes an das oder die zur Publikation gewählten Medien, z.B. Browser oder Buchdruck.

Dokumentenanalyse

Der erste Schritt, die Analyse der Textverwendung und damit der Auszeichungsart, kann prinzipiell unabhängig von TEI geschehen. Allerdings erweist sich auch hier die Lektüre der TEI-Handbücher als sehr fruchtbar, da man dort viele Anregungen und Hinweise von erfahrenen Anwendern finden wird. Vor allem geht es jedoch darum, daß die Aufgabe einer Edition möglichst genau spezifiziert wird. Dazu gehören theoretische Grundsatzentscheidungen, wie die Fragen nach den Editionsprinzipien und der Wahl des Apparattyps. Abhängig vom Verwendungszweck der Ausgabe wird man wie üblich ermitteln, welche Texte, welche Handschriften, evtl. auch als Bilder, und welche Materialien einbezogen werden sollen. Für die TEI-Auszeichnung besonders relevant sind die Fragen, welche Textelemente dem Benutzer zugänglich sein sollen, sei es durch eine entsprechende Visualisierung, sei es im Textretrieval. So wird es der Konzeption einer elektronischen Edition sicherlich zugute kommen, wenn der Editor über deren mögliche Verwendungsweisen informiert ist. Anders als gedruckte Editionen, auf die immer lesend zugegriffen wird, kann eine elektronische Edition gelesen werden, aber auch in vielfältiger Weise weiter verarbeitet werden. Sie kann gedruckt werden, man kann ihn ihr suchen, man kann sie automatisch auswerten, z.B. mit Statistikprogrammen.[20]

So wird man bei der Auszeichnung eines Romans nur in Ausnahmefällen darauf verzichten, Kapitel zu markieren. Einzelne Sprecher im Text und ihre direkte Rede wird man allerdings nur dann auszeichnen, wenn der Zugriff auf diese Textelemente den Editoren besonders wünschenswert erscheint. Soll parallel zur elektronischen Edition eine Druckausgabe erscheinen, muß die Auszeichnung auch für diesen Zweck differenziert genug sein und die Ansteuerung jedes typographisch variablen Textelements erlauben.

In der Praxis werden allerdings nicht in allen Fällen nur die selbstgewählten Ziele über die Art der Textauszeichnung entscheiden. Ein Markup mit ‘hoher Tiefenschärfe’ verlangt einigen personellen Aufwand. Schon aus Zeitgründen, von den beschränkten finanziellen Mitteln ganz zu schweigen, wird man sich also oft mit einer ‘niedrigeren Auflösung’ der Auszeichnung bescheiden müssen.[21]

Nachdem definiert ist, was ausgezeichnet werden soll, müssen die dazu notwendigen Tags ausgewählt werden. Wie schon erwähnt, haben die TEI-Entwickler mehrere Tag Sets entworfen. Diese Sets lassen sich in zwei Klassen einteilen: die Base Tag Sets und die Additional Tag Sets. Das Core Tag Set steht in jedem TEI-Dokument zur Verfügung und muß nicht ausdrücklich gewählt werden. Der entscheidende Unterschied zwischen Base Tag Sets und Additional Tag Sets besteht darin, daß man aus der ersten Klasse für ein TEI-Dokument nur ein einziges Set auswählen kann, während aus den zusätzlichen Tag Sets beliebig viele gewählt werden dürfen. Hier ein knapper Überblick über die beiden Klassen:

TEI.mixed: Auszeichnung von Texten, die Tags aus mehreren der anderen Kategorien benötigen.

TEI.general: Wie TEI.mixed, allerdings können innerhalb einer Korpuseinheit nur die Elemente eines Base Tags Sets verwendet werden.

TEI.linking: Auszeichnungselemente, um Texte mit Hyperlinks zu verbinden und um sie zu segmentieren.

TEI.certainty: Elemente, um festzuhalten, mit welcher Sicherheit eine Auszeichnung zutreffend und wer für sie verantwortlich ist.

Will man z.B. Verstexte einschließlich einiger Handschriftenreproduktionen und eines kritischen Apparats auszeichnen und die verschiedenen Fassungen eng mittels Hyperlinks miteinander verbinden, so wird man aus dem Base Tag Set „TEI.verse“ wählen und aus dem Additional Tag Set "TEI.linking", "TEI.transcr", "TEI.textcrit" und "TEI.figures". Der Dateianfang sieht dann so aus:

<!DOCTYPE TEI.2 SYSTEM "tei2.dtd" [
<!ENTITY % TEI.verse 'INCLUDE'>
<!ENTITY % TEI.textcrit 'INCLUDE'>
<!ENTITY % TEI.transcr 'INCLUDE'>
<!ENTITY % TEI.linking 'INCLUDE'>
<!ENTITY % TEI.figures 'INCLUDE'>
<!ENTITY % isolat1 PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN">
%isolat1; ]>

Insbesondere in Projekten, in denen die Textauszeichnung von mehreren Mitarbeitern vorgenommen wird, muß die Entscheidung, welche Textphänomene mit welchen Elementen und Attributen kodiert werden sollen, möglichst früh vereinheitlicht werden, auch wenn ganz sicher im weiteren Fortgang der Arbeit Veränderungen an diesen selbstgesetzten Regeln notwendig werden. Aber nur über solch eine gutdokumentierte Festlegung kann die Konsistenz des Projekts gewährleistet werden. Die Forderung nach Standardisierung und Dokumentation ist für die Attributwerte sogar noch wesentlicher als für Elemente und Attribute, da zumindest die logische Konsistenz (aber nicht die inhaltliche) der letzteren mit einem Programm überprüft werden kann. Attributwerte dagegen sind fast immer frei wählbar und können nur über eine selbstgewählte Nomenklatur vereinheitlicht werden.

Digitalisierung

Der zweite Schritt der Erstellung einer elektronischen Edition soll hier nicht ausführlicher behandelt werden. Wenn Einfluß auf die Gewinnung der Textdaten besteht, dann sollte darauf geachtet werden, daß soviele Informationen wie möglich bei der Digitalisierung erhalten bleiben. Das muß nicht durch die Verwendung von TEI-Kodes geschehen - die Komplexität des Auszeichnungssystems spricht eher gegen so ein Verfahren. Wenn die Textvorlage gescannt wird, dann können moderne OCR-Systeme einen Teil der typographischen Information erhalten, was später dann Ausgangspunkt für eine Automatisierung der Auszeichnung sein kann. Wird der Text manuell erfaßt, kann ein einfaches System, z.B. das Arbeiten mit Druckformaten in einer Textverarbeitung, den Text mit vielen Informationen anreichern, die nachträglich zu erfassen sehr aufwendig wäre.

Für die automatische Kollationierung von bereits elektronisch vorliegenden Texten stehen zumindest zwei Programme zur Verfügung: TUSTEP und Collate. Das Macintoshprogramm Collate, das erst im Laufe des Jahres 1997 als Windowsversion erscheinen wird, bietet - der Produktinformation nach - die Möglichkeit, die Ergebnisse der automatisierten Kollationierung im TEI-Format zu speichern. Auch das Tübinger Produkt TUSTEP wird in Richtung SGML-Verarbeitung erweitert.

Auszeichnung des Textes

Die Textauszeichnung soll unter zwei Aspekten behandelt werden: einmal unter dem eher formalen und technischen Aspekt, wie kann eine gewählte Auszeichnung in den Text eingetragen werden, zum anderen unter dem inhaltlichen Aspekt: Welche Textmerkmale lassen sich in welcher Weise auszeichnen.

Automatische Auszeichnung / Konvertierung

Je mehr Informationen ein Text bereits enthält, um so besser kann die Auszeichnung automatisiert werden. Wesentlich ist wohl nur, daß ein eindeutiges Auszeichnungssystem gewählt wird, mit dem die jeweiligen Bearbeiter komfortabel arbeiten können. Die manuelle Eingabe von TEI-Kodes ist zu aufwendig und fehleranfällig, daher ist der einfachste Weg nach TEI eine eindeutige Auszeichnung der Texte mit irgendeinem Auszeichnungssystem (z.B. als Druckformate in einer Textverarbeitung), das anschließend nach TEI konvertiert wird. Wichtig ist nur die eindeutige Auszeichnung und das Erfassen aller Textelemente.

Robinson berichtet, daß er gute Erfahrungen mit der Konversion von Dateien im RTF-Format hat.[22] Das Projekt „Werke des jungen Goethe“ hat sich dazu entschieden, die Daten in zwei Formaten zu publizieren: Einmal im proprietären Format von Folioviews und dann als TEI-Datei. Nur für die erste Fassung soll auch gleich der Browser mitgeliefert werden. Als die Entscheidung gefällt wurde, standen keine SGML-Browser zur Verfügung, die ähnlich leistungsfähig und zugleich kostengünstig waren. Der Produktionsprozeß sieht im Projekt daher so aus, daß der Text in einer Textverarbeitung kommentiert wird und mit Druckformatvorlagen Informationen zur Textstruktur eingearbeitet werden, die später in Auszeichnungen konvertiert werden sollen. Ein Importfilter von Folioviews erzeugt daraus eine binäre Datei im Folioviews-Format. Diese Datei wiederum kann - unter Beibehaltung aller Informationen - in ein ASCII-Format, eine sogenannte Flatfile, exportiert werden. Daraus wird mittels eines Perl-Skripts der TEI-Text gewonnnen.

Durch eine sorgfältige Analyse der Datei, die nach TEI konvertiert werden soll, auf ihre Regelmäßigkeiten hin können Ansatzpunkte für die Umwandlung ausfindig gemacht werden; dazu gehört auch das Einbeziehen von Leerzeichen, Absatzmarken und Tabulatoren. Jedes wiederkehrende Muster kann zum Ausgangspunkt einer Konversion werden.[23] Allerdings sind für solche Zwecke die Suche/Ersetze-Funktionen von Textverarbeitungen meistens überfordert. Der Bearbeiter wird sich - bei einem umfangreicheren Projekt - mit spezialisierter Software vertraut machen. Aber auch bei kleineren Projekten kann sehr viel Arbeit schon mit den Anfangsgründen von regulären Ausdrücken gespart werden.[24]

Reguläre Ausdrücke erlauben es, nicht nur nach Zeichenketten, sondern nach Mustern von Zeichenklassen zu suchen. So muß für eine Position in der Zeichenkette nicht angegeben werden, welches Zeichen genau dort steht, sondern es kann eine Klasse von Zeichen gesucht werden, z.B. alle Großbuchstaben, alle Zahlen, nur Vokale etc. Außerdem kann man angeben, ob ein Zeichen oder eine Zeichenklasse einmal oder mehrmals vorkommen muß. Will man etwa eine mehrstellige Zahl am Anfang einer Zeile suchen, von der man nicht weiß, wieviele Stellen sie hat, aber daß sie von einem Leerzeichen gefolgt wird, dann kann das mit folgendem Ausdruck geschehen:[25] /^[0-9]+ /. Reguläre Ausdrücke werden von einer ganzen Reihe von Programmen unterstützt. Ein kleines Programm, das sich auch zur Konversion eignet, ist das Unix Utility ‘sed’, das aber auch nach DOS portiert wurde. Sehr viel mächtiger ist die Skript-Sprache Perl.[26] Neben diesen allgemeinen Werkzeugen gibt es zwei Programme, die speziell für den Zweck der Konvertierung von und nach SGML geschaffen wurden: Dynatag (von Electronic Book Technologies) und Omnimark. Omnimark ist allerdings ein sehr komplexes Werkzeug, das sich dem ungeübten Programmierer nicht leicht erschließt. Eine sehr vereinfachte Version von regulären Ausdrücken findet man übrigens schon in der Textverarbeitung Winword 6.0 unter dem Stichwort ‘Mustervergleich’.

Die automatische Auszeichnung kann im Idealfall jede manuelle Auszeichnung überflüssig machen, wenn bereits vor der Konversion alle Textelemente erfaßt wurden. Selbst in dieser besten aller Welten wird aber ein gewisses Nachbearbeiten notwendig sein. In unserer sublunaren Welt werden sich aber zwei Punkte immer wieder als problematisch erweisen: 1. Textauszeichnungen wurden in einer Art und Weise miteinander kombiniert, die mit der Hierarchie-Logik der DTD unverträglich ist. 2. Textelemente wurden nicht disambiguiert. Insbesondere in diesem zweiten Punkt kann die schnelle Übersetzungsleistung der menschlichen Textverarbeitung den Bearbeitern einen Streich spielen; so kann z.B. eine Leerzeile im selben Text den Übergang von Gedichtüberschrift zum Gedichttext, die Strophentrennung und das Ende des Gedichts signalisieren. Typographisch orientierte Programme behalten die Leerzeile bei, was zur Folge hat, daß die unterschiedliche Bedeutung des Zeichens nicht auffällt und erst in der SGML-Auszeichnung zum Problem wird.

Manuelle Auszeichnung

Die manuelle Eingabe von SGML-Texten ist aufwendig und fehleranfällig. Prinzipiell kann man mit jedem Programm, das Texte im ASCII-Format abspeichern kann, seinen TEI-konformen Text erstellen, es gibt aber auch spezielle SGML-Editoren, die Aufwand und Fehlerzahl reduzieren können. Allerdings haben die meisten dieser Editoren den Nachteil, daß der Anwender gezwungen ist, mit einem neuen Programm zu arbeiten - und man kann die Akzeptanz von SGML-Programmen bei Bearbeitern, die auch noch mit Textanalyse und -kommentierung beschäftigt sind, kaum unterschätzen. Deshalb ist für umfangreichere Projekte der oben skizzierte Weg, der eine Eingabe in der gewohnten Umgebung ermöglicht und dann das Ergebnis konvertiert, sicherlich der für alle Seiten befriedigendste. Aber auch für die Nachbearbeitung kann ein SGML-Editor von Nutzen sein, da die meisten die DTD so auswerten, daß Elemente nur dann verwendet werden können, wenn der Kontext es zuläßt.

Zwei Arten von SGML-Editoren sind zur Zeit üblich. Einmal Zusatzprogramme zu Standard-Textverarbeitungen. Nach diesem Prinzip funktionieren z.B. SGML Author von Microsoft und Near&Far Author von Microstar, beide sind als Zusatz zu Winword gedacht. Bevor man diese Programme verwenden kann, muß man jedem Element der DTD ein Druckformat zuweisen. In der Textverarbeitung ordnet man dem Text dann ein Druckformat zu und kann zuletzt seinen Text direkt als SGML-Dokument exportieren. In der Praxis gewinnt man allerdings den Eindruck, daß diese Anwendungen eher für den Umgang mit büroüblichen Textmengen gedacht sind und sich wenig zur Erstellung von Korpora eignen. Eine Ausnahme bildet wohl der SGML-Zusatz zum Editor emacs, der in der Unixwelt weit verbreitet ist.
Die zweite Produktkategorie sind dedizierte SGML-Editoren. Diese Werkzeuge haben immer den Nachteil, daß sie den Anwender in eine fremde Arbeitsumgebung zwingen, aber sie sind deutlich stabiler in ihrem Laufverhalten.[27] Author/Editor der Firma Softquad, ein weiter verbreitetes Programm, visualisiert die Auszeichnungselemente und kontrolliert bei der Eingabe neuer Elemente, ob sie an dieser Stelle erlaubt sind. Allerdings arbeitet Author/Editor nicht direkt mit der DTD, sondern verwendet eine kompilierte Version. Dieses Kompilationsprogramm kann mit der TEI-DTD, wie sie vorliegt, nicht viel anfangen und erwartet eine besonders aufbereitete DTD.
Nicht alle SGML-Editoren und -Browser können mit den TEI-DTDs umgehen, da jene nicht alle von TEI verwendeten Eigenschaften des SGML-Standards unterstützen. Um dennoch mit diesen Programmen arbeiten zu können, muß man eine normalisierte Version der DTD herstellen. Dazu gibt es zwei Möglichkeiten: einmal ein Perlskript,[28] zweitens ein DOS-Programm.[29] Das Perlskript ist etwas einfacher zu handhaben, da man die Tag Sets, die verwendet werden sollen, einfach dem Programm als Parameter beim Aufruf übergibt. Das DOS-Programm arbeitet schneller, allerdings muß man die gewünschten Tag Sets mittels des Include-Befehls, der sonst am Anfang der Dokument-Instanz steht, in der Datei ‘tei2.dtd’ selbst ansteuern.[30]

Textauszeichnung

Von den über 400 Elementen, die von der TEI entwickelt und beschrieben worden sind, soll im nachfolgenden nur eine kleiner Auswahl behandelt werden; eben jene, die sich in der Erstellung einer elektronischen Edition mit einem nicht sonderlich komplexen Apparat als wesentlich erwiesen haben. Jedes TEI-Dokument besteht aus einem Kopf (<TEIHEADER>), der das elektronische Titelblatt darstellt, und dem Textkörper (<TEXT>), der den eigentlichen elektronischen Text enthält, wozu auch das Titelblatt eines gedruckten Werkes zählen würde:

Da die Gestaltung des TEI-Headers in vielen Punkten von der Textauszeichnung abhängig ist, wird man zunächst einen minimalen Header erstellen, der dann im Verlauf der Arbeit ausgebaut wird. Aus diesem Grund wird zuerst die Auszeichung des Textes besprochen und dann die Erstellung des Headers.

Soll eine Gruppe von Texten in einer TEI-Datei kodiert werden, gibt es zwei Wege, abhängig davon, ob jeder der Texte auch ein elektronisches Titelblatt erfordert oder nicht. Ein eigenes elektronisches Titelblatt ist meist nur für heterogene Texte, z.B. Sprachkorpora, erforderlich. Der Aufbau des TEI-Dokuments sieht dann folgendermaßen aus:

<TEICORPUS.2>
<TEIHEADER> [...]</TEIHEADER>
<TEI.2> [...]</TEI.2>
<TEI.2> [...]</TEI.2>
[...]
</TEICORPUS.2>.

Jedes TEI.2 Element hat seinen eigenen Header. DOCTYPE ist in diesem Fall nicht mehr TEI.2, sondern TEICORPUS.2. Für die Kodierung der Werke eines Autors oder eines sonst homogeneren Korpus kann man dagegen den Inhalt des TEXT-Elements weiter differenzieren:

<TEI.2>
<TEIHEADER>
[...]
</TEIHEADER>
<TEXT>
<GROUP>
<TEXT>
[...]
</TEXT>
<TEXT>
[...]
</TEXT>
[...]
</GROUP>
</TEXT>
</TEI.2>

Das TEXT-Element taucht auf zwei Hierarchieebenen auf. Einmal als Gesamtklammer, die alles unterhalb des Headers zusammenfaßt. Außerdem erscheint es als Einheit des Einzeltexts, die mit mit anderen Einheiten durch das GROUP-Element gebündelt wird.

Es hat sich sowohl bei der automatischen als auch der manuellen Auszeichnung als praktikabler erwiesen, den Text nicht Zeile für Zeile mit allen vorgesehen Tags auszuzeichnen, sondern erst einmal die Gliederungselemente und die Grundelemente (meist <P> und <L>) einzutragen. Diese ersten Auszeichnungsschritte können oft auch bei reinen Textdateien, die sonst keine weiteren Informationen enthalten, automatisiert werden. Hat man eine lauffähige Fassung, kann man blockweise immer mehr Informationen eintragen.

Gliederungselemente

Alle nachfolgenden Ausführung dienen der Beschreibung, wie der Inhalt des TEXT-Elements differenziert ausgezeichnet werden kann. Die Auszeichnungselemente zur Gliederung des Textes und auch die für viele komplexere Textmerkmale stehen, sobald man die TEI-DTD aufgerufen hat, automatisch im Core Tag Set zur Verfügung. Der elektronische Text kann, z.B. bei der Wiedergabe von Büchern, in <FRONT><BODY> und <BACK> eingeteilt werden. Unter FRONT würde man z.B. das Titelblatt des Buchs wiedergeben,[31] bei einem Drama den Titel und das Verzeichnis der dramatis personae. Unter BACK würde man Textteile am Ende eines Werks, z.B. ein Glossar, ein Nachwort etc. kodieren. Die Struktur eines einzelnen Textes sieht so aus:

<TEXT>
<FRONT> [...]</FRONT>
<BODY> [...]</BODY>
<BACK> [...]</BACK>
</TEXT>[32]

Die üblichen Untergliederungen von Texten, z.B. Kapitel im Roman, Akte im Drama oder Zyklen bzw. Gruppen in der Lyrik werden alle mit einem generischen Gliederungselement namens DIV repräsentiert. Die Art der Gliederung, ob Kapitel, Brief, Tagebucheintrag, Auftritt, Akt, Szene usw. wird durch ein Attribut festgehalten. Man kann entweder mit numerierten oder mit unnumerierten DIV-Elementen arbeiten. Die numerierten Elemente haben den Vorteil, daß sie leichter zu verwalten sind und nur bei der ersten Verwendung eines DIV-Elements dessen Type angegeben werden muß. Allerdings kann man nicht mehr als die zur Verfügung gestellten acht Ebenen (von DIV0 bis DIV7) verwenden. Unnumerierte DIV-Elemente dagegen können beliebig tief geschachtelt werden, sind aber nicht unbedingt einfach zu verwalten, und bei jeder Öffnung muß das Type-Attribut angegeben werden. Numerierte und unnumerierte DIV-Elemente dürfen in einem FRONT, BODY oder BACK-Element nicht miteinander vermengt werden. Kapitelüberschriften, Aktangaben, Zyklentitel werden mit einem eigenen Element (HEAD) ausgezeichnet. Hier jeweils ein Beispiel:

<BODY>
<DIV1 Type=Werktitel><HEAD>Die Leiden des jungen Werthers</HEAD>[...]
<DIV2 Type=Buch><HEAD>Erstes Buch</HEAD>
<DIV3 Type=Brief><HEAD>Am 4. Mai 1771. </HEAD>
[...] </DIV3>
<DIV3 Type=Brief><HEAD>Am 12. Mai. </HEAD>
[...]</DIV3></DIV2>
<DIV2 Type=Buch><HEAD>Zweites Buch</HEAD>
[...] </DIV2>
</DIV1>
</BODY>

<BODY>
<DIV Type=Werktitel><HEAD>Die Leiden des jungen Werthers</HEAD>[...]
<DIV Type=Buch><HEAD>Erstes Buch</HEAD>
<DIV Type=Brief><HEAD>Am 4. Mai 1771. </HEAD>
[...] </DIV>
<DIV Type=Brief><HEAD>Am 12. Mai. </HEAD>
[...]</DIV > </DIV>
<DIV Type=Buch><HEAD>Zweites Buch</HEAD>
[...] </DIV>
</DIV>
</BODY>

Falls mehrere Überschriften logisch einer Gliederungsebene zugeordnet sind, kann man mehrere HEAD-Elemente verwenden, jeweils differenziert durch ein Type-Attribut:

<DIV1 Type=Werk><HEAD>Die Abenteuer des Don Sylvio von Rosalva</HEAD>
<DIV2 Type=Teil><HEAD>Erster Teil</HEAD>
<DIV3 Type=Buch><HEAD>Erstes Buch</HEAD>
<DIV4 Type=Kapitel>
<HEAD Type=Haupttitel>Erstes Capitel</HEAD>
<HEAD Type=Untertitel>Character einer Art von Taten</HEAD>

Immer wieder wird man bei der Einrichtung einer Texthierarchie feststellen, daß eigentlich mehrere Hierarchien zu berücksichtigen sind, häufig eine inhaltliche, z.B. Werk, Kapitel, Absatz, und eine formale, z.B. Buch, Seite, Zeile. SGML und TEI unterstützen mit CONCUR zwar eine Kodierungstechnik, die mehrere Hierarchien zuläßt, aber sie wird von kaum einem der vorhandenen Programme unterstützt. Deshalb muß man einen Umweg gehen, der noch öfter zu sehen sein wird: Die eine Hierarchie wird wie üblich mit nicht-leeren Elementen ausgezeichnet (z.B. <DIV1> Text Text Text ....</DIV1>), während die andere mit leeren Elementen ausgezeichnet wird. Wie oben schon beschrieben (vgl. S. 4), haben leere Elemente keinen Textinhalt und werden - das ist einer der Nachteile - bei einer Strukturüberprüfung nicht mitgeprüft. TEI stellt für das eben geschilderte Problem einige spezialisierte und ein generisches leeres Element zur Verfügung. Zu den spezialisierten gehören <LB> (Line Break) und <PB> (Page Break), mit denen Zeilen- und Seitenumbruch einer spezifischen Edition kodiert werden können. Das Attribut ‘ed’ erhält als Wert eine Sigle, die auf die Edition verweist. Mit dem Attribut ‘n’ kann die Zahl der Zeile oder Seite angegeben werden:

Das generische Element MILESTONE verwendet ebenfalls das Attribut ‘ed’, um die Edition anzugeben, auf die sich die Unterteilung bezieht. Außerdem muß das Attribut ‘unit’ angegeben werden, um die Art der markierten Einheit festzuhalten:[33]

Textsortenspezifische Auszeichnungen[34]

Ebenfalls dem Core Tag Set angehörig sind die wesentlichen Elemente, um Prosa, Drama, Vers auszuzeichnen. Nicht behandelt werden im nachfolgenden die Auszeichnungselemente für Wörterbücher, linguistische Korpora und Transkriptionen gesprochener Sprache, die von der TEI entwickelt wurden.

Zur Auszeichnung von Prosatext steht das Tag <P> (Paragraph) zur Verfügung. Verseinheiten wie Strophen können mit <LG> (Line Group), Verse mit <L> (Line) ausgezeichnet werden. Für die Auszeichnung von Dramentext gibt es <SP> (Speach), <SPEAKER> und <STAGE>.

<SP><SPEAKER>Bernardo</SPEAKER>Schilt dein Herz nicht, es wird dein Glück machen.</SP>
<SP><SPEAKER>Erwin</SPEAKER>In dieser Welt, Bernardo?</SP>

Sollen nur die Auszeichnungselemente des Core Tag Sets verwendet werden, ruft man das Base Tag Set für Prosa auf, das keine neuen Elemente oder Attribute definiert:

Sollen Dramen und Gedichte detaillierter ausgezeichnet werden und werden zur Auszeichnung mehr Elemente benötigt, als im CORE Tag Set zur Verfügung stehen, dann kann man entweder das Tag Set für Drama oder für Lyrik aufrufen:

Das Base Tag Set für Lyrik definiert das Element <CAESURA> neu, mit dem eine Zäsur in einem Vers ausgezeichnet werden kann, und numerierte <LG>-Elemente, die ähnlich wie die numerierten DIV-Elemente zur Hierarchisierung verwendet werden können. Außerdem werden eine Reihe von Attributen definiert, die zur Kodierung von Reim und metrischem Schema dienen.

Deutlich umfangreicher ist die Erweiterung des Tag Sets durch das Base Tag Set TEI.drama. Drei Klassen von Elementen werden definiert: 1. Elemente zur Kodierung von Textmerkmalen, die unter FRONT oder BACK zu stehen kommen. 2. Elemente zur Kodierung von Bühnenanweisungen aller Art. 3. Diverse andere Elemente u.a. zur Kodierung von audiovisuellen Medien.

Da die Anwendung dieser Elemente außer bei sehr hoher Auflösung normalerweise keine größeren Probleme ergibt, soll sie hier nicht ausführlicher behandelt werden.[35]

Handschriften- und Apparat-Elemente

Eine angemessen komplexe Auszeichnung von Textveränderungen in Handschriften verwendet auch Elemente des Tag Sets zur Auszeichnung textkritischer Apparate. Deshalb sollen hier beide zusammen behandelt werden. Um die beiden Tag Sets einzubinden, müssen folgende Anweisungen gegeben werden:

Im nachfolgenden sollen in einem ersten Block alle Tags behandelt werden, die zur Auszeichnung von Veränderungen in Handschriften herangezogen werden können. Insbesondere werden Streichung, Hinzufügung, Ersetzung und Auslassung ausführlicher dargestellt, da sie wohl wesentliche Werkzeuge für einen Editor sind.

Streichung, Einfügung und Ersetzung

Streichung kann mit zwei Elementen ausgezeichnet werden: <DEL> und <DELSPAN>. <DEL> ist ein nicht-leeres Element und kann überall dort herangezogen werden, wo die Streichung keine Hierarchiegrenzen überschreitet und keine weiteren Streichungen enthält.

rend (rendition): Gibt wieder, wie die Streichung vorgenommen wurde. Mögliche Werte sind: „subpunction“ (Streichung durch Punkte unter dem zu Streichenden); „overstrike“ (Streichung durch Linien durch den Text); „erasure“ (Streichung durch Textlöschung); „bracketed“ (Streichung durch Verwendung von Klammern).

type: Gibt in einer freigewählten Typologie die Art der Streichung an. Die Art der Streichung soll allerdings durch das Attribut ‘rend’ wiedergegeben werden.

status: Dient zur Angabe, ob die Streichung fälschlicherweise links oder rechts zu wenig oder zuviel Text erfaßt hat.

resp: Gibt an, wer für die Angabe des Ursprungs der Streichung (mit dem Attribut ‘hand’) verantwortlich ist; muß sich auf einen Editor beziehen, der im Header definiert wurde.

cert (certainty): Gibt an, wie sicher die Angabe über den Ursprung der Streichung ist.

Wenn Text aufgrund einer Streichung nicht mehr leserlich ist, soll nicht das Element DEL verwendet werden, sondern <OMIT>. Mit DEL sollen keine Streichungen markiert werden, die von den Editoren stammen, sondern nur solche, die sich in der Quelle finden.

<DEL rend=overstrike type=Gesamtstreichung>Elegien<LB>Erotica Romana<LB>-----------<LB>Rom<LB>1788</DEL>

Wie schon erwähnt, soll und kann DEL nicht in allen Fällen einer Streichung verwendet werden. So ist z.B. folgende Auszeichnung falsch:

<L><DEL> Wie er die seltsame Gruppe muthwillig geordnet so läuft er </L>
<L>Eilig und rufet: Herbey!</DEL> herrliche Thaten geschehen!</L>

Das Element DEL kreuzt sich hier mit dem Element L, und das ist in TEI nicht möglich - außer wie gesagt bei der Verwendung von Concurrent Structures, die allerdings hier auch nicht viel helfen würden. Geht die Streichung über Hierarchiegrenzen hinweg oder umfaßt sie mehrere Streichungen und Hinzufügungen muß das Element DELSPAN verwendet werden. Die Attribute von DELSPAN sind identisch mit denen von DEL, allerdings mit zwei Ausnahmen: 1. DELSPAN muß immer mit dem Attribut ‘to’ ausgezeichnet werden. Da DELSPAN ein leeres Element ist, kann das Ende der Streichung nicht mit </DELSPAN> ausgezeichnet werden, sondern muß mit dem Attribut ‘to’ markiert werden:

Falls sich am Ende der Streichung kein Element befindet, auf dessen ID mit dem Attribut ‘to’ gezeigt werden kann, muß das Element ANCHOR verwendet werden:[36]

<L><DELSPAN to=SE1> Wie er die seltsame Gruppe muthwillig geordnet so läuft er </L>
<L>Eilig und rufet: Herbey!<ANCHOR id=SE1> herrliche Thaten geschehen!</L>

Der zweite Unterschied zwischen DEL und DELSPAN betrifft die Kodierung der Streichungsart. Was im Falle von DEL mit dem Attribut ‘rend’ wiedergegeben wurde, muß aus unerfindlichen Gründen im Fall von DELSPAN mit ‘type’ wiedergegeben werden.

Ein weiteres Problem der Verwendung von leeren Elementen wie DELSPAN besteht darin, daß die getesteten Browser es nicht auswerten können. Deshalb liegt es nahe, eine Schreibweise zu wählen, die einerseits den Gesamtumfang einer Streichung mit DELSPAN markiert, gleichzeitig aber das DEL Element innerhalb der einzelnen Textelemente verwendet:

<L><DELSPAN to=SE1><DEL> Wie er die seltsame Gruppe muthwillig geordnet so läuft er </DEL</L>
<L><DEL>Eilig und rufet: Herbey!</DEL><ANCHOR id=SE1> herrliche Thaten geschehen!</L>

Man mag gegen dieses Verfahren einwenden, daß es um der Darstellung willen von den TEI-Vorschlägen etwas abweicht, allerdings sind die TEI-Richtlinien in diesem Punkt selbst schon ein Workaround und aufgrund der technischen Notwendigkeiten des SGML Standards nicht homogen, da das gleiche Textphänomen einmal mit einem nicht-leeren und dann mit einem leeren Element ausgezeichnet werden soll, abhängig von dem Umstand, ob durch die Streichung eine Elementgrenze überschritten wird oder nicht. TEI bietet oft von vornherein Möglichkeiten, überschneidende Hierarchien wie in diesem Fall zu vermeiden, allerdings auf Kosten der Auszeichnungsstringenz und auch auf Kosten der Visualisierungsmöglichkeiten. Insgesamt taucht dieser Punkt der konkurrierenden Hierarchien immer wieder in der TEI-Diskussion auf und steht auf der Agenda des Standardisierungsgremiums.[37]

Eine Einfügung wird mit den Elementen <ADD> oder <ADDSPAN> ausgezeichnet. Es besteht die gleiche Problemlage wie im Fall von DEL. Einfügungen, die Hierarchiegrenzen überschreiten, müssen mit ADDSPAN ausgezeichnet werden, und über einen Zeigermechanismus wird das Ende der Einfügung markiert.

Folgende Attribute stehen bei der Verwendung von ADD und ADDSPAN zur Verfügung:

place: Gibt den Ort des eingefügten Textes an. Vorgeschlagene Werte[38] sind: inline (in eine Lücke, die in der Zeile vom Schreiber gelassen wurde, eingefügt); supralinear (über der Zeile); infralinear (unter der Zeile); left (linker Rand); right (rechter Rand); top (oberer Rand); bottom (unterer Rand); opposite (gegenüberliegende Seite); verso (Rückseite); mixed (irgendwo sonst, einer oder mehrere Werte)

resp: Der Verantwortliche für die Identifizierung des Schreibers der Einfügung. Muß im Header angegeben sein.

hand: Schreiber der Einfügung. Muß als einer der möglichen Schreiber im TeiHeader angegeben sein, dort auch die Auflösung der verwendeten Siglen.

<L>Laß dich Geliebte nicht <ADD place=supralinear hand=JWG>reu’n</ADD> daß du so schnell dich ergeben,</L>
[...]
<L> [...] Verstehst du nun Geliebte den Wink.</L>
<ADDSPAN place=bottom to=Ende>
<L>Jene buschige Myrthe beschattet ein heiliges Plätzchen</L>
<L>Unsre Zufriedenheit bringt keine Gefärde der Welt.</L><ANCHOR id=Ende>

Um Streichungen in Streichungen und Einfügungen in Einfügungen auszuzeichnen, können die Elemente geschachtelt werden. Empfohlen wird dazu immer die Verwendung von DELSPAN bzw. ADDSPAN, doch kann man, wenn keine Elementgrenzen überschritten werden, auch DEL und ADD schachteln.

Einen Sonderfall der Streichung und Einfügung stellt die Ersetzung dar, die beide Elemente miteinander kombiniert. Die TEI hat kein eigenes Element dafür definiert, sondern schlägt mehrere Möglichkeiten vor, Ersetzungen auszuzeichnen. Leider haben alle gewisse Nachteile.

Strassen redet ein Wort! Genius <CORR resp=JWG sic= "rührst">regst du dich nicht?</L>[39]

Mit dem Element CORR kann sofort angezeigt werden, daß "regst" eine Ersetzung von "rührst" ist. Allerdings hat CORR kein besonderes Attribut, um die Art der Streichung und die Form der Einfügung zu markieren. Diese Informationen können mit den Elementen ADD und DEL notiert werden:

Genius <DEL hand=JWG type=durchgestrichen>rührst</DEL>
<ADD hand=JWG place=superlinear>regst</ADD> du dich nicht?</L>

Das TEI-Handbuch weist zu Recht daraufhin, daß dieses Verfahren den Nachteil hat, die Einfügung nicht deutlich als Ersatz für das Gestrichene zu markieren, und macht einen dritten Vorschlag, der die Vorteile der ersten und zweiten Möglichkeit miteinander verbinden soll:[40]

Genius
<APP>
<RDG hand=JWG><DEL type=durchgestrichen>rührst </DEL></RDG>
<RDG hand=JWG><ADD place=superlinear>regst </ADD></RDG>
</APP>
du dich nicht?</L>

Das Element <APP> dient dazu, einen Apparateintrag auszuzeichnen. In APP können entweder ein oder mehrere RDG (Reading = Lesarten bzw. Varianten) oder RDGGRP (Reading group) stehen. Auf diese Weise lassen sich die beiden Worte aufeinander beziehen. Der Nachteil dieser letzten Methode ist offensichtlich der Aufwand, den man für eine Auszeichnung betreiben muß.

Noch in einem weiteren Punkt erweist sich dieser letzte Vorschlag als nicht ganz befriedigend: Die Zusammengehörigkeit von Arbeitsschritten kann nur sehr aufwendig über ein vom Editor erstelltes Siglensystem markiert werden, das dann über das generische Attribut 'type' in den Text eingebracht wird. Zwar kann man die Reihenfolge von Variationen mit dem Attribut 'varSeq' festhalten, doch wird dadurch nur etwas über diese eine Sequenz ausgesagt:

Genius
<APP>
<RDG hand=JWG varSeq=1><DEL type=durchgestrichen>rührst </DEL></RDG>
<RDG hand=JWG varSeq=2><ADD place=superlinear>regst </ADD></RDG>
</APP>
du dich nicht?</L>

Auf diese Weise muß eine automatische Auswertung der Auszeichnung nicht mühsam über die Bedeutung von DEL unterrichtet werden, sondern kann einfach die gewünschte Sequenzstufe auslesen. Doch ist damit, wie gesagt, nur eine sehr lokalisierte Sequenz beschreibbar. Offensichtlich zusammenhängende Varianten, z.B. weil sie nur gemeinsam eine grammatisch korrekte Konstruktion ergeben, die sich aber dennoch nicht nur an einer Textstelle befinden, lassen sich nur mit Aufwand aufeinander beziehen. Die TEI-Richtlinien sehen dafür keine Konstruktion vor. Ein etwas vereinfachtes Beispiel mag diesen Punkt illustrieren. Goethe hat die Verse: "Dulde mich Jupiter hier und Hermes führe mich später / Die Pyramide vorbey leise zum Orcus hinab." korrigiert und geändert zu "leise dem Orcus ins Reich", indem er das Wort "zum" gestrichen und darüber "dem" gesetzt und ebenso "hinab" gegen "ins Reich" ausgetauscht hat. Diese Eingriffe könnten so kodiert werden:

<L>Die Pyramide vorbey leise
<DEL>zum</DEL>
<ADD>dem</ADD> Orcus
<DEL>hinab</DEL>
<ADD>ins Reich</ADD>.</L>

Wie aber kann der Editor die Information, daß die beiden Veränderungen Teil eines einzigen Arbeitsschrittes waren, in die Kodierung mit aufnehmen? Auch eine ausführlichere Auszeichnung, die mit den Elementen APP und RDG arbeitet, kann nur die jeweils ersetzten Elemente aufeinander beziehen oder bezieht das Satzglied insgesamt aufeinander:

<L>Die Pyramide vorbey leise
<APP><RDG><DEL>zum</DEL> Orcus <DEL>hinab</DEL></RDG>
<RDG><ADD>dem</ADD> Orcus <ADD>ins Reich</ADD></APP>
.</L>

In dieser Form wird der Zusammenhang deutlich, aber es wurde ein künstlicher Text geschaffen, da das Wort "Orcus" in der Handschrift ja nur einmal steht. Hier zeigt sich ein deutlicher Mangel der augenblicklichen TEI-Richtlinien. Deren Kapitel über die Auszeichnung eines textkritischen Apparats, in dem die Arbeitsweise von RDG beschrieben wird, beschränkt sich fast ausschließlich auf die Behandlung eines Apparats, in dem verschiedene Quellen wiedergegeben werden. Diese Einseitigkeit zeigt sich auch in der Definition der Elemente und Attribute. Man kann mit den generischen Auszeichnungselementen, die die Tag Sets für Simple Analytic Mechanisms und die Feature Structures zur Verfügung stellen, auch die Phänomene von Arbeitshandschriften auszeichnen, ebenso kann man mit dem Attribut 'type' eine Klassifikation der Textveränderungen, z.B. "Sofortkorrektur" usw., in den Text eintragen, aber die Differenziertheit, die die TEI-Richtlinien in anderen Bereichen auszeichnet, ist für den Bereich der Trankription von Arbeitshandschriften noch nicht erreicht. Es bleibt zu hoffen, daß die Überarbeitung der TEI-Guidelines diesen Mangel beheben wird und auch die Auszeichnung von Arbeitshandschriften und die Probleme bei der genetischen Rekonstruktion stärker berücksichtigen wird.[41]

Werden mehrere Quellen ausgezeichnet, z.B. um sie auf einen Basistext zu beziehen, dann wird bei den Varianten mit dem Attribut 'wit' auch die jeweilige Quelle angeben:

<P >Zu Ende des vorigen Jahrs machte ich eine Reise
<APP>
<RDG wit=H2>Serenissumum <ADD hand=g> meinen gnädigsten Herrn </ADD></RDG>
<RDG wit=C>Serenissimum </RDG>
nach Leipzig zu begleiten;

Die hierbei verwendeten Siglen müssen wiederum aufgelöst werden. Das geschieht mit den Elementen <WITLIST> und <WITNESS>, am besten im FRONT Element des Textes:

<TEXT>
<FRONT>
<DIV Type="Liste der Textzeugen">
<WITLIST>
<WITNESS sigil=H1>Erste Handschrift</WITNESS>
<WITNESS sigil=C>Druck in der Ausgabe letzer Hand </WITNESS>
</WITLIST>
</DIV>
</FRONT>
<BODY>

Hypertext [42]

Hypertext-Mechanismen sind für die Erstellung einer kritischen Edition in zwei Hinsichten wichtig. Erstens läßt sich auf diese Weise der Text und mit dem Apparat verknüpfen. Zweitens können so Text-, Bild-, Audio-, Film- und Programmelemente miteinander verknüpft werden. Im nachfolgenden soll vor allem das Problem, wie Text und Apparat verbunden werden können, behandelt werden. Anschließend wird das TEI-eigene Modell zur Beschreibung von Sprungmarken innerhalb eines Textes, aber zu externen Datenquellen kurz umrissen.

Die Tags zur Auszeichnung von textkritischen Apparaten sind so konzipiert worden, daß sie so weit wie möglich unabhängig von einem bestimmten Modell des Apparats oder einer Editionstheorie sind. So gibt es z.B. mehrere Möglichkeiten den Apparat mit dem Text zu verbinden ebenso wie mehrere Möglichkeiten, Varianten zu notieren.

Die einfachste Möglichkeit ist die Verwendung des Elements <NOTE>. Damit werden einem Textelement weitere Informationen zugeordnet:

<P id="werther22" > [...] und sagte ihr alles was ich mußte<NOTE resp=„Editor“>Der erste und der zweite Druck haben „mußte“, im dritten Druck entstellt zu „wußte“</NOTE>, und bemerkte erst nach einiger Zeit, da Lotte das Gespräch an die andern wendete, daß diese die Zeit über mit offnen Augen, als säßen sie nicht da, da gesessen hatten. [...]</P>

Das Attribut „resp“ (responsible) erlaubt es zu notieren, wer für die Anmerkung zuständig ist. Mit <NOTE resp=„Autor“> werden Anmerkungen des Autors, in diesem Fall also Goethes, ausgezeichnet. Um die Bearbeitung übersichtlicher zu gestalten, kann man die Anmerkungen sammeln, zum Beispiel am Ende der Datei, und mit dem Attribut „target“ auf den Bezugspunkt verweisen. Das Attribut verwendet als Wert eine ID-Angabe. Sollte wie im Beispiel keine ID eine präzise Lokalisierung der Anmerkung erlauben, kann man mit den Elementen <ANCHOR> oder <SEG> einem Punkt im Text oder einer Textspanne eine ID zuweisen, die dann als Sprungziel verwendet werden kann:

[...] reden hörte, kam ich eben ausser mich und sagte ihr alles was ich <SEG ID=„Anmerkung122“>mußte<SEG>, und bemerkte erst nach einiger Zeit
[...]
<NOTE resp=„Editor“ target=„Anmerkung122“>Der erste und der zweite Druck haben „mußte“, im dritten Druck entstellt zu „wußte“</NOTE>[43]

Das Element <NOTE> wird in Browsern meist als Pop-up realisiert, das heißt, ein optisches Signal verweist auf die Existenz von weiteren Informationen. Durch eine Benutzeraktion, z.B. ein Mausklick, öffnet sich dann ein zusätzliches Fenster, das den Text der Anmerkung enthält. Im Prinzip sehr ähnlich funktioniert das Springen zu einer anderen Stelle der Datei oder zu einer anderen Datei, wo sich dann die Anmerkungen als laufender Text befinden.

Der Vorteil dieser Methode ist der geringe Grad an Formalisierung, der notwendig wird. Allerdings wird es eben dadurch auch unmöglich gemacht, sehr präzise auf den Text zuzugreifen. Die Methoden, die im nachfolgenden beschrieben werden, erlauben es, sehr viel präziser das Verhältnis von Text und Apparat zu bestimmen und - zwei von ihnen - die Textfassung eines der Zeugen wiederherzustellen.

Drei Methoden schlägt das TEI-Handbuch vor, die kurz vorgestellt werden sollen: Die Location-Referenced Methode, die Double End-Point Methode und die Parallel Segmentation Methode.[44]

Die Location-Referenced Methode entspricht dem Apparat einer gedruckten Edition insofern, daß der Apparat nur über eine ungefähre Ortsangabe, z.B. Zeile oder Satz, mit dem Text verbunden ist. Das kann den Nachteil haben, daß sich nicht vollkommen automatisch alle Zeugen rekonstruieren lassen, selbst wenn man mit dem Element <LEM> (lemma) den präzisen Ort der Verknüpfung angibt:

<P>Zu Ende des vorigen Jahrs machte ich eine Reise
<APP>
<LEM wit=C>meinen gnädigsten Herrn</LEM>
<RDG wit=H2>Serenissimum</RDG>
<APP>
nach Leipzig zu begleiten; [...]</P>

Vorteil dieser Methode ist ihre relativ einfache Umsetzung, besonders wenn man eine bereits existierende gedruckte Edition elektronisch aufbereiten möchte. Der Apparat kann auch extern gelagert werden und kommt damit einer Druckedition sehr nahe:

<P id=1>Zu Ende des vorigen Jahrs machte ich eine Reise meinen gnädigsten Herrn nach Leipzig zu begleiten; [...]</P>
[... ]
<APP>
<LEM wit=C>meinen gnädigsten Herrn </LEM>
<RDG wit=H2>Serenissimum</RDG>
<APP>

Diese Einfachheit wird, wie erwähnt, mit dem Nachteil erkauft, daß die Zeugen nicht automatisch rekonstruiert werden können. Die beiden anderen Methoden haben diesen Nachteil nicht, allerdings wächst noch einmal die Komplexität der Auszeichnung. Die Double-End-Point Methode gibt im Apparatelement die Anfangs- und die Endadresse der Variante im Basistext an. Läßt sich die Adresse nicht über bereits im Text vorhandene IDs angeben, muß man mit dem ANCHOR-Element diese Eckpunkte erst setzen.[45] Hier ein Beispiel für eine externen Apparat:

<P n=2 id=TuJH1796>Zu Ende des vorigen Jahrs machte ich eine Reise <ANCHOR id=Anfang >meinen gnädigsten Herrn <ANCHOR id=Ende>nach Leipzig zu begleiten; [...]</P>
[...]
<DIV1><HEAD>Apparat</HEAD>
<P><APP from="Anfang" to="Ende">
<RDG wit=H2>Serenissimum</RDG>
</APP>

Der gewählte Basistext muß nicht mehr im Apparat angegeben werden, kann aber z.B. mit dem Element LEM noch einmal ausdrücklich aufgeführt werden. Vorteil dieser Methode ist ihre Flexibilität; man kann mit ihr z.B. überlappende Varianten erfassen. Nachteil ist die Festlegung auf einen Bezugstext. Die Parallel-Segmentation Methode kann keine überlappenden Varianten wiedergeben, verzichtet andererseits wiederum auf die Konstruktion eines Basis-Texts.[46] Die existierenden Alternativen eines Textelements werden im Text angegeben. Diese Methode kann also keinen externen Apparat haben:

<P id=1>Zu Ende des vorigen Jahrs machte ich eine Reise
<APP>
<RDG wit=C>meinen gnädigsten Herrn</RDG>
<RDG wit=H2>Serenissimum</RDG>
<APP>
nach Leipzig zu begleiten; [...]</P>

Ein Text, der mit dieser Methode aufbereitet wurde, kann in einem Browser so dargestellt werden, daß der Benutzer sich mit einem Knopfdruck jeweils eine Quelle als Basistext und die anderen als Apparat darstellen lassen kann.

Um solch eine Darstellung zu erzielen, muß man für jede Quelle, die als Basistext dienen soll, ein eigenes Stylesheet[47] für den Browser entwerfen. Entscheidend für die richtige Darstellung sind die jeweilen Zeugenangaben durch das Attribut 'wit'. Die Formatierung und Darstellung muß so definiert werden, daß sie vom Wert dieses Attributs abhängig ist. Der Basistext wird dann für eine normale Anzeige definiert, während die anderen als Popup-Fenster definiert werden. Über die Definition des Stylesheets würde man auch für die anderen Methoden festlegen, was als zusätzliches Fenster angezeigt werden soll, z.B. indem man dem Element APP die Definition Popup zuordnet.

Mit TEI kann man den Text mit sehr geringem Aufwand zu einem Hypertext machen. Zur Erstellung von Hypertext-Links bietet TEI vier Elemente; zwei Elemente (REF und PTR), die zur Verbindung von Textelementen innerhalb einer Datei geeignet sind, und zwei Elemente (XREF und XPTR), die zur Verknüpfung von Elementen in verschiedenen Dateien dienen.

REF ist ein nicht-leeres Element und PTR ein leeres. Ansonsten ist die Funktionsweise identisch: Mit dem Attribut 'target' wird das Ziel der Sprungmarke angegeben. Als Attributwert muß eine ID angegeben werden:

<P>Siehe dazu unten <REF target=Kap9>Kapitel 9</REF>
[...]
<DIV 2 type=kapitel id=Kap9><HEAD>Kapitel 9</HEAD>

Um einen gegenseitigen Verweis von zwei Textstellen aufeinander zu kodieren, kann man das Element LINK verwenden, dem als Attributwerte die beiden Referenzen übergeben werden:

<P id=A1>Siehe zum Vergleich auch die Ausführungen unten</P>
[...]
<P id=A2>Siehe zum Vergleich auch die Ausführungen oben</P>
[...]
<LINK target="A1 A2">

Sprungmarken in andere Dateien sind etwas komplizierter, da zum einen der Name der Zieldatei kodiert werden muß, zum anderen nicht immer von einem TEI-, ja nicht einmal von einem SGML-kodierten Text als Zieldatei ausgegangen werden kann. XPTR und XREF bieten ausgesprochen viele Möglichkeiten und ihre Arbeitsweise ist entsprechend komplex. Hier soll nur die einfachste Form besprochen werden, nämlich der Sprung in eine andere Datei zu einem Element mit einer bekannten ID.

<P>Siehe dazu unten <XREF doc=Buch1 from=id (Kap9)>Kapitel 9</REF>
[In einer anderen Datei:]
<DIV 2 type=kapitel id=Kap9><HEAD>Kapitel 9</HEAD>

Der Attributwert von 'doc' ist kein Dateiname, sondern eine Entity, die im Header definiert werden muß, um auf eine Datei zu verweisen. Diese Angabe könnte für das Beispiel so aussehen:

Erst durch diese Definition kann man in den Elementen XREF oder XPTR auf die externe Datei zugreifen.

Das einzige Darstellungsprogramm für SGML-Dateien, das im Augenblick die Syntax von XREF/XPTR unterstützt ist Panorama. Damit dort das XREF-Element als Extended Pointer erkannt wird, muß man außerdem eine weitere Befehlszeile in der DTD hinzufügen:
<?TAGLINK xref "TEI-P3">
<!ENTITY buch1 SYSTEM "Kap9.sgm" NDATA SGML>

Auf diese Weise kann man direkt auf bestimmte Elemente zugreifen, aber auch auf Elemente in einer Hierarchie oder sogar eine Zeichenfolge abgeben, nach der in der Zieldatei gesucht werden soll. Auch hier gilt, was auch die Diskussion bislang bestimmt hat: Nur die wesentlichen Prinzipien der Arbeit mit TEI sollen hier besprochen werden, um den Einstieg zu erleichtern und einige typische Probleme anzusprechen - die Komplexität und damit auch der Reichtum an Möglichkeiten erschließt sich erst mit der Zeit und einer genauen Lektüre des Handbuchs.

TEI-Header

Wie bereits erwähnt, besteht ein TEI-Dokument aus zwei Komponenten: dem Textkörper und dem TEI-Header. Bislang wurde nur der Körper besprochen, der mit <TEXT> und </TEXT> umschlossen ist. Davor steht der HEADER:

Ein TEI-Header hat die Funktion, das digitale Titelblatt der elektronischen Edition zu sein. Dazu zählen als Minimum Angaben über den Autor und den Editor des Textes und seinen Titel. Man kann allerdings auch die Verwendungsweise aller Elemente, Angaben über die Kodierungsprinzipien und weitere Zusatzinformationen im Header angeben. Im nachfolgenden sollen nur die Elemente des Headers besprochen werden, die obligatorisch sind, und diejenigen, die für einen Editor von besonderem Interesse sind. Die Grundstruktur sieht so aus (obligatorische Elemente sind fett gedruckt):

Das obligatorische Element <FILEDESC> enthält alle bibliographischen Angaben zum elektronischen Text. Unter <ENCODINGDESC> kann die Beziehung zwischen elektronischem Text und Vorlage dokumentiert werden. <PROFILEDESC> versammelt Angaben zur Entstehung, zur verwendeten Sprache, zu Schlagworten nach einem Bibliothekssystem und - wenn das Tag Set für die Transkription von Primärquellen gewählt wurde - zu den Schreibern der Quellen. Mit <REVISIONDESC> kann die Überarbeitungsgeschichte des Textes festgehalten werden.

<TEIHEADER>
<FILEDESC>
<TITLESTMT>
<TITLE>Titel des Werks: elektronische Edition</TITLE>
<AUTHOR>Autor des Werks</AUTHOR>
<RESPSTMT>
<RESP>erstellt von</RESP> <NAME>Name des Editors</NAME>
</RESPSTMT>
</TITLESTMT>
<PUBLICATIONSTMT>
<PUBLISHER> Vertrieb des Textes durch XXX</PUBLISHER>
</PUBLICATIONSTMT>
<SOURCEDESC>
<BIBL>Bibliographische Angaben zur Vorlage</BIBL>
</SOURCEDESC>
</FILEDESC>
</TEIHEADER>

Für die oben behandelten Mechanismen zur Auszeichnung von Quellen sind zwei Ergänzungen notwendig. Die Art der Verbindung zwischen Apparat und Text muß im Header angegeben werden:

<ENCODINGDESC>
<variantEncoding method="double-end-point" location=external>
</ENCODINGDESC>[48]

Erlaubte Attributwerte für 'method' sind "location-referenced", "double-end-point" und "parallel-segmentation", die den oben beschriebenen Methoden zur Verbindung von Apparat und Text entsprechen. Das Attribut 'location' kann als Wert entweder "internal" oder "external" haben, abhängig davon, ob der Apparat direkt am Lemma ausgezeichnet worden ist, oder ob er sich in einer anderen Datei oder an einer anderen Stelle der Datei befindet.

Die Angaben darüber, wer eine Streichung oder eine Einfügung vorgenommen hat, und auch für andere textkritische Auszeichnungen werden mit dem Attribut 'hand' ausgezeichnet. Dabei werden üblicherweise Siglen verwendet, deren Auflösung ebenfalls im Header definiert werden muß:

Der Header sollte insgesamt zur Speicherung aller relevanten Informationen zum Dokument dienen. Insbesondere die Kodierungsprinzipien können hier angegeben werden. Dazu zählen Informationen zur spezifischen Verwendung generischer Elemente und vor allem auch eine Liste der gewählten Attributwerte, wenn diese frei wählbar waren, und deren Bedeutung.

Überprüfung der Auszeichnung

Um die Übereinstimmung der Auszeichung mit den Regeln der TEI-DTDs zu überprüfen, verwendet man einen sogenannten Parser. Dieses Programm kann entweder Teil eines Editors sein (z.B. in Author/Editor) oder eigenes Programm. Ergebnis eines Parserlaufs, den man meist schon nach jeder neu eingebrachten Auszeichnungsstruktur machen sollte, ist am Anfang der Arbeit, in ihrer Mitte und auch noch sehr kurz vor dem Ende eine mehr oder weniger umfangreiche Fehlerliste.

Ein sehr beliebter Parser ist nsgmls von James Clark, da das Programm für mehrere Plattformen erhältlich, sehr robust und außerdem kostenlos ist.[50] Nsgmls wertet die Umgebungsvariable SGML_SEARCH_PATH aus, um eine Katalog-Datei zu finden. Das Programm erstellt, wenn man ihm als Argument den Namen der Dokumentinstanz übergibt, daraus eine Datei nach dem ESIS-Format.[51] Da man meistens nur an den Fehlermeldungen interessiert sein wird, ruft man das Programm (unter DOS) so auf:
nsgmls -s -ferror.txt datei.sgm
Der Schalter -s unterdrückt die Erstellung der Ausgabe, so daß nur die Fehlermeldungen angezeigt werden. Mit dem Schalter -f erzwingt man die Ausgabe der Fehlermeldungen in die nachstehende Datei; im Beispiel also error.txt. Bearbeitet wird die Datei datei.sgm.
Um sich während der Auszeichnung ein Bild der Elementhierarchie einer DTD zu machen, kann man DTD-Visualisierungen verwenden. Near&Far lite von der Firma Microstar[52] zeigt den Aufbau einer DTD als Baumstruktur an und erlaubt das selektive Expandieren und Minimieren der einzelnen Äste. Auf diese Weise kann man sich ein Bild von den erlaubten Positionen eines Elements machen.

Am Ende der Darstellung, wie Texte ausgezeichnet werden, sei noch einmal betont, daß die Kodierung eines Textelements mit einem TEI-Tag nichts Automatisches oder Mechanisches darstellt, sondern stets Ergebnis eines Interpretations-Aktes ist. Ganz offensichtlich ist die Entscheidung, ob ein Textmerkmal kodiert werden soll, bereits eine editorische Entscheidung. Etwas weniger offensichtlich aber ist die Tatsache, daß die Art und Weise, wie ein Textmerkmal ausgezeichnet wird, ebenfalls eine Entscheidung des Bearbeiters darstellt. Die Text Encoding Initiative hat kein starres Paragraphenwerk vorgelegt, sondern Richtlinien, in denen für zahlreiche Problemfälle bereits alternative Lösungswege aufgezeigt werden, und die Zahl weiterer Auszeichnungsvarianten wächst wohl mit jedem neuen Anwender der TEI. Dennoch bleiben diese individuellen Ansätze, geformt durch theoretische Vorentscheidungen und Bedingungen des Materials, aufeinander beziehbar durch den abstrakten Standard der TEI.

Publikation

Man kann sehr gründlich nach den saubersten TEI-Prinzipien auszeichnen, doch wird man sein Produkt auch zugänglich machen wollen. Da man keinem die Lektüre eines SGML-Textes für die Textarbeit zumuten kann, muß man also bereits bei der Auszeichnung darauf achten, wie die eingetragenen Auszeichnungen mit dem gewählten Browser visualisiert werden können. Dabei ergeben sich Rückwirkungen auf die Art der Auszeichnungen, da sich bestimmte gewünschte Visualisierungen nur mit entsprechenden Auszeichnungen erreichen lassen.

Da es hier um elektronische Editionen gehen soll, wird die Wahl eines Browsers und die Anpassung der Edition an diesen Browser im Vordergrund stehen.[53] Die getesteten Browser haben alle zwei weitere Arbeitsschritte gemeinsam:

Eine Navigationshilfe stellt ein elektronisches Inhaltsverzeichnis zur Verfügung, das möglichst klar gegliedert sein sollte, damit der Anwender sich in der Edition nicht verliert. Das Stylesheet ordnet jedem TEI-Element eine typographische Information zu. Unterstützt werden hierbei auch recht komplexe Anweisungen, die die Darstellung vom Attributwert abhängig macht oder den Wert eines bestimmten Attributs vor den Text stellt usw. Beide Arbeitsschritte müssen leider immer noch für jede Anwendung extra durchgeführt werden. Wünschenswert wäre es, wenn beide Informationen (Navigation und Stylesheet) in einem ebenso standardisierten Format abgespeichert und ausgewertet werden könnten. Der neue Standard DSSSL scheint genau dies zu versprechen, aber er wird im Augenblick noch von keinem der weiter verbreiteten kommerziellen SGML-Programme unterstützt.

Sowohl die elektronische Visualisierung als auch die Druckausgabe machen den Kodierer auf Mängel seiner Auszeichnung aufmerksam, da er manchmal feststellen muß, daß die Art der Auszeichnung die gewünschte Ausgabe nicht möglich macht. Das bedeutet nicht unbedingt, daß eine falsche oder auch nur eine zu wenig differenzierte Auszeichnung gewählt wurde, sondern ist oft durch die Einschränkungen des Druck- und Visualisierungprogramms bedingt. Man wird also auch diesen Arbeitsschritt schon im Vorgriff bei der Auszeichnung berücksichtigen müssen.

Perspektiven

Von den augenblicklich zur Verfügung stehenden Möglichkeiten, eine elektronische Edition zu erstellen, ist TEI ohne Zweifel die beste Lösung. Allerdings gibt es mehrere Punkte, in denen in der Zukunft noch Veränderung zu erwarten und erhoffen ist. Die Entwicklung von DSSSL wurde bereits angesprochen; jetzt muß dieser Standard noch von der Industrie aufgegriffen werden. Ähnlich wie bei SGML ist auch hier durch das Internet eine gewisse Beschleunigung zu erwarten, da ein Subset von DSSSL in einen neuen Standard für WWW-Seiten namens XML (extended markup language) eingegangen ist.

Die Zahl der verfügbaren SGML-Werkzeuge hat in den letzten Jahren weiterhin zugenommen, doch zur Visualisierung und Auswertung von TEI-Dokumenten ist die kommerzielle Software immer nur mit Einschränkungen geeignet. Vielleicht könnten sich verschiedene nationale Philologenorganisationen zusammentun, um das Geld für die Entwicklung eines plattformunabhängigen SGML-Browsers evtl. mit DSSSL -Fähigkeit aufzubringen. Die Verwendung von Java, einer relativ neuen Programmiersprache, die auf den meisten Plattformen verfügbar ist und eben für solche systemübergreifenden Aufgaben gedacht ist, könnte ein solches Projekt realisierbar machen.

Auch die Richtlinien der TEI müssen und werden sich noch weiter entwickeln. Wie eine moderne Edition, z.B. die Sattlersche Hölderlin-Edition, eindringlich vor Augen führt, ist für literaturwissenschaftliche Editionen einer der Grundgedanken von SGML nicht ganz unproblematisch, nämlich die eindeutige Trennung von typographischer und struktureller Information; das Typographische wird so zu einer kontingenten Formulierung einer notwendigen strukturellen Information.[54] Diese Sichtweise, die in vielen Fällen durchaus zulässig und fruchtbar sein kann, ergibt allerdings einige Probleme, wenn das (Typo-)Graphische als gleichwertiger Informationsträger gelten soll, dessen Gehalt sich nicht bruchlos in strukturelle Information übersetzen läßt. Soll für den Buchkundler z.B. die Art des Einbands, die Schrifttype des Drucks und das Buchformat erfaßt werden, so fehlt es dafür ebenso an spezialisierten Auszeichnungselementen wie für die angemessene Beschreibung von Handschriften, dem Winkel des Zeilenverlaufs usw. Die TEI-Richtlinien bieten über das Attribut 'rend' schon die Möglichkeit, die Wiedergabe eines Elements mitzukodieren. Außerdem kann für die Zukunft gerade eine Ausarbeitung in diesem Bereich erwartet werden. Zudem gibt es noch keinen Konsens, welche Informationen dieser Art denn nun als unentbehrlich gelten müssen und welche nur ad hoc zur Beantwortung spezifischer Fragen relevant sind. Man kann einem Auszeichnungssystem nicht gut einen Wissensstand abverlangen, den das Fach noch nicht erreicht hat.

Die elektronische historisch-kritische Edition bietet vielleicht die Möglichkeit, über den mittlerweise sehr weiten Graben zwischen Produzenten von textkritischen Editionen und ihren prospektiven Benutzern eine Brücke zu bauen. Dazu muß es gelingen, die komplexen diakritischen Zeichen des Drucks in größtenteils intuitiv einleuchtende Visualisierungen umzusetzen. Dazu kann man auch den Anschluß an die empirische Forschung zur Verwendung (und ihren Problemen) von Hypertexten suchen.[55] Eine Hypertextstruktur wird von allein nämlich nicht die Lösung bringen. Selbst wenn die assoziative Struktur des Hypertexts der menschlichen Informationsspeicherung ähnlich ist,[56] so spricht wenig dafür, daß sie in dieser Form schon einen effektiven Weg zur Informationsgewinnung darstellt.[57]

Hans Walter Gabler ist sicherlich zuzustimmen, wenn er betont, daß die Entwicklung der Computeredition erst am Anfang steht und die weiteren Möglichkeiten kaum abzusehen sind.[58] Ihr besonderes Potential und die Tatsache, daß sie keine exklusive Alternative zur Druckedition darstellt, sondern ohne übermäßigen Aufwand parallel erstellt werden kann,[59] lassen immerhin eine Feststellung zu: Ein Editionsprojekt der Gegenwart, das seinen Text nicht auch für eine elektronische Edition aufbereitet, vergeudet unnötig Ressourcen. Im Zuge der globalen Digitalisierung des kulturellen Wissens werden künftige Editoren das Versäumte mit großem Aufwand an Geld und Zeit nachholen müssen.

[1] Eine „elektronische Edition“ oder eine „Computeredition“ bezeichnet einen Text, der nicht nur mit Hilfe des Rechners erstellt, sondern dort auch verwendet wird. Computergestützte Editionen, also Texte, die mit Hilfe des Computers erstellt werden, aber dann nur in gedruckter Form zugänglich sind, haben eine verhältnismäßig lange Geschichte (vgl. die Literatur in Wilhelm Ott: Computers and Textual Editing. In: Christopher S. Butler (Hg.): Computers and Written Text. Oxford, Cambridge (USA) 1992, S. 205), während elektronische Editionen ein recht neues Phänomen sind. Morgenthaler weist zu Recht daraufhin, daß elektronische Editionen auch von noch nicht abschließend edierten Texten bereits in einem frühen Stadium ein wichtiges Instrument für den Editor darstellen, vgl. Walter Morgenthaler: Der produktionsorientierte Stellenkommentar in der Computer-Edition. In: Gunter Martens (Hg.): Kommentierungsverfahren und Kommentarformen. Tübingen 1993, S. 251-255.

[2] Zu einem Plädoyer für elektronische Editionen vgl. Karl Eibl: Es müssen nicht immer Bücher sein. In: Jahrbuch der Schillergesellschaft 35 (1991), S. 349-351. Zu den Möglichkeiten beim Übergang von der computergestützten zur Computer-Edition vgl. Hans Walter Gabler: Computergestütztes Edieren und Computer-Edition (Im Druck).

[3] Dieses Problem haben nicht nur elektronische Editionen, sondern alle Texte, die elektronisch angefertigt werden, auch wenn sie nicht in diesem Medium publiziert werden, z.B. elektronische Aufsatz- und Buchtyposkripte, elektronische Arbeitseditionen von Druckausgaben usw.

[4] Einen Überblick über einige proprietäre Auszeichnungssysteme, wie sie bei der Transkription von Handschriften Anwendung gefunden haben, gibt Peter Robinson: The Transcription of Primary Textual Sources Using SGML. Oxford 1994. Robinsons Darstellung ist wohl zur Zeit die einzige praxisorientierte Einführung in das Arbeiten mit TEI.

[5] Ein Beispiel dafür ist, nach allem Anschein, die Geschichte des bislang wohl besten Textretrievalsystems für Philologen, WordCruncher. Das zeichenorientierte DOS-Programm hat nie richtig den Sprung auf eine graphische Benutzeroberfläche geschafft und scheint inzwischen überhaupt nicht mehr gepflegt zu werden. Texte, die dafür kodiert worden sind, müssen nun, damit sie auch in Zukunft greifbar sind, konvertiert werden.

[6] Die Forderung nach einem solchen Standard wurde auch in Deutschland formuliert, vgl. Manfred Thaller: Datenbasen als Editionsformen. In: Anton Schwob, Karin Kranich-Hofbauer, Diethard Suntinger (Hg.): Historische Edition und Computer. Möglichkeiten und Probleme interdiziplinärer Textverarbeitung und Textbearbeitung. Graz 1989, S. 221. Thaller berichtet in der Diskussion von einem VW-Projekt, das nicht ein spezifisches Textauszeichungssystem, sondern eine Methode zur Entwicklung von Textauszeichnungssystemen angezielt hat, was also ein Äquivalent zu SGML wäre; vgl. Brigitte Spreitzer: Protokoll der Diskussion zur Sektion 5. In: Schwob, S. 342.

[7] Der TEI-Standard ist als Buch, im Internet in verschiedenen Textformaten und als CDROM-Version zugänglich. Hier wurde die CDROM-Version verwendet: C.M. Sperberg-McQueen/Lou Bernard: Guidelines for Electronic Textencoding and Interchange. Providence 1995. Die TEI-Homepage im Internet hat die Adresse: "http://www.uic.edu:80/orgs/tei/". Dort findet sich u.a. eine Liste der Editionsprojekte, die mit TEI arbeiten. Es gibt zwei Mailing-Listen zum Thema TEI (TEI-L und TEI-Tech).

[9] Als Parser wird ein Programm bezeichnet, das eine Zeichenkette nach vorgebenen Regeln in Einzelelemente zerlegt und dazu verwendet werden kann, deren syntaktische Korrektheit, d.h. die Übereinstimmung der Zeichenkette mit den Regeln, zu überprüfen; vgl. unten S. 25.

[12] Im TEI-Handbuch gibt es eine zu Recht gerühmte Einführung in den SGML-Standard „A gentle introduction into SGML“. Eine empfehlenswerte Vertiefung bietet: Wolfgang Rieger: SGML für die Praxis. Ansatz und Einsatz von ISO 8879. Berlin, Heidelberg, New York 1995. Das Buch von Martin Colby/David S. Jackson (Hg.): Special Edition Using SGML. Indianapolis 1996. bietet zahlreiche praxisbezogene Informationen, ist aber nicht ganz fehlerfrei. Es ist inzwischen im Internet zugänglich unter: "http://www.mcp.com/que/et/se_sgml/". Für denjenigen, der SGML bereits kennt, ist ein sehr gutes Nachschlagewerk Neil Bradley: The Concise <SGML> Companion. Harlow, England u.a. 1997. Nicht für Einsteiger geeignet, aber unentbehrlich für diejenigen, die neue DTDs entwickeln wollen, ist die ausführliche Beschreibung des SGML-Standards in Charles F. Goldfarb/Yuri Rubnisky: The SGML Handbook. Oxford 1990. Eine Diskussionsgruppe zum Thema SGML findet man im Usenet unter "comp.text.sgml". Ein guter Einstieg zu allen Online-Quellen zu SGML bieten "http://www.sil.org/sgml/" und "http://www.sgmlopen.org/". Eine Liste der verfügbaren SGML-Programme ist unter "http://www.falch.no/people/pepper/sgmltool/" zu finden.

[13] Die Browser für das WWW, z.B. von Netscape oder Microsoft, sind spezialisierte SGML-Programme. Die HTML-DTD wurde in diese Programme eingearbeitet. Das hat den Vorteil, daß sie nicht bei jedem Dokument übers Netz übertragen werden muß, hat aber den Nachteil, daß diese Browser keine SGML-konformen Dokumente mit einer anderen DTD lesen können.

[15] TEI.transcr ist eine besondere Klasse von TEI-Elementen und Attributen, die man für seine Arbeit zusätzlich wählen kann. Mit dem Attribut 'cert' wird angegeben, wie sicher sich der Editor bei der Identifizierung eines Textelements oder einer Urheberzuschreibung ist. 'resp' (responsible) bezeichnet denjenigen, der für die Identifizierung und Zuschreibung verantwortlich ist, zumeist also einer der Editoren.

[17] Da die ergänzenden DTD-Angaben nach der DOCTYPE-Definition in der Dokumentinstanz zuerst ausgewertet werden, kann man an dieser Stelle die DTD-Angaben ergänzen. Voreingestelle Werte in den DTDs werden dadurch überschrieben. Diese Eigenschaft macht sich das TEI-Verfahren zunutze: in den TEI-DTDs sind alle Parameter Entities sozusagen ausgeschaltet. Durch die ergänzende Angabe nach der DOCTYPE-Definition über einzuschließende Entities wird diese Deaktivierung aber aufgehoben.

[18] Zur Verdeutlichung: Die Verwendung der Parameter Entity (mit der Anweisung %isolat1; in der DTD) fügt in die DTD eine Datei ein, in der eine lange Reihe von Zeichendefinitionen mittels General Entities gespeichert sind. Deshalb greift man in der Dokumentinstanz auf die Sonderzeichen als General Entities zurück.

[19] Solange der internationale 16bit Standard zur Zeichenkodierung namens Unicode nicht selbstverständlich geworden ist, muß man bei der Kodierung von Texten auf die Portabilität des gewählten Zeichensatzes achten. Eine recht sichere Grundlage bildet der Zeichensatz ISO 8859/1, dessen ersten 127 Zeichen dem ASCII-Zeichensatz entsprechen und dessen restlichen 127 Zeichen größtenteils durch die Entitäten ISOlat1, ISOnum und ISOdia angesprochen werden können.

[20] Einen Einblick in statistische Verfahren der Textanalyse, die in der Literaturwissenschaft verwendet worden sind, gibt John F. Burrows: Computers and the Study of Literature. In: Christopher S. Butler (Hg.): Computers and Written Texts. Oxford, Cambridge 1992, S. 167-204

[26] Perl ist unter den Programmier- und Skriptsprachen, die zur Zeit zur Verfügung stehen, wohl am besten zur Textbearbeitung geeignet. Es ist leicht zu erlernen und erlaubt auch dem Anfänger bald sehr effektive Textmanipulationen. Vgl. Zur Einführung Randal L. Schwartz: Einführung in Perl. Bonn u.a. 1995. Oder David Till: Perl 5 in 21 days. Indianapolis 1996. Das umfassende Handbuch zur Skriptsprache stammt u.a. vom Erfinder selbst: Larry Wall, Tom Christiansen, Randal L. Schwartz: Programming Perl Bonn u.a. 1996.

[30] Am einfachsten gehen Sie so vor: Kopieren Sie alle TEI2-DTDs in ein seperates Unterverzeichnis und fügen Sie in die Datei „tei2.dtd“ in den Abschnitt 3.6.2 die Include-Anweisungen ein. Dann können Sie mit „normdtd tei2.dtd“ die normalisierte Version generieren.

[33] Das Beispiel zum Element MILESTONE im TEI-Handbuch ist falsch, da dort das notwendige Attribut ‘unit’ weggelassen wurde; vgl. TEI-Handbuch Kap. 35 „Elements“ Eintrag ‘milestones’. Das im Beispiel verwendete Attribut ‘name’ erzeugt im Parser auch eine Fehlermeldung. Zwar gibt das Handbuch an, nur page, column, line, book, poem, canto, stanza, act, scene, section und absent seien mögliche Werte von ‘unit’; ein Blick in die DTD und ein Versuch mit einer anders ausgezeichneten Textinstanz zeigen aber, daß ‘unit’ einen beliebigen Wert annimmt, die Liste also lediglich ein Vorschlag ist (suggested values und nicht legal values).

[38] Das TEI-Handbuch gibt für das Attribut ‘place’ des Elements ADD an, daß es sich um "Legal Values" handle. Das ist, wie ein Blick in die DTD deutlich macht, nicht korrekt. Es handelt sich um "suggested values", die nicht verbindlich sind (und von denen abzuweichen keine Fehlermeldung des Parsers erzeugt).

[40] Es gehört zu den positiven Eigenheiten von SGML, daß Absatzmarken, Leerzeichen, Tabulatoren zum Zwecke der Formatierung eingefügt werden können, wenn an der Stelle kein Text erlaubt ist (Ansonsten würden die Zeichen als Teil des Textes behandelt werden). Auf diese Weise kann man komplexe Auszeichnungen, wie z.B. die mittels des APP-Elements, etwas übersichtlicher gestalten. - Dieses und die nachfolgenden Beispiele stammen aus Goethes Römischen Elegien in der Facsimile-Ausgabe von Hans-Georg Dewitz, Frankfurt a.M. ⁴1993.

[42] Die Literatur zum Thema 'Hypertext' ist bereits kaum mehr überschaubar. Die erste Konzeption eines Hypertextsystem geht bekanntlich auf einen Artikel aus dem Jahre 1945 zurück und seit den 80er Jahren hat das Konzept eines Hypertexts zahlreiche Definitionsversuche und theoretische Begründungen provoziert. Für den Editor einer elektronischen Ausgabe sind wohl weniger die Versuche relevant, die Hypertext und poststrukturalistische Literaturtheorien zusammenbringen wollen, sondern eher die Überlegungen, wie man Hypertexte so gestalten kann, daß der Anwender sich nicht in ihnen verliert und nicht übermäßig viel Vorwissen zu ihrer Verwendung mitbringen muß; vgl. Vannevar Bush: As we may think. In: Atlantic Monthly 176 (Juli 1945), S. 101-108; tatsächlich beschreibt Bush ein System, in dem Informationen in herkömmlicher Weise angeordnet sind und in dem erst der Anwender divergente Elemente miteinander zu einer persönlichen Assoziationsspur verbindet. George Landow: Hypertext. The Convergence of Contemporary Critical Theory and Technolgy. Baltimore, London 1992; Yasar Tonta: Indexing in Hypertext Databases. In: Susan Stone/Michael Buckland: Studies in Multimedia: State-of-the-Art Solutions in Multimedia and Hypertext. Medford, N.J. 1992, S. 21-30; außerdem die Literatur in Fußnote 51.

[43] Eine andere Frage ist es, ob und wie das Darstellungsprogramm, der Browser, diese Anmerkungen dann visualisiert. Softquads Panorama z.B. erlaubt das Ausgliedern der Anmerkungen, unterscheidet in der Bildschirm-Darstellung aber nicht zwischen den Elementen ANCHOR und SEG.

[46] Dieser Verzicht hat den Vorteil, daß der Verwender der Ausgabe weniger von den Entscheidungen des Editors abhängig ist und den für ihn relevanten Basistext heranziehen kann. Allerdings muß man sich immer darüber im Klaren sein, daß diese größere 'Demokratisierung' der Edition mit einem hohen Preis bezahlt wird: Nicht nur wird jedem Leser ein größeres Wissen zur Verwendung der Edition abverlangt, sondern der Aufwand zur Erstellung von Editionen, die möglichst alle Varianten gleichberechtigt behandeln, ist deutlich höher; so aufwendig können nur wenige Texte ediert werden, was wiederum ihre Kanonisierung im Fach stabilisiert; vgl.

[49] Das Attribut 'hand' ist im Element HAND obligatorisch und dient der Angabe der Sigle. Das Beispiel Nr. 106 im Handbuch Kap. 18.2.1 zeigt, daß über diesen Punkt auch bei den TEI-Editoren eine gewisse Verwirrung geherrscht hat, da es in der gegebenen Form falsch ist: <HAND id=h2 type='copperplate' ink='brown' [...]>. Die Sigle sollte aber nicht mit dem Attribut 'id' gekennzeichnet werden, sondern eben mit 'hand': <HAND hand=h2 [...]>.

[53] Es gibt wohl zur Zeit nur zwei DTP-Programme mit SGML-Filtern: das Produkt XXX für die Macintosh-Version von Quark Express und der neue Corel Ventura Publisher mit einem integrierten SGML-Filter und einer Reihe von Zusatzprogrammen, um seine SGML-Dateien verwalten und importieren zu können.

[55] Vgl. dazu Jean-Francois Rouet u.a. (Hg.): Hypertext and Cognition. Mahwah, New Jersey 1996. Bislang gibt es kaum Forschungen zu den Bedürfnissen von Anwendern der humanities software applications, vgl. Susan Hockey: Creating and using electronic editions. In: Richard J. Finneran (Hg.) The Literary Text in the Digital Age. Ann Arbor: University of Michigan Press 1996, S. 14.

[56] Vgl. z.B. Shillingburg, der diese Annahme bereits als Konsens wiedergibt und zahlreiche Literaturhinweise bietet; Peter Shillingsburg: Scholarly Editing in the Computer Age: Theory and Practice. University of Georgia Press, 1996, S. 164. Bereits Bush hebt an seinem Modell Memex hervor, daß es erlauben würde Informationen so zugänglich zu machen, wie der menschliche Geist funktioniert; vgl. Fußnote 38.

[57] Vgl. dazu Andrew Dillon: Myths, Misconceptions, and an Alternative Perspective on Information Usage and the Electronic Medium. In Rouet (FN 51) S. 25-42. Dillon greift mit polemischer Schärfe eine Reihe von Äußerungen an, die immer wieder in Hypertext-Theorien zu hören sind. Vor allem die These, Hypertext wäre dem menschlichen Geist sozusagen naturwüchsig nahe: „Associative Linking of Information is Natural in That It Mimics the Workings of the Human Mind“ (28).

[59] Das Wissen zur Erstellung einer elektronischen Edition ist also ein Aspekt der Erstellung von wissenschaftlichen Textausgaben überhaupt, was sich jetzt schon in den Einführungen in die Editionsphilologie zeigt; vgl. z.B. in Shillingburg Kap. 14 "Electronic Editions" (wie Fußnote 52). Oder Herbert Kraft (Hg.): Editionsphilologie. Darmstadt 1990, Kap. 5 "Edition und Datenverarbeitung" (von Wilhelm Ott).