This blog is based on a “deleted scene” but is also an update to the technology mentioned in my book, Semantic Webs of Meaning—specifically Chapter 8 on scaling query performance for a knowledge-graph deployment. In that chapter I did not talk about the contribution a performance-oriented semantic layer (ex. Kyvos) can make. The book is about knowledge graphs. The missing piece was what happens when the semantic layer reaches beyond its information-centric core competency towards a knowledge-centric knowledge graph.
Notes:
- A disclosure: I work for Kyvos as a Principal Solutions Architect. I have also spent much of my career (mostly the last 25 years) developing and writing about the ideas discussed here, including years before I joined Kyvos. I am not presenting Kyvos as a disinterested observer. But I genuinely believe in its pre-aggregated semantic layer, and now its movement toward explicit knowledge.
- Some of the figures are very busy. For a full view, click on the Figure, and hit the Browser’s back arrow to return to this article.
- If purchasing Semantic Webs of Meaning from the Technics Publications website, use the code TP25 for a 25% discount.
- I need to clarify that what I refer to “AI” (“LLM systems”) is pretty much the LLM-centric AI of today—commonly, LLMs embedded with RAG processes, chain of thought, and/or chat environments such as ChatGPT and Grok.
Introduction
Whenever a component of a system is “pulled closer” to an adjacent component, performance usually improves—at least the opportunity for continued improvement is planted. The two sides share more context. There is less marshalling of data across a boundary. There is more room for a single planner to choose the cheapest path. That advantage is larger still when both components live under one builder, because the optimizations do not have to stop at a published interface.
A modern example is Databricks’ use of query pushdown, a version of the broader idea of “bringing the logic to the data”. Instead of repeatedly moving large amounts of data to some distant place to be processed, computation is brought to where the data already lives. This is query pushdown, where filters, projections, aggregations, joins, and other operations are translated into work that can be executed by the system holding the data rather than after the data has been moved.
The idea is much broader than databases. It applies to any system/process components, whether in manufacturing, shipping of goods, or shopping for goods. We see it whenever adjacent capabilities are brought together so that a large handoff disappears. A smartphone combined the camera, photo album, editing tools, communications, GPS, and maps that once lived in separate devices and processes. A modern online store can connect the storefront directly to inventory, payment, fulfillment, and shipping instead of requiring people or files to bridge each step. Even something as ordinary as a supermarket bakery closes the gap between producing something and selling it. What once required a bakery, packaging, transportation, receiving, and stocking can happen within the same operation.
The individual components do not necessarily become better at their specialties. The supermarket bakery does not have to be the world’s greatest bakery. The value comes from eliminating the large jumps between components. The result is an in-house bakery that can fulfill the requirements of say, 90% of customers 90% of the time.
Note: I’d like to acknowledge that this means independent bakeries would have a harder time staying in business, which means that the 10% of customers who insist on an extra level of quality only independent bakeries can provide might no longer have that choice.
Information doesn’t have to be translated, transported, rediscovered, reconciled, and governed again every time it crosses a boundary.
That is a kind of vertical integration I mean here. Bringing KG capability closer to the semantic layer does not require the semantic layer to acquire built-in graph capability on par with first-tier KG platforms such as Stardog, Neo4j, or GraphDB. It does not need to hold all of Wikidata and DBpedia, support every conceivable graph workload, or become the enterprise repository for everything that can possibly be expressed as a graph. It only needs to handle enough of the common work locally that every graph-shaped question does not require a trip across a major architectural boundary.
Once those two capabilities are close enough, several more technical advantages follow:
- Shared identity, not a join after the fact. If a customer, product, or region already has a governed identity in the semantic layer, the graph should not have to rediscover that identity through fuzzy matching at query time.
- Pushdown instead of export. A graph question that is really a slice—customers who are also suppliers, SKUs in a delayed plant, regions above a threshold—can be answered from pre-aggregates rather than by shipping detail into a separate triple store.
- One planner, two shapes of work. Cube navigation and graph traversal are different, but they are not enemies. A builder that owns both can decide, for a given question, whether to walk edges, hit an aggregate, or do a little of each.
- One definition, many consumers. A measure authored in the semantic model should be the same object a rule, a causal path, or an agent refers to. Re-implementing “revenue” in the graph is how semantic drift begins.
- Governance that travels with the question. Security, lineage, and certified logic already exist in a serious semantic layer. Moving knowledge next to that layer means those controls do not have to be reconstructed on the other side of an export.
- Less translation tax. Every hop between cube, warehouse, catalog, and graph is a chance to lose grain, rename a member, or freeze a snapshot that is already stale. Closeness removes hops.
That is very different from an architecture in which every graph-related question requires a remote call, often with substantial transference of data. Even if the local graph answers only the common portion of the workload, avoiding that boundary most of the time can improve performance substantially. The specialized system remains available for what it does best without requiring every question to pay the cost of leaving the semantic environment.
From Data to Wisdom
The familiar progression from data→information→knowledge→understanding→wisdom (DIKUW) is not a clean pipeline in which one technology supersedes the previous one. Each level continues to depend upon and feed back into the others. What is especially interesting to me now is that Kyvos, traditionally very strong in the semantic layer portion of this picture, is beginning to extend beyond governed information and into explicit knowledge through its forthcoming knowledge graph capabilities.
Flow from Data to Wisdom
Figure 1 is intended to show an evolution rather than a replacement. The highlight of Figure 1 is the item marked as “Semantic Layer KG” in magenta. It depicts a KG derived from the semantic layer. It consists of the entities, attributes, relationships between entities and attributes, as well as other things that might be found in a semantic layer—but exposed in graph form. In graph form, other KGs can, to various levels of ease, extend into it.
Towards the middle-left of Figure 1, operational databases and event hubs provide data. A semantic layer such as Kyvos transforms much of that raw detail into information: governed measures, dimensions, hierarchies, calculations, and aggregates that answer questions such as how much, how many, where, and when. Machine learning takes another path upward from the data. By discovering statistical patterns that were not explicitly authored, it can provide a kind of inductive understanding. It can infer from examples that things tend to behave a certain way, but its understanding remains statistical rather than logical.
Note that the Semantic Layer contributes to machine learning as well as data. The semantic layer can provide much training data in a highly-performant manner. That is great for multiple training rounds.
The KG represents another step upward. It is not simply another place to store data. It makes relationships, classifications, rules, provenance, meanings, and other knowledge explicit. The semantic layer can contribute governed information to that graph, while machine learning can contribute discovered patterns or classifications. In the other direction, the KG links that analytical information into rich context. This is where the movement from Cube Space (semantic layer) toward Insight Space becomes important: the semantic layer tells us what the numbers are, while the KG can retain what those numbers mean, how they relate, and what has been learned from them.
I already mentioned “inductive understanding”, but there are three types of understanding represented in Figure 1, described in Table 1. But note that I use understanding functionally here: the ability to integrate what is known into a usable model or interpretation, not as a claim about consciousness or subjective experience.
| Understanding | Primary Component | Short Description |
|---|---|---|
| Inductive Understanding | Machine Learning | Learns patterns from data by generalizing from examples. It can identify tendencies, similarities, classifications, and predictions, but its understanding is statistical rather than explicitly logical. |
| Deductive Understanding | Reasoner | Derives conclusions that logically follow from explicit facts and rules in the knowledge graph. It is more exact and explainable than machine learning, but limited to what has been formally represented. |
| Contextual Understanding | Artificial Intelligence / LLM | Interprets meaning by combining language, background knowledge, retrieved facts, statistical regularities, and the immediate situation. It is broader and more flexible than deductive reasoning, but less deterministic. |
Formal reasoners such as Pellet or HermiT, and logic/rule systems such as Prolog, can derive conclusions from explicitly represented facts, axioms, and rules. I label this deductive understanding because, given a set of facts and rules, the reasoner can derive what logically follows from them. This is much more exact and explainable than statistical inference, but also more brittle. It can only reason from what has been explicitly represented.
One thing deliberately missing from Figure 1 is the interface layer. These components are not normally consumed by people staring directly at their internal structures. A semantic layer may be reached through Tableau, Power BI, Excel, SQL, MDX, APIs, agents, or custom applications. A KG may be reached through SPARQL, graph APIs, reasoners, applications, or agents. ML models similarly appear behind APIs, applications, analytical tools, or other services.
Those interfaces are important—without the interfaces, there cannot be integration. But I have omitted them from the figure because they are primarily ways into the capabilities shown here, rather than additional levels in the DIKUW progression. For example, Tableau does not itself become another node between information and knowledge simply because it displays information from the semantic layer. Likewise, an API into a KG is an access path to knowledge rather than another kind of knowledge.
In real life, however, those interfaces matter greatly because they allow the same underlying information and knowledge to be reused by many consumers. A person working in Tableau, an application calling an API, and an AI agent may all be approaching the same governed semantic model or KG through different doors.
As I’ve mentioned in many blogs and my books, there is a compelling symbiotic relationship between AI and KGs. The KG can ground AI by supplying explicit enterprise facts, definitions, relationships, rules, and context. That helps constrain an LLM’s much broader but less exact reasoning. In the opposite direction, AI can help extend and author the KG.
But I do not mean that an LLM should simply write enterprise truth directly into it. AI is better viewed as assisting human KG authors: proposing relationships, extracting candidate facts, recognizing possible classifications, suggesting missing links, and helping people express what they know more efficiently. Human judgment remains in the loop before those suggestions become trusted knowledge. The KG should be seen as an explicit, governed reference point presented to AI, including hard constraints and rules where appropriate.
That is why I call the AI layer contextual understanding. It is more flexible than a deductive reasoner and broader than a statistical model—with the downside common to all non-deterministic computations. An LLM can combine background knowledge, language, analogy, statistical regularities, retrieved facts, and the immediate situation to form an interpretation.
It can also perform something resembling abductive reasoning: given a collection of observations, what explanation might best account for them? A capable human does this naturally as well. The advantage of AI is breadth and speed. AI’s disadvantage is that its conclusions can be probabilistic and unsupported. Formal deduction avoids that particular problem by making conclusions follow explicitly from represented premises and rules—although bad premises can still produce bad conclusions.
Human intelligence sits at the widest point of the figure because people participate at every level. Humans generate much of the material used to train AI—documents, code, images, audio, video, and other artifacts. They also create and refine semantic models, author knowledge, evaluate machine-learning results, and decide what conclusions matter. And, for consequential decisions, humans remain the parties ultimately responsible for deciding what authority AI should have and for the real-world consequences of that authority.
At this upper end I use wisdom deliberately. Wisdom involves more than recognizing patterns, applying logic, or assembling context. It includes judgment about goals, consequences, trade-offs, values, and what should actually be done. AI can certainly influence that level and can sometimes produce conclusions that appear remarkably wise, but the responsibility for what becomes trusted knowledge and what actions follow from it still belongs primarily to people.
Examples from Wisdom Drilling Down to Data
The distinctions along the DIKUW progression can feel abstract when presented only as definitions. It may be easier to present examples, starting at the top (wisdom)—with topics we readily recognize as expert judgment—and work downwards to see what supports it.
For each example, ask what the expert is actually deciding. Then move downward: What understanding of the system makes that decision possible? What relationships constitute the knowledge behind that understanding? What information was derived to establish those relationships? And finally, what observations supplied the underlying data?
This is illustrated in Table 2.
| Level | Doctor | Lawyer | Martial Artist |
|---|---|---|---|
| Wisdom | Chooses a treatment plan for this patient: which treatment to use, what not to use, when to intervene, which risks are acceptable, and what to monitor afterward. | Chooses the legal strategy: which arguments to emphasize, what to concede, whether to negotiate or litigate, what risks to accept, and when a technically valid tactic would be strategically unwise. | Chooses the appropriate technique—or decides not to attack—at this particular instant, while anticipating counters, trade-offs, and likely next states. |
| Understanding | Sees the patient as a system: condition, symptoms, age, other diseases, medications, interactions, likely progression, and possible responses to treatment. | Sees the case as a system: facts, law, evidence, procedure, opposing arguments, remedies, deadlines, costs, and possible responses from the other side. | Sees the encounter as a changing system of balance, movement, leverage, timing, intention, possible attacks, counters, and reactions. |
| Knowledge | Knows relationships such as: this symptom is associated with this condition; this drug affects this pathway; this treatment improves one outcome but increases another risk. | Knows relationships among facts, rules, and precedent: this fact satisfies this legal element; this precedent interprets this statute; this evidence strengthens or weakens this argument. | Knows relationships learned through training and experience: pressure in this direction creates an opening there; breaking balance this way makes this throw possible; this response invites that counter. |
| Information | Study results, risk scores, response rates, averages, ranges, classifications, trends, and other functions applied to clinical observations. | Timelines, damages calculations, document classifications, case searches, summaries, deadline calculations, and other derived results from the legal record. | Assessments derived from sensory observations: balance is shifting forward, distance is closing, pressure is increasing on one side, momentum is changing, or an opening is developing. |
| Data | Individual symptoms, temperatures, blood pressure, lab values, imaging results, treatment outcomes, and the patient-level observations making up clinical studies. | Dates, contracts, emails, testimony, transactions, filings, statutes, regulations, and individual facts in prior cases. | Stance, grip, foot position, distance, direction of force, timing, pressure, movement, and the opponent’s reactions. |
Looking at Table 2 from top to bottom also shows why I do not think wisdom is simply “more knowledge”. The doctor may know hundreds of treatments, the lawyer hundreds of precedents, and the martial artist dozens of techniques. Wisdom is the ability to select appropriately from that accumulated solution space for the situation at hand.
That selection also constrains the search space. The expert does not seriously consider every treatment, legal maneuver, or martial-arts technique. Knowledge and understanding have already eliminated most of them. Wisdom focuses attention on the relatively small region of the solution space that makes sense here.
Beyond wisdom is creativity. Sometimes the expert reaches the end of that constrained solution space and still does not have an adequate answer. That is where System ⅈ, curiosity, analogy, abduction, and invention can take us beyond wisdom.
Semantic Layers Reaching from Information to Knowledge
The important point for semantic layers such as Kyvos is that they are no longer just the only interface between human analysts and data/information sources. A high-performance semantic layer already transforms data into governed information. Adding KG capabilities allows that same foundation to reach upward into explicit knowledge, while AI and formal reasoners provide different kinds of understanding over it. The interesting architecture is therefore not BI or knowledge graphs or AI, but the interaction among them: fast governed information underneath, explicit knowledge in the middle, multiple kinds of reasoning above it, and humans continuing to supply judgment and direction.
For Machine Learning to KG, the idea is that both the “rules” of the model and the outputs can be defined in the KG. LLMs can then access that information in one place, as described in Machine Learning Models in Knowledge Graphs.
Lastly, note that AI can use all of the other items as sources shown in Figure 1 within its RAG process.
Wisdom in AI
Believe it or not, not all decisions and actions of humans are wise and AI can appear to be wise more than occasionally. What appears to be wisdom from AI will only continue to grow. But for now, I’d rather AI didn’t directly exercise its “wisdom”, instead offering it as advice to people. AI systems do not share the continuous embodied needs, consequences, emotions, and lived history from which human judgment develops. They can model and express those things remarkably well, but that is not sufficient reason to treat their judgment as equivalent to human experience. Not yet, anyway.
From Information Toward Knowledge
Kyvos has recently begun announcing upcoming (not yet released) features that reaches out from information of the semantic layer towards knowledge of the semantic web. Figure 2 is a snapshot of the Kyvos home page as of this writing (September 30, 2026).
Its upcoming Business Knowledge Graphs are described as connecting KPIs, entities, concepts, and knowledge through rules, weights, and causal paths. Kyvos places that capability alongside its semantic model—which defines metrics, dimensions, hierarchies, and business logic—and unstructured business knowledge such as policies and playbooks.
This bridge from semantic layer to KG helps bring closer the KG hero of my book Semantic Webs of Meaning to the KG sub-component of Enterprise Intelligence.
Note:
- A semantic model defines how concepts and data should be interpreted—for example, measures, dimensions, hierarchies, calculations, classes, properties, and relationships.
- A semantic layer operationalizes and exposes that modeled meaning consistently to people, BI tools, applications, and AI.
- The Semantic Web is the broader standards-based approach—using technologies such as IRIs, RDF, RDFS, OWL, and SPARQL—for expressing and connecting machine-readable meaning across systems. See FAQ. Kyvos is both semantic model and semantic layer.
I don’t see that as abandoning BI for something new. I see it as continuing the climb. Detailed databases supply data. A cube or semantic model transforms enormous quantities of that data into governed business information—the sum of this, the count of that, sliced by these dimensions under these definitions. A KG can carry that farther by explicitly representing what things are, how they relate, what rules apply, and eventually what has been learned about them. The information produced by BI becomes material from which knowledge can be constructed. Understanding and wisdom still belong to the reasoners working over that material—people, AI, and other reasoning systems.
Once these features are released by Kyvos, I will write about it in more detail.
Related Kyvos Material:
- Business Context for AI — Kyvos’s current description of its Semantic Model, Unstructured Knowledge, Business Knowledge Graph, and Governance as parts of a larger business context for AI. The Business Knowledge Graph is described as connecting KPIs, entities, concepts, and knowledge through rules, weights, and causal paths.
- Understanding Semantics, Relationships, Ontology, Knowledge Graphs & Business Context for Enterprise AI — Distinguishes semantics, relationships, ontology, knowledge graphs, and the broader Business Context and explains how Kyvos intends them to work together.
- Kyvos AI Space — Describes AI Space as combining business context with analytical tools, including business relationships, causal graphs, graph traversal, knowledge lookup, root-cause analysis, anomaly detection, and other reasoning-oriented capabilities.
- Semantic Data Models for Enterprise-Scale Analytics — Useful for the information side of your argument: measures, dimensions, hierarchies, calculations, relationships, and business rules in the semantic model.
From the Semantic Layer into the Knowledge Graph World
Figure 3 shows the semantic layer not as an isolated BI structure, but as something that can increasingly participate in a larger knowledge-oriented architecture. On the far left, Enterprise Data Sources (1) represent the detailed operational and analytical facts of the enterprise: ERP, CRM, HR, Finance, Sales, Inventory, event hubs, and other systems. The Semantic Layer (3) transforms much of that raw detail into governed business information: measures, dimensions, hierarchies, calculations, and other structures that let people and software ask analytical questions in business terms rather than in tables and joins.
The large box with the black outline on the right is the Enterprise Knowledge Graph (2). It represents a broader world of explicit knowledge. The EKG is not meant to duplicate the semantic layer. A semantic layer is already very good at serving governed analytical information quickly and consistently. The role of the EKG is different. It provides an integrated place for explicit identities, relationships, classifications, rules, provenance, metadata, insights, correlations, and links to knowledge that is outside the narrow boundaries of an analytical model. The semantic layer primarily organizes information, while the EKG helps organize and connect knowledge.
Within that EKG, the Domain and World Ontologies (4) provide the conceptual side of the graph. This is where enterprise concepts such as products, customers, suppliers, risks, locations, events, and processes can be related to broader domain meaning and, when appropriate, to the larger world of knowledge beyond the enterprise. The Data Catalog (5) provides another essential part of the graph by giving technical artifacts—systems, tables, columns, models, and related metadata—explicit identities and relationships. Together, those two parts help connect business meaning to the physical and technical reality from which it arose.
The Business Intelligence portion of the EKG, shown here as (6), is where the Insight Space Graph and Tuple Correlation Web live. Those structures are built from what is learned through ordinary use of the semantic layer. A query against the semantic layer returns governed information. The Insight Function Array can examine that result and notice something worth remembering: a spike, a drop, an inflection, a long tail, an unusual correlation, a cluster, or some other salient observation. The ISG preserves what was learned from the query. The TCW preserves another kind of learned knowledge: empirical relationships among qualified tuples across time. Both are examples of promoting what began as information into something more durable and explanatory.
The new element in this version of the figure is (7) beside the semantic layer. That small graph represents the upcoming Kyvos knowledge graph. It is important because it shows the semantic layer beginning to reach outward into the knowledge-graph world rather than stopping at governed information. I do not mean that the semantic layer itself suddenly becomes the entirety of an enterprise knowledge graph.
Nor does the graph beside the semantic layer need to reproduce everything available in the larger EKG. Its value comes partly from locality. If it contains the identities, relationships, definitions, and graph structures needed for the common analytical questions, those questions can remain close to the high-performance information layer. When a question exceeds that local scope, the graph can follow its links outward into the larger knowledge-graph world. The local graph is therefore not a smaller EKG competing with the larger one; it is an entry point into it.
That outward reach matters. The Kyvos-side graph at (7) can be thought of as a local KG extension growing from the semantic layer and connecting into the wider graph world. That wider world includes ontologies, data catalog structures, and also the Enterprise Intelligence structures such as the ISG and TCW. In other words, the semantic layer is no longer merely a source from which the EKG harvests information. It begins to gain its own graph-shaped extension that can participate more directly in knowledge-oriented architectures.
So a reasoner could access Kyvos:
- As part of a RAG process where the Kyvos Semantic Layer (3) is a resource available to it for querying.
- Through the EKG where the built-in KG of Kyvos (7) could be accessed.
- Directly to the built-in KG of Kyvos (7).
The big advantage for option 3 is that the KG will have a very close link to the Semantic Layer.
The red MSFT example at (8) illustrates why such connections matter. The same real-world thing may appear in several different forms: as a member within the semantic layer, as a node in the Kyvos-side graph, as an entity in the data catalog, as a concept in the ontologies, and as a tuple or relationship within the TCW or ISG. The value of the knowledge graph is not that it duplicates each representation in isolation, but that it can explicitly connect them. Once those connections exist, meaning and evidence can travel among the different parts of the architecture.
This is why I see the figure as showing an extension, not a replacement. The semantic layer still plays its traditional role extremely well: transforming raw enterprise data into governed analytical information. But now there is a path beyond that role. The adjacent Kyvos graph at (7) suggests how the semantic layer can begin to participate in knowledge structures directly, while still connecting into the much broader EKG. That broader EKG, in turn, includes not only ontology and metadata, but also the learned enterprise knowledge represented by the ISG and TCW.
The larger point is that information and knowledge should not be separated into disconnected worlds. The semantic layer should remain tied to the EKG, and the EKG should remain tied back to the semantic layer. Information can be promoted into explicit knowledge through ontologies, catalogs, insights, and correlations. Knowledge can then guide us back toward the information when we need evidence, validation, or another question answered. The new Kyvos graph is interesting precisely because it helps close that gap. It suggests a future in which the semantic layer does not merely feed the knowledge layer from a distance, but increasingly becomes an active participant in it.
Symbiotic Relationship Between the Semantic Layer and Knowledge Graphs
Note: This is DIFFERENT from the symbiotic relationship between Knowledge Graphs and LLMs mentioned earlier.
With vertical integration, the benefit comes from proximity and common control. Because Kyvos controls the semantic layer and its upcoming KG capability, it can progressively mitigate expensive handoffs, share identities and governance, push work to the right engine, and optimize across the boundary. Kyvos’s public material is already moving in this direction: it describes the semantic model, Business KG, governance, and other knowledge as pieces of one shared business context.
But symbiosis goes both ways. What does each component give the other that the other is intrinsically bad at producing for itself?
What the KG gives the Semantic Layer
The semantic layer is superb at producing information. It knows how to answer things like revenue by customer, inventory by plant, margin by product, change over time, rankings, slices, and aggregations—quickly, consistently, and in business terms. Kyvos specifically emphasizes semantic models, acceleration, caching, and querying at enterprise scale. But it largely lives inside the analytical model.
The KG gives the semantic layer reach. A KPI can now connect to a customer, which connects to a supplier, which connects to a geographical region, a regulation, a risk, an ontology concept, a business rule, another domain’s model, or eventually something outside the enterprise. Rules and reasoners can follow those relationships and derive answers that are not simply another aggregation.
So, a KG gives a Semantic Layer context, relationships, rules, reasoning, and reach beyond the data and information. That’s what we’ve been talking about.
What Does the Semantic Layer Give the KG?
In my blog, Prolog and Business Intelligence-Prolog’s Role in the LLM Era, Part 5, I describe MetaFacts—Prolog facts imported from another data source (usually relational database or semantic layer). They are facts generated dynamically from external data, particularly OLAP and OLTP. I describe OLAP as highly curated, user-friendly, and performant, and MetaFacts as a way to bring necessary facts into the reasoning environment as needed rather than loading the whole underlying dataset.
That idea translates almost directly from Prolog into a KG. The KG should not necessarily contain every customer × every date × every product × every measure × every possible aggregation. That would be absurd. That’s precisely the information space the semantic layer was built to manage.
Instead, the KG could know how to obtain a fact. Rather than physically storing millions or billions of triples representing analytical state, a portion of the KG could effectively be a virtual graph (mostly associated with Stardog) backed by the semantic layer. A virtual graph presents data from an external source as though it were part of the knowledge graph, translating graph queries to the underlying source rather than requiring that all of the data first be copied into a triple store. In Semantic Webs of Meaning, I discuss Stardog’s virtual graph capability in Chapter 9, page 194, although there I use it in the context of security, not as a linked source of data.
For example, the graph may conceptually expose derived observations such as:
- Acme→ hasRevenue→$14.2M
- Acme→ revenueGrowth→-17%
- Plant17→ inventoryBacklog→High
- ProductX→ lostImpressionShare→23%
These are not timeless ontological assertions. They are contextual observations whose meaning depends on time, grain, calculation, filters, source, and sometimes a classification rule. The semantic layer is what supplies that context.
Those do not need to be persistent RDF facts sitting in a triple store. They can be MetaFacts—not Prolog in this case, but graph-shaped (RDF in a standards-based implementation such as Stardog) facts resolved from the governed semantic model when required.
That’s a very different contribution from the KG’s gift to the semantic layer. Instead, a semantic layer gives the KG a huge, governed, performant, business-friendly source of virtual facts. And I think virtual is critical.
The KG Doesn’t Need to Reflect the Entire Semantic Layer
We don’t want an enterprise KG to become just the “graph version of a data warehouse”.
My blog, The Art of Knowledge Graph Competency Questions, says essentially that large volumes of detailed observations remain in BI systems; the KG represents and connects enterprise knowledge, while BI supplies the figures.
MetaFacts make that separation operational rather than philosophical.
The graph could contain something roughly like:
- KPI→calculatedBy→SemanticModelMeasure
- Customer→participatesIn→RevenueAnalysis
- RevenueAnalysis→suppliedBy→KyvosSemanticModel
Then, when a rule or traversal actually requires the revenue for Acme during Q3, the system asks the semantic layer. The resulting value temporarily behaves as though it were part of the graph.
That is very close to my original MetaFact concept: the knowledge structure knows how to summon the fact when reasoning requires it.
And Kyvos is an unusually valuable source because these aren’t arbitrary raw database values. They have already passed through the governance of the semantic layer: measures have definitions, dimensions have meaning, identities are governed, security applies, aggregates are optimized, and common analytical questions are fast.
So the KG receives something better than raw data. It receives information ready to construct knowledge. That results in a genuinely reciprocal relationship illustrated in Table 3.
| Pairing | One side contributes | Other side contributes | Nature of relationship |
|---|---|---|---|
| Semantic Layer + KG under Kyvos | proximity, shared identities, optimization | proximity, shared planner/context | Vertical integration |
| LLM + KG | interpretation, extraction, proposed relationships | explicit facts, grounding, provenance | Epistemic symbiosis |
| Semantic Layer + KG | governed, performant MetaFacts | relationships, rules, context, reasoning | Analytical symbiosis |
That third one might actually be more important than the optimization story. The semantic layer says: Here are the facts as the business currently measures them. The KG says: Here is what those facts relate to, what rules apply to them, and where they may lead. And then the KG can come back asking for another fact.
That creates a loop:
KG relationship/rule→ need for evidence → MetaFact query into semantic layer → governed information → graph reasoning→ new question → another MetaFact
That is a much richer architecture than simply “put a little KG beside the cube.”
And there is one particularly elegant consequence: the boundary between information and knowledge becomes traversable without erasing the boundary.
We don’t want to lose the benefit of specialization.
The semantic layer does not need to become a first-tier graph database. The graph does not need to become an OLAP engine. Each remains very good at its own job, but each can now borrow the other’s capabilities when crossing the boundary requires them.
The KG extends the semantic layer into the world of relationships and reasoning; MetaFacts extend the knowledge graph back into the highly curated, high-performance information world of the semantic layer.
That gives Figure 1 a two-way arrow rather than an upward climb.
The old MetaFacts concept may be more naturally at home in this architecture than it ever was in Prolog. In 2004, the mechanism happened to produce Prolog facts because Prolog was the discussed reasoning substrate. The deeper abstraction was always virtual facts summoned from an external analytical system into a reasoning system as needed.
Today those could just as naturally be virtual graph facts.
Conclusion
The point of all of this is not that the semantic layer should become a knowledge graph, or that the knowledge graph should replace the semantic layer. They are natural partners, each doing what it does best.
The semantic layer is extraordinarily good at turning huge quantities of detailed data into governed information quickly: How much? How many? Which customers? Which products? Compared with when? A knowledge graph is good at preserving the relationships that tell us what those things are, how they are connected, what we have learned about them, and where else that knowledge leads.
What becomes interesting is when those worlds stop being islands.
A query to the semantic layer can produce information. Something learned from that information can become knowledge: an insight, a relationship, a classification, a correlation, a connection to an ontology, or simply the recognition that two representations refer to the same thing. Once retained in the knowledge graph, that knowledge can later lead us back to the semantic layer for evidence, measurement, validation, or another question.
So the pipeline is not simply: Data→Information→Knowledge
It should be a loop as depicted in Figure 1.
That is why the small graph shown as (7) in Figure 3 is more significant than its size might suggest. It represents the semantic layer beginning to acquire a direct foothold in the KG world. The larger Enterprise Knowledge Graph can still extend far beyond it—into ontologies, catalogs, external knowledge, the Insight Space Graph, the Tuple Correlation Web, and whatever else the enterprise comes to know—but there is now a shorter path between the information we calculate and the knowledge we map.
Bringing the two closer does not erase the distinction between them—merging two things into one. It minimizes the distance the ball needs to be thrown.
There is another problem that follows immediately from this architecture: information changes, and therefore some of the knowledge derived from it can age, expire, or need to be reconsidered. That question—how information is refreshed and how the things built from it remain current—is important enough that I am leaving it for the next blog.
