Eine Magisterarbeit von Johanna Neumann, 2006 Referent: Stefan Lang, stefan.lang@uni-koeln.de

1. Ein allgemeiner Datentyp für die implizite Bereitstellung komplexer Texteigenschaften in darauf aufbauender Software Eine Magisterarbeit von Johanna Neumann, 2006 Referent: Stefan Lang, stefan.lang@uni-koeln.de

2. Übersicht • Einleitung • Darstellung von Text • Markup-Sprachen • Überlappungsproblem • Lösungsansätze zum Überlappungsproblem • Zeichenketten in der Programmierung • Die Klassen XChar, XTextData und XText für „erweiterte Zeichen“ • Fazit

3. Einleitung • „Normale“ Textverarbeitung reicht für die Zwecke der Geisteswissenschaften nicht aus. • Quellmaterial kann nicht originalgetreu genug wiedergegeben werden. • Deshalb gibt es Markupsprachen, die Texte beschreiben können (Bereitstellung von Texteigenschaften ist explizit, nicht implizit)

4. Einleitung • Ziel dieser Magisterarbeit ist eben diese implizite Bereitstellung von Texteigenschaften auf Progammierebene. • Dafür wird ein neuer Datentyp eingeführt (Weiteres dazu im späteren Teil des Referats)

5. Allg. Anforderungen an Textkodierung • 1. Original soll möglichst detailgetreu dargestellt werden können. • 2. Digitale Weiterverarbeitung sollte möglich sein. • 3. Alle impliziten und virtuellen strukturellen Eigenschaften eines Textes sollten explizit darstellbar sein. • 4. „Form des Inhalts“ sollte zur Geltung kommen.

6. Darstellung von Text • Transkription von historischen Texten (z.B. Handschriftensammlungen) nicht einfach • Prinzip des hermeneutischen Zirkels: • Problem: Unterscheidung von Repräsentation und Interpretation von Texten: Wo zieht man die Grenze?

7. Explizite Bereitstellung von Texteigenschaften 4 Komponenten, die zur Aussage eines Textes beitragen: • Inhalt • Formatierungs- und Layoutangaben • Struktur (z.B. bei Gedichten wichtig) • Logische Informationen (Worte als Personen, Daten, Ortsangaben etc. erkennen)

8. Descriptive Markup Language (DML) bzw. Generic Markup -> beschreibt die Syntax von Daten Procedural Markup Language (PML) -> beschreibt die Schritte, die zur Darstellung nötig sind. Textauszeichung durch Markup • Zwei Gruppen von Markup Language:

9. Descriptive Markup Language (DML) bzw. Generic Markup • Dokumentstrukturen sowie logische Informationen werden beschrieben. • Dies geschieht meist in SGML oder in XML, z.T. auch in TEI (Format der Text Encoding Initiative) • Vorteil: Änderungen in externer Datei sind leicht vorzunehmen. • Problem: Dem Text wird eine Struktur aufgezwungen, die evtl. gar nicht vorhanden ist, hierarchischer Aufbau wird angenommen.

10. 3 Probleme der Descriptive Markup Language (DML) nach Ted Nelson • Editierbarkeit der Dokumente (…“SGML is not a working format.“) -> Bei der Überarbeitung eines Dokuments gerät die Reihenfolge der Tags durcheinander. 2. “Transpublishing“ (virtuelles Einbinden von Material anderer Quellen) -> Das Markup der externen Datei könnte nicht passend sein, schwierige Einbettung. 3. „Structures that don‘t fit“ (Strukturen, die nicht ins hierarchische Schema von XML oder SGML passen). -> So genanntes Überlappungsproblem.

11. Überlappungen und nicht-hierarchische Daten • Überlappung: <tag1>…<tag2>…</tag1>…</tag2> • (Überlappung) tritt auf… …bei gleichzeitiger Auszeichnung von physikalischer und logischer Struktur (d.h. Formatierungsanweisungen und Aufbau werden gleichzeitig beschrieben) … in Beschreibungen nur der logischen Struktur (metrische und grammatische Struktur stimmen nicht überein, z.B. muss das Ende eines Satzes nicht auch das Ende eines Verses sein).

