FAQ on Metadata, Semantics, Taxonomy, Ontology, Knowledge Graphs, and Context

I have two recent pet peeves. First, people take the well-known techniques of semantics, call them context, and declare the whole topic brand new, as if AI agents had just unleashed it on us. Second, experts explain metadata, semantics, taxonomy, ontology, knowledge graphs, and context without a single example, which leaves the audience more confused than when the conversation began.

Over my career, I have watched the so-called “moat” oscillate all over the stack. In the early days, the vendor that stored your data called the shots (relational database vendors). Then the moat moved to the application layer (ERPs), then to the API gateway, and finally to the BI tool. More recently, foundation model companies have staked the same claim.

Now, vendors across the stack have repositioned around the “context layer,” claiming that context is the center of gravity and will solve the shortcomings of probabilistic models and agents that have no real knowledge of enterprise data.

In this blog, I demystify the concepts that lead up to the idea of context, and I do it the way I wish more people would: with concrete examples. I close with my own view on how to build the context layer.

Why now?

Four things happened in the last two years that made an old debate suddenly urgent.

• First, autonomous agents arrived. They read documents, write code, file tickets, and call APIs on our behalf, acting where software used to only inform.
• Second, the cost of being wrong went up. A dashboard with a fuzzy definition of “revenue” annoys a CFO. An agent with the same fuzzy definition issues refunds, sends emails, or files compliance reports based on the wrong number.
• Third, the technology is finally ready. LLMs extract entities and relationships from unstructured text, graph databases have matured, and standards like OSI, MCP, Delta Sharing, and the Iceberg REST catalog are converging fast. Unstructured data can now be made as useful as structured data.
• Fourth, the consumer of data has changed. A human ran a handful of queries a day and could absorb a slow or inconsistent answer through judgment and conversation. An agent issues orders of magnitude more requests and has neither.

When humans get three different revenue numbers from three different reports, we tolerate the chaos by reconciling inconsistency through conversation. Once the consumer is an agent, the same chaos becomes operational risk. If we do not fix the semantic problem now, AI will not solve our consistency problem, but rather it will scale it.

Frequently asked questions

Vendors throw around terms like metadata, semantics, taxonomy, ontology, knowledge graphs, and context interchangeably. Buyers don’t know what to ask for, and the architects in the middle are left translating. But these six terms are not competing concepts. They are a stack. Each layer does a specific job, and each is incomplete without the others. The stack is exactly what separates an AI agent that hallucinates from one that does not.

This post is the FAQ I keep needing to hand people before any architecture conversation goes anywhere useful. I use two running examples to keep it concrete: the MacBook Air I bought recently, and a customer support agent trying to resolve a defective-part complaint. Both show up in nearly every answer.

1. What are the definitions: metadata, semantics, taxonomy, ontology, knowledge graphs, and context?

2. How do they relate to each other?

3. Where does the semantic layer physically reside?

4. What is the role of standards like OSI (Open Semantic Interchange)?

5. How is the context layer built and persisted?

1. What are the definitions?

As these topics move from a research-conference curiosity to a CDO priority, definitions are the first step. Abstract definitions are forgettable, but examples make them concrete. Three years ago, I defined data products by comparing them to a box of cereal, Cinnamon Toast Crunch, to be exact. But I digress. Here I’ll use my new MacBook Air to make these concepts tangible.

Metadata

Metadata is data about data. The MacBook Air arrived with a serial number, a model identifier, a manufacture date, a country of origin, a warranty start date, an order number, and a delivery timestamp. None of that is the laptop itself. All of it describes the laptop.

Inside the laptop, every file gets metadata too: created date, modified date, owner, permissions, MIME type. Metadata is what makes assets findable, governable, and trustworthy. It is the substrate every other layer depends on.

Metadata is further classified as technical, operational, social, and business:

