PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX wd: <http://www.wikidata.org/entity/>
SELECT ?occupation ?occupationLabel WHERE {
  wd:Q81960 wdt:P106 ?occupation .
  ?occupation rdfs:label ?occupationLabel .
  FILTER ( LANG( ?occupationLabel ) = "en" )
}

Using entities:
- Robert Burns (wd:Q81960), also known as Bard of Ayrshire, National poet of Scotland, Ploughman Poet, Rabbie Burns, Robbie Burns, etc.: has occupation writer / has occupation songwriter / has occupation poet / has occupation farmer / has occupation musicologist / is instance of human / Scottish poet and lyricist (1759–1796)

Using properties:
- occupation (wd:P106 as wdt), also known as avocation, career, craft, employ, employment, etc.: occupation of a person; see also "field of work" (Property:P101), "position held" (Property:P39) / occupation of a person; see also "field of work" (Property:P101), "position held" (Property:P39) / occupation of a person; see also "field of work" (Property:P101), "position held" (Property:P39)

Got 5 rows and 2 columns:
| occupation                  | occupationLabel        |
| --------------------------- | ---------------------- |
| farmer (wd:Q131512)         | farmer (lang:en)       |
| musicologist (wd:Q14915627) | musicologist (lang:en) |
| writer (wd:Q36180)          | writer (lang:en)       |
| poet (wd:Q49757)            | poet (lang:en)         |
| songwriter (wd:Q753110)     | songwriter (lang:en)   |

Answer: Robert Burns had the following jobs: farmer, musicologist, writer, poet, and songwriter.

Robert Burns had the following jobs: farmer, musicologist, writer, poet, and songwriter.

SPARQL query over wikidata:
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX wd: <http://www.wikidata.org/entity/>
SELECT ?occupation ?occupationLabel WHERE {
  wd:Q81960 wdt:P106 ?occupation .
  ?occupation rdfs:label ?occupationLabel .
  FILTER ( LANG( ?occupationLabel ) = "en" )
}

Using entities:
- Robert Burns (wd:Q81960), also known as Bard of Ayrshire, National poet of Scotland, Ploughman Poet, Rabbie Burns, Robbie Burns, etc.: has occupation writer / has occupation songwriter / has occupation poet / has occupation farmer / has occupation musicologist / is instance of human / Scottish poet and lyricist (1759–1796)

Using properties:
- occupation (wd:P106 as wdt), also known as avocation, career, craft, employ, employment, etc.: occupation of a person; see also "field of work" (Property:P101), "position held" (Property:P39) / occupation of a person; see also "field of work" (Property:P101), "position held" (Property:P39) / occupation of a person; see also "field of work" (Property:P101), "position held" (Property:P39)

Execution result:
Got 5 rows and 2 columns:
| occupation                  | occupationLabel        |
| --------------------------- | ---------------------- |
| farmer (wd:Q131512)         | farmer (lang:en)       |
| musicologist (wd:Q14915627) | musicologist (lang:en) |
| writer (wd:Q36180)          | writer (lang:en)       |
| poet (wd:Q49757)            | poet (lang:en)         |
| songwriter (wd:Q753110)     | songwriter (lang:en)   |

[System]
You are a question answering assistant. Your job is to generate a SPARQL query to answer a given user question.

You should follow a step-by-step approach to generate the SPARQL query:
1. Determine possible entities and properties implied by the user question.
2. Search for the entities and properties in the knowledge graphs. Where applicable, constrain the searches with already identified entities and properties.
3. Gradually build up the SPARQL query using the identified entities and properties. Start with simple queries and add more complexity as needed. Execute intermediate queries to get feedback and to verify your assumptions. You may need to refine or rethink your current plan based on the query results and go back to step 2 if needed, possibly multiple times.
4. Use the answer or cancel function to finalize your answer and stop the generation process.

Available knowledge graphs:
- wikidata at http://localhost:7001 with prefix index for entities and similarity index for properties, and notes:
  - P106 = occupation. Use wdt:P106 to get occupations and fetch English labels with rdfs:label + FILTER(LANG(?label)="en"). When returning human occupations confirm the subject is human (wdt:P31 wd:Q5) to avoid non-human items.
  - Population (P1082) and tabular (P4179): use wdt:P1082 for quick/direct values; for time-series/point-in-time use p:P1082 + ps:P1082 + pq:P585 and ORDER BY pq:P585 DESC. Inspect statement qualifiers (e.g., 'applies to part') and prov:wasDerivedFrom references (pr:P854 etc.) to detect city-proper vs metro/prefecture scopes before using values.
  - Common person properties: P31 (instance of human Q5), P106 (occupation), P569 (date of birth), P19 (place of birth), P27 (country of citizenship), P21 (sex/gender), P166 (award received). Use wdt: for direct values when possible.
  - P17 (country) can be incomplete/misleading for places (historical/overseas tags). To get modern cities in a country combine: instance-of city (P31=Q515) + wdt:P17 OR use wdt:P131* to find an admin parent whose wdt:P17 = the country. Also cross-check coordinates (P625) or admin hierarchy to spot outliers.
  - When filtering by date of birth (P569) use xsd:dateTime comparisons (e.g. >= "1900-01-01T00:00:00Z"^^xsd:dateTime). Be aware many items have year-only or imprecise dates and coverage is biased toward notable/public figures (sportspeople, politicians, artists).
  - To retrieve qualifiers (e.g., award year) use the statement/qualifier pattern: p:Pxxx / ps:Pxxx / pq:P585. Use wdt:Pxxx for normalized/direct values when you don't need qualifiers. Example: p:P166 + pq:P585 gives award year.
  - To get a person's occupations: use wdt:P106 for direct/normalized values and rdfs:label for human-readable names (FILTER(LANG(...))). Example: wd:Q... wdt:P106 ?occ . ?occ rdfs:label ?occLabel . FILTER(LANG(?occLabel)="en").
  - P166 = award received. Use wdt:P166 for normalized/direct values when you only need award items. To get award years or qualifiers use p:P166 / ps:P166 / pq:P585. Many statements lack pq:P585 — use OPTIONAL { ?stmt pq:P585 ?date } and ORDER BY DESC(?date). When listing award winners, filter ?person wdt:P31 wd:Q5 to ensure humans.
  - Population time-series pattern: wd:Q... p:P1082 ?stmt . ?stmt ps:P1082 ?pop . OPTIONAL { ?stmt pq:P585 ?date } . ORDER BY DESC(?date). pq:P585 is the point-in-time qualifier. IMPORTANT: time-series may mix scopes (city proper vs metro) — e.g., Tokyo has a 2016 entry ~38,140,000 likely metro vs smaller city figures. Inspect qualifiers/references for scope before use.
  - Use wdt:P131* to traverse the admin hierarchy and compare wdt:P17 on the place vs an admin parent to detect historical/colonial country assignments. When mismatches appear, inspect the admin parent's instance-of (P31), labels, qualifiers and references to interpret the historical scope.
  - wdt:P106 often yields multiple occupations for a person. Use GROUP_CONCAT(DISTINCT ?occLabel; separator=", ") or return multiple rows. Always fetch labels with rdfs:label + FILTER(LANG(?label)="en") to get readable occupation names.
  - When a search_entity returns multiple hits (person vs sculpture vs memorial), confirm you selected the human/statements by checking wdt:P31 (instance of) and relevant wdt: properties (e.g., wdt:P106). This avoids using a non-human QID by mistake.
  - search_autocomplete can be constrained with a SPARQL pattern containing ?search (e.g., SELECT * WHERE { ?search wdt:P31 wd:Q5 }). Use constraints to focus results (e.g., humans) and avoid ambiguous fallbacks; if it returns no results, fallback to search_entity and verify wdt:P31.
  - Use search_property_of_entity to find relevant properties for an entity (e.g., 'award' -> P166) and search_object_of_property to discover candidate objects (e.g., 'physicist' for P106). This reduces guessing P/Q ids and surfaces qualifiers.
  - Inspect statement references and qualifiers: use prov:wasDerivedFrom on p: statements to find sources, and check qualifiers (e.g., 'applies to part' or other scope qualifiers) to disambiguate city vs metro vs admin area. Reference labels can be empty; inspect reference node properties for URLs or publication dates.

Index types used for entities and properties:
- Prefix index: Retrieves items by overlap between query keywords and item words. The query keywords can match item words exactly or as prefixes.
- Similarity index: Retrieves items by cosine similarity between their embeddings and the query embedding.

General notes across knowledge graphs:
- Use rdfs:label + FILTER(LANG(?label)="en") for labels; avoid SERVICE wikibase:label. Use wdt:Pxxx for normalized/direct values when qualifiers aren't needed. Use p:Pxxx / ps:Pxxx / pq:Pxxx to access statement qualifiers (e.g., award year via pq:P585). When dates matter, prefer xsd:dateTime and watch for year-only precision.
- Practical query patterns: use rdfs:label + FILTER(LANG(...)) for labels. Use wdt:Pxxx for direct/normalized values when qualifiers aren't needed. Use p:Pxxx / ps:Pxxx / pq:Pxxx to access qualifiers (dates via pq:P585). For dates use xsd:dateTime and expect year-only precision. For places: combine P17 with P131 or coordinate (P625) filters to avoid historical/overseas mismatches.
- Use OPTIONAL for pq: qualifiers (e.g., pq:P585), sort by qualifier (ORDER BY pq:P585 DESC) to prefer recent values. Use GROUP_CONCAT to combine multiple labels/values in one row. Watch for typed literals (xsd:dateTime, xsd:decimal) when filtering or sorting.
- Before querying, use search_entity to resolve human-friendly names to wd:Q identifiers and verify instance-of (e.g., check wdt:P31 = wd:Q5 for humans) to avoid ambiguous matches. Prefer the top match but programmatically confirm P31 before using its data.
- Use search_property to confirm property identifiers (e.g., "country" -> P17) before embedding them in queries. This prevents mistakes from assuming an ID and helps pick the best property if multiple choices exist.
- search_autocomplete can fall back to an unconstrained search or error when there are too many candidates. If this happens (e.g., "more than the maximum supported number of subject candidates"), retry with narrower constraints such as instance-of (wdt:P31), additional type filters, or short prefixes to reduce the candidate set; otherwise fallback to search_entity and verify wdt:P31.
- Use list(...) to inspect all triples on an entity for exploration, but expect large results for notable items. Prefer wdt: properties or targeted p:/ps:/pq: patterns in SPARQL when you need normalized values or qualifiers, respectively.
- Before embedding property or item IDs in SPARQL, use search_property, search_property_of_entity, and search_object_of_property to discover the appropriate P/PID or object QIDs. This reduces errors from guessing IDs and surfaces better property alternatives and qualifiers.
- search_constrained and search_autocomplete can return no results for constrained queries or when the index is large. If they fail, fallback to search_entity + verify P31 (or use search_property_of_entity). Constrain with instance-of (wdt:P31) or other properties in the SPARQL to improve matches.
- When selecting awards by year, prefer xsd:dateTime range filters (e.g., >= "2001-01-01T00:00:00Z"^^xsd:dateTime && < "2002-01-01T00:00:00Z"^^xsd:dateTime) instead of YEAR() for portability and precision.
- When selecting award winners via wdt:P166, filter ?person wdt:P31 wd:Q5 to ensure humans — fictional characters or non-humans may have award claims. If you need award years use p:P166 / ps:P166 / pq:P585 and OPTIONAL { ?stmt pq:P585 ?year } to retrieve qualifier years.
- Use wdt:P625 (coordinates) together with wdt:P131* and wdt:P17 checks to validate a place's modern country or to filter by geography. When country labels mismatch historically, inspect admin parents and coordinates to resolve whether the item refers to historical/colonial scope or current boundaries.
- Prefer wdt:Pxxx for normalized/direct values when qualifiers aren't needed. Use p:Pxxx / ps:Pxxx / pq:Pxxx to access qualifiers (e.g., pq:P585 for award year). Always fetch labels with rdfs:label + FILTER(LANG(?label) = "en").
- If search_autocomplete returns too many candidates or errors, retry with constraints (e.g., SELECT * WHERE { ?search wdt:P31 wd:Q5 }) or narrower query text. If still failing, fallback to search_entity and verify wdt:P31 for type checks.
- For award-year queries use p:P166 / ps:P166 / pq:P585 to access award statements and year qualifiers. Filter by xsd:dateTime ranges (e.g., >= "2020-01-01T00:00:00Z"^^xsd:dateTime && < "2021-01-01T00:00:00Z"^^xsd:dateTime) instead of YEAR() for robustness.
- Use search_property_of_entity to surface relevant properties for an entity (e.g., 'birth' -> P569/P19). list(...) can inspect triples but may return large results for notable items—prefer targeted wdt: patterns (wdt:Pxxx) or p:/ps:/pq: patterns when you need qualifiers.

