Posts
Turn a Wikidata query into a useful interactive timeline
Rewritten on 28 October 2026 for the current Histropedia Query Timeline tool. The original publication date is retained above.
Histropedia Query Timeline runs SPARQL against Wikidata and displays the result with HistropediaJS. It provides a query editor, date and content mappings, colours, filters, sharing and export. Start here when you want to explore data before building a custom JavaScript application.
The important design decision happens before the code: what does one event mean? A person’s lifetime, a painting’s creation and an award win use different dates and need different grouping rules.
Start from a question with a small result
Choose one of the working examples:
- Recorded descendants of Queen Victoria: birth-to-death intervals and missing end dates.
- Dated items near a landmark: a location radius, inception dates and a numeric distance scale.
- Paintings by an artist: creation dates, images and collection categories.
- Oscar award statements: dates on a relationship and repeated wins by the same person.
Each walkthrough includes the query, a downloadable copy and a link carrying its field mappings. Open Configure Timeline, inspect the query and choose Generate timeline. These examples use the Main graph. The tool also offers a scholarly graph; changing endpoints is not a general fix for a query that returns no results.
Define the row before selecting fields
For a painting, the item identifier can identify the work. For an award, the person alone does not identify the event: one person can win in several years. Keep the event’s date and, when needed for later processing, the statement identifier or other event key.
Return a title and a start date first. Add an end date only if you mean an interval. Then add a source item, description, image and the categories needed for exploration. Extra multi-valued properties can multiply rows; add them one at a time and inspect the result count.
Map fields explicitly
Enter variable names without ?. A typical setup uses itemLabel for title, itemDescription for description, start for the start date and item for the Wikidata/source URL. Automatic detection is convenient, but explicit mappings survive a change in the order of the selected variables.
Dates need precision as well as timestamps. Retrieve wikibase:timeValue and wikibase:timePrecision from the same value node, then map both. Day precision is 11, month 10, year 9. Without a mapped precision, the tool defaults to day precision. January 1 in an exported timestamp is not enough to establish whether the original source meant that day or only the year.
Wikidata can also carry calendar models, uncertainty bounds and competing statements. The simple examples here do not turn all of those into visual uncertainty. Inspect source statements for historical or disputed dates; a clean card is not proof of an exact date. Rows without the mapped start date cannot become timeline events.
Control duplicates and density
Enable Merge duplicate results and provide a Group by variable when repeated rows describe the same item and start date. Different-start-date events remain separate. Matching start dates can still conceal different end dates or precision: the merge key does not compare those. Leave merging off while investigating competing date statements, as in the descendants examples. Inspect disagreements rather than forcing them into one card. A query’s LIMIT counts rows before grouping; it does not guarantee a number of unique events.
If the timeline looks sparse, check event density and zoom as well as the query result. If you provide a rank variable, larger numeric values receive higher priority. Otherwise query order affects priority. Rank is a display choice, not a measure of historical significance or source reliability.
Make the next action useful
Use a categorical field for comparisons such as collection or award recipient. Use a numeric field for a continuous colour scale. Add filter categories that answer likely follow-up questions, and retain source links so viewers can investigate anomalies. An image is helpful context, but keep titles and descriptions useful when an image is missing or fails to load.
Share gives a configured query URL and embed code. Reopen the URL to verify what it actually preserves. Live queries depend on service availability and current data; a saved URL is not a snapshot of the result or necessarily of every temporary viewing filter. Export provides data for a dated snapshot or further work in Histropedia Sheets. Keep the query, mappings and retrieval date with research exports, and check image licences separately before reusing images outside the tool.
For a custom product, HistropediaJS documentation and examples are the next step. For query syntax, use the Wikidata SPARQL tutorial. The original 2017 article introduced the early query viewer; the workflow above replaces its beta-era controls and naming.