Wikidata is a free, collaboratively edited knowledge base run by the Wikimedia Foundation, storing facts about millions of things as structured statements that any person or program can read and edit. It launched in 2012 as a central data store for Wikipedia and its sister projects, and it has become the most widely reused open knowledge graph on the web: its data is released under CC0, it is queryable over SPARQL, and its identifiers are the usual link target for sameAs across the linked data cloud.

The data model: items, properties, statements

Wikidata has a small vocabulary of structural parts, and almost everything else follows from them.

An item is a thing. Albert Einstein, the Eiffel Tower, the concept of a university, the colour blue. Each item has an identifier beginning with Q, called a Q-ID: Einstein is Q937, the Eiffel Tower is Q243, human is Q5, university is Q3918. An item also has labels, descriptions and aliases in many languages, and sitelinks to the Wikipedia articles and other Wikimedia pages about it.

A property is a kind of relationship or attribute. Properties have identifiers beginning with P, called P-IDs: P31 is “instance of”, P279 is “subclass of”, P106 is “occupation”, P569 is “date of birth”, P856 is “official website”. Each property has a fixed datatype, which constrains what its values can be: another item, a string, an external identifier, a quantity with a unit, a point in time with a precision, a geographic coordinate, a URL, or monolingual text. A property cannot take an arbitrary value of the wrong shape, which is what keeps the data machine-readable.

A statement is an item, a property and a value: Q937, P106, Q169470 says that Einstein’s occupation was theoretical physicist. Statements are the unit of content on Wikidata, and in RDF terms each one corresponds to a triple with extra structure attached.

Qualifiers, references and ranks

A bare triple cannot express a fact that was true only for a while, or true in a particular role, so every statement can carry qualifiers and references.

Qualifiers add context inside the statement. A person’s employer statement can carry P580 (start time) and P582 (end time); an award statement can carry P585 (point in time) for the year it was given; a population statement carries the date the figure refers to. Qualifiers are what make Wikidata a record of time-bound claims rather than a snapshot.

References say where the claim came from. A reference is itself a set of property-value pairs, most commonly P248 (stated in) pointing to an item for the source, or P854 (reference URL) with P813 (retrieved) for the access date. A statement with no reference is not invalid, but it is the first thing another editor will challenge, and it is what data reusers filter on.

Ranks resolve conflicts. Every statement is preferred, normal or deprecated. When an item has three population figures from three censuses, marking the newest as preferred tells consumers which one to use. Deprecated marks a claim known to be wrong that is kept for the record. The “truthy” view of Wikidata, exposed in RDF as the wdt: prefix, returns preferred statements where any exist and normal ones otherwise, and hides deprecated ones entirely.

This structure is why a Wikidata statement is not simply a triple. In the RDF export, wd:Q937 wdt:P166 wd:Q38104 is the simplified form, while wd:Q937 p:P166 ?statement reaches the statement node where ps: gives the main value, pq: gives the qualifiers and the reference nodes hang off it. The Wikidata Query Service page works through both forms. Wikidata also holds lexemes (identifiers beginning with L) describing words and their senses, on a separate model that rarely matters for entity work.

Notability, in practical terms

Wikidata’s notability policy is looser than Wikipedia’s, and misunderstanding this in either direction causes most rejected contributions. An item is acceptable if it meets any one of three conditions.

1. It has a valid sitelink to a page on Wikipedia, Wikivoyage, Wikisource, Wikiquote, Wikinews, Wikibooks, Wikiversity, Wikispecies or Wikimedia Commons. Anything with a Wikipedia article in any language qualifies automatically.
2. It refers to a clearly identifiable entity that can be described with serious, publicly available references. This is the clause that admits things without Wikipedia articles: a company recorded in a national business register, a scholarly article with a DOI, a listed building, a species, a person covered in published sources. The requirement is verifiability by sources outside the subject’s own control, not fame.
3. It fulfils a structural need, meaning the item is required to make sense of other statements. A minor publisher may exist as an item only so that hundreds of book items can point at it.

