planung.md

@@ -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
+abgrenzen würden.