Ontology vs traditional semantic layer

What traditional semantic layers get right

YAML-based semantic layers like dbt metrics, Cube, and Looker LookML have earned their place in the modern data stack. They centralize metric definitions so that every downstream tool uses the same formula, same filters, and same time-grain logic. This alone eliminates a large class of data inconsistency bugs.

These tools also integrate tightly with the SQL ecosystem. dbt metrics live alongside your transformation models. Cube exposes an API that any BI tool can query. LookML is embedded in the Looker platform. For teams that already use these tools, the setup cost is low and the payoff is immediate.

If your primary need is shared metric definitions for dashboards, a YAML semantic layer is a solid choice. The question is whether it is sufficient when your goals expand to include AI-powered analytics, formal governance, and rich semantic context.

What YAML semantic layers miss

What an ontology adds

Consider a simple example. In YAML you might define a revenue metric as a name, an expression, and a table. In OWL/Turtle, the same metric carries additional formal semantics:

b:TotalRevenue a bv:Metric ;
    rdfs:label "Total Revenue" ;
    rdfs:comment "Sum of completed order amounts after refunds" ;
    skos:altLabel "Revenue" , "Net Revenue" , "GMV" ;
    bv:metricExpression "SUM(total_amount)" ;
    bv:timeDimension b:OrderDate ;
    bv:metricTable t:public.orders ;
    bv:dependsOnProperty b:orderStatus ;
    bv:dependsOnRelationship b:placedBy ;
    bv:metricPreFilter "status = 'completed'" .

Notice the additional predicates that YAML cannot express: skos:altLabel gives the metric three synonyms, bv:dependsOnRelationship declares a dependency on the Customer-Order relationship, and rdfs:comment provides a precise description that AI uses to disambiguate the metric from similar ones.

These additional predicates are what make AI analytics work reliably. When a user asks “show me GMV by region,” the system resolves the synonym, identifies the correct metric and its dependencies, finds the region dimension through the ontology graph, and constructs the right SQL. No guesswork.

Explore more