Where Should an Enterprise Knowledge Graph Start?

I recently became aware of a stance on how to begin a knowledge graph endeavor that is somewhat contradictory to what I prescribe in Semantic Webs of Meaning. This is an important point to clarify. Here is the bullet-point summary:

• Different Stance: Do not infer what the ontology ought to be merely from the structures you inherited. Start from what the system needs to know and answer.
• My Stance: Agreed, but the existing structures, especially those that are active parts of business processes, define the current context of the enterprise.

I consider my position to be contradictory because Chapter 4 (Knowledge Graphs vs. Traditional Data Structures) explicitly prescribes beginning with the semantic structure already embedded in databases, BI systems, software, and business processes—the very starting point this opposing view warns against. Let’s refer to this practice here, this “mining of knowledge from existing artifacts”, as “schema lifting”.

The main thing I wish to convey is that the opposing stance and I meet back up in Chapter 10 (Building and Growing an EKG). Competency questions are practical questions that turn business needs into testable requirements for what a KG must be able to answer. They guide what concepts, relationships, and knowledge need to be modeled, and they evolve as new questions expose gaps in the graph. Chapter 10 uses the simple example, “Why are SQL Server queries taking a long time?”—a question that can lead down a rabbit hole of causes, evidence, relationships, and eventually other domains.

The difference is that I would make the first competency questions about that foundation itself:

• Can the KG faithfully reflect the knowledge already captured in our BI systems?
• Can it see the systems embodied in our software and business processes?
• Can it preserve the domain-specific meanings expressed through ubiquitous language?

Once those questions are satisfied, subsequent competency questions can drive the KG outward into additional concepts, relationships, domains, and the broader Semantic Web.

Chapter 4 argues that enterprises already contain a great deal of latent semantic structure in databases, object-oriented software, UML, Data Vaults, semantic layers, documents, and other artifacts.

Much of that structure can be extracted programmatically and used as a practical starting point rather than beginning from a blank page. But that raises a second question: if existing systems provide the starting material, what determines how the graph should grow beyond what those systems already know? That makes sense, since those artifacts were created by people with deep knowledge of the domains and processes they support.

That is where Chapter 10 comes in. The lifecycle begins with business needs and competency questions, which define what the enterprise knowledge graph (EKG) must be able to answer and provide the direction for subsequent modeling. Existing enterprise sources then become the raw material from which that required meaning can be mapped, extended, corrected, and connected.

My basic rule remains the one developed in Chapter 4:

Start with the meaning the enterprise has already encoded, because it is concrete, connected to real systems, and often partially automatable to extract. Then use competency questions to determine what must be added, refined, or connected beyond that starting point. Chapter 4 is about avoiding the blank page; Chapter 10 is about deciding where to go next.

My arguments for starting with schema lifting are:

• It will convert what is familiar to the stakeholders. That is important because this needs to be performed at domain levels and not everyone is an ontologist.
• Automation is always a benefit—especially with a structure that must remain current. Automate what makes sense. That goes for the initial build as well as maintenance.
• We are purposefully linked into the current processes of the enterprise.

The argument against schema lifting is strong if end product of schema lifting is treated as ontology design. A relational schema was built to support a particular application, process, storage model, and performance envelope. Tables, foreign keys, nullability, cardinality, codes, and hierarchies therefore contain a mixture of genuine domain meaning and implementation compromises. Mechanically turning those structures into classes and properties risks freezing database design decisions into the ontology as though they were truths about the world.

Chapter 4 itself rejects that mechanical interpretation: extraction requires deciding what is an identifier, literal, relationship, or class and, most importantly, mapping those things to governed concepts. I state this on page 73:

Tasks involved in ontology extraction are not limited to copying columns into triples, but to recognizing which columns are literals, which are relationships, which are identifiers, which imply classes, and, most importantly, mapping them to governed and/or master data concepts.

The EKG cannot be designed as though the enterprise begins with a blank sheet of paper. Its knowledge is already embodied in several kinds of systems:

• Machine systems such as databases, applications, APIs, models, and code;
• Process systems such as workflows, policies, controls, reports, and business procedures
• Human systems consisting of terminology, judgment, exceptions, experience, and knowledge held by SMEs. Chapter 4 treats all of these as sources of knowledge and explicitly notes that some are structured enough to be mined programmatically while others require interpretation.

So I would state the distinction this way:

Schema lifting is poor ontology methodology when it means treating the schema as truth. It is very useful implementation methodology when it means using existing systems as evidence and as a semantic starting point.

