:construction: 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)
1. Kanonisierung oder rein historisches Lexikon/Sprachmodell oder "historisierte" Daten (NC-Modell)
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. Kanonisierung oder rein historisches Lexikon/Sprachmodell oder "historisierte" Daten (NC-Modell)
mit Koordinierungsprojekt (und mit LMU) abstimmen!
1. Wort-Resegmentierung (Worttrennzeichen im Fehlermodell), auf welcher Einheitengröße suchen vs modellieren wir? (z.B. ges. Dokument für Sprachmodell, aber nur Zeile oder nur 10-Zeichen-Fenster für Fehler)
1. Normierung der einzelnen Konfidenzen, Möglichkeit zur Gewichtung der Modelle (und Varianten) untereinander (also Hypothesen/Fehler/Lexikon/Sprachmodell), Gesamtschwellwert; Schätzung sinnvoller Gewichte/Schwellwerte auf Lernstichprobe
1. Erkennung der Muttersprache und Domäne (Anfang+Ende) für Auswahl von Lexikon und Sprachmodell; Domäne als Textelement, Textgattung, Zeitraum, Dialekt, Textnormalisierungskonvention
1. Wort-Resegmentierung (Worttrennzeichen im Fehlermodell), auf welcher Einheitengröße suchen vs modellieren wir? (z.B. ges. Dokument für Sprachmodell, aber nur Zeile oder nur 10-Zeichen-Fenster für Fehler)
1. Normierung der einzelnen Konfidenzen, Möglichkeit zur Gewichtung der Modelle (und Varianten) untereinander (also Hypothesen/Fehler/Lexikon/Sprachmodell), Gesamtschwellwert; Schätzung sinnvoller Gewichte/Schwellwerte auf Lernstichprobe
1. Erkennung der Muttersprache und Domäne (Anfang+Ende) für Auswahl von Lexikon und Sprachmodell; Domäne als Textelement, Textgattung, Zeitraum, Dialekt, Textnormalisierungskonvention
mit Koordinierungsprojekt (und mit LMU) abstimmen!
1. Protokollierungsmöglichkeiten (ohne gesamten Suchraum exportieren zu müssen, etwa diskrete Ereignisse aus wertstetigen Graphen; mindestens Ersetzungskandidaten mit Konfidenz, evtl Lexikon-Ableitungsgraph, Fehler-Verwechslungsgraph, Sprachmodell-Bewertung/Domäne, Muttersprache)
1. Protokollierungsmöglichkeiten (ohne gesamten Suchraum exportieren zu müssen, etwa diskrete Ereignisse aus wertstetigen Graphen; mindestens Ersetzungskandidaten mit Konfidenz, evtl Lexikon-Ableitungsgraph, Fehler-Verwechslungsgraph, Sprachmodell-Bewertung/Domäne, Muttersprache)
optional?
1. Morphologie: unüberwacht/datengetrieben vs regelbasiert (F+D+K) vs kombiniert; für verschiedene Sprachen, für Eigennamen/OOV (Zeichen-Polygramme)
...
...
@@ -87,9 +87,9 @@ Folgen für uns:
1. Komposition von Lexikon und Fehlermodell vorberechnen
1. Test verschiedener Wort-/Sprachmodelle:
1. Lexikon und Ganzwortmorphologie
1. nur Lexikon (Maciejs Lexikon mit 50k Wortformen, Asse-Lexikon)
1. Zeichen-ngram-Sprachmodell mit OpenGrm
1. Lexikon und Ganzwortmorphologie
1. nur Lexikon (Maciejs Lexikon mit 50k Wortformen, Asse-Lexikon)
1. Zeichen-ngram-Sprachmodell mit OpenGrm
1. Lazy Composition testen (OpenFST-Implementierung in C++)
1. Vergleich der Laufzeit mit WWMOCR
...
...
@@ -523,11 +523,13 @@ Weitere Ideen zum Inhalt:
- Formulierung so, dass es sich eher an den Geisteswissenschaftler wendet
Mögliche Titel:
-`Towards Context-Aware Language Models for Historical OCR Post-Correction`
-`Comprehensive Context-Aware Language Models for Historical OCR Post-Correction`
-`Leveraging Document and Text Context in Language Models for
OCR-Postcorrection`
-`Context-Aware OCR-Postcorrection for Historical Documents`
> _Towards Context-Aware Language Models for Historical OCR Post-Correction_
> _Comprehensive Context-Aware Language Models for Historical OCR Post-Correction_
> _Leveraging Document and Text Context in Language Models for OCR-Postcorrection_
> _Context-Aware OCR-Postcorrection for Historical Documents_
(Wichtige Inhalte des Titels: Nachkorrektur, historische Korpora, Metadaten)
...
...
@@ -561,34 +563,32 @@ Rückmeldungen)
- PrintSpace nicht aus buchdrucktechnischer Sicht (d.h. alles was gesetzt werden muß), sondern abstrakter (alles was den fortlaufenden "Text" des Buches ausmacht)
- Unterscheidung zwischen Textflusselementen und Textfluss unterbrechenden
Elementen:
- Erfassung und Klassifizierung der Textfluß-Abfolge der Region-Elemente in `ReadingOrder`
- entweder als `OrderedGroup` oder `UnorderedGroup`
- Unterscheidung zwischen Textflusselementen und Textfluss unterbrechenden Elementen:
- Erfassung und Klassifizierung der Textfluß-Abfolge der Region-Elemente in `ReadingOrder`
- entweder als `OrderedGroup` oder `UnorderedGroup`
- neuer Struktur-GT (nur Zoning, kein Inhalt)
- Fonts werden grob eingeteilt in alle Antiqua-artigen und "Blackletter" (d.h. gebrochene und historische Schriften)
- mit Statistik zu Page-Typen (d.h. wieviele `content`, `title`, `index` und `other`) und Region-Typen (s.o.)
- Fonts werden grob eingeteilt in alle Antiqua-artigen und "Blackletter" (d.h. gebrochene und historische Schriften)
- mit Statistik zu Page-Typen (d.h. wieviele `content`, `title`, `index` und `other`) und Region-Typen (s.o.)
- Konzept: Integration der Tools über die Kommandozeile, aber als spezialisierte, einheitliche CLI mit einer __Workspace__ genannten gekapselten persistenten Datenverwaltung auf Basis von METS/PAGE
- Arbeitsschwerpunkte:
-*Spezifikationen* (Richtlinien zu Datenformaten, Anforderungen an Schnittstellen, normativ und antizipativ aber diskutabel)
-*Werkzeuge* (Verifikation und Referenzimplementierungen)
-[*Glossar*](https://ocr-d.github.io/glossary) zur verbindlichen Festlegung kritischer Begriffe (Druckspiegel/Printspace, Zeichen/Glyph/Graphemcluster, ...)
-*Spezifikationen* (Richtlinien zu Datenformaten, Anforderungen an Schnittstellen, normativ und antizipativ aber diskutabel)
-*Werkzeuge* (Verifikation und Referenzimplementierungen)
-[*Glossar*](https://ocr-d.github.io/glossary) zur verbindlichen Festlegung kritischer Begriffe (Druckspiegel/Printspace, Zeichen/Glyph/Graphemcluster, ...)
- Erklärung der einzelnen Repositories auf Github:
-[spec](https://github.com/OCR-D/spec): Spezifikation von Ein-/Ausgabeformaten, Schnittstellenanforderungen
(später: Deployment)
-[docs](https://github.com/OCR-D/docs): Beispiele, Cookbook für die Dokumentation, Metadokumentation
-[core](https://github.com/OCR-D/core): eigentliches Framework, Implementation von *spec* als Python-Toolkit,
mit API für PageXML und METS, mit CLI für die Python-Schnittstelle (später: auch Wrapping
- Zustandshafte Integrationsschnittstelle zu verwenden, damit Kontext für uns über lange Passagen hinweg sichtbar ist, wäre technisch gesehen wohl nicht problematisch. Müsste man in der konkreten Anwendung sehen.
* Java-Implementation von Steven Price für die Edit-Distance, wohl nicht auf OCR ausgerichtet
* Im Impact-Projekt sind 4 verschiedene Evaluations-Tools für OCR
entstanden (für verschiedene Teilprobleme). Ursprünglich sollte hiervon
ein Tool beim Entwickler-Workshop gewrappt werden, wurde wegen
technischer Probleme dann nicht gemacht.
- Metadaten, die wir bekommen können:
* Erscheinungsdatum (nicht normalisiert)
* Autorschaft (nicht normalisiert)
* Regalnummer (aber fragwürdig)
* Genre: wird noch geklärt
* Sprache: wurde sehr ungenau genutzt/annotiert
- Zustandshafte Integrationsschnittstelle zu verwenden, damit Kontext für uns über lange Passagen hinweg sichtbar ist, wäre technisch gesehen wohl nicht problematisch. Müsste man in der konkreten Anwendung sehen.
