...alles geklärt bis auf Normierung – einarbeiten, neue Seite zu Architektur anfangen!
1. Entwicklung Architektur:
1. Entwicklung Architektur:
1. Kombination von FST mit RNN (Alternativengraph vs Merkmalvektor, DP-Suche),
1. Kombination von FST mit RNN (Alternativengraph vs Merkmalvektor, DP-Suche),
1. wortbasierte Sprachmodelle (Merkmalextraktion/numerische Repräsentation bei RNN, Wortklassen oder direkt, Konvention der Tokenisierung/Textnormalisierung)
1. wortbasierte Sprachmodelle (Merkmalextraktion/numerische Repräsentation bei RNN, Wortklassen oder direkt, Konvention der Tokenisierung/Textnormalisierung)
...
@@ -20,59 +22,44 @@ u.g. priorisieren...
...
@@ -20,59 +22,44 @@ u.g. priorisieren...
### Organisatorische Fragen
### Organisatorische Fragen
1. unreine/Fehler-Daten (aus OCR-Workflow) vom DTA anfordern – Antwort steht noch aus
| überwacht | mit FST | (Adaption: vorerst nicht) |
| | 2) mit RNN | |
| | mit RNN | (Adaption: vorerst nicht) |
| unüberwacht | 3) Denoising mit RNN | 4) Fehlermodell mittels EM |
| unüberwacht | Denoising mit RNN | (adaptiv mittels EM: schon bei CIS-Gruppe) |
Für jedes der Experimente Tests auf
1. erste Fehlermodelle (auf Asse-Daten und auf GT sobald verfügbar) gemäß Tabelle;
1. den Asse-Daten
RNN hierbei per Encoder-Decoder-Modell auf Zeichenebene, d.h. zugleich zeichenbasiertes Sprachmodell; später auch mit Wortebene, d.h. Ausgabe von Alternativen (Baumausgabe) und Eingabe (per Aggregation oder Pruning von Pfaden) in Wortmodell und wortbasiertes Sprachmodell
1. den DTA-Daten
1. Code-Gerüst (Python) für gesamtes Modul (Kombinationsmöglichkeit für FST und RNN)
1. historische Lexika und Morphologie selber extrahieren (feste Wortformen vs Wortbildung/Morphologie, Häufigkeit und Smoothing/OOV) mit Morle (Wortform + Lemma oder Wortform + Wortvektor) und/oder mit Soricut&Och
durchführen und auch auf den jeweils anderen Daten testen.
1. wortbasierte Sprachmodelle trainieren mit Polygrammen (klassenbasiert und cache-basiert?) und LSTM-RNN: OOV, Klassen und/oder Lemmatisierung, Eigennamen, Morphologie, künstliche Daten
1. Rescoring und Graph-Eingabe
1. erste Tests auf Asse-Daten durchgeführt, Verbesserung der Performanz notwendig
1. OCR-Toolchain(s) auf GT-Daten, damit weitere Fehlermodelle erzeugen
1. überwachtes Training mit echten Fehlerdaten, Umfang der Asse-Daten vermutlich zu gering für sinnvolle Ergebnisse
1. Erzeugung von künstlichen Trainingsdaten durch absichtliches Verrauschen, siehe D'hondt et al. (2017)
1. Fehlermodell pro Dokument mittels Expectation Maximization (EM) anpassen
zu 2. + 3. Versuche zu
1. Grapheingabe (Aggregation von Pfaden, Pruning von Pfaden)
1. Baumausgabe (Sequence-to-Sequence mit Beam Search)
## Erledigt
## Erledigt
1. im Antrag referenzierte Arbeiten
1. Literatur: im Antrag referenzierte Arbeiten
1. keras-Tutorial
1. Werkzeuge: keras-Tutorial
1. Mächtigkeit und Trainierbarkeit von FNN/RNN
1. Literatur: Mächtigkeit und Trainierbarkeit von FNN/RNN
1. HFST installieren/benutzen
1. Werkzeuge: HFST und OpenFST installieren/benutzen
1. ddc-concordance installieren
1. Werkzeuge: Gensim, Tesseract etc installieren
1. DTA-Daten und GT-Daten ansehen
1. Recherche: Asse-Daten, DTA-Daten und GT-Daten ansehen
1. Ressourcen: im DTA gibt es definitiv keine unreinen/Fehler-Daten (aus OCR-Workflow) mehr
1. Literatur: RNN mit Folgen verschiedener Länge, mit Graphen als Eingabe und Ausgabe
1. Literatur...
1. Werkzeuge: weitere Ressourcen und Daten, etwa vorberechnete Wort-Vektorraumrepräsentationen; als Korpuswerkzeug (Textnormalisierung) nehmen wir die ASV-Toolbox
1. Experimente: (mit Asse-Fehlerdaten und Asse-Lexikon) erste Fehlermodelle erzeugen und ausprobieren, Einflüsse verschiedener Parameter auf Qualität und Rechenaufwand (1/2/3-Gramm-Kontext, Anzahl erlaubter Fehler pro Wort, mit/ohne Morle-Morphologie, volle vs Lazy-Komposition): Fehlerdaten zu klein, Performanz mit OpenFST fragwürdig (Profiling notwendig)
1. Experimente: (mit [1](https://github.com/Rj7/Unsupervised-morphology-induction-word2vec) und [2](https://github.com/jodaiber/semantic_compound_splitting):) Soricut&Och-Modell auf vorberechneten Wortvektoren trainieren
1. Architektur: Kanonisierung wird nicht versucht, wir erzeugen kontextbasierte Modelle über historischen *und* modernen Sprachdaten
1. Architektur: wir benutzen keine externen Morphologie-Ressourcen (Morphix/Tagh/NetLex etc)
## Besprechungen
## Besprechungen
### 3. Mai 2018
### 3. Mai 2018 (mit Prof. Heyer)
* EM (Expectation Maximization) als unüberwachter transduktiver Ansatz für das Fehlermodell wird zunächst nicht verfolgt (an der LMU schon vertreten).
* EM (Expectation Maximization) als unüberwachter transduktiver Ansatz für das Fehlermodell wird zunächst nicht verfolgt (an der LMU schon vertreten).
* Der FST-Ansatz wird zurückgestellt, falls er nicht performant genug ist.
* Der FST-Ansatz wird zurückgestellt, falls er nicht performant genug ist.
- Das kann Morle mit `morle analyze`, falls die RNN-Option gesetzt wurde (in
- Das kann Morle mit `morle analyze`, falls die RNN-Option gesetzt wurde (in
ein paar Wochen verfügbar, funktioniert momentan nicht).
ein paar Wochen verfügbar, funktioniert momentan nicht).
### 29./30. Mai 2018 (BBAW)
### 29-30. Mai 2018 (am BBAW mit Kay-Michael Würzner, Matthias Boenig und Bryan Jurish)
#### 29. Mai 2018 (Kai-Michael Würzner, Matthias Boenig)
1
#### Konfidenzen und Abbruchkriterien, Integration der Ergebnisse nach hinten
Das Modul Qualitätssicherung überprüft die Ergebnisse jeder Modulkomponente
Das (vom entsprechenden Modulprojekt oder der Koordinierungsgruppe noch zu schaffende) **Modul Qualitätssicherung** überprüft die Ergebnisse jedes Moduls
nach dem jeweiligen Arbeitsschritt.
nach dem jeweiligen Arbeitsschritt.
Wenn dabei festgestellt wird, dass die Ausgabe eines Moduls nicht brauchbar
Wenn dabei festgestellt wird, dass die Ausgabe eines Moduls nicht brauchbar
ist, wird sie nicht an das nächste Modul weitergegeben.
ist, wird sie nicht an das nächste Modul weitergegeben, sondern der zuletzt ausgeführte Schritt wird neu ausgelöst oder anders realisiert (streng *lineare Prozeßkette*).
Wir müssen nicht die Integration mit den anderen Komponenten (also inkl.
Dafür werden auch die Konfidenzwerte der Module genutzt, aber nicht ausschließlich.
Anpassung/Normierung unserer Konfidenzwerte in Bezug auf die anderen
Wir brauchen OCR-Ergebnisse *nicht* selber zu integrieren (also als Rückfallstufe inkl.
Konfidenzwerte) übernehmen, da das durch das Modul Qualitätssicherung
Anpassung/Normierung der Konfidenzwerte): dafür ist ebenfalls das QS-Modul zuständig.
übernommen wird.
Dabei wird von einer klar linearen Prozesskette ausgegangen, in der die
Wir können also unsere Ergebnisse mit unseren *Konfidenzen* ausgeben, ohne
Qualitätssicherung einen Schritt (den zuletzt ausgeführten) neu auslösen
kann.
Wir können also unsere Ergebnisse mit unseren Konfidenzen ausgeben, ohne
vom Rest abhängig zu sein.
vom Rest abhängig zu sein.
Für das Logging zusätzlicher Informationen/Metadaten, die während unserer
Bearbeitung anfallen (z.B. Domäne, Sprache) gibt es eine vorgegebene
Logging-Schnittstelle.
Die Minimalanforderungen an uns sind: Wir bekommen einen String oder eine
Falls wir die Konfidenzen der OCR-Ausgabe benutzen wollen, sollten wir vorsichtig sein: sie direkt als Wahrscheinlichkeit zu interpretieren (etwa im FST) dürfte zu sehr schlechten Resultaten führen. Entweder lernt man eine nichtlinear-weiche Abbildung (etwa im RNN) oder man diskretisiert und verwendet sie als *Symbole* (im FST; wobei natürlich sichergestellt sein muß, daß etwa `a[0.9]/e` auch unter `a[0.7]/e` mitgezählt wird).
Konfusionsmatrix (das wird beim nächsten Entwicklertreffen genau geklärt)
und geben unseren korrigierten Text raus.
#### enge vs lose Kopplung nach vorne
Die Minimalanforderungen an uns sind: Wir bekommen einen String **oder** eine
*Konfusionsmatrix* und geben unseren korrigierten Text aus. (Inwieweit letzteres mit Tesseract überhaupt vollumfänglich möglich ist, wird bis zum nächsten Entwicklertreffen genau geklärt – die Mannheimer haben das letzte Wort.)
Es ist keine Schnittstelle für Offline-User-Interaktion vorgesehen.
#### Protokollierung und anfallende Zwischenergebnisse
Für das Logging wird es Vorgaben und eine Schnittstelle/Implementierung geben. Zusätzliche Informationen/Metadaten, die während unserer Bearbeitung anfallen (z.B. Domäne, Sprache, Neuwörter) können abgelegt werden, aber diese Daten können nicht weiterverarbeitet oder wieder gelesen werden – alle Module müssen **zustandslos** (innerhalb des Dokuments oder sogar innerhalb der Seite/Zeile??) und reproduzierbar arbeiten.
#### Adaption und Interaktion
Es ist keine (Schnittstelle für) Nutzer-Interaktion vorgesehen.
Daher würde eine Lösung für Adaption von Fehlermodellen mittels eines
Daher würde eine Lösung für Adaption von Fehlermodellen mittels eines
kleines GT-Datensatzes nicht im Rahmen von OCR-D genutzt werden.
kleines GT-Datensatzes nicht im Rahmen von OCR-D genutzt und evaluiert werden (dürfen).
Themen wie manuelle Änderungen an den verarbeiteten Daten und
Themen wie manuelle Änderungen an den verarbeiteten Daten und
Neuprozessierung sind komplexe Fragestellungen an die Langzeitarchivierung.
Neuprozessierung sind komplexe Fragestellungen an die *Langzeitarchivierung*. Das Umfeld ist in den Bibliotheken dafür noch nicht weit genug entwickelt.
Der Fokus bei uns sollte auf dem Mitliefern funktionierender Fehlermodelle
Der Fokus bei uns sollte in diesem Projekt auf den **bestmöglichen Standardmodellen** liegen.
liegen.
2
#### Treffen im Juni, Entwicklungsmodell und Evaluierung
Wir werden vermutlich Informationen zur verwendeten Schriftart bekommen, da
Wir haben gemessen an unserer Aufgabe sehr wenig Zeit. Wir sollten Programm und Modelle **iterativ** entwickeln, damit es möglichst früh ein funktionierendes Produkt gibt und am Schluß bei Zeitnot höchstens eine Iteration verloren geht.
es dafür ein Modulprojekt gibt.
Wir sollten unser Programm iterativ entwickeln, damit es immer ein
Dabei sollten wir immer nur versuchen *relative Fortschritte* zu erzielen und wenig Zeit auf die *absolute Evaluierung* der jeweiligen Teilprobleme (gemessen am Stand der Kunst) verwenden. Diese Evaluierung kann uns die Koordinierungsgruppe **abnehmen**.
funktionierendes Produkt gibt.
Den Test und die Evaluation unseres Programms kann auch das
Koordinationsteam übernehmen.
Beim Entwicklertreffen im Juni (26./27.) werden wir für existierende Tools
Bis zum ersten Entwicklertreffen im Juni (26.-27.6.) brauchen wir noch keinen eigenen Durchlauf-Prototypen haben, sondern es werden für existierende Tools (nicht unsere eigenen) *Wrapper* gebaut, wie es von der OCR-D-Spezifikation vorgesehen ist, um diesen Schritt einzuüben.
(nicht unsere eigenen) Wrapper bauen, wie es von der OCR-D-Spezifikation
vorgesehen ist, um das zu üben.
Kai-Michael Würzner ist skeptisch bezüglich Morphologie und Kanonisierung,
#### dynamische Kanonisierung vs historische Modelle
Kay ist sehr skeptisch bezüglich Morphologie und Kanonisierung,
da es aufgrund der hohen Sprachvarianz unmöglich sei, alle
da es aufgrund der hohen Sprachvarianz unmöglich sei, alle
Arten von Sprache mit einem allgemeinen Modell abzudecken.
Arten von Sprache mit einem einzigen allgemeinen Modell abzudecken.
Eine Möglichkeit wäre eventuell ein Verfahren für Morphologieinduktion,
mit dem wir Modelle für verschiedene Zeitintervalle erstellen.
3
Was *Kanonisierung* betrifft, selbst CAB bestünde eher aus einer großen, manuell gewachsenen Ausnahmeliste. Es wäre besser, direkt historische Modelle zu trainieren und **gar nicht** zu kanonisieren.
Laut ihm soll Nutzung der Genre-Information soll wohl keine Vorteile
Was *Morphologie* betrifft, eine Möglichkeit wäre eventuell ein Verfahren für Morphologieinduktion, mit dem wir Modelle für verschiedene Zeitintervalle erstellen. Anstelle von Wortebene nur auf Allomorph-Ebene zu gehen hält Kay für noch problematischer, da wir keine gute Segmentierung hinbekommen werden.
bringen. Es ist unklar, ob wir dazu Metadaten bekommen, da die Zuordnung zu
Genres nicht eindeutig ist. Innerhalb eines Buches können auch viele
verschiedene Arten von Text gesammelt sein.
Die jetzigen GT-Daten enthalten noch keine Metadaten. Die METS-Daten mit
#### Metadaten und Textelement-Typen
Metadaten sind gerade in der Entstehung begriffen.
Die bisherigen GT-Daten dienen nur als Referenz, wie die späteren Daten
Die bisherigen GT-Daten dienen nur als erste *Referenz*, wie die späteren Daten
aussehen werden. Die späteren Trainings- und Testdaten werden jetzt gerade
aussehen werden. Die großen Trainings- und Testdaten werden aktuell gerade
erzeugt (etwa 30k Seiten).
erzeugt (etwa 30k Seiten).
PageXML hat nur einen minimalen Metadatenteil, der kein Genre vorsieht. Wir
Die jetzigen GT-Daten enthalten auch noch keine Metadaten. Die METS-Daten entstehen aber gerade und werden sich qualitativ an DTABf orientieren (aber ggf. erneuern).
können aber Custom-Attribute (in Absprache mit dem Koordinationsteam) für
derartiges verwenden und selbst befüllen, falls wir so etwas klassifizieren.
Wir werden vermutlich Informationen zur verwendeten **Schriftart** bekommen, da
es dafür ein Modulprojekt gibt.
Das Koordinationsteam wird nachfragen und herausfinden, inwieweit die VD- und die
PageXML selbst hat nur einen minimalen Metadaten-Teil (`Page:primaryLanguage`, `TextRegion:Type`), der kein **Genre** vorsieht. Wir dürfen aber das [`Custom`-Attribut von `TextRegion`](http://www.ocr-d.de/sites/all/gt_guidelines/structur_gtpageformat.html) für feinere Differenzierung (also `stage` / `speaker` / `poem` / `poem_lg` etc.) von `Paragraph` verwenden (ähnlich DTABf, in Absprache mit dem Koordinationsteam) und selbst befüllen, falls wir so etwas klassifizieren können. Von der Vorverarbeitung in OCR-D ist es eher unwahrscheinlich (da Layout und sprachliche Besonderheiten zusammenkommen müssen).
DTA-Klassifikation für Genres in Verbindung gebracht und vereinheitlicht
werden können.
4
Kay schätzt, daß die Genre-Informationen wohl keine Vorteile bringen. Es ist noch unklar, ob wir dazu Metadaten bekommen, da die Definition und Zuordnung oft nicht eindeutig ist oder unsauber gehandhabt wird. Für vielen Texte ist einfach kein Genre angegeben. Die Einordnung benötigt meist Fachwissen oder inhaltliche Erschließung durch den Bearbeiter, was in den Bibliotheken teuer ist. Zudem ist Konsistenz oft schwer herzustellen. Innerhalb eines Buches können außerdem viele verschiedene Arten von Text vereinigt sein.
Für vielen Texte ist auch einfach kein Genre angegeben. Die Einschätzung
Das Koordinationsteam wird trotzdem nachfragen und herausfinden, inwieweit die VD- und die
ist auch sehr unklar, da es viele verschiedene Meinungen gibt. Die
DTA/DWDS-Klassifikation für Genres in Verbindung gebracht und vereinheitlicht
inhaltliche Erschließung in den Bibliotheken ist zudem teuer.
werden können. (Wenige sehr allgemeine Kategorien wären vermutlich robust genug, sofern sie nicht direkt als Domäne benutzt werden.)
Wenn wir Genre überhaupt nutzen, dann lieber eine grobe Unterteilung.
Eventuell bekommen wir das Erscheinungsdatum der Erstauflage bzw. des
Eventuell bekommen wir sogar das **Erscheinungsdatum** der *Erstauflage* bzw. des
ersten verzeichneten Drucks.
ersten verzeichneten Drucks. In jedem Falle gibt es aber eine Zeitangabe der Aktualauflage und des **Autors**. Letzterer könnte mittelbare Hinweise auf die regionale Zuordnung geben.
#### Performanz
In der Produktivphase soll die Prozesskette auf einigen Millionen Seiten
In der Produktivphase soll die Prozesskette auf einigen Millionen Seiten
ausgeführt werden. Als grobe erste Abschätzung für die Laufzeit sollte die
ausgeführt werden. Als grobe erste Abschätzung für die *Laufzeit* sollte die
Verarbeitung einer einzelnen Seite (pro Modul) nicht länger als 1 Minute
Verarbeitung einer einzelnen Seite (pro Modul) nicht länger als 1 Minute
dauern.
dauern (Durchsatz, nicht Latenz).
Eine Kommunikation des Programms mit externen Servern darf keine Pflicht
Eine Kommunikation des Programms mit externen Servern darf keine Pflicht
sein. Das Programm sollte in Form eines Docker-Images auf einem einzelnen
sein. Das Programm sollte in Form eines Docker-Images auf einem einzelnen
Rechner laufen können.
Rechner laufen können.
Für eine effizientere Lazy Composition von FSTs muss eine Tiefensuche
Für eine effizientere *Lazy Composition* von FSTs muss eine Tiefensuche
durchgeführt werden. Von Kai gibt es eine Veröffentlichung (2009) über eine
(statt Breitensuche) durchgeführt werden. Von Kay gibt es eine Veröffentlichung (2009) über eine effiziente Implementierung.
effiziente Implementierung.
#### Abstimmung mit CIS-Gruppe
Für eine Abstimmung mit den Münchnern sollten wir uns mit diesen direkt
Für eine Abstimmung mit den Münchnern sollten wir uns mit diesen direkt
besprechen, z.B. beim Entwicklertreffen.
besprechen, z.B. beim Entwicklertreffen.
Es ist nicht zwingend notwendig, da beide Projekte bewilligt wurden und wir
Es ist zwar nicht zwingend notwendig, da beide Projekte bewilligt wurden und wir
daher auch unabhängig von einander "unser Ding" machen dürfen.
daher auch unabhängig von einander "unser Ding" machen dürfen.
Eine Organisierung kann aber sehr sinnvoll sein, wenn es Komponenten gibt,
Eine Organisierung kann aber nicht nur sinnvoll sein, um Diversifikation zu erreichen (also nicht nachzuimplementieren), sondern umgekehrt auch um aufwendige Komponenten, die von beiden Teams benötigt werden (z.B. Sprachmodell oder dynamische Lexikonerweiterung), gemeinsam zu realisieren.
die von beiden Teams benötigt werden (z.B. Sprachmodell). Diese könnte man
dann gemeinsam erarbeiten/implementieren.
5
Die Münchner verwenden bei ihrem Ansatz (Fehlermodell / Kanonisierung?) Ausnahme-Regel-Listen, die man von Hand bearbeiten kann. Diese manuelle Modellierung findet Kay nicht so
sinnvoll, da man das lieber aus Fehlerdaten lernen sollte.
Die Münchner verwenden bei ihrem Ansatz Ausnahme-Regel-Listen, die man von
Die Entwickler des Profilers (Reffle und Ringlstetter) sind auch nicht mehr am
Hand bearbeiten kann. Diese manuelle Modellierung findet Kai nicht so
CIS. Ein weiteres Problem des CIS-Ansatzes ist, dass der Regelsatz nicht
sinnvoll, da man das lieber aus Fehlerdaten generieren sollte.
Der Entwickler des Profilers (Herr Ringelstädter) ist auch nicht mehr am
CIS. Ein weiteres Problem des CIS-ANsatzes ist, dass der Regelsatz nicht
zeitspezifisch ist.
zeitspezifisch ist.
#### Zeichensatz bei Ein- und Ausgabe
Wir sollen auf keinen Fall eine Kanonisierung oder Normalisierung des Textes
Wir sollen auf keinen Fall eine Kanonisierung oder Normalisierung des Textes
ausgeben, sondern er soll genau wie der Originaltext aussehen.
ausgeben, sondern er soll genau wie der Originaltext aussehen.
Das beinhaltet dann z.B. auch Trennstriche am Zeilenende.
Das beinhaltet sogar *Trennstriche* am Zeilenende.
Es gibt ein festes Inventar von Zeichen, mit denen wir rechnen können.
Dabei sind keine konsonantischen Ligaturen vorgesehen, sondern nur
vokalische. Die Zeichenkombinationen sind also zum Teil aufgelöst (GT-Level
2).
6
Gemäß [GT-Transkriptionsrichtlinien](http://www.ocr-d.de/sites/all/gt_guidelines/transkription.html) gibt ein festes Inventar von Zeichen, mit denen wir rechnen können.
Dabei gibt es dreierlei Arten Trennstriche (U+002D, U+2E17, U+003D). Es sind keine konsonantischen Ligaturzeichen vorgesehen, sondern nur die rein vokalischen (`æ` und `œ`) sowie natürlich `ß`. Auch hochgestellte Umlaute sollen als solche erhalten bleiben (2 Codepoints 1 Graphem). Andere Diakritika werden nur dann als Kombination dargestellt, wenn sie nicht als Einzelzeichen standardisiert sind. Kürzungsstriche bleiben ebenfalls als Zeichenkombination (mit U+0303) erhalten. Die Zeichenkombinationen sind also zum Großteil aufgelöst (GT-Level 2).
Auf Morphemebene zu gehen sieht Kai als unmöglich an, da wir keine gute
#### historische OCR-Fehlerdaten zum Mitnehmen
Segmentierung hinbekommen werden.
An sich ist eine enge Kopplung von OCR mit Nachkorrektur besser als eine
Der [Archiscribe-Korpus](https://github.com/jbaiter/archiscribe-corpus) enthält Bild + Text für Zeilen aus verschiedenen Jahrhunderten in Fraktur, ist für unsere Bedürfnisse aber nicht umfangreich genug (4k Zeilen).
lose Kopplung. Es ist unklar, ob wir die gesamte Konfusionsmatrix bekommen
können. Das erfahren wir beim nächsten Entwicklertreffen von den
Mannheimern.
Der Archiscribe-Korpus enthält Bild + Text für Zeilen aus verschiedenen
Stattdessen haben wir 61k Zeilen (`dta19-reduced`) bekommen mit Fraktur aus dem 19.
Jahrhunderten, ist für unsere Tests aber nicht umfangreich genug (4k Zeilen).
Stattdessen habe wir 61k Zeilen (dta_19) bekommen mit Fraktur aus dem 19.
Jahrhundert.
Jahrhundert.
Nutzbare Modelle für unsere Erzeugung von fehlerhaftem OCR:
[Nutzbare](Entwicklungsumgebung#tesseract) Modelle zur Erzeugung von fehlerbehafteter OCR:
- tessdata_best -> scripts/Fraktur
-[tessdata_best](https://github.com/tesseract-ocr/tessdata_best) für Tesseract 4 → `scripts/Fraktur`
- von Kai trainiertes Modell für Tesseract (mit 9k Zeilen trainiert, jede
-[von Kay trainiertes Modell](http://odo.dwds.de/~kmw/foo.traineddata) für Tesseract 4 (mit 9k Zeilen trainiert, jede etwa einmal gesehen)
etwa einmal gesehen)
-`tesseract-ocr-deu-frak` aus den Ubuntu-Repos für Tesseract 3
- ocropus (auch hierfür haben wir ein Modell von Kai bekommen)
omnifont-Modell und deu-frak schreiben kein langes ſ, daher vielleicht eher problematisch (oder zumindest zu beachten)
- omnifont-Modell und deu-frak (aus tesseract3) schreibt kein langes s, daher
-[von Kay trainiertes Modell](http://odo.dwds.de/~kmw/fraktur19-00050000.pyrnn.gz) für ocropus
vielleicht eher problematisch
Mit den zusätzlichen Daten wird das Koordinationsteam bessere Modelle
Mit den zusätzlichen Daten wird das Koordinationsteam dann auch sukzessive bessere Modelle
trainieren.
trainieren.
OCR-D/core verwendet für XML-Parsing in Python lxml.
#### Schnittstellen für ersten Prototypen
Page ist dort in Python gewrappt.
[OCR-D/core](https://github.com/OCR-D/core) verwendet für XML-Parsing/Serialisierung in Python `lxml`. PAGE ist dort in Python gewrappt.
Mit einer Einarbeitung in diesen Code sollten wir allerdings bis zum
Mit einer Einarbeitung in diesen Code sollten wir allerdings bis zum
Entwicklertreffen abwarten, da sich bis dahin noch viel daran ändern kann.
Entwicklertreffen abwarten, da sich bis dahin noch viel daran ändern kann.
Für technische Fragen ist Konstantin Baierer zuständig.
Für technische Fragen dazu ist Konstantin Baierer zuständig.
#### Bryan Jurish
#### Kanonisierung
CAB und sein Quellcode darf nicht weitergegeben werden. Es nutzt viele
CAB und sein Quellcode darf leider nicht weitergegeben werden. Es nutzt viele
Modelle, die auch nicht weitergegeben werden dürfen. Daher ist die Nutzung
Modelle (wie TAGH), die auch nicht weitergegeben werden dürfen. Allein schon deshalb ist CAB für uns **ungeeignet**.
von CAB für uns ungeeignet.
Zudem stellt die Kanonisierung eine zusäzliche Fehlerquelle dar, sodass
Zudem stellt die Kanonisierung immer eine nicht unerhebliche zusätzliche *Fehlerquelle* dar. Bei dieser Komplexität ließe sich ohnehin schwer sagen, woher ein Fehler jeweils stammt.
sich schwer sagen lässt, woher ein Fehler stammt.
Bei Texten aus dem 18. Jh. und später ist CAB recht verlässlich.
Bei Texten aus dem 18. Jh. und später ist CAB noch recht verlässlich, besteht aber tatsächlich aus vielen gewachsenen Ausnahmen (könnte also womöglich schlecht generalisieren).
Bei älteren Texten verschlechtert sich die Qualität.
Bei älteren Texten verschlechtert sich die Qualität erheblich. Man muß ohnehin immer einen Kompromiß zwischen zuvielen Falschpositiven (v.a. bei veralteten Wortformen) und zuvielen Falschnegativen (v.a. bei Eigennamen) finden.
Bei Training von CAB mit Texten aus verschiedenen Zeiten (17. bis 19. Jh.)
und Evaluation gegeneinander konnte Bryan keine signifikaten Unterschiede
feststellen.
Bryan sieht eine mögliche Anwendung der Kanonisierung in der
Qualitätskontrolle nach der eigentlichen Korrektur:
Man könnte die Ausgabe unserer Nachkorrektur
kanonisieren und dann mit einem modernen Wortmodell die Plausibilität
prüfen. Das wäre vielleicht eher Teil der Qualitätssicherung.
Bei CAB sind nur die Gewichte des FST-Modells datengetrieben, nicht die
Bei CAB sind nur die Gewichte des FST-Modells datengetrieben, nicht die
Topologie. Daher können durch mehr Daten nicht mehr oder neue Regeln
Topologie. Daher können durch mehr Daten nicht mehr oder neue Regeln
gelernt werden.
gelernt werden. Mit einem Training von Gewichten mit Texten aus verschiedenen Zeiten (17. bis 19. Jh.) und Evaluation gegeneinander konnte Bryan keine signifikaten Unterschiede
feststellen. (Diese bilden die beträchtlichen Unterschiede im Zeitverlauf also nicht ab.)
Erfolgreiche *neuronale* Kanonisierung läßt im Grunde noch immer auf sich warten. Die Arbeiten von al-Azawi hat er noch nicht rezipiert, aber die Kollegen Uwe Springmann und Marcel Bollmann haben seiner Kenntnis nach jeweils auch mit neuronalen Lernverfahren experimentiert – zu einem Abgleich der Ergebnisse mit CAB auf DTA ist es noch nicht gekommen.
Bryan sieht aber eine mögliche Anwendung der Kanonisierung in der
**Qualitätskontrolle** nach der eigentlichen Korrektur:
Man könnte die Ausgabe unserer Nachkorrektur
kanonisieren, um dann mit einem modernen Wortmodell die Plausibilität
zu prüfen. (Das wäre also ein möglicher Teil der Qualitätssicherung.)
GFSM ist der Name von Bryans FST-Implementierung (libgfsmxl).
#### effiziente Komposition
Hier ist eine Lazy Composition implementiert, die problematisch ist, wenn
auf der Eingabeseite des FST eine Epsilon-Schleife mit Gewicht 0 besteht.
Man kann bei dieser Komposition nur einen einzelnen String hineingeben
(keinen FST), für den dann die besten Pfade gesucht werden.
Bryan hat festgestellt, dass die Lazy Composition von OpenFST so lange
GFSM ist der Name von Bryans FST-Implementierung (`libgfsmxl`).
braucht, da vor der eingentlichen Suche von Pfaden Attribute des FSTs
Sie implementiert eine Lazy Composition mit Vorberechnung von Pfaden mit Dijkstra und A*-Beamsearch zur Laufzeit. Diese ist in den gutartigen Fällen sehr effizient und nur dann problematisch, wenn auf der Eingabeseite des FST eine Epsilon-Schleife mit Gewicht 0 besteht.
aufwendig getestet werden.
Die aktuelle Implementierung hat noch eine Einschränkung: Man kann nur einen einzelnen String hineingeben (keinen FST), für den dann die besten Pfade gesucht werden.
#### 30. Mai 2018 (Kai-Michael Würzner, Matthias Boenig)
Bryan hat festgestellt, dass die Lazy Composition von OpenFST deshalb so lange
braucht, weil vor der eingentlichen Suche von Pfaden bestimmte Attribute der FSTs
aufwendig abgeglichen werden.
10
#### Treffen und Konferenz im Oktober
Das übernächste Entwicklichertreffen wird am 4./5. Oktober in Rostock
Das übernächste Entwicklichertreffen wird am 4./5. Oktober in Rostock
stattfinden. Da es ursprünglich nicht im Projekt eingeplant wurde, wird es
stattfinden. Da es ursprünglich nicht im Projekt eingeplant wurde, wird es
auf einer Konferenz im Rahmen eines Workshops stattfinden. Die Idee ist,
auf einer Konferenz im Rahmen eines Workshops stattfinden. Die Idee ist,
dass jedes Modulprojekt eine Einreichung beim Call for Posters macht, und
dass jedes Modulprojekt eine Einreichung beim Call for Posters macht, und
wir so eine "OCR-D-Ecke" dort haben.
wir eine "OCR-D-Ecke" dort haben.
Auf diese Weise können wir auch etwas Öffentlichkeitsarbeit für OCR-D
Auf diese Weise können wir auch etwas (dringend benötigte) Öffentlichkeitsarbeit für OCR-D
machen und erhalten wertvolle wissenschaftliche Rückmeldung.
machen und erhalten wertvolle wissenschaftliche Rückmeldung. Gastgeber ist das [CITLab](https://www.citlab.uni-rostock.de/), die Einreichungen dürfen also auch theoretisch ausgerichtet sein. Wir treten für unser Institut auf, dürfen uns aber gerne mit OCR-D schmücken/ausweisen.
Bei diesem 2. Entwicklertreffen wird die Integration der einzelnen Module
Bei diesem 2. Entwicklertreffen wird dann die Integration der einzelnen Module
zu einem Workflow durchgeführt/getestet.
zu einem Workflow durchgeführt/getestet.
#### Erzeugung von Modellen
Das Training unserer Modelle muss so gestaltet sein, dass andere Leute das
Das Training unserer Modelle muss so gestaltet sein, dass andere Leute das
auch durchführen können.
auch durchführen können. Die nötigen Daten müssen identifiziert und beschaffbar sein, am besten in öffentlichen Repos/Archiven. Ansonsten dürfen wir das so gestalten, wie wir es brauchen und für richtig halten. Insbesondere brauchen wir nicht zu garantieren, daß diese binär identisch erzeugt werden können. Unsere interne Renormierung der Konfidenzen kann ein Rezeptschritt wie andere auch sein, der für jede neue Modellkombination wiederholt werden muß.
ocrd-tool-json ist nur dafür gedacht, dass core unser Programm im Sinn
Das Modulprojekt zur Trainingsdateninfrastruktur wird voraussichtlich doch nicht zustandekommen.
einer automatisierten Verarbeitung laden kann und dann alle Schnittstellen
registriert sind.
[ocrd-tool.json](https://ocr-d.github.io/ocrd_tool) ist nur dafür gedacht, dass `core` unser Programm im Sinn einer automatisierten Verarbeitung laden kann und dann alle Schnittstellen
registriert sind. Es ersetzt nicht die Dokumentation der Modellerzeugung als Rezept. Letzteres wäre idealerweise eine ablauffähige Formalisierung (Makefile), muß es aber nicht.
Der Fragebogen zu den technsichen Details unseres Programm (verwendete
Der Fragebogen zu den technsichen Details unseres Programm (verwendete
Hardware, Bibliotheken etc.) betrifft auch die Training-Tools.
Hardware, Bibliotheken etc.) betrifft auch die Training-Tools, am besten für jedes Programm ein Exemplar. Wenn uns auffällt, daß sinnvolle Fragen oder Antworten fehlen, sollten wir sie bitte ergänzen. Zeitraum für Antworten ist möglichst bald.
#### nochmal Komposition
OpenFST gilt als die Standard-Bibliothek für FSTs.
OpenFST gilt als die Standard-Bibliothek für FSTs.
Wenn wir FSTs verwenden, dann sollten wir also möglichst OpenFST verwenden und
Wenn wir FSTs verwenden, dann sollten wir also möglichst OpenFST verwenden und
nicht etwas, das niemand benutzt. Der Maintainer/Entwickler Kyle Gorman ist
nicht etwas, das fast niemand benutzt und wartet (empfiehlt Kay). Der Maintainer/Entwickler Kyle Gorman ist auf vollzeitbeschäftigt, kann also Support leisten und ist für Feedback dankbar. Wenn wir das (Performanz-Problem einigermaßen identifiziert haben, sollten wir weder auf eine andere Bibliothek ausweichen noch auf eigene Faust reparieren.)
auch für Feedback dankbar und kann auch Support leisten.