SPARQL prefixes for use in function calls:
- bd: <http://www.bigdata.com/rdf#
- cc: <http://creativecommons.org/ns#
- data: <https://www.wikidata.org/wiki/Special:EntityData/
- dc: <http://purl.org/dc/elements/1.1/
- dct: <http://purl.org/dc/terms/
- foaf: <http://xmlns.com/foaf/0.1/
- geo: <http://www.opengis.net/ont/geosparql#
- geof: <http://www.opengis.net/def/function/geosparql/
- gn: <http://www.geonames.org/ontology#
- hint: <http://www.bigdata.com/queryHints#
- imdb: <https://www.imdb.com/
- math: <http://www.w3.org/2005/xpath-functions/math#
- ontolex: <http://www.w3.org/ns/lemon/ontolex#
- owl: <http://www.w3.org/2002/07/owl#
- p: <http://www.wikidata.org/prop/
- pq: <http://www.wikidata.org/prop/qualifier/
- pqn: <http://www.wikidata.org/prop/qualifier/value-normalized/
- pqv: <http://www.wikidata.org/prop/qualifier/value/
- pr: <http://www.wikidata.org/prop/reference/
- prn: <http://www.wikidata.org/prop/reference/value-normalized/
- prov: <http://www.w3.org/ns/prov#
- prv: <http://www.wikidata.org/prop/reference/value/
- ps: <http://www.wikidata.org/prop/statement/
- psn: <http://www.wikidata.org/prop/statement/value-normalized/
- psv: <http://www.wikidata.org/prop/statement/value/
- qb: <http://purl.org/linked-data/cube#
- qfn: <http://qlever.cs.uni-freiburg.de/function#
- ql: <http://qlever.cs.uni-freiburg.de/builtin-functions/
- qlss: <https://qlever.cs.uni-freiburg.de/spatialSearch/
- rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#
- rdfs: <http://www.w3.org/2000/01/rdf-schema#
- ref: <http://www.wikidata.org/reference/
- s: <http://www.wikidata.org/entity/statement/
- schema: <http://schema.org/
- skos: <http://www.w3.org/2004/02/skos/core#
- v: <http://www.wikidata.org/value/
- void: <http://rdfs.org/ns/void#
- wd: <http://www.wikidata.org/entity/
- wdno: <http://www.wikidata.org/prop/novalue/
- wdt: <http://www.wikidata.org/prop/direct/
- wdtn: <http://www.wikidata.org/prop/direct-normalized/
- wikibase: <http://wikiba.se/ontology#
- xsd: <http://www.w3.org/2001/XMLSchema#

Additional rules to follow:
- Explain your thought process before and after each step and function call.
- Do not just use or make up entity or property identifiers without verifying their existence in the knowledge graphs first.
- Do not ask the user for clarifications without first attempting to complete the task. If the task input is incomplete or ambiguous, try to make reasonable assumptions and document them.
- Do not use "SERVICE wikibase:label { bd:serviceParam wikibase:language ..." in SPARQL queries. It is not SPARQL standard and unsupported by the used QLever SPARQL endpoints. Use rdfs:label or similar properties to get labels instead.
- Always execute your final SPARQL query before giving an answer to make sure it returns the expected results.
- The SPARQL query should always return the actual identifiers / IRIs of the items in its result. It additionally may return labels or other human-readable information, but they are optional and should be put within optional clauses unless explicitly requested by the user.
- Do not stop early if there are still obvious improvements to be made to the SPARQL query. For example, keep refining your SPARQL query if its result contains irrelevant items or is missing items you expected.
- Do not perform additional computation (e.g. filtering, sorting, calculations) on the result of the SPARQL query to determine the answer. All computation should be done solely within SPARQL.
- For questions with a "True" or "False" answer the SPARQL query should be an ASK query.

[User] what jobs did robert burns have?

[Assistant]
To determine the jobs (occupations) of Robert Burns, I will follow these steps:

1. **Identify Robert Burns in Wikidata**: Use `search_entity` to find the Wikidata item for Robert Burns.
2. **Verify that it is a human**: Check that the item has `wdt:P31 wd:Q5` (instance of human).
3. **Find his occupations**: Use `wdt:P106` to get the occupations and retrieve their English labels using `rdfs:label`.
4. **Construct and execute the SPARQL query**: Combine the above into a SPARQL query to fetch the occupations with readable labels.

Let me begin by searching for Robert Burns.

Question: robert burns

Top 10 entity alternatives:
1. Robert Burns (wd:Q81960), also known as Bard of Ayrshire, National poet of Scotland, Ploughman Poet, Rabbie Burns, Robbie Burns, etc.: Scottish poet and lyricist (1759–1796) / has occupation musicologist / has occupation songwriter / has occupation farmer / has occupation writer / is instance of human / has occupation poet
2. Robert Hunter (wd:Q1375663, matched via Robert Burns), also known as Robert Burns, Robert C. Christie Hunter: American lyricist, musician, singer-songwriter, translator, and poet / has occupation translator / has occupation songwriter / has occupation Guitarist / has occupation guitarist / has occupation lyricist / has occupation Lyricist / has occupation musician / has occupation writer / has occupation singer / is instance of human / has occupation poet
3. Bob Burns (wd:Q887831, matched via Robert Burns), also known as Robbie Burn, Robert Burns, Robin Burn, Robin William Burn: American musical comedian (1890–1956) / has occupation radio personality / has occupation businessperson / has occupation film actor / has occupation comedian / has occupation musician / is instance of human
4. Robert Burns (wd:Q7342516), also known as Robert Clayton Burns: has occupation visual artist / has occupation art educator / British artist (1869-1941) / has occupation designer / has occupation painter / is instance of human / British artist / British artist
5. Robert Burns (wd:Q2156654): American politician (1792-1866) / has occupation politician / is instance of human
6. Robert Burns (wd:Q27824730): has occupation sport cyclist / is instance of human / Australian cyclist / Australian cyclist / Australian cyclist
7. Robert Burns (wd:Q15997904), also known as William Robert Burns: American attorney and politician in Oklahoma (1874-1950) / has occupation politician / has occupation lawyer / is instance of human
8. Robert Burns (wd:Q3434685): Canadian politician (1936–2014) / has occupation trade unionist / has occupation politician / has occupation lawyer / has occupation judge / is instance of human / Canadian politician / Canadian politician
9. Robert H. Burns (wd:Q16066723, matched via Robert Burns), also known as Robert Burns: American politician in Wisconsin (1870-19__) / has occupation politician / is instance of human
10. Bob Burns III (wd:Q4931984, matched via Robert Burns), also known as Bob Burns, Kogar, Robert Burns: American film historian and actor / has occupation property designer / has occupation film historian / has occupation film actor / is instance of human

[Assistant]
The top result for "Robert Burns" is **Q81960**, identified as the Scottish poet and lyricist (1759–1796), also known as the "Bard of Ayrshire" and "National poet of Scotland". This is the most historically significant and likely the intended Robert Burns.

Let me verify that this is a human by checking its `wdt:P31` (instance of) value.

list

wd:Q81960

[Assistant]
Great! The item `wd:Q81960` is indeed a human (`wd:Q5`), so we can proceed with confidence.

Now, I will retrieve Robert Burns's occupations using `wdt:P106` and fetch their English labels using `rdfs:label`.

I'll construct and execute a SPARQL query to get the occupations with readable labels.

execute

SELECT ?occupation ?occupationLabel WHERE { wd:Q81960 wdt:P106 ?occupation . ?occupation rdfs:label ?occupationLabel . FILTER(LANG(?occupationLabel) = "en") }

Got 5 rows and 2 columns:
| occupation                  | occupationLabel        |
| --------------------------- | ---------------------- |
| farmer (wd:Q131512)         | farmer (lang:en)       |
| musicologist (wd:Q14915627) | musicologist (lang:en) |
| writer (wd:Q36180)          | writer (lang:en)       |
| poet (wd:Q49757)            | poet (lang:en)         |
| songwriter (wd:Q753110)     | songwriter (lang:en)   |

[Assistant]
The SPARQL query successfully retrieved Robert Burns's occupations. He had the following jobs:

- farmer
- musicologist
- writer
- poet
- songwriter

These are all confirmed with English labels and are directly linked to `wd:Q81960` (Robert Burns).

I now have the complete answer and will provide the final SPARQL query and response.

I will now call `answer` to finalize.

answer

SELECT ?occupation ?occupationLabel WHERE { wd:Q81960 wdt:P106 ?occupation . ?occupation rdfs:label ?occupationLabel . FILTER(LANG(?occupationLabel) = "en") }

Answer: Robert Burns had the following jobs: farmer, musicologist, writer, poet, and songwriter.


PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX wd: <http://www.wikidata.org/entity/>
SELECT ?zipCode WHERE {
  wd:Q5083 wdt:P281 ?zipCode
}

Using entities:
- Seattle (wd:Q5083), also known as Duwamps, Emerald City, New York Alki, Seattle, WA, Seattle, Washington: is instance of city in the United States / is instance of city of the United States / is instance of big city / is instance of county seat / city in and county seat of King County, State of Washington, United States

Using properties:
- postal code (wd:P281 as wdt), also known as pincode, PIN Code, postal index number, post code, postcode, etc.: identifier assigned by postal authorities for the subject area / identifier assigned by postal authorities for the subject area / identifier assigned by postal authorities for the subject area or building

Got 1 row and 1 column:
| zipCode |
| ------- |
| 98101   |

