What You See Is What You … Have to Revise Afterwards

von Martin Prell

Daten und Zielstellung

Im Juli 2024 hatte ich dank eines FAIR-Data-Stipendiums von NFDI4Memory am DH Lab des IEG die Gelegenheit, ein Datenset zu transformieren, das wenige Jahre zuvor am Lehrstuhl für Geschlechtergeschichte der Universität Jena entstanden war: Das in der staatlichen Bücher- und Kupferstichsammlung Greiz befindliche handschriftliche Reisetagebuch zur Kavalierstour des pietistischen Grafen und späteren Fürsten Heinrich XI. Reuß-Greiz (1722–1800) in den Jahren 1740 bis 1742 war damals durch die Thüringer Landes- und Universitätsbibliothek digitalisiert und mit Hilfe der virtuellen Forschungsumgebung FuD transkribiert und annotiert worden. FuD beinhaltet unter anderem einen sogenannten WYSIWYM-XML-Editor; ein Akronym für „What you see is what you mean“, da die Eingabe der Daten in einer graphischen Oberfläche stattfindet, ohne dabei zwingend mit Auszeichnungskodierung in Berührung zu kommen. Die avisierte Präsentation des Tagebuchs im Editionenportal Thüringen war zum Ende der Erschließung nicht mehr möglich. Ziel des FAIR Data-Stipendiums war es daher, die FuD-XML-Forschungsdaten so zu transformieren und zu publizieren, dass die Edition bestmöglich auffindbar, langfristig zugänglich, interoperabel und nachnutzbar wird.

Wahl des Publikationsorgans

Der erste Schritt bestand in der Auswahl eines geeigneten Publikationsorgans, das neben der Bereitstellung der Daten in einem Repositorium und der genannten FAIR-Prinzipien auch die aktive Nutzung der Edition mit einer Präsentationsschicht ermöglichen sollte. Das am NFDI-Konsortium Text+ beteiligte Deutsche Textarchiv als Archiv für deutschsprachige, historische Texte erfüllt diese Bedingungen. Darüber hinaus bietet es eine Vielzahl weiterer Vorteile, darunter eine elaborierte linguistische Suche, linguistische Tools wie bspw. CAB (orthographische Normalisierung) oder DiaCollo (Analyse von Wortbedeutungsverschiebungen) und eine DWDS-Indizierung. Voraussetzung für die DTA-Integration ist die Konformität der Daten mit dem vom DTA entwickelten und von der DFG empfohlenen TEI-Subset DTA-Basisformat (DTABf). Selbst wenn die Aufnahme des Tagebuchs in das DTA nicht möglich gewesen wäre, erschien das etablierte, korpustaugliche DTABf als Zielschema meiner Transformation sinnvoll. Glücklicherweise hatte mir das DTA-Redaktionsteam gleich zu Beginn des Stipendiums mitgeteilt, dass eine Aufnahme des Tagebuchs in das DTA unter bestimmten technischen Bedingungen möglich sei.

Wahl des optimalen Vorgehens

Zu Beginn einer Datentransformation stellt sich insbesondere die Frage nach dem optimalen Vorgehen, mit dem sich automatisierte, semiautomatisierte und manuelle Transformationsschritte so kombinieren lassen, dass nicht nur eine möglichst hohe Datenqualität, sondern auch eine effiziente Zeit- und Ressourcennutzung erreicht werden kann. Zwei mögliche Wege standen zur Wahl:

Option 1 ist die einer von Anfang an und konsequent umgesetzten manuellen bzw. halbautomatisierten Anpassung der Ausgangsdaten. Halbautomatisiert hätte in diesem Fall das Suchen und Ersetzen von Text/Kodierung unter Zuhilfenahme regulärer Ausdrücke bedeutet. Vollautomatisierte skriptbasierte Transformationsroutinen wären hierbei nicht Bestandteil gewesen, da diese auf zuvor punktuell manuell manipulierten Daten nur sehr unzuverlässig funktioniert hätten. Sobald manuelle Eingriffe stattfinden, ist man gut beraten, diesen manuellen Weg auch konsequent weiterzugehen. Dies gilt umso mehr, je mehr manuelle Anpassungen unterschiedlicher Art stattgefunden haben. Etwaige Beschleunigungen durch skriptbasierte Verarbeitungsroutinen würden dabei mit einem hohen Potenzial an unbeabsichtigten Fehltransformationen einhergehen, deren Bereinigung den potenziellen Zeitgewinn nivellieren würde. Zudem besteht bei zwischen- oder nachgelagerten automatisierten Verarbeitungen immer die Gefahr der Überschreibung vorheriger manueller Änderungen. Da das manuelle Vorgehen ferner kaum Spielraum für Überraschungen im Datenset oder technischer Natur lässt, erfordert es vor dem Beginn der Transformation sehr viel Zeit zum konzeptuellen vollständigen Durchdenken der Verarbeitung. Das ist angesichts der meist hohen Komplexität von historischen Forschungsdaten sehr anspruchsvoll bis unrealistisch.