12. Überlappungen und nicht-hierarchische Daten • (Überlappung) tritt auf… …bei Objekten, die sich selbst überlappen können (abweichende Lesearten eines Worts, Hyperlinks, Durchgestrichenes) …bei Textinhalten, die nicht in hierarchische Strukturen gebracht werden können (unterbrochene Listen, unterbrochene Gedichte innerhalb eines Texts) …bei Mehrdeutigkeiten (z.B. der Satz: „I saw the man with the telescope“)

13. Lösungsansätze mit hierarchischen Modellen • Lösungsansätze in XML und SGML • Konzept CONCUR (vom engl. concurrent – gleichzeitig): -> Ein Text wird nach zwei oder mehreren DTDs strukturiert (z.B. eine für Inhalt, eine für Syntax) Problem: Schnell komplexe Strukturen, schwierige Implementierung

14. Lösungsansätze mit hierarchischen Modellen - Leere Elemente: -> Ein Element wird in der DTD als EMPTY deklariert, somit kann es mit nur einem Tag (nicht als Tag-Paar) verwendet werden, die Zusammengehörigkeit wird durch Attribute wiederhergestellt (z.B. mit milestone-Elementen, alle Attribute zwischen milestones gelten als eine Einheit, z.B. <milestone unit=“page“/>). Problem: Ausgezeichnete Elemente lassen sich nicht in Baumstruktur wiedergeben und können nicht in Bezug auf andere Elemente gesetzt werden.

15. Lösungsansätze mit hierarchischen Modellen • Fragmentierung und Referenzen: -> Unterteilung sich überschneidender Passagen in kleinere Elemente (mit dem Attributswert „partial“ und Referenzen auf vorherige bzw. nachfolgende Sequenzen) Problem: Unterteilung des Haupttextes muss gut durchdacht sein, die Dokumentstruktur des Originals wird verfälscht und verliert an Klarheit.

16. Lösungsansätze mit alternativer Syntax • 1980er Jahre: „Norwegian Wittgenstein Project“, nicht-hierarchiche Kodierung in MECS (Multi Element Code System):

17. Lösungsansätze mit alternativer Syntax • Multi-Element-Code: Polyelement-Code und N-Element-Code: Zwischen Start- und Endtag kommt ein Separator-Tag, z.B.: [elname/3|…/elname|…/elname|…/elname] (N-Element elname hat 3 Unterelemente, die auch bei jedem Auftreten verwendet werden müssen) Vorteil: unkomplizierter Umgang mit Überlappungen Nachteil: Verarbeitung und Validierung der Programme wird schwieriger, es muss immer erst das gesamte Programm eingelesen werden, bevor Operationen ausgeführt werden können.

18. Lösungsansätze mit alternativer Syntax • 2002: Tennison, Piez und Nicol: Die „Layered Markup Annotation Language“ (LMNL). Dokument wird als Sequenz von Zeichen gesehen, über die sich benannte „Ranges“ spannen, die wiederum auf Layern (=Schichten) angeordnet sind. Ranges sind gekennzeichnet durch einen Namen, einen Startpunkt und die Länge und können durch Annotiation ähnlich wie XML-Attribute Metainformtionen speichern.

19. Lösungsansätze mit alternativer Syntax Ein Beispiel mit LMNL: Die dazugehörige LMNL-Notation: [name [occupation} student { ]} [id} [vn} Johanna {vn] [nn [bn}Neumann{]} N{id]eumann {nn] {name]

20. Lösungsansätze mit alternativer Syntax • Nachteil: komplizierte Programmierung, (noch?) keine Tools vorhanden. • Vorteil: Trennung von Datenmodell und physikalischer Repräsentation lässt prinzipiell auch XML-Syntax zu. • Somit wäre auch XML-Software nutzbar.

21. Zusammenfassende Betrachtung • Lösung des Überlappungsproblems spielt Schlüsselrolle • Bisher keine vollständig zufrieden stellende Lösung gefunden. • In allen Lösungsansätzen wird Nähe zur XML-Syntax gesucht.

