I’ve put together a small pipeline that queries Wikidata via SPARQL, converts the results to tiddlers, and deploys a single-file TiddlyWiki to GitHub Pages — automatically, on a schedule, with no server required. The code is at https://github.com/andjar/wikitiddler, with a simple demo at https://github.com/andjar/wikitiddler-demo (wiki: My TiddlyWiki — a non-linear personal web notebook).
The demo lists Norwegians killed during the German invasion of Norway, with a tiddler for each individual, including some basic info such as dates of birth/death and place of birth. Since Wikidata is linked, it would also be possible to put them on a map, connect them to events, add portraits, add external sources/links etc
What Wikidata actually is
For those unfamiliar: Wikidata is a free, collaboratively maintained knowledge graph with tens of millions of structured entities — people, places, organisations, species, artworks, buildings, chemical compounds, you name it. Unlike Wikipedia, everything in Wikidata is machine-readable and interlinked. A person entity might link to their employer, their field of work, their place of birth, their academic advisors, and the awards they received — all as typed, queryable relationships.
The query language is SPARQL, which lets you traverse these links. Some examples of what this looks like in practice:
-
All architects who studied under a specific person, with their notable buildings
-
All lakes in a given country, with surface area, elevation, and coordinates
-
All heads of state who were also published authors
-
All species of a given genus, with their conservation status and first described date
-
All films made in a particular decade, grouped by director’s nationality
The data is maintained by a large community, which means it keeps improving. When someone adds or corrects an entry on Wikidata, your wiki picks it up on the next build.
The pipeline
The GitHub Action does four things: runs the SPARQL query against the Wikidata endpoint, feeds the JSON results through a Python script that generates one .tid file per entity, builds the wiki with the TiddlyWiki Node.js CLI, and deploys the output to GitHub Pages. Dates from Wikidata (xsd:dateTime) are converted to TiddlyWiki’s datetime format automatically; multi-valued properties (via GROUP_CONCAT) become TiddlyWiki list fields ([[val1]] [[val2]]), so you can use [list[!!field]] filters directly in your templates.
Your repository only needs three things: a query.sparql file, a templates/ folder with your .tid files, and a workflow .yml that calls the action. No package.json, no requirements.txt, no scripts — the action provides all of that.
Where TiddlyWiki comes in
Each Wikidata result becomes a tiddler with fields populated from the SPARQL columns. From there, everything TiddlyWiki already does well applies: view templates, $list filters, tags, transclusion, DataTables-style displays, custom stylesheets. You can build quite rich browsing experiences — grouped views, cross-linked entries, filtered subsets — purely through wikitext and templates, without touching the pipeline at all.
This is the part I find most interesting. The same SPARQL query result can be presented in completely different ways just by changing the templates. A dataset of people could be a timeline, a grouped list by occupation, a table sorted by date, or a network of linked tiddlers — all from the same underlying data, with no code changes.
Some things this could be useful for
-
Browsable indexes of domain-specific Wikidata subsets (scientists in a field, buildings in a city, species in a genus)
-
Local or regional history projects where the data already lives in Wikidata but has no good public interface
-
Reference wikis that stay current without manual data entry — anything where Wikidata is a reasonable upstream source
Happy to discuss the SPARQL side, the template approach, or how to extend the pipeline if there’s interest.