The best-known knowledge graph examples are Wikidata, DBpedia, and the Google Knowledge Graph, but the same structure (identified entities connected by typed relationships under a shared schema) appears in product catalogs, streaming recommendation systems, biomedical research databases, bank fraud detection, and factory digital twins. This page groups the examples by category and ends with a small graph a reader could build in an afternoon. For the underlying concept, see /concepts/what-is-a-knowledge-graph/.

Public and open knowledge graphs

These graphs are freely downloadable or queryable, which makes them the reference examples for the field and the usual source of identifiers that other graphs link to.

Wikidata is the Wikimedia Foundation’s collaboratively edited knowledge graph, launched in October 2012. Items have Q-IDs (Q7186 for Marie Curie, Q243 for the Eiffel Tower), properties have P-IDs, and every statement can carry qualifiers and references. The data is published under CC0, available as RDF dumps, and queryable through a public SPARQL endpoint. Wikidata also serves as the central store of structured data for Wikipedia in all languages, which is why its coverage is broad and multilingual. See /ecosystems/wikidata/ and /ecosystems/wikidata-query-service/.

DBpedia extracts structured facts from Wikipedia infoboxes and publishes them as RDF, a project begun in 2007 by researchers at Freie Universität Berlin and Leipzig University. It was one of the first large linked-data sets and became a hub that other datasets linked to. Its ontology, SPARQL endpoint, and entity IRIs (http://dbpedia.org/resource/Marie_Curie) are still widely used in research. See /ecosystems/dbpedia/.

YAGO (“Yet Another Great Ontology”) comes from the Max Planck Institute for Informatics. It combines instance data derived from Wikipedia and, in recent versions, Wikidata, with a deliberately clean taxonomy built on schema.org classes and logical constraints, so that the graph can be reasoned over without contradictions.

Freebase was a collaboratively built graph created by Metaweb and acquired by Google in 2010. It supplied much of the early data and the /m/ identifier scheme still visible in Google Knowledge Graph MIDs. Google shut Freebase down in 2016 and worked with Wikimedia to migrate suitable content to Wikidata.

ConceptNet is a graph of common-sense knowledge (a “dog” is a “pet,” “bread” is “used for” “making sandwiches”) that grew out of the Open Mind Common Sense project at the MIT Media Lab. Its nodes are mostly words and phrases rather than named entities, and it has been used in natural language processing to give models background knowledge that text corpora rarely state.

Search-engine knowledge graphs

Google Knowledge Graph. Announced in May 2012 with the phrase “things, not strings,” it is the entity graph behind knowledge panels, entity carousels, and much of Google’s query understanding. Its sources include licensed databases, public graphs such as Wikidata, structured data on web pages, and information extracted from the web. The graph is not downloadable, but the Knowledge Graph Search API exposes entity IDs, names, types, and descriptions. For SEO, it is the graph that decides whether a brand or person appears as an entity in results. See /ecosystems/google-knowledge-graph/ and /ecosystems/google-knowledge-panel/.

Microsoft Bing. Bing maintains its own entity graph, developed under the name Satori, that powers entity results and answers in Bing search and is exposed to developers through the Bing Entity Search API. Its role is the same as Google’s: recognize which thing a query refers to and assemble facts about it.

Both engines consume schema.org structured data from web pages as one input, which is the practical link between web publishing and these graphs. See /ecosystems/structured-data/.

Consumer product knowledge graphs

Large consumer companies have described knowledge graphs in engineering blogs, conference talks, and research papers. The descriptions below stick to what those companies have said publicly.

Amazon Product Graph. Amazon researchers have published on a product knowledge graph that connects products to their attributes (brand, material, flavor, compatible devices), to related products, and to the concepts customers use when searching. The stated goal is to answer questions like “which of these is gluten-free” from structured facts rather than text, and to fill in attributes that sellers left blank by extracting them from product descriptions.

Netflix and other streaming services. Streaming platforms have described graph representations of their catalogs in which titles connect to people (actors, directors), genres, themes, and production metadata, and viewing behavior connects members to titles. The graph is one input to recommendation and search alongside statistical models. Netflix’s engineering blog has described knowledge-graph work in its content and studio systems, where relationships between talent, titles, and productions are tracked.

LinkedIn Economic Graph. LinkedIn describes the Economic Graph as a digital representation of the global economy built from its data: members, companies, jobs, skills, schools, and the relationships among them. It underlies features such as job recommendations, and LinkedIn publishes labor-market research derived from it.

Airbnb. Airbnb’s engineering team has described a knowledge graph that connects listings to places, landmarks, activities, and categories, used to provide context for search and discovery (what is near a listing, or which listings fit a category such as “beachfront”).

The common pattern is that these graphs connect items to attributes and concepts so that search and recommendation can operate on meaning (“family-friendly,” “compatible with this model”) rather than on text alone.

Enterprise and domain knowledge graphs

Outside consumer technology, knowledge graphs are most established in fields with many interlinked but separately maintained data sources.

Biomedicine

Hetionet is an open biomedical knowledge graph created by Daniel Himmelstein and collaborators that integrates dozens of public databases into a single network with node types including genes, compounds, diseases, anatomy, pathways, and side effects. It was built to support drug repurposing: finding paths from a compound through genes and pathways to a disease that suggest the compound might treat it. Hetionet is available as a Neo4j database, which makes it a frequently used teaching example of an LPG knowledge graph.

UMLS (the Unified Medical Language System), maintained by the U.S. National Library of Medicine, is an older and larger resource. Its Metathesaurus integrates over a hundred biomedical vocabularies (SNOMED CT, MeSH, ICD, RxNorm and others) by assigning a Concept Unique Identifier (CUI) to each concept and mapping every vocabulary’s terms onto it, while its Semantic Network defines the types and relationships. It is a knowledge graph built primarily to solve entity resolution across vocabularies.

Finance

Banks and payment companies use graphs that connect customers, accounts, devices, addresses, transactions, and counterparties. Fraud rings that are invisible in a table of individual transactions become visible as clusters of accounts sharing a phone number or device, or as circular money movements. The same graphs support anti-money-laundering investigations, sanctions screening (resolving whether a counterparty is the sanctioned entity under a variant spelling), and know-your-customer checks that trace beneficial ownership across corporate structures.

Manufacturing and digital twins

A digital twin is a data model of a physical asset (a turbine, a production line, a building) kept in sync with the asset’s state. Knowledge graphs serve as the backbone of digital twins because they can represent the asset hierarchy (plant, line, machine, component), the relationships between components, attached sensor streams, and maintenance history in one queryable structure. The W3C’s Semantic Sensor Network ontology and the Building Topology Ontology (BOT) exist for this purpose.

Enterprise search and data catalogs

Many organizations build a graph of their own people, teams, projects, documents, systems, and customers so that internal search can answer relationship questions (“which team owns this API,” “which customers use this feature”). The same graph doubles as a data catalog, and it is the most common starting point for retrieval-augmented generation over a knowledge graph; see /build/graphrag/.

A small knowledge graph you could build

Knowledge graphs do not need to be large to be useful. The following graph describes one university’s departments, a program, and a faculty member in eight triples, using schema.org vocabulary in Turtle syntax. The university is fictional.

@prefix ex:     <https://example.edu/kg/> .
@prefix schema: <https://schema.org/> .
ex:ExampleStateUniversity a schema:CollegeOrUniversity ;
    schema:name "Example State University" .
ex:DeptOfComputerScience a schema:EducationalOrganization ;
    schema:name "Department of Computer Science" ;
    schema:parentOrganization ex:ExampleStateUniversity .
ex:MSDataScience a schema:EducationalOccupationalProgram ;
    schema:name "M.S. in Data Science" ;
    schema:provider ex:DeptOfComputerScience .
ex:ProfLinRodriguez a schema:Person ;
    schema:worksFor ex:DeptOfComputerScience .

With this in place, a SPARQL query can already answer “which programs does Example State University offer” by following schema:provider and then schema:parentOrganization, even though no triple states the university-to-program relationship directly. Adding faculty, courses, and research areas is a matter of adding triples. Publishing the same data as JSON-LD on the university’s program pages makes it structured data that search engines can read, which is where the developer and SEO views of a knowledge graph meet. Triple syntax is explained at /concepts/triples-subject-predicate-object/, and query basics at /languages/sparql/.

For developers

The public graphs above are the fastest way to learn by doing. Wikidata’s SPARQL endpoint requires no setup. Hetionet ships as a Neo4j dump, which makes it a convenient way to try Cypher against a real domain graph. When starting an in-house graph, the examples suggest a pattern: begin with the two or three source systems whose data most needs to be joined, reuse schema.org or a domain ontology rather than designing a vocabulary from scratch, and link entities to public identifiers (Q-IDs, MIDs, UMLS CUIs) from the first load. Tooling options are compared at /build/knowledge-graph-tools/ and Python approaches at /build/knowledge-graph-python/.

For SEOs

Three of these examples matter directly for search visibility. The Google Knowledge Graph determines whether an organization or person is shown as an entity. Wikidata is one of its public inputs and the one a site can most directly influence, subject to Wikidata’s notability rules. Schema.org structured data on the site’s own pages is the third, and it is entirely under the publisher’s control. The university graph above, published as JSON-LD, is the kind of data that helps a search engine connect a program page to the department and institution that offer it. See /seo/entity-seo/ and /seo/organization-schema/.

How to pick a knowledge graph use case

The examples share a set of conditions under which a graph earns its cost, and those conditions make a reasonable checklist for a new project.

1. The questions are about relationships. “Which compounds target genes involved in this disease” and “which accounts share a device with this one” are path questions. If the questions are aggregations over one table, a graph adds little.
2. The data comes from several sources that describe the same things. Integration and entity resolution are where graphs do work that tables do not.
3. The schema will keep changing. Adding a new relationship type to a graph means adding edges. Adding one to a relational schema means a migration.
4. Explanations matter. Recommendation and fraud systems that must justify a result benefit from explicit paths.
5. Others need to reuse the data. Where data will be shared across organizations or linked to public identifiers, RDF with shared vocabularies pays off. Where it stays inside one application, an LPG database is often simpler.

Where two or more conditions hold, the examples on this page suggest starting small (a few entity types, a few sources, one concrete question) and growing the graph as the questions multiply.

Related pages

• What is a knowledge graph?
• What is an entity?
• Google Knowledge Graph
• Wikidata
• Knowledge graph vs. graph database
• GraphRAG

FAQ

What is the most famous example of a knowledge graph?

The Google Knowledge Graph, announced in May 2012, is the most widely recognized because it powers the knowledge panels shown in Google search results. Among open graphs, Wikidata is the best-known example: it is free to download and query, edited collaboratively, and identifies every item with a Q-ID that other graphs link to.

Is Wikipedia a knowledge graph?

No. Wikipedia is an encyclopedia of prose articles. Wikidata, its sister project, is the knowledge graph: it stores the same facts as structured statements (item, property, value) with identifiers, qualifiers, and references. DBpedia is a separate project that extracts structured data from Wikipedia infoboxes and publishes it as a graph.

What are common knowledge graph use cases in business?

The most established business uses are enterprise search and question answering over internal data, product and content recommendations, fraud detection and compliance in financial services, customer data integration, drug discovery and clinical data integration in life sciences, and digital twins in manufacturing. Grounding large language model applications in verified facts is the fastest-growing use.

Can a small organization build a knowledge graph?

Yes. A useful graph can start with a few dozen entities and one or two relationship types, expressed in Turtle or JSON-LD with schema.org vocabulary, and stored in a free triple store or graph database. Publishing the same data as structured data on the organization’s website gives it immediate value for search, and the graph can grow as new questions arise.

Sources and further reading

• 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
• DBpedia Association. About DBpedia. https://www.dbpedia.org/about/
• Hetionet project page. https://het.io/
• U.S. National Library of Medicine. Unified Medical Language System (UMLS). https://www.nlm.nih.gov/research/umls/index.html
• Hogan, A. et al. Knowledge Graphs. Morgan & Claypool, 2021. https://kgbook.org/