Answer: The ZIP code for Seattle, Washington is 98101.

The ZIP code for Seattle, Washington is 98101.

SPARQL query over wikidata:
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX wd: <http://www.wikidata.org/entity/>
SELECT ?zipCode WHERE {
  wd:Q5083 wdt:P281 ?zipCode
}

Using entities:
- Seattle (wd:Q5083), also known as Duwamps, Emerald City, New York Alki, Seattle, WA, Seattle, Washington: is instance of city in the United States / is instance of city of the United States / is instance of big city / is instance of county seat / city in and county seat of King County, State of Washington, United States

Using properties:
- postal code (wd:P281 as wdt), also known as pincode, PIN Code, postal index number, post code, postcode, etc.: identifier assigned by postal authorities for the subject area / identifier assigned by postal authorities for the subject area / identifier assigned by postal authorities for the subject area or building

Execution result:
Got 1 row and 1 column:
| zipCode |
| ------- |
| 98101   |

[System]
You are a question answering assistant. Your job is to generate a SPARQL query to answer a given user question.

You should follow a step-by-step approach to generate the SPARQL query:
1. Determine possible entities and properties implied by the user question.
2. Search for the entities and properties in the knowledge graphs. Where applicable, constrain the searches with already identified entities and properties.
3. Gradually build up the SPARQL query using the identified entities and properties. Start with simple queries and add more complexity as needed. Execute intermediate queries to get feedback and to verify your assumptions. You may need to refine or rethink your current plan based on the query results and go back to step 2 if needed, possibly multiple times.
4. Use the answer or cancel function to finalize your answer and stop the generation process.

Available knowledge graphs:
- wikidata at http://localhost:7001 with prefix index for entities and similarity index for properties, and notes:
  - P106 = occupation. Use wdt:P106 to get occupations and fetch English labels with rdfs:label + FILTER(LANG(?label)="en"). When returning human occupations confirm the subject is human (wdt:P31 wd:Q5) to avoid non-human items.
  - Population (P1082) and tabular (P4179): use wdt:P1082 for quick/direct values; for time-series/point-in-time use p:P1082 + ps:P1082 + pq:P585 and ORDER BY pq:P585 DESC. Inspect statement qualifiers (e.g., 'applies to part') and prov:wasDerivedFrom references (pr:P854 etc.) to detect city-proper vs metro/prefecture scopes before using values.
  - Common person properties: P31 (instance of human Q5), P106 (occupation), P569 (date of birth), P19 (place of birth), P27 (country of citizenship), P21 (sex/gender), P166 (award received). Use wdt: for direct values when possible.
  - P17 (country) can be incomplete/misleading for places (historical/overseas tags). To get modern cities in a country combine: instance-of city (P31=Q515) + wdt:P17 OR use wdt:P131* to find an admin parent whose wdt:P17 = the country. Also cross-check coordinates (P625) or admin hierarchy to spot outliers.
  - When filtering by date of birth (P569) use xsd:dateTime comparisons (e.g. >= "1900-01-01T00:00:00Z"^^xsd:dateTime). Be aware many items have year-only or imprecise dates and coverage is biased toward notable/public figures (sportspeople, politicians, artists).
  - To retrieve qualifiers (e.g., award year) use the statement/qualifier pattern: p:Pxxx / ps:Pxxx / pq:P585. Use wdt:Pxxx for normalized/direct values when you don't need qualifiers. Example: p:P166 + pq:P585 gives award year.
  - To get a person's occupations: use wdt:P106 for direct/normalized values and rdfs:label for human-readable names (FILTER(LANG(...))). Example: wd:Q... wdt:P106 ?occ . ?occ rdfs:label ?occLabel . FILTER(LANG(?occLabel)="en").
  - P166 = award received. Use wdt:P166 for normalized/direct values when you only need award items. To get award years or qualifiers use p:P166 / ps:P166 / pq:P585. Many statements lack pq:P585 — use OPTIONAL { ?stmt pq:P585 ?date } and ORDER BY DESC(?date). When listing award winners, filter ?person wdt:P31 wd:Q5 to ensure humans.
  - Population time-series pattern: wd:Q... p:P1082 ?stmt . ?stmt ps:P1082 ?pop . OPTIONAL { ?stmt pq:P585 ?date } . ORDER BY DESC(?date). pq:P585 is the point-in-time qualifier. IMPORTANT: time-series may mix scopes (city proper vs metro) — e.g., Tokyo has a 2016 entry ~38,140,000 likely metro vs smaller city figures. Inspect qualifiers/references for scope before use.
  - Use wdt:P131* to traverse the admin hierarchy and compare wdt:P17 on the place vs an admin parent to detect historical/colonial country assignments. When mismatches appear, inspect the admin parent's instance-of (P31), labels, qualifiers and references to interpret the historical scope.
  - wdt:P106 often yields multiple occupations for a person. Use GROUP_CONCAT(DISTINCT ?occLabel; separator=", ") or return multiple rows. Always fetch labels with rdfs:label + FILTER(LANG(?label)="en") to get readable occupation names.
  - When a search_entity returns multiple hits (person vs sculpture vs memorial), confirm you selected the human/statements by checking wdt:P31 (instance of) and relevant wdt: properties (e.g., wdt:P106). This avoids using a non-human QID by mistake.
  - search_autocomplete can be constrained with a SPARQL pattern containing ?search (e.g., SELECT * WHERE { ?search wdt:P31 wd:Q5 }). Use constraints to focus results (e.g., humans) and avoid ambiguous fallbacks; if it returns no results, fallback to search_entity and verify wdt:P31.
  - Use search_property_of_entity to find relevant properties for an entity (e.g., 'award' -> P166) and search_object_of_property to discover candidate objects (e.g., 'physicist' for P106). This reduces guessing P/Q ids and surfaces qualifiers.
  - Inspect statement references and qualifiers: use prov:wasDerivedFrom on p: statements to find sources, and check qualifiers (e.g., 'applies to part' or other scope qualifiers) to disambiguate city vs metro vs admin area. Reference labels can be empty; inspect reference node properties for URLs or publication dates.

Index types used for entities and properties:
- Prefix index: Retrieves items by overlap between query keywords and item words. The query keywords can match item words exactly or as prefixes.
- Similarity index: Retrieves items by cosine similarity between their embeddings and the query embedding.

General notes across knowledge graphs:
- Use rdfs:label + FILTER(LANG(?label)="en") for labels; avoid SERVICE wikibase:label. Use wdt:Pxxx for normalized/direct values when qualifiers aren't needed. Use p:Pxxx / ps:Pxxx / pq:Pxxx to access statement qualifiers (e.g., award year via pq:P585). When dates matter, prefer xsd:dateTime and watch for year-only precision.
- Practical query patterns: use rdfs:label + FILTER(LANG(...)) for labels. Use wdt:Pxxx for direct/normalized values when qualifiers aren't needed. Use p:Pxxx / ps:Pxxx / pq:Pxxx to access qualifiers (dates via pq:P585). For dates use xsd:dateTime and expect year-only precision. For places: combine P17 with P131 or coordinate (P625) filters to avoid historical/overseas mismatches.
- Use OPTIONAL for pq: qualifiers (e.g., pq:P585), sort by qualifier (ORDER BY pq:P585 DESC) to prefer recent values. Use GROUP_CONCAT to combine multiple labels/values in one row. Watch for typed literals (xsd:dateTime, xsd:decimal) when filtering or sorting.
- Before querying, use search_entity to resolve human-friendly names to wd:Q identifiers and verify instance-of (e.g., check wdt:P31 = wd:Q5 for humans) to avoid ambiguous matches. Prefer the top match but programmatically confirm P31 before using its data.
- Use search_property to confirm property identifiers (e.g., "country" -> P17) before embedding them in queries. This prevents mistakes from assuming an ID and helps pick the best property if multiple choices exist.
- search_autocomplete can fall back to an unconstrained search or error when there are too many candidates. If this happens (e.g., "more than the maximum supported number of subject candidates"), retry with narrower constraints such as instance-of (wdt:P31), additional type filters, or short prefixes to reduce the candidate set; otherwise fallback to search_entity and verify wdt:P31.
- Use list(...) to inspect all triples on an entity for exploration, but expect large results for notable items. Prefer wdt: properties or targeted p:/ps:/pq: patterns in SPARQL when you need normalized values or qualifiers, respectively.
- Before embedding property or item IDs in SPARQL, use search_property, search_property_of_entity, and search_object_of_property to discover the appropriate P/PID or object QIDs. This reduces errors from guessing IDs and surfaces better property alternatives and qualifiers.
- search_constrained and search_autocomplete can return no results for constrained queries or when the index is large. If they fail, fallback to search_entity + verify P31 (or use search_property_of_entity). Constrain with instance-of (wdt:P31) or other properties in the SPARQL to improve matches.
- When selecting awards by year, prefer xsd:dateTime range filters (e.g., >= "2001-01-01T00:00:00Z"^^xsd:dateTime && < "2002-01-01T00:00:00Z"^^xsd:dateTime) instead of YEAR() for portability and precision.
- When selecting award winners via wdt:P166, filter ?person wdt:P31 wd:Q5 to ensure humans — fictional characters or non-humans may have award claims. If you need award years use p:P166 / ps:P166 / pq:P585 and OPTIONAL { ?stmt pq:P585 ?year } to retrieve qualifier years.
- Use wdt:P625 (coordinates) together with wdt:P131* and wdt:P17 checks to validate a place's modern country or to filter by geography. When country labels mismatch historically, inspect admin parents and coordinates to resolve whether the item refers to historical/colonial scope or current boundaries.
- Prefer wdt:Pxxx for normalized/direct values when qualifiers aren't needed. Use p:Pxxx / ps:Pxxx / pq:Pxxx to access qualifiers (e.g., pq:P585 for award year). Always fetch labels with rdfs:label + FILTER(LANG(?label) = "en").
- If search_autocomplete returns too many candidates or errors, retry with constraints (e.g., SELECT * WHERE { ?search wdt:P31 wd:Q5 }) or narrower query text. If still failing, fallback to search_entity and verify wdt:P31 for type checks.
- For award-year queries use p:P166 / ps:P166 / pq:P585 to access award statements and year qualifiers. Filter by xsd:dateTime ranges (e.g., >= "2020-01-01T00:00:00Z"^^xsd:dateTime && < "2021-01-01T00:00:00Z"^^xsd:dateTime) instead of YEAR() for robustness.
- Use search_property_of_entity to surface relevant properties for an entity (e.g., 'birth' -> P569/P19). list(...) can inspect triples but may return large results for notable items—prefer targeted wdt: patterns (wdt:Pxxx) or p:/ps:/pq: patterns when you need qualifiers.

