Your ontology is a semantic layer — and so much more

A user asks: “Which customer segments should we target to improve retention?”

Answering that requires more than a metric formula. The system needs to traverse from the Retention metric to Churn, from Churn to Customer Segment, and from Segment to Purchase Frequency — following typed relationships through a formal graph. Semantic layers were not designed to express this kind of structure. Ontologies are.

Get Started Free Ontology overview

What is a semantic layer?

A semantic layer sits between your raw database tables and the people (or AI systems) that ask questions about the data. Instead of writing SQL against column names like amt_usd or crt_dt, users work with business concepts such as “Total Revenue” or “Order Date.” The semantic layer translates those concepts into the correct SQL, joins, and filters automatically.

For data teams, the value is consistency. When “Monthly Recurring Revenue” is defined once in the semantic layer, every dashboard, ad-hoc query, and AI-generated answer uses the same formula. There is no drift between the finance team's spreadsheet and the product team's dashboard, because both resolve to the same underlying definition and the same mapped columns.

Tools like dbt metrics, Cube, and Looker LookML have earned their place in the modern data stack by solving this problem well. They centralize metric definitions so that every downstream tool uses the same formula, same filters, and same time-grain logic. If your primary need is shared metric definitions for dashboards, a YAML semantic layer is a solid choice.

Your ontology is a semantic layer

Magnowlia gives you everything a traditional semantic layer provides — shared metric definitions, consistent formulas, time-grain logic, pre-filters — because the ontology is your semantic layer. Metrics, dimensions, and their mappings to your database are all defined in the same OWL/Turtle model.

The question is what happens when your goals expand beyond dashboards. When you want AI to answer open-ended questions, trace how a metric is calculated, or discover which dimensions are relevant to a business problem, a flat YAML file runs out of expressiveness. That is where the ontology keeps going.

What an ontology adds on top

Formal relationships

YAML files define metrics as flat key-value pairs. Relationships between concepts (Customer places Order, Order contains LineItem) are implicit in SQL joins, not declared as first-class entities. An ontology makes these relationships explicit and typed, so an AI system can traverse the graph to find relevant dimensions and joins automatically.

Rich AI context

A YAML metric has a name, a description, and a SQL expression. An OWL ontology adds formal types, class hierarchies, property domains and ranges, synonyms via SKOS altLabel, and explicit dependency chains. This deeper context lets AI systems resolve ambiguous queries without guessing.

Synonym support

When a user asks about “GMV” instead of “Gross Merchandise Value,” a YAML semantic layer cannot resolve the synonym. OWL/Turtle ontologies support skos:altLabel natively, so every concept can have multiple names that all resolve to the same definition.

Open standard

LookML, dbt YAML, and Cube schemas are proprietary formats. Migrating from one to another means rewriting your metric layer. OWL/Turtle is a W3C open standard: your ontology is portable, tooling is available in every language, and you are not locked into any single vendor.

Here is what a metric looks like with these additional capabilities:

b:totalRevenueMetric 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(b:orderTotal)" ;
    bv:timeDimension b:orderDate ;
    bv:sourceEntity b:Order ;
    bv:dependsOnProperty b:orderStatus ;
    bv:dependsOnRelationship b:placedBy ;
    bv:metricPreFilter "b:orderStatus = 'completed'" ;
    bv:metricCategory "Revenue" .

These are the predicates that give AI the context it needs: skos:altLabel gives the metric three synonyms so users can ask about “GMV” or “Net Revenue” and resolve to the same definition, 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.

How Magnowlia compares

Magnowlia gives you everything a traditional semantic layer provides, plus the capabilities that come from formal ontology semantics.

Capability	Magnowlia	Looker (LookML)	dbt Semantic Layer	Cube
Metric definitions	✓	✓	✓	✓
Formal relationships	✓	Partial	✗	Partial
Synonyms / alt labels	✓	✗	✗	✗
AI / natural-language queries	✓	Limited	Limited	Limited
Full traceability	✓	Partial	Partial	Partial
Open standard	✓ W3C OWL	✗	✗	✗
Self-serve BI	✓	✓	Via partners	✓
Version control	✓	✓	✓	✓

From ontology to SQL

Here is a concrete example. The Turtle snippet below defines a “Total Revenue” metric in the ontology, and the SQL block shows what Magnowlia generates from it.

Turtle metric definition

b:TotalRevenue a bv:Metric ;
    rdfs:label "Total Revenue" ;
    rdfs:comment "Sum of all completed order amounts" ;
    bv:metricExpression "SUM(b:orderTotal)" ;
    bv:timeDimension b:orderDate ;
    bv:sourceEntity b:Order ;
    bv:dependsOnProperty b:orderStatus ;
    bv:metricPreFilter "b:orderStatus = 'completed'" .

Generated SQL

SELECT DATE_TRUNC('month', order_date) AS period,
       SUM(total_amount) AS total_revenue
FROM public.orders
WHERE status = 'completed'
GROUP BY 1
ORDER BY 1

How each predicate maps to SQL

Turtle predicate	SQL element	Explanation
bv:metricExpression	SUM(b:orderTotal)	The aggregation formula used in the SELECT clause
bv:timeDimension	DATE_TRUNC('month', order_date)	Points to a date/timestamp property; resolves the time column and applies the requested grain
bv:sourceEntity	FROM public.orders	The source entity's mapped table, resolved via the ontology
bv:metricPreFilter	WHERE b:orderStatus = 'completed'	A pre-filter applied before aggregation to scope the metric
bv:dependsOnProperty	status column	Declares the column dependency, used for lineage and validation
rdfs:label	AS total_revenue	The human-readable name becomes the column alias

Every part of the generated SQL traces back to a specific predicate in the ontology. When a metric changes, you update the Turtle definition and every downstream query picks up the new logic automatically.

Works alongside your existing tools

Already using dbt, Cube, or another semantic layer tool? Magnowlia integrates with them. You can import existing metric definitions, enrich them with ontology semantics, and keep your current workflows running while adding the formal relationships and AI context that the ontology provides.

View all integrations →

A semantic layer that goes further

Define metrics and relationships in a W3C standard format. Connect your data and start asking questions in plain English — from simple dashboards to open-ended analysis. No credit card required.

Get Started Free