Documentación del proceso de migración a MARC 21

Este documento intenta cumplir una doble función: por una parte, presentamos un informe de las actividades desarrolladas durante el proceso de migración a MARC 21 de la base de datos bibliográfica de la Biblioteca Rivadavia de la ciudad de Bahía Blanca; por la otra, queremos que esta experiencia sirva de guía para futuras migraciones al formato MARC 21, y por esa razón nos explayamos en algunos aspectos de interés general.

Consideraciones básicas

No perder datos (o determinar qué datos pueden perderse sin problemas)
Evitar en lo posible una etapa de transición en la cual los catalogadores deben trabajar sobre una base semi-migrada
¿Podemos ir haciendo modificaciones sobre la base durante el diseño de la migración, o sólo al momento de ejecutar el proceso?

Algunos documentos sobre migración de datos en general

Introduction to data migration Trish Rose-Sandler, VRA Conference Kansas City, MO, March 28 2007

Análisis previo

Análisis de la base

Estructura: los registros son independientes o tienen algún vínculo (e.g. registros madre-hijo, registros analíticos)
Tipos de registros (libros, videos, …)
Convenciones locales de carga: i) campos o subcampos de uso local (no contemplados en el formato); ii) campos/subcampos existentes en el formato, pero usados en forma no estándar; iii) convenciones de puntuación (p.ej., en BR se sustituyen los paréntesis por guiones en los títulos, debido a una limitación de las búsquedas con MicroIsis).
Reglas de catalogación: ¿En qué medida los registros originales respetan las Reglas de catalogación angloamericanas 2da edición? ¿Los registros incluyen mención de responsabilidad? Si no la incluyen, ¿los registros migrados a MARC la incluirán? ¿Se han respetado los criterios para definir el punto de acceso principal (main entry)? Si no se han respetado, ¿se puede definir un punto de acceso principal para los registros migrados? ¿Se han creado registros distintos para reimpresiones de una obra? ¿Se usan las abreviaturas correctas (p.ej. S.l., s.n.)? ¿Se usan comillas para citas textuales en las notas (p.ej. en las notas de resumen)?
Estudio del uso real de campos y subcampos (herramientas: mxf0, mxtb). Ver mxf0.pft, Análisis de la base de datos BR con mxf0.
Detección de errores en el uso de campos y subcampos.
Presencia del símbolo de porcentaje (%).
Historia de la base: cambios en las convenciones de carga que pueden haberse producido a lo largo del tiempo.
Distinguir entre problemas que deben solucionarse antes de la migración, y aquellos cuya solución puede diferirse.

Mapeo de datos

Tabla 1: A qué campos de MARC se deben mover los datos almacenados en FOCAD.

[Pendiente: incluir lista de subcampos, y de normalizaciones necesarias para cada uno. Revisar qué elementos son propios de FOCAD, y cuáles son locales]

Campo FOCAD	Campos MARC	Observaciones
05 - Tipo de registro / Link a registro madre	?
07 -
10 - ISBN	020	Eliminar guiones
11 - ISBN	020	Eliminar guiones
14 -
20 - Título (nivel analítico)	740, 653	Distinguir títulos de descriptores
22 - Autor personal (nivel analítico)	700
23 - Autor institucional (nivel analítico)	710
24 - Título (nivel monográfico)	245
27 - Título uniforme	130/730
28 - Autor personal (nivel monográfico)	100/700 o 720?
29 - Autor institucional (nivel monográfico)	110/710 o 720?
30 - Título (nivel colección)	440/490
40 -
41 - Fecha de reunión?
42 -
44 - Edición	250
45 - Fecha de publicación	260$c, 008/06-14
47 - Editor, lugar de edición	260$a, 260$b
48 - Código de país	008/15-17, 044
49 - Referencias bibliográficas	504
50 - Código de idioma	008/35- 37, 041
52 - Descripción física	300
59 - Notas	500, 505, 511
60 - Clasificación temática	082
65 - Descriptores	653, 600, 008, 700 (videos)
69 - Resumen	520
75 - Signatura topográfica	082, 859
78 - Número de ejemplar	859
79 - Links a registros hijos		Usando solo en registros madre
84 - Nro. de volumen / Ubicación	859
85 - Disponibilidad (préstamo/consulta)	859?
999 - Identificador del registro		Usado para links desde otros registros

