Ontology by Another Name: Why BI "Semantic Layers" Are Just Narrow TBoxes — and R2RML Is the Open Path Out

Virtuoso Universal Server Tips, Tricks, and HowTos
, , , ,
1

Infographic

The vocabulary problem

Walk into a conversation about modern data architecture and you’ll hear “semantic layer” and “context layer” used constantly—often interchangeably, and occasionally as if they name two entirely different architectural components.

In my view, they don’t—or at least, they don’t have to.

In the vast majority of cases, both terms point to the same basic idea: a layer above raw storage where the meaning of data—what a Person is, what worksFor implies, and how orders relates to customers—becomes explicit instead of remaining locked inside table names, foreign keys, and application code that only a human or hard-coded query can interpret.

There’s already a well-established name for that layer and for the two things that live inside it: an ontology. It’s the term I’ve spent much of the past 20-plus years arguing should play a larger role in industry vocabulary.

What an ontology actually is

An ontology defines the nature of entities and relationships in a discourse domain. It has two components, and the distinction between them matters more than most BI vocabulary acknowledges:

  • TBox (terminological box)—the schema itself: classes, properties, domain and range constraints, and hierarchies. The TBox declares that a Person is a kind of Agent, that worksFor relates a Person to an Organization, and that revenue is a measure with a currency and a time grain.
  • ABox (assertional box)—the instance data expressed using those terms: :Ian a :Person ; :worksFor :OpenLink.

Their full value emerges when they are used together. A collection of facts without an explicit TBox leaves much of its intended meaning implicit, limiting consistent interpretation, federation, and inference. A TBox without an ABox provides a vocabulary and conceptual model but contains no domain-specific assertions. Together, they turn raw data into something explicitly described and machine-computable.

The BI “semantic layer” is a TBox wearing a different name

This is the part that clears up the confusion for me. When a contemporary Semantic Layer YAML model defines metrics, dimensions, entities, and joins, it is performing a TBox-like role. It declares terms and their relationships so that a question such as “revenue by region” resolves correctly, without the person asking it needing to know the underlying table structure.

What makes it narrower than a full ontology is threefold:

  1. Scope. It is built primarily for reporting, analytics, and metric resolution—not for general-purpose reasoning about the domain.
  2. Semantic fidelity. Although Semantic Layer YAML has emerged as a de facto open standard, its model remains largely confined to metrics, dimensions, entities, and joins. It lacks the richer class axioms, property semantics, constraints, identity relations, and inference capabilities provided by open standards such as RDF Schema (RDFS) and the Web Ontology Language (OWL).
  3. Connectivity. Its assertions remain anchored to the tables and execution environments of participating analytics systems. It does not inherently give entities globally resolvable identifiers or make them natively linkable to external knowledge graphs, ontologies, and independently governed data spaces.

None of this makes it fake or less effective at its intended job. Semantic Layer YAML is a useful de facto open standard and a purpose-built TBox-like layer. But calling it a “semantic layer,” full stop, obscures its fundamental semantic-fidelity and connectivity limitations.

It remains a special case of something more general—and that general case already has standards, tooling, and decades of formal groundwork behind it. That is groundwork my company has been building against for a very long time.

R2RML: the open equivalent, minus the semantic and connectivity constraints

If Semantic Layer YAML is a narrow, de facto open TBox-like standard, the natural question I keep coming back to is: what provides the same practical mapping function without sacrificing semantic fidelity or connectivity?

That is R2RML, the W3C Recommendation for expressing customized mappings from relational databases to RDF datasets.

An R2RML mapping does not, by itself, constitute an RDFS or OWL TBox. Instead, it connects relational tables, columns, keys, and joins to the classes and properties of a chosen target vocabulary:

  • The target vocabulary—typically defined using RDFS, OWL, or both—supplies the TBox.
  • Executing or virtualizing the R2RML mapping supplies the ABox: actual RDF triples representing facts derived from relational rows.
  • The mapping document itself is an RDF graph, written in Turtle, that specifies how relational structures generate those RDF terms and assertions.

The practical difference is not simply openness. Semantic Layer YAML is already a de facto open standard. The deeper differences are semantic fidelity and connectivity.

An R2RML mapping can connect relational data to vocabularies with formally defined classes, properties, identity relations, constraints, and inference semantics. It can also assign globally resolvable IRIs to entities, making them linkable across systems, knowledge graphs, and independently governed data spaces.

