What Is a Knowledge Graph? Definition, Components & Examples

A knowledge graph is a structured representation of real-world things (people, places, organizations, products, concepts) and the relationships between them, stored as a graph of nodes and edges that both software and people can query. Each thing is an entity with a stable identifier, each relationship is a typed link, and the whole structure is organized by a schema or ontology that gives the data shared meaning. The term is used for public resources such as Wikidata, for the Google Knowledge Graph behind search results, and for private graphs that companies build over their own data.

Knowledge graph definition

The shortest working definition: a knowledge graph is a graph of entities and their relationships, with a schema that says what the entities and relationships mean.

Three parts of that sentence carry weight. “Graph” means the data model is nodes connected by edges, rather than rows in tables. “Entities” means the nodes represent identifiable things in the world, each with its own identifier, rather than strings of text. “Schema” means the graph declares its vocabulary (which classes exist, which properties connect them) so that the same fact means the same thing wherever it appears.

The survey by Hogan et al., Knowledge Graphs (2021), describes a knowledge graph as “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.” That definition covers graphs built on the W3C’s RDF standard and graphs built in a labeled property graph (LPG) database such as Neo4j, as long as the graph is about real-world entities and carries enough structure to be interpreted.

Components: nodes, edges, labels, and literals

Every knowledge graph is built from a small number of building blocks.

