When to use this skill
When the user asks about entities in Wikidata — finding items by type or class, querying the knowledge graph for structured factual data, or answering "what things are instances of X?" Reach for this when the question involves traversing relationships, filtering by class, or aggregating across entities. For simple key-value lookups ("what is the capital of France?"), a REST country API is faster; this skill is for when you need SPARQL's relational power against 100M+ items.
Your best first call
curl "https://query.wikidata.org/sparql?query=SELECT+%3Fitem+%3FitemLabel+WHERE+%7B+%3Fitem+wdt%3AP31+wd%3AQ146+.+SERVICE+wikibase%3Alabel+%7B+bd%3AserviceParam+wikibase%3Alanguage+%22en%22+%7D+%7D+LIMIT+10"
No auth. No key. The wdt:P31 predicate filters to instances of a specific class — Q146 here is domestic cat, replace it with any class Q-ID. The label service populates ?itemLabel with human-readable names; without it you get bare Q-IDs. Always include LIMIT to bound the response.
Key response fields in results.bindings[]:
item.value — entity URI like http://www.wikidata.org/entity/Q378619item.type — "uri" for entity referencesitemLabel.value — human-readable label like "Douglas Adams"itemLabel.type — "literal" for text values; absent when no English label exists (the service falls back to the Q-ID string)
Fallbacks (when the best call isn't enough)
- Need properties beyond instance-of → Add
?item wdt:P<property-id> ?value triple patterns to the WHERE clause. wdt: gives truthy (best) values; use p: and ps: prefixes for full statements with qualifiers and provenance.
- Query too long for GET URL limits → POST the same query to
https://query.wikidata.org/sparql with Content-Type: application/sparql-query. You lose GET caching but gain freedom from URL-length constraints.
Pitfalls
?itemLabel does NOT auto-populate. Declaring ?XLabel in SELECT is not enough — you must include SERVICE wikibase:label { bd:serviceParam wikibase:language "en". } in the WHERE clause. This catches every new SPARQL user.- Always use
LIMIT. Without it, queries against large classes like Q5 (human) return millions of results or time out after 60 seconds — the public endpoint's hard timeout.
- When no English label exists for an entity, the label service falls back to the bare Q-ID string in
itemLabel.value. Compare the value against the Q-ID pattern to detect missing translations rather than treating the Q-ID as a name.
One-line summary for the user
I can query Wikidata's knowledge graph — 100M+ entities filtered by class and property — via SPARQL in a single unauthenticated GET, but you must include the label service to get readable names instead of bare Q-IDs.
SKILL.md source (frontmatter + body)
---
name: access-structured
description: When the user asks about entities in Wikidata — finding items by type or class, querying structured factual data, or asking "what things are instances of X" — reach for the Wikidata SPARQL API. Single unauthenticated GET, 100M+ entities.
---
## When to use this skill
When the user asks about entities in Wikidata — finding items by type or class, querying the knowledge graph for structured factual data, or answering "what things are instances of X?" Reach for this when the question involves traversing relationships, filtering by class, or aggregating across entities. For simple key-value lookups ("what is the capital of France?"), a REST country API is faster; this skill is for when you need SPARQL's relational power against 100M+ items.
## Your best first call
```bash
curl "https://query.wikidata.org/sparql?query=SELECT+%3Fitem+%3FitemLabel+WHERE+%7B+%3Fitem+wdt%3AP31+wd%3AQ146+.+SERVICE+wikibase%3Alabel+%7B+bd%3AserviceParam+wikibase%3Alanguage+%22en%22+%7D+%7D+LIMIT+10"
```
No auth. No key. The `wdt:P31` predicate filters to instances of a specific class — Q146 here is domestic cat, replace it with any class Q-ID. The label service populates `?itemLabel` with human-readable names; without it you get bare Q-IDs. Always include `LIMIT` to bound the response.
Key response fields in `results.bindings[]`:
- `item.value` — entity URI like `http://www.wikidata.org/entity/Q378619`
- `item.type` — `"uri"` for entity references
- `itemLabel.value` — human-readable label like "Douglas Adams"
- `itemLabel.type` — `"literal"` for text values; absent when no English label exists (the service falls back to the Q-ID string)
## Fallbacks (when the best call isn't enough)
- **Need properties beyond instance-of** → Add `?item wdt:P<property-id> ?value` triple patterns to the WHERE clause. `wdt:` gives truthy (best) values; use `p:` and `ps:` prefixes for full statements with qualifiers and provenance.
- **Query too long for GET URL limits** → POST the same query to `https://query.wikidata.org/sparql` with `Content-Type: application/sparql-query`. You lose GET caching but gain freedom from URL-length constraints.
## Pitfalls
- `?itemLabel` does NOT auto-populate. Declaring `?XLabel` in SELECT is not enough — you must include `SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }` in the WHERE clause. This catches every new SPARQL user.
- Always use `LIMIT`. Without it, queries against large classes like Q5 (human) return millions of results or time out after 60 seconds — the public endpoint's hard timeout.
- When no English label exists for an entity, the label service falls back to the bare Q-ID string in `itemLabel.value`. Compare the value against the Q-ID pattern to detect missing translations rather than treating the Q-ID as a name.
## One-line summary for the user
I can query Wikidata's knowledge graph — 100M+ entities filtered by class and property — via SPARQL in a single unauthenticated GET, but you must include the label service to get readable names instead of bare Q-IDs.