Why Ontologies Matter, and the Trap Most Teams Fall Into
Updated: 5 days ago
If you spend enough time around digital twins, enterprise software, or semantic technologies, you’ve probably come across the word “ontology”. You may have seen it used to describe a taxonomy, a domain ontology, a semantic graph, or a technical schema. Those concepts are related, but they’re not interchangeable.
This isn’t merely an exercise in terminology: understanding the distinctions matters once you move from describing a domain to building an application that needs to drive business value.
Taxonomy, Ontology, Semantic Graph, and Schema: What's the Difference?
Let’s start by clarifying the terms. They work together, but they play very different roles in a semantic application.
1) Taxonomy
A taxonomy is an agreed set of terms, often organised in a hierarchy. It's useful, but it doesn't capture the richer relationships, rules, and meaning of an ontology.
2) Domain Ontology
Domain ontologies provide reusable semantic models either for an entire sector (an industry ontology) or for a specific organisation (an enterprise ontology).
Industry ontology
Brick, SAREF, ifcOWL, and RealEstateCore, for example, are industry ontologies that describe concepts and relationships across buildings, equipment, sensors, observations and spaces.
Ontologies like these might describe a piece of equipment, its BMS points, and its relationships to other equipment in a way that can be understood across the building industry.
Enterprise Ontology
An enterprise ontology describes one organisation rather than a whole industry.
Where an industry ontology gives you a shared vocabulary for a whole sector, an enterprise ontology gives you the vocabulary for one company so that every application built for that enterprise describes the same things in the same way. It can be derived from one or more industry ontologies, then narrowed and extended to fit the organisation.
Ontologies like these might describe the types of equipment specific to the business, the organisation’s processes and roles, and its terminology.
3) Application Ontology
An application ontology is the semantic model a specific application needs in order to run: the concepts, relationships, rules and constraints scoped precisely to the job of that application. It’s the model that actually gets deployed, populated, and reasoned over.
4) Semantic Graph
A semantic graph contains the actual entities and relationships described by the application ontology – it's a hydrated ontology, brought to life by populating it with real-world entities and data.
The ontology defines the classes, relationships and rules; hydration supplies the real entities, relationships, and facts of an actual building, plant, or network.
5) Schema
A schema describes how data is structured and stored: fields, types, keys, and other constraints on the shape of a record. It’s necessary for software to function, but it doesn’t tell you what the data means: what kinds of things exist, how they relate and what rules govern those relationships.
The Trap? Not Knowing the Difference Between Domain Ontologies and Application Ontologies
Of those five, taxonomy is just hierarchy, schema is a technical concern, and a semantic graph is what you get once an ontology is populated. The ambiguity that will cost your team time and money is between:
1) the ontologies that describe a domain (whether an industry or an enterprise)
2) the ontologies that make applications work.
A Concrete Example: The Air-Handling Unit
Let’s consider an application designed to manage maintenance in a building and compare industry ontologies for buildings with an application ontology designed to support maintenance workflows.
Building Domain Ontologies and AHUs
An industry ontology describes a domain in general. Brick, BOT, SAREF and the others are built for broad applicability across an entire industry and are not tuned to a specific running application.
Take an air-handling unit in a commercial building. Brick can define what an AHU is in general: what kind of equipment it is, the points associated with it, how it relates to other equipment and locations.
Maintenance Application Ontology and AHUs
For a maintenance application, only a fraction of the Brick model matters, but it also needs things that Brick is missing. The application ontology doesn't need to reproduce everything Brick knows about an AHU; only what the maintenance workflow actually reasons over. For example, from Brick we can use:
AHU-01 serves Zone-03 AHU-01 contains Filter-02 Filter-02 has a condition state AHU-01 has a discharge-air-temperature reading
Additionally, we can add entities and relationships that Brick doesn’t have:
An anomaly from telemetry data related to a BMS point can trigger a maintenance alert
That alert can be associated with a work order
Same AHU. Same industry semantics. A much smaller, more purposeful model, scoped to exactly what one running application needs.
Put simply:
A domain ontology describes an area of knowledge. An application ontology describes what an application needs to deliver business value.
Creating Application Ontologies with Twinit
On Twinit, every application ontology starts from a shared foundation called the Micro Core. It's deliberately small and domain-neutral. The Micro Core provides the common structural foundation that every Twinit application builds from. It is a small set of domain-neutral classes, such as entities, telemetry, events, states and actions, together with the relationships and rules between them, from which any application ontology is composed.
Think of the Micro Core as the grammar, the domain ontology as the dictionary, and the application ontology as the sentences you actually write to get a job done.
An industry ontology is the dictionary a whole sector shares; an enterprise ontology is the house dictionary one company keeps. They are applied differently, as the two patterns below show, but they play the same role: they supply the words. The application ontology is what gets written with them.
Twinit’s data models are flexible and can be built to suit the application. Two patterns cover most cases, and the Micro Core is the base of both.
For an application built to serve many industries, the application ontology sits directly on the Micro Core and carries the operational logic and workflows the software needs. Industry ontologies sit on top as the classification layer: they give the individuals in each project their shared domain meaning, so the same maintenance application can classify equipment against Brick on one project and against a different industry vocabulary on the next, without changing the application beneath.
For an enterprise, the layers invert. The enterprise ontology sits directly on the Micro Core as a shared semantic layer that describes the company’s own assets, sites, processes and terms once. Application ontologies then sit on top, each scoped to its own purpose but all drawing on the same enterprise semantics, so a maintenance application, an energy application and a space application in the same organisation all mean the same thing by “Building 4” and “AHU-01”.
In both patterns the application ontology does more than sit beside the application. Once reviewed and locked, it becomes a contract the rest of the application is built against. When the application is deployed, hydration then supplies the actual AHUs, sensors and other assets at a particular site, turning the generic model into a graph of the real asset environment.
Why This Matters Practically
A shared description of a domain and a running application solve different problems. A domain ontology is a semantic foundation, not a runtime: it has no way to ingest a live sensor reading, bind that reading to an asset, or trigger an alert when a condition changes. It tells you what something is but doesn't run anything.
That's the application ontology's job. It's what actually gets deployed, populated per project, and reasoned over by AI agents. It is the model the application is built from.
Getting this distinction wrong is the pattern behind a fair number of stalled "ontology-driven" initiatives: a team tries to operationalise the domain ontology directly, instead of deriving a scoped application ontology from it.
Why This Matters for AI-Native Digital Twins
An AI agent reasoning about a piece of equipment doesn't just need a reading and an asset ID. It needs to understand what the equipment is, what it connects to and what its measurements mean. That's what graph-aware reasoning means in practice: AI reasoning over known concepts, relationships and rules rather than isolated values.
On Twinit, the same ontology that defines the graph also provides the stable vocabulary against which integrations, workflows and agents operate. When an agent reasons about an asset, it does so within a model whose concepts and relationships have already been defined and governed.
The ontology isn't there to describe the application after it has been built. It is part of what the application is built from.
The Distinction Worth Remembering
If you could only take one sentence from this article, it would be this:
To build apps that drive real business value, define an application ontology scoped to your use case – a domain ontology only tells you what things are, but an application ontology is what an application is actually built from and runs on.
The Micro Core is the foundation in every case; what comes next depends on what you’re building. A cross-industry application puts its application ontology on the Micro Core and classifies with industry ontologies. An enterprise puts its enterprise ontology on the Micro Core and builds application ontologies on top.
Next in our ontologies blog series, we’ll have a post that discusses how we designed the application ontology for our open-source Asset Intelligence App Template. After that, we’ll have a post that shows how the Ontology Studio helps you take an application ontology from defined to deployed. For the full analysis, download our whitepaper on The Ontology as a Seed of The Application at the link below.
If you're working through how an existing industry ontology translates into a deployable digital twin application, get in touch with us and discuss your strategy or sign up for our email list to get notified!
