Abstract

• 1. Probleme und Begriffe
• 2. Statisch, automatisch und ähnlich
• 3. dse-static-cookiecutter
• 4. Lösungsansätze für Einschränkungen statischer Webseiten
  • 4.1 Register
  • 4.2 Volltextsuche
  • 4.3 Schnittstellen
  • 4.4 Faksimiles
  • 4.5 Versionierung
  • 4.6 FAIR data
• 5. Abschluss und Ausblick
• Bibliografie
• Abbildungsverzeichnis

1. Probleme und Begriffe

[1]Digitale Editionen werden oftmals im Rahmen von auf zwei bis drei Jahren befristeten drittmittelfinanzierten Projekten realisiert.‍[1] Während dieser Zeit werden ausgewählte Texte im TEI-XML-Format kodiert. Die Art der Auszeichnung und der verwendeten TEI-Tags orientiert sich an der jeweiligen Fragestellung und dem zu edierenden Material. Die TEI-XML-Kodierung ist für die Forscher*innen dabei primär Mittel zum Zweck der Veröffentlichung einer digitalen Edition. In der Regel verstehen sie darunter eine Webseite zur Darstellung, Publikation und Durchsuchbarkeit (Volltextsuche, registerbasierte Suche) ihrer edierten Texte. Für die Realisierung dieser Webseite werden Kooperationen mit einschlägigen Institutionen wie etwa dem Austrian Centre for Digital Humanities (ACDH) eingegangen. Von diesen Institutionen wird erwartet, dass sie nach der Entwicklung einer qualitativ hochwertigen und aktuellen Standards‍[2] entsprechenden digitalen Edition das stabile und langfristige Hosting der Edition betreiben. Seitens der Projektpartner*innen und Fördergeber*innen stehen für gewöhnlich nach Projektabschluss keine finanziellen Ressourcen mehr zur Verfügung.‍[3] Was ist nun konkret als Zeitraum für den Bestand einer Edition anzunehmen? Zwei Jahre scheint zu kurz, zehn Jahre scheint lang. Wer weiß schon, wie das Internet in zehn Jahren funktioniert? Am ACDH wird grundsätzlich garantiert, die im Projekt entwickelten Applikationen, worunter auch digitale Editionen fallen, zwei Jahre nach Projektende online zu halten. Nach diesem Zeitraum werden diese weiter automatisch überwacht‍[4] und technisch notwendige Updates – im Falle von überschaubarem Aufwand und unter Berücksichtigung der personellen Ressourcen – durchgeführt. Als zusätzliche Erschwernis kommt es immer wieder vor, dass Applikationen auf veralteter Technologie basieren und die ursprünglichen Entwickler*innen der Applikation nicht mehr zur Verfügung stehen. Derartige Applikationen müssen nach einer abschließenden technischen Evaluierung und der Sicherung der Daten und des Quellcodes vom Netz genommen werden.‍[5]

[2]Was bedeutet ›langfristig‹ nun im Kontext dieses Beitrages? Langfristig heißt hier, dass eine auf den Prinzipien des dse-static-cookiecutter‍[6] basierende digitale Edition so lange online bleiben kann, wie der institutionelle Kontext, in dem die Edition publiziert wurde, nicht strukturell geändert oder aufgelöst wird. Das heißt auch, dass das Überleben der Applikation weder an die Entwicklung einer bestimmten Technologie gekoppelt ist, noch an die Karriere einer einzelnen Person.

[3]Bleibt noch zu klären, was der vorliegende Beitrag unter einer digitalen Edition versteht.‍[7] Eine digitale Edition beschreibt hier eine Reihe von TEI-XML-Dateien – in der Regel handelt es sich dabei um eine »erschließende Wiedergabe historischer Dokumente«‍[8] – die in einer kuratierten Form als HTML-Dateien im Kontext einer Webseite im Internet zugänglich gemacht werden. Eine digitale Edition besteht also neben den Daten auch aus einem spezifisch für diese Daten entwickelten Interface, einer je nach Machart mehr oder weniger individualisierbaren Leseansicht.

2. Statisch, automatisch und ähnlich

[4]Am ACDH versucht man dem Versprechen, digitale Edition langfristig am Leben zu erhalten, mit Hilfe dreier Prinzipien gerecht zu werden. Diese Prinzipien werden von den Schlagworten ›statisch‹, ›automatisch‹ und ›ähnlich‹ skizziert.