What the second clause excludes in practice is self-description. An item whose only possible references are the subject’s own website, press releases and social profiles fails, because nothing independent establishes that the entity is what the item says it is. Items created purely to promote an organization are deleted, and creating one from an account associated with the subject invites scrutiny of everything else that account has edited. There is no requirement that an entity be interesting: much of the database is gene records, astronomical objects, scholarly articles and administrative units, added in bulk because they are identifiable and sourced.

Creating and sourcing an item

The mechanics are short. The judgment is in the sourcing.

1. Search first. Query the item’s likely names and aliases in several languages before creating anything. Duplicate items are the most common error, and merging them afterward is more work than checking.
2. Create the item at Special:NewItem with a label, a description, and any aliases. The description disambiguates rather than praises: “American higher education institution in Gainesville, Florida”, not “leading research university”.
3. Add P31 first. “Instance of” is the statement everything else depends on, because it decides which classes the item belongs to and therefore which queries find it. Choose the most specific accurate class, since class membership is normally read through the subclass chain rather than through P31 alone.
4. Add the core statements for what it is. An organization typically takes P571 (inception), P159 (headquarters location), P17 (country), P452 (industry), P856 (official website), and P749 (parent organization). A person takes P31 Q5, P569, P106, P27 (country of citizenship), and often P108 (employer).
5. Add external identifiers. These make the item useful to other systems: P213 (ISNI), P214 (VIAF ID), and the domain-specific registry identifiers for the field. Each identifier is an independent handle on the same entity, and identifier properties are how Wikidata acts as a reconciliation hub.
6. Reference every claim that is not obvious from a sitelink. Use P854 with P813 for a web source, or P248 for a published work with its own item. A well-referenced item survives; an unreferenced one gets tagged or trimmed.
7. Add sitelinks if Wikipedia articles exist, and check that no other item already carries them.

Bulk work belongs in tools rather than the web form. OpenRefine reconciles a spreadsheet of names against existing items, and QuickStatements applies a plain-text list of statements. An incorrect batch is as easy to run as a correct one.

Three ways to read Wikidata

Which access route to use depends on whether the question is about one entity or about a pattern across many.

The Action API answers questions about specific items. It is the MediaWiki API at https://www.wikidata.org/w/api.php, and two modules cover most needs. wbsearchentities turns a name into candidate Q-IDs:

curl -s -G "https://www.wikidata.org/w/api.php" \
  --data-urlencode "action=wbsearchentities" \
  --data-urlencode "search=Marie Curie" \
  --data-urlencode "language=en" \
  --data-urlencode "type=item" \
  --data-urlencode "limit=5" \
  --data-urlencode "format=json"

wbgetentities fetches the full content of up to fifty items at once, and props trims the response to what is needed:

curl -s -G "https://www.wikidata.org/w/api.php" \
  --data-urlencode "action=wbgetentities" \
  --data-urlencode "ids=Q937|Q243" \
  --data-urlencode "props=labels|descriptions|claims|sitelinks" \
  --data-urlencode "languages=en" \
  --data-urlencode "format=json"

For a single item with no parameters to remember, https://www.wikidata.org/wiki/Special:EntityData/Q937.json returns the same entity document, and swapping the extension for .ttl, .nt or .rdf returns RDF instead. That is the dereferencing route described in linked data, and it is the cheapest way to see exactly how statements, qualifiers, and references are serialized.

The Action API is also the write interface. wbcreateclaim, wbsetreference and the rest require an authenticated session and a CSRF token, and bot-scale editing requires community approval for the account.

The SPARQL endpoint answers questions about sets: every university in a state, every person with a given occupation and employer, every organization missing an official website. It is a different tool from the API, not a faster one, and it is no substitute when the job is fetching one known item.

The dumps answer questions that need the whole graph. Wikimedia publishes full JSON and RDF dumps of all entities at dumps.wikimedia.org, including a truthy N-Triples export that omits statement nodes and is far smaller. A scan of all items, a local index, or repeated heavy aggregation belongs in a local copy of a dump rather than in repeated queries against the public endpoint.

For developers

Send a descriptive User-Agent with a contact URL on every request; the Wikimedia APIs block generic agents. Cache by Q-ID, because items change but their identifiers do not. When parsing entity JSON, read claims defensively: a property may be absent, may have several statements, and may have statements ranked deprecated that should be skipped. Prefer external identifier properties over label matching when joining Wikidata to another dataset, since labels are ambiguous and multilingual while an ISNI is not.

