MusiGraph. (Open MusiGraph in a new tab)

A semantic music explorer that queries Wikidata and SPARQL in real time: instead of returning a list of results, it walks the links between artists, albums, genres and influences. It started as a university assignment; I liked the problem enough to keep building until it was deployed.

Tech-stack I used here

Origin and purpose

  • A university assignment that stuck. MusiGraph began as coursework on semantic data, but linked data answered a question I actually cared about: how are two artists related?

  • Search lists facts, graphs follow links. A classic music search returns a list; Wikidata stores artists, albums, genres and influences as connected entities, so “who influenced whom” comes from the same data.

  • Free, open and multilingual. Wikidata is community-maintained, multilingual and queryable through SPARQL, so the project works with the data instead of paying for it.

Decisions

  • Server for data, client for interaction. Live data is fetched on the server; only search, filters and tabs run in the browser, so the SPARQL layer never leaves the server.

  • One API route, validation included. Everything goes through /api/sparql, which removes CORS against Wikidata; QIDs, decades and search terms are sanitized before the builders interpolate them.

  • Labels and language resolved in the query. Labels are resolved per engine (Blazegraph label service on v1, OPTIONAL plus COALESCE on QLever). The page language travels from client to builders, so names come back readable and in the language you are reading.

  • Cache and graceful failure. A server-side LRU cache plus client-side request dedupe make repeat queries cheap, and the profile still renders when a secondary query times out.

  • An engineering notebook, not a dashboard. Space Mono, a graph-paper dot grid and one coral accent, with flat fills and CSS-only motion.

Five sources, one endpoint

MusiGraph multi-source data flowA client search request travels through /api/sparql to the Auto orchestrator, which queries the Wikidata core with QLever failover and four enrichment sources in parallel, then merges the results with provenance before rendering the profile tabs.Client UIsearch · profile tabs/api/sparqlvalidate · cachedispatchAuto orchestratoridentity resolutionfan-out · provenanceWikidata coreSPARQL · QLever failoverEnrichment sourcesWikipedia · DBpedia ESMusicBrainz · DiscogsMergeprecedence · dedupeprovenance badgesProfile tabsoverview · discographyinfluences · collabsDashed enrichment runs in parallel.It never blocks the core profile.Every merged row keeps its source.

Results

  • Live and open source. Deployed on Vercel at musigraph.vercel.app and MIT licensed on GitHub: artist search, profile, discography, influences and collaborations tabs, filters, EN/ES i18n and dark/light themes.

  • Five sources behind one endpoint. Auto mode orchestrates Wikidata, Wikipedia, DBpedia, MusicBrainz and Discogs from a single /api/sparql route, with provenance badges that show where every row came from.

  • A page that explains the data. The /[lang]/data page documents the flow, the source precedence rules, each provider’s limits and its license.

  • Fast where it matters. Query sizing, batch label resolution and caching took the slowest searches from more than 20 seconds to about 5, and kept cold profile queries near a second.

  • Still moving. Next up: an interactive influence network graph, a discography timeline and shared query caching. The MVP is complete; the visualizations are the fun part.