Schlagwort-Archive: TEI

Report of the 2019 TEI SIG Text and Graphics meeting

by Martin de la Iglesia (HAB)

Text and Graphics is one of currently 10 active Special Interest Groups (SIGs) within the Text Encoding Initiative (TEI). Although the TEI is concerned first and foremost, as its name suggests, with the encoding of text, users of the TEI Guidelines will often also want to encode information relating to graphics which occur either as digital facsimiles of the text pages or as inline figures within the text. The Text and Graphics SIG aims to “discuss, develop, and document various strategies and best practices for implementing the digital facsimile structures available in TEI P5, especially as relates to graphically rich texts, and for developing methods to extend the TEI when existing structures are not suitable” (https://wiki.tei-c.org/index.php?title=SIG:Text%26Graphic). The SIG usually holds an informal meeting during the annual TEI Conference and Members’ Meeting.

Accordingly, this year’s SIG meeting took place in Graz, Austria, on September 17. To a small but select audience, Uwe Sikora (Göttingen State and University Library, Germany) kicked off the meeting with a presentation of a software application he is developing for the “Ilanot – Maps of God” project (http://ilanot.haifa.ac.il/site/, SUB Göttingen / University of Haifa). In this project, kabbalistic parchment scrolls containing “divine topographies” will be edited in the form of interactive maps. Uwe’s tool, which is based on the VGG Image Annotator (VIA,  http://www.robots.ox.ac.uk/~vgg/software/via/) and runs within the Virtual Research Environment TextGrid (https://textgrid.de/), enables users to select portions on a digital image in the shape of rectangles, polygons, paths, circles, ellipses and points.

These shapes are stored as SVG code that contains coordinates to record their position on the digital image.

The SVG shapes are linked to TEI code in which the selected scroll sections are encoded as tei:zone elements. Using a Graphical User Interface, semantic relations between these zones may be defined by arranging them in a hierarchical structure.

Furthermore each shape may be annotated by custom metadata and tagged according to a custom ontology:

Textual content of the scrolls can be transcribed and added to the resulting TEI document in the usual way, which may then be presented – in their respective positions, as indicated by the SVG code – as an annotation layer on top of the image. A standalone version of the application is going to be developed to provide non-TextGrid users the possibility to annotate image files on their own system and create TEI resources locally.

This approach ties nicely into a discussion that we have had in the SIG and the wider TEI community since at least the 2016 meeting in Vienna: are the current TEI Guidelines sufficient if we want to encode the position of zones in a non-TEI format? The corresponding GitHub Issue is https://github.com/TEIC/TEI/issues/1508, if anyone would like to weigh in. The idea is that some encoders prefer other formats such as JSON or SVG over the att.coordinated attributes (https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.coordinated.html) available in tei:zone (as well as in tei:surface and tei:line). One motivation behind this might be that other formats offer more options for defining shapes, e.g. circles which in SVG are simply encoded using x and y coordinates for the circle center and a third attribute for the radius. Another motivation might be interoperability: some applications may output coordinate data as e.g. JSON files which one would like to refer to directly from the TEI document, while some applications may require e.g. JSON as input – perhaps the most prominent example being IIIF applications – and one does not want to store the same coordinate data twice, in both TEI and JSON.

There are three possible solutions:

  1. Leave everything as it is. In the TEI document, semantically vague linking mechanisms such as @corresp may be used to refer to the non-TEI code, or in some cases it may be stored directly somewhere in the TEI file using its own namespace. Applications need to be configured on a case-by-case basis in order to make use of such coordinate data.
  2. Augment the TEI Guidelines so that TEI can express anything you want. For instance, if you would like to encode a circle in SVG style, a tei:circle element and @radius attribute need to be introduced. If other formats are still necessary for interoperability reasons, the TEI data can then be losslessly converted.
  3. Keep coordinate data in non-TEI files, but introduce a semantically strong linking mechanism so that the TEI code explicitly tells you what to expect at the other side of the link. For instance, a new attribute named @pointsRef would mean: “this link refers to coordinate points for the parent element”. Add some MIME type information, and relatively generic applications could be created that would know how to process e.g. SVG or JSON coordinates when they are explicitly referred to as such in a TEI document.

So far, no consensus has been reached about this issue, but questions of how TEI data and non-TEI data interact become more and more urgent as technologies such as IIIF rapidly rise in popularity.

Recommended citation: Martin de la Iglesia: Report of the 2019 TEI SIG Text and Graphics meeting. In: Ex officina Seleni: aus der Werkstatt der Herzog August Bibliothek Wolfenbüttel. Blog der Arbeitsgemeinschaft Digitale Editionen. October 17, 2019. https://eos.hypotheses.org/272.

Handschriftliche Vielfalt im Griff der spitzen Klammern

Beitrag von Hanne Grießmann (HAB)

Es ist eine Herausforderung – aber sie lohnt sich: Im Rahmen des MWW Forschungsprojekts „Text und Rahmen“ werden mittelalterliche und frühneuzeitliche Psalmenhandschriften und -drucke durch die Kodierung nach TEI-Richtlinien maschinenlesbar gemacht. Auf dieser digitalen Grundlage können die erfassten Texte mit Hilfe von Computern analysiert und über Fachgrenzen hinweg genutzt werden.

Der zweisprachige Psalter Wolfenbüttel, Herzog August Bibliothek, Cod. Guelf. 81.10 Aug. 2° ist eine der spätmittelalterlichen Handschriften, die im Projekt “Mediengeschichte der Psalmen” nach TEI-Richtlinien kodiert werden.

Das Austarieren zwischen der vielfältigen Seitengestaltung mittelalterlicher Psalmen-Handschriften und der streng logischen und sauberen Klammerstruktur eines XML-Dokuments ist in meiner Arbeit eine wiederkehrende Herausforderung. Denn viele Fragen und Probleme stellen sich erst in dem Moment, in dem ich beginne, eine konkrete Handschrift für das Projekt „Mediengeschichte der Psalmen“ zu transkribieren.

Vielfältiges Erscheinungsbild

Wer sich bereits mit spätmittelalterlichen Handschriften beschäftigt hat, der weiß um ihr äußerst vielfältiges Erscheinungsbild: Sie unterscheiden sich stark voneinander in der Einrichtung (ein- oder zweispaltiges Seitenlayout), im Buchschmuck (Initialen, Rubrizierungen, Unterstreichungen), im Grad der Sorgfalt (Streichungen und Korrekturen), in den Schreibkonventionen (Hochpunkte, Virgeln, Häufigkeit von Abkürzungen) und nicht zuletzt in der Sprache (Schreibsprache, Wortwahl). Diese Eigenschaften der Handschriften werden beim Transkribieren mitkodiert. Dafür gibt es eine Grammatik, die XML (Extensible Markup Language – Erweiterbare Auszeichnungssprache), und ein Wörterbuch, den Standard der Text Encoding Initiative (TEI).

Der Aufbau eines XML-Dokuments erfolgt in einer Struktur, in der verschiedene Elemente ineinander verschachtelt sind. Diese können wiederum mit Inhalten – hier mit den Texten der Handschriften – gefüllt werden. Diese Verschachtelung kann beliebig tief fortgeführt werden. Die Funktion oder Bedeutung eines Elements wird durch sogenannte Tags definiert. Diese umschließen als Start- und End-Tag in spitzen Klammern den jeweiligen Inhalt, und bei eben dieser Umklammerung handelt es sich um das Kodieren oder Auszeichnen.

An Psalm 18,5 aus der Lutherbibel (Stuttgart, Deutsche Bibelgesellschaft 1999) führe ich vor, wie eine TEI-konforme Kodierung einer modernen Psalmenausgabe aussehen kann:

Würde dieser Psalm aus der Lutherbibel im Projekt „Mediengeschichte der Psalmen“ kodiert werden, sähe Vers 5 so aus:

Hier wird die angesprochene Verschachtelung sichtbar. <ab> dient als Wurzelelement, das wie ein Container alle folgenden Elemente enthält. Da in unserem Projekt die Struktur der Psalmen untersucht und verglichen werden soll, würden hier insbesondere die typographischen Strukturmerkmale mit sogenannten Attributen ausgezeichnet; also die hochgestellte Versnummer 5 (Attribut: rend=”sup”) und das im Fettdruck (Attribut: rend=”bold”) stehende Alinea-Zeichen. Die Tiefe der Verschachtelung hält sich in diesem Fall jedoch in überschaubaren Grenzen.

Ein etwas anderes Bild ergibt die Auszeichnung von Psalm 18,5 aus der nachstehend abgebildeten Handschrift Wolfenbüttel, Herzog August Bibliothek, Cod. Guelf. 81.10 Aug. 2°.

Bei dieser Handschrift handelt es sich um einen zweisprachigen Psalter aus dem 15. Jahrhundert. Den Psalmen ist jeweils ein mittelniederdeutscher Kommentar vorangestellt. Jeder einzelne Psalmvers ist im Anschluss in Latein sowie in seiner mittelniederdeutschen Übersetzung oder Auslegung wiedergegeben. Zur Strukturierung des Werkes haben sich Schreiber und Rubrikator üblicher zeitgenössischer Mittel bedient: Große, rote Lombarden kennzeichnen den Beginn eines neuen Abschnittes (in diesem Fall des neuen Kommentars), rubrizierte Majuskeln (Großbuchstaben) gliedern den Fließtext (in diesem Fall die Psalmverse), und rote Unterstreichungen heben bestimmte Textteile (in diesem Fall die lateinischen Verse) hervor.

Der lateinische Beginn von Vers 18,5 ist in der Handschrift wie folgt gestaltet:

Die Auszeichnung von Psalm 18,5 aus dieser Handschrift sieht wiederum so aus:

Neben der Länge fällt besonders die umfangreichere und tiefere Verschachtelung auf. Dies ist der Struktur geschuldet, die von der Handschrift vorgegeben wird, hängt jedoch auch mit dem Aufbau eines XML-Dokuments zusammen: Die unterschiedlichen Kodierungselemente müssen konsequent verschachtelt werden. Gibt es hier Widersprüche oder Überschneidungen, ist das Dokument nicht wohlgeformt und kann nicht weiter verarbeitet werden.

Konsequent verschachtelt

Die Abkürzungen korrekt zu kodieren, ist eine besondere Herausforderung: Bereits das erste Wort besitzt vier Eigenschaften, die durch Klammern ausgedrückt werden müssen: die rubrizierte Initial-Majuskel, die Worttrennung am Zeilenende, die durchgehende rote Linierung sowie die Abkürzungen. Hat man jedoch das grundlegende Prinzip eines XML-Dokuments verstanden – eine innerhalb einer Eltern-Klammer geöffnete Kinder-Klammer muss auch innerhalb dieser Eltern-Klammer wieder geschlossen werden –, bekommt man auch diese ausführlicheren strukturellen Merkmale in den (Klammer-)Griff.

An dem hier angeführten Beispiel wird bereits deutlich, wie schwierig es sein kann, die mittelalterliche Schriftgestaltung in eine korrekte XML-Struktur zu übertragen. Noch komplizierter wird es, wenn weitere Zusätze berücksichtigt werden müssen, die nicht so einfach strukturiert werden können oder die mit einer bereits bestehenden Struktur in Konflikt geraten würden. So trifft man zum Beispiel in mittelalterlichen Handschriften häufig auf Randbemerkungen, die eine inhaltliche Ergänzung darstellen. Sie können über mehrere Zeilen gehen, oftmals von anderer Hand geschrieben sein und sich auf Textteile beziehen, die über einen Spalten- oder Seitenumbruch hinausgehen können.

Fundiertes Hilfsmittel

Hier stößt man durchaus an Grenzen der hierarchischen Schachtelung, doch finden sich in den TEI-Richtlinien auch Lösungsvorschläge für den Umgang mit solchen, einander übergreifenden Strukturen (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/NH.html). In den Richtlinien wird an dieser Stelle zwar nicht explizit auf mittelalterliche Textphänomene und deren Kodierung Bezug genommen, doch ist es möglich, mit den bestehenden Elementen und Attributen die unterschiedlichen strukturellen Phänomene spätmittelalterlicher Handschriften auszuzeichnen. Dies setzt jedoch eine kontinuierliche Auseinandersetzung mit den unterschiedlichen Auszeichnungsmöglichkeiten und teilweise eine flexible Handhabung der Elemente und Attribute voraus.

Durch die Arbeit mit  verschiedenen spätmittelalterlichen Handschriften und ihrer Transkription und Kodierung liegen für das Projekt „Mediengeschichte der Psalmen“ inzwischen Richtlinien vor, wie und nach welchen Regeln ausgezeichnet wird. Durch diese Richtlinien, in denen Kodierungslösungen für zahlreiche Phänomene verzeichnet sind, sowie durch die Weiterentwicklung eines schnellen Auszeichnungssystems für die Transkriptionsarbeit wird zum Abschluss des Projektes ein fundiertes Hilfsmittel für Arbeiten mit einer ähnlichen Ausrichtung in der Texterfassung und -behandlung bereitstehen. Zahlreiche Kodierungsfragen, die im Verlauf des Projektes aufgekommen sind und sicher auch noch aufkommen werden, müssen so bei zukünftigen Forschungsvorhaben nicht mehr geklärt werden. Stattdessen können unsere Ergebnisse übernommen, angewendet und ausgebaut werden.

 

Zitierempfehlung:
Hanne Grießmann: Handschriftliche Vielfalt im Griff der spitzen Klammern.
In: Ex officina Seleni: aus der Werkstatt der Herzog August Bibliothek Wolfenbüttel. Blog der Arbeitsgemeinschaft Digitale Editionen. 6. Juli 2017. https://eos.hypotheses.org/241.

How to build a digital edition web app

Beitrag von Peter Andorfer (ACDH), Dario Kampkaspar (HAB) und Timo Steyer (MWW)

Aufgrund zahlreicher Sommer-Schulen, Workshops, DH-Studiengänge und vielfältiger online Tutorials stellt die Kodierung eines Textes in XML nach dem de facto-Standard TEI für viele GeisteswissenschaftlerInnen mittlerweile eine gut zu bewältigende Herausforderung dar. Anders formuliert: Digitale Editionen haben die Wild-West-Phase hinter sich und bieten dem Forscher ein methodisch und theoretisch sicheres Terrain. Was jedoch häufig fehlt sind einstiegsfreundliche Anleitungen, Tutorials, HowTos zu dem sich an die Kodierung anschließenden Themenkomplex der Publikation einer digitalen Edition. Die Frage nach dem »Wohin?« der oftmals in langer und mühsamer Arbeit erstellten Editionen betrifft vor allem jene Forschende, welche nicht Teil eines größer angelegten Projektes sind oder auch sonst über keine allzu starke Anbindung an eine gut institutionalisierte Forschungsinfrastruktur verfügen. Zwar entwickeln zunehmend mehr Institutionen, vielfach durch Drittmittelprojekte, Kompetenzen, Workflows und (technische) Infrastrukturen zur Veröffentlichung Digitaler Editionen, aufgrund chronisch knapper Finanzierungen können oftmals aber nur wenige und in erster Linie nur eigene/interne Projekte hinreichend betreut werden.

Gleichzeitig kann in vielen Digitalen Editionsprojekten eine sehr starre Arbeitsteilung zwischen so genannten FachwissenschlafterInnen und TechnikerInnen beobachtet werden. Obwohl es sicherlich nicht als Nachteil bewertet werden kann, wenn jeder das tut, wofür er ausgebildet wurde und was sie bzw. er demzufolge auch gut kann, so besteht in einem stark arbeitsteiligen Umfeld die Gefahr asymmetrischer Kompetenzverhältnisse und daraus resultierender Abhängigkeiten. Sei es durch unrealistische Wünsche seitens der Fachwissenschaft, die aufgrund mangelnder technischer Kenntnisse an die Technik herangetragen werden. Oder sei es die Verzögerung des Arbeitfortschritts aufgrund schleppender Implementierung basaler Technologien oder von editorischer Seite dringend benötigter Funktionalitäten.

Dies ist aber nur die eine Seite der Medaille, denn es gibt nach wie vor infrastrukturelle Fallstricke bei der Erstellung von digitalen Editionen. Viele Editionsprojekte beginnen ohne eine entsprechende Infrastruktur für die spätere Präsentation der Texte, andere Editionstexte entstehen als „Nebenprodukt“ eines wissenschaftlichen Forschungsvorhaben und werden nie publiziert, da eine wissenschaftliche out-of-the-box Präsentationslösung fehlt. Es fehlt sichtbar an einer einfachen Lösung für Editionsvorhaben ihre Texte in einer Infrastruktur zu publizieren bzw. zu erproben, die noch keine institutionelle Anbindung mit einem festen „Layout- und Funktionskorsett“ hat und den Editoren so noch den weitreichenden experimentellen Freiraum lässt, um die für die Editionsvorhaben notwendigen Präsentationsmodi zu identifizieren.

Dieser Problematik widmete sich der von Peter Andorfer (ÖAW/ACDH), Dario Kampaskar (HAB) und Timo Steyer (MWW/HAB) konzipierte Workshop mit dem Titel „How to build a digital edition web app“ auf der diesjährigen Tagung des DHd-Vereins in der Schweizer Bundeshauptstadt Bern. Auf der Basis der XML-Datenbank eXist-DB wurde gemeinsam mit den Workshopteilnehmern eine Präsentationsoberfläche am Beispiel der Korrespondenz von Leo Thun-Hohenstein erstellt. Für die Verwendung der XML-Datenbank eXist-db spricht ihr Open-Source-Charakter, die verbreitete Nutzung im digitalen Editionskontext und die Möglichkeit weitere Funktionsweisen durch Zusatzprogramme hinzuzufügen. Die Nachteile von eXist liegen in der relativ kleinen Community und der für viele Anwendungsbereiche noch nicht existierenden detaillierten Dokumentation.

Beginn des Workshops auf der Dhd17 in Bern. Bild des Tweets von Stefan Münnich (@music_enfanthen):”Workshop #w6 how to build your own digital web app with @csae8092 @steyer_ti & kampkaspar about to start #dhd2017″. https://twitter.com/music_enfanthen/status/831406933852684288 (20.02.2017)

Eine ›Digital Edition Web-App‹ sollte ganz generell die kodierten Texte in einer möglichst benutzerfreundlichen Art und Weise präsentieren und den »technischen Unterbau« dem Benutzer nicht aufbürden, wohl aber die computergestützte Weiterverarbeitung der Texte jederzeit ermöglichen. Konkreter formuliert heißt das, dass eine solche Anwendung  folgende Anforderungen zu erfüllen hat.

NutzerInnen sollen auf einer zentralen Einstiegsseite einen möglichst vollständigen Überblick über den kompletten Umfang der Edition erhalten. Dies ist insbesondere dann von großer Bedeutung, wenn die Edition aus mehreren Editionseinheiten besteht, wie zum Beispiel im Falle eines Briefwechsels.

In der im Zuge des Workshops zu entwickelnden Applikation wird das in Form einer ListView gelöst, welche sämtliche XML/TEI Dokumente bzw. ausgewählte Informationen aus dem teiHeader in einer von den NutzerInnen such-, filter- und sortierbaren Ansicht präsentiert. Von diesem Inhaltsverzeichnis gelangen die NutzerInnen dann über Verlinkung zu den einzelnen Dokumenten.

Da Digitale Editionen im www verfügbar sind, muss davon ausgegangen werden, dass diese generell in digitaler Form, sprich auf einem PC, Notebook, Tablet, eventuell auch auf einem Smartphone gelesen werden. Insofern gilt es, den kodierten Text in einer leserfreundlichen Darstellung anzuzeigen, die die verschiedenen Formate der Anzeigegeräte berücksichtigt (womit einige der Grundlagen des sog. ›responsive design‹ berücksichtigt werden müssen). Andererseits darf aber der Wunsch vieler Nutzer, die Inhalte »klassisch« auf Papier zu nutzen, nicht vergessen werden.

Die digitalen Darstellung im Web eröffnet indes auch die Möglichkeit für dynamische, sprich von den Nutzer/innen frei konfigurierbare, Darstellungsweisen. Abhängig vom konkreten Mark-Up können, um nur ein paar Beispiele zu nennen, etwa Anmerkungen ein- oder ausgeblendet, Abkürzungen aufgelöst, oder Korrekturschritte ausgeblendet werden.

In der ›Digital Edition Web-App‹ wird mittels XSLT Transformation aus den XML Dateien eine HTML Dokument ›on the fly‹ generiert. Diese ›DetailView‹ verfügt, sofern aufgrund des Markups des Ausgangsdokumentes möglich, über ein Navigationsmenü, welches eine rasche Orientierung im Text ermöglicht. Über ein weiteres Menü können außerdem verschiedene Darstellungsoptionen (de)aktiviert werden.

Die Möglichkeit, eine digitale Edition in ihrer Gesamtheit im Volltext durchsuchen zu können, wird häufig als einer der größten Vorzüge einer digitalen Edition beschrieben. Zusätzlich zu einer so genannten »einfachen Suche« wird darüber hinaus auch gerne eine »erweiterte Suche« angeboten, welche eine spezifizierte Suche wie zum Beispiel nur in Anmerkungen oder über  Metadaten ermöglicht.

Aufgrund der Integration der Volltext-Suchengine Lucene in die Datenbanksoftware eXist-db ist die Realisierung sowohl einer »einfachen« wie auch einer »erweiterten« Suche im Rahmen der ›Digital Edition Web-App‹ einfach zu bewerkstelligen, wobei die Spezifika der »erweiterten« Suche vom konkreten Markup der einzelnen Editionen abhängt.

Neben einer Volltextsuche bieten viele digitale Editionen auch eine registerbasierte Suche an, mit deren Hilfe etwa gezielt Personen oder Orte in der Edition identifiziert werden können.

Je nach Art der Daten wird ein solches Register auf verschiedene Weisen demonstriert werden. Da die Texte in einer (einigermaßen) standardisierten Art und Weise kodiert sind, können diese auch maschinell prozessiert werden. Dafür ist es notwendig, dass nicht nur eine HTML Darstellung der Daten veröffentlicht wird, sondern auch die eigentlichen XML/TEI-Daten.

Die ›Digital Edition Web-App‹ wird ihre Daten über die in der eXist-db integrierte ›REST-Style Web API‹ veröffentlichen.

Es würde hier zu weit führen, einen vollständigen Abriss des Workshops zu geben, dies ist aber auch gar nicht nötig, da die einzelnen Bestandteile des Workshop inkl. Code- und Datenbeispiele hier zu finden sind:

https://howto.acdh.oeaw.ac.at/blog/books/how-to-build-a-digital-edition-web-app

Peter Andorfer und Dario Kampkaspar: Time to set you free. Posterbeitrag auf der TEI-Konferenz 2016. https://howto.acdh.oeaw.ac.at/blog/books/how-to-build-a-digital-edition-web-app/ (4.3.2017)

Es kann also jeder den Workshop nachvollziehen und seine eigene Umgebung für Editionstexte aufbauen. Der Workshop zeigte von Beginn an, wie eXist-db eingerichtet wird, wie die Texte in die Datenbank gelangen, wie eine auf Bootstrap basierende Präsentationsoberfläche gebaut wird. Darauf aufbauend lernten die Workshopteilnehmer die Erstellung von automatisiert erstellten Register, die Erstellung einer Volltextsuche und von Inhaltsverzeichnisse. Die in XML in die Datenbank geladende Texte werden über XLST-Skripte dynamisch in eine HTML-Ausgabe transformiert.

Gelobt wurde die Gestaltung eines Workshops verbunden mit einer Dokumentation, die es den Teilnehmern erlaubt auch nach der Konferenz noch alles nachzunutzen – ganz im Sinne des Tagungsmotto: Nachhaltigkeit.

Weiterführende Links: “set you free”: 

https://howto.acdh.oeaw.ac.at/blog/books/how-to-build-a-digital-edition-web-app/

Zitierempfehlung: Peter Andorfer / Dario Kampkaspar / Timo Steyer: How to build a digital edition web app. In: Ex officina Seleni: aus der Werkstatt der Herzog August Bibliothek Wolfenbüttel. Blog der Arbeitsgemeinschaft Digitale Editionen. 13. März 2017. https://eos.hypotheses.org/151.