Knowledge Graph Ecosystems: Google, Wikidata, DBpedia & Schema.org

Knowledge graph ecosystems are the public and proprietary knowledge bases that hold entity data at web scale, together with the vocabularies and APIs that move data between them. Three of them matter to most practitioners: Google’s Knowledge Graph, which is private and drives knowledge panels; Wikidata and DBpedia, which are open and queryable; and schema.org, the shared vocabulary that lets an ordinary website contribute entity statements of its own. This section covers each one, how they reference each other, and what a publisher can actually influence.

The pattern connecting them is identifier reuse. A single organization can exist as a Wikidata item, a DBpedia resource, a Google Knowledge Graph entity with a machine ID, and a set of schema.org statements on its own domain. What binds those four records into one entity is not string matching on the name but explicit links between identifiers, the mechanism described in linked data. Everything in this section is a variation on that idea.

Google Knowledge Graph

Google announced its Knowledge Graph in May 2012 with the phrase “things, not strings”, built on the Freebase data it had acquired two years earlier. It is a closed knowledge base: no dump, no SPARQL endpoint, and no public account of how any given fact got in. Entities carry machine identifiers of the form /m/..., a convention inherited directly from Freebase. The Google Knowledge Graph page covers that lineage, how entity IDs work, and what search engineers have documented about how the graph is populated.

Google Knowledge Graph Search API

The one official read path into the graph is a lookup API at https://kgsearch.googleapis.com/v1/entities:search. It takes a query string or an entity ID, requires an API key, and returns a JSON-LD list of candidate entities with a resultScore for each. It answers a narrow question well and is often mistaken for something larger. The Knowledge Graph Search API page provides working curl and Python examples, explains what the response fields do and do not contain, and sets out why the API is not a window onto knowledge panel generation.

Google Knowledge Panel

A knowledge panel is the information box Search shows beside or above results when it is confident the query names an entity it holds. Panels come in distinct varieties with distinct data sources: organizations and brands, people, local businesses fed by Google Business Profile, and creative works such as films and books. The Google knowledge panel page covers each type, the knowledge sources behind them, and the two feedback mechanisms Google offers: verified claiming and suggested edits.

How to Get a Knowledge Panel

Panels are generated, not requested, so the practical work is making an entity unambiguous and well corroborated rather than filing an application. That means one canonical page that serves as the entity home, consistent naming across every property, sameAs links to the identifiers other systems already use, and independent third-party coverage that repeats the same facts. The how to get a knowledge panel page gives an ordered checklist and states plainly which steps have documented effects and which are practitioner inference.

Wikidata

Wikidata is a collaboratively edited knowledge base run by the Wikimedia Foundation, holding well over 100 million items. Each item has a Q-ID (Albert Einstein is Q937), each statement uses a numbered property (P31 for “instance of”), and statements carry references and qualifiers so that contested facts can coexist with their sources. It publishes full RDF dumps under CC0 and is the most widely reused identifier hub on the open web. The Wikidata page covers the data model, the API, notability requirements, and how to contribute without getting an edit reverted.

Wikidata Query Service

The Wikidata Query Service exposes the whole knowledge base over SPARQL at query.wikidata.org, which makes questions possible that no keyword search answers: every public university in a given state with its enrollment figure, every person with a stated occupation and a death date in a given decade. The Wikidata Query Service page collects copy-paste queries that run against the live endpoint, with notes on labels, timeouts and federation. The query language itself is covered at SPARQL.

DBpedia

DBpedia extracts structured data from Wikipedia infoboxes and republishes it as RDF with its own ontology and a public SPARQL endpoint. It predates Wikidata and was the original center of the linked open data cloud, so dbpedia.org/resource/... URIs are cited across an enormous amount of older research and tooling. It remains useful for its ontology, its per-language chapters, and DBpedia Spotlight, an entity linking service. The DBpedia page covers the extraction framework and where DBpedia still beats Wikidata for a given job.

Schema.org

Schema.org is a shared vocabulary of types and properties, launched in 2011 and maintained by a community project with Google, Microsoft, Yahoo and Yandex among its sponsors. It defines what a Person, an Organization or a Course is and which properties apply to each, along with an inheritance hierarchy that lets a CollegeOrUniversity borrow everything an Organization has. It is a vocabulary and not a syntax, which is why the same schema.org statements can be written in JSON-LD, RDFa or Microdata. The schema.org page covers types, properties, extension mechanisms and how the vocabulary evolves.

Structured Data

Structured data is the on-page layer of all of this: the markup a site publishes so that a crawler can read its entities and relationships without inferring them from prose. It is where a publisher’s own graph meets everyone else’s, and the only part of the ecosystem under direct editorial control. The structured data page covers what search engines document about how they consume it, what LLM-based systems appear to do with it, and how to validate what a site is emitting.

How the pieces connect

For a developer, the useful mental model is a directed set of feeds. Wikipedia editors write articles; Wikidata holds machine-readable statements about the same subjects, increasingly as the primary source rather than a mirror; DBpedia extracts from Wikipedia independently; Google ingests from many sources including licensed data and open bases and reconciles them into its own graph. None of these is a copy of another, so the same entity can carry conflicting values in each. Anyone querying more than one needs a reconciliation step, and identifiers are how that step succeeds. Start with what is a knowledge graph for the underlying structure.

For an SEO, the model is simpler and more constrained. Nothing here is a control surface. A site cannot write to Google’s Knowledge Graph, and Wikidata is not an intake form for it. What a site can do is state its own entity clearly, in markup, at a stable identifier, and make sure the claims it makes are repeated by sources it does not own. The tactics are collected in knowledge graph SEO and entity SEO.

Frequently asked questions

What is the difference between Wikidata and the Google Knowledge Graph?

Wikidata is an open, collaboratively edited knowledge base with public dumps, a SPARQL endpoint, and item identifiers anyone can cite. The Google Knowledge Graph is Google’s private knowledge base, built from many sources including licensed data, with no dump and no public edit path. Google reconciles against open sources, but a Wikidata edit is not an edit to Google’s graph.

Which public knowledge graph should a project use?

Use Wikidata for breadth, current data, permissive licensing and a live SPARQL endpoint. Use DBpedia when the Wikipedia infobox text itself is the object of study, when a language-specific chapter is needed, or when DBpedia Spotlight fits an entity linking task. Many projects load both and reconcile them through the Wikidata item identifiers that DBpedia resources carry.

Do search engines read structured data from every site?

Search engines document that they extract structured data broadly, but extraction is not the same as use. Google states that only some types are eligible for rich results, and that ineligible markup may be read without producing any visible change. Correct markup on a low-authority site is read; whether it influences anything depends on corroboration elsewhere.

Is schema.org owned by Google?

No. Schema.org is a community project with its own steering group, hosted at schema.org and developed in public on GitHub. Google, Microsoft, Yahoo and Yandex founded and sponsor it, and Google publishes its own separate documentation for the subset of types it supports for rich results, which is narrower than the full vocabulary.

Sources and further reading

Google. Introducing the Knowledge Graph: things, not strings (May 2012). https://blog.google/products/search/introducing-knowledge-graph-things-not/
Google Developers. Knowledge Graph Search API. https://developers.google.com/knowledge-graph
Google Search Central. Introduction to structured data markup. https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
Wikidata. Introduction. https://www.wikidata.org/wiki/Wikidata:Introduction
DBpedia. https://www.dbpedia.org/
schema.org. https://schema.org/
The Linked Open Data Cloud. https://lod-cloud.net/