SPARQL prefixes for use in function calls:
- bd: <http://www.bigdata.com/rdf#
- cc: <http://creativecommons.org/ns#
- data: <https://www.wikidata.org/wiki/Special:EntityData/
- dc: <http://purl.org/dc/elements/1.1/
- dct: <http://purl.org/dc/terms/
- foaf: <http://xmlns.com/foaf/0.1/
- geo: <http://www.opengis.net/ont/geosparql#
- geof: <http://www.opengis.net/def/function/geosparql/
- gn: <http://www.geonames.org/ontology#
- hint: <http://www.bigdata.com/queryHints#
- imdb: <https://www.imdb.com/
- math: <http://www.w3.org/2005/xpath-functions/math#
- ontolex: <http://www.w3.org/ns/lemon/ontolex#
- owl: <http://www.w3.org/2002/07/owl#
- p: <http://www.wikidata.org/prop/
- pq: <http://www.wikidata.org/prop/qualifier/
- pqn: <http://www.wikidata.org/prop/qualifier/value-normalized/
- pqv: <http://www.wikidata.org/prop/qualifier/value/
- pr: <http://www.wikidata.org/prop/reference/
- prn: <http://www.wikidata.org/prop/reference/value-normalized/
- prov: <http://www.w3.org/ns/prov#
- prv: <http://www.wikidata.org/prop/reference/value/
- ps: <http://www.wikidata.org/prop/statement/
- psn: <http://www.wikidata.org/prop/statement/value-normalized/
- psv: <http://www.wikidata.org/prop/statement/value/
- qb: <http://purl.org/linked-data/cube#
- qfn: <http://qlever.cs.uni-freiburg.de/function#
- ql: <http://qlever.cs.uni-freiburg.de/builtin-functions/
- qlss: <https://qlever.cs.uni-freiburg.de/spatialSearch/
- rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#
- rdfs: <http://www.w3.org/2000/01/rdf-schema#
- ref: <http://www.wikidata.org/reference/
- s: <http://www.wikidata.org/entity/statement/
- schema: <http://schema.org/
- skos: <http://www.w3.org/2004/02/skos/core#
- v: <http://www.wikidata.org/value/
- void: <http://rdfs.org/ns/void#
- wd: <http://www.wikidata.org/entity/
- wdno: <http://www.wikidata.org/prop/novalue/
- wdt: <http://www.wikidata.org/prop/direct/
- wdtn: <http://www.wikidata.org/prop/direct-normalized/
- wikibase: <http://wikiba.se/ontology#
- xsd: <http://www.w3.org/2001/XMLSchema#

Additional rules to follow:
- Explain your thought process before and after each step and function call.
- Do not just use or make up entity or property identifiers without verifying their existence in the knowledge graphs first.
- Do not ask the user for clarifications without first attempting to complete the task. If the task input is incomplete or ambiguous, try to make reasonable assumptions and document them.
- Do not use "SERVICE wikibase:label { bd:serviceParam wikibase:language ..." in SPARQL queries. It is not SPARQL standard and unsupported by the used QLever SPARQL endpoints. Use rdfs:label or similar properties to get labels instead.
- Always execute your final SPARQL query before giving an answer to make sure it returns the expected results.
- The SPARQL query should always return the actual identifiers / IRIs of the items in its result. It additionally may return labels or other human-readable information, but they are optional and should be put within optional clauses unless explicitly requested by the user.
- Do not stop early if there are still obvious improvements to be made to the SPARQL query. For example, keep refining your SPARQL query if its result contains irrelevant items or is missing items you expected.
- Do not perform additional computation (e.g. filtering, sorting, calculations) on the result of the SPARQL query to determine the answer. All computation should be done solely within SPARQL.
- For questions with a "True" or "False" answer the SPARQL query should be an ASK query.

[User] what the zip code for seattle washington?

[Assistant]
To find the ZIP code for Seattle, Washington, I need to determine the appropriate property in Wikidata that represents ZIP codes.

First, I will search for properties related to ZIP codes or postal codes in Wikidata.

Question: ZIP code

Top 10 property alternatives:
1. postal code (wd:P281 as ps/psv/p/pqv/pqn/psn/pq/wdt/pr/prn/prv/wdtn, matched via zip code), also known as pincode, PIN Code, postal index number, post code, postcode, etc.: identifier assigned by postal authorities for the subject area or building / identifier assigned by postal authorities for the subject area / identifier assigned by postal authorities for the subject area
2. official number of town quarter (wd:P5901 as ps/psv/p/pqv/pqn/psn/pq/wdt/pr/prn/prv/wdtn, matched via district number), also known as Chak number, district number, region number, village number, P5901: official number for the administrative division or section, region or part of a town
3. electoral district number (wd:P4565 as ps/psv/p/pqv/pqn/psn/pq/wdt/pr/prn/prv/wdtn, matched via district number), also known as district number, P4565: number of the constituency/electoral district established by ... lack legal force, even if contained in a government database.
4. local dialing code (wd:P473 as ps/psv/p/pqv/pqn/psn/pq/wdt/pr/prn/prv/wdtn, matched via area code), also known as area code, dialling code, local calling code, local dialling code, STD code, etc.: identifier dedicated to subject city by the area communication network / code to identify a local area in a telephone network
5. urban area census code (wd:P12704 as ps/psv/p/pqv/pqn/psn/pq/wdt/pr/prn/prv/wdtn), also known as UACE, P12704: unique identifier assigned by the United States Census Bureau to an urban area
6. street key (wd:P1945 as ps/psv/p/pqv/pqn/psn/pq/wdt/pr/prn/prv/wdtn, matched via street ID), also known as street ID, P1945: identification number for a specific street within the street cadastre of a municipality
7. locality number in Austria (wd:P8384 as ps/psv/p/pqv/pqn/psn/pq/wdt/pr/prn/prv/wdtn, matched via Ortschaftskennziffer), also known as Ortschaftskennziffer, Ortschaftskennziffer (Austria), P8384: identifier for a locality in Austria (Ortschaftskennziffer); format: 5 digits, generally starting with 0 or 1
8. street address (wd:P6375 as ps/psv/p/pqv/pqn/psn/pq/wdt/pr/prn/prv/wdtn, matched via postal address), also known as address, full address, located at street address, mail address, mailing address, etc.: full street address where subject is located. Include ... use also P669 if the street has its own separate item / full street address that the subject is located at. Include ... use also P669 if the street is known as a separate element / full street address that the subject is located at. Include ... use also P669 if the street is known as a separate element
9. Austrian Street ID (wd:P10198 as ps/psv/p/pqv/pqn/psn/pq/wdt/pr/prn/prv/wdtn, matched via Straßenkennziffer), also known as Straßenkennziffer, street identifier (Austria), street number in Austria, P10198: six-digit identifier for named and inhabited streets within ... May apply to settlements without named streets / is subproperty of street key
10. station code (wd:P296 as ps/psv/p/pqv/pqn/psn/pq/wdt/pr/prn/prv/wdtn), also known as station identifier, station number, station numbering, telegraph code, P296: generic identifier for a railway station, when possible, use ... coding system (e.g. P1378 for China Railway TMIS codes) / generic identifier for a railway station, when possible, use ... coding system (e.g. P1378 for China Railway TMIS codes) / generic identifier for a railway station, when possible, use ... coding system (e.g. P1378 for China Railway TMIS codes) / is subproperty of location code

[Assistant]
The property for postal code in Wikidata is `wdt:P281`. Now, I need to find the entity for Seattle, Washington. I'll search for Seattle in Wikidata.

Question: Seattle Washington

Top 10 entity alternatives:
1. Seattle (wd:Q5083, matched via Seattle, Washington), also known as Duwamps, Emerald City, New York Alki, Seattle, WA, Seattle, Washington: city in and county seat of King County, State of Washington, United States / is instance of city in the United States / is instance of city of the United States / is instance of county seat / is instance of big city
2. Seattle Washington Temple (wd:Q3844785): temple of the Church of Jesus Christ of Latter-day Saints in Bellevue, Washington / is instance of Temple / is instance of temple
3. Washington Park (wd:Q7972093, matched via Washington Park, Seattle), also known as Washington Park, Seattle: is instance of neighbourhood / is instance of neighborhood
4. Seattle Heights (wd:Q122543838, matched via Seattle Heights, Washington), also known as Seattle Heights, WA, Seattle Heights, Washington: neighborhood in Snohomish County, Washington, United States / is instance of human settlement / is instance of neighbourhood / is instance of neighborhood
5. Seattle Hill (wd:Q122540504, matched via Seattle Hill, Washington), also known as Seattle Hill, WA, Seattle Hill, Washington: populated place in Snohomish County, Washington, United States / is instance of human settlement
6. East Seattle (wd:Q122593560, matched via East Seattle, Washington), also known as East Seattle, WA, East Seattle, Washington: populated place in King County, Washington, United States / is instance of human settlement
7. Seattle, Washington Auditions (wd:Q114507485): is instance of television series episode / episode of American Idol (S6 E2)
8. "Carole, Seattle, Washington" (wd:Q64144357): photograph in the National Gallery of Art (NGA 135163) / is instance of photograph
9. Seattleites (wd:Q55779668, matched via Seattle, Washington, residents), also known as Seattlers, Seattle, Washington, residents, Seattlites: people from or residents of Seattle, Washington / is instance of human population / is subclass of Washingtonians / is instance of Population / is instance of population / is subclass of inhabitant
10. University of Washington (wd:Q219563, matched via University of Washington Seattle), also known as U-Dub, UDub, University of Washington Seattle, Univ. of Washington, U of W, etc.: public research university in Seattle, Washington, United States / is instance of public university

[Assistant]
The correct entity for Seattle, Washington is `wd:Q5083`. Now, I will query for the postal code (ZIP code) of Seattle using the property `wdt:P281`.

execute

SELECT ?zipCode WHERE { wd:Q5083 wdt:P281 ?zipCode }

Got 1 row and 1 column:
| zipCode |
| ------- |
| 98101   |

[Assistant]
The ZIP code for Seattle, Washington is 98101. This is the primary ZIP code associated with the city in Wikidata.

I will now provide the final answer.

answer

SELECT ?zipCode WHERE { wd:Q5083 wdt:P281 ?zipCode }

Answer: The ZIP code for Seattle, Washington is 98101.


PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX ps: <http://www.wikidata.org/prop/statement/>
PREFIX p: <http://www.wikidata.org/prop/>
PREFIX pq: <http://www.wikidata.org/prop/qualifier/>
PREFIX wd: <http://www.wikidata.org/entity/>
SELECT ?partner ?partnerLabel WHERE {
  wd:Q575689 p:P451 ?stmt .
  ?stmt ps:P451 ?partner .
  OPTIONAL {
    ?stmt pq:P580 ?startDate
  }
  .
  ?partner rdfs:label ?partnerLabel .
  FILTER ( LANG( ?partnerLabel ) = "en" )
}
ORDER BY DESC ( ?startDate )
LIMIT 1

Using entities:
- Kourtney Kardashian (wd:Q575689), also known as Kourtney, Kourtney Kardashian Barker, Kourtney Mary Kardashian: has occupation actor / has occupation socialite / has occupation Model / has occupation model / has occupation businessperson / has occupation fashion designer / has occupation television actor / has occupation celebrity / has occupation media personality / has occupation Entrepreneur / has occupation entrepreneur / is instance of human / American media personality, model and businesswoman (born 1979)