• Technical metadata is what we used to call a data dictionary: the structure of a table, including column names, data types, and distribution histograms.
• Operational metadata describes the data in motion: freshness, last refresh time, pipeline run duration, error counts, query latency.
• Social metadata is the tacit knowledge users contribute: steward endorsements, ratings, comments, and signals like how many dashboards consume the table.
• Business metadata describes what the asset means to the organization. A column named cust_addr_st carries no meaning until something says “this is the customer’s state, two-letter US postal code, drawn from the ISO 3166–2:US list.”

That is where we cross from metadata into semantics.

Semantics

Semantics is the meaning attached to data. The string “M5 MacBook Air” in a column does not become a laptop until something encodes that it refers to a specific Apple product line. Semantics is what turns symbols into things: the layer that tells you a row is a customer, a column is a price, a value is a currency, a code is a country.

Semantics covers everything that establishes meaning around an asset, including:

• Definitions: the precise, shared meaning of business terms. “Active Customer” means a customer with at least one transaction in the last 90 days. “Churn” excludes paused accounts but includes downgrades to the free tier.
• Metrics and KPIs: how numbers are calculated. “Monthly Recurring Revenue” is the sum of active subscription values at month end, excluding one-time charges and pro-rated amounts. Each metric has one canonical definition, or it has none.
• Business rules: when policies and calculations apply. Commissions apply only to deals above $10,000. Refunds within 30 days do not count toward sales quotas. New-customer pricing applies for the first 90 days only.
• Hierarchies and classifications: how concepts roll up. Products into categories. Customers into segments. Transactions into pipeline stages. This is where taxonomies live.

Semantics is the answer BI tools, analysts, and increasingly AI agents need before they can use the data at all. Without it, every consumer is left guessing, which produces inconsistent results.

Taxonomy

A taxonomy is a hierarchical classification, a way to organize concepts into parent-child relationships. My MacBook Air sits inside a taxonomy that any e-commerce site uses: Electronics → Computers → Laptops → Apple → MacBook → MacBook Air → 13-inch → M5. Each level narrows the scope. A taxonomy is what lets you ask “show me all laptops” without enumerating every model in existence.

Enterprises rely on taxonomies everywhere. Products roll up into categories. Customers roll up into segments. Transactions roll up into pipeline stages. Employees roll up into org units. Industries roll up through standards like NAICS or GICS. Procurement spend rolls up through UNSPSC. Healthcare diagnoses roll up through ICD-10. Each is a parent-child tree, and each makes aggregate questions answerable.

The same asset usually belongs to several taxonomies at once. My MacBook Air sits in the product catalog taxonomy (under Laptops), the support taxonomy (under Apple Hardware), the regulatory taxonomy (under Lithium-Ion Battery Devices), and the accounting taxonomy (under Capital Equipment). Most enterprises have several taxonomies, each governed by a different team.

A taxonomy cannot say that a MacBook Air runs macOS, shares an iCloud account with an iPhone, or was purchased on the same order as a pair of AirPods. Those are relationships, not classifications. (The AirPods, incidentally, were happily appropriated by my daughter.) Once you need relationships, you have crossed from taxonomy into ontology.

Ontology

An ontology is a formal model of entities, their attributes, and the relationships between them. Where a taxonomy tells you that a MacBook Air is a kind of laptop, an ontology tells you that a MacBook Air has an M5 chip, ships with macOS, is owned by a Customer, was sold through an Order, and is covered by a Warranty. The nouns are the entities; the verbs linking them are the relationships. The model encodes both.

Ontologies are built from three components:

• Entities (formally, classes). The things that exist in the domain. Customer. Product. Order. Address. Warranty. Account.
• Attributes. The properties each entity carries. A Customer has a name and an email. A Product has a SKU, a price, and a chip generation. An Order has a date and a total amount.
• Relationships. The legal connections between entities. A Customer places an Order. An Order contains one or more Products. A Product is covered by a Warranty for a specific duration.

A taxonomy gives you only the hierarchy. An ontology adds the attributes and the relationships, and makes all three machine-readable.

