Beyond the BIM File, Teil 2: Wenn Daten miteinander sprechen

Im letzten Blogpost haben wir uns damit beschäftigt, warum wir uns weg von Dateien hin zu Daten bewegen müssen. Doch damit ist es noch lange nicht getan: nur weil unsere granularen Daten zugänglich sind, bedeutet das noch lange nicht, dass sie uns wirklich Mehrwert bitten.

Heute war mal wieder ein verregneter Sonntag und ich habe die Zeit im Fitness Studio dazu genutzt, ein paar Podcasts zu hören – und bin mal wieder beim TRXL-Podcast von Evan Troxel hängen geblieben, in dem verschiedene Experten aus der AEC-Technologiebranche darüber sprechen, welchen Wert unsere historischen Projektdaten haben und wie wir diesen zukünftig besser nutzen können.
Zwischen der Rudermaschine und der Beinpresse ist mir besonders ein Gedanke hängen geblieben: Wir dokumentieren ziemlich gut, was wir gemacht haben, aber kaum, warum wir es gemacht haben. Und genau hier kommen für mich Knowledge Graphs, Ontologien und die Bedeutung von Kontext ins Spiel.

Daten sind noch lange kein Wissen

Überlegt einmal, wie viele Projekte euer Unternehmen in den letzten 10 oder 20 Jahren bearbeitet hat. Wie viele Planungsentscheidungen getroffen, Details entwickelt und Probleme gelöst wurden. Eigentlich müsste jedes neue Projekt von diesen Erfahrungen profitieren. In der Praxis ist es allerdings häufig so, dass wir immer wieder dieselben Probleme lösen, obwohl jemand anderes im Unternehmen die passende Lösung vielleicht schon längst gefunden hat.

Marty Rozmanith von Skema zieht im Podcast einen interessanten Vergleich mit der Rechtsbranche. Für Anwälte sind historische Fälle eine wichtige Wissensgrundlage, auf die sie während ihrer gesamten Karriere zurückgreifen können – jeder Fan von Suits, Boston Legal oder anderen Anwaltsserien weiß das. Warum funktioniert das in der Architektur nicht genauso?

Natürlich verwenden wir bestehende Details, Familien oder Vorlagen wieder. Allerdings ist deren Nutzung meistens darauf beschränkt, dass jemand weiß, wo sie zu finden sind, und idealerweise auch noch in Erinnerung hat, unter welchen Bedingungen sie entstanden sind. Denn wenn wir ein Detail aus einem früheren Projekt übernehmen, fehlt uns häufig eine entscheidende Information: Warum wurde es genau so ausgeführt?
Vielleicht gab es spezielle Anforderungen des Auftraggebers, besondere Randbedingungen oder Probleme während der Ausführung, die zu dieser Lösung geführt haben. Ohne dieses Wissen können wir zwar das Ergebnis kopieren, aber nicht unbedingt die dahinterliegende Entscheidung nachvollziehen.

Und das kann durchaus problematisch sein, denn eine Lösung, die in einem Projekt hervorragend funktioniert hat, muss nicht zwangsläufig auch für das nächste Projekt geeignet sein.

Kontext: Die fehlende Dimension in AEC

Nehmen wir als Beispiel einen Fassadenanschluss: Wir haben ein Detail, das alle geometrischen Informationen enthält und sauber mit den zugehörigen Materialien und Bauteilen verknüpft ist.
Was wir allerdings nicht sehen, ist, dass dieser Anschluss ursprünglich aufgrund einer speziellen Brandschutzanforderung entwickelt wurde, während der Ausführung mehrmals angepasst werden musste und später zu Problemen bei der Abdichtung geführt hat. All diese Informationen existieren möglicherweise sogar digital – irgendwo in Besprechungsprotokollen, Issues, E-Mails oder Baudokumentationen – aber sie sind nicht miteinander verbunden. Wenn wir nun nur das Detail betrachten, fehlt uns also ein großer Teil des Kontexts, der für die Wiederverwendung entscheidend wäre.

Sasha Crotty von Autodesk spricht im Podcast darüber, wie wichtig es ist, nicht nur die eigentliche Entscheidung zu dokumentieren, sondern auch die Umstände, die dazu geführt haben. Ich finde diesen Gedanken besonders spannend, denn damit verändert sich auch die Art, wie wir über BIM-Daten nachdenken: Es geht nicht mehr nur um Objekte und deren Eigenschaften, sondern zunehmend auch um Anforderungen, Entscheidungen, Ereignisse und die Beziehungen dazwischen.