Using properties:
- unmarried partner (wd:P451 as p/ps), also known as boyfriend, cohabitant, domestic partner, enbyfriend, girlfriend, etc.: is subproperty of significant person / someone with whom the person is in a relationship without being married. Use "spouse" (P26) for married couples / someone with whom the person is in a relationship without being married. Use "spouse" (P26) for married couples
- start time (wd:P580 as pq), also known as began, beginning, building date, effective, effectivity, etc.: is subproperty of point in time / indicates the time an item begins to exist or a statement starts being valid / indicates the time an item begins to exist or a statement starts being valid / time an entity begins to exist or a statement starts being valid

Answer: Travis Barker

Travis Barker

SPARQL query over wikidata:
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX ps: <http://www.wikidata.org/prop/statement/>
PREFIX p: <http://www.wikidata.org/prop/>
PREFIX pq: <http://www.wikidata.org/prop/qualifier/>
PREFIX wd: <http://www.wikidata.org/entity/>
SELECT ?partner ?partnerLabel WHERE {
  wd:Q575689 p:P451 ?stmt .
  ?stmt ps:P451 ?partner .
  OPTIONAL {
    ?stmt pq:P580 ?startDate
  }
  .
  ?partner rdfs:label ?partnerLabel .
  FILTER ( LANG( ?partnerLabel ) = "en" )
}
ORDER BY DESC ( ?startDate )
LIMIT 1

Using entities:
- Kourtney Kardashian (wd:Q575689), also known as Kourtney, Kourtney Kardashian Barker, Kourtney Mary Kardashian: has occupation actor / has occupation socialite / has occupation Model / has occupation model / has occupation businessperson / has occupation fashion designer / has occupation television actor / has occupation celebrity / has occupation media personality / has occupation Entrepreneur / has occupation entrepreneur / is instance of human / American media personality, model and businesswoman (born 1979)

Using properties:
- unmarried partner (wd:P451 as p/ps), also known as boyfriend, cohabitant, domestic partner, enbyfriend, girlfriend, etc.: is subproperty of significant person / someone with whom the person is in a relationship without being married. Use "spouse" (P26) for married couples / someone with whom the person is in a relationship without being married. Use "spouse" (P26) for married couples
- start time (wd:P580 as pq), also known as began, beginning, building date, effective, effectivity, etc.: is subproperty of point in time / indicates the time an item begins to exist or a statement starts being valid / indicates the time an item begins to exist or a statement starts being valid / time an entity begins to exist or a statement starts being valid

Execution result:
Got 1 row and 2 columns:
| partner                    | partnerLabel            |
| -------------------------- | ----------------------- |
| Travis Barker (wd:Q220140) | Travis Barker (lang:en) |

[System]
You are a question answering assistant. Your job is to generate a SPARQL query to answer a given user question.

You should follow a step-by-step approach to generate the SPARQL query:
1. Determine possible entities and properties implied by the user question.
2. Search for the entities and properties in the knowledge graphs. Where applicable, constrain the searches with already identified entities and properties.
3. Gradually build up the SPARQL query using the identified entities and properties. Start with simple queries and add more complexity as needed. Execute intermediate queries to get feedback and to verify your assumptions. You may need to refine or rethink your current plan based on the query results and go back to step 2 if needed, possibly multiple times.
4. Use the answer or cancel function to finalize your answer and stop the generation process.

Available knowledge graphs:
- wikidata at http://localhost:7001 with prefix index for entities and similarity index for properties, and notes:
  - P106 = occupation. Use wdt:P106 to get occupations and fetch English labels with rdfs:label + FILTER(LANG(?label)="en"). When returning human occupations confirm the subject is human (wdt:P31 wd:Q5) to avoid non-human items.
  - Population (P1082) and tabular (P4179): use wdt:P1082 for quick/direct values; for time-series/point-in-time use p:P1082 + ps:P1082 + pq:P585 and ORDER BY pq:P585 DESC. Inspect statement qualifiers (e.g., 'applies to part') and prov:wasDerivedFrom references (pr:P854 etc.) to detect city-proper vs metro/prefecture scopes before using values.
  - Common person properties: P31 (instance of human Q5), P106 (occupation), P569 (date of birth), P19 (place of birth), P27 (country of citizenship), P21 (sex/gender), P166 (award received). Use wdt: for direct values when possible.
  - P17 (country) can be incomplete/misleading for places (historical/overseas tags). To get modern cities in a country combine: instance-of city (P31=Q515) + wdt:P17 OR use wdt:P131* to find an admin parent whose wdt:P17 = the country. Also cross-check coordinates (P625) or admin hierarchy to spot outliers.
  - When filtering by date of birth (P569) use xsd:dateTime comparisons (e.g. >= "1900-01-01T00:00:00Z"^^xsd:dateTime). Be aware many items have year-only or imprecise dates and coverage is biased toward notable/public figures (sportspeople, politicians, artists).
  - To retrieve qualifiers (e.g., award year) use the statement/qualifier pattern: p:Pxxx / ps:Pxxx / pq:P585. Use wdt:Pxxx for normalized/direct values when you don't need qualifiers. Example: p:P166 + pq:P585 gives award year.
  - To get a person's occupations: use wdt:P106 for direct/normalized values and rdfs:label for human-readable names (FILTER(LANG(...))). Example: wd:Q... wdt:P106 ?occ . ?occ rdfs:label ?occLabel . FILTER(LANG(?occLabel)="en").
  - P166 = award received. Use wdt:P166 for normalized/direct values when you only need award items. To get award years or qualifiers use p:P166 / ps:P166 / pq:P585. Many statements lack pq:P585 — use OPTIONAL { ?stmt pq:P585 ?date } and ORDER BY DESC(?date). When listing award winners, filter ?person wdt:P31 wd:Q5 to ensure humans.
  - Population time-series pattern: wd:Q... p:P1082 ?stmt . ?stmt ps:P1082 ?pop . OPTIONAL { ?stmt pq:P585 ?date } . ORDER BY DESC(?date). pq:P585 is the point-in-time qualifier. IMPORTANT: time-series may mix scopes (city proper vs metro) — e.g., Tokyo has a 2016 entry ~38,140,000 likely metro vs smaller city figures. Inspect qualifiers/references for scope before use.
  - Use wdt:P131* to traverse the admin hierarchy and compare wdt:P17 on the place vs an admin parent to detect historical/colonial country assignments. When mismatches appear, inspect the admin parent's instance-of (P31), labels, qualifiers and references to interpret the historical scope.
  - wdt:P106 often yields multiple occupations for a person. Use GROUP_CONCAT(DISTINCT ?occLabel; separator=", ") or return multiple rows. Always fetch labels with rdfs:label + FILTER(LANG(?label)="en") to get readable occupation names.
  - When a search_entity returns multiple hits (person vs sculpture vs memorial), confirm you selected the human/statements by checking wdt:P31 (instance of) and relevant wdt: properties (e.g., wdt:P106). This avoids using a non-human QID by mistake.
  - search_autocomplete can be constrained with a SPARQL pattern containing ?search (e.g., SELECT * WHERE { ?search wdt:P31 wd:Q5 }). Use constraints to focus results (e.g., humans) and avoid ambiguous fallbacks; if it returns no results, fallback to search_entity and verify wdt:P31.
  - Use search_property_of_entity to find relevant properties for an entity (e.g., 'award' -> P166) and search_object_of_property to discover candidate objects (e.g., 'physicist' for P106). This reduces guessing P/Q ids and surfaces qualifiers.
  - Inspect statement references and qualifiers: use prov:wasDerivedFrom on p: statements to find sources, and check qualifiers (e.g., 'applies to part' or other scope qualifiers) to disambiguate city vs metro vs admin area. Reference labels can be empty; inspect reference node properties for URLs or publication dates.

Index types used for entities and properties:
- Prefix index: Retrieves items by overlap between query keywords and item words. The query keywords can match item words exactly or as prefixes.
- Similarity index: Retrieves items by cosine similarity between their embeddings and the query embedding.

General notes across knowledge graphs:
- Use rdfs:label + FILTER(LANG(?label)="en") for labels; avoid SERVICE wikibase:label. Use wdt:Pxxx for normalized/direct values when qualifiers aren't needed. Use p:Pxxx / ps:Pxxx / pq:Pxxx to access statement qualifiers (e.g., award year via pq:P585). When dates matter, prefer xsd:dateTime and watch for year-only precision.
- Practical query patterns: use rdfs:label + FILTER(LANG(...)) for labels. Use wdt:Pxxx for direct/normalized values when qualifiers aren't needed. Use p:Pxxx / ps:Pxxx / pq:Pxxx to access qualifiers (dates via pq:P585). For dates use xsd:dateTime and expect year-only precision. For places: combine P17 with P131 or coordinate (P625) filters to avoid historical/overseas mismatches.
- Use OPTIONAL for pq: qualifiers (e.g., pq:P585), sort by qualifier (ORDER BY pq:P585 DESC) to prefer recent values. Use GROUP_CONCAT to combine multiple labels/values in one row. Watch for typed literals (xsd:dateTime, xsd:decimal) when filtering or sorting.
- Before querying, use search_entity to resolve human-friendly names to wd:Q identifiers and verify instance-of (e.g., check wdt:P31 = wd:Q5 for humans) to avoid ambiguous matches. Prefer the top match but programmatically confirm P31 before using its data.
- Use search_property to confirm property identifiers (e.g., "country" -> P17) before embedding them in queries. This prevents mistakes from assuming an ID and helps pick the best property if multiple choices exist.
- search_autocomplete can fall back to an unconstrained search or error when there are too many candidates. If this happens (e.g., "more than the maximum supported number of subject candidates"), retry with narrower constraints such as instance-of (wdt:P31), additional type filters, or short prefixes to reduce the candidate set; otherwise fallback to search_entity and verify wdt:P31.
- Use list(...) to inspect all triples on an entity for exploration, but expect large results for notable items. Prefer wdt: properties or targeted p:/ps:/pq: patterns in SPARQL when you need normalized values or qualifiers, respectively.
- Before embedding property or item IDs in SPARQL, use search_property, search_property_of_entity, and search_object_of_property to discover the appropriate P/PID or object QIDs. This reduces errors from guessing IDs and surfaces better property alternatives and qualifiers.
- search_constrained and search_autocomplete can return no results for constrained queries or when the index is large. If they fail, fallback to search_entity + verify P31 (or use search_property_of_entity). Constrain with instance-of (wdt:P31) or other properties in the SPARQL to improve matches.
- When selecting awards by year, prefer xsd:dateTime range filters (e.g., >= "2001-01-01T00:00:00Z"^^xsd:dateTime && < "2002-01-01T00:00:00Z"^^xsd:dateTime) instead of YEAR() for portability and precision.
- When selecting award winners via wdt:P166, filter ?person wdt:P31 wd:Q5 to ensure humans — fictional characters or non-humans may have award claims. If you need award years use p:P166 / ps:P166 / pq:P585 and OPTIONAL { ?stmt pq:P585 ?year } to retrieve qualifier years.
- Use wdt:P625 (coordinates) together with wdt:P131* and wdt:P17 checks to validate a place's modern country or to filter by geography. When country labels mismatch historically, inspect admin parents and coordinates to resolve whether the item refers to historical/colonial scope or current boundaries.
- Prefer wdt:Pxxx for normalized/direct values when qualifiers aren't needed. Use p:Pxxx / ps:Pxxx / pq:Pxxx to access qualifiers (e.g., pq:P585 for award year). Always fetch labels with rdfs:label + FILTER(LANG(?label) = "en").
- If search_autocomplete returns too many candidates or errors, retry with constraints (e.g., SELECT * WHERE { ?search wdt:P31 wd:Q5 }) or narrower query text. If still failing, fallback to search_entity and verify wdt:P31 for type checks.
- For award-year queries use p:P166 / ps:P166 / pq:P585 to access award statements and year qualifiers. Filter by xsd:dateTime ranges (e.g., >= "2020-01-01T00:00:00Z"^^xsd:dateTime && < "2021-01-01T00:00:00Z"^^xsd:dateTime) instead of YEAR() for robustness.
- Use search_property_of_entity to surface relevant properties for an entity (e.g., 'birth' -> P569/P19). list(...) can inspect triples but may return large results for notable items—prefer targeted wdt: patterns (wdt:Pxxx) or p:/ps:/pq: patterns when you need qualifiers.

SPARQL prefixes for use in function calls:
- bd: <http://www.bigdata.com/rdf#
- cc: <http://creativecommons.org/ns#
- data: <https://www.wikidata.org/wiki/Special:EntityData/
- dc: <http://purl.org/dc/elements/1.1/
- dct: <http://purl.org/dc/terms/
- foaf: <http://xmlns.com/foaf/0.1/
- geo: <http://www.opengis.net/ont/geosparql#
- geof: <http://www.opengis.net/def/function/geosparql/
- gn: <http://www.geonames.org/ontology#
- hint: <http://www.bigdata.com/queryHints#
- imdb: <https://www.imdb.com/
- math: <http://www.w3.org/2005/xpath-functions/math#
- ontolex: <http://www.w3.org/ns/lemon/ontolex#
- owl: <http://www.w3.org/2002/07/owl#
- p: <http://www.wikidata.org/prop/
- pq: <http://www.wikidata.org/prop/qualifier/
- pqn: <http://www.wikidata.org/prop/qualifier/value-normalized/
- pqv: <http://www.wikidata.org/prop/qualifier/value/
- pr: <http://www.wikidata.org/prop/reference/
- prn: <http://www.wikidata.org/prop/reference/value-normalized/
- prov: <http://www.w3.org/ns/prov#
- prv: <http://www.wikidata.org/prop/reference/value/
- ps: <http://www.wikidata.org/prop/statement/
- psn: <http://www.wikidata.org/prop/statement/value-normalized/
- psv: <http://www.wikidata.org/prop/statement/value/
- qb: <http://purl.org/linked-data/cube#
- qfn: <http://qlever.cs.uni-freiburg.de/function#
- ql: <http://qlever.cs.uni-freiburg.de/builtin-functions/
- qlss: <https://qlever.cs.uni-freiburg.de/spatialSearch/
- rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#
- rdfs: <http://www.w3.org/2000/01/rdf-schema#
- ref: <http://www.wikidata.org/reference/
- s: <http://www.wikidata.org/entity/statement/
- schema: <http://schema.org/
- skos: <http://www.w3.org/2004/02/skos/core#
- v: <http://www.wikidata.org/value/
- void: <http://rdfs.org/ns/void#
- wd: <http://www.wikidata.org/entity/
- wdno: <http://www.wikidata.org/prop/novalue/
- wdt: <http://www.wikidata.org/prop/direct/
- wdtn: <http://www.wikidata.org/prop/direct-normalized/
- wikibase: <http://wikiba.se/ontology#
- xsd: <http://www.w3.org/2001/XMLSchema#

Additional rules to follow:
- Explain your thought process before and after each step and function call.
- Do not just use or make up entity or property identifiers without verifying their existence in the knowledge graphs first.
- Do not ask the user for clarifications without first attempting to complete the task. If the task input is incomplete or ambiguous, try to make reasonable assumptions and document them.
- Do not use "SERVICE wikibase:label { bd:serviceParam wikibase:language ..." in SPARQL queries. It is not SPARQL standard and unsupported by the used QLever SPARQL endpoints. Use rdfs:label or similar properties to get labels instead.
- Always execute your final SPARQL query before giving an answer to make sure it returns the expected results.
- The SPARQL query should always return the actual identifiers / IRIs of the items in its result. It additionally may return labels or other human-readable information, but they are optional and should be put within optional clauses unless explicitly requested by the user.
- Do not stop early if there are still obvious improvements to be made to the SPARQL query. For example, keep refining your SPARQL query if its result contains irrelevant items or is missing items you expected.
- Do not perform additional computation (e.g. filtering, sorting, calculations) on the result of the SPARQL query to determine the answer. All computation should be done solely within SPARQL.
- For questions with a "True" or "False" answer the SPARQL query should be an ASK query.

[User] what kourtney kardashian boyfriends name?

[Assistant]
To find the name of Kourtney Kardashian's boyfriend, I need to identify the relevant information about her romantic relationships. This typically involves finding her partner(s) through Wikidata, which may be stored as a relationship property such as "partner" (P451) or similar.

### Step 1: Search for Kourtney Kardashian in Wikidata
First, I will search for Kourtney Kardashian to get her Wikidata entity ID.

Question: Kourtney Kardashian

Top 10 entity alternatives:
1. Kourtney Kardashian (wd:Q575689), also known as Kourtney, Kourtney Kardashian Barker, Kourtney Mary Kardashian: American media personality, model and businesswoman (born 1979) / has occupation media personality / has occupation fashion designer / has occupation television actor / has occupation businessperson / has occupation entrepreneur / has occupation Entrepreneur / has occupation socialite / has occupation celebrity / has occupation actor / has occupation model / has occupation Model / is instance of human
2. Kim Kardashian (wd:Q186304), also known as Kimberly Kardashian, Kimberly Noel Kardashian, Kimberly Noel Kardashian-West, Kim K, Kim K., etc.: American media personality, businesswoman, model and actress (born 1980) / American television and social media personality / has occupation erotic photography model / has occupation television producer / has occupation fashion designer / has occupation glamour model / has occupation entrepreneur / has occupation Entrepreneur / has occupation voice actor / has occupation socialite / has occupation celebrity / has occupation blogger / has occupation Model / has occupation actor / has occupation model / is instance of human
3. Kanye West (wd:Q15935, matched via Kanye Kardashian), also known as Kanye, Kanye Kardashian, Kanye Omari West, Ye, Yeezy: American rapper, singer, record producer, and fashion designer (born 1977) / American rapper, record producer, singer and fashion designer (born 1977) / has occupation fashion designer / has occupation record producer / has occupation businessperson / has occupation Entrepreneur / has occupation entrepreneur / has occupation songwriter / has occupation director / has occupation overseer / has occupation singer / has occupation rapper / is instance of human
4. Khloé Kardashian (wd:Q231270), also known as Khloe Alexandra Kardashian, Khloé Alexandra Kardashian, Khloé Alexandra Kardashian Odom, Khloe Kardashian, Khloe Kardashian Odom, etc.: American media personality,influencer, businesswoman (born 1984) / has occupation radio personality / has occupation fashion designer / has occupation television actor / has occupation film producer / has occupation Film producer / has occupation manufacturer / has occupation Entrepreneur / has occupation entrepreneur / has occupation film actor / has occupation socialite / has occupation celebrity / has occupation novelist / has occupation writer / has occupation Model / has occupation actor / has occupation model / is instance of human
5. Kris Jenner (wd:Q1138235, matched via Kris Kardashian), also known as Chris Jenner, Kris Houghton, Kris Kardashian, Kristen Houghton, Kristen Jenner, etc.: American media personality, socialite, and businesswoman / has occupation television presenter / has occupation television producer / has occupation flight attendant / has occupation Flight attendant / has occupation socialite / has occupation celebrity / has occupation author / has occupation actor / is instance of human
6. Robert Kardashian (wd:Q1816737), also known as Robert George Kardashian, Robert G. Kardashian, Rob Kardashian: American attorney and businessman (1944–2003) / has occupation Entrepreneur / has occupation entrepreneur / has occupation jurist / has occupation lawyer / has occupation Jurist / is instance of human
7. Rob Kardashian (wd:Q26318), also known as Robert Arthur Kardashian: American television personality and businessman / has occupation television actor / has occupation businessperson / has occupation socialite / has occupation Model / has occupation model / is instance of human
8. Kardashian-Jenner family (wd:Q95747857, matched via Kardashian family), also known as Kardashian family, Kardashians: American family prominent in entertainment, business, and fashion / is instance of family
9. Kardashian Index (wd:Q18387077), also known as K-Index: measure of the discrepancy between a scientist's social media profile and publication record / is instance of citation index
10. Kourtney Keegan (wd:Q26722249), also known as Kourtney Jean Keegan: has occupation tennis player / American tennis player / is instance of human

[Assistant]
The correct entity for Kourtney Kardashian is `wd:Q575689`. Now I will explore her properties to find information about her romantic partners. The most relevant property for this would be "partner" (P451). I will use `list` to inspect her triples and look for partner-related properties.

list

wd:Q575689

[Assistant]
Kourtney Kardashian has had two notable unmarried partners listed in Wikidata: **Younes Bendjima** and **Scott Disick**.

Since the question asks for "boyfriend's name" (singular), it is likely referring to her most recent or most well-known partner. As of recent public knowledge, **Scott Disick** is her long-term partner and the father of her children, while Younes Bendjima is a more recent partner (as of 2021–2023).

To confirm the most relevant answer, I will check the qualifiers or references for these relationships to see if there is a time-based qualifier (e.g., start date) that can help determine the most recent or primary partner.

I will now check the statement-level information (using `p:P451`) for qualifiers like start date (`pq:P580`) to determine the timeline of these relationships.

wd:Q575689

[Assistant]
The `p:P451` statements are stored as statement nodes (`s:...`), and I need to inspect the qualifiers and references for each to find start dates (`pq:P580`) or other time information.

I will now retrieve the qualifiers for each of these statements to determine when the relationships started.

[Assistant] Now I'll check the next statement for Scott Disick.

[Assistant] Now I'll check the third statement for Scott Disick.

[Assistant]
Now I have the full timeline of Kourtney Kardashian's relationships:

1. **Scott Disick** (wd:Q7883337):
   - Relationship period: **2006–2015** (3 children together)
   - Status: Ended in 2015, but they remained co-parents and were often seen together afterward.

2. **Younes Bendjima** (wd:Q55200042):
   - Relationship period: **2017–2018**
   - Status: Ended after about a year.

3. **Travis Barker** (wd:Q220140):
   - Relationship period: **2020–2022**
   - Status: Ended in April 2022 (marked as deprecated in Wikidata).
   - Note: This relationship was publicly confirmed, and they got engaged in 2021.

### Interpretation:
- The most recent and widely publicized boyfriend is **Travis Barker**, but the Wikidata entry for this relationship is marked as **deprecated**, likely because it ended.
- The current (as of 2024) publicly known partner is **Travis Barker**, even though the relationship ended in 2022 — there is no newer confirmed partner listed in Wikidata.
- Scott Disick is her long-term ex-partner and father of her children, but they are not currently in a romantic relationship.

Since the question asks for "boyfriend's name" (present tense), and **Travis Barker** is the most recent and well-known boyfriend (even if the relationship ended), and no newer partner is listed, **Travis Barker** is the correct answer.

I will now construct a SPARQL query to retrieve the most recent unmarried partner of Kourtney Kardashian, ordered by start time descending, and return the name.

### Final SPARQL Query:
I will use `p:P451` (unmarried partner) with `ps:P451` for the partner and `pq:P580` for start time, then order by start time descending to get the most recent.

I will also fetch the label of the partner in English.

execute

SELECT ?partner ?partnerLabel WHERE { wd:Q575689 p:P451 ?stmt . ?stmt ps:P451 ?partner . OPTIONAL { ?stmt pq:P580 ?startDate } . SERVICE wikibase:label { bd:serviceParam wikibase:language "en" } } ORDER BY DESC(?startDate) LIMIT 1

SPARQL execution failed:
Error while executing a SERVICE request to <http://wikiba.se:80/ontology#label>: SERVICE responded with HTTP status code: 301, Moved Permanently. First 100 bytes of the response: '
<title>301 Moved Permanently</title>

301 Moved Permanently'

[Assistant]
I need to avoid using `SERVICE wikibase:label` because it is not supported in this endpoint. Instead, I will use `rdfs:label` with a `FILTER(LANG(?label) = "en")` to get the English label of the partner.

Let me rewrite the query correctly.

SELECT ?partner ?partnerLabel WHERE { wd:Q575689 p:P451 ?stmt . ?stmt ps:P451 ?partner . OPTIONAL { ?stmt pq:P580 ?startDate } . ?partner rdfs:label ?partnerLabel . FILTER(LANG(?partnerLabel) = "en") } ORDER BY DESC(?startDate) LIMIT 1

[Assistant]
The SPARQL query successfully returned **Travis Barker** as Kourtney Kardashian's most recent unmarried partner, based on the latest start date in the data.

Even though their relationship ended in 2022, he is the most recent boyfriend listed in Wikidata, and no newer partner is recorded.

### Final Answer:
Kourtney Kardashian's most recent boyfriend is **Travis Barker**.

I will now provide the final SPARQL query and answer.

answer

SELECT ?partner ?partnerLabel WHERE { wd:Q575689 p:P451 ?stmt . ?stmt ps:P451 ?partner . OPTIONAL { ?stmt pq:P580 ?startDate } . ?partner rdfs:label ?partnerLabel . FILTER(LANG(?partnerLabel) = "en") } ORDER BY DESC(?startDate) LIMIT 1

Answer: Travis Barker


PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX wd: <http://www.wikidata.org/entity/>
SELECT ?nationality ?nationalityLabel WHERE {
  wd:Q192955 wdt:P27 ?nationality .
  ?nationality rdfs:label ?nationalityLabel .
  FILTER ( LANG( ?nationalityLabel ) = "en" )
}

Using entities:
- Steve Nash (wd:Q192955), also known as Stephen John Nash: has occupation film director / has occupation basketball player / has occupation businessperson / has occupation basketball coach / is instance of human / Canadian basketball player and coach

Using properties:
- country of citizenship (wd:P27 as wdt), also known as citizen of, citizenship, country, (legal) nationality, nation, etc.: is subproperty of country / the object is a country that recognizes the subject as its citizen / the object is a country that recognizes the subject as its citizen

Got 2 rows and 2 columns:
| nationality              | nationalityLabel         |
| ------------------------ | ------------------------ |
| United Kingdom (wd:Q145) | United Kingdom (lang:en) |
| Canada (wd:Q16)          | Canada (lang:en)         |

Answer:
Steve Nash holds dual citizenship in Canada and the United Kingdom. However, he is most prominently associated with Canada, as he represented Canada in international basketball and spent most of his life there.

Final Answer: Steve Nash's nationality is Canadian and British (United Kingdom).

Steve Nash holds dual citizenship in Canada and the United Kingdom. However, he is most prominently associated with Canada, as he represented Canada in international basketball and spent most of his life there.

Final Answer: Steve Nash's nationality is Canadian and British (United Kingdom).

SPARQL query over wikidata:
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX wd: <http://www.wikidata.org/entity/>
SELECT ?nationality ?nationalityLabel WHERE {
  wd:Q192955 wdt:P27 ?nationality .
  ?nationality rdfs:label ?nationalityLabel .
  FILTER ( LANG( ?nationalityLabel ) = "en" )
}

Using entities:
- Steve Nash (wd:Q192955), also known as Stephen John Nash: has occupation film director / has occupation basketball player / has occupation businessperson / has occupation basketball coach / is instance of human / Canadian basketball player and coach

Using properties:
- country of citizenship (wd:P27 as wdt), also known as citizen of, citizenship, country, (legal) nationality, nation, etc.: is subproperty of country / the object is a country that recognizes the subject as its citizen / the object is a country that recognizes the subject as its citizen

Execution result:
Got 2 rows and 2 columns:
| nationality              | nationalityLabel         |
| ------------------------ | ------------------------ |
| United Kingdom (wd:Q145) | United Kingdom (lang:en) |
| Canada (wd:Q16)          | Canada (lang:en)         |

[System]
You are a question answering assistant. Your job is to generate a SPARQL query to answer a given user question.

You should follow a step-by-step approach to generate the SPARQL query:
1. Determine possible entities and properties implied by the user question.
2. Search for the entities and properties in the knowledge graphs. Where applicable, constrain the searches with already identified entities and properties.
3. Gradually build up the SPARQL query using the identified entities and properties. Start with simple queries and add more complexity as needed. Execute intermediate queries to get feedback and to verify your assumptions. You may need to refine or rethink your current plan based on the query results and go back to step 2 if needed, possibly multiple times.
4. Use the answer or cancel function to finalize your answer and stop the generation process.

Available knowledge graphs:
- wikidata at http://localhost:7001 with prefix index for entities and similarity index for properties, and notes:
  - P106 = occupation. Use wdt:P106 to get occupations and fetch English labels with rdfs:label + FILTER(LANG(?label)="en"). When returning human occupations confirm the subject is human (wdt:P31 wd:Q5) to avoid non-human items.
  - Population (P1082) and tabular (P4179): use wdt:P1082 for quick/direct values; for time-series/point-in-time use p:P1082 + ps:P1082 + pq:P585 and ORDER BY pq:P585 DESC. Inspect statement qualifiers (e.g., 'applies to part') and prov:wasDerivedFrom references (pr:P854 etc.) to detect city-proper vs metro/prefecture scopes before using values.
  - Common person properties: P31 (instance of human Q5), P106 (occupation), P569 (date of birth), P19 (place of birth), P27 (country of citizenship), P21 (sex/gender), P166 (award received). Use wdt: for direct values when possible.
  - P17 (country) can be incomplete/misleading for places (historical/overseas tags). To get modern cities in a country combine: instance-of city (P31=Q515) + wdt:P17 OR use wdt:P131* to find an admin parent whose wdt:P17 = the country. Also cross-check coordinates (P625) or admin hierarchy to spot outliers.
  - When filtering by date of birth (P569) use xsd:dateTime comparisons (e.g. >= "1900-01-01T00:00:00Z"^^xsd:dateTime). Be aware many items have year-only or imprecise dates and coverage is biased toward notable/public figures (sportspeople, politicians, artists).
  - To retrieve qualifiers (e.g., award year) use the statement/qualifier pattern: p:Pxxx / ps:Pxxx / pq:P585. Use wdt:Pxxx for normalized/direct values when you don't need qualifiers. Example: p:P166 + pq:P585 gives award year.
  - To get a person's occupations: use wdt:P106 for direct/normalized values and rdfs:label for human-readable names (FILTER(LANG(...))). Example: wd:Q... wdt:P106 ?occ . ?occ rdfs:label ?occLabel . FILTER(LANG(?occLabel)="en").
  - P166 = award received. Use wdt:P166 for normalized/direct values when you only need award items. To get award years or qualifiers use p:P166 / ps:P166 / pq:P585. Many statements lack pq:P585 — use OPTIONAL { ?stmt pq:P585 ?date } and ORDER BY DESC(?date). When listing award winners, filter ?person wdt:P31 wd:Q5 to ensure humans.
  - Population time-series pattern: wd:Q... p:P1082 ?stmt . ?stmt ps:P1082 ?pop . OPTIONAL { ?stmt pq:P585 ?date } . ORDER BY DESC(?date). pq:P585 is the point-in-time qualifier. IMPORTANT: time-series may mix scopes (city proper vs metro) — e.g., Tokyo has a 2016 entry ~38,140,000 likely metro vs smaller city figures. Inspect qualifiers/references for scope before use.
  - Use wdt:P131* to traverse the admin hierarchy and compare wdt:P17 on the place vs an admin parent to detect historical/colonial country assignments. When mismatches appear, inspect the admin parent's instance-of (P31), labels, qualifiers and references to interpret the historical scope.
  - wdt:P106 often yields multiple occupations for a person. Use GROUP_CONCAT(DISTINCT ?occLabel; separator=", ") or return multiple rows. Always fetch labels with rdfs:label + FILTER(LANG(?label)="en") to get readable occupation names.
  - When a search_entity returns multiple hits (person vs sculpture vs memorial), confirm you selected the human/statements by checking wdt:P31 (instance of) and relevant wdt: properties (e.g., wdt:P106). This avoids using a non-human QID by mistake.
  - search_autocomplete can be constrained with a SPARQL pattern containing ?search (e.g., SELECT * WHERE { ?search wdt:P31 wd:Q5 }). Use constraints to focus results (e.g., humans) and avoid ambiguous fallbacks; if it returns no results, fallback to search_entity and verify wdt:P31.
  - Use search_property_of_entity to find relevant properties for an entity (e.g., 'award' -> P166) and search_object_of_property to discover candidate objects (e.g., 'physicist' for P106). This reduces guessing P/Q ids and surfaces qualifiers.
  - Inspect statement references and qualifiers: use prov:wasDerivedFrom on p: statements to find sources, and check qualifiers (e.g., 'applies to part' or other scope qualifiers) to disambiguate city vs metro vs admin area. Reference labels can be empty; inspect reference node properties for URLs or publication dates.

Index types used for entities and properties:
- Prefix index: Retrieves items by overlap between query keywords and item words. The query keywords can match item words exactly or as prefixes.
- Similarity index: Retrieves items by cosine similarity between their embeddings and the query embedding.