The resulting RDF can be queried using SPARQL, reasoned over using the semantics of its vocabulary, and federated with other knowledge graphs by any compatible engine.

It doesn’t merely standardize the description of a semantic layer; it makes the resulting entities and relationships interoperable beyond the analytics environment that produced them.

That “virtualized” qualifier matters. It is the point I tried to make concrete in my 2018 piece on conceptual relational data virtualization, using our own Virtuoso engine.

My starting premise there cuts beneath the entire SQL-versus-graph-database framing: data is fundamentally an expression of entity–relationship types—relations—and tabular and graphical are simply different representations of the same underlying thing, not two competing kinds of database. SQL and SPARQL are both declarative languages for operating on relations; they simply default to different surface representations.

Virtuoso exploits that equivalence directly. Instead of relying on a one-time ETL process that copies relational rows into a separate triple store, R2RML mappings can be loaded into Virtuoso as RDF and processed into Quad Maps—native mapping rules that its SPARQL query engine consults at query time.

A SPARQL query against the “RDF view” of a Suppliers table does not need to read from a pre-materialized copy. It can be rewritten dynamically against the actual SQL rows, which may be local or accessible through an ODBC or JDBC connection to a remote RDBMS.

Add a URI-rewrite rule, and each row can become independently dereferenceable: retrievable over HTTP as its own RDF entity description, with content negotiation selecting among representations such as Turtle and RDF/XML.

That is what “conceptual data virtualization” is pointing at: the semantic model, the R2RML mapping or Quad Map, and the query-time RDF view over live rows can work together without requiring a separate copy of the data.

It is my practical rebuttal to the assumption that moving from a narrow Semantic Layer YAML model to an open, standards-based ontology requires an expensive migration. R2RML, combined with a processor such as Virtuoso’s, gets you there as a view, not a rewrite.

The part that changes the economics

Standards arguments are easy to nod along to and hard to act on because authoring R2RML mappings has historically required expertise that most teams do not have readily available. That is the part that has changed—and it has changed faster than I expected.

LLMs can now generate useful R2RML mapping drafts from either of two starting points: a raw SQL schema in DDL form or an existing Semantic Layer YAML model.

The second case is the more interesting one to me because it performs the exact translation this argument points toward: an LLM reads a narrow, de facto open TBox-like model and re-expresses its intent using an open W3C mapping standard and a semantically richer, globally connected target ontology.

This preserves the practical value already captured in the Semantic Layer YAML model while addressing its fundamental semantic-fidelity and connectivity shortcomings.

As with any generated integration artifact, the result should still be validated against the source schema, target vocabulary, and representative queries.

What once required a modeler to author mappings manually—table by table and relationship by relationship—can now begin as a generation step. Combined with virtualized execution, which requires neither a data copy nor a migration window, that substantially reduces the two main practical barriers to moving beyond a conventional semantic layer: authoring cost and infrastructure cost.

Where “context layer” fits—and where it doesn’t

“Context layer” muddies things further. This is the piece I found myself untangling most directly because the term is used in two different ways, often by the same vendor in the same breath:

  • Sometimes it is a straightforward rebranding of the same narrow TBox: metrics and dimensions dressed in different marketing language.
  • Increasingly, it means something else: the substrate that informs an AI agent’s behavior—memory, often stored literally in .md files; execution traces; stored preferences; and prior session state.

The second meaning dominates much of today’s agent-tooling discourse, and it is the real source of the apparent deviation. It sounds like a wholly different concern from a BI semantic layer—unrelated in kind rather than merely different in scope.

But that appearance of unrelatedness does not survive inspection, at least not for me. Memory, traces, and preferences are not another category of thing sitting outside an ontology’s reach. They are entities with relationships, just like anything else in a domain model.

A preference has a subject—the user or agent to which it belongs—a scope, a provenance, and a relationship to the rule or action it constrains. A trace is an event with an agent, timestamp, inputs, outputs, and causal links to prior events.

Memory consists of structured assertions of exactly this kind: a TBox defining memory types and provenance relationships, with an ABox containing the asserted instances.

The “confusing deviation,” then, is not that agent context is fundamentally different from a BI semantic layer. It is that agent-context tooling tends to represent context informally—as flat files, prose, or ad hoc key-value stores—rather than as declared entities and relationships.

That is a representational choice, not an ontological one.

