.svg){kind=icon}
Learn
An ontology is the formal schema that defines the entity types, properties, and relationships allowed in a domain, while a knowledge graph is the populated data instance built to that ontology, holding the actual entities and the links between them.
Last updated: October 18, 2026
Why it matters to your mission. Two programs each build a graph of the same adversary network, define "unit" and "subordinate to" differently, and the two pictures cannot be joined without hand-reconciliation. An ontology fixes the meaning first: it is the agreed schema of entity types, properties, and relationships that a knowledge graph is then populated against. The outcome is mission data that means the same thing across systems, so a graph built in one program is intelligible to another instead of trapped in its own private definitions.
An ontology is the formal schema that defines the entity types, properties, and relationships allowed in a domain, while a knowledge graph is the populated data instance built to that ontology, holding the actual entities and the links between them. Put plainly, the ontology is the blueprint and the knowledge graph is the building. One says what kinds of things can exist and how they may relate; the other records the specific things that do exist and how they actually relate.
The two are complementary layers, not competitors. A knowledge graph can technically exist without a formally declared ontology, but then its rules of meaning are implicit and inconsistent, which is exactly the failure that makes two graphs impossible to join. An ontology without a knowledge graph is a schema with nothing in it. Mission-grade work needs both: a shared definition of meaning, and the populated graph that obeys it.
Key takeaways
An ontology is a formal, machine-readable specification of what exists in a domain and how those things relate. The W3C defines its ontology language, OWL, as "a Semantic Web language designed to represent rich and complex knowledge about things, groups of things, and relations between things," and describes an ontology itself as "a set of precise descriptive statements about some part of the world" (see the W3C OWL 2 Web Ontology Language Primer, 2012). OWL is a logic-based language, so the statements in an ontology can be reasoned over by a computer to check consistency and to make implicit facts explicit.
An ontology for an intelligence domain declares the classes that matter (person, unit, vessel, facility, event), the properties each can have, and the relationships that are allowed between them (a person is a member of a unit; a vessel is operated by an organization; a unit is subordinate to another unit). It also captures the rules: if a unit is subordinate to a second unit that is subordinate to a third, the first is subordinate to the third. That is the layer where meaning is fixed, before any data is loaded.
A knowledge graph is a data structure that stores real entities as nodes and the relationships between them as typed edges, so the connections are first-class data rather than something a query has to infer. The W3C RDF data model, one common foundation for knowledge graphs, describes this plainly: data is expressed as triples that "we can visualize as a connected graph," where "the subjects and objects of the triples make up the nodes in the graph; the predicates form the arcs" (see the W3C RDF 1.1 Primer, 2014).
Where the ontology says a person can be a member of a unit, the knowledge graph records that a specific person is a member of a specific unit, with a link back to the reporting that established it. The graph is the populated instance: the actual network, built from resolved entities, that an analyst traverses and a model reasons over. It is only trustworthy when the entities in it have been correctly resolved and every node and edge traces back to its source.
*Bottom line: the ontology is the schema that defines allowed types and relationships for a domain; the knowledge graph is the populated data that conforms to that schema. One defines meaning; the other records facts. The table makes the contrast extractable.*
The cleanest way to hold the distinction is schema versus instance. A database schema defines tables and columns; the rows are the data. An ontology defines classes and relationships; the knowledge graph is the populated set of entities and links. You design the ontology once and carefully, because everything downstream inherits its definitions; you populate and grow the graph continuously as new reporting arrives.
| Dimension | Ontology | Knowledge graph |
|---|---|---|
| What it is | The schema: allowed entity types, properties, and relationships | The data: actual entities and the links between them |
| Analogy | The blueprint, or a database schema | The building, or the populated rows |
| Contains | Classes, properties, relationship types, and logical rules | Specific people, units, vessels, events, and their connections |
| Changes | Infrequently and deliberately; it is designed | Continuously, as new data is ingested and resolved |
| Answers | What kinds of things can exist and how they may relate | What things do exist and how they actually relate |
| Reasoning role | Lets a machine check consistency and infer implicit facts | Supplies the facts the reasoning runs over |
| Standards | OWL, RDFS (W3C) | RDF, property-graph models populated to the schema |
| Failure if missing | Graphs use incompatible definitions and cannot be joined | A schema with no populated data to reason over |
A knowledge graph conforms to an ontology; the ontology constrains the graph. Change the ontology, and you change what the graph is permitted to express. That dependency is why the ontology is the higher-stakes decision: a weak or vendor-private ontology quietly limits every graph built on it.
Technically no, practically yes. You can assemble a knowledge graph with an ad hoc, implicit schema, where entity types and relationship meanings are whatever each ingestion decided on the day. It will function in isolation. The problem appears the moment you try to join it to another graph, correlate across programs, or reason over it with logic that expects consistent types: the definitions do not line up, and the work of reconciliation falls back on people.
An explicit ontology is what lets a machine do the reasoning the W3C ontology language was built for, checking consistency and surfacing implicit relationships, and what lets two systems agree that their "unit" and "subordinate to" mean the same thing. For single-use or throwaway work, an implicit schema may be enough. For mission data that has to be shared, correlated, and defended across services and over time, the ontology is the part you cannot skip.
Defense data is fragmented across services, systems, and classification levels, and the hardest part of integrating it is not moving the bytes but agreeing on what they mean. The U.S. Government Accountability Office, reviewing the Department of Defense's command-and-control integration, found that without "a framework that provides clear guidance for investments and measures to track progress, military departments and combatant commands will continue to focus on meeting the needs of their organization's specific mission objectives without understanding how their efforts align with" the joint goal (see GAO-25-106454, Defense Command and Control, 2025). A shared ontology is one concrete form that shared meaning takes: it is how independently built graphs become interoperable instead of each being correct only inside its own program.
The distinction also decides where the mission risk sits. If the ontology is owned and governed by the customer, the meaning of the data is under mission control and portable across systems. If it is buried inside a vendor's proprietary model, the graph may look rich while the definitions that make it intelligible are rented, and the data is effectively locked to that vendor even when the customer owns the records underneath. For defense, keeping the ontology explicit, standards-based, and government-owned is what keeps mission data interoperable rather than trapped.
Torch.AI builds reasoning infrastructure the customer can own and govern, offered as a government-owned (GOTS) deployment when a mission requires it; whether a specific deployment is government-owned or commercial (COTS) depends on the system the customer installs and purchases. Two products map to this topic. NEXUS makes data meaningful, building the semantic representation and Knowledge Domains that carry the shared definitions a domain ontology expresses. HALO makes relationships understandable, fusing resolved entities into a graph and reasoning across it. The ontology layer fixes what things mean; the graph layer holds what is actually connected. You can see how this is packaged as a capability on the Torch.AI software page.
The result is mission data whose meaning travels with it: entities resolved and linked into a graph that conforms to an explicit, governed definition, with every node and edge traceable back to its source reporting and its original classification preserved. This is the systems of record versus systems of reason distinction at the center of Torch.AI's approach: the reasoning layer sits on top of the customer's existing systems of record, complementing them rather than replacing them, so the authoritative sources stay intact and interoperable instead of locked inside a proprietary model. For the broader picture of how shared meaning is organized and governed across a mission, see the pillar on Knowledge Domains.
Evaluating a capability? The seven requirements above are the backbone of an evaluation you can score against. Bring them to a scoping call and we will walk each one against your environment: request a technical walkthrough.
An ontology is a formal, machine-readable schema that defines the entity types, properties, relationships, and logical rules allowed in a domain. The W3C describes it as a set of precise descriptive statements about some part of the world, expressed in a logic-based language a computer can reason over.
A knowledge graph is a data structure that stores real entities as nodes and the relationships between them as typed edges, so connections are first-class data an analyst can traverse and a model can reason over, with each node and edge ideally traceable back to its source.
An ontology is the schema that defines the allowed entity types and relationships for a domain; a knowledge graph is the populated data instance built to that schema, holding the actual entities and links. One defines meaning; the other records facts.
Technically no, practically yes. A graph can run on an implicit schema in isolation, but without an explicit, shared ontology it cannot be reliably joined to other graphs, correlated across programs, or reasoned over with logic that expects consistent types.
Because integrating defense data turns on agreeing what it means, not just moving it. A shared, governed, standards-based ontology is how independently built graphs become interoperable, and keeping it government-owned keeps mission data from being locked to a vendor's private definitions.
They play the same schema-versus-data role, but an ontology is richer: it is logic-based, so it can express rules and let a machine infer implicit facts and check consistency, where a conventional database schema mainly constrains structure.
Describe the problem.
Define the constraints. We will structure the session.
No demo.
No slide deck.
Real work.
Describe the problem.
Define the constraints. We will structure the session.
No demo.
No slide deck.
Real work.
