PREFIX p: <http://www.wikidata.org/prop/>
PREFIX ps: <http://www.wikidata.org/prop/statement/>
PREFIX wd: <http://www.wikidata.org/entity/>
SELECT ?date WHERE {
  wd:Q211386 p:P585 ?stmt .
  ?stmt ps:P585 ?date
}

Using entities:
- 1906 San Francisco earthquake (wd:Q211386), also known as 1906 San Francisco earthquake and fire, earthquake of 1906, Great 1906 San Francisco Earthquake, Great San Francisco Earthquake and Fire, San Francisco earthquake and fire, 1906, etc.: is instance of earthquake / is instance of Earthquake / major earthquake that struck San Francisco and the coast of Northern California

Using properties:
- point in time (wd:P585 as p/ps), also known as as of, at time, by date, date, during, etc.: date something took place, existed or a statement was true; for providing time use the "refine date" property (P4241) / time and date something took place, existed or a statement was true / time and date something took place, existed or a statement was true / time and date something took place, existed or a statement was true

Answer: The San Francisco earthquake occurred on April 18, 1906.

The San Francisco earthquake occurred on April 18, 1906.

SPARQL query over wikidata:
PREFIX p: <http://www.wikidata.org/prop/>
PREFIX ps: <http://www.wikidata.org/prop/statement/>
PREFIX wd: <http://www.wikidata.org/entity/>
SELECT ?date WHERE {
  wd:Q211386 p:P585 ?stmt .
  ?stmt ps:P585 ?date
}

Using entities:
- 1906 San Francisco earthquake (wd:Q211386), also known as 1906 San Francisco earthquake and fire, earthquake of 1906, Great 1906 San Francisco Earthquake, Great San Francisco Earthquake and Fire, San Francisco earthquake and fire, 1906, etc.: is instance of earthquake / is instance of Earthquake / major earthquake that struck San Francisco and the coast of Northern California

Using properties:
- point in time (wd:P585 as p/ps), also known as as of, at time, by date, date, during, etc.: date something took place, existed or a statement was true; for providing time use the "refine date" property (P4241) / time and date something took place, existed or a statement was true / time and date something took place, existed or a statement was true / time and date something took place, existed or a statement was true

Execution result:
Got 2 rows and 1 column:
| date                                |
| ----------------------------------- |
| 1906-04-18T00:00:00Z (xsd:dateTime) |
| 1906-04-18T00:00:00Z (xsd:dateTime) |

[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] when did the san francisco earthquake occur?

[Assistant]
To determine when the San Francisco earthquake occurred, I need to identify the specific earthquake event and its date. The most famous San Francisco earthquake is the 1906 earthquake, but I should verify this using the knowledge graph.

### Step 1: Search for the entity "San Francisco earthquake"
I'll start by searching for the entity related to the San Francisco earthquake to identify its Wikidata identifier.

Question: San Francisco earthquake

Top 10 entity alternatives:
1. 1906 San Francisco earthquake (wd:Q211386), also known as 1906 San Francisco earthquake and fire, earthquake of 1906, Great 1906 San Francisco Earthquake, Great San Francisco Earthquake and Fire, San Francisco earthquake and fire, 1906, etc.: major earthquake that struck San Francisco and the coast of Northern California / is instance of earthquake / is instance of Earthquake
2. 1989 Loma Prieta earthquake (wd:Q1053476, matched via 1989 San Francisco earthquake), also known as 1989 San Francisco earthquake, Loma Prieta earthquake: major earthquake in northern California / major earthquake in northern California / is instance of natural disaster / is instance of Earthquake / is instance of earthquake / is instance of disaster
3. 1957 San Francisco earthquake (wd:Q20312370): is instance of earthquake / is instance of Earthquake
4. The Great San Francisco Earthquake (wd:Q125816606): scientific article published in 1988 / is instance of scholarly article / is instance of academic article
5. Earthquake waves at San Francisco (wd:Q80986050): scientific article published on 01 February 1884 / is instance of scholarly article / is instance of academic article
6. The Big Picture: San Francisco Earthquake (wd:Q110056932): is instance of Saturday Night Live sketch / sketch from Saturday Night Live
7. The San Francisco earthquake of 1906 (wd:Q58176314): scholarly article by Dennis R. Dean published November 1993 in Annals of Science / is instance of scholarly article / is instance of academic article
8. Saints and the San Francisco earthquake (wd:Q57138167): scientific article published on 01 January 1983 / is instance of scholarly article / is instance of academic article
9. The 1906 San Francisco Earthquake and Fire (wd:Q133012217): online exhibition from National Archives and Records Administration (United States) / is instance of online exhibition
10. Widely felt M3.7 earthquake shakes San Francisco (wd:Q132185779): scientific article published on 28 October 2023 / is instance of scholarly article / is instance of academic article

