Taxonomy, ontology, semantic layer, context layer: what's the difference?
Taxonomies, ontologies, semantic layers and context layers are showing up across analytics, integration and AI. Here’s what each one does, how they relate, and where Taxi and Orbital fit.
Marty Pitt@marty_pittAnalytics teams have been talking about semantic layers for a while. (So have we.)
But with the rise of AI, a wider set of terms - taxonomy, ontology, semantic layer, context layer - has moved into mainstream architecture discussions.
To make enterprise AI work at scale, it needs to understand more about how the organisation models its world: what things are, how they relate, where those concepts appear in real systems, and what matters for the task at hand.
So, here’s how we think about the terminology:
| Layer | What it answers |
|---|---|
| Taxonomy | What kinds of things exist, and how are they classified? |
| Ontology | How are those things related, and what can we assert about them? |
| Semantic layer | How do those meanings map onto the concrete data and capabilities in our systems? |
| Context layer | Given that semantic map, what is relevant right now, how do we get to it, and how can we act on it? |
These ideas aren’t coming from one corner of the market. dbt, Snowflake and Databricks have invested heavily in semantic layers for analytics and AI. Data catalogue vendors such as Atlan are talking about context layers. MCP has made exposing tools and capabilities to AI much easier - which makes the next problem more obvious:
Once an agent can reach hundreds of systems, how does it know how their data relates, what matters, and how they fit together?
So, let’s take a look at these concepts, and how they work together
A taxonomy is agreeing what to call things
Taxonomies are the smallest building block. They give us a way to name, define and classify concepts.
For example, a database might have a column:
email_address VARCHAR(255)or, if you’re unlucky:
eadd VARCHAR(255)The schema tells us how the value is stored; the field name only hints at what it means. Across systems, the same concept is often named differently. As we’ve written before, field names are a bad proxy for meaning.
A taxonomy gives that concept a stable name and definition, independent of any particular system.
type PersonalData
[[ An electronic mail address used to contact a person ]]type EmailAddress inherits PersonalData
type Name inherits PersonalDatatype PhoneNumber inherits PersonalData
// Taxonomies aren't limited to scalar values, but// Taxi usually keeps shared semantics scalar,// so systems can share meaning without sharing structure.type Partytype Person inherits Partytype LegalEntity inherits PartyThere’s more going on here than giving email_address a nicer name. We’ve defined what EmailAddress means, classified it as PersonalData, and created a vocabulary that can be shared across an organisation.
As we’ll see later, once that vocabulary is attached to APIs, datasets or catalogues, software can find data by meaning, apply governance rules, and recognise the same concept across otherwise unrelated systems.
Taxonomies can classify bigger business concepts too: Person and LegalEntity can both be kinds of Party. What they generally don’t describe is how those concepts relate. They don’t tell us that a person works for a legal entity, or that a billing account belongs to one.
That’s where an ontology adds more.
An ontology maps how the business fits together
Our taxonomy gave us some concepts: Person, LegalEntity, BillingAccount, Order, EmailAddress.
An ontology starts to describe what we know about those concepts - particularly the relationships between them.
relationship hasEmail: Person -> EmailAddressrelationship worksFor: Person -> LegalEntity
relationship belongsTo: BillingAccount -> LegalEntityrelationship hasContact: BillingAccount -> Person
relationship placedBy: Order -> BillingAccountPut together, those relationships form a model that software can navigate:
Person ──worksFor──> LegalEntity ↑ belongsTo │ BillingAccount ↑ ↑ hasContact placedBy │ │ Person OrderThis is a big part of why companies like Palantir put so much emphasis on ontologies. Once this knowledge is explicit, it becomes reusable: software can understand how an order relates to a legal entity, or how a person relates to an account, without reconstructing that knowledge from API names and schemas each time.
Ontologies tend to be abstract
Importantly, none of this says anything about where the data lives. Ontologies usually describe the domain independently of the systems that implement it.
Person worksFor LegalEntity is a statement about the business. It doesn’t say that a Person JSON object contains a worksFor field, or that the relationship lives in the CRM.
That’s useful: the model can stay stable while systems change underneath it. But there’s a trade-off:
If the ontology remains entirely abstract, you now have two representations of the organisation: the conceptual model, and the collection of systems that actually implement it.
Those two can drift. The ontology may describe customers, accounts and orders beautifully, while the real implementation is scattered across API fields, database joins, event payloads and application logic.
Taxi keeps the ontology abstract without leaving it disconnected from the real systems. Schemas can explicitly link themselves to the concepts and relationships they implement.
That bridge between the abstract model and the concrete data and capabilities in your systems is the semantic layer.
A semantic layer connects the abstract model to real systems
So far, the taxonomy and ontology have been abstract. A semantic layer connects those concepts to the data and capabilities that actually exist in our systems.
This idea is already familiar in analytics
Tools such as dbt let teams define entities, dimensions and metrics over warehouse models, so concepts such as NetRevenue don’t have to be reimplemented independently in every dashboard or report.
A simplified dbt definition might look something like:
semantic_models: - name: sales model: ref('fct_sales')
measures: - name: gross_revenue agg: sum expr: gross_amount
- name: credit_notes agg: sum expr: credit_note_amount
metrics: - name: net_revenue type: derived type_params: expr: gross_revenue - credit_notes metrics: - name: gross_revenue - name: credit_notesTaxi supports the same idea of making business calculations reusable, although it models them as semantic types:
type GrossRevenue inherits Decimaltype CreditNotes inherits Decimal
type NetRevenue = GrossRevenue - CreditNotesThe abstractions are different - dbt is purpose-built around analytical models, aggregations and joins - but the principle is the same: give business meaning and logic a stable definition, then connect it to the data that implements it.
The same idea applies to operational systems
Suppose our ontology contains:
relationship hasEmailAddress: Person -> EmailAddressrelationship worksFor: Person -> LegalEntityAnd the CRM exposes:
model EmployeeRecord satisfies Person { email: EmailAddress? employer: CompanyRecord?}
model CompanyRecord satisfies LegalEntityEmployeeRecord is a concrete schema; Person is the abstract concept it represents. Likewise, employer is a field in that schema, while worksFor is the more general relationship in the ontology.
Another system might realise the same relationship through a database join, identifier or API call; the ontology stays the same.
The semantics can live with the schemas you already have
This doesn’t require replacing OpenAPI, Avro or Protobuf. Taxi metadata can be embedded directly into those formats:
components: schemas: EmployeeRecord: type: object properties: email: type: string x-taxi-type: name: acme.EmailAddressThe existing specification remains the source of truth for structure; Taxi adds the connection back to the shared taxonomy and ontology.
The ontology says Person worksFor LegalEntity. The semantic layer tells us how that statement is realised in the systems we actually have.
A context layer surfaces what’s relevant now
At this point we have a semantic map of the organisation: what things mean, how they relate, and where they can be found.
A context layer uses that map to surface the information relevant to a particular request.
For example:
Jimmy’s on the phone. Show me his open orders, unpaid invoices, and outstanding support tickets.
The context here spans multiple domains: Jimmy himself, his orders, invoices and tickets, plus things like permissions, provenance and authoritative sources.
There are two broad ways to provide it.
One is to copy the data into a central store - a warehouse, knowledge graph or index - and query it there. That makes querying simpler, but requires pipelines to keep another copy of the data in sync, and that copy can become stale.
The harder approach is to fetch context from systems of record when it’s needed: find Jimmy in the CRM, use that result to call the Orders API, query invoices from a database, then fetch tickets from support.
That’s harder than querying data loaded into Snowflake overnight. But the source systems remain authoritative, the data stays where it belongs, (avoiding vendor lock-in), and the context reflects what’s true now.
TaxiQL describes the context you want
TaxiQL is designed around this second model. A query describes the data required in semantic terms, without specifying which APIs or databases should provide it:
given { EmailAddress = 'jimmy@demo.com' }
find { Person } as { name: PersonName orders: Order[](OrderStatus == 'OPEN') invoices: Invoice[](InvoiceStatus == 'UNPAID') tickets: SupportTicket[](TicketStatus == 'OPEN')}There’s deliberately no JOIN, API URL or service name in that query.
Using the semantic layer, a runtime such as Orbital can work out a route through the available systems: perhaps looking Jimmy up in the CRM, using the identifiers it discovers to call the Orders and Support APIs, and querying invoices from a database. The query describes the context required; the runtime works out how to assemble it.
That’s the distinction: the semantic layer tells us how the organisation’s concepts map onto its systems. The context layer uses that map to assemble what’s relevant for the task at hand.
Why AI has pulled these ideas together
Analytics teams made business meaning explicit because otherwise different reports produced different answers. Integration teams have always needed the same kind of knowledge across systems, but much of it ended up buried in mappings, transformations and orchestration code.
AI has both problems at once. An agent needs to understand what the data means, but it also needs to navigate across systems to find or change it.
MCP helps with one part of that problem by standardising how AI applications discover resources and invoke tools. It doesn’t tell an agent what your company means by Customer, which source is authoritative for an order, or how the output of one operation relates to the input of another.
We’ve seen the practical effect in our own orchestration benchmark: planning accuracy dropped to unusable levels once agents faced a few hundred plain OpenAPI endpoints, and recovered when we added semantic metadata.
That’s why these previously separate ideas are starting to converge. AI needs both the meaning of the organisation and a way to apply that meaning across the systems where work actually happens.
Where Taxi and Orbital fit
Taxi gives us one language for the first three parts of this picture: shared concepts, relationships, and the mappings from those concepts onto APIs, databases and streams.
Orbital is the runtime piece. It uses those definitions to fulfil requests against the systems available at query time - working out which operations to call, how data flows between them, and assembling the context the consumer asked for.
That’s why we think of Orbital as a context layer built on an operational semantic layer. Taxi describes the map; Orbital uses it.