Ontologies are written in formal languages like RDFS and OWL so that software can reason about them, not just display them. Industry-standard ontologies already exist for most domains: Schema.org gives a shared vocabulary for the open web. FIBO does the same for finance. SNOMED CT does it for clinical medicine. GS1 standardizes product identifiers across global supply chains.

An ontology is what lets machines reason about meaning, but on its own it is still just a model. It defines what could exist, how things could relate, and what can be inferred. To answer a real question, you need to populate it with actual customers, actual orders, and actual MacBook Airs. That populated version is a knowledge graph.

Knowledge graph

A knowledge graph is what happens when an ontology meets real data. The ontology says “every Customer has Orders and lives at an Address.” The knowledge graph says “Sanjeev Mohan, account #12345, placed Order #99887 on May 17, 2026, for a MacBook Air (serial C02XYZ123), shipping to 123 Main Street, paired with iPhone serial F2L456789, eligible for AppleCare under policy AP-2026–0517.” The ontology is the schema. The knowledge graph is the populated, queryable instance of that schema.

A note on terminology: this ontology-grounded view describes an RDF knowledge graph. Labeled property graphs, the other common style, store the same nodes, edges, and properties but do not require a formal ontology. I’m describing the ontology-backed kind, where the graph is the populated instance of the model.

A knowledge graph is built from three structural elements:

• Nodes. The actual entities. My specific MacBook Air. My specific Apple ID. The specific order I placed.
• Edges. The actual relationships between them. This MacBook Air was purchased by this customer. This order was shipped to this address. This AppleCare policy covers this serial number.
• Properties. The attributes that hang off nodes and edges. The MacBook Air node carries a serial number and a chip generation. The “was purchased by” edge carries a purchase date and a channel.

The killer feature is multi-hop reasoning. SQL can barely express “find all customers who share an address with someone who returned the same model within 30 days.” A knowledge graph traverses that natively.

For AI specifically, GraphRAG structures retrieval through the knowledge graph, so the agent sees not just a relevant document but the connected web of entities around it. That is the difference between an agent that recites and an agent that reasons.

In the example above, the knowledge graph captured everything about the transaction: who, what, when, where, and how. What it does not capture is why I chose this particular MacBook Air. Those decisions sit in entirely different places. My web search history. The support tickets I filed about my old laptop. The conversations I had with my family (especially my daughter who only wanted the AirPods). Assembling the right slice of all of this, for a specific moment and a specific user, is what we call context.

Context

Context is the situational awareness that sits on top of everything else. It connects various systems of record so that agents can reason not just about what happened but why. Context about a customer transaction may be in Confluence pages, query logs, Slack messages, emails, web logs, and product documentation.

Notice that several of those signals are live, not historical. Context isn’t just assembled from stored data, it requires real-time streams. IBM’s $11 billion acquisition of Confluent in 2026, explicitly to “make real-time data the engine of enterprise AI and agents,” signals exactly this. Without streaming infrastructure underneath the context layer, you are always working with yesterday’s picture.

Bring this to the customer support example. A customer calls about a defective MacBook Air keyboard. The agent has the structured record: purchase history, warranty status, prior tickets. That is the easy ten percent. The context that decides the outcome lives outside the database:

• the parts documentation PDF describing the known defect pattern in a specific manufacturing batch,
• the web server logs showing the customer visited the troubleshooting page seven times this week,
• the tweet where the customer publicly criticized the brand,
• the query logs from the support search bar showing they typed “return policy” three times in two days,
• the email thread with the field engineer who diagnosed the same defect in another customer’s machine last week.

None of that sits in one place, and none of it is useful until it is assembled. Context is the runtime act of pulling those signals together. Without the context layer, the agent has the data but not the judgment. With it, the agent reasons about meaning, history, intent, and policy in a single bundle, every time. If semantics gives you the vocabulary and the knowledge graph gives you the facts, then the context layer gives you the moment.

Context is supposedly the next trillion-dollar opportunity if you listen to the Silicon Valley VCs. But detractors say it is a well-known, age-old knowledge engineering problem that ontologists have been trying to solve. In its current incarnation, it can look like a theoretical idea that earlier attempts repeatedly failed to deliver. Old wine in a new bottle.

