Kurz gesagt
Transfer bedeutet für IncluLearn.AI nicht, eine abgeschlossene Forschungssoftware neben bestehende Systeme zu stellen und von anderen Einrichtungen die komplette Umstellung ihrer Arbeitsweise zu erwarten.
Ein nachhaltigerer Weg ist, offene Standards an den Grenzen zu nutzen, etablierte Werkzeuge dort wiederzuverwenden, wo sie ein Problem bereits gut lösen, und projektspezifische Entwicklung auf die tatsächlich neue Aufgabe zu konzentrieren: überprüfbare Semantik komplexer MINT-Inhalte.
Fünf Beispiele zeigen, wie unterschiedlich solche Bausteine sein können.
MathML: Mathematik als Struktur, nicht als Bild
MathML kodiert mathematische Notation und Struktur maschinenlesbar. Der 2026 gestartete W3C Math Working Group Charter nennt bessere Accessibility ausdrücklich als Ziel.
Geplant sind unter anderem Arbeiten an Accessibility-Annotationen sowie Open-Source-Beispielimplementierungen für MathML-to-speech und MathML-to-braille.
Für IncluLearn.AI ist MathML damit ein naheliegender Referenzpunkt für mathematische Ausgabe und Interoperabilität. Es löst aber nicht automatisch die vorgelagerte Aufgabe, Mathematik aus beliebigen PDFs oder Bildern korrekt zu rekonstruieren.
EPUB Accessibility: Zugänglichkeit auch auffindbar machen
EPUB Accessibility 1.1 ist seit Oktober 2024 eine W3C Recommendation. Die Spezifikation definiert Anforderungen zur Prüfung der Zugänglichkeit von EPUB-Publikationen und Metadaten, mit denen zugängliche Eigenschaften auffindbar werden.
Das ist für Transfer interessant, weil ein barrierefreies Ergebnis nicht nur erzeugt, sondern auch beschrieben, geprüft und in bestehende Publikationsökosysteme eingebettet werden muss.
Ob EPUB selbst ein zentrales IncluLearn.AI-Ausgabeformat wird, ist damit noch nicht entschieden.
DAISY Pipeline: Transformation als modularer Produktionsprozess
Die DAISY Pipeline ist ein Open-Source-Framework für automatisierte Transformationen zwischen zugänglichen digitalen Formaten. Der DAISY Consortium beschreibt ausdrücklich einen Single-Source-Master-Ansatz, modulare wiederverwendbare Komponenten und Integration über Kommandozeile bzw. Web-API.
Für IncluLearn.AI ist weniger interessant, eine solche Pipeline nachzubauen, als von ihrer Produktionslogik zu lernen:
- Standards als stabile Grenzen,
- wiederverwendbare Transformationsmodule,
- automatisierbare Workflows,
- Trennung zwischen Verarbeitung und konkreter Bedienoberfläche.
Die neuartige Projektfrage liegt davor: Wie entsteht aus komplexem visuellem MINT-Material zunächst eine ausreichend zuverlässige fachliche Semantik?
Pandoc: text-first Quellen in viele Formate überführen
Pandoc konvertiert zwischen zahlreichen Markup- und Dokumentformaten, darunter Markdown, HTML, LaTeX und DOCX.
In der eigenen Pattern Collection dient Pandoc als Beispiel dafür, wie ein strukturierter textueller Kern in eine visuell gestaltete Ausgabe transformiert werden kann.
Für IncluLearn.AI ist das ein gutes Beispiel für das Prinzip: Ein Renderer oder Konverter muss nicht zugleich die fachliche Bedeutung erschließen. Wenn die Semantik bereits korrekt und strukturiert vorliegt, können etablierte Werkzeuge Teile der Ausgabe übernehmen.
PlantUML: ein Modell, mehrere Wahrnehmungswege
PlantUML erzeugt Diagramme aus einer textuellen Sprache. In den eigenen Lehrvorarbeiten wurde dieser Ansatz für UML-Klassendiagramme genutzt.
Das Interessante ist nicht nur der Renderer, sondern die gemeinsame Quelle: Eine Person kann die textuelle Struktur mit Screenreader oder Braille bearbeiten, während andere dieselbe Quelle als visuelles Diagramm betrachten.
Genau dieser Gedanke passt zum Semantic-first-Ziel von IncluLearn.AI.
Was daraus architektonisch folgt
Die fünf Beispiele erfüllen unterschiedliche Aufgaben. Sie sollten nicht in einen Topf geworfen werden.
Eine plausible Schichtung ist:
- fachliche Semantik rekonstruieren und prüfen – Kernforschung von IncluLearn.AI,
- offene Repräsentationen und Standards verwenden – etwa MathML oder strukturierte Webformate,
- bewährte Konverter und Renderer nutzen – wo sie bereits zuverlässig arbeiten,
- bestehende Produktionssysteme anbinden – statt parallele Inselworkflows zu erzwingen.
Damit bleibt die semantische Quelle möglichst unabhängig von einzelnen Tools.
Noch keine endgültige Toolauswahl
Dieser Beitrag beschreibt Referenztechnologien und Transferoptionen, keine bereits beschlossene Produktarchitektur.
Vor einer Integration müssen unter anderem Accessibility in den tatsächlich verwendeten Clients, Lizenzbedingungen, Wartbarkeit, Formatabdeckung, Performance und Anschlussfähigkeit an reale Partnerworkflows geprüft werden.
Gerade deshalb ist frühes Feedback wichtig: Welche Formate und Werkzeuge sind in Medienzentren, Hochschulen und Lernplattformen tatsächlich Teil des Alltags?