Ontology vs semantic layer vs context layer

An ontology describes what exists in a business and how those things relate. A semantic layer defines metrics on warehouse tables so reporting tools return consistent numbers. A context layer records what each figure means across systems, with owners, approvals and lineage, so people and AI use agreed definitions. Many teams need parts of all three.

Vendors use all three terms loosely. Here is how they usually compare.

How they compare

  • Ontology. Describes concepts and relationships, such as customer, account and product. Usually maintained by data architects or a data governance team. Its strength is reasoning across concepts.
  • Semantic layer. Describes metrics and dimensions mapped to warehouse tables. Usually maintained by the data team. Its strength is consistent numbers in BI tools.
  • Context layer. Describes definitions, cross-system mappings, owners, approvals and lineage. Maintained by finance with data team support. Its strength is figures people and AI can trust and trace.

Where each one stops

  1. An ontology says an account is an instance of a product, but not which definition of deposits the CFO approved.
  2. A semantic layer calculates deposits consistently on the warehouse, but often can't see systems outside it or record who approved the logic.
  3. A context layer records the approved definition and where it lives, and benefits from the relationships an ontology describes.

Which do you need?

  1. If AI agents need to reason across many concepts, start with the ontology.
  2. If dashboards disagree on the same metric, start with the semantic layer.
  3. If regulators, auditors or the board will check the numbers, you need the ownership and approval trail of a context layer.

How Preql helps

Preql's agents map how each system represents the same business concept and propose shared definitions. Business owners approve them, and every change is versioned with an audit trail and lineage back to source.

FAQ

Can one tool do all three?

Some cover more than one. Check what each actually stores: relationships, metric logic, or ownership and approvals.

Which comes first?

The one tied to the problem you have now. They can be connected later.