---
# System prepended metadata

title: Protokoll zum Antragsworkshop (7.8.2020)

---

# 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