Trabajar con reglas de normalización

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

Para trabajar con reglas de normalización, se debe poseer uno de los siguientes roles:

Administrador de catalogación
Gerente de catálogo
Catalogador

Se utilizan reglas de normalización para cambiar o actualizar metadatos bibliográficos en diferentes etapas como, por ejemplo, cuando se guarda el registro en el Editor de Metadatos, importados a través del perfil de importación, importados desde recursos de búsqueda externos o editados a través del menú "Mejorar el registro" en el Editor de Metadatos. Las reglas de normalización se escriben con una sintaxis específica, lo que permite crear reglas que afecten cambios específicos en los registros. Por ejemplo, se puede editar o borrar un campo, y se puede hacer de manera condicional, según alguna otra condición que tenga lugar o no en el registro bibliográfico.

Las reglas de normalización se pueden aplicar a registros individuales en el Editor MD o a un grupo de registros:

Para aplicar reglas de normalización a un registro individual, utilice la opción Mejorar registro (consulte la sección Opciones de menú y barra de herramientas del Editor MD) o Aplicar cambios a un registro individual, al usar la función de vista preliminar de las reglas de normalización (consulte Vista preliminar del resultado de una regla).
Para aplicar reglas de normalización a un conjunto de registros, se debe crear un proceso usando las tareas MarcDroolNormalization o DcDroolNormalization (véase Trabajar con procesos de normalización) y especificar la regla de normalización que se crea con el Editor MD (ir al procedimiento Crear un nuevo fichero de reglas de normalización). Una vez que se haya creado el proceso, se puede ejecutar una tarea usando dicho proceso (véase Ejecutar tareas manuales en conjuntos definidos). Además, puede crear un proceso que habilite aplicar las reglas de normalización cuando se hace clic en Guardar en el Editor MD (consulte Trabajar con los procesos de normalización).

Las reglas de normalización son creadas siguiendo una sintaxis de programación específica y usando la ventana de edición provista en el Editor MD en la pestaña Reglas.

Ventana de edición de la pestaña Reglas

Además de crear su propio programa de reglas de normalización, puede copiar/pegar reglas existentes en la ventana de edición o utilizar ejemplos predeterminados (pestaña Reglas) para desarrollar sus reglas de normalización. Consultar Sintaxis de las reglas de normalización para más información sobre la sintaxis de las reglas de normalización y ejemplos que se pueden copiar en la ventana de edición.

Al usar la función Vista preliminar en el Editor MD, se puede:

Ver las reglas de normalización y los registros de metadatos unos junto a otros
Tener una vista preliminar del resultado de una regla al ejecutarla en un registro de metadatos
Alternar entre la regla y los cambios de la vista preliminar
Editar reglas y probarlas de inmediato

Para obtener una descripción general breve de las Reglas de normalización, véase Reglas de normalización (6:00).
Para obtener información detallada sobre las Reglas de normalización con ejemplos, vea Reglas de normalización (1 hora).

Crear Reglas de normalización

Esta sección describe cómo crear una regla de normalización o copiar una regla desde la Zona de la Comunidad, trabajar con ficheros de reglas creados previamente y obtener una vista preliminar del resultado de una regla al ejecutarla en un único registro de metadatos. Para más información, vea el área de Reglas de normalización en esta página.

Téngase en cuenta que las reglas de normalización en registros de la ZI que están enlazados a registros de la ZR solo se pueden aplicar en campos locales. Para aplicar reglas de normalización a esos registros, ejecutar las reglas y los procesos de normalización solo en la Institución de la red.

En el caso de miembros de un consorcio de la Zona de red, los usuarios pueden controlar si desean guardar las nuevas reglas en forma local o en una institución de la red. Para realizar esta selección, abrir el área de Registros o Plantillas y dirigirse a Nuevo > Opciones de colocación. Téngase en cuenta que esta selección es por usuario.

Para crear una nueva regla de normalización:

En la página del Editor MD (Recursos > Catalogación > Abrir editor de metadatos), abra el Área de reglas.
Para crear una regla de normalización para un registro MARC o Dublin Core, seleccione Nuevo > Normalización. Se abrirá el cuadro de diálogo Propiedades de reglas de normalización (nueva regla).

Cuadro de diálogo Propiedades de reglas de normalización
Introducir un nombre y una descripción para la regla de normalización.
La palabra "regla" no debe estar en mayúscula si se utiliza en el nombre de la regla. Si se escribe con mayúsculas, la regla no funcionará.

