What is a knowledge graph?

A knowledge graph is a store of entities and the typed relationships between them, organized by a schema that says what may connect to what. An entity is a thing with an identity: a part, a supplier, an aircraft. A relationship is a named, directed link: a ticket is about a part, a supplier notice changes it.

Two neighbors are easy to confuse with it. A relational database keeps the same facts in tables and rebuilds the links with joins when a query asks for them. A document index keeps text and finds the passages that look like a question. A knowledge graph keeps the links themselves, so following one is a lookup rather than a reconstruction.

A survey by Aidan Hogan and 17 coauthors adopts an inclusive definition: “a graph of data intended to accumulate and convey knowledge of the real world, whose nodes represent entities of interest and whose edges represent relations between these entities.”

Two data models carry most knowledge graphs. The W3C’s RDF standard builds a graph from “a set of triples, each consisting of a subject, a predicate and an object.” A property graph, the other common model, also stores named fields on each node. Part P-220 has a revision and a material, and its supplier is a node of its own.

The schema is the part teams skip and later regret. It names the types: part, supplier, ticket, maintenance log. It lists the fields each type has, the key that identifies a record, and the relationships allowed between types. Neo4j’s introduction calls this layer organizing principles, anything from a product taxonomy to a full business vocabulary.

Identity matters as much as structure. Say the ticket system writes the part as P220-C and the parts list writes P-220 rev C. The graph needs one key for both, or it holds two parts that are really one.

A relational table answers known questions well. A row per part, a row per ticket, a foreign key between them: the join is fast and the database checks every value. The trouble starts when a question crosses systems. The ticket lives in one database, the part in another, the supplier notice in an inbox, and nothing joins them until someone writes the integration.

A document index answers a different question: which text looks like this? It finds every ticket that mentions a leak. It will not find the supplier notice that changed the seal on the leaking part, because the notice never says leak. What links the notice to the ticket is a part number, not its wording.

A knowledge graph stores that link once, when the records are loaded, and every later question can follow it. It does not replace the table or the index. The source systems stay the authority on their records. A good system uses search to find a starting point and the graph to walk from it.

Google made the term common in 2012. It introduced its Knowledge Graph as a model that “understands real-world entities and their relationships to one another: things, not strings.” That distinction now decides whether an AI assistant gives a useful answer.

A language model answers from what it is given. Handed the ten passages most similar to a question, it reasons over text that resembles the question. Handed a walk through a graph, it reasons over the records connected to the question. That means the part, its open tickets, the notice that changed it and the last seal swap.

Each of those is a record with an id, so the answer can cite them and a person can check each one. The survey separates open knowledge graphs, such as Wikidata, from enterprise knowledge graphs. A company builds the second kind over its own records, for its own use.

• Unstable keys. If a record’s identity changes between loads, each load creates a new node. Our own graph model documentation names unstable keys as the top cause of duplicates.
• Everything a node. Turning every value into a node makes the graph large and slow to read. A status or a date is a field; a supplier is a node.
• Too few edges. A graph whose records keep their links only as text fields is a document store with extra steps. Add an edge wherever people will ask a question that crosses it.
• A stale copy. A graph loaded once from an export is right on the day it was built. Changes in the sources have to keep arriving, or the graph drifts away from them.
• Permissions left behind. An export carries the records and drops who may read them. A graph built that way shows every user everything, or nobody is allowed to use it.

Five questions separate a useful knowledge graph from a diagram of one:

1. Which three questions does it answer that search cannot? Write them down before modeling anything. Each should cross at least two systems.
2. Where does each node’s identity come from? A key from the source system survives a reload; a generated one may not.
3. How does a change in a source system reach the graph, and how long does that take?
4. Where do permissions live, and when are they checked? Checked once at load time, they go stale. Checked when a question is asked, they hold.
5. Can every answer show its path, from the node it started at to the record it ends on?

Curiosity Studio keeps a typed property graph: nodes are records and entities, edges are named relationships, and fields live on the nodes. Connectors bring in records from more than 70 systems, and a connector SDK in C# or Python writes records for the rest. The graph keeps a synced copy of what each connector maps, linked back to its source. There is no RDF or SPARQL layer.

Permissions live in the same graph. A user is a node, a team is a node, and membership and ownership are edges, as the property graph documentation describes. Access is synced from the source systems and checked per record at query time. A question asked as a user returns only records that user could open in the source.

Search and AI run on that graph, with the model you choose, on your own infrastructure. The knowledge graph page covers the developer side. Studio calls the result a context graph, and What is a context graph? explains where the two differ.