2026‐10‐05 Community Board (Kitodo.Production) - kitodo/kitodo-production GitHub Wiki

Teilnehmende: André Hohmann, Anja Piller, Armin Möller (E), Christoph Bartmann, Katharina Gart (E), Kerstin Wendt (M/P), Lole Westedt (E), Matthias Kissler, Nils Reichert (E) - Gast: Arved Solth ab 14.30

Themen in dieser Sitzung

• Automatische Strukturierung in Kitodo.Production mit der Hilfe von LLMs

  • Christoph stellt sein vielversprechendes Ergebnis für einen historischen Druck mit mittelkomplexer Struktur inkl. Zweispaltigkeit vor. Er zeigt auch kurz den dahinterliegenden Prompt, der die Scans direkt verarbeitet hat.
  • erste Gedanken zu einer Einbindung in Kitodo.Production:
    • als skriptgesteuernten Prozess in den Workflow integrieren - vergleichbar zum OCR-Thema
    • Ergebnisse nicht direkt in die meta.xml schreiben - das Ergebnis aus der KI im JSON-Format ausgeben lassen, als Option im Metadateneditor visualieren lassen mit der Möglichkeit, das Ergebnis zu verwerfen und vollständig selbst tätig zu werden bei der Strukturierung
    • Wie gut die LLMs mit Hierarchien in der Kapitelgestaltung umgehen können, gilt es auszuprobieren. Alternativ könnte man die Kapitel in flacher Hierarchie aufnehmen lassen und die Hierarchie dann über den Metadateneditor zügig umsetzen. Korrekturen an verunglückten Hierarchien erscheinen aufwändiger.
    • Bei den vorzugebenden Strukturelementen ggf. auch stark vereinfacht vorgehen mit "Abschnitt".
    • Die Übergabe von vorhandenen Metadaten zum Objekt (Dokumenttyp, Sprache, Erscheinungsjahr, Schrifttyp) verbessert ggf. das Ergebnis
    • Welches Modell reicht aus für unser Anliegen? Mit kleinem Modell starten - trainieren mit vorhandenen Daten (Groundtruth)
    • Konkrete (mehr technische) Fragestellungen ggf. unterstützend von Masterarbeit an HAW Hamburg bearbeiten lassen? (z.B. Welches Level an LLM wird benötigt?)
    • Einbindung der AnwenderInnen und ihrer Erwartung aus der täglichen Praxis (Community-Treffen?)

• Dokuthemen mit Arved besprochen

  • Transformation der Anwenderdokumentation in GitHub zu einer durchsuchbaren Website (Idee von Daniel Opitz): Weiterarbeit an den Einzelseiten in GitHub in Verbindung mit Nutzung des Tools Zensical als static site generator. Die Grundlage für die Struktur der Website ist dazu in einer Markdown-Datei zu konfigurieren und anzupassen (s. https://github.com/danielopitz/kitodocs/blob/main/_nav.md). Die Verlinkung innerhalb der Dokumentation bleibt konsistent und das Tool ist in der Lage nicht funktionierende Links aufzudecken.
  • Arved unterstützt den Vorschlag uneingeschränkt. Christoph organisiert Verabredung mit Arved und Daniel zur konkreten Umsetzung.

• Wege zur Aufgabe von überholten Features?

  • In der Sitzung wurde von André eine Liste mit bekannten Features, die überholt oder mittlerweile problematisch sind, zusammengestellt und mit ihrem jeweiligen Status kommentiert.
  • Frage: Welches Feature sollte als erstes angegangen werden?
  • Wege der Kommunikation zur "Abkündigung": Praxistreffen, Community-Liste, Wiki, Elements
  • Beim Zeitungsthema (Abschaffung der möglicherweise nie genutzten Aggregationsmöglichkeiten bei den Vorgängen) ist ggf. noch das Migrationsthema zu bedenken für Vorgänge, die zwar als Einzelvorgang angelegt wurden - aber die überflüssige Datenstruktur mit den Zwischenebenen aufweisen - siehe Gesamtschau des Problems von Christoph und Kommentar zum Umgang mit bestehenden Vorgängen.

mögliche Themen für das nächste Treffen

• Metadatenupdate
• Themensichtung allg.
• Verfeinerung der Idee zu einem nächsten Community-Treffen: Dokumentation / Version 4 - Erfahrungen

Nächstes Treffen

• Moderation: ??
• Protokoll: ??