Digital Humanities |

tei-mcp v0.3: TEI kodieren, ohne die Quelle anzutasten

Tue, 05 May 2026 00:00:00 +0000

Als ich , ging es darum, KI-Assistenten das Halluzinieren von TEI-Markup abzugewöhnen. Die Verankerung im Schema (Schema Grounding) hat einen Teil des Problems gelöst: Mit direktem, werkzeuggestütztem Zugriff auf die P5-Spezifikation muss das Modell nicht mehr raten, was ein Element bedeutet oder welche Attribute es zulässt. Die Ausgabe validiert.

Nur hat die Halluzination beim TEI-Kodieren zwei Gesichter, und das Schema erkennt bloß eines davon. Die Validierung gegen die Spezifikation verrät, dass das Markup in Ordnung ist; über den Text, den dieses Markup umschließt, sagt sie nichts. Und genau dort – im Text selbst – hausen die gefährlicheren Halluzinationen. Span-locked Composition, das Herzstück von v0.3, ist eigens dafür gebaut, sie zu unterbinden.

Inhaltsverzeichnis

Die Halluzination, die dem Schema entgeht

Lassen Sie ein Modell einen französischen Brief aus dem 16. Jahrhundert kodieren, und Sie bekommen nicht selten ein TEI-Dokument zurück, das tadellos aussieht. Der Header ist ausgefüllt, die <persName>-Tags sitzen, die <dateline> ist wohlgeformt. Durch validate_document geschickt, besteht es die Prüfung.

Dann vergleichen Sie den Textkörper mit der Quelle.

Aus mesme ist même geworden. Ein Komma ist gewandert. luy wurde stillschweigend zu lui modernisiert. Ein in der Handschrift schwer lesbarer Satzteil ist zu etwas Glatterem „berichtigt“ worden. Nichts davon war verlangt, nichts davon wird gemeldet. Das Dokument ist schemavalide – und in aller Stille falsch.

In einem archivischen Arbeitsablauf, in dem der kodierte Text zur dauerhaften Aufzeichnung wird, auf die sich spätere Leser, Suchindizes und Zitate verlassen, ist das der Fehler, der wirklich zählt. Ein missratenes Tag ist ärgerlich. Eine modernisierte Schreibung, die fünf Jahre lang niemand bemerkt, ist eine Textverderbnis.

Span-locked Composition

Die neue Version (v0.3) bringt einen Schutzmechanismus mit, der genau auf diesen Fehler zielt. Der Anspruch: Halluzinationen im Textkörper sollen nicht bloß unwahrscheinlich, sondern schon durch die Konstruktion unmöglich sein.

Die Idee ist einfach: Das Modell tippt nie Textkörper.

Der Ablauf sieht stattdessen so aus:

Das Modell ruft get_source("letter_001") auf und erhält den Quelltext als unveränderliche Zeichenkette.
Für jedes Tag, das es setzen möchte, ruft es tag_span("letter_001", start, end, element_path, attrs) auf und registriert damit ein TEI-Element an einem Zeichenbereich über der Quelle.
Ist es fertig, ruft es compose("letter_001") auf. Der Server verschränkt die registrierten Tags mit dem ursprünglichen Klartext, rendert das endgültige TEI und prüft dann Byte für Byte, ob der reine Textinhalt des gerenderten Dokuments der Quelle gleicht.

Stimmen die Bytes überein, kommt das Dokument zurück. Wenn nicht – wenn die Tags des Modells auf irgendeinem Weg einen Textkörper ergeben, der auch nur um ein einziges Zeichen von der Quelle abweicht –, wirft compose() einen Fehler, statt ein verdorbenes Dokument auszuliefern.

Es gibt in diesem Ablauf keinen Pfad, auf dem das Modell ein TEI-Dokument erzeugen könnte, dessen Textkörper von der Quelle abweicht. Die Invariante ist mechanisch, nicht eine Frage des Wohlverhaltens. Sie müssen nicht darauf vertrauen, dass das Modell nicht halluziniert – nur darauf, dass ein ==-Vergleich zweier Byte-Strings tut, was er soll.

Was das ist – und was nicht

Span-locked Composition ergänzt das Schema Grounding; sie ersetzt es nicht. Die Schema-Grounding-Tools (validate_document, lookup_element, valid_children und die übrigen der ursprünglichen sechzehn) helfen dem Modell, valides TEI zu erzeugen. Span-locked Composition garantiert, dass der Textkörper in diesem TEI der Quelle treu bleibt. Ein einsatzreifer Kodierungsablauf muss auf beiden Achsen bestehen – und beide deckt nun ein einziger Server ab.

Ein Allheilmittel ist es freilich nicht. compose() prüft noch nicht, ob die registrierten Tags nach einer geladenen ODD-Anpassung zulässig sind; das ist der nächste Schritt. Registrierte Tags leben im Arbeitsspeicher des Prozesses und überleben keinen Neustart. Und die Quelldateien müssen von dort aus lesbar sein, wo der Server läuft. All das lässt sich lösen; nichts davon rührt an der Kerninvariante.

