PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
SELECT ?item ?officialName ?itemLabel_en ?itemLabel_uk WHERE {
  ?item wdt:P1448 ?officialName .
  FILTER ( LANG( ?officialName ) = "uk" && STR( ?officialName ) = "Коломия" ) .
  OPTIONAL {
    ?item rdfs:label ?itemLabel_en FILTER ( LANG( ?itemLabel_en ) = "en" )
  }
  OPTIONAL {
    ?item rdfs:label ?itemLabel_uk FILTER ( LANG( ?itemLabel_uk ) = "uk" )
  }
}
ORDER BY ?item

Using properties:
- official name (wd:P1448 as wdt), also known as be named, complete title, full title, legal name, long name, etc.: is subproperty of name / official name of the subject in its official language(s) / official name of the subject in its official language(s) / official name of the subject in its official language(s)

Answer: The query returns one item: wd:Q52193 — the city Kolomyia (official name in Ukrainian: "Коломия").

The query returns one item: wd:Q52193 — the city Kolomyia (official name in Ukrainian: "Коломия").

SPARQL query over wikidata:
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
SELECT ?item ?officialName ?itemLabel_en ?itemLabel_uk WHERE {
  ?item wdt:P1448 ?officialName .
  FILTER ( LANG( ?officialName ) = "uk" && STR( ?officialName ) = "Коломия" ) .
  OPTIONAL {
    ?item rdfs:label ?itemLabel_en FILTER ( LANG( ?itemLabel_en ) = "en" )
  }
  OPTIONAL {
    ?item rdfs:label ?itemLabel_uk FILTER ( LANG( ?itemLabel_uk ) = "uk" )
  }
}
ORDER BY ?item

Using properties:
- official name (wd:P1448 as wdt), also known as be named, complete title, full title, legal name, long name, etc.: is subproperty of name / official name of the subject in its official language(s) / official name of the subject in its official language(s) / official name of the subject in its official language(s)

Execution result:
Got 1 row and 4 columns:
| item                 | officialName      | itemLabel_en       | itemLabel_uk      |
| -------------------- | ----------------- | ------------------ | ----------------- |
| Kolomyia (wd:Q52193) | Коломия (lang:uk) | Kolomyia (lang:en) | Коломия (lang:uk) |

[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] Which items have the official name "Коломия" in Ukrainian?

[Assistant]
Step 1: I'll search for the Wikidata property that corresponds to "official name" (I will use search_property).

Question: official name

