Changes

Page history
Update planung authored by Lena Schiffer's avatar Lena Schiffer
Show whitespace changes
Inline Side-by-side
planung.md
View page @ 8ab4cec0
...@@ -233,3 +233,227 @@ Morph-Segmentierer abzuleiten? ...@@ -233,3 +233,227 @@ Morph-Segmentierer abzuleiten?
- 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. Mai 2018 (Kai-Michael Würzner, Matthias Boenig)
1
Das Modul Qualitätssicherung überprüft die Ergebnisse jeder Modulkomponente
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
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.
Es ist keine Schnittstelle für Offline-User-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.
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.
2
Wir werden vermutlich Informationen zur verwendeten Schriftart bekommen, da
es dafür ein Modulprojekt gibt.
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.
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.
Kai-Michael Würzner ist 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.
3
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.
Die jetzigen GT-Daten enthalten noch keine Metadaten. Die METS-Daten mit
Metadaten sind gerade in der Entstehung begriffen.
Die bisherigen GT-Daten dienen nur als Referenz, wie die späteren Daten
aussehen werden. Die späteren Trainings- und Testdaten werden jetzt 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.
Das Koordinationsteam wird nachfragen und herausfinden, inwieweit die VD- und die
DTA-Klassifikation für Genres in Verbindung gebracht und vereinheitlicht
werden können.
4
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.
Eventuell bekommen wir das Erscheinungsdatum der Erstauflage bzw. des
ersten verzeichneten Drucks.
In der Produktivphase soll die Prozesskette auf einigen Millionen Seiten
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.
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 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
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.
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
zeitspezifisch ist.
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).
6
Auf Morphemebene zu gehen sieht Kai als unmöglich an, da wir keine gute
Segmentierung hinbekommen werden.
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 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.
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
Mit den zusätzlichen Daten wird das Koordinationsteam bessere Modelle
trainieren.
OCR-D/core verwendet für XML-Parsing 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.
#### Bryan Jurish
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.
Zudem stellt die Kanonisierung eine zusäzliche Fehlerquelle dar, sodass
sich schwer sagen lässt, woher ein Fehler 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 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.
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.
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.
#### 30. Mai 2018 (Kai-Michael Würzner, Matthias Boenig)
10
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
zu einem Workflow durchgeführt/getestet.
Das Training unserer Modelle muss so gestaltet sein, dass andere Leute das
auch durchführen können.
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.
Der Fragebogen zu den technsichen Details unseres Programm (verwendete
Hardware, Bibliotheken etc.) betrifft auch die Training-Tools.
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.