(Una historia de OpenMusicRepository)
En la primera publicación presentamos brevemente el proyecto y contamos que estamos construyendo una infraestructura para trabajar con partituras y metadatos musicales.
Ahora podemos dar un pequeño paso más y explicar el problema real que hemos encontrado.
Leer más: De una colección de partituras a un catálogo que pueda entenderseEl problema no son las partituras. Son los datos.
Cuando se trabaja con partituras procedentes de distintas fuentes, encontrar el archivo puede ser relativamente sencillo.
Lo complicado empieza después.
Una misma obra puede aparecer con:
- títulos ligeramente diferentes;
- abreviaturas;
- idiomas distintos;
- números de catálogo escritos de formas diferentes;
- nombres de compositores con variantes;
- errores de transcripción;
- información incompleta;
- identificadores diferentes según el proveedor.
Por ejemplo, una misma obra puede aparecer como:
Ave verum corpus, K. 618
Ave Verum Corpus, K.618 (Mozart, Wolfgang Amadeus)
Ave, verum corpus
Para una persona, probablemente está claro que estamos hablando de la misma obra.
Para un sistema informático, no necesariamente.
Y cuando se trabaja con miles de obras, este problema deja de ser anecdótico.
¿Y si simplemente buscamos el título?
Esa fue una de las primeras aproximaciones.
Consultar diferentes catálogos, recoger los resultados y tratar de encontrar coincidencias.
Funciona razonablemente bien para algunos casos.
Pero pronto aparece otro problema: los catálogos no responden de la misma manera.
Una búsqueda por Mozart, por ejemplo, puede devolver cientos de obras en una fuente y resultados diferentes en otra.
Además, los resultados están paginados.
Si analizamos solamente la primera página de cada proveedor, podemos estar comparando únicamente una parte del universo disponible.
Y entonces una coincidencia que parece correcta puede dejar de serlo cuando aparece una obra mejor candidata en una página posterior.
Por eso estamos cambiando la forma de plantearlo
En lugar de considerar una consulta como una petición que debe resolverse completamente antes de responder, estamos construyendo un proceso progresivo.
La idea es sencilla:
la petición empieza el trabajo, pero no tiene que esperar a que termine.
Cuando se solicita una resolución:
- se crea una sesión;
- se empieza a consultar a los proveedores;
- se conservan los resultados obtenidos;
- se van analizando las obras;
- los resultados pueden mejorar cuando aparece nueva información;
- el proceso puede continuar aunque el navegador se cierre o una petición HTTP haya terminado.
Esto nos permite separar dos cosas que antes estaban demasiado juntas:
buscar y resolver.
Buscar no es resolver
Una búsqueda debe ser rápida; queremos poder preguntar a una fuente:
«¿Qué tienes sobre Mozart?»
y empezar a mostrar resultados. Resolver una obra es otra cosa, ahí queremos responder preguntas como:
¿Estas dos representaciones corresponden a la misma obra?
¿Este nombre de compositor es realmente Mozart?
¿Qué catálogo identifica esta obra?
¿Qué fuentes coinciden?
¿Qué evidencia tenemos para afirmar que dos registros son la misma entidad?
Ese proceso necesita más información y, en ocasiones, más tiempo.
Por eso estamos construyendo una capa específica para la resolución de identidad musical.
No queremos convertirnos en otro catálogo
Esta es probablemente una de las decisiones más importantes del proyecto.
OSAP necesita conservar información durante una resolución para poder trabajar con ella, pero eso no significa que queramos crear una copia permanente de todos los catálogos que consultamos.
- Una consulta tiene su propio contexto,
- Sus resultados pertenecen a esa operación.
- Una vez terminado su ciclo de vida, esos datos pueden desaparecer.
De esta manera podemos utilizar información de varias fuentes sin convertir nuestra API en un catálogo paralelo.
Y hay otra cuestión importante: equivocarse
Durante las primeras pruebas trabajamos con 250 obras reales.
Los resultados fueron interesantes.
El sistema consiguió identificar correctamente muchas obras, pero también encontramos algo mucho más importante:
una resolución aparentemente segura puede ser incorrecta.
Una coincidencia equivocada es peor que reconocer que no sabemos la respuesta.
Por eso estamos trabajando para que el sistema pueda distinguir entre:
- una coincidencia suficientemente fuerte;
- varias posibilidades razonables;
- ausencia de evidencia suficiente.
La palabra importante aquí es evidencia.
No queremos que el sistema simplemente diga:
«Creo que es Mozart.»
Queremos poder saber por qué lo cree.
Qué proveedores coincidieron, qué título encontraron, qué catálogo apareció y qué identificadores externos respaldan la decisión.
Un proyecto que empieza a tomar forma
Todavía estamos en una etapa de construcción.
No estamos intentando resolver todos los problemas de la música digital de una vez.
Estamos construyendo las piezas poco a poco:
fuentes → búsqueda → normalización → coincidencias → evidencia → resolución
Y, sobre todo, estamos probando estas ideas con datos reales.
Porque en este tipo de proyecto es muy fácil diseñar un sistema que funciona perfectamente con diez ejemplos.
Lo interesante empieza cuando lo ponemos delante de cientos, miles o millones de registros.
Ahí es donde estamos aprendiendo realmente qué necesitamos construir.
Para cerrar
Estamos construyendo OSAP poco a poco: no solo para encontrar partituras, sino para conseguir que las distintas representaciones de una misma obra puedan entenderse como parte de una misma realidad musical.
Seguiremos contando el proceso.
Descubre más desde Recursos para formacion
Suscríbete y recibe las últimas entradas en tu correo electrónico.