Un explorador musical semántico que consulta Wikidata y SPARQL en tiempo real: en lugar de devolver una lista de resultados, recorre los enlaces entre artistas, álbumes, géneros e influencias. Empezó como un trabajo de la universidad; me gustó el problema lo suficiente como para seguir construyéndolo hasta tenerlo desplegado.

Tech-stack que usé aquí

Origen y propósito

  • Un trabajo de la universidad que se quedó. MusiGraph empezó como un trabajo sobre datos semánticos, pero los datos enlazados respondían una pregunta que sí me importaba: ¿cómo se relacionan dos artistas?

  • La búsqueda lista datos; un grafo sigue enlaces. Una búsqueda musical clásica devuelve una lista. Wikidata guarda artistas, álbumes, géneros e influencias como entidades conectadas, así que “quién influyó a quién” sale de los mismos datos.

  • Libre, abierto y multilingüe. Wikidata la mantiene la comunidad, es multilingüe y se consulta con SPARQL, así que el proyecto trabaja los datos en lugar de pagar por ellos.

Decisiones

  • Servidor para datos, cliente para interacción. Los datos en vivo se traen en el servidor; solo la búsqueda, los filtros y las pestañas corren en el navegador, así la capa SPARQL nunca sale del servidor.

  • Una sola API route, con la validación dentro. Todo pasa por /api/sparql, lo que elimina el CORS con Wikidata; los QIDs, las décadas y los términos de búsqueda se sanitizan antes de que los builders los interpolen.

  • Etiquetas e idioma resueltos en la consulta. Las etiquetas se resuelven por motor (label service en Blazegraph v1, OPTIONAL con COALESCE en QLever). El idioma de la página viaja del cliente a los builders, así los nombres vuelven legibles y en el idioma en el que estás leyendo.

  • Caché y fallos sin drama. Una caché LRU en el servidor y dedupe de peticiones en el cliente abaratan las consultas repetidas, y el perfil se sigue mostrando aunque una consulta secundaria se caiga.

  • Un cuaderno de ingeniería, no un dashboard. Space Mono, una retícula de puntos como papel cuadriculado y un solo acento coral, con rellenos planos y animación solo en CSS.

Cinco fuentes, un endpoint

Flujo de datos multifuente de MusiGraphUna búsqueda del cliente pasa por /api/sparql hasta el orquestador Auto, que consulta el núcleo de Wikidata con relevo a QLever y cuatro fuentes de enriquecimiento en paralelo; después fusiona los resultados con su procedencia y renderiza las pestañas del perfil.Interfazbúsqueda · pestañas/api/sparqlvalidación · cachédespachoOrquestador Autoresolución de identidadfuentes · procedenciaNúcleo WikidataSPARQL · relevo QLeverEnriquecimientoWikipedia · DBpedia ESMusicBrainz · DiscogsFusiónprecedencia · dedupebadges de origenPestañasresumen · discografíainfluencias · colabsEl enriquecimiento punteado es paralelo.Nunca bloquea el perfil principal.Cada fila fusionada conserva su origen.

Resultados

  • En vivo y open source. Desplegado en Vercel en musigraph.vercel.app y con licencia MIT en GitHub: búsqueda de artistas, perfil, discografía, pestañas de influencias y colaboraciones, filtros, i18n en/es y temas claro y oscuro.

  • Cinco fuentes detrás de un endpoint. El modo Auto orquesta Wikidata, Wikipedia, DBpedia, MusicBrainz y Discogs desde una sola ruta /api/sparql, con badges de procedencia que muestran de dónde viene cada fila.

  • Una página que explica los datos. La página /[lang]/data documenta el flujo, las reglas de precedencia entre fuentes, los límites de cada proveedor y su licencia.

  • Rápido donde importa. Ajustar consultas, resolver etiquetas por lotes y cachear bajó las búsquedas más lentas de más de 20 segundos a unos 5, y mantuvo las consultas de perfil en frío cerca de un segundo.

  • Sigue en movimiento. Lo siguiente: un grafo interactivo de influencias, una línea de tiempo de discografía y caché compartida de consultas. El MVP está completo; las visualizaciones son la parte divertida.