Tabla 2: cómo construir un registro MARC en base a los datos presentes en un registro FOCAD.

Campo MARC	Campos FOCAD
001 - Número de control	AUTO
003 - Código de la biblioteca	AUTO
005 - Fecha y hora de última modif.	AUTO
008 - Datos codificados	45, 48, 50, 52, 65, etc
020 - ISBN	10, 11
041 - Código de idioma	50
044 - Código de país	48
082 - Clasificación Dewey	60, 75
100 - Nombre personal	28?
110 - Nombre institucional	29?
111 - Nombre de reunión	??
130 - Título uniforme	27
240 - Título uniforme	27
245 - Título y mención de responsabilidad	24, 14, 40
246 - Variantes de título	??
250 - Mención de edición	44
260 - Publicación, distribución, etc.	47, 45
300 - Descripción física	52
440 - Serie	??
490 - Mención de serie	30
500 - Nota general	59
504 - Nota de bibliografía	49
505 - Nota de contenido con formato	59 ('Contenido: ')
511 - Nota de elenco	59 ('Elenco: ')
520 - Nota de resumen	69
600 - Nombre personal	65, 22¹⁾
653 - Descriptor	65, 20²⁾
700 - Nombre personal	28, 22, 65 (videos)
710 - Nombre institucional	29, 23
720 - Nombre no controlado³⁾	28, 29, 22, 23
730 - Título uniforme	??
740 - Título relacionado/analítico	20
859 - Existencias	75, 78, …

Limpieza de la base

Eliminar espacios en los extremos de campos (mxcp clean) y subcampos (p.ej. con un gizmo que reemplace “ ^” por “^”). Hay 2 registros con “^ ”: MFN 429, campo 47 Ed. Mart¡nez Roca^ lBuenos Aires, y MFN 63350, campo 52 475 p.^iil.^ 22 cm.
Detectar y luego eliminar o corregir caracteres inválidos

Detección y unión de familias de registros

Criterios. Ejemplos. Testeo.

Criterios

Vínculo entre registro madre y registro(s) hijo(s)
Igual signatura topográfica (basada en Dewey)
Igual clave formada por la combinación de elementos como autor, título, fecha (previa normalización)

Este es un ejemplo de familia de registros (obra en 6 vol., 2 ejemplares de cada uno):

mx br0 "pft=if v24:'Teatro' and v28:'Gambaro' then mfn,x2,v24,x3,v45,x3,v28,x3,v84,c53,v78,x3,v999,x3,v5/ fi" now

MFN     v24      v45    v28                 v84     v78    v999     v5      
----------------------------------------------------------------------------
002595  Teatro   1992   Gambaro^bGriselda   v.1     Ej.1   002623   n       
010854  Teatro   1992   Gambaro^bGriselda           Ej.2   010884   x2623
112909  Teatro   1992   Gambaro^bGriselda   v.2     Ej.1   112909   x2623
112910  Teatro   1992   Gambaro^bGriselda   v.3     Ej.1   112910   x2623
112911  Teatro   1992   Gambaro^bGriselda   v.4     Ej.1   112911   x2623
112912  Teatro   1992   Gambaro^bGriselda   v.5     Ej.1   112912   x2623
112913  Teatro   1992   Gambaro^bGriselda   v.6     Ej.1   112913   x2623
112914  Teatro   1992   Gambaro^bGriselda   v.2     Ej.2   112914   x2623
112915  Teatro   1992   Gambaro^bGriselda   v.3     Ej.2   112915   x2623
112916  Teatro   1992   Gambaro^bGriselda   v.4     Ej.2   112916   x2623
112917  Teatro   1992   Gambaro^bGriselda   v.5     Ej.2   112917   x2623
112918  Teatro   1992   Gambaro^bGriselda   v.6     Ej.2   112918   x2623

El primer registro, MFN 2595, tiene además un campo repetible 79 con estas 11 ocurrencias:

10884, 112909, 112910, 112911, 112912, 112913, 112914, 112915, 112916, 112917, 112918

que corresponden a los campos 999 de los registros hijos.