Top 10 property alternatives:
1. native label (wd:P1705 as pr/psn/wdtn/ps/prn/p/pq/pqv/wdt/prv/psv/pqn, matched via official name), also known as autonym, label in official language, label in original language, name in official language, name in original language, etc.: label for the items in their official language (P37) or their original language (P364) / label for the items in their official language (P37) or their original language (P364) / label for the items in their official language (P37) or their original language (P364) / label for the items in their official language  or their original language / is subproperty of name
2. official name (wd:P1448 as pr/psn/wdtn/ps/prn/p/pq/pqv/wdt/prv/psv/pqn), also known as be named, complete title, full title, legal name, long name, etc.: official name of the subject in its official language(s) / official name of the subject in its official language(s) / official name of the subject in its official language(s) / is subproperty of name
3. official website (wd:P856 as pr/psn/wdtn/ps/prn/p/pq/pqv/wdt/prv/psv/pqn, matched via official site), also known as home page, homepage, home page (official), homepage (official), official homepage, etc.: URL of the official page of an item (current or former). ... see the "Hijacked or dead websites" section of the Talk page / is subproperty of URL
4. officialized by (wd:P5194 as pr/psn/wdtn/ps/prn/p/pq/pqv/wdt/prv/psv/pqn, matched via officialised by), also known as made official by, officialised by, P5194: the item which officialized this lexeme
5. given name (wd:P735 as pr/psn/wdtn/ps/prn/p/pq/pqv/wdt/prv/psv/pqn, matched via proper 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
6. official wiki URL (wd:P12203 as pr/psn/wdtn/ps/prn/p/pq/pqv/wdt/prv/psv/pqn, matched via official wiki), also known as official wiki, official wiki website, wiki, wiki URL, wiki website, etc.: URL of the official wiki for the item / is subproperty of URL
7. self-identified name (wd:P12089 as pr/psn/wdtn/ps/prn/p/pq/pqv/wdt/prv/psv/pqn, matched via own name), also known as endonym, internal name, own name, P12089: name by which a group of humans refers to itself (endonym)
8. professional name (wd:P2838 as pr/psn/wdtn/ps/prn/p/pq/pqv/wdt/prv/psv/pqn), also known as P2838: name passed down by generation assumed by a master of a traditional Japanese art or sport such as kabuki or sumo
9. official symbol (wd:P2238 as pr/psn/wdtn/ps/prn/p/pq/pqv/wdt/prv/psv/pqn), also known as emblem, floral emblem, official emblem, official tartan, state tartan, etc.: official symbol of an organisation
10. official language (wd:P37 as pr/psn/wdtn/ps/prn/p/pq/pqv/wdt/prv/psv/pqn), also known as language official, language spoken, speaking, spoken in, P37: language designated as official by this item / language designated as official by this item / language designated as official by this item / language designated as official by this item / is subproperty of language used

[Assistant]
I'll look for objects (values) of property P1448 ("official name") that match the Ukrainian string "Коломия" to discover candidate items. I'll use search_object_of_property constrained to property wdt:P1448 and query "Коломия".

Question: Коломия

Falling back to an unconstrained search on the full search indices due to an error:
Got more than the maximum supported number of object candidates (131,072)

No entity items found

No other items found

No literal items found

[Assistant]
I'll run a SPARQL SELECT query against Wikidata to find items whose wdt:P1448 (official name) is the Ukrainian literal "Коломия". The query will return the item IRI plus English and Ukrainian rdfs:label (if available) and the official name literal. I expect at least the city Kolomyia to appear; this will confirm exact matches. Now I'll execute the query.

execute

SELECT ?item ?itemLabel_en ?itemLabel_uk ?officialName WHERE {
  ?item wdt:P1448 ?officialName .
  FILTER(LANG(?officialName) = "uk" && STR(?officialName) = "Коломия") .
  OPTIONAL { ?item rdfs:label ?itemLabel_en FILTER(LANG(?itemLabel_en) = "en") }
  OPTIONAL { ?item rdfs:label ?itemLabel_uk FILTER(LANG(?itemLabel_uk) = "uk") }
}
ORDER BY ?item

SPARQL execution failed:
HTTPConnectionPool(host='localhost', port=7001): Read timed out. (read timeout=30)

[Assistant]
The previous query timed out; I'll retry with a simpler query that selects only the item IRIs (and limits results) to reduce load and avoid the timeout.

SELECT ?item WHERE {
  ?item wdt:P1448 ?officialName .
  FILTER(LANG(?officialName) = "uk" && STR(?officialName) = "")
} LIMIT 100

[Assistant]
I made a mistake in the previous retry. I'll run the corrected simple query (only item IRIs, with a LIMIT to avoid timeouts).

SELECT ?item WHERE {
  ?item wdt:P1448 ?officialName .
  FILTER(LANG(?officialName) = "uk" && STR(?officialName) = "Коломия")
} LIMIT 100

[Assistant]
I will finalize with a SPARQL query that returns the item IRI(s), the officialName literal, and English/Ukrainian rdfs:labels (optional). The query looks for wdt:P1448 values that equal the Ukrainian string "Коломия". Based on the earlier simple query we found one matching item (wd:Q52193). I'll submit the final query and give the concise answer listing the item(s).

answer

SELECT ?item ?officialName ?itemLabel_en ?itemLabel_uk WHERE {
  ?item wdt:P1448 ?officialName .
  FILTER(LANG(?officialName) = "uk" && STR(?officialName) = "Коломия") .
  OPTIONAL { ?item rdfs:label ?itemLabel_en FILTER(LANG(?itemLabel_en) = "en") }
  OPTIONAL { ?item rdfs:label ?itemLabel_uk FILTER(LANG(?itemLabel_uk) = "uk") }
}
ORDER BY ?item

Answer: The query returns one item: wd:Q52193 — the city Kolomyia (official name in Ukrainian: "Коломия").


PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
SELECT ?secondParent ?secondParentLabel WHERE {
  wd:Q1318441 wdt:P749 ?parent .
  ?parent wdt:P749 ?secondParent .
  OPTIONAL {
    ?secondParent rdfs:label ?secondParentLabel .
    FILTER ( LANG( ?secondParentLabel ) = "en" )
  }
}

Using entities:
- AdMob (wd:Q1318441): is instance of business / mobile advertising company

Using properties:
- parent organization (wd:P749 as wdt), also known as chapter of, has organizational parent, holding, holding company, owned by (company or organisation), etc.: is subproperty of owned by / is subproperty of part of / parent organization of an organization, opposite of subsidiaries (P355)

Answer: I will run the query to find the second-level parent organization of AdMob and then report the result.

I will run the query to find the second-level parent organization of AdMob and then report the result.

SPARQL query over wikidata:
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
SELECT ?secondParent ?secondParentLabel WHERE {
  wd:Q1318441 wdt:P749 ?parent .
  ?parent wdt:P749 ?secondParent .
  OPTIONAL {
    ?secondParent rdfs:label ?secondParentLabel .
    FILTER ( LANG( ?secondParentLabel ) = "en" )
  }
}

Using entities:
- AdMob (wd:Q1318441): is instance of business / mobile advertising company

Using properties:
- parent organization (wd:P749 as wdt), also known as chapter of, has organizational parent, holding, holding company, owned by (company or organisation), etc.: is subproperty of owned by / is subproperty of part of / parent organization of an organization, opposite of subsidiaries (P355)

Execution result:
Got 1 row and 2 columns:
| secondParent                 | secondParentLabel       |
| ---------------------------- | ----------------------- |
| Alphabet Inc. (wd:Q20800404) | Alphabet Inc. (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 the second-level parent organization of AdMob, the mobile advertising company?

[Assistant]
Step 1 — I will search Wikidata for the entity for "AdMob" to get its QID and check relevant parent/ownership properties (parent organization P749 and owned by P127). I'll first search for the AdMob item.

Question: AdMob

Top 10 entity alternatives:
1. AdMob (wd:Q1318441): mobile advertising company / is instance of business

[Assistant]
I'll list triples for the AdMob item to find properties indicating its parent or owner (e.g., P749 parent organization, P127 owned by). I'll request triples for wd:Q1318441.

list

wd:Q1318441

Got 168 rows and 3 columns, showing the first 10 rows below:
| subject             | property                           | object                              |
| ------------------- | ---------------------------------- | ----------------------------------- |
| AdMob (wd:Q1318441) | instance of (wdt:P31)              | business (wd:Q4830453)              |
| AdMob (wd:Q1318441) | country (wdt:P17)                  | United States (wd:Q30)              |
| AdMob (wd:Q1318441) | Commons category (wdt:P373)        | AdMob                               |
| AdMob (wd:Q1318441) | Freebase ID (wdt:P646)             | /m/02k7816                          |
| AdMob (wd:Q1318441) | inception (wdt:P571)               | 2006-01-01T00:00:00Z (xsd:dateTime) |
| AdMob (wd:Q1318441) | official website (wdt:P856)        | <http://www.google.com/admob/>      |
| AdMob (wd:Q1318441) | headquarters location (wdt:P159)   | Mountain View (wd:Q486860)          |
| AdMob (wd:Q1318441) | social media followers (wdt:P8687) | 81321 (xsd:decimal)                 |
| AdMob (wd:Q1318441) | legal form (wdt:P1454)             | subsidiary (wd:Q658255)             |
| AdMob (wd:Q1318441) | X (Twitter) username (wdt:P2002)   | GoogleAdmob                         |
| ...                 | ...                                | ...                                 |

[Assistant]
I'll check specifically for owned by (P127) and parent organization (P749) statements for AdMob.

wd:Q1318441

[Assistant]
Now checking for parent organization (P749) on the AdMob item.

wd:Q1318441

[Assistant]
AdMob's parent organization is Google (wd:Q95). Next I'll check Google for its parent organization (the second-level parent of AdMob). I'll list Google (wd:Q95) for P749.

wd:Q95

[Assistant]
I'll run a SPARQL query that follows the parent-organization chain two steps: AdMob (wd:Q1318441) -> parent (wdt:P749) -> parent (wdt:P749) and return the second-level parent's IRI and English label. Then I'll provide the answer.

answer

PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?secondParent ?secondParentLabel WHERE {
  wd:Q1318441 wdt:P749 ?parent .
  ?parent wdt:P749 ?secondParent .
  OPTIONAL { ?secondParent rdfs:label ?secondParentLabel . FILTER(LANG(?secondParentLabel) = "en") }
}

Answer: I will run the query to find the second-level parent organization of AdMob and then report the result.


PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
SELECT DISTINCT ?occ ?occLabel ?sub ?subLabel WHERE {
  ?occ wdt:P279 * wd:Q639669 .
  FILTER EXISTS {
    ?person wdt:P106 ?occ .
    ?person wdt:P31 wd:Q5
  }
  OPTIONAL {
    ?occ rdfs:label ?occLabel FILTER ( LANG( ?occLabel ) = "en" )
  }
  OPTIONAL {
    ?sub wdt:P279 ?occ .
    ?sub rdfs:label ?subLabel
    FILTER ( LANG( ?subLabel ) = "en" )
  }
}
ORDER BY ?occLabel ?subLabel

Using entities:
- human (wd:Q5), also known as human being, humans, individual Homo sapiens, individual human, modern humans, etc.: is instance of class of organisms known by one particular common name / is instance of organisms known by a particular common name / is subclass of mammal / is subclass of natural person / is subclass of omnivore / is subclass of person / is subclass of individual animal / any member of Homo sapiens, unique extant species of the genus Homo / common name of Homo sapiens, unique extant species of the genus Homo / common name of Homo sapiens, unique extant species of the genus Homo / common name of Homo sapiens, unique extant species of the genus Homo, from embryo to adult
- musician (wd:Q639669), also known as musical artist: is instance of occupation / is instance of musical profession / is subclass of artist / person who composes, conducts or performs music

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)
- subclass of (wd:P279 as wdt), also known as all members of this class also belong to, category of, form of, has superclass, is a class of, etc.: this item is a subclass (subset) of that item; ALL instances ... of volcanic landform); Everest is an instance of mountain / this item is a subclass (subset) of that item; all instances ... instance of volcanic landform); K2 is an instance of mountain / this item is a subclass (subset) of that item; all instances ... instance of volcanic landform); K2 is an instance of mountain / this item is a subclass (subset) of that item; all instances ... instance of volcanic landform); K2 is an instance of mountain
- instance of (wd:P31 as wdt), also known as example of, has type, is a, is an, is of type, etc.: that class of which this subject is a particular example and ... a subclass of mountain (and an instance of volcanic landform) / type to which this subject corresponds/belongs. Different ... and the volcano is a type (instance) of volcanic landform

