Signs you need an ontology
The symptom is rarely described as a semantic problem. It sounds like this:
- Two dashboards show different revenue numbers and both are "right".
- Sales, finance and support each have their own definition of an active customer.
- Every new data source takes months to integrate because nobody agrees how it maps.
- Your AI assistant answers fluently and gets relationships wrong: the wrong contract, the wrong entity, the wrong version.
- A data catalogue exists, but nobody trusts it.
Adding another pipeline does not fix any of these. It copies the confusion somewhere new. What fixes it is a shared, written model of meaning. If the terms are muddled, start with my explainer on ontology vs knowledge graph vs semantic layer.
The problems I solve
One definition of truth
I run domain workshops with the people who own the business concepts, capture the entities, relationships and rules, and turn them into an ontology that is versioned and reviewed like code.
Joining data that was never designed to join
Entity resolution connects the same customer, patient or supplier across CRM, ERP, documents and legacy systems, with clear rules and confidence scores rather than one-off scripts.
Meaning that reaches every consumer
A semantic layer exposes the model to BI tools, APIs and applications, so a metric is defined once and used everywhere.
AI that understands your business
A knowledge graph gives LLMs structured context. Retrieval can follow relationships, answers can cite facts, and access rules can be enforced at query time. This is the foundation of the GraphRAG systems I build as an AI architect.
My approach
- Pick the questions first. Which decisions, reports or AI use cases must the model support? That keeps the ontology useful rather than academic.
- Model the core domain. A small set of well-defined concepts beats an exhaustive taxonomy nobody maintains.
- Reuse standards where they exist. Industry vocabularies save years of argument. In healthcare that means SNOMED CT, LOINC and RxNorm; in other domains, the relevant public schemas.
- Map sources and resolve entities. Source by source, with data quality checks at the boundaries.
- Choose the right store. RDF and OWL with SPARQL where reasoning and standards matter, a property graph such as Neo4j with Cypher where operational speed matters.
- Serve it. Semantic layer for analytics, APIs for applications, graph retrieval for AI agents.
- Govern it lightly. Ownership, change review and versioning, so the model keeps pace with the business.
What you get
| Deliverable | Purpose |
|---|---|
| Domain ontology and vocabularies | The shared, versioned model of meaning |
| Source mappings and entity resolution rules | How each system feeds the model |
| Knowledge graph | Connected, queryable data organised by the ontology |
| Semantic layer | Consistent metrics for BI and APIs |
| GraphRAG retrieval | Grounded, citable context for LLMs and agents |
| Governance playbook | Who owns what and how changes are made |
How an engagement runs
A first useful ontology usually comes out of three to four weeks of workshops and modelling, often as part of an architecture review. Building the graph, mappings and semantic layer is then a project of a few months, delivered in slices: one domain, one consumer, one measurable win at a time. I work embedded with your data team so the knowledge stays with them.
See the enterprise knowledge graph case study for the shape of a typical engagement.
Common mistakes with ontologies
Modelling the whole world
The most common failure is ambition. A team sets out to model every concept in the enterprise, spends a year in workshops and delivers a beautiful diagram nobody uses. I start with the handful of concepts behind the questions that matter, then grow the model as use cases arrive.
Leaving the business out
An ontology written only by engineers encodes engineering assumptions. The people who own the concepts, such as finance for revenue or clinicians for diagnoses, have to agree the definitions. My workshops are short and focused so senior people actually attend.
No path to production
A model that lives in a modelling tool and never reaches a pipeline, an API or a dashboard has no effect. Every modelling sprint I run ends with something consumed by a real system.
Choosing a graph database before a use case
RDF triple stores and property graphs both work well. Picking one before you know the queries, the reasoning needs and the team's skills leads to awkward workarounds later. I make that choice with the use cases on the table.
No owner after go-live
Businesses change, and so must the model. Without named owners and a light change process, the ontology falls out of date and trust disappears. Governance does not have to be heavy, but it has to exist.
Where knowledge graphs pay off fastest
- Customer 360. One connected view of accounts, contacts, contracts and support history across systems.
- Product and supply data. Parts, suppliers and compliance attributes that must stay consistent across catalogues.
- Clinical and research data. Conditions, drugs and lab results linked through standard vocabularies.
- Enterprise AI assistants. Grounded answers that cite the facts they depend on.
Relevant experience
- Healthcare research data mapped onto the OMOP common data model and standard clinical vocabularies, with OHDSI tooling for reproducible analysis. More in healthcare data architecture.
- Production RAG and agent systems where a domain model made the difference between plausible and correct answers.
- Deep data-modelling experience as a MongoDB Community Leader, including an open MongoDB cookbook and an aggregation pipeline generator.
- Large-scale data platforms, including event-driven systems at more than a million transactions a day.
If semantics is one part of a wider technology agenda, the fractional CTO engagement may suit you better.