The ontology must remain connected to those systems because that is where enterprise identity, state, processes, and much of its accumulated meaning actually live. Chapter 4 therefore preserves lineage back to tables and columns rather than severing the ontology from its physical sources. But the KG also has to go beyond those systems because they were intentionally built on a “need-to-know” basis. That is where competency questions become important: they tell us which missing concepts, relationships, context, and cross-domain connections are worth adding. Chapter 10 describes existing enterprise sources as the raw material, while competency questions act as living requirements for extending the graph.

I think the concise principle is:

Do not mistake the structure of an existing system for the structure of reality. But do not build an enterprise ontology detached from the systems—machine, process, and human—in which the enterprise’s knowledge is already embodied. Mine those systems for a grounded starting point, retain their provenance and connections, and use competency questions to decide how the knowledge graph must extend beyond them.

The Enterprise Is Not a Blank Slate

An established enterprise has already spent decades painfully modeling its world and evolving the model with a changing world. Large enterprises are also large to the point where knowledge, by domain and various levels of perspective, of the enterprise is well beyond what can fit into one or even a few heads.

A moderately-sized enterprise could use all the automated help it can get for any task. That’s especially true for a task as substantial, complicated, and intricate as building a knowledge graph.

A relational schema contains tables, keys, constraints, hierarchies, naming conventions, and code values. An object model contains classes, inheritance, composition, and behavior. A BI semantic layer contains measures, dimensions, hierarchies, calculations, and governed business names. A Data Vault contains durable business identities, explicit links, source attribution, history, and domain-specific descriptions. Documentation and policies contain another layer of meaning, and subject-matter experts carry still more.

None of those sources is a complete ontology. Some are not even close. But they are not semantically empty either.

They are evidence of how the enterprise has already chosen to describe customers, products, employees, orders, locations, processes, metrics, policies, and countless other things. More importantly, much of that evidence can be extracted programmatically. Database metadata can be read. Foreign keys and hierarchies can be inspected. OOP classes and UML can be parsed. Catalogs and semantic layers can be queried. LLMs can assist with more ambiguous material such as documentation, tickets, policies, and source-code comments.

That gives us something extremely valuable: a semantic starting point that is already attached to the operational enterprise.

This isn’t just about deriving entities from databases.

Starting from Existing Systems Does Not Mean Treating Them as Truth

A database schema is not a finished enterprise ontology simply because it contains an implied ontology. A schema contains implementation compromises. A table may exist because of normalization. A bridge table may exist because of a many-to-many relationship. A column may exist because a UI needed a flag. A dimensional model intentionally discards detail that was not useful for analytics. An application class may reflect the requirements of one workflow rather than the deeper meaning of the domain.

In Chapter 4, page 80, I state:

KGs are not a superior replacement for relational databases—both are necessary. KGs are a means to extend meaning beyond the strategic constraints of the relational database’s immediate requirements—to move beyond the “need-to-know basis” of relational database models. That “thriftiness” is about promoting performance, in terms of storage and query performance, by having as little data as possible. Relational databases gave us a workable way to manage data. Knowledge graphs give us a workable way to manage connected meaning.

So schema lifting should not mean copying every table and column into RDF and declaring victory.

The task is interpretive. We ask which elements represent identities, which represent relationships, which imply classes or controlled vocabularies, which are merely implementation artifacts, and which should map to governed enterprise concepts. The graph should also preserve provenance and traceability back to the systems from which those concepts and assertions came.

In other words:

Existing systems are a source of candidate semantics, not an authority on ultimate meaning.

That is why I think of them as knowledge ore (page 68). There is already value in the material, but it still has to be separated, interpreted, refined, and connected.

BI as a Foundation of an AI System

One of the primary themes within my books (esp. Enterprise Intelligence), is that of BI systems (today mostly called “Semantic Layers”) as a solid foundation for an AI system.

Different systems model the enterprise for different purposes. An OLTP system models what is necessary to execute a business process. A BI semantic layer reorganizes and integrates that information around what analysts and managers need to measure and understand towards making informed decisions and crafting competitive strategies. A knowledge graph addresses a different problem again: making identities, relationships, context, rules, and meaning explicit enough to connect and reason across domains and beyond the boundaries of existing systems.

That does not make the earlier representations irrelevant. Primary and foreign keys, application entities, process states, source code, dimensional models, measures, hierarchies, and semantic-layer definitions are all encoded knowledge. They are evidence of what the enterprise has already formalized and, importantly, they keep the KG connected to the systems in which the business actually operates.

For a decision-oriented enterprise AI, I generally favor starting from the BI/semantic-layer level where it exists. Much of the difficult work of selecting useful business concepts, integrating sources, reconciling terminology, establishing trusted measures, and presenting information at the level relevant to analysts and managers has already been performed. Deeper OLTP and software structures remain available when explanation or operational intelligence requires them.

