Knowledge graph, Wikidata alignment, KGE and NL-to-SPARQL RAG
Web Datamining & Semantics, ESILV · a Wikipedia case study
- Period
- Mar 2026
- My part
- Repo owner and main developer in a team of 2 (24 of 27 commits). My teammate wrote the core RAG module; I hardened it.
- Stack
- Python
- httpx
- trafilatura
- spaCy
- rdflib
- SPARQL
- OWL
- Owlready2
- HermiT
- PyKEEN
- PyTorch
- Ollama
- Anthropic SDK
- Gradio
- Links
- Source on GitHub
Built an end-to-end knowledge-graph pipeline: crawler, transformer NER, RDF/OWL ontology aligned to Wikidata (65k triples), PyKEEN embeddings, and NL-to-SPARQL RAG with self-repair.
- Built an end-to-end knowledge-graph pipeline on public Wikipedia/Wikidata data: robots.txt-compliant crawler, spaCy-transformer NER (14k mentions, 9 types), and a hand-designed RDF/OWL ontology (15 classes, 10 relations) aligned to Wikidata and expanded by SPARQL into a 65k-triple Wikidata-expanded graph (52k entities).
- Trained TransE and DistMult (PyKEEN, 128-d, 200 epochs) after extracting a degree-2 dense core from a 43k-triple graph. DistMult reached MRR 0.21 / Hits@10 0.38, versus MRR 0.02 on the raw sparse graph. Added OWL/HermiT reasoning and t-SNE embedding analysis.
- Hardened a NL-to-SPARQL RAG assistant (deterministic query planner plus self-repair of Wikidata URIs, optional Ollama gemma3 or Claude Haiku backends, Gradio UI) to 9/9 grounded answers with zero repairs. Packaged as python -m modules with a tagged v1.0 release and MIT licence.
The finding
About 97% of entities had degree 1, so more triples made link prediction worse. The fix was to change the data, not the model.