General notes across knowledge graphs:
- Use rdfs:label + FILTER(LANG(?label)="en") for labels; avoid SERVICE wikibase:label. Use wdt:Pxxx for normalized/direct values when qualifiers aren't needed. Use p:Pxxx / ps:Pxxx / pq:Pxxx to access statement qualifiers (e.g., award year via pq:P585). When dates matter, prefer xsd:dateTime and watch for year-only precision.
- Practical query patterns: use rdfs:label + FILTER(LANG(...)) for labels. Use wdt:Pxxx for direct/normalized values when qualifiers aren't needed. Use p:Pxxx / ps:Pxxx / pq:Pxxx to access qualifiers (dates via pq:P585). For dates use xsd:dateTime and expect year-only precision. For places: combine P17 with P131 or coordinate (P625) filters to avoid historical/overseas mismatches.
- Use OPTIONAL for pq: qualifiers (e.g., pq:P585), sort by qualifier (ORDER BY pq:P585 DESC) to prefer recent values. Use GROUP_CONCAT to combine multiple labels/values in one row. Watch for typed literals (xsd:dateTime, xsd:decimal) when filtering or sorting.
- Before querying, use search_entity to resolve human-friendly names to wd:Q identifiers and verify instance-of (e.g., check wdt:P31 = wd:Q5 for humans) to avoid ambiguous matches. Prefer the top match but programmatically confirm P31 before using its data.
- Use search_property to confirm property identifiers (e.g., "country" -> P17) before embedding them in queries. This prevents mistakes from assuming an ID and helps pick the best property if multiple choices exist.
- search_autocomplete can fall back to an unconstrained search or error when there are too many candidates. If this happens (e.g., "more than the maximum supported number of subject candidates"), retry with narrower constraints such as instance-of (wdt:P31), additional type filters, or short prefixes to reduce the candidate set; otherwise fallback to search_entity and verify wdt:P31.
- Use list(...) to inspect all triples on an entity for exploration, but expect large results for notable items. Prefer wdt: properties or targeted p:/ps:/pq: patterns in SPARQL when you need normalized values or qualifiers, respectively.
- Before embedding property or item IDs in SPARQL, use search_property, search_property_of_entity, and search_object_of_property to discover the appropriate P/PID or object QIDs. This reduces errors from guessing IDs and surfaces better property alternatives and qualifiers.
- search_constrained and search_autocomplete can return no results for constrained queries or when the index is large. If they fail, fallback to search_entity + verify P31 (or use search_property_of_entity). Constrain with instance-of (wdt:P31) or other properties in the SPARQL to improve matches.
- When selecting awards by year, prefer xsd:dateTime range filters (e.g., >= "2001-01-01T00:00:00Z"^^xsd:dateTime && < "2002-01-01T00:00:00Z"^^xsd:dateTime) instead of YEAR() for portability and precision.
- When selecting award winners via wdt:P166, filter ?person wdt:P31 wd:Q5 to ensure humans — fictional characters or non-humans may have award claims. If you need award years use p:P166 / ps:P166 / pq:P585 and OPTIONAL { ?stmt pq:P585 ?year } to retrieve qualifier years.
- Use wdt:P625 (coordinates) together with wdt:P131* and wdt:P17 checks to validate a place's modern country or to filter by geography. When country labels mismatch historically, inspect admin parents and coordinates to resolve whether the item refers to historical/colonial scope or current boundaries.
- Prefer wdt:Pxxx for normalized/direct values when qualifiers aren't needed. Use p:Pxxx / ps:Pxxx / pq:Pxxx to access qualifiers (e.g., pq:P585 for award year). Always fetch labels with rdfs:label + FILTER(LANG(?label) = "en").
- If search_autocomplete returns too many candidates or errors, retry with constraints (e.g., SELECT * WHERE { ?search wdt:P31 wd:Q5 }) or narrower query text. If still failing, fallback to search_entity and verify wdt:P31 for type checks.
- For award-year queries use p:P166 / ps:P166 / pq:P585 to access award statements and year qualifiers. Filter by xsd:dateTime ranges (e.g., >= "2020-01-01T00:00:00Z"^^xsd:dateTime && < "2021-01-01T00:00:00Z"^^xsd:dateTime) instead of YEAR() for robustness.
- Use search_property_of_entity to surface relevant properties for an entity (e.g., 'birth' -> P569/P19). list(...) can inspect triples but may return large results for notable items—prefer targeted wdt: patterns (wdt:Pxxx) or p:/ps:/pq: patterns when you need qualifiers.

SPARQL prefixes for use in function calls:
- bd: <http://www.bigdata.com/rdf#
- cc: <http://creativecommons.org/ns#
- data: <https://www.wikidata.org/wiki/Special:EntityData/
- dc: <http://purl.org/dc/elements/1.1/
- dct: <http://purl.org/dc/terms/
- foaf: <http://xmlns.com/foaf/0.1/
- geo: <http://www.opengis.net/ont/geosparql#
- geof: <http://www.opengis.net/def/function/geosparql/
- gn: <http://www.geonames.org/ontology#
- hint: <http://www.bigdata.com/queryHints#
- imdb: <https://www.imdb.com/
- math: <http://www.w3.org/2005/xpath-functions/math#
- ontolex: <http://www.w3.org/ns/lemon/ontolex#
- owl: <http://www.w3.org/2002/07/owl#
- p: <http://www.wikidata.org/prop/
- pq: <http://www.wikidata.org/prop/qualifier/
- pqn: <http://www.wikidata.org/prop/qualifier/value-normalized/
- pqv: <http://www.wikidata.org/prop/qualifier/value/
- pr: <http://www.wikidata.org/prop/reference/
- prn: <http://www.wikidata.org/prop/reference/value-normalized/
- prov: <http://www.w3.org/ns/prov#
- prv: <http://www.wikidata.org/prop/reference/value/
- ps: <http://www.wikidata.org/prop/statement/
- psn: <http://www.wikidata.org/prop/statement/value-normalized/
- psv: <http://www.wikidata.org/prop/statement/value/
- qb: <http://purl.org/linked-data/cube#
- qfn: <http://qlever.cs.uni-freiburg.de/function#
- ql: <http://qlever.cs.uni-freiburg.de/builtin-functions/
- qlss: <https://qlever.cs.uni-freiburg.de/spatialSearch/
- rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#
- rdfs: <http://www.w3.org/2000/01/rdf-schema#
- ref: <http://www.wikidata.org/reference/
- s: <http://www.wikidata.org/entity/statement/
- schema: <http://schema.org/
- skos: <http://www.w3.org/2004/02/skos/core#
- v: <http://www.wikidata.org/value/
- void: <http://rdfs.org/ns/void#
- wd: <http://www.wikidata.org/entity/
- wdno: <http://www.wikidata.org/prop/novalue/
- wdt: <http://www.wikidata.org/prop/direct/
- wdtn: <http://www.wikidata.org/prop/direct-normalized/
- wikibase: <http://wikiba.se/ontology#
- xsd: <http://www.w3.org/2001/XMLSchema#

Additional rules to follow:
- Explain your thought process before and after each step and function call.
- Do not just use or make up entity or property identifiers without verifying their existence in the knowledge graphs first.
- Do not ask the user for clarifications without first attempting to complete the task. If the task input is incomplete or ambiguous, try to make reasonable assumptions and document them.
- Do not use "SERVICE wikibase:label { bd:serviceParam wikibase:language ..." in SPARQL queries. It is not SPARQL standard and unsupported by the used QLever SPARQL endpoints. Use rdfs:label or similar properties to get labels instead.
- Always execute your final SPARQL query before giving an answer to make sure it returns the expected results.
- The SPARQL query should always return the actual identifiers / IRIs of the items in its result. It additionally may return labels or other human-readable information, but they are optional and should be put within optional clauses unless explicitly requested by the user.
- Do not stop early if there are still obvious improvements to be made to the SPARQL query. For example, keep refining your SPARQL query if its result contains irrelevant items or is missing items you expected.
- Do not perform additional computation (e.g. filtering, sorting, calculations) on the result of the SPARQL query to determine the answer. All computation should be done solely within SPARQL.
- For questions with a "True" or "False" answer the SPARQL query should be an ASK query.

[User] what is steve nash nationality?

[Assistant]
To determine Steve Nash's nationality, I need to find information about his country of citizenship. In Wikidata, the property for country of citizenship is P27.

Step 1: Search for the entity "Steve Nash" in Wikidata to get his Q identifier.

Question: steve nash

Top 10 entity alternatives:
1. Steve Nash (wd:Q192955), also known as Stephen John Nash: Canadian basketball player and coach / has occupation basketball player / has occupation basketball coach / has occupation businessperson / has occupation film director / is instance of human
2. Steve Nash (wd:Q16137022): English rugby league footballer and coach / has occupation rugby league player / is instance of human
3. Steve Nash (wd:Q48851147): has occupation disc jockey / is instance of human / has occupation DJ
4. Steve Nash (wd:Q42316961): has occupation actor / is instance of human / actor
5. Steven Jackson (wd:Q3499240, matched via Steven Nash Jackson), also known as Steven Nash Jackson: has occupation baseball player / American baseball player / is instance of human
6. Steven G. Nash (wd:Q98756087): has occupation businessperson / has occupation politician / is instance of human / American politician
7. Steven Roy Nash (wd:Q76187877), also known as Dr. Steven Roy Nash: Peerage person ID=590989 / is instance of human
8. Edward Mungo Steven Nash (wd:Q76187880), also known as Edward Nash: is instance of human / (born 1990)
9. Nash v. Nash (wd:Q125279638): is instance of decision of the Supreme Court of Canada / case from the Supreme Court of Canada
10. Richard Nash [nashricha0005026] (wd:Q103882781): is instance of encyclopaedic article / is instance of encyclopedia article / article in Electronic Enlightenment

[Assistant]
The top result is Steve Nash (wd:Q192955), a Canadian basketball player and coach. This is the most relevant entity for the well-known Steve Nash. I will now check his country of citizenship (P27) to confirm his nationality.

Step 2: Retrieve the country of citizenship (P27) for Steve Nash (wd:Q192955).

execute

SELECT ?nationality WHERE { wd:Q192955 wdt:P27 ?nationality }

Got 2 rows and 1 column:
| nationality              |
| ------------------------ |
| United Kingdom (wd:Q145) |
| Canada (wd:Q16)          |

[Assistant]
The results show that Steve Nash (wd:Q192955) has two countries of citizenship: the United Kingdom (wd:Q145) and Canada (wd:Q16). This is because Steve Nash was born in South Africa to British parents and moved to Canada at a young age. He holds dual citizenship in Canada and the United Kingdom, but he is most commonly associated with Canada, as he represented Canada internationally in basketball.

To provide a clear answer, I will now retrieve the labels for these countries to confirm their names in English.

Step 3: Retrieve the English labels for the nationality entities (United Kingdom and Canada).

SELECT ?nationality ?nationalityLabel WHERE { wd:Q192955 wdt:P27 ?nationality . ?nationality rdfs:label ?nationalityLabel . FILTER(LANG(?nationalityLabel) = "en") }

Got 2 rows and 2 columns:
| nationality              | nationalityLabel         |
| ------------------------ | ------------------------ |
| United Kingdom (wd:Q145) | United Kingdom (lang:en) |
| Canada (wd:Q16)          | Canada (lang:en)         |

[Assistant]
Steve Nash holds dual citizenship in Canada and the United Kingdom. However, he is most prominently associated with Canada, as he represented Canada in international basketball and spent most of his life there.

Final Answer: Steve Nash's nationality is Canadian and British (United Kingdom).