¡No use una barra invertida (\) en el nombre de una regla! Si lo hace, la regla no se podrá usar para la funcionalidad del conjunto de filtros.
Para crear una regla de normalización para un registro MARC, seleccione Drool. Para crear una regla de normalización para un registro DC (Dublin Core), seleccionar 'XSL'.
Seleccionar una opción de acceso, Privado o Compartido Si se selecciona Privado, solo usted podrá trabajar en la regla y dicha regla no podrá incluirse en un proceso de normalización. Si se selecciona Compartido, la regla será compartida entre los catalogadores. En este caso, más de un usuario podrá ver la regla al mismo tiempo y, si dos o más personas tienen la regla abierta para editarla, aparecerá un mensaje de advertencia cuando alguna intente guardar los cambios. (Existe la opción de conservar los cambios propios o permitir que el otro usuario realice y guarde sus propios cambios.)
Seleccionar Guardar. Se abre el panel de edición del Editor MD.
Puede incluir sintaxis de reglas existentes (Editar > Añadir regla > {type of rule}) o definir una regla (para obtener detalles, véase Sintaxis de reglas de normalización).
Seleccionar Guardar. La regla se añade a la lista de ficheros de reglas en la pestaña Reglas de normalización.

Para copiar/contribuir reglas de normalización a la Zona de la Comunidad:

En la página del Editor MD (Recursos > Catalogación > Abrir el editor de metadatos), seleccione la pestaña Reglas y expanda la carpeta de Normalización.
Para copiar, abrir la carpeta Comunidad. Hacer clic derecho sobre la regla que se desea copiar y seleccionar Duplicar.
Se abre el diálogo de Duplicar regla. Indicar su nombre y descripción, e indicar si se desea guardar como regla privada (disponible sobre para usted) o compartida (disponible para todos los usuarios en su institución).
El nombre y el correo electrónico de contacto del usuario de Alma que contribuyó la regla a la ZC se indican en el diálogo; se puede contactar a este usuario en caso de tener preguntas.
Para realizar su propia contribución a la ZC, hacer clic derecho sobre la regla y seleccionar Contribuir a la ZC.
Se abre el diálogo de Compartir regla. Proporcionar un nombre descriptivo y una descripción, y seleccionar Guardar para guardar la regla en la ZC.

Para trabajar con una regla de normalización existente:

En la página del Editor MD (Recursos > Catalogación > Abrir el editor de metadatos), seleccione la pestaña Reglas y expanda la carpeta Normalización para mostrar las reglas guardadas.
Seleccionar la regla con la que se desea trabajar y seleccionar una de las siguientes opciones:
- Editar – Abre el cuadro de texto con la sintaxis de la(s) regla(s) que permite su modificación (para más detalles, véase Sintaxis de reglas de normalización).
- Borrar – Seleccionar Sí para confirmar la eliminación del fichero de reglas.
- Duplicar – Duplica la regla seleccionada y permite modificarla y guardarla como una nueva regla, sin afectar la regla original.
- Propiedades – Abre el cuadro de diálogo Propiedades de reglas de normalización, permitiendo modificar las propiedades del fichero de reglas.
Para cambiar el nombre de la regla, duplicar la regla, dar el nombre deseado al duplicado y luego borrar la regla vieja.

Para realizar una vista preliminar y guardar y probar el resultado de una regla:

Ubicar el registro bibliográfico con el que se desea trabajar (usando la pestaña Búsqueda en el repositorio o dentro del Editor MD > Registros) y abrirlo en el Editor MD.
Pulse (F6) o seleccione el icono Dividir editor.
Seleccione la pestaña Reglas en el panel izquierdo y expanda la carpeta Normalización.
Seleccione con el botón derecho la regla para la que desea obtener una vista preliminar o que quiere probar en la carpeta Privado o Compartido (no Comunidad) y seleccione Editar.

La regla se muestra en el panel derecho del Editor de metadatos.
Seleccionar Vista preliminar. La regla se aplica al registro y aparece el resultado.

Para actualizar registros de Red, la normalización debe ser ejecutada por la institución de la Red (no por un miembro). Una institución no puede actualizar registros de Red, por lo tanto, la normalización se aplicará solo en los campos locales (las extensiones locales del miembro). En la vista preliminar de una regla para un registro de red, se muestra el siguiente mensaje: Se debe tener en cuenta que las reglas se aplicarán solo a los campos locales cuando se ejecute el proceso de normalización.

Seleccionar Aplicar cambios para guardar las modificaciones del registro o seleccionar Regresar a reglas de normalización para realizar más ediciones.
Cuando se hayan realizado los cambios finales a la regla de normalización, seleccionar Guardar y probar utilizando un registro externo para guardar la versión final de la regla de normalización. Para obtener detalles, véase Probar reglas de normalización para fuentes de datos externos.

Reglas de normalización para registros de Dublin Core

En el Editor de metadatos, existen los siguientes tipos de reglas relacionadas con Dublin Core:

Reglas de indicación XSL
Regla de normalización XSL

La Regla de normalización de XSL no admite discovery:local.

Las Reglas de normalización de Dublin Core no se pueden escribir en un formato de Regla de normalización habitual, solo como un XSL. Esto significa que se redacta el XSL directamente en el Editor de metadatos (como se explicó anteriormente), o bien se puede redactar en Notepad (u otra aplicación externa que se elija) y luego copiarla al Editor de metadatos.