Warum das über TEI hinausweist

Das Muster lässt sich verallgemeinern. Wann immer ein Modell einen Text annotieren, umformen oder umschließen soll – und wann immer die Unversehrtheit dieses Textes wichtiger ist als die Gabe des Modells, ihn zu „verbessern“ –, taugt dieselbe Lösung. Lassen Sie das Modell den Text nicht neu tippen. Lassen Sie es Anweisungen über dem Text erzeugen, und überlassen Sie es einem deterministischen Composer, sie unter einer Gleichheitsinvariante anzuwenden.

Für digitale Editionen im Besonderen verschiebt das die Grenze dessen, was man einem Modell guten Gewissens überlassen kann. Das Kodieren wird mit einem Mal zu einer Aufgabe, die sich delegieren lässt, ohne dass man jede Ausgabe von Hand mit der Quelle abgleichen müsste. Die Maschine übernimmt den öden Teil; die Editorin prüft das Markup, nicht die Rechtschreibung.

Das Update beziehen

Wenn tei-mcp bereits installiert ist:

uvx tei-mcp@latest

Oder frisch:

pip install tei-mcp

Für Span-locked Composition zeigen Sie dem Server ein Verzeichnis mit Klartext-Quelldateien:

export TEI_MCP_SPAN_SOURCE_ROOT=/path/to/sources
uvx tei-mcp

Der Dateiname ohne Endung wird zur Dokument-ID (letter_001.txt → letter_001).

Quellcode, vollständige Dokumentation und die Entwurfsnotizen zur Invariante:

Eine digitale Edition anderer Art

Tue, 24 Mar 2026 00:00:00 +0000

Die meisten Primärquellen werden nie veröffentlicht. Und das Modell, mit dem wir dem abhelfen wollen – die drittmittelfinanzierte digitale Edition –, ist zu teuer, zu zentralisiert und zu zerbrechlich, als dass es in der Breite funktionieren könnte. In lege ich dar, warum ich die kritische Edition von Cavrianas Briefen anders anlege: als digitalisierte Primärquellen, die organisch wachsen, mit minimaler Infrastruktur auskommen, sich selbsttätig warten, offen für Mitarbeit sind und so wenig kosten, dass es gar keiner Förderung bedarf. Es ist ein Plädoyer für Digital Humanities, die auch ohne institutionellen Rückhalt funktionieren.

tei-mcp: TEI P5 für KI-Agenten

Sun, 15 Mar 2026 00:00:00 +0000

Wer schon einmal einen KI-Programmierassistenten TEI-XML hat schreiben lassen, weiß, dass dabei Fehler passieren. Elemente stehen, wo sie nicht hingehören; Attribute werden frei erfunden; Verschachtelungsregeln bleiben unbeachtet. Das Modell hat eine ungefähre Vorstellung davon, wie TEI aussieht – von der Spezifikation selbst weiß es nichts Verlässliches.

tei-mcp schafft hier Abhilfe: Es gibt KI-Agenten direkten, werkzeuggestützten Zugriff auf die TEI-P5-Guidelines.

Inhaltsverzeichnis

Was ist MCP?

Das (MCP) ist ein offener Standard, über den sich KI-Anwendungen mit externen Datenquellen und Werkzeugen verbinden. Man kann es sich als USB-Anschluss für KI vorstellen: ein einziges Protokoll, mit dem sich jeder kompatible Client – Claude, Cursor, Windsurf und andere – an spezialisierte Dienste anstöpseln lässt.

Ein MCP-Server stellt Tools bereit, die die KI im Laufe eines Gesprächs aufrufen kann. Statt auf angelerntes Trainingswissen zu vertrauen, kann das Modell eine aktuelle, maßgebliche Quelle befragen.

Was tei-mcp leistet

tei-mcp liest die ODD-Spezifikation von TEI P5 ein und stellt 16 Tools bereit, die die häufigsten Fragen beantworten, die sich beim Edieren und Kodieren stellen:

Was ist dieses Element? Nachschlagen von Elementen, Klassen, Makros und Modulen nach Namen, ohne Rücksicht auf Groß- und Kleinschreibung und mit Vorschlägen bei Tippfehlern.
Welche Attribute nimmt es? Auflösen der Attribute über die gesamte Klassenhierarchie – zuerst die lokalen, dann der Reihe nach die geerbten.
Was darf hinein? Entfalten von Inhaltsmodellen zu strukturierten Bäumen oder eine flache Liste der zulässigen Kindelemente.
Darf dieses Element hierhin? Prüfen der Eltern-Kind-Verschachtelung oder Nachverfolgen der Erreichbarkeit durch die gesamte Elementhierarchie.
Ist mein Dokument valide? Validieren einer TEI-XML-Datei gegen die Spezifikation: Inhaltsmodelle, Attributwerte, geschlossene Wertelisten, Integrität der Verweise und Warnungen vor veralteten Konstrukten.
Und mein Projektschema? Laden einer ODD-Anpassung, um all das auf die projektspezifische Teilmenge von TEI einzuschränken.

