Semantic Web Question Answering with SPARQL and Large Language Models

The Resource Description Framework (RDF) is the data model that underpins the Semantic Web. In RDF, every fact is expressed as a triple of subject, predicate, and object, where the subject and object are nodes in a graph and the predicate is a typed, named edge. Because every entity and every relationship is identified by a globally unique URI, data published by different organizations can be merged into a single shared graph without ambiguity. This graph-based foundation is what distinguishes RDF from ordinary tables or JSON documents: relationships are first-class citizens, and any two datasets that share a URI can be joined seamlessly.

One of the great advantages of RDF is that several large knowledge bases are published as public SPARQL endpoints, meaning anyone with an HTTP client can query them free of charge and without registration. DBpedia exposes http://dbpedia.org/sparql, and Wikidata exposes https://query.wikidata.org/sparql; both return results in the same standardized JSON format, so the same client code can talk to either endpoint. This means that a developer can, in a handful of lines of Python, ask structured questions about millions of people, places, organizations, and concepts curated by the Wikipedia and Wikimedia communities with no API keys, no licensing fees, and no local data storage required.

Public SPARQL endpoints also compose naturally. Because DBpedia and Wikidata both speak SPARQL and both model their data as RDF, a program can query both endpoints for the same entities and merge the results into a single context for downstream processing. Each source contributes different strengths: DBpedia carries richer infobox-derived product lists and financial figures, while Wikidata provides more comprehensive subsidiary and leadership relationships—so combining them yields a fuller picture than either alone. The remainder of this chapter shows exactly how to build such a system, pairing these public endpoints with a large language model that turns structured triples into natural-language answers.

Before we dig into the example code implementation, let us see what the finished programs actually do. We have three scripts that all answer the same question but draw on different knowledge bases.

That last example is the key insight of this chapter: because both DBpedia and Wikidata use the same RDF data model, a client program can query both and merge the results. The LLM then synthesizes a single answer that draws on the strengths of each source.

The code in this directory is split across four files:

Each of the three example scripts implements the same four-stage pipeline:

1. Entity extraction - An LLM identifies named entities in the question and classifies them by type (person, organization, place, or misc).
2. Relationship detection - A keyword-matching layer checks whether the question asks about a specific relationship such as “capital of” or “married to.”
3. SPARQL retrieval - The program constructs and executes SPARQL queries against one or more knowledge bases, gathering descriptions and structured facts.
4. Answer synthesis - An LLM synthesizes the retrieved facts into a natural-language answer.

The shared library.py handles the parts that are identical across all three scripts: the Fireworks.ai LLM client, the entity-extraction prompt, the answer-synthesis prompt, and the SPARQL HTTP transport. The KB-specific scripts handle the parts that differ: SPARQL query templates, property mappings, and enrichment logic.

The Resource Description Framework (RDF) is the data model underlying the Semantic Web. In RDF, every piece of knowledge is a triple:

The subject and object are nodes in a graph (entities), and the predicate is a typed edge (a relationship). For example, the statement “Paris is the capital of France” becomes the triple:

Each URI is a globally unique identifier. The predicate URI http://dbpedia.org/ontology/capital is not just a label; it is a defined property in the DBpedia ontology with a documented meaning. Because every entity and every relationship has a URI, data from different sources can be merged unambiguously into a single graph.

DBpedia is a community project that extracts structured data from Wikipedia infoboxes. It uses human-readable URIs like http://dbpedia.org/resource/IBM for entities and http://dbpedia.org/ontology/foundingDate for properties. The DBpedia ontology defines classes (Person, Organisation, Place) and properties (birthDate, foundedBy, capital) in a way that mirrors common-sense categories.

Wikidata is the structured-data sister project of Wikipedia, maintained by the Wikimedia Foundation. It uses opaque identifiers: entities are Q-numbers (Q2283 for Microsoft) and properties are P-numbers (P159 for headquarters location). This design allows Wikidata to be language-neutral and to support claims with qualifiers, references, and ranks, but it makes queries less readable without label resolution.

Both knowledge bases expose public SPARQL endpoints:

Because both speak SPARQL and return results in the same JSON format, the same client code can query either one.

Objects in RDF triples can be URIs (links to other entities) or literals (plain values such as strings, numbers, or dates). String literals can carry a language tag. For example, the short description of IBM in DBpedia is stored as:

The @en suffix marks the string as English. Both DBpedia and Wikidata contain descriptions in many languages, so SPARQL queries almost always include a language filter to avoid mixing languages in the results.

SPARQL (SPARQL Protocol and RDF Query Language) is the standard query language for RDF graphs. A SPARQL query matches graph patterns using variables prefixed with ?. Here is a minimal example that finds the English label of any entity whose capital is France:

The SELECT clause lists which variables to return. The block inside { } is the graph pattern: one or more triple patterns that the data must match. The FILTER function constrains results, in this case requiring the label to be in English.

The queries in these scripts use several SPARQL features worth understanding:

VALUES enumerates a set of allowed values for a variable. Instead of writing three separate triple patterns for three predicates, we write one pattern and constrain the predicate variable:

A powerful variant uses two-variable VALUES to pair a URI with a literal label in each row. The enrichment queries use this to carry a human-readable property name alongside each property URI:

When the query matches a triple ?s dbo:foundingDate ?obj, the variable ?propLabel is automatically bound to the string "foundingDate".

OPTIONAL specifies a pattern that may or may not match. If the optional pattern fails, the rest of the query still returns results, with the optional variables unbound. We use this so that an rdf:type constraint does not eliminate entities whose type does not perfectly match our expectation.

FILTER applies a boolean condition to each candidate row. We use it for language filtering (lang(?comment) = 'en'), for excluding Wikipedia category pages (!CONTAINS(STR(?s), 'dbpedia.org/resource/Category:')), and for requiring URI-valued objects (isURI(?obj)).

ORDER BY sorts results. We sort by ?p so that the preferred predicate (the full abstract) appears first in the results, and the shorter description fields come later as fallback.

LIMIT caps the number of rows returned, which keeps queries fast and prevents oversized responses.

Wikidata queries often use the wikibase:label service to resolve Q-numbers to human-readable labels. However, our enrichment queries use a simpler approach: an OPTIONAL block that fetches rdfs:label for each object value. This works with any SPARQL endpoint and does not require Wikidata-specific extensions.

The library.py module contains all the code that is identical across the three example scripts. Let us walk through each piece.

The program uses the OpenAI Python SDK to talk to Fireworks.ai, which provides an OpenAI-compatible API. This means we can use the familiar client.chat.completions.create interface with a different base_url:

The API key is read from the FIREWORKS_API_KEY environment variable. If it is not set, the client receives None, and the first LLM call raises an authentication error. The MODEL_ID constant identifies which model to use; we picked deepseek-v4-flash for its speed and low cost, which matters because the program makes up to three LLM calls per question.

A descriptive User-Agent string is defined so that SPARQL endpoints (especially Wikidata) do not reject our queries as unidentified bot traffic:

Every LLM call in the program follows the same pattern, so we factor it into a single helper:

The temperature=0 default makes the model deterministic, which is important for entity extraction: we want the same question to produce the same entities every time. Callers that want more creative output (such as answer synthesis) can override the temperature.

Natural-language questions mention entities by name: “Bill Gates,” “Paris,” “IBM.” Before we can query any knowledge base, we need to identify these entities and classify them by type. The extract_entities function uses an LLM with a one-shot prompt to do this in a single API call.

A one-shot prompt gives the model one example before asking it to perform the task on new input. This anchors the model on the desired output format:

Several design choices in this prompt are worth noting:

• Role assignment (“You are an expert named-entity recognition system”) primes the model to adopt the persona of a specialist system.
• Explicit type definitions with parenthetical examples prevent the model from guessing what each type means.
• Format constraint (“Return ONLY a JSON object”) tells the model we want structured output, not prose.
• A worked example shows the exact input/output shape, which is more reliable than describing the format abstractly.
• Negative instructions (“No prose, no markdown fences”) anticipate and suppress common failure modes.

The {text} placeholder is replaced with the user’s actual question before the prompt is sent to llm_complete.

Even with instructions to return only JSON, LLMs sometimes wrap their output in markdown code fences. The code handles this with a regex fallback:

The regex r"```(?:json)?\s*(.*?)```" matches a fenced code block with an optional json language tag. re.DOTALL lets . match newlines so the fence can span multiple lines. If a fence is found, we extract its inner content; otherwise we parse the raw string directly.

After parsing, the normalization loop converts single strings to one-element lists (the model might return {"PERSON": "Bill Gates"} instead of {"PERSON": ["Bill Gates"]}) and coerces all names to strings. The broad except clause ensures that a malformed LLM response does not crash the program; it returns an empty dict, and the pipeline continues with no entities.

The synthesize_answer function sends the question and the retrieved context to the LLM, asking it to produce a natural-language answer. It is shared by all three scripts:

The prompt has three parts: the original question, the retrieved knowledge, and instructions on how to answer. The instruction to “address every entity the user asked about” is critical for multi-entity questions like “tell me about IBM, Microsoft.” Without it, the model might focus on only the first entity and ignore the rest.

The source_label parameter lets each script name its source: “DBpedia”, “Wikidata”, or “DBpedia and Wikidata”. The context is truncated to 3000 characters to stay within the model’s context window and control cost.

All SPARQL queries go through a single function that uses the requests library to send the query over HTTP:

The function is endpoint-agnostic: it works with DBpedia, Wikidata, or any other SPARQL 1.1 endpoint that supports JSON results. The User-Agent header is especially important for Wikidata, which rejects requests without one. The format=json query parameter tells the endpoint to return results in the SPARQL 1.1 JSON Results format.

The JSON Results format represents each value as a dict with a type (uri, literal, typed-literal, or bnode) and a value. For literals, an optional xml:lang key carries the language tag. The rest of the code accesses values with patterns like result["comment"]["value"] and result["objLabel"]["value"].

Many questions ask about a specific relationship: “What is the capital of France?” “Where was Bill Gates born?” The detect_relationship function is generic: it takes the question and a caller-supplied mapping table, and returns the matching property URI and verb:

The keys are sorted by descending length so that multi-word phrases are checked before their single-word sub-phrases. Without this, the question “What is the capital of France?” would match “capital” before “capital of,” and while both map to the same URI in this case, the ordering matters for phrases where a shorter key maps to a different property than the longer one.

Both DBpedia and Wikidata return values that can be either literals (dates, numbers) or URIs (links to other entities). The resolve_value helper converts any value to a human-readable string:

If the SPARQL query resolved the object to an English label (via an OPTIONAL block), we use that. Otherwise, if the object is a URI, we extract the last path segment and replace underscores with spaces (for example, Information_technology becomes Information technology). If the object is a literal, we return it directly.

All three scripts use the same command-line interface, provided by run_cli:

The answer_fn parameter is a callable supplied by each script. This is how DBPedia.py, Wikidata.py, and DBPedia_and_Wikidata.py each plug in their own answer pipeline while sharing the same CLI logic.

The DBpedia script defines three SPARQL query templates, a relationship property mapping, an entity-type-to-ontology mapping, and an enrichment property table. Let us walk through each.

The first template finds an entity by its English label and retrieves descriptive text:

Line by line:

• SELECT DISTINCT ?s ?p ?comment returns the subject URI, the predicate used, and the descriptive text.
• ?s rdfs:label '{name}'@en finds entities whose English label matches the name we are looking for.
• FILTER(!CONTAINS(STR(?s), 'dbpedia.org/resource/Category:')) excludes Wikipedia category pages, which carry only the unhelpful label “Wikimedia category.”
• VALUES ?p { ... } lists three predicates to try, in priority order.
• {dbpedia_type} is replaced with an optional rdf:type constraint.
• ORDER BY ?p sorts results so the abstract comes before the shorter comment and description.
• LIMIT 15 caps the result set.

The doubled braces {{ }} are Python str.format escapes; they produce literal braces in the output. The single-brace placeholders {name} and {dbpedia_type} are replaced at runtime.

The template is instantiated by build_sparql_query:

The type clause is wrapped in OPTIONAL deliberately: if we made it a hard requirement, entities whose LLM-assigned type does not exactly match the DBpedia ontology would be missed. For example, “Pepsi” might be tagged as an organization by the LLM but typed as dbo:Beverage in DBpedia. With OPTIONAL, the label match alone is sufficient.

The enrichment template fetches a curated set of property/value pairs in one query:

This uses the two-variable VALUES clause described earlier. Each row pairs a property URI with a human-readable label string. The OPTIONAL block resolves URI-valued objects to their English label.

The ENRICHMENT_PROPERTIES dictionary defines which DBpedia properties to fetch for each entity type:

The properties are chosen to match the kinds of information a person would typically want to know about each entity type. For an organization, that means who founded it, what industry it is in, how many employees it has, and what its revenue is. For a person, that means birth and death dates, occupation, nationality, and spouse. For a place, that means population, area, capital, and leader.

The enrichment function builds the VALUES block from the property table, executes the SPARQL query, and converts the raw results into human-readable fact strings:

The values_block string is built by joining together (<uri> "label") pairs, one per property. For an organization like IBM, this produces a block of sixteen rows. The seen set deduplicates facts, because DBpedia sometimes has multiple labels for the same URI.

The answer_question function in DBPedia.py orchestrates the full pipeline:

If a relationship is detected, the function returns immediately with a direct answer like “The capital of France is: Paris.” This early return is intentional: for relationship questions, the direct SPARQL lookup gives a precise, fast answer. Otherwise, the program builds a context string from DBpedia, asks the LLM to synthesize an answer, and falls back to raw descriptions if the LLM call fails.

The RELATIONSHIP_PROPERTIES dictionary maps English phrases to DBpedia ontology property URIs:

Multiple English phrases can map to the same DBpedia property. Both “capital” and “capital of” point to dbo:capital. This redundancy is intentional: users phrase questions in many ways.

This disambiguates entities with common names. “Washington” could be a person (George Washington) or a place (Washington state). If the LLM tags it as a GPE, the type constraint steers DBpedia toward the geographic entity. For MISC entities, the empty string means the type clause is omitted entirely.

Wikidata uses a different data model from DBpedia. Entities are identified by Q-numbers and properties by P-numbers. This section explains the key differences in the SPARQL templates and query patterns.

The first step in any Wikidata query is to find the Q-number for an entity given its English label. The lookup template filters out disambiguation pages and sorts by ascending Q-number so the most prominent entity comes first:

The BIND clause extracts the numeric part of the Q-number, and ORDER BY xsd:integer(?qnum) sorts results so that Q2283 (Microsoft) comes before Q124998 (a Microsoft brand page). The schema:description predicate gives us the short Wikidata description, which is the equivalent of DBpedia’s dbo:description.

The lookup_entity_qid function executes this query and returns the first non-disambiguation Q-number:

Wikidata enforces stricter rate limits than DBpedia. The _query_wikidata wrapper inserts a delay between queries to avoid HTTP 429 responses:

This is a simple but effective strategy. In a production system you would use exponential backoff on 429 responses, but for an educational example the fixed delay keeps the code simple.

Wikidata’s property system has a meta-model that differs from DBpedia’s. Each direct-claim property (wdt:P159, for “headquarters location”) has a corresponding property entity (wd:P159) whose rdfs:label gives us the human-readable property name. The enrichment template uses this to fetch both the property name and the value in one query:

The VALUES block pairs each direct-claim property with its property entity:

For IBM (Q37156), the VALUES block contains ten pairs like (wdt:P571 wd:P571) (inception), (wdt:P112 wd:P112) (founded by), and so on. The query matches all ten properties in a single round trip.

The enrichment property table for Wikidata uses P-numbers instead of full URIs:

Compare this with the DBpedia enrichment table: the property names are different (DBpedia uses camelCase like foundingDate, Wikidata uses descriptive labels like inception), but the logical coverage is the same. Both tables define which properties to fetch for each entity type.

The relationship mapping for Wikidata uses P-number property IDs instead of full URIs:

The relationship template takes a Q-number and a P-number and fetches the related entity’s label:

This is simpler than the DBpedia relationship template because we already know the entity’s Q-number from the lookup step, so we can use it directly in the wd:{qid} pattern instead of matching by label.

The Wikidata answer pipeline follows the same structure as the DBpedia one, but with an extra step: each entity name must be resolved to a Q-number before any enrichment queries can be issued:

The get_entity_context function for Wikidata resolves each entity name to a Q-number, fetches the short description, and runs the enrichment query:

The context string includes the Q-number alongside the entity name, which helps the LLM (and the reader) understand where the data came from.

The combined script demonstrates one of the most powerful features of the Semantic Web: because both DBpedia and Wikidata use RDF and SPARQL, a client application can query both and merge the results. This is called federation.

The script is remarkably short because it delegates all the work to the two KB-specific modules:

The function calls DBPedia.get_entity_context and Wikidata.get_entity_context with the same entity dict, then concatenates the two context strings with source labels. The LLM sees both blocks of facts and synthesizes an answer that draws on both.

When we look at the combined output, we can see what each knowledge base contributes:

• DBpedia provides richer product and service lists (it extracts from Wikipedia infoboxes, which list products individually), financial figures formatted as typed literals, and the short dbo:description text.
• Wikidata provides more subsidiaries (its P355 property lists child organizations comprehensively), leadership details (current and former chairpersons), and structured industry classifications that are more granular than DBpedia’s.

The LLM synthesis step naturally reconciles overlapping facts. When both sources say IBM was founded on June 16, 1911, the LLM states it once. When Wikidata lists Thomas J. Watson Sr. as a founder but DBpedia does not, the LLM includes him. This is a practical demonstration of how the Semantic Web enables knowledge fusion.

SPARQL supports a SERVICE keyword that lets a single query federate across multiple endpoints:

We do not use SERVICE in this program for two reasons. First, the Wikidata endpoint often blocks federated queries from external endpoints due to rate limiting. Second, our approach of querying each endpoint separately and merging the results in Python gives us more control over error handling and rate limiting. The tradeoff is that we make more HTTP requests, but the SPARQL_DELAY between Wikidata queries keeps us within rate limits.

The project uses uv for dependency management. Install dependencies with:

This reads pyproject.toml and creates a virtual environment with openai and requests.

Set your Fireworks.ai API key as an environment variable:

DBpedia only:

Wikidata only:

Combined DBpedia + Wikidata:

All three scripts also accept relationship queries:

And all three can run in interactive mode (no arguments):

DBPedia.py also provides a chat_with_context function for a conversational interface that maintains message history:

Each turn, the function extracts entities, fetches DBpedia context, and appends both to the message list. The assistant’s reply is appended back, so subsequent turns have access to the full conversation history.

These queries match against the built-in property mapping tables and return direct answers:

These queries go through the full enrichment and LLM synthesis pipeline:

The example outputs shown at the beginning of this chapter are the results of these commands.

FIREWORKS_API_KEY not set - The script passes None to the OpenAI client, which raises an authentication error on the first LLM call. Make sure you have exported the variable in the shell where you run the script.