Se pueden ver los siguientes ejemplos de Reglas de normalización de XSL en la Zona de la Comunidad, en el Editor de metadatos:

EXL: Cambiar el valor dc:language en a Inglés
EXL: Regla genérica que reemplaza la secuencia en el registro Dublin Core
EXL_Add_field_accessRights

Para escribir XSL para Dublin Core:

Escribir el XSL en la aplicación externa que se elija.
Abra el Editor de metadatos > sección de Reglas.
Copiar y pegar el XSL en el Editor de metadatos y guardar la regla.

Reglas de normalización para Primo VE y Esploro.

Además de las reglas de normalización de Alma, puede crear reglas de normalización para Primo VE y Esploro. Para crear estas reglas, clicar Nueva y luego seleccionar:

Normalización (Descubrimiento) - Esta opción aparece solo si Primo VE está definido en el sistema. Seleccionar esta opción si se crearán reglas de normalización DC o XML para registros bibliográficos cargados en Primo VE y no gestionados en Alma. Para obtener información sobre la sintaxis de estas reglas, véase Sintaxis de reglas de normalización para formatos DC y XML.
Normalización (Investigación) - Esta opción aparece solo si Esploro está definido en el sistema. Para obtener más detalles, véase Gestionar reglas de normalización de activos (Esploro).

Sintaxis de las reglas de normalización

La regla puede contener una o varias reglas. Cada regla contiene una condición y una o más acciones para aplicar a los registros. Las acciones se aplican a un registro si el registro cumple con la condición. Cada acción se puede realizar en un único campo dentro de un registro. Las acciones se llevan a cabo en el orden en que aparecen en la regla.

Al definir una regla que contenga reglas múltiples, se debe usar el factor de prioridad (o prominencia). Las acciones estipuladas en la regla con prioridad más alta se ejecutan primero. Por ejemplo, la acción de una regla con prioridad 2 se ejecuta antes que la acción de una regla con prioridad 1. Para ejemplos de la forma en que la prioridad (o prominencia) puede ser usada en reglas de normalización, vea Ejemplos de reglas de normalización en Alma. Observe que la prioridad (o prominencia) solo es necesaria cuando los campos en las reglas son los mismos. De lo contrario, cuando cada regla trata con diferentes campos, múltiples reglas se ejecutan de arriba hacia abajo.

Aprenda más sobre la creación de reglas de normalización en el vídeo Reglas de Normalización (11 min).

Para aprender a crear reglas de normalización que borren campos específicos de los registros o que cambien los contenidos de estos campos, véase el vídeo Sintaxis de rutina de normalización para la eliminación o modificación de contenido (9:57 min.).

When
 (<conditions on MARC record>) then
 Action
 End

<conditions on MARC record> contiene una o más cláusulas booleanas que se aplican al registro. Si <conditions on MARC record> devuelve TRUE, la regla se aplica al registro; de lo contrario, la regla no se aplica y el registro no es procesado.

“When” debe ser la única palabra en la primera línea. La condición debe ubicarse en una línea separada.
Puede usar múltiples condiciones en el registro completo solo en la condición "Cuando". Cada regla debe tener solo una acción (después de la línea "Entonces"). Si desea usar varias acciones después de la línea "Entonces", divida esto en varias reglas, cada una con una sola acción.
Aunque se permite incluir varios operadores booleanos en las reglas, cuando son seleccionados un gran número de operadores booleanos, es probable que el rendimiento se ralentice. Por lo tanto, cada regla debe incluir como máximo 200 operadores booleanos.
Si no se especifica, la condición funcionará a nivel de registro. Si desea que la condición funcione en cada campo MARC21 por separado, deberá especificar la condición por campo. Por ejemplo, cuando hay varios campos MARC21 con la misma etiqueta.

Tenga en cuenta que cuando usa barras invertidas no puede utilizar un número impar de barras invertidas como, por ejemplo, \z o \\\z. Sin embargo, se admite el uso de una sola barra invertida en las siguientes secuencias de escape:

En general, debe usar una doble barra invertida (\\) para secuencias de escape.

Usar un número impar de barras invertidas producirá el siguiente error: "Secuencia de escape inválida (las válidas son \b \t \n \f \r \" \' \\ )"

Los siguientes son algunos ejemplos de correcciones que se pueden aplicar a las reglas cuando ocurre este error que mantienen el comportamiento de la regla existente:

reemplazar \\\ con \\
reemplazar \. con .
reemplazar \ con \\
reemplazar \( con (
reemplazar \) con )
reemplazar \\\| con \\|

Elementos de registro

Las condiciones y acciones se aplican a los elementos del registro, como el registro MARC, los campos (uno o más), los indicadores, los subcampos (uno o más) y el contenido de campos/subcampos.

Para probar una condición o aplicar una acción a un elemento del registro, el elemento debe coincidir con la siguiente sintaxis:

Sintaxis
Expresión	Significado
"<tag>", "<new tag>"	Representa una etiqueta de campo, por ejemplo, 001, 245, etc.
"<oldCode>", "<newCode>"	Representa un código de subcampo, por ejemplo, a, b, c.
"<element>" para un campo de datos	Los siguientes son valores posibles para el campo de datos: FIELD – por ejempo: 245 FIELD_VALUE – por ejemplo: 245.value* FIELD_INDICATOR – por ejemplo: 245.{1,2} FIELD_SUBFIELD_CODE – por ejemplo: 245.a FIELD_INDICATOR_SUBFIELD_CODE – por ejemplo: 245.{1,2}.a FIELD_SUBFIELD_CODE_VALUE – por ejemplo: 245.a.value* FIELD_INDICATOR_SUBFIELD_CODE_VALUE – por ejemplo: 245.{1,2}.a.value*
"<element>" para un campo de control	Los siguientes son valores posibles para un campo de control: FIELD_POSITION_LENGTH – por ejemplo: LDR.{17,3} FIELD_POSITION_LENGTH_VALUE – por ejemplo: LDR.{17,3}.eng
"<elemento>" para un campo de posición fija.	Los siguientes son valores posibles para un campo de posición fija UNIMARC/CNMARC 1XX: FIELD – por ejemplo: 100 FIELD_VALUE – for example: 100.{,}..{,}.value FIELD_INDICATOR – for example: 100.{1,2} FIELD_SUBFIELD_CODE – for example: 100.a FIELD_INDICATOR_SUBFIELD_CODE – for example: 100.{1,2}.a FIELD_SUBFIELD_CODE_VALUE – for example: 100.a.value* FIELD_INDICATOR_SUBFIELD_CODE_VALUE – por ejemplo: 100.{1,2}.a.{,}.value* FIELD_POSITION_LENGTH – for example: 100.{,}.a.{17,3} FIELD_POSITION_LENGTH_VALUE – por ejemplo: 100.{,}.a.{17,3}.* Relevante solo para campos UNIMARC/CNMARC 1XX.
CONDICIÓN a nivel del registro	Las siguientes son opciones de condición posibles. Consultar la siguiente sección (Condiciones) para conocer información importante. TRUE – siempre verdadero not exists "{element}" – verdadero si el elemento no existe (para campos de datos) not existsControl "{element}" – verdadero si el elemento no existe (para campos de control) exists "{element}" – verdadero si el elemento existe al menos una vez (para campos de datos) existsControl "{element}" – verdadero si el elemento existe al menos una vez (para campos de control) existsMoreThanOnce "{element}" – verdadero si el elemento existe más de una vez. Para obtener un ejemplo del uso de esta condición, véase Reglas de indicación para registros MARC - Ejemplos de sintaxis. contains – verdadero si el elemento contiene un valor. Usado para reglas de fusión. Las siguientes son las posibles opciones de condición relevantes solo para campos UNIMARC/CNMARC 1XX: existsFixedField "{element}" - true if the element does not exist (for data of 1XX fixed position fields) not existsFixedField "{element}" - Verdadero si el elemento no existe (para datos de campos de posición fija 1XX)

Condiciones

Las condiciones pueden ser definidas al nivel de toda una regla (WHEN), o al nivel específico de una acción (IF). La misma condición se comportará diferente según el nivel para el que esté definida.

Cláusula WHEN – Una condición que debe ser satisfecha por el registro entero para determinar si la regla se aplica al registro
IF (dentro de una acción) – Una condición que se aplica a un único campo para determinar si la acción específica debe llevarse a cabo en ese campo

Las condiciones pueden ser:

containsScript: Use esta condición pra detectar un idioma específico. La condicióncontainsScript usa la siguiente lista fija de idiomas para los cuales puede revisar: Árabe, armenio, bengalí, bopomofo, braille, buhid, canadiense_aborigen, cherokee, cirílico, devanagari, etíope, georgiano, griego, gujarati, gurmukhi, han, hangul, hanunoo, hebreo, hiragana, heredado, kannada, katakana, khmer, lao, latín, limbu, malayalam, mongol, myanmar, ogham, oriya, rúnico, cingalés, siríaco, tagalog, tagbanwa, taiLe, tamil, telugu, thaana, tailandés, tibetano y yi. Véase el ejemplo siguiente de sintaxis:

regla "Es CJK en autoridad"
cuando
containsScript "Han" "1**"
entonces
establecer indicación."verdadero"
fin
exists <element> – Se encuentra al menos una coincidencia
- exists <element> – Se aplica a los campos de datos. Al utilizarla en una cláusula IF, tanto el elemento de la acción como el elemento evaluado por la condición deben ser el mismo campo (de datos).
- existsControl <element> – Se aplica a los campos de control. Al utilizarla en una cláusula IF, tanto el elemento de la acción como el elemento evaluado por la condición deben ser el mismo campo (de control).
existsMoreThanOnce <element> – Se encuentran múltiples coincidencias. Se aplica a campos de datos. Al utilizarla en una cláusula IF, tanto el elemento de la acción como el elemento evaluado por la condición deben ser el mismo campo (de datos).
not exists <element> – No se encuentran coincidencias
- not exists <element> – Se aplica a los campos de datos. Al utilizarla en una cláusula IF, tanto el elemento de la acción como el elemento evaluado por la condición deben ser el mismo campo (de datos).
- not existsControl <element> – Se aplica a los campos de control. Al utilizarla en una cláusula IF, tanto el elemento de la acción como el elemento evaluado por la condición deben ser el mismo campo (de control).
recordHasDuplicateSubfields (para reglas de indicación, véase Trabajar con reglas de indicación) – Devuelve el valor verdadero si se encuentran subcampos duplicados (subcampo y sus contenidos) para el registro actual según los campos, subcampos y los caracteres a ignorar (charsToIgnore) cadena que se pasó como parámetros en el siguiente formato:

recordHasDuplicateSubfields "<tag>" "<code>" "<charsToIgnore>"

Se pueden especificar múltiples etiquetas (campos) separados por comas. Se pueden especificar múltiples códigos (subcampos) sin espacios para separarlos. Uno o más caracteres (alfanumérico o puntuación) sin espacios de separación se pueden especificar como caracteres que se ignorarán al final del contenido en los subcampos que se evalúan para duplicar. Véase Ejemplo 6 para más información.

Se crea un conjunto de registros que cumplen con la condición recordHasDuplicateSubfields (devuleve el resultado verdadero).

Cada acción de una cláusula IF puede tener uno de los siguientes formatos:

Se aplica si una condición específica no es verdadera, por ejemplo: addControlField "{element}" if(not exists "{condition}")
Se aplica si una condición específica es verdadera, por ejemplo: addControlField "{element}" if(exists "{condition}")
Se aplica incondicionalmente, por ejemplo: addControlField "{element}"

El operador booleano OR puede usarse en una afirmación de consecuencia al usar el símbolo de la barra vertical (|); por ejemplo: removeField "866" si (no existe"866.8.0|99") Si la pleca es parte del valor, utilizar cuatro barras invertidas (\\\\) para escaparlo, por ejemplo: removeField "866" si (existe "866.8.0\\\\|99")

Hay un problema detectado en el que no se logra escapar la "|". Se corregirá en las próximas versiones.

Lista de acciones

La siguiente tabla ofrece una lista de acciones disponibles.

Lista de acciones
Acción	Formato / Ejemplo	Comentario
Reemplazar campos y subcampos con otros campos y subcampos	changeControlField "<tag>" to "<new tag>" Ejemplo: changeControlField "007" to "008"	Cambia el identificador de etiqueta de un campo controlado; no modifica los contenidos.
	changeField "<tag>" to "<new tag>" Ejemplo: changeField "245" to "246"	Cambia el identificador de etiqueta; no modifica los indicadores ni los subcampos.
	changeSubField "<tag>.<code>" to "<new code>" changeSubFieldOnlyFirst "<tag>.<code>" to "<new code>" changeSubFieldExceptFirst "<tag>.<code>" to "<new code>" Ejemplo: changeSubField "035.b" to "a"	Cambia los subcampos (o solo el primer subcampo, o todos excepto el primer subcampo) "<code>" por el subcampo "<new code>" en el campo "<tag>".
	changeFirstIndicator "<tag>" to "<value>" changeSecondIndicator "<tag>" to "<value>" Ejemplo: changeFirstIndicator "245" to "3"	Establece el valor del indicador especificado en la etiqueta <tag>.
	combineFields "<tag>" excluding "<comma-separated subfield list>" Ejemplo: combineFields "852" excluding "a,b"	Combinar todos los campos del número especificado. Copiar todos los subcampos de la segunda línea y las subsiguientes líneas a la primera línea, excluyendo los subcampos nombrados; solo las primeras ocurrencias de los subcampos excluidos son copiadas, y solo si no existen ya en la primera línea.
Añadir campos y subcampos	addField "<tag>.<code>.<value>" addField "<tag>.{<ind1>,<ind2>}.<code>. <value>" Ejemplo: addField "999.a.RESTRICTED"	Añadir el campo al registro MARC. Establecer el valor indicado como el valor del subcampo.
	addControlField "<tag>.<value>" Ejemplo: addControlField "008.820305s1991####nyu###########001#0#eng##"	Añade el campo controlado al registro MARC.
	addSubField "<tag>.<code>.<value>" addSubField "<tag>.{<ind1>,<ind2>}.<code>.<value>" Ejemplo: addSubField "245.h.[Journal]"	Añade el subcampo <code> con el valor <value> al campo <tag>. Si el campo no existe, no se hace nada.
	addSystemNumber "<element>" from "<tag>" prefixed by "<prefix tag>" Ejemplo: addSystemNumber "035.a" from "001" prefixed by "003"	Iguala el campo de datos <element> a los contenidos del segundo campo de control <prefix tag> entre paréntesis seguido de los contenidos del primer campo de control <tag>. Por ejemplo: si 001 tiene el valor 9945110100121 y 003 tiene el valor DAV, la condición del ejemplo a la izquierda producirá 035 con el valor ‡(DAV)9945110100121.