Warum das zählt

Wer in TEI kodiert, schlägt ständig in den Guidelines nach. Erfahrene Encoder haben die gängigen Muster verinnerlicht, aber selbst sie müssen bei selteneren Elementen oder verwickelten Inhaltsmodellen in die Spezifikation schauen. Für KI-Assistenten, denen jedes verinnerlichte Wissen fehlt, ist das Problem gravierender: Sie halluzinieren Markup, das plausibel aussieht und falsch ist.

Mit tei-mcp muss die KI nicht raten. Sie kann die Antwort in der Spezifikation nachschlagen, ehe sie auch nur eine spitze Klammer schreibt. Heraus kommt Markup, das TEI P5 entspricht – oder der ODD-Anpassung Ihres Projekts.

Erste Schritte

Installation von PyPI:

pip install tei-mcp

Anschließend in die Konfiguration Ihres MCP-Clients eintragen:

{
 "mcpServers": {
 "tei": {
 "command": "uvx",
 "args": ["tei-mcp"]
 }
 }
}

Beim ersten Start lädt der Server die TEI-Spezifikation herunter; er arbeitet mit jedem MCP-kompatiblen Client zusammen.

Quellcode und vollständige Dokumentation:

Binärcode begreifen mit dem ITA2-Telegrafen-Emulator

Thu, 13 Feb 2025 00:00:00 +0000

Abstraktes greifbar machen

Dieser ITA2-Emulator ist ein handfestes Lehrmittel: Er macht sichtbar und anfassbar, was sonst abstrakt bleibt, und führt Studierende so an einen Grundbegriff von Informatik und Telekommunikation heran – die Binärdarstellung, also die Frage, wie aus Text ein Muster aus Einsen und Nullen wird. Oft lehren wir das rein abstrakt. Wer aber zusieht, wie die Löcher tatsächlich im Streifen erscheinen, begreift viel leichter, dass ein physisches System digitale Information tragen kann.

ITA2 (Baudot-Murray) Telegraph Type Emulator

Type a word in the input below to see its representation on the ITA2 tape.

Type word:

Historischer Hintergrund: Vom Telegrafen zum Computer

Der ITA2-Code (Internationales Telegrafenalphabet Nr. 2), auch Baudot-Murray-Code genannt, entstand in den 1920er Jahren als Weiterentwicklung des Telegrafencodes, den Émile Baudot in den 1870er Jahren entworfen hatte. Diese frühen Fernmeldesysteme haben die spätere Entwicklung des Computers unmittelbar geprägt:

Das 5-Bit-Schema ist ein frühes Beispiel für Zeichenkodierung
Weil fünf Bit nur 32 Kombinationen zulassen, brauchte es einen Kunstgriff: die Umschaltung zwischen Buchstaben und Ziffern (LETTERS/FIGURES)
Fernschreiber arbeiteten mit diesem System bis weit ins 20. Jahrhundert hinein

Zustandsautomaten im Spiel lernen

Mit der LETTERS/FIGURES-Umschaltung ist der Zustandsautomat wie von selbst im Raum. Beim Ausprobieren entdecken die Studierenden, dass ein und dasselbe Muster je nach Modus ein anderes Zeichen bedeutet – eine handfeste Erfahrung mit zustandsabhängiger Kodierung, die den Boden für anspruchsvollere Begriffe der Informatik bereitet. Das Bitmuster 00011 etwa steht für:

den Buchstaben ‚A‘ im LETTERS-Modus
die Ziffer ‚1‘ im FIGURES-Modus Dass die Bedeutung vom Zustand abhängt, gehört zum Kern dessen, wie Computer mit Daten umgehen.

Übungen für den Unterricht

Einige Vorschläge, wie sich der ITA2-Emulator in die Lehre einbauen lässt:

Code knacken: Lassen Sie Studierende Nachrichten entschlüsseln, die als ITA2-Muster vorliegen
Sparsam kodieren: Erörtern Sie, warum die Umschaltung wichtig war, um Bandbreite zu sparen
Kodierung im Wandel: Stellen Sie dem 5-Bit-Code von ITA2 ASCII (7 Bit) und Unicode gegenüber
Physical Computing: Schlagen Sie die Brücke von diesem historischen System zu heutigen Mikrocontrollern wie dem Arduino

Ein Gewinn für die Zugänglichkeit

Abgesehen vom historischen Reiz kommt dieser Zugang Studierenden mit ganz unterschiedlichen Lernweisen entgegen:

Wer visuell lernt, sieht die Muster
Wer über die Hand lernt, greift unmittelbar in den Kodierungsvorgang ein
Wer begrifflich denkt, kann die mathematische Seite der Informationstheorie erkunden

Zur Implementierung

Der Emulator ist in JavaScript geschrieben und lässt sich ohne Umstände in jede webbasierte Lernplattform einbinden. Der Code ist modular aufgebaut und für verschiedene Unterrichtssituationen anpassbar. Quellcode und Emulator zum Selbstausprobieren finden Sie hier: