opengovai4d

Knowledge Graph

Knowledge Graph AI4Deliberation models public consultations as a structured IBIS (Issue-Based Information System) hierarchy: The Consultations contain Articles (legislative provisions), which accept Citizens' Positions (proposed amendments), each supported by Arguments. Analyses extracted via LLM from several consultation datasets are converted via an ETL pipeline into RDF triples stored in a Virtuoso triple store. A multi-agent RAG service (Translator → Validator → Narrator) answers natural language questions by creating and running SPARQL queries on this graph.

How it works Knowledge Graph;

1. Data
The source is Greek consultation data, which consists of several SQLite databases, one per legislative article. Each database contains comments from citizens processed in advance by a tool, which extracted a structured JSON from each comment: a list of posts (proposed amendments with amendment _type: addition, removal, modification or suggestion) and arguments by location (each with polarity: positive, negative or neutral).


2. ETL Pipeline
The pipeline is run in two phases:
Export: It reads every SQLite database and analyzes JSON. Maintains full nested structure: consultation → article → comment → positions → arguments. Articles and consultations metadata (titles, ministry, dates) are searched by the main consultation data source.
Transformation: Converts the extracted data to RDF triads using the IBIS ontology:

  • Every Consultation and Article becomes an ibis:Issue hub
  • ibis:questions links a Consultation to each of its Articles
  • Each exported position becomes ibis:Position with ibis:respondsTo showing in its Article
  • Posts with amendment _type: removal or modification also acquire ibis:objectsTo → Article
  • Each argument becomes ibis:Argument with ibis:supports or ibis:objectsTo showing in its Position
  • Initial citizen comments are kept as og:Comment nodes connected back to locations via og:extractedFrom

3. Save Knowledge Graph
The pipeline serializes the graph in ttl file format. This Turtle file is loaded into a Virtuoso triple store, which exposes a SPARQL 1.1 endpoint.


4. RAG service
A FastAPI service wraps a pipeline of three agents powered by LLMs:

  • Translator's Agent: It takes the user's natural language question (along with conversation history) and generates a SPARQL query following the IBIS transit rules.
  • Agent Validator: It checks the generated SPARQL for structural correctness, such as valid prefixes, valid properties, correct multi-step crossing, without false predications, and either approves it or returns a correction.
  • Agent Narrator: Performs the validated query in Virtuoso, receives the raw result lines and composes a coherent natural language answer in Greek or English depending on the question.

5. User Interaction
Users submit a question (with optional chat history) to the endpoint. The three agents are executed sequentially. If the query does not return results, Narrator clearly states it instead of inventing an answer. Multi-round conversations are supported by transferring previous pairs (question, answer) with each request.