# Protokoll zum Antragsworkshop (7.8.2020)

## aktuelle Entwicklungspläne des Koordinierungsprojekts

## Update der Implementierungsvorhaben

### SUUB Bremen/UB Frankfurt/ULB Bonn
* 16 Bibliotheken potentiell Interesse an Implementierung
* QA auch Set an Standardworkflows möglich/geplant?
* VZG ausführlichere Gespräche => erst Geschäftsmodell, jetzt eher API
* Bedarf an Koordinierung für API-Entwicklung (Training + OCR)
* Frankfurt Docker, Bremen nativ installiert
* user guide schwierig
* Bonn 17.8. große VC mit VL

#### Fragen VL
* Karlsruhe jetzt Pilotbibliothek, semantics Interesse an Open Source

### ThULB Jena/VZG
* MyCoRe eher verworfen
* Jena keine Ressourcen für Entwicklung
* Kooperation mit Bremen intendiert

#### Fragen VZG
* Aufgabenverteilung der gemeinsamen API-Entwicklung in möglichst viele Anträge unterbringen

### SLUB Dresden/UB Mannheim/UB Braunschweig
* API wichtig
* Kommandozeile <=> Web API
* wer entwickelt backend/job queue?
* Halle hat sich als Pilotnutzer angeboten
* MWW API-Interesse
* Leipzig nicht mehr dabei (QA)
* Kernidee des Projekts evtl. in Kitodo-Projekt einbinden
*

#### Fragen Kitodo
*

### Uni Würzburg
* vermutlich zusammen mit GEI Braunschweig als Anwender Antrag stellen
* Worfklows zusammenstellen und dann möglichst auch exportieren und für OCR-D nutzen
* Ergebnisse von Workflows visualisieren um Probleme zu finden
* Taggings vergeben sodass daran Testsets erstellt werden können
* Training gemischter Modelle für Calamari (Ergänzung zu Tesseract, Mannheim)
* Infrastruktur aus Würzburg könnten andere Projekte nutzen
* METS-Schnittstelle hat funktioniert
* Pilotierung weitgehend abgeschlossen + läuft alles
* Layoutevaluation Lösung inzwischen vorhanden?

#### Fragen OCR4all
* Gameifizierung GT-Produktion
*

### ULB Halle
* Austausch mit Göttingen für Performanz
* QA war/ist auch großes Interesse
* kleineres Testset schon durchlaufen lassen => Fokus auf Performanz, Parallelisierung
* Datenbereinigung über OAI-Schnittstelle recht aufwändig => Hilfe von Koordinierung erwünscht (zu viele fileGroups)
* neue Derivate müssen erzeugt werden (pdf mit Volltexten, ...)
* nach Prozessierung bereinigen (Zwischenergebnissebnissebnisse)
* bei Altdaten unterschiedlichste Konventionen/Standards => Herausforderung
*

#### Fragen Halle
*

### SUB Göttingen/GWDG
* Altbestand Bilddigitalisate + Neudigitalisate prozessieren
* Fokus auf Parallelisierung/HPC
* Gespräche mit anderen Implementierungspartnern (z.B. Halle, ...)
*

#### Fragen Göttingen

### UB Mannheim
* viele Mannheim angefragt wegen Zusammenarbeit => Mannheim an allen Interesse
* GT-Aufwertung gerade als wichtiges Thema
* in Transkribus-GT meist nur Baselines gut (aber nicht line boxes) => gerade auf der Suche nach gutem Werkzeug für Verbesserung
* Multiparameter-Analyse für Training aus Leipzig gerade veröffentlicht
* Trainingsdaten-Verbesserung sicher auch für Würzburg interessant

#### Fragen Mannheim
* in Kraken neue Segmentierungsmethode um Polygone aus Baselines zu erzeugen
* Angebot für Letter of Support zu Projektidee

### MWW
* Fokus auf Niedrigschwelligkeit + einfache Nutzbarkeit für einzelne Forschungsprojekte
* Interesse an Zusammenarbeit mit Siegen
* Nutzbarmachung für IIIF soll als Bedarf an Koordinierung gemeldet werden
* großes Interesse an API
* Tests erst gestartet, Know.How zu OCR-D fehlt noch
*

#### Fragen MWW
* Bremen Interesse an gemeinsamem Anfänger-Workshop zu OCR-D => könnte in SupportCall gemacht werden
* Installationsprobleme in Wiki sammeln
*

