Anmerkungen zum Vortrag von Eva Büthe-Scheider über die Boich-Weinsberg-Edition
Die Edition des “Boich Weinsberg” ist ein typisches Beispiel für die durch die Verfügbarkeit digitaler Methoden gewandelten Anforderungen an ein Editions-Projekt. Es schreibt die Familiengeschichte des Kölner Bürgers Hermann Weinsberg und stellt – obwohl oder mitunter auch weil sie teilweise frei erfunden ist – eine wichtige historische Quelle zum Selbstverständnis und zur Mentalität des Stadtpatriziats in der frühen Neuzeit dar. Mit einer zeitgemäßen Edition des Werks sind nun Erwartungen wie die folgenden verbunden:
- Das zu edierende Werk ist für unterschiedliche wissenschaftliche Fächer von Interesse, für die Geschichtswissenschaft nicht weniger als für die Germanistik und historische Linguistik, die aber jeweils unterschiedliche Ansprüche stellen. Für die Geschichtswissenschaft wäre ein möglichst lesbarer, am besten teilnormalisierter, vielleicht gar übersetzter Text von größtem Nutzen. Für die historische Linguistik ist dagegen gerade die Bewahrung der sprachlichen Eigenheiten relevant.
Von der Digitaltechnik wird erwartet, möglichst beiden Anforderungen gerecht zu werden, oder dass – falls es anders das Projekt sprengen würde – doch zumindest bei der Datenkodierung die Möglichkeit einer Zweitausgabe mit anderem Fokus nicht verbaut wird.
-
Beinahe schon selbstverständlich ist die Anforderung, dass neben einer Druckausgabe eine frei verfügbare Online-Ausgabe entsteht, die von den zusätzlichen Möglichkeiten des digitalen Mediums auch Gebrauch macht.
-
Die Editionsdaten sollten dabei natürlich so kodiert sein, dass sie sich neben der Produktion menschenlesbarer Ausgaben auch für die maschinelle Weiterverarbeitung gut eignen.
Nicht zuletzt wegen der Anforderungen der Maschinenlesbarkeit der Daten und der Unterstützung unterschiedlicher Ausgabeformate sind gängige Textverarbeitungsprogramme, mit denen der Text so eingegeben wird, wie er gedruckt erscheinen soll, kein geeignetes Werkzeug für die Kodierung digitaler Editionsdaten. Aus diesem Grund stützen sich größere Editionsvorhaben häufig auf XML-zentrierte Arbeitsabläufe und Werkzeuge. Die haben aber den Nachteil, dass ihre Realisierung technisch so aufwändig ist, dass sie von Fachwissenschaftlern neben der Erstellung der Edition selbst nicht auch noch geleistet werden kann.
Gerade für kleine Editionsprojekte, deren Finanzierung nicht für die Einstellung eines Programmierers oder eines “DevOps” (Developer/Operator) hinreicht, oder die zunächst ganz ohne Finanzierung in Eigeninitiative von Forschern begonnen werden, sind andere Technologien gefragt.
Mögliche Kandidaten sind Textsatzsysteme wie LaTeX, TUSTEP oder der Classical Text Editor. Alle diese Technologien sind in vertretbarer Zeit erlernbar und beherrschbar. Sie eignen sich daher auch für Ein-Personen-Editionsprojekte. Allerdings wurden alle diese Technologien ursprünglich für die Produktion von Drucktexten entwickelt. Sie erzwingen daher weder die bei digitalen Editionen üblicherweise geforderte semantische Auszeichnung, noch erzeugen sie von selbst eine digitale Ausgabe der damit kodierten Editionsdaten.
Eindeutige Kodierungen mit dem Classical Text Editor
Mit etwas Erfindungsgeist lassen sich LaTeX oder der Classical Text Editor aber sehr wohl auch für semantisch präzise ausgezeichnete Editionen einsetzen. Wie das mit dem “Classical Text Editor” gemacht werden kann, führt Eva Büthe mit der Boich-Weinsberg-Edition vor Augen. Die wichtigsten Ingredienzien ihres Ansatzes sind dabei:
-
Eine geschickt gewählte Eigennotation, die sowohl für menschliche Leser sinnvoll aussieht, als auch eindeutig genug ist, um maschinell verarbeitet zu werden.
-
Eine konsequente Orientierung an dem Prinzip eine Formatierung für eine Funktion.
-
Die pragmatische Beschränkung auf das Wesentliche – kein “Over-Engineering”!
Wie werden diese Punkte bei der Edition “Boich Weinsberg” umgesetzt?
Um einen (für heutige Leser) nicht unmittelbar verständlichen Text im Rahmen einer Edition wieder lesbar zu machen, bieten sich grundsätzlich drei Alternativen an: Normalisierung, Übersetzung und Kommentierung, die alle ihre jeweiligen Vor- und Nachteile haben (siehe dazu die Präsentation von Eva Büthe-Scheider, Blatt 44-49). Um den Text in möglichst ursprünglicher Form zu erhalten wurde in diesem Fall primär eine sachliche und sprachliche Kommentierung in Verbindung mit einer ganz behutsamen und immer kenntlich gemachten Normalisierung als der geeignetste Ansatz gewählt.
Zudem ist die Transkription so eingerichtet, dass ein stärker normalisierter und damit leichter lesbarer Text automatisch hergestellt werden kann. Dieser Ansatz spielt auch an anderer Stelle eine Rolle, dazu im Folgenden ein ausführlicheres Beispiel.
Eindeutige Kodierung von Übersetzungstexten im Kommentar
Das Besondere daran ist, dass die Kommentare so codiert wurden, dass sich die dialektalen Ausdrücke und deren im Kommentar enthaltene Übersetzung so eindeutig zuordnen lassen, dass man theoretische sogar die dialektalen Ausdrücke durch ihre Übersetzung ersetzen könnte. Damit ließe sich z.B. eine Online-Ausgabe in der dialektale Ausdrücke mit einer beim überfahren mit dem Mauszeiger erscheinenden Übersetzung versehen werden, leicht automatisiert erzeugen.
Die gewählte Kodierung funktioniert wie folgt:
Zeile aus dem Originaltext:
… sampt etlichen Dützen fursten abgefertiget …
Dazu der Kommentar in der Fußnote:
Dützen] ‘deutschen’ | abgefertiget] ‘entsandt’
Vor der eckigen Klammer ] steht der Text aus dem Original, auf den sich der Kommentar bezieht, danach folgen die kommentierenden Erläuterungen, die – in einfachen – Anführungsstrichen den übersetzten Text beinhalten, wobei die Wortformen der Übersetzung so gewählt sind, dass man den Text im Original durch den Übersetzungstext aus der Fußnote ersetzen könnte. (Vgl. Präsentation, Blatt 54))
In dem Beispiel eben bestand der Kommentar nur aus der Übersetzung des nicht verständlichen Wortes. (Was “nicht verständlich” ist und daher kommentiert und übersetzt werden sollte, ermittelt Eva Büthe-Scheider übrigens mit Hilfe von “Test-Leser/innen”.) Kommentare können aber durchaus auch komplexer ausfallen:
oenoriüs] Transliteration von ὀινώριος ‘Weinberg’
(“ὀινώριος” steht so im Text, wie die recte-Schreibung kenntlich macht. Die übliche Schreibung wäre “οἰνώριος” mit spiritus lenis auf dem Iota.)
Die automatisierte Ersetzung (schwer verständlicher) Originalpassagen durch ihre Übersetzung bleibt wegen der eindeutigen Kennzeichnung der Übersetzung durch die einfachen Anführungsstriche aber auch dann noch eine triviale Aufgabe. Lediglich in den Fällen, in denen mehrere Übersetzungen angegeben werden, müsste der Algorithmus willkürlich eine auswählen. Als Fehlerquellen bleiben dann nur noch die Fälle übrig, in denen das Kodierungsschema fehlerhaft gehandhabt wurde. Solange das nicht vom Computer mit Hilfe eines (leicht zu erstellenden) Validierungsprogramms überprüft wird, muss man auch bei gründlichem Korrekturlesen damit rechnen, dass immer noch einzelne Fehler dieser Art übrig bleiben.
Das Prinzip “Eine Formatierung für eine Funktion”
Für die Computerlesbarkeit ebenso wichtig ist das Prinzip “eine Formatierung für eine Funktion”. Das klingt zwar wie eine Binsenweisheit, da es auch für menschliche Leserinnen und Leser hilfreich ist, keine mehrdeutigen Formatierungen zu verwenden. Aber menschliche Leserinnen und Leser sind anders als der Computer leicht in der Lage, anhand des Kontextes zu verstehen, ob z.B. eine Kursivierung in einem gegebenen Fall ein Zitat kennzeichnet oder einen fremdsprachlichen Einschub, oder ob er lediglich der Hervorhebung dient. Bei dem Versuch der Automatisierung von Retrodigitalisierungsarbeitsabläufen tritt diese Art von Kontextabhängigkeit daher immer wieder als Herausforderung auf.
Eva Büthe beschränkt sich bei der Umsetzung dieses Prinzips auf wenige einfache, aber konsequent in allen Textteilen und Apparaten umgesetzte Regeln:
-
Der Originaltext wird immer recte gesetzt und alle Herausgeberzutaten kursiv. Zu letzteren gehört vor allem die Auflösung von Abkürzungen (“Adrianus probus” mit us-Kürzel im Original) und von Kurzschreibungen (“Ao 53” zu “Anno 53”).
-
Da bei Interpunktionszeichen eine Kursivierung kaum erkennbar wäre, werden von der Herausgeberin ergänzte Interpunktionen in eckige Klammern gesetzt, während getilgte Interpunktionen hellgrau unterlegt werden.
-
Rubrizierungen (Rotfärbungen von Buchstaben) im Originaltext werden durch Fettschrift wiedergegeben.
-
Schreiberversehen, die das Lesen stören und bei denen die gemeinte Fassung ganz eindeutig ist, werden korrigiert, durch Kursivierung gekennzeichnet (falls möglich) und immer im Kommentar vermerkt. Diese Eingriffe lassen sich freilich nicht automatisch rückgängig machen und werden nur selten vorgenommen: So wird das Zusammenschreiben des Namens “Weinsberg” mit einer zufällig folgenden Form verbessert und vermerkt, nicht aber eine Schreibung wie “Gotſalckcuͦs”, bei der die gemeinte Form nicht eindeutig ist.
Kein “Over-Engineering”
Der Classical Text Editor funktioniert nach dem What-you-see-is-what-you-mean-Prinzip (WYSIWYM), d.h. mit dem Classical Text Editor wird unmittelbar der (Druck-)Text eingegeben, wenn auch anders als bei Textverarbeitungsprogrammen, die nach dem What-you-see-is-what-you-get-Prinzip (WYSIWYG) arbeiten, nicht unmittelbar in der Gestalt des späteren Drucks. (Was insofern keine schwerwiegende Einschränkung darstellt, als bei mehreren anvisierten Ausgabemedien – Druck, Online, und Letzteres für unterschiedliche Bildschirmgrößen – das WYSIWYG-Prinzip ohnehin keinen Sinn mehr hat.)
Entsprechend unterscheidet sich der Classical Text Editor von anderen digitalen Editionstechnologien wie LaTeX oder XML auch darin, auf welche Weise man “versteckte” Daten im Text unterbringt, d.h. Daten, die im Anzeigetext nicht sichtbar, aber z.B. für die Such- oder Verknüpfungs-Funktionen einer Online-Ausgabe relevant sind. Während XML in Form von Attributen oder auch von Tags, deren Inhalt nicht angezeigt wird, die Anreicherung mit nicht-sichtbaren Zusatzdaten geradezu vorsieht und LaTeX es durch Kommentare oder selbstdefinierte Makros zumindest mühelos erlaubt, wäre es beim Classical Text Editor (CTE) wohl das Mittel der Wahl, Annotationen auf einer versteckten, nicht für die Ausgabe bestimmten Apparatebene vorzunehmen (was im CTE vorgesehen ist) oder in den Haupttext geschriebene Zusätze mit dem Fontattribut “hidden” auszuzeichnen.
Von diesen Möglichkeiten einmal abgesehen, ist man beim Einsatz des CTE gezwungen, die eigenen Kodierungen – wie das Eva Büthe-Scheider getan hat – so zu wählen, dass sie auch als Drucktext funktionieren. Das nötigt unvermeidlich auch zu einer gewissen Beschränkung dessen, was überhaupt kodiert wird. Was nun zunächst wie ein Nachteil klingt, ist andererseits auch ein Segen, denn es erfordert eine Beschränkung auf das Wesentliche. Das Risiko des “Over-Engineering”, das bei Groß-Editionsprojekten immer wieder zu beobachten ist (vgl. dazu etwa die Rezension der Faust-Edition im RIDE-Journal (“Review Journal for Digital Editions and Resources” des IDE)), tritt hier nicht auf.
Damit empfiehlt sich dieser Ansatz besonders für kleine Projekte, die über keinen eigenen Techniker verfügen. Die Edition des “Boich Weinsberg” wird zwar von der Gesellschaft für Rheinische Geschichtskunde gefördert, aber nicht in dem Umfang, dass ein Programmierer oder eine Programmiererin hätte eingestellt werden können.
Diskussionspunkte
Normdaten
Unmittelbar an den letzten Punkt anknüpfend wurde in der Diskussion des Vortrags die Frage aufgeworfen, ob und wie z.B. eine Normdatenverknüpfung in der Edition vorgesehen und möglich wäre. Auch hier ist mit dem Classical Text Editor eine pragmatische Lösung gefragt, da man im Drucktext ja nicht hinter jeder Namensnennung die GND-Nummer für die genannte Person sehen möchte.
Ein Vorschlag war daher, die GND-Nummern einfach im Personen-Index unterzubringen, denn dort stören sie nicht den Lesefluss und wären umgekehrt auch in der Druckausgabe eine sinnvolle Ergänzung.
Online-Ausgabe und unterschiedliche Textfassungen
Eine andere Frage war, wie denn – ausgehend vom CTE-Manuskript – eine Online-Ausgabe angefertigt werden könnte. Mit dem CTE selbst lässt sich ja zunächst nur eine Druckausgabe bzw. ein PDF erstellen, aber keine Online-Ausgabe. Hierfür ist in jedem Fall noch Techniker-Arbeitskraft erforderlich, auch wenn der Aufwand nicht groß sein dürfte.
Weiterhin wird die erste Druckfassung zunächst auf die Bedürfnisse des historisch interessierten Publikums zugeschnitten sein, da die Gesellschaft für Rheinische Geschichtskunde das Editionsprojekt fördert. Ein speziell auf die Bedürfnisse für Linguisten und Germanisten zugeschnittene Textfassung erfordert eine andere Darbietung der Online-Ausgabe, was zusätzlichen Aufwand für die Techniker-Arbeitskraft bedeutet.
Links
Präsentation von Eva Büthe-Scheider zur Boich-Weinsberg-Edition
Gesellschaft für Rheinische Geschichtskunde
Rezension der Faust-Edition im RIDE-Journal
OpenEdition schlägt Ihnen vor, diesen Beitrag wie folgt zu zitieren:
Eckhart Arnold (5. Januar 2021). Digitale Editionen im Eigenbau. dhmuc. Abgerufen am 8. Oktober 2024 von https://doi.org/10.58079/nlba
Das Prinzip, Unterscheidungen ausdrücklich und einheitlich zu treffen (“eine Formatierung für eine Funktion”) kann man gar nicht hoch genug hängen. Es ist das wichtigste Prinzip der digitalen Geisteswissenschaften überhaupt, zugleich das vielleicht am seltensten wirklich verstandene und angewandte. Ein Werk, bei deren Eingabe es ausnahmsweise berücksichtigt wird, ist in der Tat kinderleicht digital zu verarbeiten. Leider ist das die absolute Ausnahme, wie jeder mit Digitalisierungserfahrung leidvoll bestätigen kann. Aber es muss ja nicht die Ausnahme bleiben, denn anscheinend geht es auch anders, und davon kann man lernen.
„Eine Formatierung für eine Funktion“ klingt für mich zugegebenermaßen nach einer Binsenweisheit, die vor allem bzw. vmtl. ausschließlich für digitale Editionen, die eigentlich eher in der Tradition des Druckes stehen, noch als Leitfaden dienen kann. Semantisiert man darstellungswürdige Phänomene, anstatt sie unmittelbar typografisch zu übersetzen, ist der Bezug automatisch 1:1 (Zitat=Zitat, Abkürzungsauflösung= Abkürzungsauflösung). Das muss nicht unbedingt in ,Over Engineering’ enden. Mich würde in dem Zusammenhang interessieren, ob das Formatierungssystem im CTS formal dokumentierbar ist, z.B. über Schemata?
Ich weiß nicht recht. Vielleicht kann der Ausdruck “Formatierung” zu leicht missverstanden werden? Der Leitfaden, Inhalt einheitlich auszudrücken, wäre nicht nur bei Druckeditionen, sondern zum Beispiel auch bei der Erstellung von XML-Emanationen wie TEI-XML einschlägig – oder: einschlägig gewesen, denn leider war die Binsenweisheit dabei nicht bekannt oder blieb jedenfalls nicht beachtet. Daher rührt nun die nicht eben erwünschte Möglichkeit (nur Möglichkeit), dass ein nach den TEI-Regeln ausgezeichneter Text *schlechter* maschinell weiterverarbeitet werden kann als ein Text, der mittelbar über Formatierungen ausgezeichnet wurde, aber eben einheitlich. Die Formatierung ist hier die mittelbare Auszeichnung gegenüber der unmittelbaren Auszeichnung durch Eingabe von XML; das Interessante an dem vorgestellten Ansatz ist wohl, dass die gewählten Formatierungen zugleich die auch typographisch erwünschten sind und bequem mit einem Editor eingegeben werden können, der sich auch noch aus anderen Gründen für historisch-kritische Editionen eignet.
Gibt es bei TEI-XML tatsächlich mehrdeutige Auszeichnungen? (So wie in einem Word-Dokument ein Kursivierung Unterschiedliches ausdrücken kann.) Mir war bisher nur bewusst, das es das Umgekehrte, nämlich unterschiedliche Auszeichnungsmöglichkeiten für ein und dasselbe Text-Phänomen gibt.
Eine Binsenweisheit ist das Prinzip “Eine Formatierung für eine Funktion” wie mir scheint erst dann, wenn man an die technische Weiterverarbeitung denkt. Denkt man dagegen nur an (menschliche) Leserinnen und Leser, so ist es nicht unbedingt notwendig (oder auch nur intuitiv naheliegend) sich an ein solches Prinzip zu halten, da Menschen eine mehrdeutige (oder “überladene”) Formatierung ja auch anhand des Kontextes bzw. ihres Gesamtverständnisses des Textes oder eines Textausschnittes richtig auffassen können.
Daraus ergibt sich dann, je nach dem wen man berät, immer wieder einmal die Erkläungsbedürftigkeit dieser Binsenweisheit.
Der “Classical Text Editor” ist in der Tat vom Paradigma her noch auf Druckausgaben ausgerichtet – aber: es ist einerseits leichter saubere Daten herauszubekommen als bei einer Textverarbeitung und andererseits kann er von Geisteswissenschaftlerinnen und Geisteswissenschaftlern ohne Technik-Kenntnisse selbst in Betrieb genommen und genutzt werden.
Bei Oxygen muss zumindest der Author-Modus doch meistens von jemandem mit soliden Technik-Kenntnissen eingerichtet werden – vom Aufsetzen einer ganzen Ediarum-Umgebung ganz zu schweigen. Geisteswissenschaftliche Ein-Personen-Projekte sind deshalb mit einer “Plug-and-Play”-Lösung wie CTE besser bedient.
Ein Schema müsste sich für den XML-Export von CTE bauen lassen. Ich bin mir aber nicht sicher, ob CTE von sich aus ein explizites Schema zu Grunde legt und für künftige Versionen garantiert… Andererseits wird ein Schema m.E. erst dann unumgänglich, wenn man die Daten in ein bestimmtes Repositorium einspeisen möchte, das ein Schema vorgibt. Aber dann steht sowieso noch einmal eine Datenkonvertierung an.
Es leuchtet mir natürlich ein, dass 1-Personen-Projekte mit Plug and Play Software gut bedient und darauf angewiesen sind. Man muss dabei m.E. aber auch einige Abstriche machen, die hier als Innovation anklangen. Ich sehe in der ,mittelbaren‘ Auszeichnung keine Vorteile, da dabei Textphänomene unwiederbringlich in Typografie übersetzt werden (wie bei der ,unmittelbaren‘ Auszeichnung bleibt ein Verarbeitungsschritt für eine menschenlesbare Darstellung nicht aus). Auch leuchtet mir nicht ein, wieso ein CTE Export maschinell leichter zu verarbeiten sein sollte als XML/TEI. Ich bin jedenfalls gespannt, ob sich die Webedition mit dem CTE Export wirklich mit geringem Aufwand umsetzen lässt.
TEI Kodierungen können schon mehrdeutig sein, das liegt dann aber eher daran, dass die Editor/innen sie nicht konsistent anwenden. Unterschiedliche Auszeichnungsmöglichkeiten für ein und dasselbe Phänomen gibt es auch, allerdings ist die TEI ja auch nur ein Pool an Möglichkeiten, aus dem man sich selbst was schlüssiges zusammensetzen muss.. und die Logik in einem Schema formalisieren sollte. Insofern ist das Schema schon zentral, unabhängig von der Einspeisung in Repositorien. Es ist gewissermaßen das technische Pendant zu den diskursiv verfassten Editionsrichtlinien.
Polysemie ist ein Spektrum, aber auch wenn man seine Ansprüche auf Bedeutungsgenauigkeit auf ein mindestes Maß beschränkt hält, wird man den Verwendungsspielraum, den ein TEI-XML-Element wie “note” lässt, doch als einen gähnenden Abgrund empfinden müssen, in dem alle theoretisch gewollten Vorteile einer standardisierten semantischen Auszeichnung untergehen. Das Beispiel “note” zeigt auch den Unterschied auf zu einem Vorgehen, bei dem der binsenweisheitliche Leitfaden tatsächlich begriffen und angewandt wurde, wie es bei der ursprünglich vorgestellten Ausgabe der Fall zu sein scheint: Dort wird eindeutig zwischen quellenseitig bezeugten und herausgeberseitig erzeugten Abschnitten unterschieden (bis zum einzelnen Zeichen hinunter). Etwas in “note” Enthaltenes kann das eine wie das andere sein, eine Anmerkung in der Quelle oder eine des Herausgebers. Wer TEI-XML nutzt, wird nicht angehalten, diese doch fundamentale Unterscheidung zu treffen (es wird sogar unnötig schwer gemacht, übrigens auch für die Weiterverarbeitung). Hier ist die Unterscheidung dann tatsächlich unwiederbringlich verloren. Dagegen ist die Unterscheidung in der vorliegenden Ausgabe maschinenlesbar bewahrt – obwohl sie mit Formatierung ausgedrückt wird – und gerade weil sie einheitlich vorgenommen wird.
Das Beispiel soll zeigen: Es kommt darauf an, *was* unterschieden wird und dass es eindeutig (genauer: nach einer programmierbaren Regel) unterschieden wird, nicht aber, dass es nicht mit Formatierung unterschieden werde. Es kommt z. B. darauf an, dass Bezeugtes und Erzeugtes eindeutig unterschieden werden, nicht, dass dabei keine Kursivierung im Spiel sein darf.
Die Entscheidung über das Was und die Einheitlichkeit der Durchführung, also das Wohl und Wehe der Anzeichnung überhaupt, hängt natürlich von den Bearbeitern ab, gleichviel, ob TEI-XML oder Formatierung eingegeben wird. – In diesem Zusammenhang sind wohl die praktischen Vorteile zu sehen, auf die schon hingewiesen wurde. Man braucht eben irgendeine einigermaßen bequeme und für historisch-kritische Editionen geeignete Eingabeoberfläche. Wenn das nicht der CTE sein muss – umso besser!
Das XML, das der CTE ausgeben kann, ist übrigens TEI-XML. Was ja entweder das Verfahren der vorliegenden Edition adelt (Sorgfalt der Bearbeitung vorausgesetzt) oder, meiner Meinung nach, das Trügerische des Maßstabes “TEI oder nicht-TEI” unterstreicht.
Wie gesagt, die TEI ist ein großes Set an Möglichkeiten, das viel Interpretationsspielraum lässt, und es liegt an der einzelnen Editionen eine in sich stimmige und dokumentierte (=Schema) Auswahl aus dem Tagset zu treffen. Das Element kann man mit Attributen weiter spezifizieren; gängig ist beispielsweise und u.Ä. Wer TEI nutzt wird nicht explizit angehalten, diese Auswahl zu treffen, *kann* sie aber leicht – wie oben beschrieben – treffen. Ich sehe darin keinen Unterschied im beschriebenen Vorgehen mit dem CTE, außer, dass die TEI Elemente und Attribute dokumentiert bereithält, und damit projektübergreifend zumindest ein gewisser Grad an Homogenität gegegeben ist, den es zwischen verschiedenen CTE-Editionen – wenn ich die Softwarebeschreibung richtig deutete – so nicht geben wird. Ich habe übrigens zwar noch nicht mit dem CTE gearbeitet, aber TEI-Exporte aus CTE gesehen und sie waren mehr als sperrig weiterzuverarbeiten.
Auch wenn mir scheint, dass wir uns in der Sache nicht einig werden, bedanke ich mich für die interessante Diskussion und möchte zum Abschluss noch einmal hinzufügen, dass ich, auch wenn ich CTE-kritisch bin, keine Kritik an der Edition oder der Qualtität ihrer Erschließung üben möchte, sondern nur die m.E. fälschlich dargestellten Vorteile bzw. Alleinstellungsmerkmale des CTEs (gegenüber der TEI) “geraderücken” wollte.
Auch ich bedanke mich für die Diskussion, zudem für die Erläuterung, dass das Anliegen war, “die m.E. fälschlich dargestellten Vorteile bzw. Alleinstellungsmerkmale des CTEs (gegenüber der TEI) „geraderücken“” zu wollen. Dann lag, wie oben vermutet, ein Missverständnis vor; denn über “Vorteile oder Alleinstellungsmerkmale des CTEs (gegenüber der TEI)” etwas zu sagen, ist aus zwei Gründen nicht meine Absicht:
1. “Vorteile bzw. Alleinstellungsmerkmale des CTEs (gegenüber der TEI)” würde ich nicht behaupten, da ja TEI-XML eine Serialisierung, der CTE aber ein Eingabewerkzeug ist, das unter anderem eine Art von TEI-XML ausgibt, ich die beiden also nicht als Alternativen sehe.
2. Hervorhebenswert war mir nicht die (im Urkommentar dieses Kommentarbäumchens unerwähnte) Verwendung von CTE und damit auch dem CTE-TEI-XML, sondern das oben angedeutete Prinzip: Einheitlichkeit, Proportionalität der Inhalts- und Ausdrucksseite, gezielte Meidung von Polynymie und Polysemie. Es hat mich gefreut, dieses Prinzip in der Bearbeitung der vorliegenden Ausgabe verstanden und weitgehend durchgeführt gefunden zu haben: erstens, weil es einen so starken Unterschied macht – für das Arbeiten mit jedem Serialisierungsformat oder Eingabewerkzeug, z. B. auch dann, wenn man sich für eine relationale oder Graph-Datenbank entschieden hat –; zweitens, weil es eben leider alles andere als selbstverständlich ist. Das ist meine Erfahrung mit allzu vielen Fällen in der Tat sperriger Weiterverarbeitung, darunter auch CTE-TEI-XML und anderes TEI-XML – was in diesem Fall sogar noch schlimmer war; denn es kommt auf etwas anderes an. Auch die Richtlinien von TEI-XML selbst deuten darauf, dass diesem Prinzip gerecht zu werden nicht so leicht ist: Ein lexikalische Vorgaben machendes “großes Set an Möglichkeiten, das viel Interpretationsspielraum lässt”, in dem fundamentale Unterscheidungen vielleicht mit diesem, vielleicht mit jenem, vielleicht mit gar keinem Attribut bezeichnet werden, wird rasch zum Teil des Problems anstatt zum Teil der Lösung. Und es kann ja zumindest keine Empfehlung für das TEI-XML sein, dass das vom CTE ausgegebene sperrig ist.
Eine andere Frage ist, welches Eingabewerkzeug man wählt, was wiederum davon abhängig ist, was es gibt. Wünschenswert wäre ein Eingabewerkzeug, das die folgenden Eigenschaften vereinigt:
1. Apparatefunktionen (mehrfache Fußnotenebenen),
2. WYSIWYM (genauer: Auszeichnung, die im XML serialisiert würde, wird im Eingabe- und Korrekturlesefenster nicht-linear angezeigt durch Formatierungen),
3. Plug & Play (kein Einrichten oder Aufsetzen durch Fachleute nötig),
4. Ausgabe einer nicht-sperrigen Serialisierung.
Ein pandoc-plugin für CTE wäre sicher eine gute Idee. Sollte auch nicht allzu schwer sein, da CTE ja einen XML-Export hat, was ja leicht zu “parsen” ist. Pandoc ist in Haskell geschrieben, also: Haskell-Kenner vor!
Allerdings würde ein solches generisches CTE-pandoc plugin die für die “Boich Weinsberg”-Edition verwendete Eigennotation noch nicht vollständig erfassen, da sie sich beim CTE-XML-Export nur teilweise (nämlich nur die Formatierung, wie kursiv, hellgrau) in der XML-Struktur wiederfindet, und zum Teil nach wie vor als “ungeparste” Eigennotation zwischen den Tags (z.B. die einfachen Anführungsstriche, die Übersetzungen des Originaltexts anzeigen).
Zur online-ausgabe: klingt fast nach etwas, wofür man ein pandoc-plugin bräuchte, zusammen mit ein paar filtern, die je nach ausgabetype neu geschrieben werden müssten (standardmäßig kann pandoc jedenfalls kein classical text editor)