Una de mis quejas más repetidas, cuando consulto OPACs o bases de datos, es la falta de COinS, que impide que los gestores de referencias, como Zotero o Mendeley, puedan capturar los datos bibliográficos del documento en cuestión. Por ejemplo, en el catálogo colectivo de REBIUN no hay este tipo de metadatos, a pesar de que he hecho este comentario por activa y por pasiva. Pues es un defecto, chicos…
Para comprender esto, es necesario empezar explicando qué es COinS. El origen viene de la especificación OpenURL, creada a finales de la década de 1990. Dentro de la especificación se introducía el concepto de ContextObjects. En breve, ContextObjects hacía posible la agregación de metadatos que permitiesen describir (desde una perspectiva informativa-documental) el recurso referenciado. Por el camino, OpenURL fue estandarizado por la ANSI/NISO como Z39.88 en 2044, y revisado en 2010.
A comienzos de la década 2000, y viendo los problemas que planteaba integrar metadatos bibliográficos en HTML, hubo varias propuestas para usar ContextObjects como medio para ello. Se escribe una especificación para integrar OpenURL en HTML, que recibe el nombre de COinS, siglas de ContextObjetcs in SPAN. A medidados de la década ya estaba aceptado y en funcionamiento, apareciendo incluso plugins de WordPress (OpenBook Book Data y Scholarpress COinS) y módulos de Drupal (COinS) para facilitar su implementación.
En plan más técnico, COinS usa un formato de serialización de OpenURL, denominado KEV, y algunos formatos de metadatos. Permite diferenciar cuatro tipos de publicaciones (genérica, artículos, libro y patente). La especificación no impone un modelo estricto de metadatos, por lo que puede adaptarse a las necesidades y particularidades del recurso en cuestión. Es más simple de lo que parece. Su uso se han extendido ampliamente, y lo usan, por ejemplo, WordlCat, LibX, Mendeley, Zotero, CiteUlike o ResearchGate. Pruébalo capturando COinS en Wikipedia, sorprendente…
Vamos, que el que no implementa COinS es porque no quiere…
