Every data or AI project starts with the same promise: "we already have the data". It's true. It sits in the PLM, the ERP, the MES, Snowflake, SharePoint, and in a few Excel files nobody dares to delete.
And yet, three months later, the project still stumbles over the same questions. What do we call a "part"? A design reference, a purchased item, or a component fitted on a line? Who is the "supplier": the site that forges, or the company that invoices?
There is no shortage of data; what remains is agreeing on what it means.
That is exactly the role of an ontology. This article answers a question we are asked at the start of every project: what is the point of creating an ontology, and why start there?
What an ontology is
An ontology is the explicit description of a business's concepts, the relationships that connect them and the rules that govern them. A part is supplied by a supplier. It is made of a material. That material is smelted in a country. Every statement of this kind becomes a link you can work with in the graph.
In practice, an ontology contains four building blocks.
An ontology differs from a database schema, which describes how data is stored for a given application: it describes what that data means for the business, independently of any application. It also goes further than a glossary, since it connects concepts to one another and makes it possible to reason over them.
Once the ontology is in place, data from the various systems attaches to it. The result is a knowledge graph: your facts, connected according to the meaning your business gives them.
Five uses of an ontology
A common language across business functions
The first value of an ontology appears before a single record has been loaded. To build it, engineering, purchasing, manufacturing and quality have to agree on their concepts. And it is often the first time they do so explicitly.
The exercise surfaces costly misunderstandings. Two teams using the same word for two different things. A rule known to a single expert. A relationship everyone assumes, but that no system carries.
The ontology lets each function keep its own vocabulary: it documents the equivalences (synonyms, local variants) and sets a reference definition, which lets the graph recognise the same object under its different names.
Reconciliation meetings decrease, and a newcomer understands the business by reading the model rather than by questioning the old hands.
Connect systems without replacing them
"Single platform" projects promise to centralise everything. They often end up as multi-year migrations, with a new silo at the end. An ontology takes the opposite path: it leaves data where it is and describes how it connects.
Each source keeps its role. The PLM remains master of design, the ERP of purchasing, the MES of manufacturing. The ontology simply states that the ERP item and the PLM reference are two facets of the same object. It builds the missing bridges between systems each designed for its own purpose.
This is also what makes the approach incremental. You connect a first source, answer a first question, then add the next one. Every source plugged in enriches the same graph instead of creating a new project.
The semantic layer sits on top of what already exists, without touching the systems of record or their owners.
Make AI reliable, and verifiable
This is today's most pressing reason. An LLM plugged directly into enterprise tables guesses what columns mean from their names. On industrial schemas, with their codes and abbreviations, it is often wrong, and confidently so.
The figures bear this out. In a benchmark published in 2023, GPT-4 querying an enterprise SQL database directly got 16.7% of answers right. The same questions asked over a knowledge-graph representation guided by an ontology reached 54.2%, three times more [1]. In a follow-up study, the ontology was also used to detect and correct the LLM's inconsistent queries, raising accuracy to 72.55% [2].
The ontology plays two roles for AI.
The ontology also brings a decisive benefit in industry: proof. When the answer comes from a path through the graph, that path becomes visible: the parts, suppliers and documents that lead to it. Every answer thus becomes justifiable and auditable, and the business expert can challenge it point by point.
AI moves from impressive demo to a tool you can base a decision on.
Answer the questions nobody planned for
A dashboard answers the question it was built for very well. The day purchasing, quality or a programme comes with a question asked from another angle, it goes silent. A new development has to be launched, freezing yet another point of view.
An ontology stores facts and their links, and the angle of analysis is chosen when the question is asked. "Which parts are exposed if this supplier fails?", "Which vehicles are affected by this regulatory change?": both questions traverse the same graph, in two different directions.
The ontology also makes it possible to model what is missing: an absent material certificate becomes an object in the graph, which can be counted, filtered and prioritised. The graph knows exactly where the gaps are, and which ones to fill first.
You move from BI that answers N planned questions to a graph that answers the questions you haven't asked yet.
An asset that grows with the business
In most companies, business knowledge lives in two fragile places: experts' heads and files that age. When the expert leaves, the rule leaves with them. When the file is no longer maintained, it becomes a risk.
The ontology captures this knowledge in an explicit, versioned and shared format. It evolves: when a question reveals a missing concept or relationship, it is added without breaking what exists. The business moves its own representation forward at the pace of its questions.
It also remains the client's property. A well-built ontology is exportable and constitutes a company asset, independent of the tool that produced it.
Every question asked, every source connected, every gap filled enriches the same model. A consultant's report ages in a drawer; an ontology gains value with every use.
Snowflake, Foundry: not all "ontologies" are equal
The word is fashionable, and the major data platforms have all adopted it. But the same word hides very different things. Two examples come up in almost all of our conversations.
Snowflake and its semantic views. Snowflake offers "semantic views": objects that describe, on top of tables, facts, dimensions, metrics, synonyms and join paths [3]. They feed Cortex Analyst, the assistant that translates a question into SQL. It is useful, and genuine progress for conversational BI. Their scope, however, remains that of a semantic layer: centred on tables and aggregates ("what is revenue by region?"), they treat relationships as joins and are limited to data present in Snowflake.
Palantir Foundry and its Ontology. Foundry goes much further. Its Ontology describes object types, link types between them, and action types that modify those objects in a controlled way [4]. It is a true operational ontology, and one of the most advanced on the market. Its limit lies elsewhere: it lives inside Foundry. It relies on data integrated into the platform, is built with its tools and teams, and does not travel elsewhere. Your business model becomes as much an asset of the platform as it is yours.
The question to ask therefore covers three points: what does this ontology model, on which data, and who owns it?
| SnowflakeSemantic views | Palantir FoundryOntology | GraphicientGraphForge | |
|---|---|---|---|
| What is modelled | Metrics, dimensions, joins | Objects, links, actions | Concepts, relationships, interfaces, rules, synonyms |
| Questions served | Aggregates and indicators (text-to-SQL) | Operational applications | Cross-cutting, multi-level questions, with a justifying sub-graph |
| Data scope | Data in Snowflake | Data integrated into Foundry | The client's existing sources, including Snowflake |
| Who builds it | Data teams | Foundry and data teams | Business experts, no-code |
| Portability | Tied to Snowflake | Tied to Foundry | Exportable at any time, owned by the client |
These approaches are not mutually exclusive. At our clients, Graphicient reads data from Snowflake and respects its governance. A semantic view remains very effective for computing an indicator; the ontology connects what no single platform can see on its own.
Why a platform's ontology is not enough
These are quality tools, and their limit comes from their starting point: a platform ontology describes that platform's data. As long as the business fits in a single tool, the gap stays small; in industry, the business always spans several systems.
- 01What isn't in the platform doesn't exist.A Snowflake semantic view only sees Snowflake tables. The Foundry Ontology only sees what has been integrated into Foundry. Yet industrial knowledge is scattered: bills of materials in the PLM, routings in the MES, contracts in the ERP, requirements in documents, rules in Excel files. For the platform's ontology to cover the business, everything must first be moved into it. You end up facing a migration project.
- 02One ontology per platform is one more silo.A large manufacturer runs several data platforms. If each carries its own "ontology", you recreate at the level of meaning the fragmentation you were trying to solve at the level of data. The "part" in Snowflake, the one in Foundry and the one in the PLM become three different objects again, which must be reconciled once more.
- 03They answer the questions that were planned.A semantic view is excellent for a metric defined in advance: a figure by region, by month, by family. As soon as a question crosses several levels, from part to material, from material to country of smelting, from country to programme, the model stops. The LLM then falls back on raw tables and has to guess the joins. That is exactly where accuracy collapses [1].
- 04They return a result, not a line of reasoning.Text-to-SQL returns a number. It doesn't show the path that leads to it, nor the intermediate objects, nor what is missing along the way. For an expert who must validate a decision, or an auditor who must check it, a number without a path is not enough. In a graph, the answer is the path.
- 05They model neither absence nor rules.A missing certificate, an expired qualification, a compliance rule between two concepts: a metrics-oriented semantic layer has no room for these objects. Yet they are what gives a risk analysis or a compliance audit its value.
- 06The model belongs to the platform.It is built with the platform's tools, in its format, often by its teams or by specialists trained on it. Changing platform means rebuilding. And business knowledge stays in the hands of those who master the tool.
In short: a platform's ontology makes that platform smarter. A business ontology makes the company smarter, whatever platforms it uses today and whichever it chooses tomorrow.
The objections we hear, and how we answer them
How to start an ontology on a project
The golden rule: start with a question, not with the exhaustive model. An ontology that tries to describe everything from day one answers nothing for six months.
- 1Pick a question that hurts."If this component becomes non-compliant, which vehicles are affected?" A question that today takes several days to answer, by hand.
- 2List the concepts it crosses.Usually five to ten: part, supplier, material, requirement, vehicle, document.
- 3Name the relationships and rules.With the business experts, not in their place. This is where misunderstandings get resolved.
- 4Connect the existing sources.No migration: the systems' columns are mapped to the ontology's concepts.
- 5Ask the question, then the next one.Each new question reveals a concept or a link to add. The ontology grows through use.
In practice, a first useful ontology is built in a few days, not a few months.
What Graphicient brings
Graphicient built its platform around one conviction: the ontology must belong to the business.
Conclusion
Creating an ontology settles, once and for all, the question every data and AI project ends up asking: what exactly are we talking about?
From there, the rest follows. Business functions share a language. Systems connect without migration. AI answers correctly, and shows why. And every new question enriches an asset that belongs to the company.
Our mission: give business teams the autonomy to structure and exploit their own knowledge, without depending on a data team for every question.
Come with a business question, leave with your first ontology.Contact us →Sources
- [1]Sequeda, Allemang, Jacob — A Benchmark to Understand the Role of Knowledge Graphs on Large Language Model's Accuracy for Question Answering on Enterprise SQL Databases (data.world, November 2023). GPT-4 zero-shot: 16.7% accuracy on direct SQL, 54.2% on the knowledge-graph representation. arxiv.org/abs/2311.07509
- [2]Allemang, Sequeda — Increasing the LLM Accuracy for Question Answering: Ontologies to the Rescue! (May 2024). The ontology is used to detect and repair erroneous queries; accuracy raised to 72.55%. arxiv.org/abs/2405.11706
- [3]Snowflake Documentation — YAML specification for semantic views: schema objects defining business concepts (logical tables, facts, dimensions, metrics) on top of Snowflake tables, used by Cortex Analyst. docs.snowflake.com
- [4]Palantir Documentation — Ontology architecture: the Foundry Ontology as an operational layer defining object types, link types and action types, on top of the assets integrated into the platform. palantir.com/docs