Eine Alternative zur ausschließlich manuellen Transformation besteht in der initialen und möglichst weitreichenden skriptbasierten Verarbeitung der Ausgangsdaten. Manuellen Anpassungen finden hierbei erst statt, sobald die Grenzen der vollautomatisierten Verarbeitung ausgeschöpft sind. Diese Grenzen bestehen bspw. in einer – im Vergleich zu manuellen Anpassungen – unverhältnismäßig hohen Zeitinvestition und/oder einer signifikanten Gefahr von Fehltransformationen. Da der FuD-Editor regelbasiert XML-Daten erzeugt, war diese zweite Option deutlich naheliegender als die erste. Hinzukommt, dass eine von Beginn an vollautomatisierte Transformationen des Ausgangsdatensets ein explorativeres, experimentelleres Vorgehen erlaubt. Gerade zu Beginn der Transformation ist dies sehr wichtig, um sich dadurch mit dem Datenset vertraut machen zu können. Ich hatte die FuD-Forschungsdaten seinerzeit zwar mit erstellt. Wenn jedoch in einem größeren Team gearbeitet wird und mehrere Jahre zwischen Datenerzeugung und -transformation liegen, sind die Spezifika der Daten zum Zeitpunkt der Transformation nicht mehr vollständig präsent. Eine initiale vollautomatisierte Verarbeitung erlaubt es zudem, bei Bedarf immer wieder zum Ausgangszustand zurückzukehren, eine erneute Transformation in wenigen Sekunden durchzuführen und dabei das Ergebnis in kürzester Zeit sogar grundsätzlich anders zu gestalten. Im Gegensatz dazu wären beim manuellen Vorgehen alle erfolgten Anpassungen nahezu irreversibel gewesen, wenn sich im Laufe des Prozesses bestimmte Entscheidungen als nicht sinnvoll erwiesen hätten. Je später dies auffällt, umso schwerer wiegt dieser Nachteil, weil es dann nur noch schwer bis unmöglich ist, frühere Stände herzustellen, ohne die bis dahin erfolgten Anpassungen zeitaufwendig und fehleranfällig wiederholen zu müssen. Das Herstellen alter Stände wäre de facto nur mit einer sehr minutiösen Dokumentation im Rahmen einer technischen Versionierung und hohen persönlichen Versionierungsdisziplin möglich. Manuellen Anpassungen inhärent ist ferner eine deutlich höhere Gefahr für versehentliche Fehler, die selbst durch ein sehr restriktives TEI-Schema (die zudem erst entwickelt werden müsste) nicht gänzlich zu verhindern sind. Demgegenüber versprach das automatisierte Vorgehen eine höhere Datenqualität innerhalb des zur Verfügung stehenden Monats.

Der gewählte Modus Operandi war folglich: skriptbasierte Transformation so viel und so lange wie möglich und manuelle Anpassungen so wenig wie nötig und so spät wie möglich. Dieses Prinzip galt es konsequent umzusetzen.

Automatisierte Transformationen bergen allerdings die Gefahr, dass Fehltransformationen ungesehen bleiben. Deshalb erfordern sie permanent eingeschobene Überprüfungen von Zwischenergebnissen. Diese bestanden unter anderem in zufälligen Einzelstichproben aber vor allem in automatisierten Abfragen und Vergleichen von Ergebnis- und Ausgangsdatenset. Hilfreich war es bspw. die Anzahl an Einträgen, distinkten Phänomene und Zeilen beider Datensets regelmäßig abzugleichen, aber auch die Gleichzahl an öffnenden wie schließenden Tags im Ergebnisdokument zu prüfen. Auch die Kontrolle, ob sich die Zeichenanzahl und die Dateigröße erwartungsgemäß oder übermäßig stark verändern, hilft dabei, die Transformationsergebnisse einzuschätzen.