2. How do they relate to each other?

They are layers in a stack, not competitors. The definitions section walked them in order of increasing meaning; the stack arranges them by what depends on what.

Figure 1: The stack that stands between your AI and a very confident wrong answer. Courtesy: Claude Cowork

Bottom to top:

• At the base sits the physical data: warehouses, lakehouses, operational databases, document repositories, message queues, log files. Metadata sits alongside this layer, describing every asset.
• The next layer up is the ontology, the formal model of meaning. It defines what counts as a Customer, what attributes a Product has, and what relationships are legal between them. Taxonomies live inside the ontology as the hierarchical bones of the classification scheme.
• The knowledge graph instantiates the ontology with real entities and relationships. It is the populated, queryable version of the model: the persistent context of the enterprise.
• The semantic layer sits above all of this as the governed business contract. It is the deployment of semantics: the metrics, KPIs, business rules, and calculation logic. It is the API that says “Active Customers this quarter = 12,847, and here is exactly how we count them.” It serves BI tools, analysts, and AI agents from the same definitions.
• On top sits the context layer: the runtime assembly that pulls the right slice from every layer below, plus user identity, session state, recent actions, and applicable policy, and hands it to a human user or an autonomous agent at the moment of decision.

Bring the MacBook Air through this stack and you see why each layer is needed. Metadata gives you the serial number and the warranty end date. The ontology defines what a Laptop is and that it has a Battery, a Chip, and a Warranty. The knowledge graph holds the actual fact that my specific laptop has serial C02XYZ123 and is linked to my Apple ID. The semantic layer says “Eligible for free battery replacement” is calculated as “warranty active AND battery cycle count over 1000 AND no prior replacement.” The context layer assembles all of this at the moment I open a support chat, plus my recent search history and the technician’s role, and packages it for the agent that responds to me.

Skip any layer and the system breaks predictably. No metadata, nothing is findable. No ontology, everyone defines “customer” differently. No knowledge graph, you can answer “what was sold” but not “what is connected to what.” No semantic layer, every dashboard fights every other dashboard. No context layer, the agent has the data but not the judgment.

The figure below shows the stack with my MacBook example embedded.

Figure 2: One laptop’s journey from a serial number to an agent that actually helps. Courtesy: Claude Cowork

3. Where does the semantic layer physically reside?

Enough of theory. The biggest question that practitioners face is how to implement the concepts in a cost-effective manner. These layers should be persistent so they can be used by humans as well as agents interchangeably. Metadata has been persisted in data catalogs where it is often called a business glossary. However, as we go up the stack, the question of persistence becomes more nuanced, driven by the needs of usability, portability, and consistent governance. For example, irrespective of how and why data is consumed, the performance penalty as the usage scales should be minimal.

This is a tall order. We want to have our cake and eat it too. Some of these requirements involve trade-offs. Making the wrong decision can lead to these concepts falling out of sync with data and the investments going awry.

In this section we look at semantic layer persistence. We see each vendor category promoting itself as the best location. However, in reality there are pros and cons of where to store these concepts. The answer, predictably, is it depends. It depends on the size of the end-user base, how much and how often the data changes, who has the most intimate knowledge about the data and hence is most capable of keeping these concepts up to date.

Before we can even ask where the context layer will live, it helps to acknowledge that we haven’t resolved a simpler question: where does the semantic layer live today? The answer, as it turns out, is everywhere and nowhere:

• BI tool: The concept of semantics was first introduced in the early 1990s by Business Objects. Since then, every BI tool has claimed to be the best place to store semantics. Looker made a valiant effort in this space, but the poster child has been Microsoft’s Power BI which claims to have over 20M semantic models. The BI tools space is as active as ever: a relatively new BI tool, Omni, recently raised $120M at $1.5B valuation. Pros: most intuitive to the actual consumers who understand the data and its usage patterns. Cons: BI tool lock-in but may be incompatible with the AI agents that do not speak BI.
• Independent layer: No matter where the semantic layer exists, it will always cause some sort of lock-in. So, independent semantic layer vendors like AtScale and Cube.dev offer a standalone service that every consumer calls. Pros: provides an independent semantic layer that delivers consistency across any BI and AI consumer. Cons: adds to the sprawl of data tools and incurs some operational overhead.
• Data governance tools: Data catalogs like Collibra, Informatica, Atlan, Alation, and ServiceNow with the acquisition of data.world have always been the bastions for storing metadata, displaying lineage, and applying access policies. Their claim to storing semantics and now context is a natural progression, as seen in new offerings like Databricks’ Unity Catalog Metrics. Data governance tools also include master data management vendors like Profisee and Reltio (acquired by SAP), because MDM was designed to provide semantic consistency through the concept of a golden record. Pros: meaning sits next to lineage, policy, and the golden record, where stewards already work. Cons: catalogs traditionally describe rather than execute, so definitions can drift from how queries actually run.
• Data integration vendors: Most of the business logic within an organization is in the data integration layer and hence vendors like dbt (acquired by Fivetran) claim to be the place to store semantics. In fact, it has open-sourced MetricFlow under Apache 2.0 and uses Git to store metrics. Pros: great for lineage. Cons: less intuitive for business users.
• Data storage vendors: Both Snowflake and BigQuery have introduced a semantic layer that sits closest to the tables and gets enforced irrespective of the type of consumer. For example, AI agents can use protocols like MCP to access semantics. Pros: strong centralized governance. Cons: vendor-specific by definition.
• AI agent: Semantic understanding learned by the agent through prompt context and tool descriptions. This is where AI vendors are racing today. Pros: continuous learning. Cons: limited scope and immature space as yet.
• Enterprise platform vendors: The most integrated approach is from Palantir’s Foundry where the ontology lives inside the platform and is maintained by their own Forward Deployed Engineers. Pros: AI agents operate natively against a governed, operational ontology. Cons: the ontology is effectively rented, not owned. Governance lives in the vendor’s payroll, not yours.

Each of these layers is used by different personas such as data engineers, data analysts, data stewards, and business users. The option of creating semantics by only one persona is limiting as they have different priorities and knowledge about the business. This can lead to outdated semantics. Semantics need to be tested and versioned to avoid drift with respect to the underlying data. Luckily, this clean separation of where the semantic layer resides is starting to blur thanks to open standards.

4. What is the role of standards like OSI?

The dirty secret of enterprise data is that every tool reinvents its own version of the truth. The BI tool has its own metric library. The data catalog has its own glossary. The semantic layer in your transformation tool defines “monthly recurring revenue” one way. The semantic layer baked into your AI agent’s prompt template defines it another. Six tools, six definitions of MRR, and zero hope of consistency.

Standards break that cycle.

Open Semantic Interchange (OSI) is the most relevant one for this stack. OSI’s goal is to define a metric once, in a standard portable format, so that it is recognized everywhere, without manual remapping. If your “Active Customer” definition is OSI-compliant, your Tableau dashboard, your Snowflake semantic view, your LangChain agent, and your GraphRAG query all read the same definition. The definition is portable. As of May 2026, over 30 companies have signed up to support OSI, including Salesforce and Databricks.

OSI has introduced a new level of portability. For example, semantics defined in Snowflake’s Semantic Views have bi-directional read/write capabilities with BI tools like Hex, ThoughtSpot, and Omni. This gives different users an optionality of who creates versus maintains semantics and keeps them in sync across different layers of the stack.

OSI is part of a broader pattern. Delta Sharing is emerging as the open standard for data sharing across organizations. The Iceberg REST catalog is converging on the standard for table metadata. Model Context Protocol (MCP), originally introduced by Anthropic and donated in late 2025 to the Agentic AI Foundation under the Linux Foundation, has become the de facto standard for connecting AI agents to tools, data, and applications.

