TEI |

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:

tei-mcp

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

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

tei-mcp ist ein quelloffener -Server, der KI-Programmierassistenten unmittelbaren Zugriff auf die -Spezifikation verschafft. Statt sich auf angelerntes Trainingswissen zu verlassen – das oft plausibel aussehendes, aber falsches Markup hervorbringt –, kann die KI die Spezifikation in Echtzeit befragen.

Funktionen

Der Server liest das ODD von TEI P5 ein und stellt 16 Tools bereit:

Nachschlagen von Elementen, Klassen, Makros und Modulen nach Namen, ohne Rücksicht auf Groß- und Kleinschreibung und mit Vorschlägen bei Tippfehlern
Attribute auflösen über die gesamte TEI-Klassenhierarchie (lokal + geerbt)
Inhaltsmodelle entfalten zu strukturierten Bäumen, mit Auflösung von Klassen und Makros
Verschachtelung prüfen – direkte Eltern-Kind-Beziehung oder rekursive Erreichbarkeit mit Pfadverfolgung
Dokumente validieren gegen TEI P5: Inhaltsmodelle, Attribute, geschlossene Wertelisten, Integrität der Verweise und Warnungen vor veralteten Konstrukten
Einzelne Elemente validieren für schrittweises Bearbeiten
ODD-Anpassungen laden, um das Schema auf die projektspezifische Teilmenge einzuschränken
Suchen über alle Entitätstypen hinweg mit regulären Ausdrücken

Installation

pip install tei-mcp

Oder direkt starten mit:

uvx tei-mcp

Verwendung

In einen beliebigen MCP-kompatiblen Client eintragen (Claude, Cursor, Windsurf usw.):

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

Quellcode und Dokumentation finden Sie im .

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:

Multi-Saxon

Fri, 28 Mar 2025 00:00:00 +0000

Multi-Saxon: Parallele XSLT-Verarbeitung für große TEI-Korpora

Multi-Saxon schließt eine empfindliche Lücke im Werkzeugkasten der XML-Verarbeitung: Es führt XSLT-2.0- und -3.0-Transformationen parallel aus, an denen LXML (die verbreitete Python-Bibliothek für XML) scheitert. Eigens für große Sammlungen von XML-TEI-Dokumenten gebaut, verkürzt Multi-Saxon die Verarbeitungszeit durch effiziente Parallelisierung beträchtlich.

Hauptmerkmale

Erweiterte XSLT-Unterstützung: Verarbeitet XSLT-2.0- und -3.0-Transformationen, die LXML nicht beherrscht
Parallele Verarbeitung: Verkürzt die Transformationszeit großer Dokumentsammlungen durch Parallelisierung drastisch
TEI-optimiert: Eigens für XML-Dokumente der Text Encoding Initiative (TEI) ausgelegt
Skalierbare Leistung: Verarbeitet Korpora von Hunderten bis Tausenden von Dokumenten effizient
Plattformübergreifend: Läuft unter verschiedenen Betriebssystemen und in verschiedenen Umgebungen

Das Problem, das Multi-Saxon löst

Wer in den Digital Humanities mit TEI arbeitet, stößt regelmäßig auf zwei Hindernisse:

LXML (die gängige Python-Bibliothek zur XML-Verarbeitung) unterstützt nur XSLT 1.0; die weiterentwickelten Möglichkeiten von XSLT 2.0/3.0 bleiben damit außer Reichweite
Große TEI-Korpora Dokument für Dokument zu verarbeiten kann unzumutbar lange dauern

Multi-Saxon räumt beide Hindernisse aus dem Weg: Es nutzt die fortgeschrittenen XSLT-Fähigkeiten von Saxon und verteilt die Arbeit auf mehrere Prozessorkerne, was erhebliche Geschwindigkeitsgewinne bringt.

Implementierung

Multi-Saxon verbindet Python mit dem Java-Prozessor Saxon zu einer leistungsfähigen Transformations-Pipeline:

Nutzt die Java-Bibliothek Saxon für robuste XSLT-2.0/3.0-Verarbeitung
Verteilt die Transformationen per Multiprocessing auf die verfügbaren CPU-Kerne
Verwaltet die Prozessor-Pools so, dass der Durchsatz maximal wird
Bietet eine schlichte Schnittstelle für die Stapelverarbeitung von TEI-Dokumenten

Anwendungsbeispiel

from multi_saxon import MultiSaxon

# Initialize with your XSLT stylesheet
transformer = MultiSaxon("transform.xsl")

# Transform a single document
transformer.transform("input.xml", "output.xml")