### Uni Siegen
* Bitfarm abgesprungen => derzeit auf der Suche nach Kooperationspartnern
* Kooperation mit OCR4all eher nicht möglich
* offen für weitere Kooperationen

#### Fragen Siegen
* Barrierefreiheit für Sehbehinderte weiterhin wünschenswert
* dazu schon erste Gespräche mit MWW
* Kompetenzen für einfache Sprache über Konsortium auf vorhanden, könnte ggf. für Projekt genutzt werden
*

### Fraunhofer/Uni Hamburg/ULB Darmstadt
* Fraunhofer Fokus auf Massenverarbeitung (Implementierung Werkzeuge + Deployment auf Kubernetes-Cluster)
* Hamburg Fokus auf Fronted (Integration OCR-D in Forschungsdatenrepo mit einfach bedienbarer GUI, Feedbach über eigene Test-Anwender)
* Darmstadt Cloudbasierter OCR-D-Workflow auf Rechencluster, Integration mit GUI
* Docker + native Installation mit verschiedensten Workflows und Materialien getestet
* Darmstadt soll auf Implementierung von Fraunhofer aufbauen

#### Fragen Forschungsdatenrepo

### SLUB Dresden/Uni Leipzig

#### Fragen Dresden
* Projekte die QA-Ergebnisse nutzen wollten sollten diese an Dresden melden damit diese ggf. in neuem Antrag berücksichtigt werden können

## Diskussion möglicher Koordinierungs- und Entwicklungsbedarfe
### Koordinierung
* API (Dresden auch Interesse an gemeinsamen Entwicklungen für Backend (job queue, Parallelisierung, ...); gefühlt alle)
* IIIF (METS über IIIF-Manifest laden oder direkt IIIF in OCR-D (als Alternative zu METS) ermöglichen; Schwierigkeiten mit fehlenden IIIF-Konventionen => Umfrage unter Bibliotheken + DFG-Praxisregeln; MWW)
* Datenbereinigung (OCR-D-(Zwischen-)Ergebnisse => ocrd-sanitize; Halle sammelt "Probleme" und Konkordanzen in Tabellen und würde diese der Koordinierung + anderen Einrichtungen zugänglich machen) Halle)
* Bereinigung Input-Daten von nicht zu prozessierenden Seiten (Buchdeckel, leere Seiten, Tabellen, ... => so soll zum einen nicht unnötig Rechenzeit vergeudet werden, zum anderen kommt es bei diesen Seiten bei der abschließenden Konversion zu Problemen/Abbrüchen; Bedarf wird von Halle (ggf. in Absprache mit Koordinierung) selbst bedient; eigentlich war Interesse an Nachnutzung von QA-Ergebnissen)
* Berücksichtigung QA-Ergebnisse in möglichst allen OCR-D-Werkzeugen + dynamisch während Workflow sodass z.B. schlechte Seiten erkannt und aussortiert oder Workflow abgebrochen werden kann
*

### Weiterentwicklung
* Page Splitting (nur für Altdaten (bei Neudigitalisaten ohnehin Einzelseiten vorliegend, kein großer Bedarf; Frage aus Würzburg)
* Aber ggf. informelles Projekt für DIY-Bookscanner von hnesk mit vouissour
* Segmentierung (Marginalien (Würzburg))
* Texterkennung Textattribute (z.B. für Lexika relevant, für eng begrenzte Korpora schon gemacht/möglich <=> derzeit (vermutlich) nicht ausweitbar/für Vielzahl an Vorlagen nutzbar; auch für GT-Produktion relevant, mehr perspektivisch)
* wird gerade in calamari evaluiert ob das möglich ist
* ggf. für MWW/HAB Arbeitskreise bzw. die Forscher interessant
* wäre v.a. für Erkennung von Titelblättern wichtig/hilfreich
* Würzburg Forscher?
* LZA kein Interesse (nur Göttingen sich selbst genannt)
* aber auch nicht geleugnet, dass LZA interessant und wichtig ist
* SLUB sieht keinen Bedarf, da hausintern bereits "vorerst" ausreichend guter Workflow
* Mustafa betont Adressierbarkeit, Versionierung usw., nicht nur LZA für OLA-HD

## Hinweise zur Antragstellung
* Keine Verlängerung Abgabetermin Pilotierungsfragebogen
* Nachfrage wer weiterentwickeln darf und wie spezifisch Bedarfe formuliert werden müssen (Würzburg)
* Nur die ursprünglichen Entwickler
* Prozessor-genau