Ontologies are built from a stack of W3C standards. RDFS provides the basic class and property model. OWL provides the reasoning structures that let software infer new facts. SKOS handles vocabulary control for taxonomies and glossaries. PROV-O models provenance, the lineage of where a fact came from. On top of this stack sit the domain ontologies introduced earlier, Schema.org, FIBO, SNOMED CT, and GS1, each one a W3C-aligned vocabulary that a whole industry can share.

Standards are why “California” is “CA” in US postal codes and not “Canada.” Painfully, “CA” is Canada in ISO 3166, which is exactly the kind of ambiguity standards exist to govern.

For agentic AI specifically, standards become non-negotiable. An agent that calls five tools and traverses three data sources cannot afford to learn five proprietary semantic schemes. OSI, MCP, and the open table formats are the agent’s lingua franca.

5. How is the context layer built and persisted?

We have spent considerable time explaining aspects of semantics. Now it is the turn to understand how context layers are being built and stored today. The terms semantics and context terms are often used interchangeably. Hopefully, this blog has clarified that the context layer is much bigger than the semantic layer. And perhaps that is the problem. When the scope is too vast, it becomes hard to implement.

Frontier models treat context as ephemeral, assembled at runtime for a single agent turn and discarded. However, persisting context across sessions allows systems to answer common queries directly, cutting expensive LLM roundtrips and token cost.

In my upcoming book called Designing the AI-Driven Data Foundations, I have introduced the pattern Extract, Context, Link (ECL) to build a context layer:

• Extract: Context is scattered. It lives in structured databases, PDFs, email threads, chat logs, support tickets, product reviews, and web logs. So, the first requirement is simply the ability to access all of them. Established integration patterns (ETL, ELT, federation) were built for structured, tabular data queried through SQL by humans. They were never designed for this messy, multi-format landscape. ECL connects to every source without forcing you to first copy the data into one warehouse and extracts the entities and their metadata from each.
• Context: Reaching a source is not the same as understanding it. Once entities are identified, LLMs infer their semantics: what each entity is, what it means in your business, and how it relates to the others. This is where the 90 percent of enterprise data that is unstructured finally becomes usable. A parts-documentation PDF stops being a blob of text and becomes “defect pattern X, affecting batch Y, on product Z.” These contextual understandings are stored as ontologies in a catalog.
• Link: The final step unifies those extracted contexts into the enterprise’s memory through a knowledge graph. It links entities and context across databases, documents, and communication systems while respecting security policies and business processes. The payoff is a single endpoint an agent can query, through an API or MCP, instead of integrating a dozen systems by hand.

This is the quiet inversion underneath the move to context architecture. Classic RAG pushed data into the agent before the model ran, guessing in advance what it would need. The context layer flips that: the agent pulls exactly what it needs at runtime, through one governed endpoint. Retrieval does not disappear. It gets governed.

Bring this back to the defective MacBook Air call. Extract reaches the order database, the parts PDF, the web logs, the customer’s tweet, and the support search logs. Context pulls the meaning out of each: the customer, the serial number, the defect pattern, the sentiment, the intent. Link stitches them into one graph, so the agent sees a single connected story instead of several disconnected fragments. That linked, queryable view is the context layer.

One nuance worth keeping. When a dataset is produced inside your own organization, you can prescribe its context up front through a data contract that declares schema, field semantics, and quality thresholds. When data comes from outside that boundary, such as third-party feeds, partner data, or poorly governed internal sources with no owner, context cannot be declared. It has to be inferred. That inference is exactly what ECL automates.

Closing

A context layer sitting on top of ungoverned metadata and inconsistent semantics is just a faster way to be wrong. In this blog we covered the concepts of metadata, semantics, taxonomy, ontology, knowledge graphs, and context, but we have not tackled the topics enterprises care about most, such as security, governance, scale, and cost. Just as the semantic layer can exist almost anywhere in the stack, the context layer may end up distributed across several layers rather than living in one place. ECL is also only one way to build it; the pattern comes from my upcoming book, Designing the AI-Driven Data Foundations.

This is the first post in a series. Future posts will go deeper on topics such as memory.