[5]›Statisch‹ – im Gegensatz zu ›dynamisch‹ – bezieht sich hier auf ein bestimmtes Konzept von Webseiten, nämlich solche, deren Inhalte bereits als eigenständige (statische) HTML-Dateien vorliegen. Im Unterschied zu vielen komplexeren Webseitenlösungen stellt das sicher, dass eine einzelne Seite nicht bei jeder Abfrage, bei jedem Aufruf neu berechnet werden muss.‍[9] Das reduziert den Anspruch beim Hosting und bei der Maintenance solcher Webseiten deutlich, da weder eine Datenbank benötigt wird noch ein webseiten-spezifischer Code am Server ausgeführt werden muss. Somit fallen gleich zwei Komponenten dynamischer Webseiten weg, die von regelmäßig notwendigen Updates betroffen wären und potentielle Sicherheitslücken beinhalten könnten. Vor allem bedeutet jedes Update, dass an solchen Schnittstellen danach eine Bruchstelle entstehen kann, die die ganze Seite unbrauchbar macht. Bis zum Ausrollen des dse-static-cookiecutters wurden digitale Edition am ACDH als dynamische Webapplikation mittels eXist-db, einer Java basierten, nativen XML-Datenbank publiziert. Dies war insofern eine naheliegende Entscheidung, als eXist-db neben der Verwaltung von XML-Dateien auch Tools und Funktionen bereitstellt, die es erlauben, dynamische, datengetriebene Webapplikationen zu entwickeln und zu publizieren. Dazu zählen etwa ein integrierter Webserver (Jetty), eine XQuery-basierte Templating-Engine, ein leistungsstarker Suchindex (Lucene), eine integrierte Entwicklungsumgebung (eXide), eine Anbindung an den Oxygen-XML Editor und vor allem auch eine in den digitalen Geisteswissenschaften verankerte Community. Diesen Vorteilen standen die Nachteile solcher dynamischen Lösungen gegenüber, vor allem das regelmäßige Nachziehen von Updates von neuen eXist-db Versionen als auch der benötigten Java-Umgebung. Unter dem Gesichtspunkt der Langfristigkeit muss außerdem bedacht werden, dass es sich bei einer Software wie eXist-db um ein vergleichsweise kleines Open-Source-Projekt handelt, welches eng an einige wenige Developer*innen geknüpft ist.‍[10]

[6]Das Schlagwort ›automatisch‹ beschreibt die Aktionen, die notwendig sind, um die fertigen HTML-Dateien der statischen Webseite aus den TEI-XML-Dateien der Edition zu generieren und online zu publizieren. Dieser Build-Prozess kann je nach Projekt mehrere Schritte umfassen. Welche Schritte dies sind, welche Umgebung (Betriebssystem, Software, welche Versionen) diese benötigen und in welcher Reihenfolge diese auszuführen sind, ist dabei in einer menschen- wie maschinenlesbaren Datei konfiguriert. Ein solches Setup erlaubt es, die digitale Edition unabhängig von den ursprünglichen Entwickler*innen respektive deren Arbeitsgeräten neu zu bauen und zu publizieren. Im dse-static-cookiecutter wird ein solcher automatischer Build-Prozess mit Hilfe einer YAML-Datei konfiguriert, welche vom CI/CD-Service GitHub-Actions interpretiert und ausgeführt wird. Alternativ dazu generiert der dse-static-coociecutter auch ein Dockerfile, wodurch das Prinzip ›automatisch‹ auch ohne Rückgriff auf die Infrastruktur von GitHub realisiert ist.

[7]Das dritte Schlagwort ›ähnlich‹ bezieht sich auf den im Build-Prozess ausgeführten Programmcode und dient dazu, die digitalen Editionen noch stärker von ihren Entwickler*innen zu entkoppeln. Statische digitale Editionen, die mit dem dse-static-cookiecutter realisiert werden, sind hinsichtlich der verwendeten Technologien, der Organisation der TEI-XML-Daten, des Quellcodes sowie des Build-Prozesses ähnlich. Das erleichtert es für Entwickler*innen und Systemadministrator*innen, allfällig notwendige Adaptionen an den Editionen vorzunehmen, sobald sie sich mit der Codebase einer einzelnen Edition vertraut gemacht haben.‍[11]

3. dse-static-cookiecutter

[8]Der dse-static-cookiecutter ist ein Static-Site-Generator für TEI-XML-Dateien. Das Ziel ist es, digital (scholarly) editions – abgekürzt DSE – als statische (static) Webseiten zu veröffentlichen. Implementiert ist dies auf Basis der in Python geschriebenen »cross-platform command-line utility«cookiecutter, womit Name und Funktionalität in aller Kürze beschrieben wären.