Answer:
Summary of results
- Anchor used: wd:Q639669 (musician).
- Query result: 481 distinct occupations that are subclasses (direct or indirect) of "musician" and that are used as occupations (P106) for humans. The query also returned direct subclasses (1,126 occ–sub pairs in total).

What the query returns
- For each occupation (?occ) related to the musical profession, the query returns the occupation IRI (e.g., wd:Q2396920), its English label (?occLabel when available), any direct subclass IRI (?sub) and its English label (?subLabel) when available.

How you can use it
- Run the provided SPARQL on the Wikidata endpoint to get the full list of occupation IRIs and labels and their direct subclasses. You can adapt the query if you want only labels, filter by particular keywords, or include indirect subclasses by changing the P279 usage on the subclass side.

If you'd like, I can:
- Return the full list of occupation labels (and subclasses) as plain text here,
- Restrict results to only occupations containing certain keywords (e.g., "composer", "singer"), or
- Expand to include occupations whose labels contain music-related terms (not only subclasses of musician).

SPARQL returned by the final query (above).

Summary of results
- Anchor used: wd:Q639669 (musician).
- Query result: 481 distinct occupations that are subclasses (direct or indirect) of "musician" and that are used as occupations (P106) for humans. The query also returned direct subclasses (1,126 occ–sub pairs in total).

