Blog · Machine readability

Knowledge graphs, Wikidata and the brand facts engines reuse

Published 8 October 2026 · Updated 12 October 2026 · 8 min read

Knowledge graphs, Wikidata and the brand facts engines reuse
Photograph: GeoJango Maps / unsplash

The short answer: A knowledge graph stores your company as an identifier with sourced statements hanging off it, not as a page of text. Wikidata is the largest open one, published under CC0, and since October 2025 Wikimedia Deutschland has run a public vector database of it with a Model Context Protocol endpoint, so an assistant can be pointed at the graph at answer time. We cannot see which engines do that. Facts you leave missing or contradictory in a freely copyable graph are facts you have no hand on downstream.

Most brand teams treat this as a Wikipedia problem. It is a different problem, with different rules, and the rules are written down.

A graph stores identifiers, not sentences

A page says "founded in 2019 in Bengaluru". A graph says Q00000000 → inception → 2019, where Q00000000 is a stand-in for whatever identifier the company actually holds, and attaches a reference to that one statement. Each node has a stable identifier, each statement has a property, a value and usually a citation. Nothing is prose, so nothing has to be parsed out of prose.

That structure is why machines like it. A retrieval system reading your about page has to decide which of four dates is the founding date. A retrieval system reading a graph gets one typed value, plus the source it came from, plus the date that value was last edited. Ambiguity is expensive at scale, and graphs remove a lot of it.

Two consequences follow for anyone doing structured data for AI search. Your markup is not the graph. Your markup is a claim submitted to whoever is building one, and it competes with claims from registries, press coverage and the brand's own older pages.

Wikidata is the open graph, and it is large

One call to Wikidata's own statistics endpoint, action=query&meta=siteinfo&siprop=statistics, returned 123,613,104 items, 45,200 accounts counted as active and 2,555,671,169 edits since launch when we ran it on 12 October 2026. Those are the site's self-reported counters at one moment, not an independent audit of them. Scale alone is not the interesting part. Licensing is: the whole thing is CC0, so anyone may copy it into a commercial index without a negotiation. Which indexes have actually done so is not visible from outside, and we are not claiming to know. The licence tells you only that nothing stops them.

The reuse path widened in October 2025, when Wikimedia Deutschland published a vector database of Wikidata with semantic search and a Model Context Protocol endpoint at wd-vectordb.wmcloud.org, per its own release announcement of 1 October 2025. An assistant wired to that endpoint can resolve a company against the graph at answer time rather than relying on whatever it absorbed during training, and knowledge cutoffs get less load-bearing when a live structured lookup is one call away. That is what the release makes possible. Whether any consumer assistant queries it by default is not something we can observe, and we have not tested it. For a brand, the honest reading is that an old, half-filled Wikidata item is now cheap for somebody else to read, and still yours to fix.

Google runs its own graph as well. Its developer documentation carries a migration warning steering users off the legacy Knowledge Graph Search API toward the Cloud Enterprise Knowledge Graph product, and describes that API as read-only. There is no public write path into Google's graph. You can only change the inputs it reads, which is the whole argument for governing brand facts in one place before anyone touches a wiki.

The notability gate, and the failure mode nobody expects

Wikidata's notability policy accepts an item on any one of three grounds: it carries a valid sitelink to a Wikimedia project, or it describes a clearly identifiable entity that serious and publicly available references can describe, or it is structurally needed to make other items work. The second route is the one most companies qualify under, and it is narrower than it reads. The policy asks for serious and publicly available references, and in deletion discussions self-published material is routinely discounted. A funding announcement in a trade publication, a regulator filing, a company registry entry: those carry more weight.

Here is the pattern we run into most often in audit work. We have not counted it across a defined sample, so read it as something we recognise rather than as a rate. Somebody creates an item in an afternoon, fills in the label, the description and the website, cites nothing, and the item is nominated for deletion within weeks. The brand concludes that Wikidata is hostile. What actually happened is that an unsourced statement was treated exactly as the policy says it will be.

The second pattern is quieter and worse. A company ends up with two items, one created from an old press mention and one created by the marketing team, each with different founding dates. Nothing breaks visibly. A downstream consumer has to pick one, and we have found no way, from outside, to learn which it picked. Duplicate identity is the same disease that sameAs and the identity links engines check exists to treat, and a duplicate inside the graph itself is harder to spot than a stale LinkedIn page.