# Transform an entire directory in parallel
transformer.transform_directory("input_dir", "output_dir")

Was das für die Digital Humanities bedeutet

Projekten der Digital Humanities mit großen TEI-Dokumentsammlungen eröffnet Multi-Saxon:

Komplexe korpusweite Transformationen, die mit LXML unmöglich wären
Drastisch kürzere Verarbeitungszeiten (auf Mehrkernsystemen oft um den Faktor 5–10)
Anspruchsvollere Analysen dank der fortgeschrittenen Funktionen von XSLT 2.0/3.0
Einfachere Arbeitsabläufe bei der Verarbeitung ganzer Dokumentsammlungen

Quellcode und Dokumentation finden Sie im .

persNamer

Fri, 28 Mar 2025 00:00:00 +0000

persNamer: TEI mit dem Virtual International Authority File verknüpfen

persNamer ist ein spezialisiertes Python-Werkzeug, das Personen-Normdaten aus VIAF (Virtual International Authority File) ohne Umwege in TEI-XML-Dokumente holt. Weil es VIAF-Identifikatoren in fertiges TEI-Markup übersetzt, erspart persNamer einen Großteil der Handarbeit, die strukturierte Personeneinträge in digitalen wissenschaftlichen Editionen sonst verlangen.

Die Mühen der Normdatenpflege in TEI

Digitale wissenschaftliche Editionen müssen historische Personen häufig exakt identifizieren, samt normiertem Namen und Lebensdaten. Wer die Normdaten über ein ganzes Projekt hinweg konsistent halten will, muss:

Personen in historischen Texten erkennen
verlässliche Normdaten zu ihnen finden
korrekt formatierte TEI-Einträge anlegen
dafür sorgen, dass die Verweise im ganzen Projekt einheitlich bleiben

All das geschieht in der Regel von Hand, kostet Zeit und lädt zu Inkonsistenzen ein.

Wie persNamer arbeitet

persNamer automatisiert diesen Ablauf, indem es:

VIAF-Daten abruft: Zu einem gegebenen VIAF-Identifikator holt das Werkzeug per HTTP Content Negotiation die RDF-Daten
die Kerninformationen ausliest: Aus dem RDF zieht es den bevorzugten Namen sowie Geburts- und Sterbedatum
TEI-Markup erzeugt: Es liefert zwei unentbehrliche XML-Schnipsel:
- einen Eintrag für die Normdatei (<person>-Element mit generierter xml:id, <persName>, <birth>, <death> und <idno type="VIAF">)
- ein eigenes Annotations-Tag (<persName> mit einem ref-Attribut, das auf den Normdateneintrag verweist)

Diese zweifache Ausgabe erlaubt es Editorinnen und Editoren, eine zentrale Normdatei zu führen und die Annotations-Tags zugleich bequem in ihre TEI-Texte einzusetzen.

Hauptmerkmale

Einheitliche ID-Vergabe: Erzeugt konsistente XML-IDs nach dem Muster pers-[familyname]-[givenname initial] (z. B. pers-deteligny-c)
RDF-Parsing: Liest mit rdflib Informationen aus verschiedenen RDF-Eigenschaften aus (z. B. rdfs:label, schema:name, viaf:mainHead)
Kommandozeile: Ein Aufruf mit der VIAF-Nummer als einzigem Pflichtargument genügt
Ausführliche Ausgabe: Liefert neben dem fertigen XML detaillierte Angaben zur Verarbeitung

Anwendungsbeispiel

python persNamer.py 314802260

Dieser Befehl erzeugt:

<person xml:id="pers-deteligny-c">
 <persName>Charles deTéligny</persName>
 <birth>1535</birth>
 <death>1572-08-24</death>
 <idno type="VIAF">314802260</idno>
</person>

<persName ref="#pers-deteligny-c">Charles deTéligny</persName>

Einsatz in den Digital Humanities

persNamer ist besonders nützlich für:

digitale wissenschaftliche Editionen, die Normdatenpflege verlangen
TEI-Kodierungsprojekte, in denen historische Persönlichkeiten vorkommen
Linked-Data-Vorhaben, die Dokumente mit Normdatensätzen verknüpfen
die Wahrung der Konsistenz in großen TEI-Korpora
die Vermittlung der Normdatenpflege in Lehrveranstaltungen der Digital Humanities

Implementierung

persNamer ist in Python geschrieben und stützt sich auf:

requests für HTTP-Anfragen
rdflib für das RDF-Parsing
lxml für die XML-Verarbeitung

Quellcode und Dokumentation finden Sie im .