What the query returns
- For each occupation (?occ) related to the musical profession, the query returns the occupation IRI (e.g., wd:Q2396920), its English label (?occLabel when available), any direct subclass IRI (?sub) and its English label (?subLabel) when available.

How you can use it
- Run the provided SPARQL on the Wikidata endpoint to get the full list of occupation IRIs and labels and their direct subclasses. You can adapt the query if you want only labels, filter by particular keywords, or include indirect subclasses by changing the P279 usage on the subclass side.

If you'd like, I can:
- Return the full list of occupation labels (and subclasses) as plain text here,
- Restrict results to only occupations containing certain keywords (e.g., "composer", "singer"), or
- Expand to include occupations whose labels contain music-related terms (not only subclasses of musician).

SPARQL returned by the final query (above).

SPARQL query over wikidata:
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
SELECT DISTINCT ?occ ?occLabel ?sub ?subLabel WHERE {
  ?occ wdt:P279 * wd:Q639669 .
  FILTER EXISTS {
    ?person wdt:P106 ?occ .
    ?person wdt:P31 wd:Q5
  }
  OPTIONAL {
    ?occ rdfs:label ?occLabel FILTER ( LANG( ?occLabel ) = "en" )
  }
  OPTIONAL {
    ?sub wdt:P279 ?occ .
    ?sub rdfs:label ?subLabel
    FILTER ( LANG( ?subLabel ) = "en" )
  }
}
ORDER BY ?occLabel ?subLabel

