Vice President · TheGreyMatter.ai
In brief
An ontology defines meaning, a knowledge graph connects entities and relationships, and a metrics semantic layer makes measures consistently queryable. They can work together, but they solve different problems.
Key takeaways
- Start with the operating question that is failing.
- Separate definitions, connected records, and metric calculations.
- Test the result with ambiguous identities, revised definitions, and restricted access.
A leadership team asks why revenue changed. One person proposes an ontology, another a knowledge graph, and another a semantic layer. Those answers may address different parts of the same problem. Before selecting a platform, identify whether the uncertainty concerns what a term means, which records belong together, or how a number is calculated. This comparison uses practical working definitions rather than treating overlapping industry labels as universal product categories.
What does each layer actually do?
A business ontology describes the concepts and relationships that matter in a domain. W3C's OWL 2 provides a formal ontology language with classes, properties, individuals, and data values. An enterprise can begin with a simpler documented business vocabulary; adopting an ontology does not automatically require OWL or a particular database.
A knowledge graph represents connected entities and relationships. RDF is one approach: its subject, predicate, and object statements form a graph. A metrics semantic layer serves a different practical purpose. For example, dbt centralizes metric definitions and handles joins so applications can query measures consistently. These boundaries overlap in real products, so evaluate the actual behavior.
| Layer | Question it helps answer | Example |
|---|---|---|
| Business ontology | What do the concepts and relationships mean? | A customer has contracts, an account owner, and a legal entity. |
| Knowledge graph | Which actual entities and records are connected? | Customer A holds contract B, delivered by company C. |
| Metrics semantic layer | How is this measure calculated and grouped? | Revenue by month and company, using a named definition. |
A portfolio reporting example
Consider a hypothetical portfolio with a subscription company and a project services company. Both report revenue, but their operational views use different dates, exclusions, and customer identities. The first useful deliverable is a comparison contract: what question the portfolio team is asking, which local values can be compared, and which differences must remain visible.
The ontology could distinguish a billing account from a legal customer and describe how a contract relates to each. A graph could connect the actual accounts, contracts, delivery obligations, and owners. A semantic layer could expose an agreed revenue measure with explicit time periods and exclusions. The graph does not decide the accounting policy, and the metric does not resolve an unidentified customer. Those decisions still need an authorized business owner.
Choose the smallest useful starting point
If the same term means different things across teams, start with a vocabulary and a definition owner. If relevant evidence is scattered across records that cannot be joined reliably, test entity matching and relationship mapping. If reports disagree because calculation logic is copied into multiple tools, test a governed metric definition. A focused experiment can reveal whether the next layer is necessary.
Write an acceptance example before choosing the architecture. For a customer review, ask for one customer, its associated contracts, the current operating measure, the source records, and the owner of any exception. Include a case where two companies share a trading name. If the prototype silently combines them, the attractive graph is concealing an identity problem rather than solving it.
- Name the decision and the person accountable for it.
- List the terms whose meaning changes the answer.
- Identify the records and relationships needed to support the answer.
- Specify the metric calculation, permitted audience, and effective date.
- Document the unresolved exceptions instead of forcing a single value.
Test meaning separately from access and freshness
Our proposed test plan changes one thing at a time. Rename a source field without changing its meaning. Change a metric definition with an effective date. Reassign a contract to the correct legal entity. Withdraw a user's access to a supporting document. Each change should have an explainable effect on the answer, with a record of the configuration used.
A connected representation does not prove that every relationship is correct or that every reader may see it. Record source identity, review status, access policy, and update responsibility alongside the mapping. When the evidence is incomplete, return the known relationships and the missing decision. A confident paragraph cannot substitute for an unresolved relationship or an absent definition.
How this relates to Business Observability
Within this site's Business Observability framing, these layers help connect a changing business signal to its context and accountable next action. They are supporting design choices, not interchangeable names for the whole operating process. A team still needs a review cadence, exception handling, and a way to correct the underlying evidence.
For a vendor demonstration, bring one difficult operating question and ask the team to trace the answer backward. Inspect the metric definition, entity mapping, original record, permission check, and correction path. That exercise is more informative than asking whether the product has a knowledge graph. Buy the capability your tested question requires, then expand only when the evidence supports it.
From reading to doing
Put it to work: resolve one disputed metric
Choose one operating question that two teams answer differently. In this hypothetical exercise, sales calls an account active after a signed contract, while finance waits for the first paid invoice. Both definitions may be useful. The problem begins when a report silently treats them as equivalent. Write the two definitions before selecting a graph database, ontology language, or metrics tool.
Work backward from the decision. If the question is which accounts need onboarding, the signed contract may be the relevant event. If the question is which accounts have produced cash, a payment event matters. A shared model should preserve those distinctions and let the report name the state it actually measures. Do not settle a business disagreement by hiding it inside a field name.
- Name the decision, the person making it, and the reporting period. Keep that scope on the worksheet.
- Write each team's definition with its event, date field, exclusions, and source system. Include who owns the definition.
- Choose three synthetic accounts: signed but unpaid, paid, and cancelled. Record the expected classification under both definitions.
- Trace each example from its source record to the displayed metric. Mark where an identifier, relationship, or calculation changes the answer.
- Agree on distinct labels or an explicit reconciliation rule. Ask both owners to review the examples before changing the shared report.
Common questions
Do I need a knowledge graph to use a semantic layer?
Not necessarily. A metrics semantic layer can operate over relational data models. A knowledge graph is useful when connected entities and relationships are central to the question, but it is not a universal prerequisite.
Is a business ontology the same as a data catalog?
No. A catalog usually helps locate and describe data assets. An ontology describes concepts and their relationships. A product may combine these functions; inspect how it represents meaning and maintains it when the business changes.
Does an ontology make AI answers accurate?
It can clarify meaning, but accuracy still depends on correct evidence, mappings, permissions, retrieval, and reasoning. Test the complete workflow, including how it handles missing or conflicting information.
Sources and evidence
AI assisted editorial analysis. Primary sources checked October 10, 2026. The worked examples and proposed review procedures are editorial illustrations, not reported customer results, vendor guarantees, or claims of personal experience.
One useful next step: Choose one idea from this note and test it at the smallest scale that could teach you something this week.