[9]Um den dse-static-cookiecutter für ein neues Projekt einzusetzen, müssen sowohl Python als auch das Python-Package cookiecutter installiert sein. Danach wird mit dem Befehl cookiecutter gh:acdh-oeaw/dse-static-cookiecutter der Initialisierungsprozess einer neuen, auf dse-static-cookiecutter basierten digitalen Edition gestartet. Nun werden ein Dutzend Fragen gestellt, beispielsweise nach dem Titel der Edition, der zukünftigen URL, dem Speicherort der TEI-XML-Dateien,‍[12] der Standardsprache des User Interfaces bzw. ob Internationalisierung‍[13] implementiert werden soll.

Abb. 1: Screenshot aus dem Initialisierungsprozess eines neuen digitalen Editionsprojektes. [Screenshot: Peter Andorfer 2025]

[10]Alle Fragen verfügen über vorgefertigte Antwortmöglichkeiten. Die meisten Antworten können außerdem nachträglich in einer globalen Konfigurationsdatei (xslt/partials/params.xsl) geändert werden.

[11]Das Ergebnis dieses Initialisierungsprozesses ist ein vom dse-static-cookiecutter angelegtes Dateiverzeichnis, welches aktuell 38 Ordner und über 2300 Dateien umfasst. Von diesen Dateien entfällt der Großteil auf Open-Source-Drittbibliotheken wie etwa das CSS-Framework Bootstrap, den Image-Viewer OpenSeadragon oder den XSLT-Prozessor Saxon. Zieht man diese ab, bleiben nur noch rund 60 Dateien übrig.

[12]Den eigentlichen Kern des Quellcodes bilden XSLT-Dateien, welche die TEI-XML-Dokumente der Edition nach HTML transformieren. Der Transformationsprozess ist in einer ANT-XML-Datei namens build.xml konfiguriert und wird von dem bereits erwähnten XSLT-Prozessor Saxon ausgeführt. Vereinfacht gesagt, definiert man in build.xml, welche Dateien mit welchem Stylesheet konvertiert werden und wohin und unter welchem Namen die erzeugten HTML-Dateien gespeichert werden sollen. Die Konvertierung kann mit dem Kommandozeilenbefehl ant ausgeführt werden, wofür ANT am Rechner installiert sein muss. Alternativ kann die Konvertierung über den XML-Editor Oxygen durchgeführt werden. Dieser gängige XML-Editor wird vom dse-static-cookiecutter von Haus aus unterstützt, indem bereits während der Initialisierung einer neuen Edition eine Oxygen-Projektdatei angelegt wird, die die Transformationsszenarien zur Konvertierung der TEI-XML-Dateien nach HTML mittels XSLT enthält.

[13]Die XSLT-Dateien sind modular aufgebaut. Sogenannte partials sind für Teile des zu generierenden HTML-Codes zuständig und können von anderen XSLT-Dokumenten eingebunden werden. Beispiele dafür wären etwa: partials/html_footer.xsl, partials/html_navbar.xsl oder partials/html_head.xsl. Damit wird die Duplizierung von Code reduziert und Elemente, die auf allen generierten HTML-Seiten anzutreffen sind, wie etwa ein Navigationsmenü oder eine Fußzeile, lassen sich in nur einer einzigen Datei ändern.

[14]Spezialseiten wie eine Startseite (index.html), das Impressum (imprint.html) oder eine 404-Seite (404.html) werden mit entsprechenden XSLT-Dateien (index.xsl, imprint.xsl, 404.xsl) generiert.

[15]Die eigentlichen TEI-XML-kodierten Editionsdateien werden vom dse-static-cookiecutter in dem Verzeichnis data/editions erwartet. TEI-XML-kodierte Paratexte (z.B. ›Über das Projekt‹, ›Editionsrichtlinien‹, ›Team‹, …) in data/meta. Vom dse-static-cookiecutter werden gleichnamige XSLT-Dateien (editions.xsl und meta.xsl) zur Verfügung gestellt, welche sämtliche in den genannten Verzeichnissen abgelegten Dateien nach HTML konvertieren.

[16]Die HTML-Standarddarstellung der einzelnen Editionseinheiten ist bewusst einfach gehalten, was der großen Heterogenität von Editionsprojekten, den zu edierenden Dokumenten und der jeweiligen TEI-Kodierung geschuldet ist. Für häufig anzutreffende Kodierungsmuster stellt der dse-static-cookiecutter mit dem Stylesheet partials/shared.xsl aber einige XSL-Templates bereit, etwa für TEI-kodierte Tabellen (tei:table, tei:row, tei:cell) und Listen (tei:list, tei:item), für Absätze (tei:p) und Zeilenumbrüche (tei:lb) oder für Verweise (tei:ref), Anmerkungen (tei:note), unklare Lesarten (tei:unclear), Streichungen (tei:del).