Vor- und Skriptverarbeitung

Einzelne Vorverarbeitungen grundlegender Strukturmerkmale waren erforderlich, um eine Skriptverarbeitung überhaupt erst zu ermöglichen. Diese Eingriffe betrafen bspw. das Aussondern von leeren div-Containern und Eintragsdubletten, das korrekte Sortieren der FuD-Blöcke entsprechend des inhaltlichen Textverlaufs, das Trennen kombinierter Attributwerte oder das Entfernen von editorischen Kodierungen, die nicht systematisch umgesetzt worden waren (vgl. preprocessFuD.xsl). Bei diesem Schritt war es zudem wichtig, möglichst alle im Zielformat benötigten Informationen aus dem Ausgangsdokument zu übertragen, damit das FuD-Ausgangsdokument bei allen anschließenden Weiterverarbeitungen nicht länger konsultiert werden muss.

Auf diesem bereinigten neuen Datenset konnte nun die Entwicklung der automatisierten Transformation beginnen. Das Ziel war eine TEI-konforme, einheitliche, menschenlesbare Inlinekodierung, die Annotationsinformationen an der annotierten Textstelle selbst und nicht länger an weit entfernten Bereichen des XML-Baumes (stand-off) speichert. Die Erstellung des dafür erforderlichen XSLT-Skriptes war ein iterativer Prozess. Er umfasste insbesondere die Umwandlung der Annotationen textstruktureller (Seiten- und Zeilenwechsel, Absätze, Abkürzungen etc.) und textkritischer bzw. textgenetischer (Streichungen, Hinzufügungen, Ersetzungen, Hervorhebungen etc.) Phänomene sowie semantischer Entitäten (Personen, Gruppen, Körperschaften, Geografika, Ereignisse, Objekte und Werke). Diese Annotationen lagen im FuD-XML sowohl als Inline- (paarige hi-Elemente) als auch stand-off-Markup (leere anchor-Elemente) vor. Vor allem die Umwandlung leerer Elemente in eine den XML-Regeln folgende, korrekt verschachtelte Inlinekodierung ohne Element-Überlappungen war eine Herausforderung. Unterschiedliche Annotationspraktiken der Editor:innen mussten zudem vereinheitlicht werden, bspw. die Kodierung von Streichungen als Hervorhebung (hi) einerseits und explizite Streichung (del) andererseits. Diese entstanden dadurch, dass die Streichungen in FuD sowohl mit Hilfe des graphischen Texteditors (hi) ausgezeichnet werden konnten (look and feel wie in MS Word) als auch mit der dafür vorgesehenen Annotation (del), die als Registereintrag im Analysebereich genannten textkritischen Register zur Verfügung stand. Eine weitere Herausforderung stellte die vermeintliche Eindeutigkeit von Registereinträgen für die Annotation dar. Beispielsweise wurden Überschreibungen häufig nicht – wie vorgesehen – mit der Annotation des überschriebenen Textes (del) einerseits und des überschreibenden Textes (add) andererseits ausgezeichnet. Stattdessen wurde lediglich der überschreibende Text und zudem mit del (statt add und ohne vorhergehendes del) kodiert, da die Bezeichnung des Registereintrages offenbar missverständlich war. Ferner waren gleiche, semantisch unspezifische Marker für unterschiedliche Textphänomene enthalten, die mit einer semantisch expliziten Kodierung vereindeutigt werden mussten, um sie voneinander unterscheiden und unterschiedlich verarbeiten zu können.

Da das DTABf als ein generisches Schema für Textkorpora aber auch Restriktionen beinhaltet (s.u.), wurde die Transformation nicht allein auf dieses Schema hin ausgerichtet. Um den Annotationsreichtum der Ausgangsdaten zu bewahren, war stattdessen das erste Ziel der Transformation (extractText.xsl > text_TEI_MASTER.xml) ein XML/TEI (Metadaten- und Textbereich), das gegen TEI-all validierend ein Maximalset aller im FuD-XML enthaltenen Annotationen enthält, aus dem sich wiederum ein DTABf-konformes XML automatisiert erzeugen lässt (toDTABf.xsl > geusau_reisetagebuchHeinrichxiReuss_1740.xml). Aus dem annotations- und informationsreicheren TEI wurde zudem ein Register erzeugt, das nicht mit in das DTA importiert werden kann (extractRegister.xsl > register.xml).

