A data catalog tells you what data exists and where it lives. An ontology tells you what that data means. A semantic layer uses that meaning to turn business questions into correct SQL. A context layer delivers all of it to AI agents when they need it. The four are often sold as separate products, but they work best as one connected stack.
This post separates the terms, shows how they relate, and suggests which to build first.
Quick comparison
| Data catalog | Ontology | Semantic layer | Context layer | |
|---|---|---|---|---|
| Answers | What data do we have, and where? | What does it mean? | What is the correct answer to this question? | What does an agent need to know right now? |
| Main contents | Systems, tables, columns, owners, tags, lineage | Concepts, relations, metrics, definitions | Metrics, dimensions, bindings, access rules, a compiler | Tools that serve meaning, inventory, rules and documents |
| Main users | Data teams, stewards, governance | Data architects, domain experts | Analysts, BI tools, apps, agents | AI agents |
| Typical output | Search results, impact analysis | OWL / RDF, a business glossary | SQL and query results | Context for one question, over MCP or an API |
The data catalog: inventory
A data catalog (data catalogue in UK spelling) is an inventory of your data estate. It records systems, schemas, tables and columns; descriptions and owners; sensitivity tags such as PII; and often lineage showing where data came from.
Catalogs answer questions like:
- Do we already have a table with customer churn dates?
- Which columns contain personal data?
- If I drop this column, what breaks?
- Is this table the original or a copy?
What a catalog does not do by itself is define business meaning precisely enough to compute with. A catalog entry that says "revenue: total revenue" does not tell a query engine to subtract discounts and exclude refunds.
The ontology: meaning
An ontology is a formal model of the business: the concepts (Customer, Order, Product), the relations between them (an Order is placed by a Customer), and the metrics defined over them (net revenue). In data teams it often starts life as a business glossary and grows into something machine-readable, commonly expressed in OWL and RDF so other tools can use it.
The key difference from a catalog is direction. A catalog starts from tables and describes them. An ontology starts from the business and maps it onto tables through bindings: Customer is stored in dim_customer in Snowflake and in contacts in the CRM database.
A good ontology:
- Has one concept even when the data lives in two systems.
- Turns bridge tables into many-to-many relations rather than fake concepts.
- Keeps definitions under human review.
- Stays in sync with the data model instead of being maintained by hand.
The semantic layer: answers
A semantic layer makes the ontology executable. Given a question in business terms, such as "net revenue by customer segment for 2026", it:
- Resolves the metric and dimensions to their definitions.
- Finds the valid join path through the relations.
- Writes SQL for the right system, in the right dialect.
- Applies access rules, row filters and masking.
- Returns the result, ideally with the SQL that ran.
Some products call the metrics-only version of this a metrics layer. The difference is that a full semantic layer also knows the entities and relations, so it can tell which joins are valid for a metric. We go deeper in What Is a Semantic Layer?.
The context layer: delivery to agents
AI agents changed the picture. An agent needs the catalog's inventory, the ontology's meaning, the semantic layer's governed answers and the organization's documents, all scoped to the question in front of it. A context layer is the interface that serves exactly that, typically as tools over the Model Context Protocol (MCP).
Without one, teams paste schemas and wiki pages into prompts and hope. With one, the agent calls a tool such as get_query_context, gets the relevant concepts, metric formula, join path and masked fields, and then asks a governed question. See The Context Layer for how that works.
How they fit together
Think of them as layers that each depend on the one below:
- Data model: the tables, keys and relationships in your warehouse.
- Catalog: the inventory of those tables across every system.
- Ontology: the business meaning, bound to catalog tables.
- Semantic layer: questions compiled into SQL using the ontology.
- Context layer: all of the above served to agents, with governance.
Problems appear when these are maintained separately. A catalog that does not know which concepts use a column cannot do impact analysis on metrics. An ontology that is not bound to tables cannot answer questions. A semantic layer whose definitions drift from the warehouse produces confident wrong numbers. An agent with context from none of them guesses.
Which do you need first?
It depends on the pain you feel today:
- "We can't find anything" or "we don't know what's sensitive": start with a catalog.
- "Everyone has a different number for revenue": start with semantic definitions: an ontology and a semantic layer.
- "Our AI agent writes wrong SQL": you need meaning and governance before you need a smarter model, so a semantic layer plus a context layer.
- "We have no clean model at all": start with the data model itself. Everything above depends on it.
Frequently asked questions
Is a business glossary an ontology? A glossary is the human-readable start of one. It lists terms and definitions. An ontology adds structure (relations, cardinality, metric formulas) and bindings to tables, so machines can use it, not just people.
Can a semantic layer work without a catalog? Yes, if its bindings are maintained by hand. In practice a catalog makes the semantic layer safer: it knows which tables exist, where copies live, and what breaks when a column changes.
Do I need OWL or RDF? Not to get value from an ontology. Standard formats matter when you want to share the ontology with other tools such as Protégé or a knowledge graph, or publish resolvable identifiers for concepts. offdataai exports OWL Turtle, JSON-LD and RDF/XML when you need them.
Where does a metrics layer fit? A metrics layer is the metric-definition part of a semantic layer. It is a good start, but metrics are only reliable when the semantic layer also knows the entities and relations they are measured over.
How offdataai connects them
offdataai was built from the data model upwards, so the layers share one source of truth:
- The data model comes from the AI data modeling tool, 174 templates, the Model Builder canvas or the Database Modeler, which reverse-engineers a live database.
- The data catalog gathers every system, table and column from your connections, records which ontology concepts use each one, and links copies to their originals, from metadata only.
- The ontology is derived from the model, reviewed by your team, published with resolvable IRIs and exportable as OWL.
- The semantic layer compiles concept-level questions into SQL per source system and federates across systems when needed.
- The context layer serves all of it to agents over MCP with scoped keys, access rules, PII masking and an activity log.
Whichever layer you start with, keeping them connected is what makes the others trustworthy.