Beyond the BIM File, Part 2: When data talks to each other

In the last blog post we explored why we need to move away from files and towards data. But that's only part of the story: just because our granular data is accessible doesn't necessarily mean it provides any real value.

Today was another rainy Sunday, so I used my time at the gym to catch up on a few podcasts and once again ended up listening to TRXL Podcast by Evan Troxel. In this episode, various experts from the AEC technology industry discussed the value of our historical project data and how we could make better use of it in the future.
Somewhere between the rowing machine and the leg press, one thought really stuck with me: We're pretty good at documenting what we did, but not nearly as good at documenting why we did it. And this is exactly where knowledge graphs, ontologies, and the importance of context come into play.

Data Is Not the Same as Knowledge

Think about how many projects your company has worked on over the past 10 or 20 years. How many design decisions were made, details developed, and problems solved? Ideally, every new project should benefit from all that experience. In practice, however, we often find ourselves solving the same problems over and over again, even though someone else in the company might have found the perfect solution years ago.

Marty Rozmanith from Skema makes an interesting comparison with the legal profession in the podcast. For lawyers, past cases are an important source of knowledge they can draw on throughout their careers - anyone who's watched Suits, Boston Legal, or pretty much any other legal drama knows this. So why doesn't it work the same way in architecture?

Of course, we reuse existing details, families, and templates. But this usually depends on someone knowing where to find them and, ideally, remembering the circumstances in which they were originally created. Because when we reuse a detail from a previous project, we're often missing one crucial piece of information: Why was it done exactly that way?
Maybe there were specific client requirements, unusual constraints, or problems during construction that led to that particular solution. Without this knowledge, we can copy the result, but we can't necessarily understand the reasoning behind it.

And that can be quite problematic, because a solution that worked perfectly in one project might not be suitable for the next one.

Context: The missing Dimension in AEC

Let's take a facade connection detail as an example. We have a detail that contains all the geometric information and is properly linked to the relevant materials and building components.
What we don't see, however, is that this connection was originally developed to meet a specific fire safety requirement, had to be modified several times during construction, and later caused problems with sealing. All this information might even exist digitally - somewhere in meeting minutes, issues, emails, or construction documentation - but it's not connected. So when we look at the detail alone, we're missing a huge part of the context that would be essential for reusing it.

Sasha Crotty from Autodesk talks about the importance of documenting not just the decision itself, but also the circumstances that led to it. I find this particularly interesting because it changes the way we think about BIM data: It's no longer just about objects and their properties, but increasingly about requirements, decisions, events, and the relationships between them.

The real value of information often lies not in an individual data point, but in how it relates to other information.

But how can we describe these relationships in a way that makes sense not just to us humans, but also to machines?

Ontologies: An Old Friend from the BIM World

This brings us to a term that's popping up more and more frequently: ontologies. An ontology describes the concepts within a particular domain, their properties, and the possible relationships between them. It provides a common semantic foundation that allows information to be interpreted and connected. This might sound a bit abstract at first, but for those of us working with BIM, the underlying concept isn't actually that new. After all, we've been working with a semantically defined data schema through IFC for years, and it already represents many of these concepts.

IFC doesn't just define object classes such as IfcWall, IfcDoor or IfcSpace.It also describes their properties and how they can relate to each other. For example, IfcRelContainedInSpatialStructure allows building elements to be assigned to a spatial structure, while IfcRelDefinesByProperties establishes relationships between objects and their property definitions.
This gives us a common foundation for interpreting building information independently of the software used to create it.

Technically speaking, however, IFC is primarily a data schema defined in EXPRESS, rather than an ontology in the strict sense.
But there's also ifcOWL , a formal representation of the IFC schema in the Web Ontology Language (OWL), published by buildingSMART. OWL allows us to describe information through interconnected statements. In a simplified representation, such statements consist of three parts: a subject, a predicate, and an object. For example, we could describe that a particular building element belongs to a specific floor.

And if that was a bit too much IFC for you, here's another fun example (although it's not exactly less nerdy 😅): The entire Star Wars universe, including characters, locations, events, and their relationships, documented in OWL.

Why is this interesting? Because it gives us a foundation for using the semantics of our BIM data beyond traditional BIM applications and connecting them with other knowledge domains.

Knowledge Graphs: When Relationships Become a Network

A knowledge graph describes the relationships between individual data points. These could be objects, events, documents, and much more. Let's look at a simple example.

• Our IFC schema defines what a door is, which properties it can have, and how it relates to other elements.
• Now imagine we have a specific door, D-104, located on the ground floor of a hospital.

So far, IFC can represent all this information perfectly well. But what if we also want to document that this door was modified because of a specific client requirement, that the change was discussed in a coordination issue, and that the final decision was recorded in meeting minutes? Of course, IFC can also represent references to documents, classifications, and other information. However, in our everyday workflows, many of these connections are created outside the actual model.

A knowledge graph could connect all this information, even if it remains stored in different systems. What matters is that the relationships between these pieces of information are clearly defined and traceable. Suddenly, instead of just searching for a particular door, we could ask something like:

Which doors in our previous hospital projects were modified because of similar requirements, what solutions were chosen, and what did we learn from them?

That's quite a big difference compared to a traditional search for building elements or parameters.

And this is where I see the real potential of knowledge graphs: They allow us to connect existing information across the boundaries of individual models, projects, and applications.

Why this is becoming so interesting for AI

LLMs have become remarkably good at working with unstructured information. They can analyze documents, generate summaries, or extract relevant content from extensive project archives.
For our industry, this could eventually mean that instead of simply searching through historical project data, we could actually learn from the experiences of previous projects. However, that doesn't automatically mean AI correctly understands the relationships between all this information.

AI can attempt to infer relationships from existing data, but those relationships need to remain clearly identifiable as assumptions and must be verifiable. Especially when it comes to safety-critical design decisions, it makes a huge difference whether something has actually been documented or simply sounds plausible.

What does this now mean for our current workflows?

In the podcast, Theodoros Galanos makes a point that I find particularly interesting: Instead of focusing exclusively on cleaning up our historical data, we should also improve the processes through which new information is created. Because as long as our workflows don't capture important relationships in the first place, we'll keep running into the same problem.

Randall Stevens gives a great example from everyday design practice: When an experienced architect corrects a detail, usually only the actual change gets documented. The reason behind that change, however, often remains undocumented. But what if we could capture that reasoning directly while making the change? Maybe even through a simple voice input that could then be automatically structured and linked to the corresponding decision.

With today's AI technologies, parts of such a workflow are certainly conceivable. That doesn't mean we've already solved the challenge of reliably assigning and interpreting this information automatically. What I find particularly exciting is the potential to move beyond the boundaries of individual projects and disciplines and make connections visible that would otherwise get lost.

With every completed project, a company should gain not just more references, but also more knowledge. And that knowledge shouldn't disappear just because the people involved leave the company or move on to the next project.

Perhaps this is the crucial step from the digital model to the digital enterprise: Connecting not just our data, but also our experiences.

I'd be curious to hear your thoughts on this. Are you already documenting the reasoning behind your design decisions, or perhaps even exploring knowledge graphs and semantic data models?

I'd love to hear about your experiences in the comments - and whether you actually enjoy these longer blog posts! 🤓

AI Disclaimer: I use Gemini Notebook, ChatGPT, and Claude for research and brainstorming, as well as for creating graphics, final proofreading, and English translations. The ideas for my articles, however, usually come to me while exercising, and the actual writing happens on Sundays with a coffee on the couch! 🤓  🤓