Building Knowledge Graphs with Common Core Ontologies

In short: a knowledge graph needs a schema layer, and an upper-mid ontology like the Common Core Ontologies (CCO) is a faster, more durable way to get one than inventing node labels as you go. The practical path is five steps: scope the domain, map entities to CCO classes, model relationships with CCO object properties, ingest and validate data against that schema, then keep it consistent as the graph grows. Done this way, the graph stays queryable and auditable well past the first few hundred thousand nodes.

Most knowledge graph projects start the opposite way: pull in data, invent a node label for whatever shows up, and wire up edges as relationships get discovered. That works for a demo. It stops working once two teams independently create a Vendor node and a Supplier node that mean the same thing, or once a query needs to traverse from a contract to the person who signed it and there is no consistent relation to follow. An ontology-first approach front-loads that modeling decision instead of discovering it the hard way in production.

Teams that reach this point without in-house ontology expertise often bring in a software partner — our overview of the custom software development process covers how that kind of engagement typically runs, from scoping through delivery, which is useful context before committing to a build-it-yourself schedule.

What Does an Ontology Actually Give a Knowledge Graph?

A knowledge graph is, structurally, just nodes and edges. What turns a pile of nodes and edges into something a query can reason over is a schema that says what kinds of things the nodes are and what kinds of connections the edges represent. An ontology is that schema, made formal: a set of classes, a set of relations between those classes, and axioms that constrain how they combine.

CCO's classes sit one level below Basic Formal Ontology's top categories — things like Independent Continuant, Act, Agent, Artifact, and Process — which is why the suite is called a mid-level ontology. That matters for graph modeling because those categories are already general enough to cover almost any domain, but specific enough that mapping a real-world entity to one of them is a concrete, checkable decision rather than a judgment call invented fresh for every project. A node labeled Invoice with no further structure tells a query nothing about how it relates to a Contract or a Payment. A node typed as an instance of Information Content Entity, related to an Act of payment through describes, gives the query something to traverse.

Step 1 — Define the Domain and Scope Before You Model Anything

The single most common reason knowledge graph projects stall is trying to model an entire organization before ingesting a single record. Start instead by naming the questions the graph needs to answer: which customers are linked to which open contracts, which assets are due for inspection, which documents reference a given regulation. Each question implies a small set of entity types and relations that actually need to exist on day one.

Scoping this way also sets a natural boundary for the pilot. A graph that only needs to answer questions about contracts and the organizations that sign them does not need to model shipping logistics yet, even if shipping data lives in the same source systems. Expanding scope later is cheap when the ontology underneath is stable; expanding scope is expensive when every new domain forces a rework of classes already in production use.

Step 2 — Map Your Entities to CCO Classes

Mapping is the work of taking the concrete things your source systems track — customers, contracts, assets, shipments, support tickets — and assigning each one to the closest existing CCO class instead of minting a new one. A customer, in most models, is an instance of Agent (or more specifically Person or Organization, both of which CCO already defines). A contract is an Information Content Entity that describes an Act of agreement. A physical asset is an Artifact. An inspection is an Act with an agent, a patient, and a time.

The discipline here is resisting the urge to create a bespoke class the moment a source system's terminology does not match exactly. A field called vendor and a field called supplier in two different systems are very likely both instances of Organization playing an Agent role in a procurement Act — the surface-level naming difference is exactly the kind of drift a shared ontology is meant to absorb. Keeping the class count small and reused is what makes cross-system queries possible later; a graph with one class per source-system table has not actually adopted an ontology, just renamed the problem.

Step 3 — Model Relationships with CCO Object Properties

Entities alone do not make a graph; relations do. CCO defines a set of object properties built for exactly this purpose — has_agent links an Act to the Agent that performed it, occurs_on links an Act or Process to a temporal region, realizes links a Role or Disposition to the Process in which it is exercised. Using these relations instead of ad hoc edge labels means two independently modeled parts of the graph can be joined automatically, because both sides already speak the same relational vocabulary.

In practice, relationship modeling is where most of the review time should go, more than class assignment. Two engineers mapping the same entity to the same CCO class will usually agree quickly. Two engineers deciding whether a relationship between an inspection and an asset should be has_participant or a more specific subproperty will disagree more often, and that disagreement is worth resolving explicitly rather than letting both patterns ship into production side by side.

RDF Triple Stores vs. Property Graph Databases — Which Fits a CCO-Backed Graph?

CCO is published as OWL, which is native to RDF triple stores: every fact is a subject-predicate-object triple, and a reasoner can check the whole graph for logical consistency against the ontology's axioms. That makes a triple store the most direct fit, and it is the right choice when formal reasoning — inferring new facts, catching contradictions automatically — is part of what the graph needs to do.

A property graph database such as Neo4j is a reasonable alternative when the priority is traversal performance and developer ergonomics over formal inference. CCO's classes become node labels and its object properties become relationship types; the modeling discipline carries over even though OWL reasoning does not come for free. Several teams run both: a triple store as the ontology's source of truth and validation layer, with a property graph as a query-optimized projection for application workloads. Which one to pick first usually comes down to whether the team already has SPARQL experience or property-graph query experience in-house.

