API glossary

Knowledge graph

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

A knowledge graph is a structured representation of knowledge as a network of entities (e.g. people, places, products, or concepts) and the relationships that connect them. Instead of storing information as isolated text, a knowledge graph records facts as nodes (the entities) linked by edges (the relationships), often with types and attributes attached. This allows both machines and people to more easily understand how things relate to one another.

In short: a knowledge graph stores facts as connected things rather than plain text: entities as nodes, their relationships as the links between them.

How a knowledge graph works

The structure is built from things and the connections between them:

  1. Entities as nodes: Each real-world thing, such as a company, a person, or a city, becomes a node with a unique identifier and a type.
  2. Relationships as edges: Nodes are connected by labeled edges stating how they relate, such as “founded by,” “located in,” or “works for.”
  3. Attributes: Nodes and edges can carry properties, such as a founding date or a population, that add detail beyond the connections themselves.
  4. A schema or ontology: A defined set of allowed entity types and relationship types keeps the graph consistent and easily queried (think of it as the rulebook that defines what kinds of things and relationships the graph is permitted to contain).
  5. Population: The graph is built by extracting entities from sources (often via entity extraction over text), extracting relationships (via relation extraction), linking entities to canonical identities, and then merging/resolving duplicates so each real-world thing maps to a single node.
  6. Querying: Applications move across the graph to answer questions that span multiple hops, such as “which companies were founded by people who studied here?”

The defining idea is that meaning lives in the connections: a knowledge graph captures not just what things are but how they relate, which lets a system reason across facts rather than retrieve them one at a time.

Knowledge graph vs. vector and relational databases

  • A vector database represents meaning as numeric vectors for similarity search; a knowledge graph represents meaning as explicit, labeled facts and relationships. One is fuzzy and statistical, the other precise and symbolic, and modern systems often combine the two.
  • A relational database stores data in fixed tables of rows and columns; a knowledge graph is built for richly connected data and multi-hop relationships across many entity types.
  • Entity and relation extraction are steps that find entities and relationships in text; related to entity extraction, a knowledge graph is the structure those extracted facts populate.

Where knowledge graphs are used

  • Search and answer engines: Understanding the things in a query rather than only the words, the shift Google described as “things, not strings” when it launched its Knowledge Graph. Open knowledge graphs such as Wikidata (one of the largest publicly available knowledge graphs, collaboratively maintained and freely queryable) play a similar role across the web.
  • Grounding and GraphRAG: Connecting an LLM to a knowledge graph can supply structured facts with provenance and can reduce hallucinations when graph quality, coverage, freshness, and retrieval are strong.
  • Recommendations: Relationships among users, products, and attributes drive suggestions such as “related to” and “people also bought.”
  • Enterprise data integration: Unifying information scattered across systems into one connected, easily queried model of an organization’s knowledge.

Knowledge graphs matter most when the value lies in the connections between facts: when answering a question means checking relationships between facts, not just matching text.

Entity extraction, semantic search, embeddings, vector database, structured data, schema.org, retrieval-augmented generation (RAG), ontology, hallucination.