Copia campos	copyField "<tag>" to "<new tag>" copyField "<tag>.<code>" to "<new tag>.<new code>" copyField "<tag>" to "<new tag>.{<ind1>,<ind2>}" Ejemplo: copyField "971.a" to "100.u"	Copia el campo a otro campo. En la primera versión, los subcampos no están especificados (<code> y <new code>), y el nuevo campo contiene los mismos subcampos que el campo anterior. En la segunda versión, si tan solo <new code> no está especificado, el nuevo subcampo es igual al especificado para <code>. copyField crea un campo separado en lugar de agregarlo a un campo existente. Puede que se desee combinar el nuevo campo con un campo combinado (consultar combineFields).
Elimina campos y subcampos	removeControlField "<tag>" Ejemplo: removeControlField "009"	Elimina todas las ocurrencias del campo controlado. Tenga en cuenta que si elimina el campo de control 008, Alma vuelve a crearlo inmediatamente si usted no lo hace. Considere volver a añadir el campo después de eliminarlo, por ejemplo: Regla"remove 008" si (VERDADERO) luego removeControlField "008" addControlField "008.######s2013####xx######r#####000#0#eng#d" fin
	removeField "<tag>" Ejemplo: removeField "880"	Elimina todas las ocurrencias del campo <tag>.
	removeSubField "<tag>.<code>" Ejemplo: removeSubField "245.h"	Elimina todas las ocurrencias del subcampo <code> del campo indicado.
Substituye texto en campos o subcampos	replaceControlContents "<tag>.{<position>,<length>}. <value>" with "<new value>" Ejemplo: replaceControlContents "LDR.{7,1}.s" with "m"	Reemplaza <value> por "<new value>" en la posición inicial <position> hasta <position>+<length> del campo de control <tag>. Substituye solo el texto que coincide con <value>.
	replaceContents "<tag>.<code>.<value>" with "<new value>" replaceContentsOnlyFirst "<tag>.<code>.<value>" with "<new value>" replaceContentsExceptFirst "<tag>.<code>.<value>" with "<new value>" Ejemplo: replaceContents "245.h.[Journal]" with "[Book]"	Substituye las cadenas coincidentes (o cada instancia de la cadena coincidente en el primer subcampo coincidente, o todas las cadenas coincidentes en todos los subcampos coincidentes excepto el primer subcampo coincidente) <value> en el subcampo <code> del campo "<tag>" con "<new value>". La cadena o parte de la cadena que no coincida con <value> no se modificará.
	replaceSubFieldContents "<tag>.<code>" with "<tag>.<code>" Ejemplo: replaceSubFieldContents "245.b" with "100.a"	Substituye los contenidos del subcampo por contenidos de otro subcampo.
	replaceFixedContents "<tag>.{<1_ind>,<2_ind>}.<code>.{<position>,<length>}.<value>" with "<new value>" Example: replaceFixedContents "100.{1,2}.a.{0,8}.20150226" with "20220724"	Reemplaza <valor> por <valor nuevo> en campos de posición fija UNIMARC y CNMARC. Relevante solo para campos UNIMARC/CNMARC 1XX.
Añade texto en subcampos	prefix "<tag>.<code>" with "<value>" Ejemplo: prefix "035.b" with "(OCoLC)"	Añade un prefijo al valor del subcampo "<code>"en el campo "<tag>". El nuevo valor será <value> seguido del valor anterior.
	prefixSubField "<tag>.<code>" with "<source tag>.<source code>" Ejemplo: prefixSubField "910.a" with "906.a"	Añade el valor del subcampo "<source code>" en el campo "<source tag>" como prefijo del subcampo "<code>" en el campo "<tag>". El nuevo valor será el valor del subcampo "<source code>" en el campo "<source tag>" seguido del valor anterior.
	suffix "<tag>.<code>" with "<value>" Ejemplo: suffix "035.b" with "(OCoLC)"	Añade un sufijo al valor del subcampo "<code>" en el campo "<tag>". El nuevo valor será el valor anterior seguido de <value>.
	suffixSubField "<tag>.<code>" with "<source tag>.<source code>" Ejemplo: suffixSubField "910.a" with "907.c"	Añade el valor del subcampo "<source code>" en el campo "<source tag>" como sufijo del subcampo "<code>" en el campo "<tag>". El nuevo valor será el valor anterior seguido del valor del subcampo "<source code>" en el campo "<source tag>".
