Detección de registros bibliográficos duplicados

Si bien el procedimiento correcto para ingresar registros a una base bibliográfica requiere que el catalogador haga previamente una búsqueda, para cerciorarse de que el registro en cuestión no ha sido ya ingresado, en la práctica a veces sucede (por distracción o por un error en la forma de hacer la búsqueda) que se termina cargando dos veces lo mismo.

Catalis no cuenta con un mecanismo para alertar al catalogador cuando se va a grabar en la base de datos un registro duplicado (aunque tal vez no sería complicado añadirle ese tipo de validación). De modo que, por la salud de nuestro catálogo, nos vemos obligados a realizar periódicamente tareas de control de calidad, que incluyan la detección de registros posiblemente duplicados.

A continuación se presenta un mecanismo sencillo que ayuda a detectar registros sospechosos de estar duplicados. El método, así como lo mostramos, funciona en Linux; con algunas mínimas adaptaciones puede usarse también en Windows.

Guardamos las siguientes líneas en un archivo que podemos llamar duplic.sh:

#!/bin/bash

#PATH=/ruta/a/cisis/1660:$PATH

mx biblio \
   uctab=ansi \
   "fst=1 0 \
      if s(v100,v110,v111) > '' then v100^a.10,v110^a.10,v111^a.10, else '----------', fi, \
      c11,'/',v008*7.4,'/', \
      replace(replace(v245^a,' /',''),' :','')" \
   fullinv=clavesdup \
   now -all
   
mx dict=clavesdup "pft=if val(v1^t)>1 then \
   putenv('COUNT=', f(val(getenv('COUNT'))+1, 1, 0)), getenv('COUNT'), c5, \
   v1^*/ fi" now

Luego hacemos que el archivo sea ejecutable:

$ chmod +x duplic.sh

Para el uso de este script, suponemos que trabajamos sobre una copia de la base bibliográfica (archivos biblio.mst y biblio.xrf), ubicados en la misma carpeta donde tenemos el archivo duplic.sh.

Ejecutamos el script con este comando:

$ ./duplic.sh > dup-sospechosos.txt

En el archivo dup-sospechosos.txt encontraremos un listado de las claves asociadas a registros que podrían estar duplicados. Luego tendremos que comprobar, para cada una de esas claves, si los respectivos registros son en realidad duplicados. Esta es una muestra de lo que podríamos encontrar dentro de dup-sospechosos.txt:

22  KARLIN, SA/1959/MATHEMATICAL METHODS AND THEORY IN GAMES, PR
23  KLEIN, FEL/1950/VORLESUNGEN UBER DIE ENTWICKLUNG DER MATHEMA
24  LIONS, J.-/1973/COURS D'ANALYSE NUMERIQUE
25  LIUSTERNIK/1961/ELEMENTS OF FUNCTIONAL ANALYSIS
26  MORGADO, J/1962/INTRODUCAO A TEORIA DOS RETICULADOS.

Para mejorar la precisión es conveniente usar la versión 16/60 del utilitario mx, que trabaja con claves grandes. Se lo puede descargar desde el sitio de la BVS. Si esa versión de mx no es la predeterminada en la computadora, entonces en duplic.sh se debe modificar esta línea:

#PATH=/ruta/a/cisis/1660:$PATH

quitando el # inicial y reemplazando /ruta/a/cisis/1660 por la ruta que corresponda.

Es de esperar que este método produzca falsos positivos; por otra parte, no debemos suponer que nos permitirá encontrar a todos los duplicados. Es decir, el método puede andar flojo tanto en 'precision' como en 'recall'… pero al menos es una ayuda para empezar a limpiar nuestros catálogos.

¿Qué significa que dos registros bibliográficos R1 y R2 compartan la misma clave? Veamos cuáles son las situaciones que se pueden presentar:

1. R1 y R2 representan exactamente a un mismo recurso bibliográfico, y por lo tanto uno de los dos registros está de más y debe ser eliminado de la base; para decidir cuál eliminar habrá que compararlos cuidadosamente. En particular, hay que consolidar los datos de existencias que pudiese haber en ambos registros.
2. R1 y R2 representan a diferentes recursos bibliográficos, pero los datos con los que se arman las claves no alcanzan a distinguir entre ambos. Podemos considerar estos casos:
   1. La clave es corta: Por ejemplo, cuando la diferencia entre R1 y R2 sólo se da en la última palabra del título, pero éste es tan largo que esa palabra no llega a entrar en la clave. Nada que corregir en la base de datos.
   2. La clave no abarca suficientes datos: La diferencia entre R1 y R2 sólo se da en un elemento que no fue considerado al armar la clave (por ejemplo, la editorial). Nada que corregir en la base de datos.
   3. Error en los datos: Las claves deberían servir para distinguir R1 de R2, pero alguno de los registros contiene un error que hace coincidir las claves. Un ejemplo: R2 se creó duplicando (intencionalmente) R1, y por una distracción no se modificaron en R2 algunos datos que estaban presentes en R1. Habrá que revisar los registros y hacer las correcciones necesarias.