Step 4 — Ingest and Validate Data Against the Ontology

Ingestion is where a schema either earns its keep or gets silently bypassed. Every record pulled from a source system needs to be checked against the target class's expected properties and relations before it lands in the graph — does this instance of Agent have the properties an Agent is expected to have, does this Act actually have an agent and a time, is this relation pointing between the right kinds of classes. Skipping that check means malformed data enters the graph looking structurally valid and only breaks a query much later, far from the point where the bad record was introduced.

A practical validation pass checks three things for every batch: that every node's assigned class actually exists in the ontology being used, that every relation connects classes the ontology permits that relation to connect, and that no required property is missing for the class in question. Running this as an automated gate in the ingestion pipeline, rather than as a one-off audit, is what keeps a graph trustworthy as more source systems and more contributors start writing into it.

Keeping the Graph Consistent as It Scales

A knowledge graph that stays small never has to deal with governance; a knowledge graph that succeeds does. Once more than one team is adding entities and relations, the ontology itself needs version control and a change process — who can add a new class, who reviews a new relation before it ships, how a renamed or deprecated class gets migrated without breaking queries that already depend on it. Treating the ontology's own schema changes with the same review rigor as a database migration, rather than as an informal convention, is what keeps a graph queryable instead of accumulating the same ad hoc drift it was built to avoid.

This is also where most of the ongoing engineering effort lives after the initial build: new source systems keep appearing, each one needs its own mapping and validation pass, and someone has to own keeping the whole thing consistent rather than letting each new integration quietly bend the schema to fit.

When to Build In-House vs. Bring In a Development Partner

A single pilot domain, mapped by one or two people already comfortable with CCO, is realistic to build in-house. Scaling past that pilot — onboarding multiple source systems, building the automated validation pipeline, maintaining the ontology's own change process — is sustained engineering work, not a one-time modeling exercise, and it is the point where many teams decide to bring in outside development capacity rather than pull engineers off other projects indefinitely. Either path works; the deciding factor is usually whether the team has the bandwidth to own the ingestion pipeline and governance process for the life of the graph, not just the initial schema design.

Frequently Asked Questions

What is the difference between an ontology and a taxonomy in a knowledge graph?

A taxonomy is a single hierarchy of categories, typically just is-a relationships organized into a tree. An ontology defines multiple classes, a rich set of relations between them, and logical axioms a reasoner can check for consistency. A taxonomy can tell you that a Contract is a kind of Document; an ontology can also tell you that a Contract has_agent a Person and occurs_on a date, and flag it as an error if a Contract is linked to something that is not an Agent.

Can I use CCO with a property graph database like Neo4j?

Yes. CCO is published as OWL, which maps naturally onto RDF triple stores, but nothing stops a team from projecting CCO classes and relations onto node labels and edge types in a property graph database. You lose native OWL reasoning unless you add a separate inference layer, but the modeling discipline — stable classes, explicit relations, no ad hoc node types — carries over either way.

How long does it take to build a production knowledge graph on CCO?

A scoped pilot covering one domain, with a handful of entity types mapped and a few thousand records ingested, is usually achievable in six to ten weeks by a small team already familiar with the ontology. Reaching production scale across multiple domains is a longer program measured in months, not weeks, because each new source system needs its own mapping and validation pass.

Do I need to use all 11 CCO modules, or can I start with a subset?

Start with a subset. Most knowledge graph projects only need a handful of modules at first — commonly Information Content Entity, Agent, Artifact, and Event or Act — and import the rest of the suite as the graph's scope grows. Because the modules share the same BFO-derived top-level categories, adding one later does not require reworking classes already in use.

How does CCO relate to BFO?

Basic Formal Ontology (BFO) is an upper ontology that defines only the most general, domain-neutral categories, such as the distinction between continuants (things that persist through time) and occurrents (things that happen or unfold). CCO is a mid-level suite that specializes those categories into classes an application can actually use, like Organization, Artifact, or Act, without inventing a new top-level structure for every project.

What's the biggest mistake teams make when modeling entities for the first time?

Creating a new class for every noun in the source data instead of mapping nouns to the closest existing CCO class. A schema that mints a bespoke class for every table or every customer's internal term loses the main benefit of using a shared ontology in the first place: that different systems and different teams converge on the same small set of classes and relations.

Can an existing graph be migrated onto a CCO schema later?

Yes, though it is more work than starting with CCO from the outset. Migration means auditing the existing node labels and edge types, mapping each one to the closest CCO class or relation, and re-writing or re-tagging existing data to match. Teams usually do this incrementally, domain by domain, rather than attempting a single cutover across the whole graph.

The ontology itself is published as open W3C OWL and registered with the OBO Foundry, which reviews ontologies for logical consistency before listing them — a useful starting point before deciding whether to adopt CCO as-is or extend it for a given graph.