Wikidata returns HTTP 429 (Too Many Requests) - Wikidata’s public endpoint aggressively rate-limits queries. The SPARQL_DELAY constant in Wikidata.py inserts a pause between queries, but if you still get 429 errors, increase the delay or wait a minute before retrying.

DBpedia SPARQL queries return empty results - DBpedia occasionally changes which predicates are available. The query templates try multiple alternatives (abstract, comment, description), and the enrichment queries use stable dbo: properties. If all fail, wait a few minutes and retry; the public endpoint is sometimes overloaded.

Entity not found - Try the canonical name. For example, use “United States” instead of “America,” and “Bill Gates” instead of “William Gates.”

LLM returns malformed JSON - The entity extraction function has a regex fallback to strip markdown code fences, but if the model returns something that is not JSON at all, the exception handler returns an empty dict and the pipeline continues with no entities. Retrying usually works.

1. Add support for additional relationship keywords (e.g., “nationality”, “child”, “parent”)

   Extend the RELATIONSHIP_PROPERTIES dictionaries in both DBPedia.py and Wikidata.py. Find the appropriate property URIs for DBpedia at https://dbpedia.org/ontology/ and the P-numbers for Wikidata at https://www.wikidata.org/wiki/Wikidata:List_of_properties. Example:

   1 # DBPedia.py
   2 "nationality": ("http://dbpedia.org/ontology/nationality", "nationality"),
   3 # Wikidata.py
   4 "nationality": ("P27", "country of citizenship"),
   

2. Add a new entity type: “PRODUCT”

   Add PRODUCT to the entity extraction prompt in library.py, add a DBpedia type URI and enrichment properties in DBPedia.py, and add Wikidata P-numbers in Wikidata.py. Research DBpedia’s dbo:Product class and Wikidata’s Q2424752 (product) class.

3. Create a caching layer for SPARQL query results

   Implement a simple in-memory cache using Python’s functools.lru_cache or a dictionary keyed by query string. This is especially valuable for the Wikidata script, where rate limiting makes redundant queries expensive. Example:

   1 from functools import lru_cache
   2 
   3 @lru_cache(maxsize=256)
   4 def query_sparql_cached(endpoint: str, sparql_query: str):
   5     return query_sparql(endpoint, sparql_query)
   

4. Modify the combined script to deduplicate overlapping facts

   Currently, DBPedia_and_Wikidata.py passes both context strings to the LLM without deduplication. Implement a Python-side deduplication step that removes facts that appear in both contexts (e.g., “foundingDate: 1911-06-16”). Consider normalizing property labels across the two sources before comparing.

5. Add support for follow-up questions that reference entities from previous answers

   Modify the answer_question functions to track conversation history. Use entity coreference resolution (“it”, “they”) by maintaining a context dictionary of recently mentioned entities. Consider storing entity names with their types and Q-numbers for disambiguation.

6. Handle multi-valued properties in the enrichment layer

   Some DBpedia and Wikidata properties (like product and subsidiary) return many values. Currently each value becomes a separate fact line. Modify enrich_entity in both scripts to group values by property label, producing a single line like subsidiary: Red Hat, Lotus Software, IBM Research, ... instead of multiple subsidiary: Red Hat lines.

7. Add a fourth knowledge base: DBpedia Japanese endpoint or another language

   DBpedia has language-specific endpoints (e.g., http://ja.dbpedia.org/sparql for Japanese). Create a new script that queries a non-English DBpedia endpoint, and modify the entity extraction prompt to detect the question’s language. This exercise explores how the Semantic Web enables multilingual knowledge access.

• DBpedia: https://wiki.dbpedia.org/
• Wikidata: https://www.wikidata.org/wiki/Wikidata:Main_Page
• Wikidata SPARQL query service: https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service
• SPARQL specification: https://www.w3.org/TR/sparql11-query/
• Fireworks.ai API documentation: https://docs.fireworks.ai/
• RDF 1.1 Primer: https://www.w3.org/TR/rdf11-primer/