The moment memory, traces, and preferences are modeled with a TBox and asserted as an ABox, the “context layer” collapses back into the same pattern as everything else in this argument: an ontology applied to a different subject matter—agent behavior and history rather than business metrics.

A working example: agent-rdf-memory

This is not merely a theoretical claim for me—I have been building it.

My agent-rdf-memory project makes this move concrete: an AI agent’s context layer—memory, preferences, execution history, and behavioral rules—built as an ontology rather than the usual collection of Markdown files.

Structurally, it contains both halves:

  • A TBox in ontology.ttl. Instead of relying on an implicit folder convention, I declared a vocabulary using RDFS and OWL classes and properties such as :PromptIntent, :RetrievalPolicy, :MemoryWriteTrigger, :ContextSource, and :SessionSymbolNode. These terms are defined with domains, ranges, and comments. A :MemoryWriteTrigger, for example, is modeled as a subclass of both prov:Activity and event:Event, reusing the W3C PROV-O ontology and the Event Ontology rather than inventing parallel concepts from scratch. Prompt intents such as :VirtuosoSparqlTroubleshooting, :RdfAuthoringTask, and :KgExplorerTask declare relationships including :routesToTopic, :requiresHowTo, and :preferredContextSource. This provides the schema for mapping a prompt to relevant memory before any specific fact is retrieved.
  • An ABox across preferences.ttl, sessions/, entities/, and howto/*.ttl. Behavioral rules are represented as schema:HowToStep instances; sessions, messages, people, organizations, and concepts are assigned entity IRIs and described using the TBox’s terms. These are machine-readable assertions, not merely prose describing them.

The result is memory that is queryable rather than merely readable.

The retrieval protocol I built prefers SPARQL: classify the prompt’s intent, follow :routesToTopic and :requiresHowTo to the relevant subset of the graph, retrieve recent session context through :requiresRecentSession, and fall back to direct file reads when no endpoint is available.

That is the practical payoff of treating context as an ontology instead of a memory folder. The same reasoning, federation, and query benefits that apply to any TBox/ABox pairing apply here too—just pointed at “What does this agent know, and why?” instead of “What does this business mean by revenue?”

It is a small-scale, single-project example of the same triangulation I am making throughout this piece: something that appears, on the surface, to be a new and different kind of “layer” turns out, once modeled properly, to be an ontology wearing a job-specific name.

Triangulating the terms

Putting it together, here is where I’ve landed:

  • Ontology is the general case: a TBox describing terminology paired with an ABox containing assertions, together making a domain’s entities and relationships explicit and machine-computable.
  • BI’s “semantic layer” is a narrow, TBox-like model purpose-built for analytics and metric resolution. Its contemporary YAML representation has become a de facto open standard, but it still offers limited semantic fidelity and connectivity: its concepts remain largely confined to metrics, dimensions, entities, joins, and their associated analytics runtimes.
  • R2RML is the open W3C mapping mechanism that connects relational data to semantically richer and globally connected RDF vocabularies. It can generate or virtualize an interoperable RDF ABox whose entities have resolvable identifiers and can participate in reasoning, federation, and links across independently governed data spaces. Critically, it does not require a migration. As our Quad Map approach in Virtuoso demonstrates, the ABox can remain virtual—a live, SPARQL-queryable, dereferenceable RDF view generated at query time over unchanged relational rows rather than a duplicated copy.
  • The “context layer”—agent memory, traces, and preferences—looks like a different category only because it is usually represented informally. In substance, it is the same pattern again: entities and relationships that an ontology can define and RDF can represent, applied to agent behavior rather than business data, as my agent-rdf-memory project demonstrates in practice.

The terminology is not actually as fractured as it sounds to me. It is one idea—ontology—appearing at different points on a spectrum of scope, semantic fidelity, connectivity, openness, and subject matter.

Sometimes it is constrained by an analytics runtime; sometimes it is left informal enough to look like something else entirely.

Now that mappings can be virtualized and increasingly generated, limited semantic fidelity and connectivity are becoming choices rather than unavoidable defaults.

Once you separate these threads, “semantic layer” and “context layer” stop being a mystery and start looking like what they have always been: ontologies scaled down, sometimes constrained by their runtimes, and sometimes simply left undeclared.

Video presentation

Related

Agent-generated reports

Each of these reports was generated by an AI agent constrained by an RDF-based context and memory layer—a harness designed to promote consistent, contract-constrained outcomes.

Additional information