Ein Arbeitswortschatz für das Pre-Construction-Büro (v0.4)

Es gibt eine Angewohnheit, wenn man genug Jour-fixe-Protokolle gelesen hat, nach einem Bleistift zu greifen. Nicht zum Schreiben — zum Unterstreichen. Dieselben Wörter kehren wieder: Prüfgegenstand, Frist, Aufgabe, Gewerk, Projektsteuerer. Sie sehen aus wie gewöhnliche deutsche Substantive, sind es aber nicht. In einem Pre-Construction-Büro sind sie Rollen in einer kleinen, dichten Grammatik — näher am Protokoll einer alten Zunft als an irgendetwas in einem Wörterbuch. Die Aufgabe einer Ontologie ist es, diese Grammatik ernst zu nehmen: den Wörtern formale Typen zu geben, die Beziehungen zwischen ihnen zu fixieren und die höfliche Fiktion zurückzuweisen, ein Absatz Prosa könne ein Modell ersetzen.¹

Diese Notiz ist die vierte Iteration dieser Arbeit. v0.1 war eine Whiteboard-Skizze an einem Nachmittag Ende 2024. v0.3 — intern letzten Dezember veröffentlicht — überlebte acht Monate Kontakt mit echten Protokollen, bevor uns drei bestimmte Edge Cases unmissverständlich klarmachten, dass wir die Grenze falsch gezogen hatten. v0.4 zieht sie neu.

Was wir modellieren

Der Korpus ist auf den ersten Blick irreführend langweilig: das tägliche Arbeitsergebnis eines Projektsteuerer-Büros — Jour-fixe-Protokolle, Vergabevermerke, Terminpläne, Pflichtenhefte, Bemusterungsprotokolle und die Bauprotokolle, die von der Baustelle zurückkommen. Etwa vierzigtausend Dokumente, jeweils zwei bis zwanzig Seiten, größtenteils in einem flachgeschliffenen bürokratischen Deutsch verfasst, das mehr mit juristischen Schriftsätzen gemeinsam hat als mit Architekturprosa.

Was sie interessant macht, ist nicht ihre Sprache, sondern ihre Verpflichtungsstruktur. Fast jeder Absatz erzeugt, überträgt oder erledigt eine Pflicht. Ein zu prüfender Gegenstand (Prüfgegenstand) taucht auf, wird einem Gewerk zugewiesen (Gewerk), erhält eine Frist (Frist) und wird später entweder abgehakt oder eskaliert. Den Fluss dieser Verpflichtungen über Dokumente hinweg zu verfolgen — vom Pre-Con-Jour-fixe bis ins Bauprotokoll und zurück — ist das ganze Spiel.

ABB. 01 Der sieben-Knoten-Kern von v0.4. Kanten sind typisiert und (mit einer Ausnahme, Mangel → Document) gerichtet. Subtypen von Aufgabe — Behebung, Prüfung, Abnahme — sind hier zur Lesbarkeit zu einem Knoten zusammengefasst. ▶ Sehen Sie eine Bauprotokoll-Zeile live in dieses Schema parsen.

Was an v0.3 gescheitert ist

v0.3 war eine fünfzehnklassige Taxonomie mit einem sauberen Vererbungsbaum. Sie war zwei Monate lang unser Stolz und sechs Monate lang unser Feind. Drei Dinge haben sie zerlegt.

1. Die Fiktion einer einzigen Frist. Eine Frist in freier Wildbahn ist selten ein Datum. Sie ist ein kleines Objekt mit drei plausiblen Lesarten: die Kalenderfrist, die vertraglich verbindliche Frist und die Frist, die der Projektsteuerer eigentlich meint, wenn er „bis nächste Woche" ins Jour-fixe-Protokoll schreibt. v0.3 hat alle drei in ein einziges datetime-Feld gestopft. v0.4 macht Frist zu einer eigenständigen Entität mit eigener Provenienz.²

