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.
mxf0, mxtb). Ver mxf0.pft, Análisis de la base de datos BR con mxf0.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 |
<html><p> </p></html>
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, 221) |
| 653 - Descriptor | 65, 202) |
| 700 - Nombre personal | 28, 22, 65 (videos) |
| 710 - Nombre institucional | 29, 23 |
| 720 - Nombre no controlado3) | 28, 29, 22, 23 |
| 730 - Título uniforme | ?? |
| 740 - Título relacionado/analítico | 20 |
| 859 - Existencias | 75, 78, … |
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.Criterios. Ejemplos. Testeo.
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
Estos cambios se pueden realizar mediante gizmos.
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:
<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:
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.
.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).Este método fue utilizado en la Biblioteca Central de la UNS para migrar de FOCAD a MARC 21.
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.).
migra.prc puede ser fácilmente reutilizado como plantilla para futuras migraciones a MARC, incluso desde otros formatos.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).–!
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).
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.
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):
migracion