Four checks, about ten minutes

Run these before you edit anything.

Does an item exist, and only one. Query the search endpoint directly and read the descriptions rather than trusting the web interface:

curl "https://www.wikidata.org/w/api.php?action=wbsearchentities&search=YOURBRAND&language=en&type=item&limit=10&format=json"

We ran that exact call on 12 October 2026 for the marketing software company whose item is Q5926631. It returned that company first, a similarly named Python client library second, and two implementation agencies after it. That is one query on one day against a live endpoint whose ranking can change, not a benchmark, and you should re-run it for your own name rather than rely on ours. The ordering is still a usable proxy for how confidently an automated consumer could pick you out of a name collision.

When was it last touched. Ask for the item's metadata with action=wbgetentities&props=info and read the modified timestamp. An item nobody has edited in three years is probably describing a company that no longer exists in that shape.

Which statements carry references. Open the item and look at the reference count under each claim, not at how full the page looks. Unreferenced claims are the ones deletion discussions go after first. Whether a particular downstream consumer discounts them is not something we can see, so treat references as the part you control, not as a known filter.

Does the official website property point at you. P856 should hold your canonical domain, matching the url in your Organization markup exactly, including the www decision. Google's Organization documentation says the url property helps it identify your organisation uniquely, so a mismatch between the two is a self-inflicted wound. That is Google's stated behaviour for its own structured data, not a rule we have confirmed for other engines.

The self-check has the rest of the ten minute version, including the non-graph identity checks.

What you control, in order

You do not control the graph. You control three inputs to it, and the order is worth keeping.

Publish the facts once, somewhere canonical, with Organization markup that names the entity, the URL, the logo and the profiles you want linked. Make every external profile repeat the same spelling, the same founding year, the same city. Then, and only then, let somebody who understands the project norms fix the Wikidata item with references to independent sources, declaring any conflict of interest.

The ordering matters because an editor who checks your claim needs something to check it against. Fixing the wiki first, while your own site still says something different, invites a revert. This is the same sequencing argument as Wikipedia, and the brand facts engines inherit, one layer down in the stack.

Honest limits

We cannot show you a clean causal line from a corrected Wikidata item to a changed AI answer. The engines do not expose which graph lookup fed which sentence, and a correction lands alongside a dozen other changes. What we can say is narrower: on a handful of audits where a brand had contradictory founding dates or a duplicate item, the wrong value appeared in answers, and after the contradiction was removed the wrong answer stopped recurring in our re-runs. We did not hold anything else constant and we have no control group, so that is an association from a small, unrepresentative set of sites, not a law.

Three things in this post are deliberately unproven. We have not tested whether any assistant queries the Wikidata vector endpoint in normal use, so the reuse argument rests on what the release enables rather than on observed traffic. The item, editor and edit counts are Wikidata's own counters read once on 12 October 2026, so a re-run will differ. And the search-ordering example is a single query against a live ranking that can change between your reading this and your running it. On timing, graph corrections propagate on the consumer's schedule, not yours; weeks is what we have seen, and anybody quoting you a date is guessing.

FAQ

Do we need a Wikipedia article to be on Wikidata? No. A sitelink is one of three routes to acceptance, not a requirement. An entity with serious independent references can qualify without any Wikipedia presence at all.

Can we just create the item ourselves? You can, and the community permits it if you declare the connection and cite independent sources for every statement. Items created without references get challenged, and a deletion discussion is a worse outcome than no item.

Does schema.org markup feed Wikidata? Not directly. Your markup is read by search systems and crawlers. Wikidata is edited by people and bots that cite sources. Markup makes your version of the facts easy to find and quote, which makes the editing argument easier to win.

Is a Google Knowledge Panel the same thing as the knowledge graph? The panel is one rendering of it. The graph behind it draws on many inputs, including licensed data and Google's own extraction, so a correct Wikidata item improves the odds without controlling the result.

Sources

Related reading

Structured data for AI search: what to mark up firstsameAs and the identity links engines checkWikipedia, and the brand facts engines inheritGovernance: one source of truth for brand factsOrganization schema done properly, with a complete exampleProduct schema for AI shopping answers