Qanary — A Methodology for Knowledge-Driven Question Answering Systems

01 — The idea

The Qanary methodology

A knowledge-driven way to design Question Answering systems, where the data flowing through the pipeline — not hard-wired code — connects the parts.

Most Question Answering systems chain together several specialised tasks: recognising named entities, disambiguating them against a knowledge graph, detecting relations, building a formal query, executing it, and selecting an answer. Traditionally each step is wired directly to the next, which makes components hard to swap, compare, or reuse.

Qanary breaks that coupling. Every component reads from and writes to a shared, process-independent knowledge base expressed in RDF and described by a standard vocabulary named qa (the QA ontology). Instead of passing messages to one another, components annotate the question and the evolving QA process in that knowledge graph.

Because every component reads and writes the same published vocabulary rather than a private API, the shared knowledge base — the Qanary triplestore — acts as a global process memory: one place that holds the question, every intermediate result, and the final answer. This is exactly what enables plug-and-play — a component can be added, removed or swapped without rewiring anything, as long as it speaks the qa vocabulary — and it is what makes the process explainable, because the complete reasoning trace stays queryable and you can see precisely what each component contributed.

Many of the available Question Answering components also provide validated, ready-made functionality. Assembling a system from such trusted building blocks makes quality assurance of the overall process much easier: each component is tested on its own, and the shared process memory lets you measure quality at every stage.

This matters most for AI-driven systems. A Question Answering system is an AI system — and as AI takes over ever more of the computation, its building blocks must stay controllable rather than disappear into an opaque black box. With Qanary a system is assembled from components that the user explicitly chooses, orders, replaces or removes, and because every component records what it did in the shared knowledge base, each AI-driven step stays transparent and auditable. People remain in charge — able to understand how an answer was computed, and to intervene when they want to.

This repository is the reference implementation of the methodology, contributing reusable resources on top of the qa vocabulary for the Question Answering community.

One question, many annotations

Each component enriches a shared knowledge graph, step by step — and you decide which components take part.

QQuestion intext or audio

KBShared RDF basethe qa vocabulary

1Entity linkingspans → entities

2Query buildingannotates SPARQL

3Query executionannotates the answer

AAnswer outread from the base

Vocabulary-driven

The standard qa ontology is the contract between components. Data — not code — defines how the parts connect, so anything that speaks the vocabulary fits in.

Best-of-breed integration

Wrap existing tools or write new approaches as components, then mix and match them. Swap a single step without touching the rest of the pipeline.

Measurable quality

Every contribution is recorded in the knowledge base, so the QA process is fully traceable and its quality can be benchmarked stage by stage.

02 — Under the hood

How a Qanary component works

A component is an independent microservice that does one job and communicates only through the shared knowledge graph.

It’s a self-contained microservice

Each component is a small, self-contained service that exposes the same REST interface and communicates only through the shared knowledge graph. Components can be implemented in different languages — there are Qanary components written in Java, Python and TypeScript — and ready-made templates help you scaffold a new one quickly.

The pipeline hands it a graph, not data

When the pipeline runs, it calls the component with the location of the current QA process: the triplestore endpoint and the graph URI for this question — nothing more.

It reads what it needs with SPARQL

The component issues a SPARQL SELECT against the shared knowledge base to fetch its inputs — the question text, or annotations produced by earlier components.

It does its one job

It performs its specific task — entity linking, relation detection, query building, query execution, … — often by wrapping an existing tool or web service.

It writes results back as annotations

Results are stored with a SPARQL INSERT using the qa vocabulary — e.g. qa:AnnotationOfInstance or qa:AnnotationOfAnswerSPARQL — so they live in the same graph.

The next component just sees them

Subsequent components read those annotations and build on them. Components compose without knowing about each other — that is the whole point of the message-driven design.

A component’s entire conversation with the rest of the system is SPARQL over the shared graph. A linking component, for example, records which entity a span of the question refers to:

annotate-entity.rq — illustrative

PREFIX qa:  <http://www.wdaqua.eu/qa#>
PREFIX oa:  <http://www.w3.org/ns/openannotation/core/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

INSERT {
  GRAPH <urn:graph:THIS-QA-PROCESS> {
    ?a a qa:AnnotationOfInstance ;
       oa:hasTarget [ oa:hasSource <urn:question> ;
                      oa:hasSelector [ a oa:TextPositionSelector ;
                                       oa:start "0"^^xsd:int ;
                                       oa:end   "5"^^xsd:int ] ] ;
       oa:hasBody <http://www.wikidata.org/entity/Q1> ;   # linked entity
       qa:score  "0.91"^^xsd:double .
  }
} WHERE { BIND(IRI(CONCAT("urn:ann:", STRUUID())) AS ?a) }

The central Qanary Pipeline registers available components, lets you pick and order them through a web UI, runs them, and reads the final answer back out of the graph. Ready-made components live in the Qanary components repository.

03 — The interface

The Qanary user interface

Although a Qanary pipeline is typically the backend of a chatbot (for example, one implemented with LangGraph), the pipeline also ships with a web frontend for composing a pipeline, running a question, and inspecting exactly what every component did — letting users validate the behaviour of a configured pipeline. Click any image to enlarge.