AbstractAccording to the Berlin Declaration on Open Access in the Sciences and Humanities, which was signed by the President of the Academy, an initiative was founded to provide a sustainable, interactive and transparent way to inspire activities in supporting research, communication and presentation with electronic media. This initiative is called Telota – the electronic life of the academy. The scalable architecture for electronic editions tries to use the opportunities of web services applied on critical text editions and was developed while processing prominent projects such as the Corpus Medicorum Graecorum/Latinorum or the Marx-Engels Gesamtausgabe. The main component is a native XML-Database which is able to interpret XQuery-scripts to form the web application. The user, according to his needs, dynamically decides on the view of the presented texts and translations and the information which is displayed like line numbers or links to the apparatus. Thus one can customize the electronic edition depending on the scientific position and interests. If possible, facsimiles are linked to text, translation and apparatus. All projects of TPM as well as the developed tools and scripts are freely accessible at the project’s homepage [1]. |
| |
[1]
|
1. Telota – The electronic life of the academy |
[2]
|
Telota (The electronic life of the academy) ist eine Initiative der Berlin-Brandenburgischen Akademie der Wissenschaften (BBAW). Im Jahre 2002 durch den damaligen Akademiepräsidenten Prof. Simon ins Leben gerufen, soll sie Instrumente entwickeln, mit denen die BBAW ihre Forschungsergebnisse digital erarbeitet, dokumentiert und präsentiert. Sie unterstützt und befördert die Standards der digitalen geisteswissenschaftlichen Arbeit an der Akademie. |
[3]
|
Die aktuellen Aufgaben von Telota sind die Evaluierung des digitalen Zustands der Forschungsvorhaben der BBAW, die Entwicklung von Konzepten und das Setzen von Zielen der Entwicklung digitaler Arbeitsmethoden sowie die Initiierung von Projekten zur Förderung der digitalen Forschungsarbeit. |
[4]
|
Das letzte, nunmehr abgeschlossene Projekt war das Telota – Projekt des Monats (TPM). Es präsentierte jeden Monat ein neues, digitales Projekt aus den Akademienvorhaben. Es sollte das Informationsangebot für die geisteswissenschaftliche Forschung bereichern und einer interessierten Öffentlichkeit Einblicke in die aktuelle Forschung geben. Das TPM arbeitete vom Februar 2005 bis zum Februar 2007. Die Arbeitsgruppe bestand aus den Autoren und den beiden Studenten Mandy Albrecht und Stephan Klinger. |
[5]
|
Die Schwerpunkte der Projekte lagen, induziert durch die an der Akademie angesiedelten Vorhaben, im Bereich der digitalen Editionen, Wörterbücher und Prosopographien. Darüber hinaus gab es verschiedene andere Vorhaben, für die im Rahmen des TPM die unterschiedlichsten Einzelfalllösungen erarbeitet wurden, wie zum Beispiel einen georeferenzierten Zugang zu einer kunsthistorischen Datenbank per GoogleMaps (Census of Antique Works of Art and Architecture Known in the Renaissance), die wechselseitige Verknüpfung von Datenbank und Scan-Galerie (Ritter-Katalog der Leibnizforschung) oder die Entwicklung des Archiv-Editors für das Vorhaben Preußen als Kulturstaat, der aber jedem »Archivgänger« nützlich sein wird. [1] Die vorliegenden Ergebnisse vom TPM lassen sich nur unter den zeitlichen und personellen Bedingungen angemessen einschätzen, unter denen sie entstanden sind. Der Koordinator, die Mitarbeiter und die Studenten waren jeweils mit einer halben Stelle für die Aufgaben vom TPM angestellt. Das Projekt trug den Namen, Projekt des Monats, mit voller Berechtigung, da es de facto nur jeweils einen Monat für die Arbeit an einem Vorhaben zur Verfügung hatte. Da die Monate zu Beginn der Arbeit vom TPM den Vorhaben zugeordnet wurden, gab es auch keine Möglichkeit, an diesem Zustand etwas zu ändern. Zu Beginn jedes neuen Monats stand das aktuelle Vorhaben mit seinen Forderungen und Aufgaben schon bereit. Um nicht eine Vielzahl von zusammenhangslosen Einzellösungen zu produzieren, wurde von Beginn an versucht, eine einheitliche technische Grundlage zu schaffen und weiterzuentwickeln, die mit möglichst geringem technischen Aufwand die spezifischen Anpassungsaufgaben, die sich aus den Einzelprojekten ergaben, ermöglichen sollte. Wie diese technische Grundlage aussieht und welche Anwendungen sie ermöglicht, soll im Folgenden vorgestellt werden. |
[6]
|
2. Anwendungen |
[7]
|
2.1. Überblick |
[8]
|
Bei der Realisierung der Projekte vom TPM wurden gleichzeitig mehrere Ziele verfolgt, die abhängig von der Ausgangssituation unterschiedlich umfassend erfüllt werden konnten. |
[9]
|
Zum einen sollten die Mitarbeiter der Vorhaben Hilfe in ihrer täglichen Arbeit erfahren, indem Teile des herkömmlichen Arbeitsablaufes elektronisch unterstützt werden. Zum anderen sollten vorhandene oder neu geschaffene elektronische Ressourcen dem Fachpublikum und der interessierten Öffentlichkeit präsentiert und auf der Basis moderner Erschließungsmethoden zugänglich gemacht werden. |
[10]
|
Es kann hier nicht auf jedes Projekt in der notwendigen Ausführlichkeit eingegangen werden. Die verschiedenen Einzelfälle, die zudem auch auf verschiedenen Technologien beruhen, sollen hier nur kurz erwähnt werden, der große zusammenhängende Themenblock der digitalen Wörterbücher wurde an anderer Stelle schon einmal vorgestellt. [2] |
[11]
|
Das Telota-Projekt des Monats… |
[12]
|
• Februar 2005 |
[13]
|
• März 2005 |
[14]
|
• April 2005 |
[15]
|
• Mai 2005 |
[16]
|
• Juni 2005 |
[17]
|
• Juli 2005 |
[18]
|
• August 2005 |
[19]
|
• September 2005 |
[20]
|
• Oktober 2005 |
[21]
|
• November 2005 |
[22]
|
• Dezember 2005 |
[23]
|
• Januar 2006 |
[24]
|
• Februar 2006 |
[25]
|
• März 2006 |
[26]
|
• April 2006> |
[27]
|
• Mai 2006 |
[28]
|
• Juni 2006 |
[29]
|
• Juli 2006 |
[30]
|
• August 2006 |
[31]
|
• September 2006 |
[32]
|
• Oktober 2006 |
[33]
|
• November 2006 |
[34]
|
• Dezember 2006 |
[35]
|
• Januar 2007 |
[36]
|
Die zum Teil sehr umfangreichen Ergebnisse der oben kurz beschriebenen Projekte sind alle online zu besichtigen.[1] |
[37]
|
Im Folgenden wird es um zwei Anwendungstypen gehen, die uns besonders geeignet scheinen, die Arbeitsweise des TPM, die Art der entstandenen Anwendungen und die zugrunde liegende Technologie zu erläutern. Es handelt sich zum einen um den Archiv-Editor, der entwickelt wurde für die Offline-Archivarbeit und einen späteren Abgleich mit einer zentralen Online-Datenbank. Zum anderen soll der Bereich der digitalen Editionen betrachtet werden, für den wir im Verlaufe von sieben Projekten eine eigene ›Skalierbare Architektur für digitale Editionen‹ entwickelt haben. |
[38]
|
Der Aufwand für die Entwicklung beider Anwendungen sprengte den Rahmen dessen, was innerhalb eines Monats zu erreichen war. Im Falle des Archiv-Editors wurde im Startmonat die Entscheidung über den grundlegenden technischen Aufbau getroffen und die Basisversion der Anwendung programmiert. Diese Basisversion wurde dann in intensiver Diskussion mit den wissenschaftlichen Mitarbeitern des Akademienvorhabens Preußen als Kulturstaat, den zukünftigen Nutzern, zu seiner heutigen, an die Erfordernisse des Vorhabens angepassten Form weiterentwickelt. Im Falle der ›Skalierbaren Architektur für digitale Edition‹ konnte ein anderer Weg der Entwicklung gewählt werden. Im ersten Projekt, das in einem Editionsvorhaben stattfand [4], wurde, wie auch beim Archiv-Editor, die technische Basis erarbeitet, auf welcher dann die elektronische Präsentation der Edition aufsetzt. Durch die große Anzahl nachfolgender Editionsvorhaben ergab sich die Möglichkeit, unter Nachnutzung der schon entwickelten Lösungen aufbauende Erweiterungen zu erstellen beziehungsweise die Teile in der bestehenden Architektur zu ersetzen, die sich als verbesserungswürdig herausstellten. |
[39]
|
2.2. Der Telota – Archiv-Editor |
[40]
|
Neben der datenbankgestützten Internetpublikation der Ergebnisse der einzelnen Akademienvorhaben wurde, wie bereits erwähnt, die Unterstützung und Optimierung der täglichen Arbeit der Mitarbeiter der Vorhaben bedacht. Ein besonderes Werkzeug für Historiker des Akademienvorhabens Preußen als Kulturstaat, welches in diesem Rahmen entwickelt wurde, ist der Telota – Archiv-Editor‹. |
[41]
|
Das Akademienvorhaben Preußen als Kulturstaat [13] erforscht das Verhältnis von Staatsbildung, Kultur und Zivilgesellschaft im 19. und frühen 20. Jahrhundert. Ziel ist es, das Zusammenwirken wie Gegeneinander gesellschaftlicher und bürokratischer Kräfte dieses sozial, kulturell und regional unterschiedlich strukturierten europäischen Machtstaats auszuleuchten. Umfängliche archivalische Überlieferungen enthalten hierfür eine unverzichtbare Quellenbasis, wie sie vor allem aus den zentralstaatlichen Akten Preußens hervorgehen. [5] |
[42]
|
Akten sind nicht gegliedert wie Bücher, die das Ergebnis geistiger Arbeit an einer Fragestellung sind und den Gedankengang ihres Verfassers strukturiert wiedergeben. Akten sind das Produkt von Verwaltungshandeln. Diese Archivalien vereinen in sich nicht selten völlig verschiedene Vorgänge, die freilich wichtige Details und Zusammenhänge für mehrere Fragestellungen freigeben. Finden sich nun in einer solchen Akte sowohl wichtige Schriftstücke über das staatliche Vorgehen gegenüber der Landeskirche und der sich separierenden religiösen Minderheiten als auch bislang unbekannte biografische Angaben zu deren führenden Figuren, so sind beides wichtige Funde, die es für die spätere wissenschaftliche Auswertung festzuhalten gilt. Der Historiker lebt von solchen archivalischen Funden, mit denen er Entwicklungen oder Ereignisse rekonstruieren, erklären sowie zweifelsfrei belegen kann. Die Fülle an Fakten, Zusammenhängen und Fundorten jedoch überfordert sein individuelles Gedächtnis und interessante, gerade erst aus den Aktenbergen zutage gebrachte Einzelheiten drohen sogleich erneut in Vergessenheit zu geraten. Bei umfassendem Aktenstudium steht der Historiker somit vor dem Problem, in seinen eigenen Arbeitsmaterialien die unterschiedlichsten Sachverhalte einer Akte effizient und strukturiert festzuhalten, sie dabei stets an ihrer Quelle zu verorten und darüber hinaus möglichst für die eigene Fragestellung abfragbar aufzubereiten. Hierfür wurden im Rahmen des TPM neue Wege eröffnet. |
[43]
|
Mit Hilfe des Archiv-Editors können aus den Akten exzerpierte Vorgänge so erfasst werden, dass eine umfassende Suche und systematische wissenschaftliche Auswertung der Daten aller Mitarbeiter möglich ist. Des Weiteren können die Daten, die in einer an den Editor angebundenen, lokalen Version der nativen XML-Datenbank eXist gespeichert werden, in diverse Formate wie HTML, PDF oder XML exportiert werden. |
[44]
| |
[45]
|
Abbildung 1: Der Archiv-Editor. |
[46]
|
Der Editor bietet in der Grundansicht einen Überblick über alle Personen und Quellen, die in der Datenbank gespeichert sind. Wählt man eine der Personen oder Quellen aus, so werden die entsprechenden Ereignisse in den Editor geladen. Ein Ereignis ist in diesem Fall ein aus der Akte in den Editor übertragener Aktenvorgang, der relevante Informationen zu einer Person enthält. |
[47]
|
Ein Ereignis besteht aus verschiedenen Komponenten, die über das Ereigniserfassungsfenster eingegeben und modifiziert werden können. Eine dieser Komponenten ist das Datum, das der einheitlichen Erfassung wegen aus Auswahllisten zusammengestellt wird. Dabei ist es möglich unscharfe Datumsangaben zu verwenden, wie zum Beispiel »vor 1850« oder »Sommer 1867«. Jedes Ereignis ist einer Kategorie, einer Art Schlagwort, zugeordnet. Eine zusätzliche Auswahlliste enthält Unterkategorien, die es ermöglichen, ein Ereignis weiter zu spezifizieren. So kann man einem Ereignis aus der Kategorie »Person« die Unterkategorie »Geburt« zuweisen. Die Kategorien sind nicht vom Editor vorgegeben, sondern können über eine Konfigurationsdatei beliebig ergänzt oder verändert werden. |
[48]
|
Der eigentliche Text, der aus der Akte übertragen wird, steht im Ereignistextfeld. Diesem Text können aus den frei konfigurierbaren Eigenschaftsauswahllisten normierte Informationen mitgegeben werden, indem die gewünschte Eigenschaft aus einer Liste ausgewählt wird. Sind Teile des Ereignistextes mit Eigenschaften verbunden, erscheinen diese grün hinterlegt. Typ und Inhalt der Eigenschaft können über einen Klick mit der rechten Maustaste auf den grünen Bereich in Erfahrung gebracht werden. Eigenschaften sind Informationen, die andere Informationen aus dem Ereignistext näher bestimmen. So können zum Beispiel unterschiedliche Schreibweisen von Namen oder Abkürzungen durch ein kontrolliertes Vokabular leicht für die Suche zugänglich gemacht werden. |
[49]
| |
[50]
|
Abbildung 2: Das Ereigniserfassungsfenster zum |
[51]
|
Zu jedem erfassten Ereignis muss eine Quelle angegeben werden, welche man aus einer Liste bestehender Quellen auswählen kann. Diese Liste kann durch die Mitarbeiter beliebig erweitert werden. |
[52]
|
Die Daten einer Person können in verschiedenen Formaten gespeichert werden. Neben den Formaten XML und Text werden auch HTML und PDF angeboten. Datenauswahl und Gestaltung können beliebig beeinflusst werden. Die nötigen Kenntnisse vorausgesetzt, ist die Gestaltung der Ausgabe der Personendaten völlig flexibel. Die Suchfunktion basiert auf der vom W3C vorgeschlagenen XQuery-Technologie zur Abfrage von XML-Datenbanken. |
[53]
|
Um die offline erarbeiteten Daten zugänglich zu machen, wurde eine zentrale Instanz der Datenbank eingerichtet, welche alle Daten aller Mitarbeiter enthält und über das Internet erreichbar ist. Diese Datenbank kann direkt aus dem Archiv-Editor heraus mit den Arbeitsergebnissen der einzelnen Projektmitarbeiter gespeist werden. Im Gegenzug wird die lokale Datenbank des Editors auf den aktuellen Stand gebracht. So hat jeder Mitarbeiter nach einer Synchronisierung immer eine aktuelle Version der Datenbank mit im Archiv. Die zentrale Datenbank kann über eine Webseite abgefragt werden. Theoretisch ist hier ebenfalls ein Export in verschiedene Formate denkbar. |
[54]
|
Realisiert wurde der Editor mit der Programmiersprache Java. Er läuft sowohl auf Microsoft Windows, als auch auf Macintosh- und Linux-Systemen. Einzige Voraussetzung ist, dass eine Java Laufzeitumgebung in mindestens der Version 5 installiert ist. [6] Der Archiv-Editor steht zum freien Download bereit [14]. |
[55]
|
2.3. Die digitalen Editionen |
[56]
|
2.3.1. Einführung |
[57]
|
Die von uns erstellten digitalen Editionen sind meist als Reproduktion einer gedruckten Ausgabe, seltener als Vorauspublikation oder reine digitale Edition zu lesen. |
[58]
|
Der Mehrwert einer digitalen Edition gegenüber der gedruckten Fassung ist von der Datengrundlage abhängig. Dort wo wir die Strukturierung der Daten selbst beeinflussen konnten, ist eine stärkere Ablösung vom Vorbildmedium Buch zu erkennen. |
[59]
|
Das Zielformat aller unserer digitalen Editionen ist XML. Wir haben uns an den Richtlinien der Text Encoding Initiative [16] orientiert. Gegebenenfalls wurde das Tagset erweitert, um den Anforderungen optimal zu genügen. Das war insbesondere bei den Transkripten von Kants Opus postumum der Fall. Im Vordergrund stand hier, den Prozess des Kant’schen Schreibens transparent zu machen. Es mussten also auch chronologische und lokale Information von Textteilen erfasst werden. Hierfür wurde ein Container-Element eingeführt, das alle Versionen mit Informationen zur Chronologie enthält. |
[60]
|
Der Vorteil einer Buchausgabe für den Publizierenden ist, dass er das physische Format (Seitengröße, Schriftart und -grad, Randgestaltung et cetera) der Publikation mehr oder minder selbst bestimmen kann. Bei einer Online-Edition ist das Format entscheidend von anderen Faktoren abhängig, nämlich von der Größe des Bildschirms und der gewählten Bildschirmauflösung des Clients. Außerdem können auch noch zusätzliche Browsereinstellungen vorgenommen worden sein, so etwa die Kontrastdarstellung für Sehbehinderte. Oder der Nutzer verwendet gar eigene personalisierte Stylesheets für die Darstellung im Browser. Insofern bleiben unsere Layoutvorschläge nur das was sie sind: Vorschläge. Davon unbenommen aber ist die Funktionalität, die wir anbieten; die Möglichkeit, bestimmte Informationen hinzu- oder wegzuschalten, bzw. die Herstellung von Bezügen mittels Hyperlinks. |
[61]
|
Historisch kritische Editionen sind per se Hypertexte, denn sie bestehen aus einem Lesetext, Registern und mindestens einem Apparatteil, der Informationen zu bestimmten Stellen im Lesetext beinhaltet. Diese Art von Verlinkung ist allerdings von Edition zu Edition unterschiedlich gestaltet, jedoch immer unidirektional. Entweder liegt der Apparat als eigenständiger Band vor, wie es bei der Marx-Engels-Gesamtausgabe (MEGA) der Fall ist oder die Apparateinträge sind als zum Teil mehrstufige Fußnoten am Ende einer Seite untergebracht, wie bei der Reihe Die griechischen christlichen Schriftsteller der ersten Jahrhunderte (GCS), wobei sich hier wie da im Lesetext keine Hinweiszeichen auf einen Apparateintrag befinden und dieser nur von sich aus einen Bezug zum Lesetext herstellt. |
[62]
|
Dank der Skalierbarkeit des Systems konnten später im Zeitplan liegende Editionen von den bis dahin entwickelten Technologien profitieren. Die einmal entwickelten Funktionen konnten aufgrund der einheitlich verwendeten XML/TEI-Struktur zügig auf die neuen Daten angepasst und sukzessive erweitert werden. Dies soll am Beispiel der Apparatanbindung und des Navigierens in der Edition verdeutlicht werden. |
[63]
|
2.3.2 Apparatanbindung |
[64]
|
Zunächst wurde, sofern möglich, der Rückbezug vom Text zum Apparat hergestellt. Der Bezug eines Apparateintrages zum Text im Printformat wird in der Regel durch Seiten- und Zeilenzahl hergestellt, zwei Ordnungsgrößen, die es im elektronischen Medium so nicht gibt. Zudem ist letztere auch kein eindeutiger Aufsetzpunkt sondern ein Bereich, wenn auch ein feinkörniger. Da in den Basisdaten der MEGA diese Informationen enthalten waren, konnten die Apparattexte maschinell ausgewertet werden und an den tatsächlichen Beginn der Stelle im Lesetext automatisch eine Referenz gesetzt werden. Sind im Apparateintrag ›Siehe-Verweise‹ enthalten, so wurden diese mit einem aktiven Link versehen, soweit die betreffenden Textstellen- und Apparateinträge zum Umfang der realisierten digitalen Edition gehörten. |
[65]
|
Bei MEGA online kann der Nutzer wählen, ob die Apparateinträge direkt rechts neben dem Text angezeigt werden oder ob sich bei Klick auf einen Link ein Popup-Fenster mit dem Apparateintrag öffnet. Die Besonderheit der MEGA ist die starke Vernetzung der verschiedenen Teile untereinander. So gibt es neben drei Registern fünf verschiedene Apparate, die untereinander Bezüge herstellen. Um nicht den Überblick zu verlieren, wird jeder Link auf einen bestimmten Apparattyp durch ein anderes und andersfarbiges Symbol gekennzeichnet. Für das Verzeichnis nicht korrigierter korrupter Stellen beispielsweise steht ein blauer Pfeil. Ist die Einstellung »nebeneinander« gewählt, wird bei Klick auf den Pfeil im rechten Bildschirmbereich der zugehörige Eintrag angezeigt. |
[66]
|
Im Unterschied zu GCS und MEGA, die einen Ausschnitt einer bereits publizierten Edition darstellen, hatten wir beim Corpus Medicorum Graecorum/Latinorum (CMG) freie Hand, da es sich hier um eine Art elektronischer Vorauspublikation handelt. Hier konnten wir von vornherein Einfluss auf die Strukturierung des Basistextes nehmen, was sich positiv auf die Ausprägung der digitalen Edition auswirkte. |
[67]
|
Der Similienapparat und der kritische Apparat sind als unterschiedlich farbkodierte Punktsymbole der betreffenden Stelle im Lesetext vorangestellt. Ist die Apparatdarstellung ausgeschaltet, öffnet sich bei Klick auf das Symbol ein Popup-Fenster mit dem Apparateintrag. Andernfalls springt die Anzeige im Apparatbereich zu dem entsprechenden Eintrag. Für die Anzeige im Apparatbereich besteht die Möglichkeit, zu dem Apparateintrag noch einmal die fragliche Textstelle aus dem Lesetext ausgeben zu lassen. Bei Klick auf den grünen Pfeil vor dem Apparat wird dieser in den Lesetext eingefügt, um auch dort noch einmal die zugehörige Stelle zu kennzeichnen. |
[68]
|
Beim CMG ist die Anzeige der Apparate kontextsensitiv hinzu- oder wegschaltbar. Wird als Anzeige nur die Übersetzung ausgewählt, ist die Auswahlmöglichkeit für die Zuschaltung des Apparates inaktiv, weil es nur zu dem griechischen Lesetext Apparateinträge gibt. |
[69]
|
Der kritische Apparat vom CMG wurde bei der Dateneingabe kategorisiert. Das ermöglicht nicht nur eine erweiterte Suchmöglichkeit in eben dieser oder jener spezifischen Apparatkategorie, es können auch die für die jeweilige Kategorie normierten Begriffe im Apparateintrag farblich hervorgehoben werden. |
[70]
|
Da gerade bei der MEGA die Referenzierung der Apparateinträge seiten- und zeilenbasiert ist, haben wir uns entschlossen, neben einer bildschirmangepassten Darstellung auch eine zeilenorientierte Darstellung anzubieten. Wählt man unter Einstellungen diese Darstellung aus, so wird der der Buchausgabe entsprechende Zeilenumbruch ausgegeben, allerdings erlauben die technischen Möglichkeiten bei fest vorgegeben Zeilenumbruch dann leider nur den Flattersatz im HTML. |
[71]
|
2.3.3. Navigieren |
[72]
|
Neu zu definieren ist bei digitalen Editionen die Granularität des auf einer Bildschirmseite anzuzeigenden Textausschnitts. Bei den bereits als Druck vorliegenden Editionen haben wir uns entschieden, die Seitenaufteilung zu übernehmen, die jedoch für eine sinntragende Textstrukturierung unerheblich ist. Der Nutzer blättert also wie im Buch Seite für Seite vorwärts. Zusätzlich kann er zu einer beliebigen Seite springen, indem er die Seitennummer in das kleine Formularfeld unter der Blätternavigation einträgt und auf das Buchsymbol klickt. |
[73]
|
Diese bei MEGA online eingeführte Blätternavigation ist auf alle folgenden Editionsprojekte vererbt worden. Jedoch kommt bei CMG online jeweils ein Lemma [7] mit Lemmakommentar als Textabschnitt zur Anzeige. Ebenso bezieht sich eine Blättereinheit der Bulla Aurea aus den Monumenta Germaniae Historica auf je ein Kapitel des Gesetzbuches. |
[74]
|
Im Gegensatz zu MEGA liegen bei CMG und GCS jeweils der Lesetext und die zugehörige Übersetzung vor. Hier kann der Nutzer entscheiden, ob er den Lesetext in griechischer Sprache, die Übersetzung in deutscher Sprache oder beide Texte zugleich auf dem Bildschirm sehen möchte, die dann automatisch mitgeblättert werden. |
[75]
|
Neben der Ausgabe im Browserfenster besteht bei MEGA online die Möglichkeit, die aktuelle Seite mit den zugehörigen Apparaten als PDF on-the-fly zu generieren. Diese Funktion soll in erster Linie illustrieren, dass ein- und dasselbe Datenformat für verschiedene Ausgabezwecke genutzt werden kann und dass dies auch implementiert ist. |
[76]
|
2.3.4. Suche |
[77]
|
Zu allen digitalen Editionen gehört eine XQuery-basierte Suchfunktion. Diese reicht je nach Datengrundlage und Anforderung von einer einfachen Volltextsuche bis hin zu kategoriengeleiteten Suchformularen. Die Anzeige der Suchergebnisse wurde sukzessive verbessert. Standardmäßig werden nun die Treffer im KWIC-Format [8] ausgegeben, wobei die KWIC-Zeilen einen Link auf die Herkunftstextstelle enthalten. Die Anzahl der anzuzeigenden Treffer kann der Nutzer selbst einstellen. Da die Suche direkten Zugriff auf die XML-Strukturen der Dokumente hat, ist es unproblematisch für verschiedene digitale Editionen, die verschiedene Kategorien auszeichnen, eine kategoriengeleitete Suche anzupassen. Darüber hinaus werden die Suchergebnisse in einem eigenen Datenpool vorgehalten, so dass man jederzeit zu ihnen zurückkehren kann. Das Gleiche gilt auch für die Möglichkeit der Speicherung der gestellten Suchanfragen. |
[78]
|
3. Ergebnisse |
[79]
|
3.1. Skalierbare Architektur für digitale Editionen |
[80]
|
Die skalierbare Architektur bietet für die Erstellung von digitalen Editionen ein modulares, frei skalierbares System, das sowohl auf Seiten des Benutzers – der Client- oder Browserseite – als auch auf Seiten des Anbieters – der Serverseite – den jeweiligen Bedürfnissen anpassbar ist. |
[81]
|
Da nicht alle Nutzer einer digitalen Edition denselben Interessenschwerpunkt teilen, ist so die Möglichkeit gegeben, die gewünschte Information optimal zu präsentieren. |
[82]
|
Die nutzerseitige Skalierbarkeit bezieht sich in erster Linie auf das Interesse des jeweiligen Nutzers. Dieser ist in der Lage, durch das Hinzu- und Wegschalten bestimmter Komponenten die digitale Edition so seinen Wünschen anzupassen, dass er optimal damit arbeiten kann. Es ist an ihm zu entscheiden, welche Editionsbestandteile gleichzeitig auf dem Bildschirm Platz haben. Soll es nur der editierte Text sein, eine vorhandene Übersetzung, verschiedene Textvarianten, Apparate, welche Apparate, neben oder unter dem Text oder in einem extra Fenster, sollen Faksimile angezeigt werden und wenn ja, wo und wie viele? Die nutzerseitige Oberflächengestaltung ist durch diesen Ansatz von der serverseitigen Systemarchitektur unabhängig. |
[83]
|
Die technische Grundlage hierfür bildet die AJAX-Technologie [9], welche eine benutzeroptimierte Darstellung und on-the-fly-Anpassung der Web-Oberfläche inklusive der angezeigten Inhalte ermöglicht. Dabei wird die Seite beim Hinzufügen einer Komponente nicht jedes Mal vollständig neu aufgebaut, sondern lediglich der angeforderte Bereich eingefügt. |
[84]
|
Serverseitig bezieht sich die Skalierbarkeit auf den Einsatz modular aufgebauter Datenbankabfrage- sowie Datentransformationsskripte. Erstere sind XQuery-Skripte, welche die Abfragen nach bestimmten Teilen der Datenbank übernehmen und je nach Webservice oder Projekt nur minimal angepasst werden müssen, um auf ein anderes Projekt übertragen zu werden. Letztere sind XSLT-Skripte, die es ermöglichen, mit browserseitigen Cascading Style Sheets (CSS) [18] die frei parametrisierbare Gestaltung der Ausgabe der Daten in verschiedene Ausgabeformate zu übernehmen. Durch eine standardisierte Datenerfassung, die an die Richtlinien der Text Encoding Initiative angelehnt ist, lassen sich sowohl die XQuery-Skripte zur Abfrage als auch die XSLT-Skripte zur Ausgabe der Daten projektübergreifend wieder verwenden. Die standardisierte Datenerfassung ermöglicht zudem ein zeitnahes, kontinuierliches Wachsen der Inhalte durch das Mitwirken der Editoren einer kritischen Edition. |
[85]
|
Die Basis für die serverseitige Skalierbarkeit ist der Einsatz der nativen XML-Datenbank eXist, die einen eigenen XQuery-Prozessor und einen XSLT-Prozessor mitbringt. |
[86]
|
Das folgende Schaubild verdeutlicht die ›Skalierbare Architektur‹. |
[87]
| |
[88]
|
Abbildung 3: Die Skalierbare Architektur für digitale Editionen. |
[89]
|
Die Datenerfassung erfolgt in XML, entweder nach den Richtlinien der TEI oder nach einem eigenen standardisierten XML-Schema. Die erfassten Daten werden in der Datenbank eXist vorgehalten, welche im Servlet-Container Tomcat [19] eingebunden ist. Vom Client wird per AJAX eine Anfrage an den Apache-Webserver [20] gestellt, der die Anfrage an den Tomcat weiterleitet. Dort wird sie von eXist weiterverarbeitet, was bedeutet, dass das entsprechende XQuery-Skript ausgeführt wird und dass Ergebnis entweder direkt als XML an den Client zurückgegeben oder, in den meisten Fällen, durch eine XSL-Transformation für die Ausgabe im Browser aufbereitet wird. Der Browser erledigt seinerseits per CSS die Formatierung des serverseitig generierten XHTML. Anstelle einer XSL-Transformation ist es möglich, durch eine XSL-FO-Transformation eine formatierte Ausgabe der XML-Daten als PDF zu erzeugen. |
[90]
|
3.2. Erfahrungen mit den verwendeten Technologien |
[91]
|
Leider haben die erwähnten Technologien, die zur Umsetzung der oben genannten Lösungen benutzt wurden, neben den erfreulichen Vorteilen für die Verarbeitung geisteswissenschaftlicher Daten auch einige Nachteile. So eignet sich eine native XML-Datenbank wie eXist tatsächlich sehr gut zur Speicherung und Abfrage semistrukturierter Daten, zum Beispiel Texte mittelalterlicher Urkunden oder antiker Papyri. Für Daten, die weniger dokumentzentriert, sondern in klaren Strukturen vorliegen, ist jedoch aus Performancegründen eine relationale Datenbank zu bevorzugen. Auch große Datenmengen (ab mehreren hundert Megabyte) und zahlreiche komplexe, tief verschachtelte XML-Dokumente können die Geschwindigkeit der Datenbankabfrage derzeit noch beeinträchtigen. |
[92]
|
Hinzu kommt, dass native XML-Datenbanken eine relativ junge Technologie sind und sich daher, wie auch die Abfragesprache XQuery, in ständiger Weiterentwicklung befinden. Aufgrund der Erfahrungen, die aus der Benutzung gewonnen werden, kann es vorkommen, dass bestimmte Module entfernt, hinzugefügt oder funktional umgestaltet werden. In XQuery sind die Änderungen hauptsächlich syntaktischer Natur, was im schlimmsten Fall dazu führen kann, dass ein aktueller XQuery-Prozessor Schwierigkeiten hat, ältere XQuery-Skripte zu verarbeiten. |
[93]
|
Ähnliches gilt für die verwendeten W3C-Standards XSLT [10], XPath [11] und XSL-FO [12], die sich in ständiger Weiterentwicklung befinden. So werden neue Funktionen implementiert, die die Lösung bestimmter Aufgaben erheblich performanter beziehungsweise überhaupt erst möglich machen. Da die Optimierung der eingesetzten Technologien jedoch durchaus im allgemeinen Interesse liegt, kann diese Art Nachteil auch positiv verstanden werden. Die Gelegenheit, die Skripte auf den neuesten Stand zu bringen, kann man so auch gut mit der Optimierung der eigenen Arbeit verbinden. |
[94]
|
Die unterschiedlichen Ergebnisse der Projekte sind maßgeblich von dem uns zur Verfügung stehenden elektronischen Material abhängig. Für die Konvertierung lagen uns die Daten in den im Kapitel 2 genannten verschiedenen Formaten vor. Eine besondere Herausforderung der Projekte des Monats war es, aus den unterschiedlichen Daten ein Maximum an struktureller Information zu gewinnen, um diese dann im Zielformat XML für die spätere Verwendung vorzuhalten. |
[95]
|
Die besten Ergebnisse konnten wir bei den Vorhaben erzielen, die über gut strukturierte Basisdaten verfügten oder die noch ganz am Beginn ihrer Arbeit standen und bei denen wir Einfluss auf die Strukturierung der Basisdaten nehmen konnten. Am schwierigsten waren semistrukturierte Word-Dokumente zu bewältigen, vor allem, weil Informationen dargestellt werden mussten, die keine strukturellen Entsprechungen in den Dokumenten hatten. Problematisch waren auch die für den Satz vorgesehenen Tustep-Dateien, denn hier war in erheblichen Maße strukturelle Information zugunsten von Layout-Informationen verloren gegangen beziehungsweise gar nicht erst aufgenommen worden. |
[96]
|
4. Konsequenzen |
[97]
|
Welche Möglichkeiten bietet nun das oben vorgestellte System? Wie aus der Beschreibung zu erkennen ist, gibt es bei der ›Skalierbaren Architektur für digitale Editionen‹ keinen klassischen Software-Bereich, der dem Nutzer des Systems verschlossen bleibt. Alle Komponenten sind frei zugänglich und können von diesem auch geändert werden. Die verwendeten Technologien zur Textanzeige bzw. Textgenerierung beruhen sämtlich auf unabhängigen, internationalen Standards. |
[98]
|
Das System ist so einfach und variabel wie möglich konzipiert. Es verlagert die editorischen Inhalte dorthin, wo sie eigentlich hingehören, in die Daten und nicht in die unikale Softwarelösung einer Benutzeroberfläche. Dadurch stehen die Daten auch unabhängig von der Benutzeroberfläche zur Verfügung. Gerade für Editionsprojekte ›in progress‹ bietet sich außerdem die Möglichkeit einer unkomplizierten Publikationsform des aktuellen Arbeitsstandes. Durch die Existenz einer angepassten skalierbaren Architektur an ein konkretes Editionsprojekt lassen sich neu edierte Dokumente ohne Aufwand in das System einlesen. Die einzige Bedingung ist, dass die Struktur des neuen Dokuments den Vorgaben entspricht. |
[99]
|
Eine weitere Möglichkeit, die sich durch diese datenorientierte Erfassung editorischer Sachverhalte ergibt, ist die Möglichkeit der nahezu unbegrenzten Tiefenstrukturierung der Daten und dies unabhängig von der Darstellbarkeit aller ausgezeichneten Informationen. Nicht immer ist es unter dem Gesichtspunkt der Übersichtlichkeit sinnvoll, alle verfügbaren Querverweise auch anzuzeigen. Natürlich lassen sich im elektronischen Medium Verweise durch Hyperlinks realisieren. Aber was passiert, wenn diese Links an zentralen Punkten des Textes kumulieren? Welche Form der Darstellung soll man wählen, wenn mehr als drei Verweise von einer Textstelle ausgehen sollen? Sollte es nicht möglich sein, die Hyperlinks nur entsprechend den veränderbaren Nutzereinstellungen zu erzeugen? Aber nicht nur bei der übersichtlichen, situationsangepassten Darstellung des Textes bringt eine Tiefenstrukturierung Vorteile. Auch und vielleicht sogar besonders für die Recherchierbarkeit des Textes bieten sich hier neue Möglichkeiten, die weder vom Buch noch von ›klassischen‹ elektronischen Editionen [13] ermöglicht werden. Solche verborgenen Informationen, die niemals zur Anzeige gelangen und auch nicht zur Anzeige gelangen sollen, können etwa normalisierte Namen in den Namensregistern sein oder auch, wie zum Beispiel im TPM Mai 2006 die Abbildung der vielfältigen griechischen Wortformen auf das jeweils zugrunde liegende Lemma und die damit verbundene Suchmöglichkeit eines Lemmas in seinen flektierten Formen. Gleiches gilt für die Verknüpfung des Wörterbuchs der manichäischen Texte mit den mittelpersischen Texten der Turfan-Forschung (TPM Januar 2006). Die Verknüpfung eines Wörterbuchstichworts mit dem Vorkommen aller flektierter Formen in den Texten der Edition ist ›händisch‹, also ohne automatisch auswertbare Tiefenstrukturierung unmöglich. |
[100]
|
Als dritte, neue Möglichkeit, die das vorgestellte System bereitstellt, sei hier abschließend noch die bisher eher theoretische Möglichkeit der Nutzung von Daten einer Edition in anderen Kontexten genannt. Dass diese Fremdnutzung und im Übrigen auch Fremdbenutzung von Teilen des Editionstextes nur begrenzt sinnvoll ist, soll hier nicht bestritten werden. Die Frage sei aber erlaubt, ob es denn wirklich hilfreich ist, Sach- und Namensregister für Editionen, die im Kontext gleicher historischer Zeiträume arbeiten, jedes Mal aufs Neue zu erstellen? Oder, ob es nicht vielmehr wünschenswert wäre, ausgewählte und passende elektronische Ressourcen gemeinsam zu nutzen und sie zum eigenen und zum Vorteil anderer bestenfalls zu verifizieren oder sogar zu erweitern? Voraussetzung für eine solche gemeinsame Nutzung und Verbesserung von elektronischen Ressourcen ist allerdings die Möglichkeit des Zugriffs auf die zugrunde liegenden Daten einer digitalen Edition und nicht nur die Möglichkeit, auf die Oberflächenpräsentation eines Editionstextes zugreifen zu können. Anders gesagt gibt es durchaus vorstellbare Nutzungssituationen für digitale Editionen, bei denen es keinen unmittelbaren menschlichen sondern einen maschinellen Nutzer gibt. |
|
|
[1] |
Eine vollständige Liste aller Projekte findet sich unter [2].
|
[2] |
Neumann 2006b.
|
[3] |
Der Terminus »native XML-Datenbank« bezeichnet die besondere Eigenschaft einer Datenbank, spezielle technische Vorrausetzung für die genuine Verarbeitung von XML-Dokumenten zu besitzen. [5].
|
[4] |
Das erste Editionsvorhaben, das im Rahmen des TPM bearbeitet wurde, war die Marx-Engels-Gesamtausgabe.
|
[5] |
Die inhaltliche Projektbeschreibung basiert auf einem Text von Fr. Dr. Bärbel Holtz, der Arbeitsstellenleiterin des Akademievorhabens Preußen als Kulturstaat.
|
[6] |
Die aktuelle Version der Laufzeitumgebung kann von den Webseiten der Firma Sun bezogen werden [15].
|
[7] |
Lemma im Sinne der Altphilologie und nicht im lexikografischen Sinne.
|
[8] |
Keyword in context.
|
[9] |
Asynchronous JavaScript and XML [17].
|
[10] |
Extensible Style Language Transformation [21].
|
[11] |
XML Path Language [22].
|
[12] |
Extensible Stylesheet Language – Formatting Objects [23].
|
[13] |
Unter ›klassischen‹ elektronischen Editionen sollen hier Editionen verstanden werden, die ihren Text zwar elektronisch aufbereitet haben, als Ergebnis aber eine statische, schwer veränderbare elektronische Version der Printausgabe erzeugt haben.
|