[Assistant]
The top result is "1906 San Francisco earthquake" (wd:Q211386), which is the most historically significant earthquake in San Francisco. This is likely the one the user is referring to. I will now retrieve the date of this earthquake.

### Step 2: Retrieve the date of the 1906 San Francisco earthquake
The date of an earthquake event is typically stored using the property "point in time" (P585). I will query for the date of the 1906 San Francisco earthquake using its Wikidata ID.

SELECT ?date WHERE { wd:Q211386 p:P585 ?stmt . ?stmt ps:P585 ?date }

[Assistant]
The 1906 San Francisco earthquake occurred on April 18, 1906. The query returned two identical results, likely due to duplicate statements in the knowledge graph, but both confirm the same date.

### Final Answer:
The San Francisco earthquake (specifically the 1906 one) occurred on April 18, 1906.

I will now provide the final SPARQL query and answer.

answer

SELECT ?date WHERE { wd:Q211386 p:P585 ?stmt . ?stmt ps:P585 ?date }

Answer: The San Francisco earthquake occurred on April 18, 1906.


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 ?placeOfBirth ?country WHERE {
  wd:Q13603754 wdt:P19 ?placeOfBirth .
  wd:Q13603754 wdt:P27 ?country .
  ?placeOfBirth rdfs:label ?placeLabel .
  ?country rdfs:label ?countryLabel .
  FILTER ( LANG( ?placeLabel ) = "en" ) .
  FILTER ( LANG( ?countryLabel ) = "en" )
}

Using entities:
- Robert Irvine (wd:Q13603754), also known as Robert Paul Irvine: has occupation chef / is instance of human / British celebrity chef