Was die Datentransformation deutlich erleichtert haben dürfte, ist, dass sich die damalige Konfiguration der verwendeten FuD-Instanz am Regelwerk des Thulb-Basisformats orientierte. Dieses zwischen 2017 und 2020 für verschiedenartige Quellengattungen entwickelte generische TEI-Schema stellt eine Erweiterung des DTABf dar. Da sich die FuD-Annotationsmöglichkeiten dadurch bereits sehr stark an das DTABf anlehnten, war es nicht erforderlich, völlig andersartige Annotationsbezeichnungen auf die DTABf-Annotationen semantisch zu übertragen.

Manuelle und semiautomatisierte Anpassungen

Sobald die Skriptverarbeitung ausgereizt war, begann die manuelle Umsetzung der während der Skripterstellung sichtbar gewordenen Anpassungsbedarfe. Als besonders aufwendig stellte sich hierbei die Änderung der div-Struktur des Tagebuchs heraus. Im FuD-XML bestand die TEI-Struktur aus seitenorientierten div-Containern. Sie wurden in eine dem Tagebuch strukturell besser entsprechende div-Struktur überführt. Diese besteht aus 71 Briefen und innerhalb dieser aus den einzelnen Tagebucheinträgen. Dies erforderte an vielen Stellen den paläografischen und editionswissenschaftlichen Detailblick, was eine vollautomatisierte Umwandlung der div-Struktur vereitelte.

Die manuellen und semiautomatisierten Arbeiten umfassten zudem eine Vielzahl an Bereinigungen und Kodierungen unterschiedlichster Einzelphänomene. Dazu gehörte unter anderem das Ersetzen behelfmäßiger Zeichen durch die entsprechende Unicode-Kodierung (bspw. Brüche wie 1/2 durch U+00BD), das Entfernen redundanter Kodierungen oder das Einfügen leerer Blätter. Auch durch Leerzeichen umgesetzte Einrückungen und vertikaler Leerraum wurden entfernt, da diese ohnehin kaum genau zu quantifizieren und zudem im topografisch-dynamischen digitalen Medium auf diese Weise nicht zuverlässig mimetisch wiedergegeben werden können. Auch überflüssige Leerzeichen am Zeilenfang oder -ende, die bei der Arbeit mit einem WYSIWYM-Editor schnell übersehen werden können, wurden entfernt. Ferner mussten  verbliebene editorische Platzhalter wie „#“ für fehlende oder nicht lesbare Zeichen oder „[ ]“ für editorische Anmerkungen mit dem dafür vorgesehenen semantischen TEI-Tagset nachkodiert werden.

Da die gesamte Transformation mit Github versioniert wurde, wäre notfalls auch das Wiederherstellen vorheriger Datenstände möglich gewesen. Eine permanente, in möglichst kleinteiligen und gut kommentierten Commits organisierte Versionierung der Arbeitsschritte sowie eine minutiöse Pflege der Arbeitspakete als Git-Issues ist ohnehin sehr empfehlenswert für derlei Transformationsarbeiten.

DTABf-Transformation

Wie oben erwähnt ging mit der Anpassung der Forschungsdaten an das DTABf ein gewisser Informationsverlust einher, der in der Herstellung der Korpustauglichkeit aller DTA-Editionen begründet ist. Zu den dafür erforderlichen Restriktionen gehören unter anderem ein begrenztes Set an expliziten Entitätenkodierungen (bspw. fehlende Kodierungen für Ereignisse oder mythische Personen/Geografika), fehlende Attributwertpaare für textgenetische Annotationen oder die Vereinheitlichung von Diakritika und Sonderzeichen. Zudem kann das DTABf als zeitlich stabiles Schema nicht alle zwischenzeitlichen TEI-Entwicklungen integrieren. Dazu gehört bspw. das mittlerweile überholte Verständnis des lb-Elements als „line break“ statt „line beginning“. Letzteres konnte aus ersterem aber automatisiert erzeugt werden.