The KG then grows beyond that foundation. Competency questions help determine which additional relationships, concepts, rules, human knowledge, and external Semantic Web connections are required. The source systems therefore provide the grounding; they do not dictate the final ontology.

Why I Still Prefer Schema Lifting as the First Move

For a long-established enterprise, starting with existing sources has several advantages.

1. It lowers the cost of getting something real into the graph—an MVP or PoC/V (proof of concept or value). Much of the initial extraction can be automated. Creative utilization of database metadata is common practice today. We are not asking a modeling team to invent a conceptual universe before anything useful exists.
2. It preserves identity and lineage. If the graph contains an Employee, Customer, Product, or Order, we should know how that concept relates to the records, identifiers, systems, and domains that already use it. A knowledge graph that cannot reconnect to the enterprise data it is supposed to explain risks becoming a semantic island floating above the systems that actually run the business.
3. It gives us breadth. One of the recurring problems with enterprise ontology efforts is that a small number of domains can be modeled very deeply while the rest of the enterprise remains disconnected. A relatively shallow but well-linked semantic skeleton across many domains can create more enterprise value than a magnificent ontology of one isolated area.

This is one reason I find Data Vault particularly interesting as a bridge. A Data Vault is not a knowledge graph, but its emphasis on business identity, links, provenance, history, and domain-specific satellites is unusually close to the structures a KG needs. It preserves more of the source semantics than a highly distilled dimensional model, which gives the KG more material from which to work.

Finally, beginning with existing systems respects how enterprises actually evolve. We rarely (if ever) get the luxury of replacing everything with a newly designed semantic architecture. We have to connect what is already there, preserve what still matters, expose what was previously implicit, and extend it.

The First Competency Questions

The first competency questions should ask whether the KG understands the enterprise before asking whether it understands the world. Before asking a knowledge graph to answer new questions, I think its first competency questions should be more fundamental:

• Can the knowledge graph reflect and evolve with the knowledge already gleaned in our BI systems?
• Can it see the systems embodied in our software and business processes?
• Can it preserve the nuances of language within individual domains—the ubiquitous language of DDD that people in those domains actually use?

Those questions establish the foundation. They do not mean that a KG should merely mirror an existing database schema (just an RDF version of the database metadata). OLTP systems, BI systems, and KGs solve different problems. An operational database is designed around running a business process. A BI semantic layer reorganizes and integrates that information around the entities, measures, dimensions, and relationships that support analysts and managers. A KG goes further still, making meaning and relationships explicit enough to connect domains, support reasoning, and extend beyond the boundaries of existing systems.

For a decision-oriented EKG, a mature BI environment is therefore an especially strong starting point. A good semantic layer (ex. Kyvos) should already contain many of the entities that matter at the level of enterprise decision making, along with the analytically valuable attributes, measures, hierarchies, and relationships associated with them. Much of the work of filtering away low-level operational detail and reconciling multiple source systems has already been done.

That does not make OLTP systems irrelevant to a KG. Primary and foreign keys, application entities, state transitions, business rules, and other structures in software and databases still encode important knowledge. They may explain where a BI concept came from, how a process actually works, or why something happened. In the land of BI, that’s a critical concern. An AI focused on operational intelligence may need to work at that detailed process level. An AI focused primarily on management and decision making can often begin higher, with the BI semantic layer, while retaining links downward when deeper explanation is required.

The same applies to domain language. A useful enterprise KG should not flatten every domain into one supposedly universal vocabulary. The language used by Finance, Sales, Manufacturing, Engineering, or Human Resources carries distinctions that matter inside those domains. Domain-level ontologies can preserve that ubiquitous language while mappings and shared identifiers connect those meanings across the enterprise.

With that grounding in place, we can build the more conceptual KG layer that ontology practitioners often envision—classes, relationships, rules, constraints, and competency-question-driven extensions—without severing it from the systems from which the enterprise actually operates and learns.

I recommend treating these as separate but connected layers: operational/process knowledge, BI/semantic-layer knowledge, domain ontologies, the broader enterprise KG, and finally connections outward to resources such as Wikidata, DBpedia, Schema.org, and other Semantic Web vocabularies.

Lastly, if an enterprise does not yet have a mature BI semantic layer, I would not think of that as a reason to skip directly to the KG. It probably still needs the BI layer. Over decades, BI has accumulated an enormous amount of hard-won infrastructure for decision support:

• Integrated and cleansed data — Data brought together from multiple operational systems, reconciled, standardized, deduplicated, validated, and transformed into a trustworthy analytical foundation.
• Conformed business entities and dimensions — Common definitions for important concepts such as Customer, Product, Account, Region, and Time so different systems and reports can analyze them consistently.
• Governed measures and KPIs — Centrally defined business calculations such as Revenue, Margin, Churn, or Inventory Turns, with agreed formulas and meanings rather than each analyst inventing a version.
• Historical context — The ability to analyze how entities, attributes, and measures change over time rather than seeing only current operational state.
• Common hierarchies — Standard rollups such as Product → Category → Division or City → State → Region that support consistent drill-down and aggregation.
• Security — Established controls over who can see which data, metrics, business units, or levels of detail.
• Lineage — Traceability from a report, measure, or semantic-layer object back through transformations to its originating source data.
• Data quality controls — Rules and processes for identifying missing, invalid, inconsistent, duplicated, or otherwise untrustworthy data before it reaches decision makers.
• Aggregation logic — Knowledge of how measures should correctly summarize across dimensions and levels, including distinctions such as additive, semi-additive, and non-additive measures.
• Performance optimization — Decades of engineering around indexing, partitioning, pre-aggregation, caching, cubes, columnar storage, query planning, and related techniques that make large-scale analytical queries practical.
• Business-friendly semantic models — A curated layer of understandable business concepts, relationships, measures, labels, and calculations that shields analysts and managers from the complexity of joins, source-system quirks, and physical storage.

Modern semantic layers add still more value by reconciling terminology and calculations across sources and presenting information at the level where analysts and managers actually reason about the business. For the kind of enterprise AI concerned with decision support, I regard BI as an “intimate” upstream component of the KG rather than an obsolete system that the KG replaces. The KG should inherit that curated foundation and extend it with richer relationships, domain meaning, inference, external knowledge, and the broader context that BI was never designed to represent.

Then Competency Questions Drive Expansion

The initial semantic skeleton from “schema lifting” is not the destination. Once we have that foothold (the context of the enterprise in KG form), competency questions tell us where we go with the EKG from there:

• What must the graph be able to answer?
• What relationships are missing?
• Which concepts are ambiguous?
• Which domains need to be connected?
• What evidence is required to explain an answer?
• What rules or constraints are needed for reliable deduction?

Competency questions (Chapter 10) are the practical questions the knowledge graph must be able to answer. They turn business needs into testable requirements and give ontology development direction without pretending we can know every question in advance. In fact, one of the reasons for building an EKG is precisely that we expect important questions to emerge later. If we already knew every question and every answer path, conventional software would often be sufficient. The goal is to build enough connected meaning that future questions can be composed from knowledge already in the graph. Competency questions therefore are not a fixed requirements document; they are living requirements that expose gaps and guide the graph’s continued expansion.

That expansion should not stop at the boundaries of any one application, database, or even enterprise domain. Shared identifiers and IRIs let separately developed knowledge connect across domains, while mappings tie the graph back to existing enterprise sources. As the graph grows, those same Semantic Web mechanisms allow local enterprise concepts to connect to broader vocabularies and knowledge outside the enterprise. The result is not a model built only to answer today’s competency questions, but a growing semantic fabric in which relationships across previously separate areas can make tomorrow’s questions answerable.

A competency question is therefore not merely a design-time checklist item. It is a living requirement. New regulations, new products, new systems, new failures, and new business questions expose gaps in the graph. Each important question becomes a probe into the semantic structure we already have.

That is why I do not see competency questions and source mining as competing with each other. They answer different questions.

• Source mining asks: What useful meaning has the enterprise already encoded?
• Competency questions ask: What meaning do we still need in order to reason about the problems that matter?

The first gives us a foundation. The second tells us how to extend it.

Bootstrap vs. Growth

I think the apparent misalignment between the two approaches comes from using the word start to mean two different things.

There is an implementation starting point and a semantic-development starting point.

For implementation, I prefer to start by mining existing sources because they provide an automatable, traceable, enterprise-grounded semantic bootstrap.

For semantic development, I prefer competency questions because they prevent us from endlessly modeling things that nobody needs and because they expose the relationships, rules, and cross-domain connections the current graph cannot support.

Put together, the pattern looks like this:

Conclusion

If I had to reduce the approach to one rule, it would still be the Chapter 4 rule:

Start with the meaning the enterprise has already encoded, make the useful parts explicit and traceable, and use that as the foundation.

But … then apply the Chapter 10 discipline:

Use competency questions to decide what must be corrected, enriched, connected, or added next.

The point is not to choose between bottom-up extraction and top-down ontology design. The point is to avoid the failure modes of both: a beautiful ontology with no connection to the systems people actually use, or a giant pile of lifted triples with no governed meaning.

An EKG has to live between those extremes. It should begin close enough to existing systems to be implementable, but remain open enough to grow beyond the assumptions and limitations those systems were built around.