Using properties:
- place of birth (wd:P19 as wdt), also known as birth city, birth location, birth place, birthplace, born, etc.: is subproperty of location / most specific known birth location of a person, animal or fictional character / most specific known (e.g. city instead of country, or ... birth location of a person, animal or fictional character / most specific known (e.g. city instead of country, or ... birth location of a person, animal or fictional character
- 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

Answer: Robert Irvine comes from Salisbury, England, United Kingdom.

Robert Irvine comes from Salisbury, England, 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 ?placeOfBirth ?country WHERE {
  wd:Q13603754 wdt:P19 ?placeOfBirth .
  wd:Q13603754 wdt:P27 ?country .
  ?placeOfBirth rdfs:label ?placeLabel .
  ?country rdfs:label ?countryLabel .
  FILTER ( LANG( ?placeLabel ) = "en" ) .
  FILTER ( LANG( ?countryLabel ) = "en" )
}

Using entities:
- Robert Irvine (wd:Q13603754), also known as Robert Paul Irvine: has occupation chef / is instance of human / British celebrity chef

Using properties:
- place of birth (wd:P19 as wdt), also known as birth city, birth location, birth place, birthplace, born, etc.: is subproperty of location / most specific known birth location of a person, animal or fictional character / most specific known (e.g. city instead of country, or ... birth location of a person, animal or fictional character / most specific known (e.g. city instead of country, or ... birth location of a person, animal or fictional character
- 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 1 row and 2 columns:
| placeOfBirth           | country                  |
| ---------------------- | ------------------------ |
| Salisbury (wd:Q160642) | United Kingdom (wd:Q145) |

[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] where does robert irvine come from?

[Assistant]
To determine where Robert Irvine comes from, I need to find information about his place of birth or country of citizenship. Let me start by searching for the entity "Robert Irvine" in Wikidata.

Question: robert irvine

Top 10 entity alternatives:
1. Robert Irvine (wd:Q29561444): has occupation association football player / has occupation soccer player / association football player / is instance of human
2. Bobby Irvine (wd:Q4935169, matched via Robert Irvine), also known as Robert Irvine, Robert James Irvine: Northern Irish association footballer (born 1942) / has occupation association football player / has occupation soccer player / is instance of human
3. Robert Irvine (wd:Q13603754), also known as Robert Paul Irvine: British celebrity chef / is instance of human / has occupation chef
4. Robert Irvine (wd:Q7345808): New Zealand rugby league footballer / has occupation rugby league player / is instance of human
5. Irvine, Robert (wd:Q94829234): entry in Alumni Oxonienses: the Members of the University of Oxford, 1715-1886 / is instance of biographical article
6. Robert Irvine (wd:Q112449704): has occupation musician / is instance of human
7. Robert Irvine (wd:Q18576922): is instance of human / Scottish Royalist
8. Robert Irvine (wd:Q93942944): is instance of scholarly article / is instance of academic article
9. Robert Irvine (wd:Q76346164): Peerage person ID=703910 / is instance of human
10. Robert Irvine (wd:Q76037914): Peerage person ID=485894 / is instance of human

[Assistant]
The search results show multiple entities named "Robert Irvine." The most prominent one appears to be Robert Irvine (wd:Q13603754), a British celebrity chef. Another notable one is Robert Irvine (wd:Q29561444), an association football player. Since the question is about where Robert Irvine comes from, and the celebrity chef is more widely known, I will focus on wd:Q13603754.

I will now check the properties of this entity to find information about his place of birth or country of citizenship.

list

wd:Q13603754

Got 186 rows and 3 columns, showing the first 10 rows below:
| subject                      | property                         | object                                                                          |
| ---------------------------- | -------------------------------- | ------------------------------------------------------------------------------- |
| Robert Irvine (wd:Q13603754) | instance of (wdt:P31)            | human (wd:Q5)                                                                   |
| Robert Irvine (wd:Q13603754) | occupation (wdt:P106)            | chef (wd:Q3499072)                                                              |
| Robert Irvine (wd:Q13603754) | sex or gender (wdt:P21)          | male (wd:Q6581097)                                                              |
| Robert Irvine (wd:Q13603754) | given name (wdt:P735)            | Robert (wd:Q4927937)                                                            |
| Robert Irvine (wd:Q13603754) | date of birth (wdt:P569)         | 1965-09-24T00:00:00Z (xsd:dateTime)                                             |
| Robert Irvine (wd:Q13603754) | Commons category (wdt:P373)      | Robert Irvine                                                                   |
| Robert Irvine (wd:Q13603754) | image (wdt:P18)                  | <http://commons.wikimedia.org/wiki/Special:FilePath/Chef%20Robert%20Irvine.jpg> |
| Robert Irvine (wd:Q13603754) | family name (wdt:P734)           | Irvine (wd:Q29477197)                                                           |
| Robert Irvine (wd:Q13603754) | country of citizenship (wdt:P27) | United Kingdom (wd:Q145)                                                        |
| Robert Irvine (wd:Q13603754) | Freebase ID (wdt:P646)           | /m/0272y2y                                                                      |
| ...                          | ...                              | ...                                                                             |

[Assistant]
From the list of triples, I can see that Robert Irvine (wd:Q13603754) has the property "country of citizenship" (wdt:P27) with the value "United Kingdom" (wd:Q145). This indicates that Robert Irvine is a citizen of the United Kingdom.

To confirm his place of birth, I will check if there is any information about his place of birth (wdt:P19).

Question: birth

Top 10 property alternatives:
1. place of birth (wd:P19 as p/wdt, matched via born), also known as birth city, birth location, birth place, birthplace, born, etc.: most specific known (e.g. city instead of country, or ... birth location of a person, animal or fictional character / most specific known (e.g. city instead of country, or ... birth location of a person, animal or fictional character / most specific known birth location of a person, animal or fictional character / is subproperty of location
2. date of birth (wd:P569 as p/wdt, matched via born), also known as birth date, birthdate, birth year, birthyear, born, etc.: is subproperty of date of foundation or creation / date on which the subject was born / date on which the subject was born / date on which the subject was born / is subproperty of inception
3. spouse (wd:P26 as p/wdt, matched via marry), also known as common-law husband, common-law spouse, common-law wife, husband, husbands, etc.: the subject has the object as their spouse (husband, wife, ... Use "unmarried partner" (P451) for non-married companions / the subject has the object as their spouse (husband, wife, ... Use "unmarried partner" (P451) for non-married companions / the subject has the object as their spouse (husband, wife, ... Use "unmarried partner" (P451) for non-married companions / is subproperty of significant person / is subproperty of relative
4. sex or gender (wd:P21 as p/wdt, matched via gender), also known as biological sex, gender, gender expression, gender identity, gender or sex, etc.: sexual identity of subject: male (Q6581097), female ... (Q43445). Groups of same gender use "subclass of" (P279) / sex or gender identity: male (Q6581097), female (Q6581072), ... (Q43445). Groups of same gender use subclass of (P279) / sex or gender identity of human or animal. For human: male, ... female organism. Groups of same gender use subclass of (P279)
5. country of citizenship (wd:P27 as p/wdt, matched via nationality), also known as citizen of, citizenship, country, (legal) nationality, nation, etc.: the object is a country that recognizes the subject as its citizen / the object is a country that recognizes the subject as its citizen / is subproperty of country
6. Open Library ID (wd:P648 as p/wdt/wdtn, matched via OLID), also known as OL ID, OLID, Open Library author ID, OpenLibrary author ID, Open Library book ID, etc.: identifier in "the Internet Archive" for information about a work ("W"), edition ("M") or author ("A") of a book / identifier for a work ("W"), edition ("M") or author ("A") for book data of the Internet Archive
7. family name (wd:P734 as p/wdt, matched via surname), also known as clan name, last name, surname, P734: last name or family name of a person / part of full name of person / part of full name of person / is subproperty of name
8. given name (wd:P735 as p/wdt, matched via name), also known as Christian name, first name, forename, middle name, name, etc.: first name or another given name of this person; values used with the property should not link disambiguations nor family names / first name or another given name of this person; values used with the property shouldn't link disambiguations nor family names / first name or another given name of this person; values used with the property shouldn't link disambiguations nor family names / is subproperty of name
9. image (wd:P18 as p/wdt, matched via still), also known as camera picture, Commons image, drawing, File:, graph, etc.: image of relevant illustration of the subject; if available, ... only images which exist on Wikimedia Commons are acceptable / image of relevant illustration of the subject; if available, ... only images which exist on Wikimedia Commons are acceptable / image of relevant illustration of the subject; if available, ... map, flag image, signature image, logo image, collage image) / image of relevant illustration of the subject; if available, ... map, flag image, signature image, logo image, collage image)
10. occupation (wd:P106 as p/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)

No other items found

[Assistant]
The property "place of birth" (wdt:P19) is listed as a relevant property for Robert Irvine. I will now check if this property has a value for Robert Irvine (wd:Q13603754).

wd:Q13603754

[Assistant]
Robert Irvine (wd:Q13603754) was born in Salisbury (wd:Q160642). Salisbury is a city in England, United Kingdom.

To summarize:
- Robert Irvine is a British celebrity chef.
- His place of birth is Salisbury, England.
- His country of citizenship is the United Kingdom.

The answer to the question "Where does Robert Irvine come from?" is that he comes from Salisbury, England, United Kingdom.

I will now provide the final SPARQL query and answer.

answer

SELECT ?placeOfBirth ?country WHERE { wd:Q13603754 wdt:P19 ?placeOfBirth . wd:Q13603754 wdt:P27 ?country . ?placeOfBirth rdfs:label ?placeLabel . ?country rdfs:label ?countryLabel . FILTER(LANG(?placeLabel) = "en") . FILTER(LANG(?countryLabel) = "en") }

Answer: Robert Irvine comes from Salisbury, England, United Kingdom.


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 ?headquarters WHERE {
  wd:Q505922 wdt:P159 ?headquarters .
  ?headquarters rdfs:label ?label
  FILTER ( LANG( ?label ) = "en" )
}

Using entities:
- Electrolux (wd:Q505922), also known as AB Electrolux: is instance of business / is instance of enterprise / is instance of public company / a multinational appliance manufacturer / a multinational appliance manufacturer / Swedish multinational manufacturer and marketer of home appliances / Swedish multinational manufacturer and marketer of home appliances

Using properties:
- headquarters location (wd:P159 as wdt), also known as admin HQ, based in, garrison, head office location, head quarters, etc.: is subproperty of significant place / city or town where an organization's headquarters is or has been situated. Use P276 qualifier for specific building / specific location where an organisation's HQ is or has been located / specific location where an organisation's HQ is or has been located

Got 1 row and 1 column:
| headquarters         |
| -------------------- |
| Stockholm (wd:Q1754) |

Answer: Electrolux is based in Stockholm, Sweden.

Electrolux is based in Stockholm, Sweden.

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 ?headquarters WHERE {
  wd:Q505922 wdt:P159 ?headquarters .
  ?headquarters rdfs:label ?label
  FILTER ( LANG( ?label ) = "en" )
}

Using entities:
- Electrolux (wd:Q505922), also known as AB Electrolux: is instance of business / is instance of enterprise / is instance of public company / a multinational appliance manufacturer / a multinational appliance manufacturer / Swedish multinational manufacturer and marketer of home appliances / Swedish multinational manufacturer and marketer of home appliances

Using properties:
- headquarters location (wd:P159 as wdt), also known as admin HQ, based in, garrison, head office location, head quarters, etc.: is subproperty of significant place / city or town where an organization's headquarters is or has been situated. Use P276 qualifier for specific building / specific location where an organisation's HQ is or has been located / specific location where an organisation's HQ is or has been located

Execution result:
Got 1 row and 1 column:
| headquarters         |
| -------------------- |
| Stockholm (wd:Q1754) |

[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] where is electrolux based?

[Assistant]
To determine where Electrolux is based, I need to find the headquarters or location of the company Electrolux in the knowledge graph.

Step 1: Search for the entity "Electrolux" to identify its Wikidata identifier.

Question: Electrolux

Top 10 entity alternatives:
1. Electrolux (wd:Q505922), also known as AB Electrolux: Swedish multinational manufacturer and marketer of home appliances / Swedish multinational manufacturer and marketer of home appliances / a multinational appliance manufacturer / a multinational appliance manufacturer / is instance of public company / is instance of enterprise / is instance of business
2. Electrolux (wd:Q2923843): is instance of taxon / genus of fishes
3. ELECTROLUX (wd:Q58218446), also known as ELECTROLUX, s.r.o.: is instance of enterprise / is instance of business / Czech company
4. Electrolux addisoni (wd:Q2387882): is subclass of electric fish / is instance of taxon / species of fish
5. Electrolux Assistent (wd:Q17496378), also known as Electrolux Ankarsrum Assistent: stand mixer introduced by Electrolux in 1940 / is instance of mixer
6. Electrolux Trilobite (wd:Q5358060): first commercially available robotic vacuum cleaner / is subclass of robotic vacuum cleaner
7. Electrolux (Italy) (wd:Q106045223), also known as Electrolux Italia S.p.A., Electrolux Rex: is instance of public company / is instance of enterprise / is instance of business
8. Electrolux Professional (wd:Q109974149): Swedish professional appliance manufacturer / is instance of company
9. Lux Norge AS (wd:Q15729564, matched via Electrolux AS), also known as Electrolux AS, Electrolux-Euroclean AS, Electrolux Rengjøringsmaskiner AS: is instance of business
10. Electrolux F.C. (wd:Q96377107): is instance of association football club / is instance of soccer club / football club

[Assistant]
The primary entity for Electrolux is "Electrolux (wd:Q505922)", which is described as a Swedish multinational manufacturer and marketer of home appliances. This is the most relevant entity for our purpose.

Step 2: Investigate the properties of Electrolux (wd:Q505922) to find its headquarters or location. I will use the `list` function to examine its triples and look for relevant properties such as headquarters (P159) or country (P17).

list

wd:Q505922

[Assistant]
The headquarters of Electrolux is located in Stockholm (wd:Q1754).

Step 3: To confirm the location, I will check the label for Stockholm to ensure it is correctly identified as a city in Sweden.

wd:Q1754

Got 268 rows and 3 columns, showing the first 10 rows below:
| subject              | property   | object                   |
| -------------------- | ---------- | ------------------------ |
| Stockholm (wd:Q1754) | rdfs:label | Estocolm (lang:ca)       |
| Stockholm (wd:Q1754) | rdfs:label | Estocòlme (lang:oc)      |
| Stockholm (wd:Q1754) | rdfs:label | Estocolmo (lang:an)      |
| Stockholm (wd:Q1754) | rdfs:label | Estocolmo (lang:cbk-zam) |
| Stockholm (wd:Q1754) | rdfs:label | Estocolmo (lang:es)      |
| Stockholm (wd:Q1754) | rdfs:label | Estocolmo (lang:gl)      |
| Stockholm (wd:Q1754) | rdfs:label | Estocolmo (lang:nah)     |
| Stockholm (wd:Q1754) | rdfs:label | Estocolmo (lang:pt)      |
| Stockholm (wd:Q1754) | rdfs:label | Estocolmo (lang:pt-br)   |
| Stockholm (wd:Q1754) | rdfs:label | Estocolmu (lang:ast)     |
| ...                  | ...        | ...                      |

[Assistant]
The label for Stockholm (wd:Q1754) includes "Stockholm" in English, confirming it is the correct entity. Since the headquarters of Electrolux is in Stockholm, and Stockholm is the capital of Sweden, Electrolux is based in Sweden.

Final SPARQL query to directly retrieve the headquarters location of Electrolux in English:

execute

SELECT ?headquarters WHERE { wd:Q505922 wdt:P159 ?headquarters . ?headquarters rdfs:label ?label FILTER(LANG(?label) = "en") }

Got 1 row and 1 column:
| headquarters         |
| -------------------- |
| Stockholm (wd:Q1754) |

[Assistant]
Electrolux is based in Stockholm, Sweden. The SPARQL query successfully retrieved the headquarters location of Electrolux as Stockholm.

Final answer:

answer

SELECT ?headquarters WHERE { wd:Q505922 wdt:P159 ?headquarters . ?headquarters rdfs:label ?label FILTER(LANG(?label) = "en") }

Answer: Electrolux is based in Stockholm, Sweden.


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

Using entities:
- Azle (wd:Q793929), also known as Azle, Texas, Azle, TX: is instance of city in the United States / is instance of city of the United States / city in Texas, 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 |
| ------- |
| 76020   |

Answer:
The ZIP code for Azle, Texas is **76020**.

### Final Answer:
The SPARQL query successfully retrieved the ZIP code for Azle, Texas.

```sparql
SELECT ?zipCode WHERE { wd:Q793929 wdt:P281 ?zipCode }
```

**Answer:** The ZIP code for Azle, Texas is 76020.

The ZIP code for Azle, Texas is **76020**.

### Final Answer:
The SPARQL query successfully retrieved the ZIP code for Azle, Texas.

```sparql
SELECT ?zipCode WHERE { wd:Q793929 wdt:P281 ?zipCode }
```

**Answer:** The ZIP code for Azle, Texas is 76020.

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

Using entities:
- Azle (wd:Q793929), also known as Azle, Texas, Azle, TX: is instance of city in the United States / is instance of city of the United States / city in Texas, 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 |
| ------- |
| 76020   |

[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 the zip code for azle texas?

[Assistant]
To find the ZIP code for Azle, Texas, I need to determine the correct entity for Azle, Texas, and then find its ZIP code property.

### Step 1: Search for the entity "Azle, Texas"
I will first search for the entity "Azle, Texas" in Wikidata to identify its QID.

Question: Azle Texas

Top 10 entity alternatives:
1. Azle (wd:Q793929, matched via Azle, Texas), also known as Azle, Texas, Azle, TX: is instance of city of the United States / is instance of city in the United States / city in Texas, United States
2. Texas Health Resources Azle heliport (wd:Q61719753): heliport in Texas, United States / is instance of heliport
3. Causal factors for seismicity near Azle, Texas (wd:Q35541092): scientific article published on 21 April 2015 / scientific article published on 21 April 2015 / scientific article published on 21 April 2015 / is instance of scholarly article / is instance of academic article
4. Texas (wd:Q1439), also known as Lone Star State, State of Texas, Tex., Texas, United States, TX, etc.: is instance of state of the United States / state of the United States of America / state of the United States of America / state of the United States of America / is instance of U.S. state
5. Houston (wd:Q16555, matched via Houston, Texas), also known as City of Houston, Houston, Texas, Houston TX, Houston, TX, H-Town, etc.: is instance of city of the United States / is instance of city in the United States / city in Texas, United States / is instance of county seat / is instance of big city
6. Dallas (wd:Q16557, matched via Dallas, Texas), also known as Big D, Dallas, Texas, Dallas TX, Dallas, TX, Dallas, TX., etc.: city in the state of Texas, United States / is instance of city in the United States / is instance of city of the United States / city in Texas, United States of America / city in Texas, United States of America / is instance of big city
7. Austin (wd:Q16559, matched via Austin, Texas), also known as Austin, Texas, Austin, TX: city in and county seat of Travis County, Texas, United States, that is also the capital of the State of Texas / capital city of Texas, United States of America / 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
8. Arlington (wd:Q17943, matched via Arlington, Texas), also known as Arlington, Texas, Arlington, TX: is instance of city of the United States / is instance of city in the United States / suburban city in Texas, United States / suburban city in Texas, United States / suburban city in Texas, United States / is instance of big city / is instance of suburb
9. Plano (wd:Q51689, matched via Plano, Texas), also known as Plano, Texas, Plano, TX: city in Collin and Denton counties in Texas, United States / is instance of city of the United States / is instance of city in the United States / is instance of big city / city in Texas
10. Lubbock (wd:Q49273, matched via Lubbock, Texas), also known as Lubbock, Texas, Lubbock, TX: county seat of Lubbock County, Texas, United States / is instance of city of the United States / is instance of city in the United States / is instance of big city / city in Texas

[Assistant]
The top result for "Azle, Texas" is `wd:Q793929`, which is correctly identified as the city of Azle in Texas, United States. Now I will check what properties are associated with this entity, particularly looking for a ZIP code property.

### Step 2: Search for properties related to ZIP code for Azle, Texas
I will use `search_property_of_entity` to find properties related to "ZIP code" for Azle.

Question: ZIP code

Top 10 property alternatives:
1. postal code (wd:P281 as p/wdt, 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. local dialing code (wd:P473 as p/wdt, 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
3. UN/LOCODE (wd:P1937 as p/wdt, matched via UN location code), also known as LOCCODE, LOCODE, UNECE location code, UNECE LOCODE, United Nations location code, etc.: geographic location code maintained by UNECE / geographic location code mantained by UNECE
4. located in the administrative territorial entity (wd:P131 as p/wdt, matched via town), also known as administrative territorial entity, administrative territory, city, happens in, in, etc.: the item is located on the territory of the following ... the item falls only partially into the administrative entity. / the item is located on the territory of the following ... the item falls only partially into the administrative entity. / the item is located on the territory of the following administrative entity / the item is located on the territory of the following administrative entity / is subproperty of location / is subproperty of part of
5. coordinate location (wd:P625 as p/wdt, matched via location), also known as co-ordinate location, co-ordinates, coordinates, co-ords, coords, etc.: geocoordinates of the subject. For Earth, please note that only WGS84 coordinating system is supported at the moment / coordinates of the subject / coordinates of the subject
6. GeoNames ID (wd:P1566 as p/wdt/wdtn, matched via GeoNames), also known as GeoNames, Geonames Id, P1566: identifier in the GeoNames geographical database / identifier in the GeoNames geographical database / identifier in the GeoNames geographical database
7. FIPS 55-3 (locations in the US) (wd:P774 as p/wdt), also known as Federal Information Processing Standard 55-3, FIPS 55-3, fips code for US locations, P774: identifier for places in the United States per former Federal Information Processing Standard FIPS 55-3 / identification code for geographic objects in the US / identification code for geographic objects in the US
8. Library of Congress authority ID (wd:P244 as p/wdt/wdtn, matched via LOC ID), also known as Authority LCCN, LCAuth ID, LCAuth identifier, LCCN, LCCN (LCSH), etc.: Library of Congress name authority (persons, families, ... by 8-10 digits (see regex). For manifestations, use P1144] / Library of Congress ID for authority control for persons and organisations (for books use P1144) / Library of Congress control number for a name or subject authority record
9. GNIS Feature ID (wd:P590 as p/wdt/wdtn, matched via Geographic Names Information System ID), also known as Geographic Names Information System ID, GNIS ID, USGS GNIS ID, P590: identifier for geographic objects in the United States issued by the USGS. For Antarctica, use Property:P804 / identifier for geographic objects in the US issued by the USGS. For Antarctica, use Property:P804 / identifier for geographic objects in the US issued by the USGS. For Antarctica, use Property:P804
10. social media followers (wd:P8687 as p/wdt, matched via sub number), also known as follow count, follower count, follower number, followers, follow number, etc.: number of subscribers on a particular social media website ... time" and property for account. For Twitter, use numeric id.

No other items found

[Assistant]
The property `wdt:P281` (postal code) is the correct property for ZIP codes in Wikidata. Now I will retrieve the postal code (ZIP code) for Azle, Texas (`wd:Q793929`) using this property.

### Step 3: Construct and execute a SPARQL query to get the ZIP code for Azle, Texas
I will write a SPARQL query to fetch the postal code (`wdt:P281`) for Azle, Texas.

execute

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

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

[Assistant]
The ZIP code for Azle, Texas is **76020**.

### Final Answer:
The SPARQL query successfully retrieved the ZIP code for Azle, Texas.

```sparql
SELECT ?zipCode WHERE { wd:Q793929 wdt:P281 ?zipCode }
```

**Answer:** The ZIP code for Azle, Texas is 76020.