@@ -235,7 +235,13 @@ Anpassung/Normierung der Konfidenzwerte): dafür ist ebenfalls das QS-Modul zust
Wir können also unsere Ergebnisse mit unseren *Konfidenzen* ausgeben, ohne
vom Rest abhängig zu sein.
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).
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.
Die OCR-Konfidenz ist dann aussagekräftig, wenn sie eine Unsicherheit (also
einen niedrigen Wert) ausdrückt.
Interessant wäre es, Konfidenzverläufe (Folgen von Konfidenzen) auf
OCR-Fehler abzubilden. So wird der Kontext eines Zeichens (umliegende
Konfidenzen) berücksichtigt.
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
...
...
@@ -263,6 +269,11 @@ Dabei sollten wir immer nur versuchen *relative Fortschritte* zu erzielen und we
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.
Beim Entwicklertreffen wird es für jedes Modul einen
15-Minuten-Vortragsslot geben. Bis dahin sollten die prinzipiellen
(vorläufigen) Design-Entscheidungen stehen. Schnittstellen und Parameter
sollten dann festgelegt sein.
#### dynamische Kanonisierung vs historische Modelle
Kay ist sehr skeptisch bezüglich Morphologie und Kanonisierung,
...
...
@@ -277,7 +288,7 @@ Was *Morphologie* betrifft, eine Möglichkeit wäre eventuell ein Verfahren für
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).
erzeugt (etwa 30k Seiten mit jeweils maximal 36 Zeilen).
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).
...
...
@@ -421,3 +432,10 @@ Hardware, Bibliotheken etc.) betrifft auch die Training-Tools, am besten für je
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 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.)
#### RNN vs FST
Kay ist der Meinung, dass RNNs am besten funktionieren und daher am besten
ein RNN-Ansatz für das Gesamtsystem umgesetzt werden sollte.
Dafür würde auch sprechen, dass wir uns dadurch thematisch von den Münchnern