Two modeling habits prevent silent errors. Filter class membership with wdt:P31/wdt:P279* rather than a bare wdt:P31, because items are typed with specific subclasses. And treat a missing statement as unknown rather than false: an absent P856 means nobody has added the website, not that the organization has none. The same items appear in DBpedia with different modeling, which is a useful cross-check.

For SEOs

Wikidata matters to search because Google’s Knowledge Graph reconciles entities against public identifiers, and Wikidata is the largest openly editable set. A correct, well-referenced item gives a search engine a machine-readable description of an entity, external identifiers that corroborate it, and a link to its official website. That is a genuine contribution to the corroboration a search engine looks for, and it is a legitimate target for sameAs markup, covered at sameAs schema.

A Wikidata item does not produce a knowledge panel. Panels are assembled from many sources, and Google decides what to show; no documented mechanism shows that creating an item triggers one, and practitioners who report a correlation are reporting a correlation. An item also does not affect rankings for ordinary queries. Anyone promising a panel in exchange for a Wikidata edit is selling something the platform does not offer.

The productive posture is to treat Wikidata as a public record to keep accurate, not a channel to exploit. Fix a wrong founding date, add the missing official website, add the ISNI, merge a duplicate, and reference unreferenced claims. Do not add a promotional description, do not create an item for an entity with no independent sources, and do not edit an employer’s item from an undisclosed account. A deleted item is worse than no item. Broader context sits at entity SEO and what is an entity?.

Wikidata compared to its neighbors

	Wikidata	DBpedia	Google Knowledge Graph
How data arrives	Edited directly by people and bots	Extracted from Wikipedia articles	Built internally by Google
Identifiers	Q-IDs	Wikipedia-derived URIs	MIDs, kg:/m/...
Editable by the public	Yes	No, edit Wikipedia instead	Suggestions only
Queryable	Public SPARQL endpoint	Public SPARQL endpoint	Lookup API over a subset
Licence	CC0	CC BY-SA	Proprietary

Wikidata replaced Freebase as the open hub after Google closed Freebase and transferred data toward Wikidata, which is why so many Wikidata items still carry a Freebase ID in property P646.

Related pages

• Wikidata Query Service
• DBpedia
• SPARQL
• Google Knowledge Graph
• Linked data
• Knowledge graph examples

FAQ

What is a Wikidata Q-ID?

A Q-ID is the permanent identifier of a Wikidata item, written as Q followed by a number: Q937 is Albert Einstein, Q243 is the Eiffel Tower, Q5 is the class human. Labels change and differ by language, but the Q-ID does not, which is why applications and sameAs links should store the Q-ID rather than the name.

What are Wikidata’s notability requirements?

An item qualifies if it meets any one of three conditions: it has a sitelink to a page on Wikipedia or another Wikimedia project; it describes a clearly identifiable entity that serious, publicly available sources can support; or it is structurally needed to make other statements work. A Wikipedia article isn’t required, but independent sources are.

Does having a Wikidata item help SEO?

An accurate, well-referenced item gives search engines a machine-readable, corroborated description of an entity and a link to its official website, which supports entity reconciliation. It does not create a knowledge panel, and it does not affect ordinary rankings. Treat it as public record-keeping, since the community deletes promotional items.

What is the difference between the Wikidata API and the SPARQL endpoint?

The Action API at www.wikidata.org/w/api.php reads and writes specific items by identifier or name, and is the only route for editing. The SPARQL endpoint at query.wikidata.org answers questions about sets of items matching a pattern, and is read-only. Whole-graph work belongs in the RDF or JSON dumps instead.

Sources and further reading

• Wikidata, introduction: https://www.wikidata.org/wiki/Wikidata:Introduction
• Wikidata, notability policy: https://www.wikidata.org/wiki/Wikidata:Notability
• Wikidata, data model primer: https://www.wikidata.org/wiki/Wikidata:Data_model
• Wikidata, data access (API, dumps, linked data interface): https://www.wikidata.org/wiki/Wikidata:Data_access
• MediaWiki, Wikibase API modules: https://www.wikidata.org/w/api.php
• Wikimedia dumps: https://dumps.wikimedia.org/wikidatawiki/entities/