Die Publikation im DTA erfordert es, die Bilder als jpg-Dateien mitzuliefern. Denn leider erlaubt der DTA-Viewer nicht das Einbinden extern gespeicherter Digitalisate, was sich aufgrund der Publikation der Digitalisate im urmel-Viewer der ThULB angeboten hätte. Das DTA ermöglicht jedoch die Publikation der bereitgestellten Bilddateien nach einer selbst gewählten Lizenz. Da die ThULB-Digitalisate beklagenswerter Weise einer restriktiven und mit den FAIR-Prinzipien schwer vereinbaren CC BY-NC-SA 4.0-Lizenz unterliegen, war dies auch zwingend erforderlich. Da die Digitalisate nur über den urmel-Viewer als PDF nicht aber auch als JPG oder in einem anderen Bilddateiformat abrufbar sind, mussten die Bilder aus den PDFs extrahiert werden. Ein dafür erstelltes Pythonskript (extractImagesFromPDF.py) übernahm die Extraktion der in den PDF enthaltenen Bilder, deren Speicherung als JPG und deren Benennung entsprechend der vom DTA vorgegebenen Notation. Die Auflösung der extrahierten Bilder ist leider schlechter als die Auflösung der über den urmel-Viewer präsentierten Bilder.

Fazit und Ausblick

Während des einmonatigen Stipendiums konnte ich ein Datenset den FAIR Data-Prinzipien entsprechend transformieren und im Deutschen Textarchiv, auf Github und Zenodo (Tagebuchtext, Register und Skripte) publizieren. Zudem ist es DWDS-indiziert, was die Analysemöglichkeiten noch einmal erweitert (vgl. bspw. die Suche nach Sentimentausdrücken im Tagebuch). Als dabei gewonnene Erkenntnisse auf Ebene der Datentransformation lässt sich Folgendes konstatieren:

XML-Editoren mit graphischem WYSIWYM-Interface, die das Ziel haben, vor der Arbeit mit Spitzklammern zu bewahren, haben ihre Stärken bei der Integration von Editor:innen mit Vorbehalten gegenüber formalisiertem Hypertext. Ihr Einsatz kann allerdings zu Lasten der FAIR Data-Prinzipien und den zeitlichen Ressourcen eines Editionsprojekts erfolgen. Im hier durchgeführten Projekt hat sich der Einsatz des FuD-Editors insbesondere unter den FAIR-Aspekten Interoperability und Reusability als problematisch erwiesen. Obwohl bereits die Konfiguration der verwendeten FuD-Instanz nah am DTABf erfolgte, erforderte die Umwandlung der Daten in ein semantisches, menschenlesbareres TEI einen hohen Aufwand. Insbesondere die nur manuell umsetzbaren Anpassungen benötigten trotz der regelbasierten XML-Erzeugung durch die FuD-Software sehr viel Zeit. Dies lag vor allem an der seitenorientierten Kodierungsstruktur, der Heterogenität der Auszeichnung gleicher Textphänomene, sowie redundante und unvollständige Kodierungen. Das Risiko heterogener Kodierungen in einem größeren Team ist zwar durch ein detailliert ausgearbeitetes und strikt umgesetztes Inter Annotator Agreement und eine (viel Erfahrung und Zeit erfordernde) vorausschauende FuD-Konfiguration reduzierbar. Es wird durch die weitere Interpretationsschicht des grafischen Interfaces von WYSIWYM-Editoren im Vergleich mit der Auszeichnung im ‚rohen‘ TEI aber offenbar auch begünstigt. Eine unmittelbare Arbeit im TEI-Code hätte an verschiedenen Stellen vermutlich sofortige Zweifel an (semantisch) fehlerhaften Auszeichnungen geweckt; und ein Blick in die TEI-Richtlinien hätte diese bestätigt. FuD ermöglicht zwar die Kontrolle der Eingaben als XML-Ansicht. Diese war in der genutzten Instanz allerdings sehr rudimentär und wurde während der Erschließung vor mehreren Jahren kaum genutzt, da zu dieser Zeit noch keine zwingende Notwendigkeit dazu erkennbar war.