Valores del campo 999 que aparecen en más de 1 registro (exactamente en 2):

001114, 001697, 003215, 003965, 019887, 023106, 026077, 030332, 040129, 044362
044363, 044364, 044365, 060323, 069137, 072052, 083014, 083015, 083016, 083017
083018, 083019, 083020, 106406, 107513, 108347, 112493, 113181, 113633, 114427
114631, 114895, 114896, 122318, 122319, 123155, 123176, 123762

Estoy intentando comprender la utilidad del campo 79, que en un registro madre contiene links hacia sus registros hijos (mediante el valor del campo 999 de éstos):

mx br0 "pft=if p(v79) then 'MFN: ',mfn,x3,'999: 'v999/(x14,' 79: 'v79,c32,ref(l(val(v79)),v5)/)/# fi" now | more

Para esto generé un archivo inventido de br0 con la fst 999 0 v999, pero aún resta una dificultad: el campo 999 tiene (salvo pocos errores) longitud 6 (relleno con ceros a izquierda), mientras que el campo 79 es de longitud variable (sin relleno).

Estos son los casos en que el campo 999 no tiene longitud 6:

  mx br0 "pft=if size(v999)<>6 then mfn,x3,v999/ fi" now

  MFN      v999

  032469   32511
  067779   67785
  068889   68897
  069287   69290
  069505   69508
  069686   69689
  070315   70319
  070833   70837
  073198   0732001
  073910   73914
  075169   11092/929
  075596   75600
  076824   76828
  077305   77309
  077542   77546
  078275   78279
  078278   78282
  078279   78283
  078281   78285
  078282   78286
  078283   78287
  078284   78288
  078285   78289
  078287   78291
  078288   78292
  078289   78293
  078290   78294
  078291   78295
  078767   78771
  078787   78791
  078788   78792
  078789   78793
  078943   78947
  088055   88055
  096092   5017
  096093   5018
  096094   5019
  096441   96441
  099244   99244
  102337   0102337
  102338   0102338
  102339   0102339
  102340   0102340
  102341   0102341
  102342   0102342
  102343   0102343
  102344   0102344
  102345   0102345
  102346   0102346
  102347   0102347
  102348   0102348
  102349   0102349
  103652   1036512
  106136   0106138
  108359   5983
  116673   11673
  117249   11724
  122406   1|22406
  122547   1225470
  123085   1213085

Conversiones de los datos existentes

Cambio de norma: p.ej. códigos de idioma, códigos de país
Normalización de datos: p.ej. edición (FOCAD 44), descriptores a minúsculas (FOCAD 65), etc.

Estos cambios se pueden realizar mediante gizmos.

Moviendo los datos a MARC 21

Nociones generales

Al migrar los datos desde el formato de origen hacia MARC, nos encontraremos con algunas pocas situaciones bastante simples, donde sólo necesitamos cambiar la etiqueta de un campo (p.ej., el campo FOCAD 44 va al campo MARC 250). Sin embargo, lo más frecuente es que la migración de datos resulte complicada por alguno de estos motivos:

Campos de origen que necesariamente van a más de un campo MARC (e.g. FOCAD 45 Fecha va a MARC 260 y MARC 008)
Campos de origen que pueden ir a más de un campo MARC (e.g. FOCAD 65 Descriptores puede ir a MARC 653 o a MARC 600)
Campos MARC que necesariamente se construyen usando más de un campo de origen (e.g. MARC 008 usa varios, MARC 260 usa FOCAD 47 y FOCAD 45)
Campos MARC que se pueden construir usando más de un campo de origen (e.g. MARC 700 puede usar FOCAD 22 y FOCAD 28)

Dos métodos de migración

<note important> Estoy intentando presentar una descripción clara y objetiva de ambos métodos. Pero dado que tengo una preferencia por el Método 2, solicito ayuda para mantener la objetividad. —FG </note>

Para mover los datos desde formato de origen hacia el formato MARC, podemos optar entre (al menos) estos dos métodos:

Método 1. Para cada campo de origen, mover sus datos a los campos MARC apropiados

Descripción general

