OnSET

Code for OnSET: Ontology and Semantic Exploration Toolkit, presented at ACM SIGIR 2025 (demo track).

Demo · Paper · Video

Research use only. Not a medical device. See DISCLAIMER.md for intended use, data provenance and limitations.

Overview

OnSET lets researchers explore and query ontologies and knowledge graphs (KGs) without writing SPARQL, and get a quick impression of the scale and structure of an unfamiliar KG. It has three main views:

• a query view, where users build queries from topics or from a natural-language prompt and refine them in a visual node-link editor,
• an explorative view of the ontology as a whole, its sparse relations and its named instances, and
• a linked view showing the class hierarchy and the topic model side by side.

For natural-language queries, a language model running locally on the server (via llama-cpp-python) extracts a prototype query graph. A grammar generated from the ontology restricts it to classes and relations that exist in the KG; the graph is then editable and runs as SPARQL against a QLever endpoint. OnSET calls no hosted LLM API. On first start, the backend downloads the language model and the sentence-embedding models from the Hugging Face Hub.

Data

The repository contains no knowledge-graph data. The docker/*-data folders hold QLever configurations (Qleverfile) that download and index public KGs, each under its own licence: DBpedia (docker/dbpedia-data, the default backend configuration), UniProt (docker/uniprot-data), the BRAINTEASER Ontology (docker/bto-data), YAGO (docker/yago-data), DNB (docker/dnb-data), DBLP (docker/dblp-data) and Olympics (docker/olympics-data). The backend configurations for each KG (SPARQL port, database, model) are in backend/src/eval_config.py.

Running locally

Docker

PostgreSQL (with pgvector/PostGIS), pgAdmin and Redis run via Docker Compose:

cd docker/onset-data
docker compose up -d

The compose file uses development default credentials (postgres/postgres); change them before exposing the services. The frontend and backend each have a Dockerfile (frontend/Dockerfile, backend/Dockerfile, the latter built with CUDA support); QLever is not part of the compose file and is started as below.

Configuration

All knowledge graph configurations live in backend/config.json (path overridable with ONSET_CONFIG), which is used by the backend and the exploration scripts alike:

{
  "default": "dbpedia",                  // pre-selected configuration
  "defaults": { "model_id": "...", ... },  // shared by every configuration
  "configs": {
    "dbpedia": {
      "name": "DBpedia", "description": "...", "sparql_endpoint": "...", "conn_str": "...",
      "variants": [ { "name": "DBpedia Mistral", "model_id": "...", "model_quant": "..." } ]
    }
  }
}

• Each configuration resolves to defaults <- config <- variant; eval_config.ALL_CONFIG_MAP[key] lists the variants followed by the base configuration, so [-1] (or get_config(key)) is the base configuration served by the API.
• String values may reference environment variables as ${VAR} or ${VAR:-fallback}, e.g. ONSET_DB_HOST, ONSET_SPARQL_HOST, REDIS_CACHE_URL, LLM_MODEL_ID, LLM_MODEL_QUANT, ONSET_DEFAULT_CONFIG.
• The API lists configurations at GET /configs; every other endpoint is scoped to a configuration as /{config_id}/... (e.g. /dbpedia/classes/roots, docs at /dbpedia/docs). Configurations are loaded lazily on first use; ONSET_MAX_LOADED_CONFIGS limits how many stay loaded at once (0 = unlimited).
• The frontend mirrors this: / selects a configuration, /:configId/explore and /:configId/circles are the pages for it. Regenerate the API client from any configuration's schema, e.g. sta generate -p http://localhost:8123/dbpedia/openapi.json -o ./src/api/client.ts --axios.

Development setup

1. Install Apache Jena so that the riot command-line tool is available (some get-data steps use it).
2. Install qlever-control (pip install qlever), then download, index and start a KG from its folder, e.g. docker/dbpedia-data (port 7012, the backend default):

   qlever get-data
   qlever index
   qlever start

3. Start the auxiliary databases (see Docker above).
4. Backend:
   • install uv,
   • install dependencies from backend/ with CMAKE_ARGS="-DGGML_CUDA=on" uv sync (or CMAKE_ARGS="-DGGML_METAL=on" uv sync on macOS),
   • start the API from backend/src with uv run python -m uvicorn api:app --reload --port 8001. The database tables are initialised on first start. DB_CONN_STR, SPARQL_ENDPOINT, LLM_MODEL_ID, LLM_MODEL_QUANT and REDIS_CACHE_URL override the configured defaults.
5. Frontend:

   cd frontend
   npm install
   npm run dev

   The frontend reads the backend URL from ONSET_API_BASE_URL (frontend/.env.development: http://localhost:8001).

Citation

@inproceedings{2025-onset,
  author    = {Kantz, Benedikt and Innerebner, Kevin and Waldert, Peter and Lengauer, Stefan and Lex, Elisabeth and Schreck, Tobias},
  title     = {{OnSET: Ontology and Semantic Exploration Toolkit}},
  booktitle = {Proceedings of the 48th International ACM SIGIR Conference on Research and Development in Information Retrieval},
  series    = {SIGIR '25},
  pages     = {3980--3984},
  year      = {2025},
  publisher = {Association for Computing Machinery},
  address   = {New York, NY, USA},
  isbn      = {9798400715921},
  doi       = {10.1145/3726302.3730148}
}

Acknowledgement

Funded by the European Union under grant agreement No 101137074 (HEREDITARY). Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Health and Digital Executive Agency (HaDEA). Neither the European Union nor the granting authority can be held responsible for them.

License

MIT, see LICENSE.