Die eigentliche Information liegt dann oft nicht mehr im einzelnen Datenpunkt, sondern in seinem Zusammenhang mit anderen Informationen.

Doch wie können wir solche Zusammenhänge überhaupt so beschreiben, dass sie nicht nur für uns Menschen, sondern auch für Maschinen verständlich sind?

Ontologien: Ein alter Bekannter aus der BIM-Welt

Damit sind wir bei einem Begriff, der aktuell immer häufiger auftaucht: Ontologien. Eine Ontologie beschreibt die Konzepte einer bestimmten Domäne, ihre Eigenschaften und die möglichen Beziehungen zwischen ihnen. Sie schafft damit eine gemeinsame semantische Grundlage, auf deren Basis Informationen interpretiert und miteinander verknüpft werden können. Das klingt zunächst etwas abstrakt, doch für uns in der BIM-Welt ist das Prinzip eigentlich gar nicht so neu: Denn mit IFC arbeiten wir bereits seit Jahren mit einem semantisch definierten Datenschema, das viele dieser Konzepte abbildet.

IFC definiert nicht nur Objektklassen wie IfcWall, IfcDoor oder IfcSpace, sondern beschreibt auch deren Eigenschaften und mögliche Beziehungen zueinander. Über IfcRelContainedInSpatialStructure können beispielsweise Bauteile einer räumlichen Struktur zugeordnet werden. Mit IfcRelDefinesByProperties werden Beziehungen zwischen Objekten und Eigenschaftsdefinitionen hergestellt.
Damit stellt IFC eine gemeinsame Grundlage bereit, um Bauwerksinformationen unabhängig von der jeweiligen Software zu interpretieren.

Technisch gesehen ist IFC allerdings zunächst ein in EXPRESS definiertes Datenschema und keine Ontologie im engeren Sinne.
Mit ifcOWL gibt es aber auch eine formale Repräsentation des IFC-Schemas in der Web Ontology Language (OWL), die von buildingSMART veröffentlicht wurde. OWL ermöglicht es, Informationen als miteinander verknüpfte Aussagen zu beschreiben. Eine solche Aussage besteht vereinfacht aus drei Teilen: Subjekt, Prädikat und Objekt. Beispielsweise könnte beschrieben werden, dass ein bestimmtes Bauteil zu einem bestimmten Geschoss gehört.

Und falls dir das jetzt zu IFC-lastig war, hier ein anderes schönes Beispiel (wenn auch nicht weniger nerdy 😅): Das gesamte Star Wars Universum inkl. Charaktere, Orte, Ereignisse und ihre Beziehungen als OWL dokumentiert.

Warum ist das interessant? Weil wir damit eine Grundlage erhalten, um die Semantik unserer BIM-Daten auch außerhalb klassischer BIM-Anwendungen zu verwenden und mit anderen Wissensdomänen zu verknüpfen.

Knowledge Graphs: Wenn aus Beziehungen ein Netzwerk wird

Ein Knowledge Graph beschreibt die Beziehungen zwischen einzelnen Datenpunkten – diese können Objekte, Ereignisse, Dokumente, etc. sein. Schauen wir uns ein einfaches Beispiel an:

• In unserem IFC-Schema ist definiert, was eine Tür ist, welche Eigenschaften sie besitzen kann und wie sie mit anderen Elementen in Beziehung steht.
• In einem konkreten Projekt haben wir nun die Tür D-104, die sich im Erdgeschoss eines Krankenhauses befindet.

Bis hierhin können wir diese Informationen bereits sehr gut mit IFC abbilden. Was passiert aber, wenn wir zusätzlich dokumentieren möchten, dass diese Tür aufgrund einer bestimmten Anforderung des Auftraggebers angepasst wurde, die Änderung in einem Koordinations-Issue diskutiert wurde und die Entscheidung in einem Besprechungsprotokoll festgehalten ist?Natürlich kann IFC auch Referenzen auf Dokumente, Klassifikationen und andere Informationen abbilden. In unseren alltäglichen Workflows entstehen viele dieser Zusammenhänge allerdings außerhalb des eigentlichen Modells.

Ein Knowledge Graph könnte all diese Informationen miteinander verbinden: Die Informationen können dabei weiterhin in unterschiedlichen Systemen liegen. Entscheidend ist, dass die Beziehungen zwischen ihnen eindeutig beschrieben und nachvollziehbar sind. Plötzlich können wir nicht mehr nur nach einer bestimmten Tür suchen, sondern beispielsweise fragen:

Welche Türen wurden in unseren vergangenen Krankenhausprojekten aufgrund ähnlicher Anforderungen angepasst, welche Lösungen wurden gewählt und welche Erfahrungen haben wir damit gemacht?

Das ist ein ziemlich großer Unterschied zur klassischen Suche nach Bauteilen oder Parametern.

Und genau hier liegt das eigentliche Potenzial von Knowledge Graphs: Wir können vorhandene Informationen über die Grenzen einzelner Modelle, Projekte und Anwendungen hinweg miteinander in Beziehung setzen.

Warum das gerade für AI so interessant wird

LLMs können inzwischen erstaunlich gut mit unstrukturierten Informationen umgehen und beispielsweise Dokumente analysieren, Zusammenfassungen erstellen oder relevante Inhalte aus umfangreichen Projektarchiven extrahieren.
Für unsere Branche könnte das langfristig bedeuten, dass wir nicht nur historische Projektdaten durchsuchen, sondern gezielt aus den Erfahrungen vergangener Projekte lernen können. Das bedeutet allerdings nicht automatisch, dass sie die Zusammenhänge zwischen diesen Informationen korrekt verstehen.

Eine AI kann versuchen, Beziehungen aus vorhandenen Daten abzuleiten. Diese müssen dann allerdings als Annahmen erkennbar und überprüfbar bleiben. Gerade bei sicherheitsrelevanten Planungsentscheidungen ist es schließlich entscheidend, ob eine Information tatsächlich dokumentiert wurde oder lediglich plausibel erscheint.

Was bedeutet das nun für unsere heutigen Workflows?

Im Podcast spricht Theodoros Galanos einen Punkt an, den ich besonders interessant finde: Anstatt ausschließlich zu versuchen, unsere historischen Daten nachträglich zu bereinigen, sollten wir vor allem die Prozesse verbessern, durch die neue Informationen entstehen. Denn solange unsere Workflows wichtige Zusammenhänge gar nicht erst dokumentieren, werden wir immer wieder vor demselben Problem stehen.

Randall Stevens bringt dafür ein schönes Beispiel aus dem Planungsalltag: Wenn ein erfahrener Architekt ein Detail korrigiert, wird meistens nur die eigentliche Änderung festgehalten. Warum er diese Änderung vorgenommen hat, bleibt dagegen häufig undokumentiert. Was wäre aber, wenn wir diese Begründung direkt während der Bearbeitung erfassen könnten? Vielleicht sogar über eine einfache Spracheingabe, die anschließend automatisch strukturiert und der entsprechenden Entscheidung zugeordnet wird.

Mit heutigen AI-Technologien sind Teile eines solchen Workflows technisch durchaus vorstellbar. Das bedeutet allerdings nicht, dass die automatische Zuordnung und Interpretation bereits zuverlässig gelöst wäre. Spannend wird es dort, wo wir die Grenzen einzelner Projekte und Disziplinen überschreiten und Zusammenhänge sichtbar machen möchten, die bisher häufig verloren gehen.

Eigentlich besitzt jedes Unternehmen mit jedem abgeschlossenen Projekt nicht nur mehr Referenzen, sondern auch mehr Wissen. Und dieses Wissen sollte nicht verschwinden, sobald die verantwortlichen Mitarbeiter das Unternehmen verlassen oder das nächste Projekt beginnt.

Vielleicht ist das der entscheidende Schritt vom digitalen Modell zum digitalen Unternehmen: Nicht nur unsere Daten miteinander zu verbinden, sondern auch unsere Erfahrungen.

Mich würde interessieren, wie ihr dieses Thema seht. Dokumentiert ihr bereits die Hintergründe eurer Planungsentscheidungen oder beschäftigt ihr euch vielleicht sogar schon mit Knowledge Graphs und semantischen Datenmodellen?

Ich freue mich auf eure Erfahrungen und Kommentare – und auch ob ihr diese langen Blogbeiträge überhaupt spannend findet? 🤓

AI Disclaimer: Ich nutze Gemini Notebook, ChatGPT und Claude für Recherche und Brainstorming, sowie für die Erstellung von Grafiken, die finale Korrektur und die englische Übersetzung. Die Ideen für meine Artikel kommen allerdings meistens beim Sport und werden Sonntags beim Kaffee auf dem Sofa geschrieben!  🤓