The Wikidata Query Service (WDQS) is Wikidata’s public SPARQL endpoint. The editor lives at https://query.wikidata.org/ and the machine endpoint at https://query.wikidata.org/sparql, both free and both needing no account. Every query on this page runs unmodified: paste one into the editor, press the run button, then change a line at a time.
What the service is
WDQS runs on Blazegraph, a triple store that holds the RDF export of every Wikidata item, property, and statement. Queries are ordinary SPARQL with three Wikidata-specific extensions: a set of predeclared prefixes, a label resolution service, and Blazegraph query hints. Those extensions appear in almost every published Wikidata query, so they are worth learning before anything else.
The editor is more than a text box. It autocompletes property and item names, links to a library of community example queries, generates a permanent short link for any query, and renders results as a table, a map, a timeline, a graph, or a bubble chart depending on what the query returns. A code button emits a ready-made Python, JavaScript, or shell call for the current query.
Queries are subject to a hard time limit measured in tens of seconds. A query that exceeds it is canceled outright rather than returning partial results, which is why the shape of a query matters more here than on a private endpoint. The service is also split so the very large scholarly-article portion of Wikidata is served from a separate endpoint; queries about academic papers may need that host instead, and the WDQS documentation lists the current arrangement.
The three things every Wikidata query uses
Predeclared prefixes. WDQS declares the common Wikidata namespaces already, so wd:, wdt:, p:, ps:, pq:, rdfs:, schema:, bd:, wikibase: and hint: all work with no PREFIX line, and redeclaring one is harmless. The label-search query below still declares skos: explicitly, which keeps it portable to a local Wikibase or a dump loaded into another store.
The label service. Labels live in language-tagged literals, and resolving them by hand is verbose. This block makes any variable named ?xLabel resolve to the label of ?x, and ?xDescription to its description:
SERVICE wikibase:label { bd:serviceParam wikibase:language "en,mul". }
Include mul in the language list. Wikidata has been moving labels that are identical across languages, personal names in particular, to the mul (multilingual) code, so more items have no English label at all. A label service call listing only "en" returns blank cells for those items with no error and no warning. Listing "en,mul" falls back correctly.
Query hints. hint:Query hint:optimizer "None" . as the first line of a WHERE block tells Blazegraph to evaluate the patterns in the order written rather than reordering them itself. This is a Blazegraph directive, not part of standard SPARQL; it does nothing on other endpoints, and some will reject it. It is needed when the query starts from a small, cheap set and the optimizer would instead start from a huge one. Two of the queries below time out without it and finish in a second with it.
One modeling rule matters as much as the other two. Filter class membership with ?item wdt:P31/wdt:P279* wd:Qxxxx, not with a bare wdt:P31. Wikidata items are typed with the most specific class available, so the University of Florida (Q501758) is an instance of “land-grant university” and “public research university” rather than of “university” (Q3918). A query asking for direct instances of Q3918 silently omits it and most of its peers. The path expression takes one instance-of step and then any number of subclass-of steps, which catches every item whose class chain reaches the target. This is the single most common cause of a Wikidata query that looks right and quietly returns an incomplete answer.
Finding entities
1. Turn a name into a Q-ID. Matching a literal against rdfs:label and skos:altLabel is the cheapest reconciliation query there is, because the bound literal makes the lookup an index hit rather than a scan. Aliases matter: many organizations are better known by a name that is not their label.
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
SELECT DISTINCT ?item ?itemLabel ?itemDescription WHERE {
VALUES ?name { "University of Florida"@en "UF"@en }
{ ?item rdfs:label ?name } UNION { ?item skos:altLabel ?name }
SERVICE wikibase:label { bd:serviceParam wikibase:language "en,mul". }
}
LIMIT 50
The language tag on the literal is not optional. "University of Florida" without @en matches nothing, because every label in the store carries a tag.
Read the result carefully, because a label match is not a resolution. This query returns thirteen rows: the university (Q501758), a power station in Alachua County that is also labeled “University of Florida”, a Wikidata property whose alias is “UF”, and several unrelated items from the “UF” alias, among them a webcomic and urea-formaldehyde. Matching a string returns every entity that carries that string. Picking the right one is disambiguation, and the description column is usually enough to do it by eye. Adding ?item wdt:P31/wdt:P279* wd:Q3918 . narrows the result to educational institutions when the type is known in advance.
2. Crosswalk between Wikidata and other identifier systems. Identifier properties let Wikidata act as a reconciliation bridge, and they work in both directions. Reading them off known items needs OPTIONAL on every pattern, because no entity carries all of them:
SELECT ?item ?itemLabel ?website ?isni ?viaf ?freebaseId WHERE {
VALUES ?item { wd:Q501758 wd:Q7186 wd:Q243 }
OPTIONAL { ?item wdt:P856 ?website. }
OPTIONAL { ?item wdt:P213 ?isni. }
OPTIONAL { ?item wdt:P214 ?viaf. }
OPTIONAL { ?item wdt:P646 ?freebaseId. }
SERVICE wikibase:label { bd:serviceParam wikibase:language "en,mul". }
}
An OPTIONAL block sharing only the bound subject never removes a row, so absent statements return empty cells. Dropping the OPTIONAL keywords would return nothing at all whenever any single property were missing, which is the most common reason a profile query comes back empty.
Reversed, the same property resolves an identifier value to a Q-ID. P646 is the Freebase ID, the property that maps a Google Knowledge Graph /m/ id onto a Wikidata item:
SELECT ?item ?itemLabel ?itemDescription WHERE {
VALUES ?freebaseId { "/m/045c7b" "/m/02j81" }
?item wdt:P646 ?freebaseId .
SERVICE wikibase:label { bd:serviceParam wikibase:language "en,mul". }
}
Those two values return Google (Q95) and the Eiffel Tower (Q243). Swap wdt:P646 for wdt:P213 (ISNI), wdt:P214 (VIAF ID) or any other identifier property, and the same shape resolves that identifier instead. Identifier values are strings, so they take quotes and no language tag. Freebase coverage is partial, so a value with no match returns no rows, which is expected rather than an error; this mapping is on the API side of the Google Knowledge Graph Search API.
3. Every entity of a type in a place. The workhorse query for entity research: all universities located anywhere inside Florida, with their official websites.
SELECT DISTINCT ?item ?itemLabel ?website WHERE {
hint:Query hint:optimizer "None" .
?place wdt:P131* wd:Q812 .
?item wdt:P131 ?place ;
wdt:P31/wdt:P279* wd:Q3918 .
OPTIONAL { ?item wdt:P856 ?website. }
SERVICE wikibase:label { bd:serviceParam wikibase:language "en,mul". }
}
ORDER BY ?itemLabel
LIMIT 200
Three decisions carry this query. ?place wdt:P131* wd:Q812 It walks the administrative containment chain upward because an institution records its location as a city, not a state. The optimizer hint forces that small set of Florida places to be resolved first; without it, Blazegraph starts from every university on earth and the query times out. And OPTIONAL around the website keeps institutions that have no P856 statement, rather than dropping them from the answer.
4. People by occupation and employer. Two bound objects make this fast with no hint needed, and it is the pattern behind any “who works where” question.
SELECT DISTINCT ?person ?personLabel ?occupationLabel WHERE {
?person wdt:P108 wd:Q501758 ;
wdt:P106 ?occupation .
SERVICE wikibase:label { bd:serviceParam wikibase:language "en,mul". }
}
ORDER BY ?personLabel
LIMIT 200
P108 is employer, and P106 is occupation. A person with three occupations returns three rows, which is what DISTINCT cannot fix, and GROUP_CONCAT can: group by ?person and concatenate ?occupationLabel to get one row each.
Sitelinks
5. Item to Wikipedia article, and back. Sitelinks are not statements. They are separate RDF triples using schema:about and schema:isPartOf, which is why no P-number retrieves them.
SELECT ?item ?itemLabel ?article WHERE {
VALUES ?item { wd:Q501758 wd:Q937 wd:Q243 }
OPTIONAL {
?article schema:about ?item ;
schema:isPartOf <https://en.wikipedia.org/> .
}
SERVICE wikibase:label { bd:serviceParam wikibase:language "en,mul". }
}
Change the schema:isPartOf value to <https://de.wikipedia.org/> for German, or drop that pattern to list every language edition. The same two triples run in reverse turn a known article URL into a Q-ID, which is the fastest way to reconcile a list of Wikipedia links:
SELECT ?item ?itemLabel WHERE {
<https://en.wikipedia.org/wiki/University_of_Florida> schema:about ?item .
SERVICE wikibase:label { bd:serviceParam wikibase:language "en,mul". }
}
Finding what is missing
6. Entities of a type that lack a property. FILTER NOT EXISTS tests that a pattern has no match, and it is the standard way to produce a gap list. Here: universities in Florida with no official website recorded.
SELECT DISTINCT ?item ?itemLabel WHERE {
hint:Query hint:optimizer "None" .
?place wdt:P131* wd:Q812 .
?item wdt:P131 ?place ;
wdt:P31/wdt:P279* wd:Q3918 .
FILTER NOT EXISTS { ?item wdt:P856 ?anyWebsite. }
SERVICE wikibase:label { bd:serviceParam wikibase:language "en,mul". }
}
ORDER BY ?itemLabel
LIMIT 200
FILTER NOT EXISTS is safer than MINUS here. MINUS removes nothing when the inner pattern shares no variable with the outer one, so a small refactoring can turn a working exclusion into a silent no-op.
7. Two gaps at once, with OPTIONAL and !BOUND. When the question is “which of these is incomplete, and how”, left-joining the optional values and filtering on their absence returns the answer and the diagnosis in the same table.
SELECT ?item ?itemLabel ?isni ?article WHERE {
?item wdt:P31/wdt:P279* wd:Q3918 ;
wdt:P17 wd:Q30 .
OPTIONAL { ?item wdt:P213 ?isni. }
OPTIONAL {
?article schema:about ?item ;
schema:isPartOf <https://en.wikipedia.org/> .
}
FILTER (!BOUND(?isni) || !BOUND(?article))
SERVICE wikibase:label { bd:serviceParam wikibase:language "en,mul". }
}
ORDER BY ?itemLabel
LIMIT 200
The FILTER sits after both OPTIONAL blocks on purpose. OPTIONAL blocks are evaluated left to right, and a filter placed before one cannot see the variable it would test.
Statements, qualifiers and structure
8. Reach into a statement for its qualifiers. A truthy property such as wdt:P39 gives the value and throws away the context. Going through the statement node with p: and ps: keeps it, and pq: reads the qualifiers.
SELECT ?positionLabel ?start ?end WHERE {
wd:Q76 p:P39 ?statement .
?statement ps:P39 ?position .
OPTIONAL { ?statement pq:P580 ?start. }
OPTIONAL { ?statement pq:P582 ?end. }
SERVICE wikibase:label { bd:serviceParam wikibase:language "en,mul". }
}
ORDER BY ?start
P39 is the position held, P580 is the start time, and P582 is the end time. Any time-bound fact on Wikidata (an employer, a headquarters, a population, a name) is modeled this way, so this is the pattern to reach for whenever a query needs a date attached to a relationship rather than to an item.
9. What counts as a member of a class. Before filtering on a class, it pays to see what the class actually contains. This walks the subclass tree downward from educational institution.
SELECT ?class ?classLabel WHERE {
?class wdt:P279* wd:Q2385804 .
SERVICE wikibase:label { bd:serviceParam wikibase:language "en,mul". }
}
LIMIT 300
The path is anchored at one end, which is what keeps it cheap. ?class wdt:P279* ?anything with both ends free traverses most of Wikidata’s class hierarchy and will not finish.
10. How completely are these entities described? Statement counts by property, across a fixed set of items. wikibase:claim maps a property entity to its p: predicate, which is how a query can iterate over all of an item’s statements without naming any property.
SELECT ?itemLabel (COUNT(DISTINCT ?property) AS ?propertiesUsed)
(COUNT(?statement) AS ?statements) WHERE {
VALUES ?item { wd:Q95 wd:Q312 wd:Q2283 }
?item ?claim ?statement .
?property wikibase:claim ?claim .
SERVICE wikibase:label { bd:serviceParam wikibase:language "en,mul". }
}
GROUP BY ?itemLabel
ORDER BY DESC(?statements)
VALUES bounds the query to three items (Google, Apple, and Microsoft), which is what makes an otherwise open-ended pattern cheap. Run it over a set of competitors to see which entities have the fuller public record, then use query 2 to see which specific identifiers are absent.
Reconciling a list of entities for SEO
Entity research usually produces a list of names: the people, organizations and places mentioned on a page, or extracted from a competitor’s content with a named entity recognizer (see /concepts/entity-linking-ner-and-extraction/). Reconciliation turns each name into a Wikidata Q-ID, and from the Q-ID into the identifiers an SEO uses in markup and audits. A VALUES block lets one query handle the whole list instead of one lookup per name.
A label match is not a resolution
A label is a string attached to an item, and many items share the same string. Matching “Google” against labels returns every item whose English or multilingual label is exactly “Google”, which can include items that are not the company. A single hit is not proof either, since editors add items constantly. The first query counts candidates per name, which shows how ambiguous each one is before anything is trusted.
SELECT ?name (COUNT(DISTINCT ?item) AS ?candidates)
(GROUP_CONCAT(DISTINCT STRAFTER(STR(?item), "entity/"); separator=" ") AS ?qids)
WHERE {
VALUES ?label {
"University of Florida"@en "University of Florida"@mul
"Google"@en "Google"@mul
"Eiffel Tower"@en "Eiffel Tower"@mul
}
?item rdfs:label ?label .
BIND(STR(?label) AS ?name)
}
GROUP BY ?name
ORDER BY DESC(?candidates)
Each name appears twice, once tagged @en and once @mul, because a language-tagged literal only matches a label in the same language, and Wikidata has been moving names that are identical across languages to the mul code (see the note on labels at /languages/sparql/). Matching both covers either case. The lookup is an exact match on the full label; aliases (skos:altLabel) and spelling variants are not searched.
Narrowing by type
The second query pairs each name with the class the extracted entity is expected to belong to, and keeps only items whose type chain reaches that class. wdt:P31/wdt:P279* follows “instance of” and then any number of “subclass of” steps, so the University of Florida, typed in Wikidata with a narrower class of university, still passes a filter on university (Q3918). The type does most of the disambiguation, though not all of it.
SELECT DISTINCT ?name ?item ?itemLabel ?website ?freebaseId ?enwiki WHERE {
VALUES (?label ?type) {
("University of Florida"@en wd:Q3918)
("University of Florida"@mul wd:Q3918)
("Google"@en wd:Q43229)
("Google"@mul wd:Q43229)
("Eiffel Tower"@en wd:Q12518)
("Eiffel Tower"@mul wd:Q12518)
}
?item rdfs:label ?label .
?item wdt:P31/wdt:P279* ?type .
BIND(STR(?label) AS ?name)
OPTIONAL { ?item wdt:P856 ?website . }
OPTIONAL { ?item wdt:P646 ?freebaseId . }
OPTIONAL { ?enwiki schema:about ?item ;
schema:isPartOf The classes used are university (Q3918), organization (Q43229) and tower (Q12518). Run against the live endpoint, the first query finds two items labelled “University of Florida”, five labelled “Google” and seventeen labelled “Eiffel Tower”. After type narrowing, the University of Florida resolves to Q501758 alone, because the other match is a power station. Google narrows to Q95 and one survivor, Q30688088, a Google division that is also an organization. The Eiffel Tower narrows to Q243 and Q5348880, a replica in an amusement park that is also a tower. Type narrowing removed most of the noise and left exactly the cases a human has to look at. P856 is the official website, P646 the Freebase ID (the /m/ identifiers that Google Knowledge Graph MIDs descend from), and the schema:about pattern returns the English Wikipedia article. All three sit in OPTIONAL blocks so that an item missing one is still returned. An item with two official websites returns two rows.
A broad class such as organization admits more false matches than a narrow one, so the narrowest class that still fits the source text works best. A name that still returns two items after type narrowing needs a second signal, such as country (P17) or location (P131), or a human decision. A name that returns none may be typed differently than expected, or may be absent from Wikidata, which is itself useful: it marks an entity with no public identifier to reference.
For SEOs, the reconciled Q-ID, website and Wikipedia URL form the candidate list for sameAs markup (covered at /seo/sameas-schema/).
Calling the endpoint from code
The endpoint accepts a query parameter over GET or POST and returns the format named in the Accept header. A descriptive User-Agent with a contact address is required; generic agents are blocked.
curl -s -G "https://query.wikidata.org/sparql" \
-H "Accept: application/sparql-results+json" \
-H "User-Agent: kgn-example/1.0 (https://example.org/contact)" \
--data-urlencode 'query=SELECT ?occupationLabel WHERE {
wd:Q937 wdt:P106 ?occupation .
SERVICE wikibase:label { bd:serviceParam wikibase:language "en,mul". }
}'
Available result formats include SPARQL Results JSON and XML, plus CSV and TSV, which makes a query a usable data source for a spreadsheet without any code at all. In Python, SPARQLWrapper handles the transport, and the same agent requirement applies.
For developers
Write the selective pattern first and keep it bound. A pattern with a bound subject or object is an index lookup; a pattern with three variables is a scan. Prefer a direct lookup to a FILTER equality test, since ?x wdt:P17 wd:Q30 reads an index while ?x wdt:P17 ?c . FILTER(?c = wd:Q30) enumerates every item with a country and discards nearly all of them.
Keep LIMIT 10 in place while developing. When a query times out, try the optimizer hint first, then reorder the patterns so the cheapest one comes first. For repeated or heavy aggregation, load an RDF dump locally instead: WDQS is a shared service with a hard timeout, and a job that scans the graph is not what it is for. Federation with SERVICE is permitted only to an allow-list, and DBpedia is on it.
For SEOs
WDQS turns entity research into a query rather than a crawl. Query 3 produces a complete list of the entities of a type in a market, which is a content gap list grounded in an entity graph instead of keyword volume. Query 4 does the same for people, which helps find the researchers, executives, or authors a search engine can already resolve at a given organization. Query 2 returns the identifiers and official website recorded for an entity, which is the candidate list for sameAs markup covered at sameAs schema. Queries 6 and 7 find the gaps, and a missing official website or a missing identifier on an entity a client owns is a concrete, verifiable fix.
Two cautions apply. Wikidata is not the Google Knowledge Graph, so presence, absence, or completeness here is evidence about Wikidata and only indirect evidence about what a search engine holds. And editing an item because a query showed a gap is fine; editing it to add promotional content is not, and the community reverts it. Wikidata sets the rules, and entity SEO sets the wider practice.
Related pages
FAQ
What is the Wikidata Query Service?
It is Wikidata’s public SPARQL endpoint, with a query editor at query.wikidata.org and a machine endpoint at query.wikidata.org/sparql. It runs on Blazegraph over the RDF export of every Wikidata item and statement, needs no account, and returns results as JSON, XML, CSV, or TSV, or as tables, maps, and timelines in the editor.
Why does my Wikidata query return empty labels?
Because the label service was asked for a language the item has no label in. Wikidata has been moving labels that are identical across languages, personal names especially, to the mul code, so an item can have no English label. Use bd:serviceParam wikibase:language “en,mul” so the service falls back instead of returning blanks.
What does hint:Query hint:optimizer “None” do?
It tells Blazegraph to evaluate the patterns in the order they are written instead of choosing its own order. It is a Blazegraph directive, not standard SPARQL. Use it as the first line of the WHERE block when the query starts from a small set that the optimizer would otherwise ignore, which is often the difference between a result and a timeout.
Why does my query time out on the Wikidata Query Service?
The service cancels any query that exceeds its time limit rather than returning partial results. Common causes include an unanchored property path, a pattern with three unbound variables evaluated first, or a class filter over a very large class. Reorder the patterns, bind an end of every path, add the optimizer hint, and move whole-graph work to a local dump.
Sources and further reading
- Wikidata Query Service user manual: https://www.mediawiki.org/wiki/Wikidata_Query_Service/User_Manual
- Wikidata, SPARQL query service example queries: https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/queries/examples
- Wikidata, SPARQL tutorial: https://www.wikidata.org/wiki/Wikidata:SPARQL_tutorial
- W3C, SPARQL 1.1 Query Language: https://www.w3.org/TR/sparql11-query/
- Blazegraph query hints documentation: https://github.com/blazegraph/database/wiki/QueryHints
- Wikidata, data access: https://www.wikidata.org/wiki/Wikidata:Data_access