Mantener información de agencia en registros bibliográficos y de autoridad Por ejemplo, esta sintaxis puede usarse en reglas de normalización que estén seleccionadas en la Lista de tareas de configuración de metadatos bibliográficos MARC 21 para normalizar los registros bibliográficos de la Zona de red al guardar. Esta función está en construcción. Para activar esta sintaxis, contactar al soporte de Ex Libris.	addCreatingAgency "<tag>.<code>" Ejemplo: addCreatingAgency "040.a"	Añade el código ISIL de la agencia creadora al subcampo "<code>" en el campo "<tag>".
	addModifyingAgency "<tag>.<code>" Ejemplo: addModifyingAgency "040.d"	Añade el código ISIL de la agencia modificadora al subcampo "<code>" en el campo "<tag>". Si ya hay una agencia modificadora en "<tag>.<code>", añade otro código ISIL de agencia.
	replaceModifyingAgency "<tag>.<code>" Ejemplo: replaceModifyingAgency "040.d"	Añade el código ISIL de la agencia modificadora al subcampo "<code>" en el campo "<tag>". Si ya existen agencias modificadoras en "<tag>.<code>", son todas substituidas.
Dividir subcampos	splitSubField "<tag>.{ind1,ind2}.<code>.<delimiter>" to "<tag>.{<ind1>,<ind2>}.<code>" addSeq "<code>" Ejemplo 1: splitSubField "866.a.;" to "555.{0,0}.a" addSeq "8" Ejemplo 2: splitSubField "555.a.;" – " to "859.{0,0}.a" addSeq "8" Ejemplo 3: splitSubField "859.a.\\\\." Ejemplo 4: splitSubField "999.a.;" to "555.a" addSeq "8"	La etiqueta es obligatoria. Los indicadores son opcionales. Dado que la división se produce en el nivel del subcampo, el código es obligatorio. El delimitador puede ser cualquier cadena. Si el delimitador no existe, el subcampo completo se copia como la primera (y única) ocurrencia, y la secuencia es añadida. El componente to es opcional. Si está especificado, se crean múltiples ocurrencias del tag.code to, cada una con los datos hasta el delimitador. Ver los ejemplos 1 y 2. Si el componente to no está especificado, el subcampo se divide en los mismos subcampos adicionales en el mismo campo, como se muestra en el ejemplo 3. El componente addSeq es opcional. No es relevante si el componente to no está especificado. Cuando se especifica addSeq, el subcampo con una secuencia será añadido como en el ejemplo 1; y si el subcampo ya existe en el campo original, una secuencia (precedida de un punto) se añadirá a ese campo, como en el ejemplo 2.
Eliminar subcampos duplicados	correctDuplicateSubfields "<tag>" "<code>" Ejemplo: Elimina los subcampos duplicados x, y, z de los campos 610 y 630. regla "Eliminar duplicados" prioridad 1 cuando (VERDADERO) luego correctDuplicateSubfields "610,630" "xyz" final	Corrige los subcampos duplicados (por ejemplo, subcampos con el mismo código Y valor) manteniendo el primero y eliminando los demás del registro actual según los campos y subcampos que se hayan pasado como parámetros. Se puede usar recordHasDuplicateSubfields para crear el conjunto de la regla de normalización que utiliza correctDuplicateSubfields. Véase Ejemplo 6 para más información. Para la deduplicación de subcampos con valores diferentes, véase: Cómo eliminar todos menos uno de varios subcampos similares en el mismo campo del Editor de metadatos.
Mover subcampos	moveSubfieldsToEndOfField "<tag>" "<code>" Ejemplo: Mueve los subcampos 9 y 2 al final del campo 650. regla "Mover subcampos al final del campo" prioridad 1 cuando (VERDADERO) luego moveSubfieldsToEndOfField "650" "92" final	Mueve la primera ocurrencia de cada subcampo al final del campo y elimina las demás ocurrencias del mismo subcampo. Si se especifica más de un subcampo, estos se colocan al final en la misma secuencia, según se indique en la regla. En este ejemplo, el subcampo 9 se coloca al final seguido del subcampo 2. Tenga en cuenta que la declaración si no es compatible con la acción moveSubfieldsToEndOfField.
Corregir campos duplicados del registro actual	correctDuplicateFields "{fields}" Ejemplo: correctDuplicateFields "610,630,650"	Esta acción toma un parámetro, campos, que contiene valores de campos separados por coma como 610,630,650. Esta acción corrige campos duplicados del registro actual de acuerdo a los campos que se aprobaron como parámetros.
Buscar campos duplicados (Reglas de indicación; véase Trabajar con reglas de indicación)	recordHasDuplicateFields "{fields}" Ejemplo: correctDuplicateFields "610,630,650"	Esta acción toma un parámetro, campos, que contiene valores de campo separados por coma como 610,630,650. Esta acción puede ser verdadera o falsa. El resultado es verdadero si se encuentran campos duplicados en el registro actual de acuerdo a los campos que se aprobaron como parámetro.

Comodines y caracteres especiales

Si bien no se admite actualmente el uso de expresiones regulares en las Reglas de normalización de Alma en su totalidad, se pueden usar algunas expresiones regulares. Para ver algunos ejemplos, consulte Ejemplos de reglas de normalización de Alma.

El separador de subcampo ($$) no puede aparecer en ningún lugar de la regla, incluyendo el nombre de regla.

