Artwork of the Day
Turns Wikidata into a daily, cited art-history experience.
Every day it features a painting by an artist born on today's date, then builds a rich, deterministic, fully-cited article about it, and the people, places, movements and institutions around it, live from open knowledge graphs. There is no language model in the loop: every sentence is a real Wikidata fact or attributed Wikipedia text, so nothing can be invented. The same facts are republished as interoperable Linked Art and IIIF, making the output open data rather than a silo.
Grounded beats generated
Wikidata holds millions of artworks, artists, places and movements as a structured graph, but it isn't something you'd actually read. The goal was to turn that graph into a polished, trustworthy daily art-history experience, and to do it without a language model so nothing can be invented.
Every sentence is assembled deterministically from a real Wikidata statement or attributed Wikipedia text, an earlier optional LLM layer was removed entirely. That single constraint forced the interesting engineering: a schema-agnostic narrator, multi-hop notability-ranked graph traversal, and a measured two-API hybrid. Factual trust becomes a product feature rather than a disclaimer.
A daily pipeline from birthday to cited article
A vanilla-JS browser shell talks to a Flask core that fans out across open knowledge graphs, narrates the result deterministically, and republishes it as standards-based open data, no database, no secrets.
Tied to the date
Each day a SPARQL query finds paintings by artists born on today's month and day, stable per day. From there the chosen artwork seeds the rest of the pipeline, the day's experience is computed, not curated by hand.
A measured two-API hybrid
SPARQL on the Wikidata Query Service handles everything graph-shaped: search, traversal, notability ranking, while the Wikibase REST API handles entity-by-id reads where it genuinely wins (qualifier spans, references), taking load off the rate-limited SPARQL endpoint.
Schema-agnostic engine
A generic narrator turns any Wikidata entity's statements into prose from a property→template registry, adding a new fact type is one line. A parallel orchestrator runs ~16 independent SPARQL/REST/Wikipedia calls concurrently, with graceful degradation so a throttled query drops one section, never the page.
Interoperable open data
The same facts are republished as schema-valid Linked Art (CIDOC-CRM JSON-LD, 7 dereferenceable record types with VIAF/Getty/ISNI authority links) and IIIF Presentation 3.0 manifests, so the output is reusable open data and a deep-zoom-ready image surface, not a closed silo.
A real product surface, not a demo
The daily article is only the start, the explorer, sharing, and viewing surfaces make it something people actually use and link to.
Deep, deterministic articles
The work's facts, the depicted subjects, the artist's life, genre & tradition, academic lineage & peers, where the work is held, its dated history, and full data provenance.
Explore the graph
Click any related work, artist or movement to load it, a knowledge-graph rabbit hole. Plus a date picker for any day, a "🎲 Surprise me" button, and a Back stack.
Gallery mode
A museum-wall dark mode that presents paintings on a wall, persisted across visits.
Social link previews
Every painting has a share URL with server-rendered Open Graph tags and a branded 1200×630 card generated on the fly, so a shared link previews the actual artwork.
Deep-zoom viewer
A full-resolution IIIF + OpenSeadragon lightbox; every artwork also serves an IIIF Presentation 3.0 manifest.
Linked Art API
Every entity is a dereferenceable Linked Art / CIDOC-CRM JSON-LD record with authority links, provenance events, content negotiation, HAL and CORS.
Trustworthy by construction
- Deterministic, fully-cited generation. The optional LLM layer was removed entirely, so every line is a real Wikidata fact or attributed Wikipedia quote, the "From Wikidata" badge is literally true, and there are no keys or per-token cost.
- The right API for each job, measured not assumed. Moving label-heavy reads to REST meant 40 value-label lookups per entity (no batch endpoint) versus 1 SPARQL query with labels inline, so those stayed on SPARQL, and REST was reserved for qualifier spans and references where it actually wins.
- Knowing when to stop. A "paintings from year N" query was un-indexable on WDQS (~23s scanning 390k rows), so it was dropped in favor of same-collection / same-movement traversal, because silent truncation and slow features are worse than fewer features.
- Parallelism with politeness. Enrichment fans out across a thread pool capped at 5 workers (WDQS's per-IP concurrency), cutting wall-time roughly 3× with graceful degradation.
- Interoperability as a deliverable. Linked Art / CIDOC-CRM JSON-LD and IIIF Presentation 3.0 output is validated against the official JSON Schemas, with VIAF/Getty/ISNI authority links making the data useful well beyond the app's own UI.
- A reviewable quality bar. 69 pytest tests cover the property narrator, qualifier/date parsing, network-facing parsers (HTTP mocked), and route-level behavior, with zero required API secrets or paid model dependencies. CI runs lint, format-check, type-check and tests on every push, alongside accessibility and SEO work on the frontend.
- Three documented deployment targets. Render, Cloud Run, and Railway/Fly are each documented with working configs, so the app ships to whichever host fits without re-engineering the deploy.
Live, deployed, and interoperable
Artwork of the Day runs in production at daily.metahistorybook.com. It is a live product that doubles as a reusable knowledge-graph narration engine, green CI, accessibility, SEO, Docker deployment, an IIIF deep-zoom viewer, and records validated against the official Linked Art JSON Schemas. The thesis in one line: cited, deterministic and standards-compliant beats generated.