[17]Ein eigenes Stylesheet toc.xsl iteriert über alle Dateien in data/editions, liest die Informationen aus dem TEI-Header aus und erstellt daraus ein Inhaltsverzeichnis der editierten Dokumente (toc.html). Dieses Inhaltsverzeichnis wird als Tabelle dargestellt. Dank der JavaScript-Bibliothek tabulator.info können Nutzer*innen die Sortierung der Tabelle ändern, die einzelnen Spalten durchsuchen, Spalten ein- und ausblenden und die Tabelle exportieren (HTML, JSON, CSV). Jede Zeile der Tabelle verlinkt auf die HTML-Seite des entsprechenden edierten Dokumentes. Da im Falle des dse-static-cookiecutters als die Datengrundlage für tabulator.info eine HTML-Tabelle (html:table) verwendet wird (möglich wäre auch eine JSON-Repräsentation der Daten), bleibt die Basisfunktion dieses Inhaltsverzeichnisses – Überblick zu den Inhalten der Editionseinheiten und Verlinkung zu diesen – aufrecht, selbst wenn zukünftige Browsergenerationen die verwendete tabulator.info-Version nicht mehr unterstützen sollten.

[18]Als Registerdaten werden standardmäßig unterstützt: Personen-, Orts-, Organisations- und Werkregister. Dafür ist das Verzeichnis data/indices vorgesehen. XSLT-Dateien (listperson.xsl, listplace.xsl, listorg.xsl, listbibl.xsl) sind für deren Konvertierung verantwortlich, wobei diese Dateien eine spezifische TEI-Kodierung der Registereinträge erwarten (tei:listPerson, tei:listPlace, tei:listOrg, tei:listBibl). Für Registereinträge werden tabellarische Listenansichten generiert, welche ebenfalls mit Hilfe von tabulator.info interaktiv sind. Das Ortsregister wird außerdem durch eine Kartenansicht ergänzt (implementiert mittels Leaflet), sofern die dafür notwendigen Geodaten von den Editor*innen erhoben wurden.

Abb. 2: Ortsregister mit Kartenansicht aus dem Editionsprojekt Familiensache. Angezeigt werden hier nur die in der Tabelle gefilterten Absendeorte. [Screenshot: Peter Andorfer 2025]

[19]Die Kartenansicht ist mit der Ortstabelle verknüpft, das heißt, nur die in der Tabelle angezeigten Einträge werden auf der Karte dargestellt, so dass sich der Kartenausschnitt ändert, wenn Filter in der Ortstabelle angewandt werden. Zusätzlich wird für jeden Registereintrag, also für jede Person, jeden Ort, jedes Werk eine eigene HTML-Seite generiert. Diese präsentiert neben den im Registereintrag verzeichneten Informationen wie etwa dem Namen der Person, Lebensdaten, Normdaten (z.B. GND, Wikidata) auch eine Auflistung sämtlicher Editionseinheiten, in welchen besagte Entität erwähnt wird. Entitäten von Editionsprojekten sind somit eindeutig über ihre projektspezifischen URLs referenzierbar, wodurch andere Projekte auf diese verlinken können. Die Datei beacon.xsl verwendet diese URLs, um eine GND-Beacon-Datei‍[14] zu erstellen.

4. Lösungsansätze für Einschränkungen statischer Webseiten

5. Abschluss und Ausblick

[32]Die vom dse-static-cookiecutter implementierten Prinzipien ›statisch‹, ›automatisch‹ und ›ähnlich‹ sind weder neu noch originell. Static-Site-Generatoren gibt es schon lange – die erste Version (v1.0.0) von Jekyll wurde am 14. Juni 2013 veröffentlicht – und neue Frameworks zum Bau statischer Webseiten, wie beispielsweise eleventy oder Astro – werden laufend entwickelt.‍[35] Statische Seiten finden auch in den digitalen Geisteswissenschaften ihre Verwendung, häufig im Kontext des Begriffs minimal computing, wie in: »Minimal computing is static site generation«.‍[36] So handelt es sich beim Webauftritt von DHQ: Digital Humanities Quarterly um eine mittels XSLT und ANT generierte statische Seite, welche mit Hilfe von GitHub-Actions gebaut und veröffentlicht wird (und ihre Volltextsuche mit staticSearch implementiert).‍[37] Ähnlich funktioniert auch der Webauftritt von The Programming Historian, der auf Jekyll basiert.‍[38] Und auch digitale Editionen werden abseits dse-static-cookiecutter-basierter Projekte in Form von statischen Seiten realisiert.‍[39] Es bestehen auch Pläne, bestehende dynamische Editionen im Sinne einer besseren Langlebigkeit in statische Seiten zu konvertieren.‍[40]