Nodes represent entities. Marie Curie is a node. Warsaw is a node. The Nobel Prize in Physics is a node. In RDF the node is identified by an IRI (a web-style identifier such as http://www.wikidata.org/entity/Q7186); in an LPG database it is identified by an internal ID plus one or more labels.

Edges represent relationships between nodes. “Marie Curie, place of birth, Warsaw” is one edge. Edges are directed and typed: the direction runs from subject to object, and the type (the predicate, or property) says what kind of relationship it is. In RDF, one node-edge-node unit is a triple, discussed in detail at /concepts/triples-subject-predicate-object/.

Labels and types attach meaning to nodes and edges. A type says which class an entity belongs to (Marie Curie is an instance of Person; Warsaw is a City). A label is the human-readable name, often in several languages. Types come from the schema; labels are ordinary data.

Literals are plain values with no identity of their own: the string “Marie Curie”, the date 1867-11-07, the integer 1903. A literal sits at the end of an edge but cannot start one. That is the difference between an entity and a literal: Warsaw as an entity can have its own edges (country: Poland, population, coordinates), while “Warsaw” as a literal is a name and nothing more. Storing a city as a string is the most common reason a graph cannot answer the questions it was built for. The concept of an entity gets its own treatment at /concepts/what-is-an-entity/.

How a knowledge graph differs from adjacent things

The term is often used interchangeably with several neighbors. They are related but distinct.

Concept	What it is	How it differs from a knowledge graph
Relational database	Data in tables with fixed columns and foreign keys	Relationships are implied by joins, not stored as first-class edges; schema is rigid and local to one application
Graph database	Software for storing and querying graph-shaped data	A storage engine; a knowledge graph is the data (entities, relations, schema) that may live in one
Ontology	A formal description of classes, properties, and the rules relating them	The schema layer; a knowledge graph combines an ontology (or lighter schema) with the instance data
Taxonomy	A hierarchy of categories (broader/narrower)	A single tree of one relationship type; a knowledge graph has many relationship types and no required hierarchy
Vector database	Stores embeddings for similarity search	Returns “similar” items by distance; a knowledge graph returns explicit, explainable facts

A relational database can hold the same facts, but the meaning of a join lives in application code, not in the data. A graph database is a tool; a knowledge graph can be stored in one, and so can a social network that nobody would call a knowledge graph. For longer comparisons, see/concepts/knowledge-graph-vs-graph-database/, /concepts/knowledge-graph-vs-ontology/, and /concepts/knowledge-graph-vs-vector-database/.

How knowledge graphs are built

Knowledge graphs are assembled rather than written. Most projects combine the following activities and then repeat them.

Integration of existing structured sources. Databases, spreadsheets, product catalogs, and public datasets are mapped onto graph entities and properties. The W3C’s R2RML standard exists specifically for mapping relational tables to RDF.
Extraction from unstructured text. Named-entity recognition finds mentions of people, places, and organizations in documents; relation extraction finds the connections between them; entity linking maps each mention to an identifier already in the graph. See /concepts/entity-linking-ner-and-extraction/.
Schema and ontology design. The team decides which classes and properties the graph uses, often reusing existing vocabularies (schema.org, SKOS, the Gene Ontology) rather than inventing new ones. See /concepts/ontologies/.
Identity and context. Records that describe the same thing are merged (entity resolution), and facts that are only true at a certain time or from a certain source carry that context. Wikidata uses qualifiers and references; RDF uses named graphs or RDF-star; LPG databases use edge properties.
Reasoning and validation. Rules infer unstated facts (if Warsaw is in Poland and Poland is in Europe, Warsaw is in Europe) and constraints check that data is well-formed (every Person has at most one birth date). OWL supports the former, SHACL the latter.
Machine-learning enrichment. Knowledge graph embeddings predict missing edges and detect errors; large language models extract information and turn questions into queries. See /concepts/knowledge-graph-embeddings/.

None of these steps is one-time. Wikidata is edited continuously; enterprise graphs are reloaded from their sources on a schedule.

Worked example: Marie Curie in Turtle and JSON-LD

The following graph records that Marie Curie was born in Warsaw and was awarded the Nobel Prize in Physics in 1903. The year is attached to the award as its own node, because “awarded” is a relationship with a date, and dates cannot be hung directly on an edge in plain RDF.

In Turtle, the W3C’s compact text syntax for RDF:

@prefix ex:     <https://example.org/kg/> .
@prefix schema: <https://schema.org/> .
@prefix xsd:    <http://www.w3.org/2001/XMLSchema#> .

ex:MarieCurie a schema:Person ;
    schema:name "Marie Curie" ;
    schema:birthDate "1867-11-07"^^xsd:date ;
    schema:birthPlace ex:Warsaw ;
    ex:awarded ex:NobelPhysics1903 ;
    schema:sameAs <http://www.wikidata.org/entity/Q7186> .

ex:Warsaw a schema:City ;
    schema:name "Warsaw" ;
    schema:sameAs <http://www.wikidata.org/entity/Q270> .

ex:NobelPhysics1903 a ex:AwardEvent ;
    ex:prize ex:NobelPrizeInPhysics ;
    ex:year "1903"^^xsd:gYear .

ex:NobelPrizeInPhysics a schema:Thing ;
    schema:name "Nobel Prize in Physics" ;
    schema:sameAs <http://www.wikidata.org/entity/Q38104> .

Each line ending in ; or . is one triple. ex:MarieCurie is a node; schema:birthPlace is an edge type; ex:Warsaw is another node; "Marie Curie" and "1867-11-07"^^xsd:date are literals. The schema:sameAs links tie the local entities to their Wikidata counterparts, so any system that knows Q7186 can merge this data with its own.

The same graph in JSON-LD, the JSON syntax for RDF that is also the format Google recommends for structured data on web pages:

{
  "@context": {
    "@vocab": "https://schema.org/",
    "ex": "https://example.org/kg/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "birthPlace": { "@type": "@id" },
    "sameAs": { "@type": "@id" },
    "birthDate": { "@type": "xsd:date" },
    "awarded": { "@id": "ex:awarded", "@type": "@id" },
    "prize": { "@id": "ex:prize", "@type": "@id" },
    "year": { "@id": "ex:year", "@type": "xsd:gYear" }
  },
  "@graph": [
    {
      "@id": "ex:MarieCurie",
      "@type": "Person",
      "name": "Marie Curie",
      "birthDate": "1867-11-07",
      "birthPlace": "ex:Warsaw",
      "awarded": "ex:NobelPhysics1903",
      "sameAs": "http://www.wikidata.org/entity/Q7186"
    },
    {
      "@id": "ex:Warsaw",
      "@type": "City",
      "name": "Warsaw",
      "sameAs": "http://www.wikidata.org/entity/Q270"
    },
    {
      "@id": "ex:NobelPhysics1903",
      "@type": "ex:AwardEvent",
      "prize": "ex:NobelPrizeInPhysics",
      "year": "1903"
    },
    {
      "@id": "ex:NobelPrizeInPhysics",
      "@type": "Thing",
      "name": "Nobel Prize in Physics",
      "sameAs": "http://www.wikidata.org/entity/Q38104"
    }
  ]
}

The two documents describe the identical set of triples. A JSON-LD processor will expand the second into the first, which is the point of having a shared data model beneath multiple syntaxes. More on the syntax at /languages/json-ld/ and /languages/rdf/.

Public knowledge graphs

Google Knowledge Graph. Google introduced it in May 2012 with the phrase “things, not strings,” describing a shift from matching query text against page text to recognizing that a query refers to a specific thing. It powers knowledge panels and entity carousels in results. The graph is not downloadable, but the Knowledge Graph Search API returns entity IDs (MIDs such as /m/0jcx for Albert Einstein), names, descriptions, and types. See /ecosystems/google-knowledge-graph/.

Wikidata. The Wikimedia Foundation’s free, collaboratively edited knowledge graph, launched in October 2012. Every item has a Q-ID (Q7186 is Marie Curie, Q937 is Albert Einstein, Q243 is the Eiffel Tower) and every property has a P-ID (P19 is place of birth). Statements carry qualifiers and references. The full graph is available as RDF dumps and through a public SPARQL endpoint. See /ecosystems/wikidata/.

DBpedia. A project that extracts structured facts from Wikipedia infoboxes and publishes them as linked data, begun in 2007. DBpedia was one of the earliest large RDF datasets and a hub of the linked open data cloud. See /ecosystems/dbpedia/.

YAGO. A knowledge base from the Max Planck Institute for Informatics that combines Wikipedia-derived facts with a clean taxonomy (recent versions use schema.org classes over Wikidata data).

Further examples are collected at /concepts/knowledge-graph-examples/.

Enterprise uses

Outside the public web, knowledge graphs are built where the value lies in connecting data that was previously kept apart.

Search and question answering. An internal graph of products, documents, people, and projects lets a search system answer “who owns the pricing service” rather than returning documents containing the words “pricing” and “service.” Graph-based retrieval also grounds large language models; see /build/graphrag/.

Recommendations. Linking users, items, and item attributes (genre, director, brand) in one graph allows recommendations that follow explicit paths, which are easier to explain than purely statistical ones.

Fraud and compliance. Financial institutions connect accounts, people, addresses, devices, and transactions to find rings of related activity that no single record reveals.

Drug discovery. Graphs such as Hetionet connect genes, compounds, diseases, and pathways from dozens of public databases so that researchers can look for paths suggesting a compound might treat a disease.

For developers

The two dominant stacks are RDF and labeled property graphs. In the RDF stack the data model is triples, the schema languages are RDFS, OWL, and SHACL, the query language is SPARQL, and the serializations are Turtle, JSON-LD, and N-Triples. Stores include Apache Jena, GraphDB, Stardog, and Amazon Neptune. In the LPG stack, nodes and edges carry arbitrary key-value properties; the query language is Cypher (Neo4j), Gremlin, or the ISO GQL standard, and the schema is typically optional. Neo4j, Memgraph, and Amazon Neptune (which supports both models) are common choices.

RDF is the natural fit when data will be shared across organizations, linked to public identifiers, or reasoned over with OWL. LPG is often chosen for application-embedded graphs where developer ergonomics and traversal performance matter more than interoperability. The trade-offs are at /concepts/property-graph-vs-rdf/, and we survey tooling at /build/knowledge-graph-tools/.

For SEOs

Search engines treat the web as a source of facts about entities, and a knowledge graph stores those facts. Three consequences follow. A brand, person, or product that exists as an entity in the Google Knowledge Graph can receive a knowledge panel; one that exists only as text on a page cannot. Structured data in JSON-LD using schema.org vocabulary is the most direct way to tell a search engine which entities a page is about, especially when sameAs links point to Wikidata, Wikipedia, and official profiles. AI-generated answers in search draw on the same entity understanding, so making entities explicit carries over to AI search.

The SEO-specific material is at /seo/entity-seo/, /ecosystems/google-knowledge-panel/, and /seo/knowledge-graphs-ai-search-and-llms/.

Common misconceptions

“A knowledge graph is a graph database.” A graph database is software. A knowledge graph is data with a schema. One can be stored in the other, or in a triple store, or as files.

“A knowledge graph must use RDF.” RDF is the standard with the deepest tooling for shared vocabularies and identifiers, but graphs built in LPG databases are knowledge graphs when they model real-world entities with a defined schema.

“Knowledge graphs replace machine learning.” In practice, they feed it. Embeddings are trained on graphs, language models are grounded with them, and extraction models populate them.

“Google’s Knowledge Graph is Wikidata.” Google’s graph draws on many sources, including licensed data and the web itself. Wikidata is one public input, but the two are separate systems with separate identifiers.

“A knowledge graph is finished when loaded.” Maintenance (re-extraction, resolution, validation) makes up most of the work over a graph’s life.

FAQ

What is a knowledge graph in simple terms?

A knowledge graph is a map of things and how they connect. Each thing (a person, city, company, or idea) is a point, each connection (born in, works for, part of) is a line, and each point has an identifier so the same thing is never confused with something else that shares its name. Software can follow the lines to answer questions.

What is the difference between a knowledge graph and a database?

A relational database stores facts in tables and expresses relationships through keys that application code must join. A knowledge graph stores relationships as explicit, typed edges between identified entities and attaches a schema that defines what each class and property means. The result is data that can be queried by relationship, merged with other graphs, and interpreted without the original application.

Is Wikidata a knowledge graph?

Yes. Wikidata is a free, publicly editable knowledge graph maintained by the Wikimedia Foundation. Each item has a Q-ID (Marie Curie is Q7186), each property has a P-ID, and statements carry qualifiers and source references. The whole graph is available as RDF downloads and through a SPARQL query service, which makes it the most widely reused public knowledge graph.

Who uses knowledge graphs?

Search engines (Google, Bing) use them to recognize entities and show knowledge panels. Technology, retail, and media companies use them for search, recommendations, and product data. Banks use them for fraud detection and compliance. Pharmaceutical and research groups use them to connect genes, compounds, and diseases. Increasingly, teams building applications on large language models use them to ground answers in verified facts.

Sources and further reading

Hogan, A. et al. Knowledge Graphs. Morgan & Claypool, 2021. Free online edition at https://kgbook.org/
W3C. RDF 1.1 Primer. https://www.w3.org/TR/rdf11-primer/
W3C. RDF 1.1 Turtle. https://www.w3.org/TR/turtle/
W3C. JSON-LD 1.1. https://www.w3.org/TR/json-ld11/
Google. “Introducing the Knowledge Graph: things, not strings” (2012). https://blog.google/products/search/introducing-knowledge-graph-things-not/
Wikidata. Wikidata:Introduction. https://www.wikidata.org/wiki/Wikidata:Introduction