El proceso puede verse como una sucesión de modificaciones a cada viejo registro en el formato de origen, para convertirlo gradualmente en un nuevo registro MARC. En cada paso del proceso, uno o más campos de origen son eliminados y su contenido es movido a uno o más campos MARC.

Se utiliza un archivo por lotes (.bat, .sh) que contiene una secuencia de comandos del tipo

mx base "proc=@campoA.prc" copy=base now -all
mx base "proc=@campoB.prc" copy=base now -all
...

Por cada campo X de la base de origen se crea un archivo campoX.prc con las instrucciones para mover los datos del campo X a uno o más campos MARC.

Ventajas

Es simple verificar qué campos de origen han sido tenidos en cuenta (u omitidos) en la migración.
En el archivo .bat se pueden agrupar los comandos que modifican un campo mediante gizmos con los comandos que procesan esos campos para generar los campos MARC (p.ej., se aplica un gizmo para cambiar el código de país, y a continuación se mueve el código al campo correspondiente).

Desventajas

Como en cada etapa del proceso los registros contienen tanto campos del formato de origen como campos MARC ya creados, es necesario estar atentos a posibles conflictos en los números de campos (p.ej., al crear un campo MARC 020 [ISBN], no se debe pisar el campo 20 de FOCAD [Título de nivel analítico]). Posible solución: aplicar un prefijo a todas las etiquetas MARC, p.ej. 3245 representa el campo 245; al final se eliminan los prefijos.
Para ver cómo queda migrado un subconjunto de registros es necesario ejecutar el proceso sobre toda la base, o bien crear una base auxiliar que solo contenga los registros que se desean migrar.
Para los campos MARC que se construyen tomando datos de más de un campo FOCAD, …

Ejemplos de uso

Este método fue utilizado en la Biblioteca Central de la UNS para migrar de FOCAD a MARC 21.

Método 2. Para cada registro de la base original, crear el correspondiente registro migrado

Descripción general

El proceso puede verse como una receta para construir los campos de un nuevo registro MARC a partir de los ingredientes disponibles (los campos de un viejo registro en el formato de origen). El proceso completo se aplica en una sola pasada a cada registro de la base.

Se ejecuta un único comando como éste:

mx base "proc=@migra.prc" now -all

el cual utiliza un único archivo migra.prc que contiene las instrucciones para crear un registro completo en el formato MARC. Opcionalmente, se puede trabajar sobre un subconjunto de registros:

mx base from=<mfn1> to=<mfn2> proc=@migra.prc    # procesa un rango de MFNs
mx base <expresión de búsqueda> proc=@migra.prc  # procesa los resultados de una búsqueda
mx base loop=100 proc=@migra.prc                 # procesa un registro cada 100

Si se desea, se puede subdividir el archivo migra.prc en archivos más pequeños, cada uno de los cuales se ocupa de crear un conjunto específico de campos MARC, p.ej. organizados por rangos de etiquetas (0xx, 2xx-5xx, 6xx, 1xx-7xx, etc.).

Ventajas

Es simple migrar sólo un subconjunto de registros. Esto es muy útil para el testeo de la migración, cuando se desea saber cómo se están migrando registros específicos.
Es posible (aunque opcional) almacenar el código del proceso en un único archivo.
La construcción de cada campo MARC se lleva a cabo en un único lugar del código —independientemente de la cantidad de campos de origen involucrados—, y por lo tanto es más sencillo revisar cómo se arma cada campo del nuevo registro.
Dado que el proceso está guiado por la construcción de campos MARC a partir de los elementos disponibles (y no por la estructura del formato de origen, como sucede en el método 1), el archivo migra.prc puede ser fácilmente reutilizado como plantilla para futuras migraciones a MARC, incluso desde otros formatos.

Desventajas

En el caso de campos de origen que van a parar a más de un campo MARC, hay porciones de código que deben mantenerse sincronizadas en caso de tener que realizar modificaciones; p.ej., el análisis de casos sobre el campo FOCAD 45 (Fecha de publicación) se usa tanto para la creación del 008/06-14 (Fechas codificadas) como para la del 260 $c (Fecha de publicación).

Ejemplos de uso

Este método fue utilizado en la Biblioteca Nacional de Maestros para migrar de CEPAL a MARC 21 (2001-2002).