2. Zusammengesetzte Gewerke. Ein Gewerk ist kein Blatt. Bei fast jedem vierten Mangel sind zwei Gewerke beteiligt, die sich an einer Schnittstelle gegenseitig die Schuld geben — das klassische Beispiel ist TGA-Planer und Rohbau, die sich um eine Schachtdurchführung streiten. v0.3 erzwang eine Zuordnung pro Mangel. v0.4 erlaubt einem Mangel, an eine beliebige Menge von Gewerken zu hängen, mit einer typisierten responsibility-Kante, die zwischen verursacht, beteiligt und betroffen unterscheidet.

3. Dokumente sind keine Container. v0.3 modellierte ein Jour-fixe-Protokoll als einen Sack Absätze mit einem Datumsstempel. Nützlich, bis man feststellt, dass zehn Prozent aller offenen Punkte im Korpus zuerst in einer E-Mail oder einem Vergabevermerk auftauchen und erst später in ein Protokoll übernommen werden. Der Dokumentengraph ist ein Netz, kein Baum, und die Entitäten schweben darüber.

„Die meisten Ontologie-Fehler sind keine Taxonomie-Fehler. Es sind Kardinalitäts-Fehler — die Fiktion, dass etwas in der Einzahl existiert, wo in Wahrheit mehrere Versionen davon im Fluss sind, nur lose miteinander abgestimmt." — Arbeitsnotiz, v0.3-Retrospektive, Feb 2026

Der v0.4-Kontrakt

Das Schema ist absichtlich klein. Sieben Kerntypen, vierzehn Kantenlabels und eine Handvoll literal-typisierter Eigenschaften. Die Entscheidungsregel, bei der wir nach mehreren Fehlstarts gelandet sind, lautet: Wenn ein Ding jemals Subjekt oder Objekt eines Satzes in einem Projektsteuerer-Protokoll sein kann, bekommt es einen Knoten; wenn es nur ein Modifikator ist, bleibt es eine Eigenschaft. Diese Regel klingt im Nachhinein offensichtlich. War sie nicht — sie hat sechs Monate und drei Ontologen gekostet, die in einem Münchner Kellerbüro gestritten haben.

Was folgt, ist die kanonische Darstellung des Schemas. Wir nutzen eine reduzierte Turtle-artige Notation; das produktive Schema liegt in OWL mit einer SHACL-Validierungsschicht.

:Project        a owl:Class ;
                rdfs:label "Bauprojekt" .
:Document       a owl:Class ;
                rdfs:subClassOf :Artefact .
:Mangel         a owl:Class ;
                rdfs:label "Defect / Beanstandung" .
:Aufgabe        a owl:Class ;
                rdfs:label "Task / Pflicht" ;
                owl:disjointWith :Mangel .
:Frist          a owl:Class ;
                rdfs:label "Deadline (typed)" .
:Gewerk         a owl:Class ;
                rdfs:label "Trade / Discipline" .
:Agent          a owl:Class ;
                rdfs:subClassOf foaf:Agent .

:contains       a owl:ObjectProperty ;
                rdfs:domain :Project ; rdfs:range :Document .
:recorded_in    a owl:ObjectProperty ;
                rdfs:domain :Mangel  ; rdfs:range :Document .
:assigned_to    a owl:ObjectProperty ;
                rdfs:domain :Aufgabe ; rdfs:range :Gewerk .
:due            a owl:ObjectProperty ;
                rdfs:domain :Aufgabe ; rdfs:range :Frist .

Zwei Dinge sind wichtig. Erstens: :Mangel und :Aufgabe sind disjunkt. Ein Mangel ist keine Aufgabe; eine Aufgabe ist die Pflicht, einen Mangel zu beheben. Diese beiden zu vermischen — wie es die meisten Standard-„Construction"-Ontologien tun — ist der einzelne teuerste Modellierungsfehler, den wir gemacht haben.³ Zweitens: :Frist ist eine Klasse, kein Literal. Sie trägt Provenienz: wer das Datum geschrieben hat, wann und gegen welchen Kalender.