Hinzu kommt die grundsätzliche Herausforderung, dass bei der algorithmischen Transformation von leeren in paarige Elemente XML-Konflikte aufgrund sich dadurch überlappender Elemente quasi vorprogrammiert sind. Leere Elemente sollten lediglich für nichttextuelle Strukturelemente wie bspw. Seiten-, Zeilen- oder Spaltenwechsel und darüber hinaus möglichst sparsam eingesetzt werden. Als XML-Editor mit hoher avisierter Generizität setzt FuD jedoch alle semantischen Auszeichnungen ebenfalls mit leeren Elementen (start- und end-anchor vor/nach der annotierten Textstelle) um, um potentielle XML-Hierarchiekonflikte zu vermeiden. Dies in Verbindung mit dem verwendeten Standoff-Markup, das Informationen zu einer Textstelle an weit voneinander entfernten Bereichen des XML-Baumes speichert, machen das FuD-XML weniger menschenlesbar und aufwändiger zu prozessieren als semantisches Inline-TEI. Vor allem bei hoher Komplexität der Auszeichnung kann die XPath-Adressierung von Text- und Elementknoten zwischen leeren Elementen zu einer Herausforderung werden, die eine paarige Annotation nicht hat.

Die Transformation der FuD-XML-Forschungsdaten erfordert aber nicht nur Zeit und bestimmte technische Fähigkeiten, sondern auch paläografische und editionswissenschaftliche sowie historische Kenntnisse. Denn häufig muss zur Überprüfung von Auszeichnungen und Text auch noch einmal die edierte Quelle konsultiert werden. Wenn dieser Aufwand in einem Projekt nicht von Anfang an mit entsprechenden Ressourcen und als explizites Aufgabenpaket der Datenkurator:innen eingeplant ist, kann dies zu einer nicht unerheblichen Belastung für den Zeitplan und die Qualität des Gesamtprojektes werden.

Sofern keine schwerwiegenden Gründe gegen das Edieren in Spitzklammern sprechen, empfiehlt es sich aus FAIR-Data-Sicht daher, von Projektbeginn an auf den Einsatz von WYSIWIM-Editoren zu verzichten und stattdessen im XML-Code zu edieren. Dafür entwickelte bzw. anpassbare Editoren (wie bspw. Oxygen XML oder Visual Studio Code) erleichtern die XML-Arbeit ungemein und reduzieren mögliche mentale oder Data Literacy-Hürden. Ihr Einsatz vermeidet anschließende aufwendige Nacharbeiten, erhöht die Qualität der Daten und führt zu einer vertieften Auseinandersetzung auch inhaltlicher Art mit dem Edendum. Durch die damit einhergehende Reduzierung von technischen Abhängigkeiten geht zudem eine Ermächtigung der Editor:innen einher. All das trägt dazu bei, WYSIWYM-Editoren als eine Übergangstechnologie zur Erzeugung von XML-Forschungsdaten sukzessive abzulösen. An dieser Stelle sei aber auch betont, dass FuD deutlich mehr als ein WYSIWYM-Editor ist und das kollaborative Edieren bspw. auch durch die Integration von Datenschnittstellen und ein elaboriertes Rechtemanagement erleichtert.

Während der Transformation sind aber nicht nur Nacharbeitungsbedarfe sichtbar geworden, sondern auch Weiterentwicklungsideen entstanden. Dazu gehören bspw. die Auflösung aller Abkürzungen, die Entitätenannotation von noch insgesamt 21 Briefen, eine noch genauere Strukturkodierung (bspw. von Listen, Akkoladen und Absätzen) sowie eine ISO-genormte Datierungs- und normdatenreferenzierte Ortsannotation. Sobald diese Arbeiten umgesetzt sind, wird eine neue Version der Edition im DTA bereitgestellt. Ein Gesamtkommentar zur Edition sowie eine zeiträumliche Visualisierung der Reise sind zudem als separate Publikation geplant.

Das FAIR-Data Stipendium schuf hervorragende Rahmenbedingungen für die Realisierung des Projektes. Ich bin daher NFDI4Memory für diese Möglichkeit und Constanze Buyken und Fabian Cremer für die hervorragende und angenehme Betreuung sehr dankbar. Marius Hug und Frank Wiegand vom DTA möchte ich sehr für die Möglichkeit der Publikation, ihre sehr schnellen und hilfsbereiten Reaktionen und schließlich alle Arbeiten danken, die DTA- und DWDS-seitig für die Indizierung des Tagebuchs erforderlich waren (und für die Bereitstellung der dann finalen Version noch werden).

---

Beitragsbild: generiertes Bild von DALL·E 3. Prompt: „An image depicting an antique book with a worn spine, displaying the title ‘Reise Herrn Heinrich d. XI. durch Teutschland Franckr. und Italien’. In front of the book is text of the book in XML code as well as an image of an 18th century count“.

---

---