El carácter de almohadilla (#) al principio de una línea indica que el resto de la línea es un comentario y debe ser ignorada al procesar la regla.

El asterisco (*) se usa para establecer coincidencias con cualquier cadena, incluso una cadena de longitud cero. Por ejemplo, "<tag>.<*>.<value>" se aplica a todos los subcampos en la etiqueta <tag>que tengan el valor <value>. * es "voraz", de modo que establecerá coincidencias con tantos caracteres como sea posible en la cadena. Por ejemplo: si posee una cadena "a b c b d b e", el patrón "b*b" coincidirá con "b c b d b", y no solo con "b c b".

Los indicadores vacíos (pero no los campos ni subcampos) se indican con un guión (-). Por ejemplo, "<tag> {-,<ind2>}" devuelve todos los campos en los que la etiqueta MARC sea <tag>, el primer indicador no está definido, y el segundo indicador es <ind2>.

Si el texto de un subcampo contiene un punto como último carácter, utilice cuatro barras invertidas para establecer una coincidencia con el punto. Por ejemplo:

rule "Replace '1 v.' to 'Leaves' in $a (unconditional)"
 when
 (TRUE)
 then
 replaceContents "300.a.1 v\\\\." with "Leaves"
 end

Las comillas dobles (solo) pueden usarse en las condiciones. Para usar comillas dobles como parte de una condición, utilizar comillas simples para encerrar el texto de la regla (') en lugar de comillas dobles ("). De este modo, podrá usar comillas dobles dentro del texto a continuación de dos barras invertidas (\\).

rule "populate 008 7-10 2016"
 when
 (exists '245.{*, }.c.\"')
 then
 replaceControlContents "008.{7,4}" with "2016"
 end

Las fechas en hebreo (solo) pueden usarse en las condiciones. (El hebreo se lee de derecha a izquierda, de modo que las dos barras invertidas en el siguiente ejemplo en realidad están antes de las comillas dobles.)

rule "populate 008 7-10 2016"
 when
 ((exists '260.{*, }.c.תשע\\"ו') OR (exists '264.{*, }.c.תשע\\"ו'))
 then
 replaceControlContents "008.{7,4}" with "2016"
 end

No pueden usarse comodines como primer carácter de una condición o un valor.
Para usar una barra invertida (\) como tal, utilizar una barra adicional para escaparla: \\.
Utilizar cuatro barras invertidas (\\\\) para escapar un punto que sea el último carácter de una cadena. Cuando el punto es seguido inmediatamente por otro caracter, no requiere de cuatro barras invertidas (como en addField "907.a.F.L.T\\\\."). Sin embargo, es una práctica recomendada utilizar siempre cuatro barras invertidas en la regla de normalización para asegurarse de que los resultados deseados sean consistentes. Véase los siguientes ejemplos:
Como se indicó más arriba, si se utiliza una comilla doble (solo) en una condición que es escapada usando comillas simples, o una comilla simple que es escapada usando comillas simples, se debe usar, a su vez, dos barras invertidas para escapar la comilla doble o simple.
Si la pleca es parte de la condición, utilice cuatro barras invertidas (\\\\) para escaparla, por ejemplo: removeField "866" if (exists "866.8.0\\\\|99"). Esto solo es necesario cuando se usa la pleca en la condición.

Ejemplo: uso del punto en una regla de normalización con replaceContents

Ejemplo de registro con puntos:

245 00 $$a Feminist literary theory. : $$b a reader / $$c edited by Mary Eagleton.

246 0# $$a F.L.T.

Regla de normalización para el ejemplo anterior:

rule "remove the periods in 245 and 246 subfield a (and replace periods with nothing); precede period with four backslashes"
 when
 (TRUE)
 then
 replaceContents "245.a.\\\\." with ""
 replaceContents "246.a.\\\\." with ""
 end

Ver la figura a continuación para ejemplos del antes y el después.

Before_and_After_Examples_of_Normalization_Rule with_Periods_Using_ replaceContents_02.png

Ejemplos del antes y el después

Ejemplo: uso del punto en una regla de normalización con addField

A continuación hay un ejemplo de un registro al que deben añadírsele puntos:

906 $$a Architecture.

907 $$a F.L.T.

A continuación se halla la regla de normalización para el ejemplo anterior, en la que se emplea la práctica recomendada de incluir siempre barras invertidas:

rule "Add field 906 with text Architecture and period at end and also add field 907 with F.L.T."
 salience 100
 when
 TRUE
 then
 addField "906.a.Architecture\\\\."
 addField "907.a.F\\\\.L\\\\.T\\\\."
 end

Véase la figura a continuación para ejemplos del registro antes y después.

Before_and_After_Examples_of_Normalization_Rule with_Periods_Using_ addField_02.png

Ejemplos del antes y el después

Ejemplos de reglas de normalización

Para consultar una lista de más de 50 ejemplos de reglas de normalización y otros documentos relacionados con reglas de normalización, véase Reglas de normalización.