Ontology and the semantic layer
A semantic layer gives your data a business-facing vocabulary: metrics, dimensions, and relationships. At Magnowlia, that vocabulary is an ontology: a formal, layered model that defines what each concept means and exactly how it maps to your database, so every insight is consistent and traceable.
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.
Most modern semantic layers use YAML configuration files to define metrics and dimensions. Magnowlia takes a different approach: it uses a formal ontology written in OWL/Turtle, a W3C standard for knowledge representation. This gives you everything a YAML-based semantic layer provides, plus formal graph relationships, rich synonym support, and deep semantic context that AI models can reason over.
Semantic layer vs ontology
How does a traditional YAML-based semantic layer compare with an OWL/Turtle ontology? The table below compares them across the dimensions that matter most for analytics and AI.
| Dimension | YAML Semantic Layer | OWL/Turtle Ontology |
|---|---|---|
| Format | YAML config files (dbt, Cube, LookML) | W3C OWL/Turtle (.ttl) |
| Relationships | Flat foreign-key references between models | Formal graph relationships (subClassOf, domain, range) |
| AI context | Limited: metric names and descriptions only | Rich: labels, comments, synonyms, hierarchy, and typed links |
| Standards | Proprietary (vendor-specific schemas) | W3C open standard (OWL, RDF, SKOS) |
| Version control | YAML files in Git | Turtle files in Git |
| Metric definitions | Yes (expressions, filters, time grains) | Yes (expressions, filters, time dimensions, dependencies) |
| Synonyms / alt labels | Limited or unsupported | Native via SKOS altLabel and hiddenLabel |
| Traceability | Partial (metric to table, not full lineage) | Full mapping layer from concept to schema, table, and column |
Traditional YAML-based semantic layers are effective at what they were designed for: giving BI tools and SQL generators a shared set of metric definitions. If your primary goal is to make sure dashboards use the same revenue formula, tools like dbt metrics, Cube, or LookML do the job well. They are familiar to data engineers, easy to template, and tightly integrated with their respective ecosystems.
Where an ontology adds value is in the depth of its semantic model. Because OWL/Turtle encodes formal relationships, class hierarchies, and rich annotations, an AI system reading the ontology understands not just “what metrics exist” but “how concepts relate to each other.” It knows that “GMV” is an alternative label for “Gross Merchandise Value,” that “Revenue” depends on “Order Status,” and that “Customer” is connected to “Order” through a typed relationship. This richer context means fewer hallucinations, more accurate query generation, and explanations that reference your actual business vocabulary.
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(total_amount)" ;
bv:timeDimension b:OrderDate ;
bv:metricTable t:public.orders ;
bv:dependsOnProperty b:orderStatus ;
bv:metricPreFilter "status = '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 1How each predicate maps to SQL
| Turtle predicate | SQL element | Explanation |
|---|---|---|
| bv:metricExpression | SUM(total_amount) | The aggregation formula used in the SELECT clause |
| bv:timeDimension | DATE_TRUNC('month', order_date) | Resolves the time column and applies the requested grain |
| bv:metricTable | FROM public.orders | The physical table mapped via the ontology's table layer |
| bv:metricPreFilter | WHERE status = '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.
Semantic layer tools comparison
How does Magnowlia's ontology-powered approach compare with other popular semantic layer tools?
| Capability | Magnowlia | Looker (LookML) | dbt Semantic Layer | Cube |
|---|---|---|---|---|
| Metric definitions | ✓ | ✓ | ✓ | ✓ |
| Formal relationships | ✓ | Partial | ✗ | Partial |
| AI / natural-language queries | ✓ | Limited | Limited | Limited |
| Open standard | ✓ W3C OWL | ✗ | ✗ | ✗ |
| Self-serve BI | ✓ | ✓ | Via partners | ✓ |
Explore more
What is a business ontology?
Definitions, why it matters for analytics, and how it differs from a data dictionary.
Learn more →Benefits of an ontology
Why teams adopt a business ontology for metrics and analytics.
Learn more →Ontology vs semantic layer
A detailed comparison of ontology-based and YAML-based approaches to defining your metrics.
Learn more →Ontology examples
Real-world Turtle snippets showing metrics, dimensions, and mappings in action.
Learn more →Sign up and get started with your own ontology
Build your semantic layer on a clear ontology. Connect your data and start asking questions in plain English. No credit card required.
Get Started Free