!–Ejemplo para la Biblioteca Rivadavia (FOCAD) (2006-2007).–!

Otros aspectos

Orden de los campos

El orden de campos en un registro MARC es importante; podemos controlar este orden desde el proceso de creación de campos MARC, o bien podemos usar proc='s' para producir un orden por número de campo (que no es necesariamente el orden correcto).

Puntuación

La puntuación que requieren los registros MARC 21 puede colocarse durante la creación de los campos, o bien en un proceso aparte, una vez creados todos los campos. A menos que haya una razón para tener una versión de la base que use etiquetas MARC pero que carezca de la puntuación, parece más recomendable ocuparse de la puntuación en el mismo momento en que los campos están siendo creados.

Recodificación de caracteres

Si la base de origen tiene la codificación de caracteres usada por MS-DOS (p.ej. si viene de MicroIsis o WinIsis), entonces para trabajar con Catalis será necesario aplicar una recodificación Latin-1. ¿Cuándo conviene realizar esta recodificación, al comienzo o al final del proceso de migración? Si el proceso se va a realizar principalmente en un entorno MS-DOS, entonces es mejor trabajar con la codificación original y dejar la conversión para el final. Debe tenerse en cuenta que la codificación utilizada incide en varios aspectos del trabajo con una base de datos ISIS, cada vez que están involucrados los llamados “caracteres especiales” (i.e. aquellos que no están en la tabla ASCII básica, de 0 a 127):

visualización
conversión a mayúsculas
generación del diccionario (mayúsculas, caracteres alfabéticos)
búsquedas
inserción de contenido (p.ej. si el proceso de migración añade a un campo un texto con acentos como “Incluye referencias bibliográficas”)

Testeo, control de calidad

Testeo de la salida. Validaciones mínimas (e.g. longitud de campo 008, creación de campos vacíos, no más de un campo 1xx, descriptores con mayúsculas). Ejemplos del uso de mx. Testeo automático (completo) vs. testeo humano (parcial usando muestras). Uso de un OPAC para testeo. Ilustrar la naturaleza iterativa del proceso de depuración.
Control de calidad de la migración. Criterios. Errores que pueden cometerse. Errores aceptables.
Generar listado de registros con existencias múltiples donde esté ausente el número de ejemplar y el nro. de parte.

Selección de un conjunto representativo de registros para verificar la calidad de la migración

Monografía ejemplar único
Obra en varios volúmenes
Obra con varios ejemplares
Obra en varios volúmenes y con varios ejemplares
Videos (1 y varios ejemplares)
Autoría personal múltiple
Autoría institucional
Títulos analíticos
Datos de edición incompletos
Notas de resumen
Existencias

Post-migración

Limpieza de la base.

Documentación

Documentación a utilizar durante el proceso: formatos, ISBN, códigos (país, idioma), …
Documentación de todo el proceso: si el trabajo es colaborativo, el uso de un wiki es una buena opción.

Software requerido

mx, versión 5.2

Otros asuntos

Migración de base de publicaciones seriadas

migracion

¹⁾

Solamente en aquellos casos donde el campo 24 Título contiene el apellido que aparece en el campo 22

²⁾

Solamente en aquellos casos donde el campo 20 aparece en MAYUSCULAS

³⁾

personal, institucional, reunión

CatalisWiki

Tabla de Contenidos

Documentación del proceso de migración a MARC 21

Consideraciones básicas

Algunos documentos sobre migración de datos en general

Análisis previo

Análisis de la base

Mapeo de datos

Limpieza de la base

Detección y unión de familias de registros

Criterios

Conversiones de los datos existentes

Moviendo los datos a MARC 21

Nociones generales

Dos métodos de migración

Método 1. Para cada campo de origen, mover sus datos a los campos MARC apropiados

Descripción general

Ventajas

Desventajas

Ejemplos de uso

Método 2. Para cada registro de la base original, crear el correspondiente registro migrado

Descripción general

Ventajas

Desventajas

Ejemplos de uso

Otros aspectos

Orden de los campos

Puntuación

Recodificación de caracteres

Testeo, control de calidad

Selección de un conjunto representativo de registros para verificar la calidad de la migración

Post-migración

Documentación

Software requerido

Otros asuntos