...alles geklärt bis auf Normierung – einarbeiten, neue Seite zu Architektur anfangen!
1. Entwicklung Architektur:
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)
...
...
@@ -20,59 +22,44 @@ u.g. priorisieren...
### Organisatorische Fragen
1. unreine/Fehler-Daten (aus OCR-Workflow) vom DTA anfordern – Antwort steht noch aus
| unüberwacht | 3) Denoising mit RNN | 4) Fehlermodell mittels EM |
Für jedes der Experimente Tests auf
1. den Asse-Daten
1. den DTA-Daten
durchführen und auch auf den jeweils anderen Daten testen.
1. erste Tests auf Asse-Daten durchgeführt, Verbesserung der Performanz notwendig
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)
| überwacht | mit FST | (Adaption: vorerst nicht) |
| | mit RNN | (Adaption: vorerst nicht) |
| unüberwacht | Denoising mit RNN | (adaptiv mittels EM: schon bei CIS-Gruppe) |
1. erste Fehlermodelle (auf Asse-Daten und auf GT sobald verfügbar) gemäß Tabelle;
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. 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
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. OCR-Toolchain(s) auf GT-Daten, damit weitere Fehlermodelle erzeugen
## Erledigt
1. im Antrag referenzierte Arbeiten
1. keras-Tutorial
1. Mächtigkeit und Trainierbarkeit von FNN/RNN
1. HFST installieren/benutzen
1. ddc-concordance installieren
1. DTA-Daten und GT-Daten ansehen
1. Literatur: im Antrag referenzierte Arbeiten
1. Werkzeuge: keras-Tutorial
1. Literatur: Mächtigkeit und Trainierbarkeit von FNN/RNN
1. Werkzeuge: HFST und OpenFST installieren/benutzen
1. Werkzeuge: Gensim, Tesseract etc installieren
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
### 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).
* 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
ein paar Wochen verfügbar, funktioniert momentan nicht).
### 29./30. Mai 2018 (BBAW)
#### 29. Mai 2018 (Kai-Michael Würzner, Matthias Boenig)
### 29-30. Mai 2018 (am BBAW mit Kay-Michael Würzner, Matthias Boenig und Bryan Jurish)
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.
Wenn dabei festgestellt wird, dass die Ausgabe eines Moduls nicht brauchbar
ist, wird sie nicht an das nächste Modul weitergegeben.
Wir müssen nicht die Integration mit den anderen Komponenten (also inkl.
Anpassung/Normierung unserer Konfidenzwerte in Bezug auf die anderen
Konfidenzwerte) übernehmen, da das durch das Modul Qualitätssicherung
übernommen wird.
Dabei wird von einer klar linearen Prozesskette ausgegangen, in der die
Qualitätssicherung einen Schritt (den zuletzt ausgeführten) neu auslösen
kann.
Wir können also unsere Ergebnisse mit unseren Konfidenzen ausgeben, ohne
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*).
Dafür werden auch die Konfidenzwerte der Module genutzt, aber nicht ausschließlich.
Wir brauchen OCR-Ergebnisse *nicht* selber zu integrieren (also als Rückfallstufe inkl.
Anpassung/Normierung der Konfidenzwerte): dafür ist ebenfalls das QS-Modul zuständig.
Wir können also unsere Ergebnisse mit unseren *Konfidenzen* ausgeben, ohne
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
Konfusionsmatrix (das wird beim nächsten Entwicklertreffen genau geklärt)
und geben unseren korrigierten Text raus.
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).
#### 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
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
Neuprozessierung sind komplexe Fragestellungen an die Langzeitarchivierung.
Der Fokus bei uns sollte auf dem Mitliefern funktionierender Fehlermodelle
liegen.
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 in diesem Projekt auf den **bestmöglichen Standardmodellen** liegen.
2
#### Treffen im Juni, Entwicklungsmodell und Evaluierung
Wir werden vermutlich Informationen zur verwendeten Schriftart bekommen, da
es dafür ein Modulprojekt gibt.
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.
Wir sollten unser Programm iterativ entwickeln, damit es immer ein
funktionierendes Produkt gibt.
Den Test und die Evaluation unseres Programms kann auch das
Koordinationsteam übernehmen.
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**.
Beim Entwicklertreffen im Juni (26./27.) werden wir für existierende Tools
(nicht unsere eigenen) Wrapper bauen, wie es von der OCR-D-Spezifikation
vorgesehen ist, um das zu üben.
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.
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
Arten von Sprache mit einem allgemeinen Modell abzudecken.
Eine Möglichkeit wäre eventuell ein Verfahren für Morphologieinduktion,
mit dem wir Modelle für verschiedene Zeitintervalle erstellen.
Arten von Sprache mit einem einzigen allgemeinen Modell abzudecken.
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
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.
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.
Die jetzigen GT-Daten enthalten noch keine Metadaten. Die METS-Daten mit
Metadaten sind gerade in der Entstehung begriffen.
#### Metadaten und Textelement-Typen
Die bisherigen GT-Daten dienen nur als Referenz, wie die späteren Daten
aussehen werden. Die späteren Trainings- und Testdaten werden jetzt gerade
Die bisherigen GT-Daten dienen nur als erste *Referenz*, wie die späteren Daten
aussehen werden. Die großen Trainings- und Testdaten werden aktuell gerade
erzeugt (etwa 30k Seiten).
PageXML hat nur einen minimalen Metadatenteil, der kein Genre vorsieht. Wir
können aber Custom-Attribute (in Absprache mit dem Koordinationsteam) für
derartiges verwenden und selbst befüllen, falls wir so etwas klassifizieren.
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).
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
DTA-Klassifikation für Genres in Verbindung gebracht und vereinheitlicht
werden können.
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).
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
ist auch sehr unklar, da es viele verschiedene Meinungen gibt. Die
inhaltliche Erschließung in den Bibliotheken ist zudem teuer.
Wenn wir Genre überhaupt nutzen, dann lieber eine grobe Unterteilung.
Das Koordinationsteam wird trotzdem nachfragen und herausfinden, inwieweit die VD- und die
DTA/DWDS-Klassifikation für Genres in Verbindung gebracht und vereinheitlicht
werden können. (Wenige sehr allgemeine Kategorien wären vermutlich robust genug, sofern sie nicht direkt als Domäne benutzt werden.)
Eventuell bekommen wir das Erscheinungsdatum der Erstauflage bzw. des
ersten verzeichneten Drucks.
Eventuell bekommen wir sogar das **Erscheinungsdatum** der *Erstauflage* bzw. des
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
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
dauern.
dauern (Durchsatz, nicht Latenz).
Eine Kommunikation des Programms mit externen Servern darf keine Pflicht
sein. Das Programm sollte in Form eines Docker-Images auf einem einzelnen
Rechner laufen können.
Für eine effizientere Lazy Composition von FSTs muss eine Tiefensuche
durchgeführt werden. Von Kai gibt es eine Veröffentlichung (2009) über eine
effiziente Implementierung.
Für eine effizientere *Lazy Composition* von FSTs muss eine Tiefensuche
(statt Breitensuche) durchgeführt werden. Von Kay gibt es eine Veröffentlichung (2009) über eine effiziente Implementierung.
#### Abstimmung mit CIS-Gruppe
Für eine Abstimmung mit den Münchnern sollten wir uns mit diesen direkt
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.
Eine Organisierung kann aber sehr sinnvoll sein, wenn es Komponenten gibt,
die von beiden Teams benötigt werden (z.B. Sprachmodell). Diese könnte man
dann gemeinsam erarbeiten/implementieren.
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.
5
Die Münchner verwenden bei ihrem Ansatz Ausnahme-Regel-Listen, die man von
Hand bearbeiten kann. Diese manuelle Modellierung findet Kai nicht so
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
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 Entwickler des Profilers (Reffle und Ringlstetter) sind auch nicht mehr am
CIS. Ein weiteres Problem des CIS-Ansatzes ist, dass der Regelsatz nicht
zeitspezifisch ist.
#### Zeichensatz bei Ein- und Ausgabe
Wir sollen auf keinen Fall eine Kanonisierung oder Normalisierung des Textes
ausgeben, sondern er soll genau wie der Originaltext aussehen.
Das beinhaltet dann z.B. auch 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).
Das beinhaltet sogar *Trennstriche* am Zeilenende.
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
Segmentierung hinbekommen werden.
#### historische OCR-Fehlerdaten zum Mitnehmen
An sich ist eine enge Kopplung von OCR mit Nachkorrektur besser als eine
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](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).
Der Archiscribe-Korpus enthält Bild + Text für Zeilen aus verschiedenen
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.
Stattdessen haben wir 61k Zeilen (`dta19-reduced`) bekommen mit Fraktur aus dem 19.
Jahrhundert.
Nutzbare Modelle für unsere Erzeugung von fehlerhaftem OCR:
- tessdata_best -> scripts/Fraktur
- von Kai trainiertes Modell für Tesseract (mit 9k Zeilen trainiert, jede
etwa einmal gesehen)
- ocropus (auch hierfür haben wir ein Modell von Kai bekommen)
- omnifont-Modell und deu-frak (aus tesseract3) schreibt kein langes s, daher
vielleicht eher problematisch
[Nutzbare](Entwicklungsumgebung#tesseract) Modelle zur Erzeugung von fehlerbehafteter OCR:
-[tessdata_best](https://github.com/tesseract-ocr/tessdata_best) für Tesseract 4 → `scripts/Fraktur`
-[von Kay trainiertes Modell](http://odo.dwds.de/~kmw/foo.traineddata) für Tesseract 4 (mit 9k Zeilen trainiert, jede etwa einmal gesehen)
-`tesseract-ocr-deu-frak` aus den Ubuntu-Repos für Tesseract 3
omnifont-Modell und deu-frak schreiben kein langes ſ, daher vielleicht eher problematisch (oder zumindest zu beachten)
-[von Kay trainiertes Modell](http://odo.dwds.de/~kmw/fraktur19-00050000.pyrnn.gz) für ocropus
Mit den zusätzlichen Daten wird das Koordinationsteam bessere Modelle
Mit den zusätzlichen Daten wird das Koordinationsteam dann auch sukzessive bessere Modelle
trainieren.
OCR-D/core verwendet für XML-Parsing in Python lxml.
Page ist dort in Python gewrappt.
#### Schnittstellen für ersten Prototypen
[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
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
Modelle, die auch nicht weitergegeben werden dürfen. Daher ist die Nutzung
von CAB für uns ungeeignet.
CAB und sein Quellcode darf leider nicht weitergegeben werden. Es nutzt viele
Modelle (wie TAGH), die auch nicht weitergegeben werden dürfen. Allein schon deshalb ist CAB für uns **ungeeignet**.
Zudem stellt die Kanonisierung eine zusäzliche Fehlerquelle dar, sodass
sich schwer sagen lässt, woher ein Fehler stammt.
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.
Bei Texten aus dem 18. Jh. und später ist CAB recht verlässlich.
Bei älteren Texten verschlechtert sich die Qualität.
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 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 erheblich. Man muß ohnehin immer einen Kompromiß zwischen zuvielen Falschpositiven (v.a. bei veralteten Wortformen) und zuvielen Falschnegativen (v.a. bei Eigennamen) finden.
Bei CAB sind nur die Gewichte des FST-Modells datengetrieben, nicht die
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).
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.
#### effiziente Komposition
Bryan hat festgestellt, dass die Lazy Composition von OpenFST so lange
braucht, da vor der eingentlichen Suche von Pfaden Attribute des FSTs
aufwendig getestet werden.
GFSM ist der Name von Bryans FST-Implementierung (`libgfsmxl`).
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.
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
stattfinden. Da es ursprünglich nicht im Projekt eingeplant wurde, wird es
auf einer Konferenz im Rahmen eines Workshops stattfinden. Die Idee ist,
dass jedes Modulprojekt eine Einreichung beim Call for Posters macht, und
wir so eine "OCR-D-Ecke" dort haben.
Auf diese Weise können wir auch etwas Öffentlichkeitsarbeit für OCR-D
machen und erhalten wertvolle wissenschaftliche Rückmeldung.
Bei diesem 2. Entwicklertreffen wird die Integration der einzelnen Module
wir eine "OCR-D-Ecke" dort haben.
Auf diese Weise können wir auch etwas (dringend benötigte) Öffentlichkeitsarbeit für OCR-D
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 dann die Integration der einzelnen Module
zu einem Workflow durchgeführt/getestet.
#### Erzeugung von Modellen
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
einer automatisierten Verarbeitung laden kann und dann alle Schnittstellen
registriert sind.
Das Modulprojekt zur Trainingsdateninfrastruktur wird voraussichtlich doch nicht zustandekommen.
[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
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.
Wenn wir FSTs verwenden, dann sollten wir also möglichst OpenFST verwenden und
nicht etwas, das niemand benutzt. Der Maintainer/Entwickler Kyle Gorman ist
auch für Feedback dankbar und kann auch Support leisten.
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.)