22. Implizite Bereitstellung von Texteigenschaften • Neumann greift eine völlig neuen Ansatz auf. • Die Texteigenschaften werden implizit auf Programmierebene in Textzeichen-Objekten bzw. in Zeichensequenzen-Objekten gespeichert. • Es lassen sich mehrere Eigenschaften zu den Objekten speichern, Methoden ermöglichen eine leichte Weiterverarbeitung.

23. Zeichenketten in der Programmierung • Moderne Programmiersprachen benutzen vordefinierte String-Klassen (die Unicode benutzen). • Java: String (statisch) und StringBuffer (variable Zeichenketten) • C: nur statische String-Objekte • C++: auch dynamische String-Objekte (z.B. Klasse QString aus Entw.-Umgebung Qt)

24. Zeichenketten in Qt • Qt: „Open Source“ C++ -Bibliothek • Klasse QStrings: Bearbeitung von Zeichenketten • Verschiedene Konstruktoren zur Initialisierung durch Strings in doppelten Anführungsstrichen, durch ein Array aus QChar-Objekten oder durch Übergabe eines QString-Objekts • Durch Zugriff auf QChar-Array können einzelne Zeichen des Strings manipuliert werden.

25. Funktionen in Qt • Durch die Funktionen left(), middle() und right() können Teilstrings als neues Objekt zurückgegeben werden. • lower() bzw. upper() für Klein- bzw. Großschreibung. • toInt(), toDouble() für Konvertierung in andere Typen. • setNum() für Konvertierung von Zahlen in Zeichenkette.

26. Implementierung von Zeichenketten mit komplexen Texteigenschaften • Formatierungsanweisungen wie Schriftarten und Farben können im Unicode nicht mitgespeichert werden. • Die Lösung: Datentypen XChar und XText (X steht für extended)

27. Die Klassen QChar, QStringData und QString für „einfache Zeichen“ • Einzelnes Unicode-Zeichen wird von Objekt QChar repräsentiert. • Eine Unicode-Zeichenkette wird in einem QChar-Array (QChar* unicode;) gespeichert. • Diese Variable wird in Objekten QStringData (Klasse für Kopien und Speicherreservierung)gespeichert. • Klasse QString (Klasse enthält Klassenvariablen vom Typ QStringData QStringData* d;)

28. Die Klassen XChar, XTextData und XText für „erweiterte Zeichen“ • Einzelnes erweitertes Zeichen: XChar-Objekt (neben Unicode werden auch Texteigenschaften abgespeichert) • Klasse XTextdata-Objekt verwaltet analog zur vorherigen Folie XChar-Objekte. • Die Klasse XText stellt Funktionen zur Verarbeitung der Variable XTextData* d; bereit. • In einer Umgebungsvariable der Klasse XTextEnv werden Manipulationsmöglichkeiten festgehalten.

29. 4 Variablen für Texteigenschaften • Zustandsvariablen: Eigenschaften wie „fettgedruckt“, „kursiv“, „durchgestrichen“, aber auch „nachträglich eingefügt“ oder „verbessert“. • Ausprägungsvariablen: Schriftart (Arial, Courier, …) und Sprache (deutsch, englisch, …)

30. 4 Variablen für Texteigenschaften • Ähnlichkeitsvariablen: Farbtyp, gespeichert in 4 Werten rot, grün, blau (RGB) und transparent für bessere Vergleichoptionen. • Relationsvariablen: Schriftgröße und Relationen zwischen den Schriftgrößen. •  Zuweisung durch set()-Funktionen

31. Funktionen für XChar-Objekte • XChar-Objekte lassen sich hinsichtlich ihrer Texteigenschaften vergleichen. • Tendenzielle Abweichungen können mit colorCompare() und sizeCompare() gerechnet werden. • Ausgabe: Text und Texteigenschaften können getrennt voneinander am Bildschirm ausgegeben werden. • XChar-Objekte können in Textdatei geschrieben werden.

32. Fazit • Datentypen XChar und XText sind eine interessante Alternative zu Markup-Sprachen • Überlappungsproblem gelöscht. • Durch Speicherung der zusätzlichen Texteigenschaften ist eine einfachere Weiterverarbeitung möglich. Literatur: • http://www.hki.uni-koeln.de/studium/MA/neumann/Magisterarbeit.pdf