Using entities:
- human (wd:Q5), also known as human being, humans, individual Homo sapiens, individual human, modern humans, etc.: is instance of class of organisms known by one particular common name / is instance of organisms known by a particular common name / is subclass of mammal / is subclass of natural person / is subclass of omnivore / is subclass of person / is subclass of individual animal / any member of Homo sapiens, unique extant species of the genus Homo / common name of Homo sapiens, unique extant species of the genus Homo / common name of Homo sapiens, unique extant species of the genus Homo / common name of Homo sapiens, unique extant species of the genus Homo, from embryo to adult
- musician (wd:Q639669), also known as musical artist: is instance of occupation / is instance of musical profession / is subclass of artist / person who composes, conducts or performs music

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)
- subclass of (wd:P279 as wdt), also known as all members of this class also belong to, category of, form of, has superclass, is a class of, etc.: this item is a subclass (subset) of that item; ALL instances ... of volcanic landform); Everest is an instance of mountain / this item is a subclass (subset) of that item; all instances ... instance of volcanic landform); K2 is an instance of mountain / this item is a subclass (subset) of that item; all instances ... instance of volcanic landform); K2 is an instance of mountain / this item is a subclass (subset) of that item; all instances ... instance of volcanic landform); K2 is an instance of mountain
- instance of (wd:P31 as wdt), also known as example of, has type, is a, is an, is of type, etc.: that class of which this subject is a particular example and ... a subclass of mountain (and an instance of volcanic landform) / type to which this subject corresponds/belongs. Different ... and the volcano is a type (instance) of volcanic landform

