planung.md

@@ -818,3 +818,162 @@ Inhalt:
 
 - Vorstellung der Struktur-Ground-Truth und der Dokumentationsrichtlinien
 
+### 7. - 8. August 2018 (am CIS in München mit Florian und Tobias)
+
+
+
+#### Multi-OCR-Alignierung
+
+Vor der Alignierung wird die Interpunktion entfernt.
+Alle OCRs werden paarweise mit der Master-OCR aligniert, dann zu einer einzelnen
+Eingabe für den Profiler kombiniert.
+Tokenisierung findet auf Basis der Master-OCR statt.
+Diese einzelnen Tokens bilden die Grundlage für die Nachkorrektur.
+
+Ursprünglich wurde erst auf Zeilenebene und dann auf Zeichenebene alignieren,
+aber auf Zeilenebene ist nun nicht mehr notwendig, da wir das als gegeben
+voraussetzen dürfen (Zeilen-ID im PageXML).
+
+Uwe Springmann hat Tests zu Multi-OCR-Nachkorrektur mit einfachen
+Voting-Verfahren gemacht, was relativ gut funktioniert hat. So entstand die
+Idee, auch bei OCR-D Multi-OCR einzusetzen.
+
+Wenn ein Wort über eine Wortgrenze der Master-OCR hinweggeht, wird es
+ignoriert/weggeworfen. (Merge)
+
+Wenn die Master-OCR ein Wort an einer Stelle vorgibt, wo eine Hilfs-OCR
+zwei Wörter erkennt, wird auch getestet, ob es zwei Wörter sein können.
+(Split)
+
+
+#### METS/PageXML-Adapter
+
+Die Alignierung wurde im PageXML so dargestellt, dass es für jedes Wört
+mehrere Alternativen in TextEquivs gibt.
+
+Im Fall von Splits in der Hilfs-OCR enthält der Eintrag Whitespaces.
+
+Im Fall von Merges steht momentan das lange (gemergte) Wort zweimal im
+PageXML, nämlich für jeder der Einzelwörter der Master-OCR.
+Das wird auf unseren Wunsch hin noch so geändert, dass das eine Wort dann
+stattdessen leer ist.
+Ansonsten lässt sich die Eingabe nicht daraus rekonstruieren.
+
+Auf Zeilenebene wurde die Alignierung so dargestellt, dass Epsilons durch
+Unterstriche dargestellt sind.
+Das kann problematisch sein, da im Eingabestring theoretisch jedes Sonderzeichen
+vorkommen kann.
+
+
+#### RNN-Sprachmodelle
+
+Mögliche Ausgaben unseres Sprachmodells
+1. Reranking vom Suchraum
+2. Ausgabe 1-bester Pfad
+
+Wir würden das Sprachmodell auf die Ausgabe des Profilers anwenden.
+
+Wir haben verschiedene Verfahren, um das Sprachmodell auf Graphen
+anzuwenden, diskutiert (z.B. History Clustering).
+
+Unser Sprachmodell verlangt Kontextvariablen als Input.
+Da diese im PageXML stehen, können sie dadurch einfach ans Sprachmodell
+gegeben werden.
+
+Es ist unklar, ob es überhaupt sinnvoll ist, dem Entscheider die Ausgabe
+des Sprachmodells als zusätzlich Eingabe zu geben.
+Vielleicht ist es am besten, dem Sprachmodell die letztendliche
+Entscheidung zu überlassen, dann würde aber der Entscheider nicht mehr
+benötigt werden bzw. wird durch das Sprachmodell ersetzt.
+
+Die Ausgabe des Sprachmodells passt nicht ins PageXML.
+Hier könnte man ein eigenes Format oder ein übliches FST-Format
+zum METS hinzufügen.
+
+Eine sinnvolle Anwendung für ein zeichenbasiertes Sprachmodell ist bei der
+Entscheidung, ob potentielle neue Wörter zum dynamischen Lexikon
+hinzugefügt werden sollen.
+
+
+#### Ansatz des CIS
+
+Zeichensetzung wird nicht mitkorrigiert, sondern so belassen, wie sie in
+der Eingabe ist.
+Der Profiler ignoriert auch Zahlen und lässt sie, wie sie sind.
+Buchstaben mit 3 oder weniger Zeichen werden auch nicht korrigiert.
+
+Die Korrektur findet auf Basis der einzelnen Tokens der Master-OCR in
+3 Schritten statt:
+
+1. Lexikonerweiterung finden
+2. Korrekturkandidaten des Profilers reranken
+3. Entscheider: wird korrigiert oder nicht?
+
+Der Profiler braucht ca. 15 Minuten für ein Dokument (ca. 100 Seiten im
+Durchschnitt).
+
+Da Verschlimmbesserungen im Impact-Projekt (mit Abbyy ohne Frakturmodell)
+ein riesiges Problem waren, will man möglichst vorsichtig korrigieren.
+Mit den aktuelleneren OCR-Modellen ist das vermutlich kein so großes
+Problem mehr.
+
+Die Entscheidung, ob ein Wort ins Lexikon aufgenommen werden soll, ist zu
+etwa 95% korrekt.
+
+Features des Entscheiders:
+- OCR-Fehler, historische Pattern (Ausgabe des Profilers)
+- Multi-OCR (Ausgabe des Aligners)
+- Konfidenz der OCR
+
+Der Profiler korrigiert auch über Zeilengrenzen hinweg (fügt halbe Wörter
+zu einem zusammen).
+
+Das Lexikon ist komplett kleingeschrieben.
+Der Profiler merkt sich für jedes Wort, ob das erste Zeichen der OCR großgeschrieben
+war.
+
+
+####  Wörterbuch-Suche
+
+Lexika umfassen ca. 200k Wörter (Vollformen), werden mit Hilfe der DTA-Daten und weiterer
+Lexika noch erweitert. Es gibt verschiedene verschiedene Lexika (modern, historisch,
+Eigennamen, geografisch, ...), in denen nacheinader gesucht wird.
+Das größte Lexikon beinhaltet etwa 100k Zustände.
+
+Bei der Erstellung der Lexikon-Automaten werden die Wörter nacheinander
+hinzugefügt und (nicht vollständig) minimiert, sodass auch die Suffixe
+unifiziert werden.
+Der Minimierungsalgorithmus arbeitet auf Basis der spärlichen
+Übergangtabelle und schiebt übereinstimmende Zeilen ineinander (siehe S. 18 des
+Skripts zum Kurs Finite-State Technologien beim Indizieren und Suchen der LMU).
+
+Als Fehlerautomat wird ein spezieller Levenshtein-Automat verwendet,
+der exponentiell mit Anzahl der Abstände/Fehler wächst.
+Das Verfahren ist beschrieben in Mihov und Schulz (2004): Fast Approximate Search in Large Dictionaries.
+Eine Implementierung findet sich zusammen mit der des Profilers auf Github.
+
+Es wird eine  vollständige Komposition von Eingabe, Levenshtein-Automat und
+Lexikon durchgeführt. Alle Dabei gefundenen Wörter werden ausgegeben.
+Es werden auch Edits der Form 1 zu 2 Zeichen und 2 zu 1 Zeichen
+zugelassen.
+
+Die Suche findet stufenweise statt: Erst ohne Fehler, dann nach und nach
+mit mehr Fehlern (bis zu 3).
+Auch in den Lexika wird nacheinander gesucht (erst in modernem Lexikon, dann in historischem, dann in
+Spezial-Lexika).
+Bei Erfolg wird nicht weitergesucht.
+
+
+#### OCR-Daten-Erzeugung
+
+Wir haben die Daten dta-19-reduced übergeben und eine
+Anleitung zur Erzeugung der OCR-Daten mit Tesseract gegeben.
+
+
+#### Organisatorisches
+
+Das CIS hat beim Bibliotheca Baltica Symposium nichts eingereicht und wird
+vielleicht nicht dort sein.
+
+
+