[33]Dass sich Projekte effizienter realisieren und warten lassen, wenn sie auf einen gemeinsamen respektive einen ähnlichen Quellcode zugreifen und den gleichen Technologie-Stack verwenden, dürfte offensichtlich sein. Dies trifft auch auf digitale Editionen zu. Dafür gibt es eine Reihe von Tools, welche sich zum Ziel gesetzt haben, die Erstellung und Publikation von TEI-XML-basierten digitalen Editionen zu unterstützen. Solche Tools reichen von generischen XSLT-Stylesheets zur Konvertierung von TEI-XML-Dateien nach HTML‍[41] oder der JavaScript-Bibliothek CETEIcean für die Darstellung TEI-XML-Dateien im Webbrowser über out-of-the-box Lösungen für spezifische Editionstypen wie dem EVT-Viewer oder dem Edition-Crafter bis hin zu vielfach verwendeten Komplettlösungen wie etwa dem TEI Publisher.‍[42] Bei letzterem handelt es sich zwar um eine auf eXist-db basierte, dynamische Applikation, allerdings wurde daran gearbeitet, statische Lösungen zu implementieren.‍[43] Hinzu kommen die vielen Frameworks, Setups und Systeme, die an spezialisierten Institutionen wie Bibliotheken, Universitäten oder Akademien gepflegt werden.‍[44] Eine aktuelle Übersicht wäre sicherlich sehr gewinnbringend.‍[45]

[34]Der dse-static-cookiecutter versucht den Spagat zwischen einem spezifisch auf die Bedürfnisse des ACDH zugeschnitten Werkzeug und einem allgemein zugänglichen Tool zum Entwickeln und Publizieren von digitalen Editionen. Der spezifische Gebrauch am ACDH zeigt sich etwa in der im Initialisierungsprozess einer neuen Instanz gestellten Frage nach einer ›Redmine-ID‹ (welche anschließend benötigt wird, um eine aktuelle Impressum-Seite zu generieren) oder in der fehlenden Unterstützung von staticSearch. Andererseits werden technologische und konzeptionelle Entscheidungen immer mit Blick darauf getroffen, einen technologisch möglichst niederschwelligen Einstieg zu ermöglichen. Während die bereits erwähnten Alternativen zum dse-static-cookiecutter sehr stark auf JavaScript setzen, baut der dse-static-cookiecutter primär auf XSLT-Transformationen zur Generierung der HTML-Seiten. Grundkenntnisse in X-Technologien sind in den digital affinen Geisteswissenschaften häufig vorhanden.‍[46] Dies trifft auch auf die starke Integration des dse-static-cookiecutters mit GitHub und vor allem GitHub-Pages zu. Das ACDH hätte zwar eigene Ressourcen und Infrastruktur, womit sich der Build- und Deploy-Prozess individueller und flexibler gestalten ließe,‍[47] setzt aber bewusst auf GitHub und GitHub Pages, um auch jene Projekte zu unterstützen, die nicht auf eine vergleichbare Infrastruktur zurückgreifen können. Das Nicht-Unterstützen aktueller JavaScript-Tools wie etwa eines Package-Managers‍[48] zur Installierung der verwendeten Bibliotheken oder eines Build-Tool wie Vite für die Entwicklung und Implementierung projektspezifischer interaktiver Elemente ist ebenfalls eine bewusst getroffene Entscheidung mit dem Zweck, den Zugang zum dse-static-cookiecutter einfach zu gestalten.

[35]Ob Editionen, die mit dem dse-static-cookiecutter realisiert wurden und werden, das eingangs gegebene Versprechen der Langfristigkeit einlösen können, wird die Zukunft zeigen. Die bisherigen Erfahrungen stimmen allerdings positiv. Was die weitere Entwicklung des dse-static-cookiecutters betrifft, so stehen aktuell die Bereiche Schnittstellen und Zitierbarkeit im Vordergrund. Darüber hinaus wird am ACDH gerade an einem zentralen Triplestore unter anderem für Entitäten aus digitalen Editionen‍[49] und an einem linguistischen Suchservice‍[50] zu automatisch linguistisch annotierten Volltexten digitaler Editionen gearbeitet, die grundsätzlich auch für Projekte außerhalb des ACDH offenstehen sollen.