Execution result:
Got 1,126 rows and 4 columns, showing the first 5 and last 5 rows below:
| occ                          | occLabel                 | sub | subLabel |
| ---------------------------- | ------------------------ | --- | -------- |
| wd:Q117973670                |                          |     |          |
| wd:Q11787407                 |                          |     |          |
| wd:Q121083305                |                          |     |          |
| wd:Q100707292                |                          |     |          |
| wd:Q102315983                |                          |     |          |
| ...                          | ...                      | ... | ...      |
| worship leader (wd:Q2396920) | worship leader (lang:en) |     |          |
| xylophonist (wd:Q66370835)   | xylophonist (lang:en)    |     |          |
| yodeler (wd:Q21234378)       | yodeler (lang:en)        |     |          |
| yoiker (wd:Q78152520)        | yoiker (lang:en)         |     |          |
| zitherist (wd:Q55977806)     | zitherist (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 are the distinct occupations related to the musical profession, along with their subclasses (if available)?

[Assistant]
I will first search for the Wikidata item for "musician" to use as an anchor, then look for occupations that are subclasses of it or whose labels contain music-related keywords. I'll explain each step and run queries to verify IDs before composing the final SPARQL. I'll start by searching for "musician".

Question: musician

Top 10 entity alternatives:
1. musician (wd:Q639669), also known as musical artist: person who composes, conducts or performs music / is instance of musical profession / is instance of occupation / is subclass of artist
2. Musician (wd:Q6942594): monthly magazine that covered news and information about American popular music / is instance of music magazine
3. Musician (wd:Q108502747): 2021 single by Porter Robinson / is instance of single
4. Dj Faith India (wd:Q122975649, matched via Musician), also known as Musician: has occupation musician / is instance of human / Musical Artist
5. Micha Liberman (wd:Q133530738, matched via Musician), also known as Musician: American music editor and composer / has occupation composer / is instance of human
6. Musician (wd:Q6942592): occupational rating in the United States Navy / is subclass of musician
7. Musician (wd:Q6942591): video game for the Philips Videopac / is instance of video game / 1980 video game / 1980 video game
8. Musician (wd:Q6942593), also known as Mus: rank equivalent to Private held by members of the Corps of Army Music of the British Army and the Royal Marines Band Service / is instance of military rank / is instance of Military rank
9. musician (wd:Q123476624), also known as P428.: narrative motif documented in Thompson's Motif-Index of Folk-Literature / is instance of narrative motif / is instance of folklore motif / is instance of Motif / is instance of motif
10. Musician (wd:Q120661984): Gouache on paper; Mughal painting; 1612 CE; in the Indian Museum, Kolkata / is instance of painting

[Assistant]
I'll run a SPARQL query that:
- uses wd:Q639669 (musician) as the anchor,
- finds occupations that are subclasses of musician OR whose English labels contain common music-related keywords,
- ensures each occupation is actually used as an occupation (P106) for at least one human,
- returns each occupation's IRI and English label plus any direct subclasses (P279) and their English labels.

I'll execute this query now to verify item identifiers and get results.

execute

SELECT DISTINCT ?occ ?occLabel ?sub ?subLabel WHERE {
  {
    ?occ wdt:P279* wd:Q639669 .
  } UNION {
    ?occ rdfs:label ?occLabel0 FILTER(LANG(?occLabel0) = "en") .
    FILTER(
      CONTAINS(LCASE(?occLabel0), "music") ||
      CONTAINS(LCASE(?occLabel0), "musician") ||
      CONTAINS(LCASE(?occLabel0), "singer") ||
      CONTAINS(LCASE(?occLabel0), "composer") ||
      CONTAINS(LCASE(?occLabel0), "conductor") ||
      CONTAINS(LCASE(?occLabel0), "songwriter") ||
      CONTAINS(LCASE(?occLabel0), "instrumentalist") ||
      CONTAINS(LCASE(?occLabel0), "musicologist") ||
      CONTAINS(LCASE(?occLabel0), "music producer") ||
      CONTAINS(LCASE(?occLabel0), "music director")
    )
    BIND(?occLabel0 AS ?occLabel)
  }

  FILTER EXISTS { ?person wdt:P106 ?occ . ?person wdt:P31 wd:Q5 }

  OPTIONAL {
    ?sub wdt:P279 ?occ .
    ?sub rdfs:label ?subLabel FILTER(LANG(?subLabel) = "en")
  }

  OPTIONAL { ?occ rdfs:label ?occLabel FILTER(LANG(?occLabel) = "en") }
}
ORDER BY ?occLabel ?subLabel

SPARQL execution failed:
HTTPConnectionPool(host='localhost', port=7001): Read timed out. (read timeout=30)

[Assistant]
I'll try a narrower query first: list occupations that are subclasses (direct or indirect) of wd:Q639669 (musician) and are actually used as occupation (P106) for humans. This reduces workload and avoids long unions. I'll run that query now.

SELECT DISTINCT ?occ ?occLabel WHERE {
  ?occ wdt:P279* wd:Q639669 .
  FILTER EXISTS { ?person wdt:P106 ?occ . ?person wdt:P31 wd:Q5 }
  OPTIONAL { ?occ rdfs:label ?occLabel FILTER(LANG(?occLabel) = "en") }
}
ORDER BY ?occLabel

[Assistant]
I'll now query the subclasses (direct P279 children) for each occupation found above, returning occupation IRIs and labels plus any subclass IRIs and labels.

SELECT DISTINCT ?occ ?occLabel ?sub ?subLabel WHERE {
  ?occ wdt:P279* wd:Q639669 .
  FILTER EXISTS { ?person wdt:P106 ?occ . ?person wdt:P31 wd:Q5 }
  OPTIONAL { ?occ rdfs:label ?occLabel FILTER(LANG(?occLabel) = "en") }
  OPTIONAL { ?sub wdt:P279 ?occ . ?sub rdfs:label ?subLabel FILTER(LANG(?subLabel) = "en") }
}
ORDER BY ?occLabel ?subLabel

[Assistant]
After the initial searches and queries I used wd:Q639669 (musician) as the anchor. I ran a query that finds occupations that are subclasses (direct or indirect) of musician and that are used as occupations (P106) for humans, and returns each occupation together with any direct subclasses (P279). The query returned 481 distinct occupations (and 1,126 occ–sub pairs including subclasses). I will now provide the final SPARQL query and a short summary of the results.

answer

SELECT DISTINCT ?occ ?occLabel ?sub ?subLabel WHERE {
  ?occ wdt:P279* wd:Q639669 .
  FILTER EXISTS { ?person wdt:P106 ?occ . ?person wdt:P31 wd:Q5 }
  OPTIONAL { ?occ rdfs:label ?occLabel FILTER(LANG(?occLabel) = "en") }
  OPTIONAL { ?sub wdt:P279 ?occ . ?sub rdfs:label ?subLabel FILTER(LANG(?subLabel) = "en") }
}
ORDER BY ?occLabel ?subLabel

Answer:
Summary of results
- Anchor used: wd:Q639669 (musician).
- Query result: 481 distinct occupations that are subclasses (direct or indirect) of "musician" and that are used as occupations (P106) for humans. The query also returned direct subclasses (1,126 occ–sub pairs in total).

What the query returns
- For each occupation (?occ) related to the musical profession, the query returns the occupation IRI (e.g., wd:Q2396920), its English label (?occLabel when available), any direct subclass IRI (?sub) and its English label (?subLabel) when available.

How you can use it
- Run the provided SPARQL on the Wikidata endpoint to get the full list of occupation IRIs and labels and their direct subclasses. You can adapt the query if you want only labels, filter by particular keywords, or include indirect subclasses by changing the P279 usage on the subclass side.

If you'd like, I can:
- Return the full list of occupation labels (and subclasses) as plain text here,
- Restrict results to only occupations containing certain keywords (e.g., "composer", "singer"), or
- Expand to include occupations whose labels contain music-related terms (not only subclasses of musician).

SPARQL returned by the final query (above).