Ein kleines, echtes Beispiel

Betrachten wir einen Absatz aus einem realen Jour-fixe-Protokoll eines Projektsteuerers, leicht redigiert:

„BV Riemerschmidt, JF-14, 14.04.2026 — TOP 4.2: Im 3. OG ist die Brandschottung im Bereich der Lüftungstrasse Achse C/4 in der Ausführungsplanung nicht eindeutig festgelegt. Klärung durch TGA-Planer in Abstimmung mit Rohbau, Vorlage bis KW 18."

v0.3 würde das als einen einzigen Mangel rendern mit einer string-typisierten deadline = „bis KW 18" und einem assignee = „TGA-Planer". v0.4 rendert es als kleinen Subgraphen: einen Prüfgegenstand-Knoten („Brandschottung Achse C/4"), aufgenommen im Jour-fixe-Protokoll JF-14 vom 14. April 2026, verknüpft mit zwei Gewerken über unterschiedliche responsibility-Kanten (verursacht: TGA-Planer, beteiligt: Rohbau), erzeugt eine einzelne Aufgabe („Klärung Brandschottung, Vorlage Detail") mit einer Frist-Entität, die sowohl die Kalender-Lesart (KW 18 / 2026, Ende 03.05.2026) als auch das textliche Original („bis KW 18") trägt.

Das sind mehr Knoten als bei v0.3. Es ist auch, gemessen an jeder Retrieval-Metrik, die uns wichtig ist, dramatisch nützlicher.⁴

Was wir nicht gelöst haben

Drei bekannte Unbekannte, in der Reihenfolge, in der sie uns nachts wachhalten:

Negation über Dokumente hinweg. „Der Mangel besteht nicht mehr" in Protokoll N+1 ist keine Löschung des Mangel-Knotens aus Protokoll N. Es ist ein Zustandsübergang. v0.4 hat eine zeitliche Schicht obendrauf, aber die Schicht ist brüchig.
Implizite Verantwortliche. Etwa fünfzehn Prozent der Mängel in unserem Korpus haben kein explizit zugewiesenes Gewerk. Ein Mensch liest den Kontext und weiß es. Das Modell rät derzeit.
Übertragung zwischen Projekten. Zwei Projekte mit demselben Projektsteuerer verwenden leicht unterschiedliche Vokabularien für dieselbe Klasse von offenen Punkten. Wir haben keinen formalen Mechanismus, um sie auszurichten; wir machen das aktuell von Hand.

v0.5 steht bereits am Whiteboard. Sie wird kleiner sein, wieder, in den Teilen, die zählen, und größer in den Teilen, die wir lieber nicht brauchen würden.

— V. T., München, 22. April 2026.

Anmerkungen

Die klassische Referenz hier ist Gruber, „A translation approach to portable ontologies" (1993), das näherliegende und weniger zitierte Vorbild ist jedoch die Arbeit von Smith & Welty zur praktischen Ontologie-Konstruktion — insbesondere die Warnung, dass auf Dokumenten trainierte Taxonomien dazu neigen, eher die Höflichkeit der Dokumente als deren Inhalt zu rekapitulieren.
Das ist der Bug, der die Neuentwicklung ausgelöst hat. Bei der Korpusabfrage „alle Mängel mit Fristen in KW 18" lieferte v0.3 fünf Treffer, v0.4 achtunddreißig. Die anderen dreiunddreißig fehlten nicht — sie waren unter Zeichenkettenfragmenten wie „Mitte Mai" und „vor Pfingsten" abgelegt.
Wir haben die Vermischung von einer der größeren BIM-Ontologien geerbt (die wir nicht namentlich nennen) und vier Monate gebraucht, um sie wieder zu entwirren.
Die F1-Metrik für Multi-Hop-Retrieval steigt auf unserem internen Benchmark von 0,41 auf 0,69. Wir veröffentlichen Benchmark und Eval-Harness in einer separaten Notiz.