After analyzing in the first article the limitations of data without semantics and the true meaning of context in organizations, this time we delve deeper into the technological components that allow us to transform that context into a structured, governable knowledge architecture ready for artificial intelligence.
Your company doesn't just need more data: it needs more context.
When an organization decides to take context seriously, three terms emerge that need clarification: semantic model, ontology, and catalog. They are similar, related, and sometimes overlap, but they don't solve exactly the same problem. Understanding their differences avoids circular arguments and helps design a cleaner architecture.
Alongside them are standards such as OWL, OWL 2 RL, SWRL, SHACL, which have been solving knowledge representation and inference problems for years, and which data platforms (Snowflake, Databricks, Microsoft) are beginning to put at the center of their products.
Semantic model, ontology and catalog: what does each piece contribute?
The semantic model is typically close to analytical consumption. It translates physical structures into queryable business concepts: defining metrics, dimensions, hierarchies, and aggregations, so that people and tools can query sales, customers, or margins without needing to know all the tables and joins. It's a contract for measurement.
Ontology goes a step deeper. It explicitly describes concepts, relationships, and constraints within a domain: that a customer can have contracts, that a contract belongs to a product line, that certain events change an entity's state. It's a map of the business world that can be read by machines, and it allows for the inference of implicit knowledge: if a turbine is a critical asset and all critical assets require periodic inspection, it can be inferred that this turbine requires it without anyone explicitly stating it.
The catalog organizes assets: it helps find data, understand ownership, check quality and lineage, and connect consumers with producers. A catalog without semantics is like a library where the books are arranged, but no one knows what theses they support; enriched with semantics, it can answer questions like "Which reports use an outdated definition of an active customer?" or "What sensitive data might this agent access?"
Mature architecture doesn't choose one piece and discard the others; it combines them. The semantic model ensures consistent consumption, the ontology makes meaning explicit, and the catalog makes everything discoverable and governable. Imagine the question, "Which premium customers are at risk of churn and have a contract expiring in 60 days?" The catalog identifies certified sources; the ontology defines what constitutes a customer, a contract, and premium status; the semantic model provides metrics on value and usage; the rules determine thresholds; and the agent responds within its permissions.
For this coexistence to work , it is advisable to establish some principles: critical definitions have an owner, official metrics are versioned, semantic quality rules are tested, agents only consume certified assets for relevant decisions, and the catalog acts as a governance interface, not as a document graveyard.
Enterprise semantic stack
Each piece brings a different responsibility: measuring, relating, governing, validating, and consuming.
The semantic layer does not replace the catalog, ontology, or quality; it coordinates them so that business and technology speak the same language.
Standards that turn context into architecture
There's no need to invent a language from scratch: there are standards from the world of the semantic web that solve precisely the problems that are now appearing in businesses: how to represent concepts unambiguously, how to derive implicit knowledge, or how to validate that a dataset meets certain conditions. It's important to be precise about their status: OWL and SHACL are established W3C recommendations; SWRL, on the other hand, was presented as a proposal (Member Submission) to combine OWL with Horn-like rules, but it never became a final recommendation.
OWL allows you to define ontologies, classes, properties, individuals, and constraints, in other words, to teach machines the business vocabulary and some rules about how it's organized. OWL 2 RL is especially interesting for enterprise environments because it's designed for scalable reasoning: certain problems can be solved in polynomial time, which in business terms means that not all semantic reasoning has to be unfeasible at scale. It fits well when we want to materialize inferences through rules: if a "strategic customer" is defined by belonging to certain segments and revenue levels, that classification can be inferred consistently. OWL doesn't replace transactional systems or SQL; its role is to represent shared knowledge, and it's especially useful for disambiguation when different systems use the same word ("account") for different things.
SWRL allows you to write rules of the type "if certain conditions are met, then this is inferred": if a customer exceeds a certain billing volume, belongs to a priority region, and has had critical incidents, they are flagged for follow-up. Although not a final W3C recommendation, its approach remains useful as a pattern for separating explicit rules from hidden logic in code, and for communicating with the business in a clear format: condition, inference, consequence. The risk of not making rules explicit is that they will be duplicated across multiple applications without anyone knowing which rule takes precedence when they conflict. For AI agents, this is key: an agent shouldn't invent a business rule just because it sounds reasonable; it should consult approved rules.
SHACL (Shapes Constraint Language) serves another purpose: validation. It's a W3C recommendation for verifying that RDF graphs meet conditions expressed as shapes, cardinalities, expected types, ranges, and mandatory relationships. This is powerful because traditional data quality doesn't always capture semantic errors: a field might not be null and have the correct type, yet a contract might have an end date earlier than its start date, or a critical incident might lack an associated asset. SHACL introduces a very sound idea: semantics are also tested. A catalog can show that a dataset exceeds certain shapes, and an agent might prefer validated sources.
How standards turn context into architecture
OWL models meaning, SWRL expresses business rules, and SHACL validates that the data conforms to the expected forms.
The bet by Snowflake, Databricks and Microsoft
Major vendors are moving in the same direction: bringing semantics closer to where data is queried, governed, and automated. The common pattern is clear: a data management system (DMS) connected to context-free tables generates plausible queries and weak responses; connected to a governed semantic layer, it has a much greater chance of being useful. This confirms a transition: the semantic layer, once a concern of business intelligence (BI), is becoming an interface for AI.
Snowflake has positioned Semantic Views as native schema objects, allowing business concepts,metrics, entities, relationships, and metadata such as synonyms and verified examples, to be stored directly in the database. Cortex Analyst uses these views to generate more accurate SQL queries from natural language, and Snowflake recommends them over legacy YAML models due to their native integration, RBAC, sharing capabilities, and governance. It also allows for custom instructions to guide how the agent interprets ambiguous queries.
Databricks is pushing semantics through Unity Catalog, with Business Semantics as a centralized platform for defining metrics and KPIs. Metric Views are at the core: they separate measures from the fields used for grouping and filtering, so a metric is defined once and queried at runtime. They also incorporate agent metadata, synonyms, display names, and formatting rules, enabling agents to better map users' colloquial language. On the consumer side, AI/BI and Genie Spaces allow for curating spaces with datasets, sample queries, and business semantic expressions tailored to each organization's terminology.
Microsoft starts from a strong position in BI with Power BI's semantic model, and clearly warns: to use Copilot with semantic models, the data, the model, and the users must be prepared beforehand, or Copilot may produce inaccurate or misleading output. The Fabric data agent processes natural language queries, identifies the most relevant source, lakehouse, warehouse, Power BI dataset, or ontology, and invokes the appropriate tool. And Fabric IQ connects semantic models with enterprise ontologies, along with features like *Prep for AI* and AI instructions. For companies already invested in Power BI, this opens a pragmatic path: there's no need to abandon existing models, but rather to improve their semantic quality.
Three pieces, one objective
Semantic model, ontology, and catalog are not three names for the same thing: each solves a different problem: measuring, understanding, and governing. Mature architecture combines them rather than choosing one. Standards like OWL, OWL 2 RL, SWRL, and SHACL provide proven ways to represent, infer, and validate that knowledge, and major data platform vendors are already putting that logic at the heart of their products because they understand that enterprise AI needs more than just prompts.
