Trabalhando com Regras de Normalização
Para trabalhar com regras de normalização, você deve ter as seguintes funções:
- Administrador de Catálogo
- Gerente de Catálogo
- Catalogador
As regras de normalização são usadas para alterar ou atualizar metadados bibliográficos em vários estágios, por exemplo, quando o registro é salvo no Editor de Metadados, importado via perfil de importação, importado de uma fonte de busca externa ou editado por meio do menu "Melhorar o registro" no Editor de Metadados. As regras de normalização são escritas em uma sintaxe específica, permitindo que você crie regras para afetar mudanças específicas nos registros. Por exemplo, você pode editar ou excluir campos, e também pode fazer isso condicionalmente, com base em alguma outra condição existente ou não no registro bibliográfico.
As regras de normalização podem ser aplicadas a registros individuais no Editor de MD ou a um grupo de registros:
- Para aplicar regras de normalização a um registro individual, use a opção Melhorar Registro (consulte a seção Opções de Menu e Barra de Ferramentas do Editor de MD) ou Aplicar Alterações ao pré-visualizar regras de normalização (veja Para pré-visualizar o resultado de uma regra).
- Para aplicar regras de normalização a um conjunto de registros, você deve criar um processo usando as tarefas MarcDroolNormalization ou DcDroolNormalization (veja Trabalhando com Processos de Normalização) e especificar a regra de normalização criada com o Editor de MD (consulte o procedimento Para criar um novo arquivo de regra de normalização). Depois de criar o processo, você pode executar um serviço que o utiliza (veja Executar Serviços Manuais em Conjuntos Definidos). Além disso, você pode criar um processo que permitirá a aplicação de regras de normalização ao clicar em Salvar no Editor de MD (veja Trabalhando com Processos de Normalização).
As regras de normalização são criadas seguindo uma sintaxe de programação específica e usando a janela de edição fornecida na aba Regras do Editor de MD.
Janela de Edição da Aba Regras
Além de criar seu próprio programa de regras de normalização, você também pode copiar/colar regras existentes na janela de edição ou usar exemplos out-of-the-box (aba Regras) para desenvolver suas regras de normalização. Veja Sintaxe das Regras de Normalização para mais informações sobre a sintaxe das regras de normalização e exemplos que você pode copiar para a janela de edição.
Usando a funcionalidade de Pré-visualização do Editor de MD, você pode:
- Visualizar as regras de normalização e os registros de metadados lado a lado
- Pré-visualizar o resultado de uma regra quando executada em um registro de metadados
- Alternar entre a regra e as alterações da pré-visualização
- Editar regras e testá-las imediatamente
- Para uma breve visão geral das regras de normalização, assista Regras de Normalização (6:00).
- Para informações detalhadas sobre Regras de normalização com exemplos, assista Regras de Normalização (1 hr) (em inglês).
Criar Regras de Normalização:
Esta seção descreve como criar uma regra de normalização ou copiar uma regra da Área da Comunidade, trabalhar com regras criadas anteriormente e pré-visualizar o resultado de uma regra quando ela for executada em um único registro de metadados. Para mais informações, consulte a área Regras de Normalização nesta página.
Observe que regras de normalização em registros da IZ que possuem link com registros da NZ podem ser aplicadas somente a campos locais. Para aplicar regras de normalização a tais registros, execute as regras e os processos de normalização somente na instituição da Rede.
Para participantes da Área da Rede, usuários podem controlar se desejam salvar novas regras localmente ou em uma instituição da rede. Para fazer esta seleção, abra a área de Registros ou de Modelos e vá para Novo > Opções de Localização. Observe que esta seleção é feita por usuário.
- Na página do Editor de MD (Recursos > Catalogação > Abrir Editor de Metadados), abra a área de Regras.
- Para criar uma regra de normalização para um registro MARC ou Dublin Core, selecione Novo > Normalização. A caixa de diálogo Propriedades das Regras de Normalização (Nova Regra) será aberta.
Caixa de Diálogo Propriedades das Regras de Normalização. - Insira um nome e uma descrição para a regra de normalização.A palavra "regra" não deve estar em letras maiúsculas se for usada no nome. Se estiver, a regra não funcionará.
Não use barras invertidas (\) no nome da regra! Se for usada, a regra não poderá ser usada para a funcionalidade de filtrar conjuntos. - Para criar uma regra de normalização para um registro MARC, selecione Drool. Para criar uma regra de normalização para um registro DC (Dublin Core), selecione “XSL”.
- Selecione uma opção de acesso, Privado ou Compartilhado. Se você selecionar Privado, somente você poderá trabalhar na regra e ela não poderá ser incluída em um processo de normalização. Se você selecionar Compartilhado, sua regra será compartilhada com os catalogadores. Nesse caso, mais de um usuário poderá visualizar a regra ao mesmo tempo; se duas ou mais pessoas estiverem com a regra aberta para edição, uma mensagem de aviso aparecerá quando uma delas tentar salvar as alterações. (Você tem a opção de manter suas alterações ou permitir que outro usuário faça e salve as alterações.)
- Selecione Salvar. O painel de edição do Editor de MD será aberto.
Você pode incluir sintaxe de regras existentes (Editar > Adicionar Regra > {type of rule}) ou definir uma regra (para detalhes, veja Sintaxe das Regras de Normalização). - Selecione Salvar. A regra será adicionada à lista de arquivos de regras na aba Regras de Normalização.
Para copiar/contribuir regras de normalização na Área da Comunidade:
- Na página do Editor de MD (Recursos > Catalogação > Abrir Editor de Metadados), selecione a aba Regras e expanda a pasta Normalização.
- Para copiar, abra a pasta Comunidade. Clique com o botão direito do mouse na regra que deseja copiar e selecione Duplicar.
A caixa de diálogo Duplicar Regra será aberta. Indique o nome e a descrição desejados e se deseja salvar a regra como privada (disponível apenas para você) ou compartilhada (disponível para todos os usuários da sua instituição).
O nome e o e-mail para contato do usuário do Alma que contribuiu com a regra para a CZ são indicados na caixa de diálogo, você pode entrar em contato com esse usuário em caso de dúvidas. - Para contribuir com sua própria regra para a CZ, clique com o botão direito do mouse na regra e selecione Contribuir com a CZ.
A caixa de diálogo Compartilhamento de Regras será aberta. Forneça um nome descritivo e uma descrição e selecione Salvar para salvar a regra na CZ.
Para trabalhar com uma regra de normalização existente:
- Na página do Editor de MD (Recursos > Catalogação > Abrir Editor de Metadados), selecione a aba Regras e expanda a pasta Normalização para visualizar as regras salvas.
- Selecione a regra com a qual deseja trabalhar e selecione uma das seguintes opções:
- Editar - Abre a caixa de texto com a sintaxe da(s) regra(s), permitindo que você a modifique (para detalhes, veja Sintaxe das Regras de Normalização).
- Excluir - Selecione Sim para confirmar a exclusão do arquivo da regra.
- Duplicar - Duplica o arquivo da regra selecionada, permitindo modificá-la e salvá-la como uma nova regra sem afetar o arquivo original.
- Propriedades - Abre a caixa de diálogo Propriedades das Regras de Normalização, permitindo modificar as propriedades do arquivo da regra.
- Para renomear a regra, duplique-a, nomeie a duplicata conforme desejado e exclua a regra antiga.
- Localize o registro bibliográfico com o qual deseja trabalhar (utilizando a Busca no Repositório ou no Editor de MD > aba de Registros) e abra-o no Editor de MD.
- Pressione (F6) ou selecione o ícone Dividir Editor.
- Selecione a aba Regras no painel esquerdo e expanda a pasta Normalização.
- Clique com o botão direito do mouse na regra que deseja pré-visualizar ou testar na pasta Privado ou Compartilhado (não Comunidade) e selecione Editar.
A regra será exibida no painel direito do Editor de MD.
- Selecione Pré-visualização. A regra será aplicada ao registro e o resultado aparecerá.
Para atualizar os registros da Rede, a normalização deve ser executada pela instituição da Rede (não por um participante). Uma instituição não pode atualizar registros da Rede, portanto, a normalização será aplicada somente aos campos locais (as extensões locais do participante). Ao pré-visualizar uma regra para um registro da Rede, a seguinte mensagem é exibida: Observe que as regras serão aplicadas somente aos campos locais quando o processo de normalização for executado.
- Selecione Aplicar Alterações para salvar as modificações no registro ou selecione Voltar para regras de normalização para continuar editando-o.
- Após terminar de fazer alterações na regra de normalização, selecione Salvar e teste-a usando o registro externo para salvar a versão final da regra. Para detalhes, veja Testar Regras de Normalização para Fontes Externas de Dados.
Regras de Normalização para Registros Dublin Core
No Editor de Metadados, existem os seguintes tipos de regras relacionadas a Dublin Core:
- Regras de seleção XSL
- Regras de Normalização XSL
A Regra de Normalização XSL não suporta discovery:local.
As regras de normalização de Dublin Core não podem ser escritas em um formato regular de Regra de Normalização, apenas como um XSL. Isso significa que o XSL é criado diretamente no Editor de Metadados (como explicado acima), ou você pode criá-lo no Bloco de Notas (ou outro aplicativo externo de sua escolha) e depois copiá-lo para o Editor de Metadados.
Os exemplos abaixo de Regras de Normalização XSL na Área da Comunidade podem ser visualizados no editor de metadados:
- EXL – Change dc:language value en to English
- EXL – Generic rule to replace string in Dublin Core record
- EXL_Add_field_accessRights
Para escrever XSL para Dublin Core:
- Escreva o XSL em um aplicativo externo de sua escolha.
- Abra a área Editor de Metadados Seção de Regras.
- Copie e cole o XSL no Editor de Metadados e salve a regra.
Regras de Normalização para Primo VE e Esploro
Além das regras de normalização do Alma, você pode criar regras de normalização para Primo VE e Esploro. Para criar essas regras, clique em Novo e então selecione:
-
Normalização (Descoberta) - Esta opção aparece somente quando o Primo VE está definido no sistema. Selecione esta opção se você estiver criando regras de normalização DC ou XML para registros bibliográficos que são carregados no Primo VE e não são gerenciados no Alma. Para informações sobre a sintaxe dessas regras, consulte Sintaxe das Regras de Normalização para Formatos DC e XML.
-
Normalização (Pesquisa) - Esta opção aparece somente quando o Esploro está definido no sistema. Para detalhes, veja Gerenciar Regras de Normalização de Ativo (Esploro).
Sintaxe da Regra de Normalização
A regra pode conter uma ou várias outras regras. Cada regra contém uma condição e uma ou mais ações a serem aplicadas aos registros. As ações são aplicadas a um registro se ele atender à condição. Cada ação pode ser executada em um único campo dentro de um registro. As ações são executadas na ordem em que aparecem na regra.
Ao definir uma regra que contém múltiplas regras, você deve usar o fator de prioridade (ou relevância). As ações estipuladas com maior prioridade na regra são executadas primeiro. Por exemplo, a ação em uma regra com prioridade 2 é executada antes da ação em uma regra com prioridade 1. Para exemplos de como a prioridade (ou relevância) pode ser usada em regras de normalização, veja Exemplos de Regra de Normalização do Alma. Observe que prioridade (ou relevância) é necessária somente quando os campos das regras são os mesmos. Caso contrário, quando cada regra lidar com campos diferentes, múltiplas regras serão executadas de cima para baixo.
Saiba mais sobre como criar regras de normalização no vídeo Regras de Normalização (11 mins).
Aprenda a criar regras de normalização que excluem campos específicos de registros ou alteram o conteúdo desses campos no vídeo Sintaxe da Rotina de Normalização para Exclusão ou Alteração de Conteúdo (9:57 mins) (em inglês).
When
(<conditions on MARC record>) then
Action
End
(<conditions on MARC record>) then
Action
End
<conditions on MARC record> contém uma ou mais cláusulas Booleanas que se aplicam ao registro. Se <conditions on MARC record> retornar TRUE, a regra será aplicada ao registro; caso contrário, a regra não será aplicada e o registro não será processado.
- “When” deve ser a única palavra na primeira linha. A condição deve ser colocada em uma linha separada.
- Você pode usar múltiplas condições em todo o registro somente na condição “When”. Toda regra deve ter apenas uma ação (após a linha “Then”). Se você desejar usar várias ações após a linha “Then”, divida isso em várias regras, cada uma com uma única ação.
- Embora seja permitido incluir múltiplos Operadores Booleanos nas regras, quando um grande número deles é selecionado, é provável que o resultado seja um desempenho mais lento. Assim, cada regra deve incluir no máximo 200 operadores Booleanos.
- Se não especificado, a condição será aplicada no nível de registro. Se você deseja que a condição seja aplicada separadamente em cada campo MARC 21, ela deverá ser especificada por campo. Por exemplo, quando existem vários campos MARC 21 com a mesma etiqueta.
Observe que, ao usar barras invertidas, você não pode usar um número ímpar de barras invertidas, como \z ou \\\z. No entanto, o uso de uma única barra invertida é suportado nas seguintes sequências de escape:
- \b
- \t
- \n
- \f
- \r
- \"
- \'
- \\
Em geral, você deve usar uma barra invertida dupla (\\) para sequências de escape.
Usar um número ímpar de barras invertidas produzirá o seguinte erro: "Sequência de escape inválida (sequências válidas são \b \t \n \f \r \" \' \\ )"
Veja a seguir alguns exemplos de correções que podem ser feitas nas regras quando esse erro é encontrado, mantendo o funcionamento da regra existente:
-
substituir \\\ por \\
-
substituir \. por .
-
substituir \ por \\
-
substituir \( por (
-
substituir \) por )
-
substituir \\\| por \\|
Elementos do Registro
Condições e ações se aplicam a elementos de registro, como no caso de registro MARC, campos (um ou mais), indicadores, subcampos (um ou mais) e conteúdos de campos/subcampos.
Para testar uma condição ou aplicar uma ação a um elemento de registro, o elemento deve corresponder à seguinte sintaxe:
| Expressão | Significado |
|---|---|
| "<tag>", "<new tag>" | Representa uma etiqueta de campo, 001, 245 etc. |
| "<oldCode>", "<newCode>" | Representa um código de subcampo, por exemplo, a, b, c. |
| "<element>" para um campo de dados | Os seguintes valores são possíveis para os campos de dados:
|
| "<element>" para um campo de controle | Os seguintes valores são possíveis para um campo de controle:
|
| "<element>" para um campo de posição fixa |
Os seguintes valores são possíveis para um campo UNIMARC/CNMARC 1XX de posição fixa:
Relevante somente para campos UNIMARC/CNMARC 1XX. |
| CONDITION no nível do registro | As seguintes opções de condições são possíveis. Veja a próxima seção (Condições) para informações importantes.
As seguintes opções de condições são possíveis somente para campos UNIMARC/CNMARC 1XX:
|
Condições
Condições podem ser definidas no nível da regra inteira (WHEN), ou em um nível de ação específico (IF). A mesma condição funcionará de maneira diferente dependendo do nível em que for definida.
- Cláusula WHEN - Uma condição que deve ser atendida por todo o registro para determinar se a regra será aplicada
- IF (sem uma ação) - Uma condição que se aplica a um único campo para determinar se a ação específica será realizada no mesmo
As condições podem ser:
-
containsScript - Use esta condição para detectar um idioma específico. Esta condição usa a seguinte lista fixa de idiomas que você pode verificar: Arabic, Armenian, Bengali, Bopomofo, Braille, Buhid, Canadian_Aboriginal, Cherokee, Cyrillic, Devanagari, Ethiopic, Georgian, Greek, Gujarati, Gurmukhi, Han, Hangul, Hanunoo, Hebrew, Hiragana, Inherited, Kannada, Katakana, Khmer, Lao, Latin, Limbu, Malayalam, Mongolian, Myanmar, Ogham, Oriya, Runic, Sinhala, Syriac, Tagalog, Tagbanwa, TaiLe, Tamil, Telugu, Thaana, Thai, Tibetan e Yi. Veja o exemplo de sintaxe abaixo:rule "Is CJK in Authority"
when
containsScript "Han" "1**"
then
set indication."true"
end - exists <element> - Ao menos uma equivalência é encontrada
- exists <element> - Aplica-se a campos de dados. Quando usado em uma cláusula IF, tanto o elemento de ação quanto o elemento testado pela condição devem ser o mesmo campo (de dados).
- existsControl <element> - Aplica-se a campos de controle. Quando usado em uma cláusula IF, tanto o elemento de ação quanto o elemento testado pela condição devem ser o mesmo campo (de controle).
- existsMoreThanOnce <element> - Múltiplas equivalências são encontradas. Aplica-se a campos de dados. Quando usado em uma cláusula IF, tanto o elemento de ação quanto o elemento testado pela condição devem ser o mesmo campo (de dados).
- not exists <element> - Nenhuma equivalência é encontrada
- not exists <element> - Aplica-se a campos de dados. Quando usado em uma cláusula IF, tanto o elemento de ação quanto o elemento testado pela condição devem ser o mesmo campo (de dados).
- not existsControl <element> - Aplica-se a campos de controle. Quando usado em uma cláusula IF, tanto o elemento de ação quanto o elemento testado pela condição devem ser o mesmo campo (de controle).
-
recordHasDuplicateSubfields (para regras de seleção; veja Trabalhando com Regras de Seleção) - Retorna true se subcampos duplicados (o subcampo e seu conteúdo) forem encontrados para o registro atual de acordo com os campos, subcampos e a expressão de caracteres a serem ignorados (charsToIgnore) que foram informados como parâmetros no seguinte formato:recordHasDuplicateSubfields "<tag>" "<code>" "<charsToIgnore>"Múltiplas etiquetas (campos) podem ser especificadas separadas por vírgulas. Múltiplos códigos (subcampos) podem ser especificados sem espaços para separá-los. Um ou mais caracteres (alfanuméricos ou de pontuação) sem espaços para separá-los podem ser especificados como caracteres a serem ignorados no final do conteúdo dos subcampos que estão sendo avaliados para duplicação. Veja o Exemplo 6 para mais informações.É criado um conjunto para os registros que atendem à condição recordHasDuplicateSubfields (retorna true).
Cada ação da cláusula IF pode ter um dos seguintes formatos:
- Aplicada se uma condição específica não for verdadeira, por exemplo: addControlField "{element}" if(not exists "{condition}")
- Aplicada se uma condição específica for verdadeira, por exemplo: addControlField "{element}" if(exists "{condition}")
- Aplicada incondicionalmente, por exemplo: addControlField "{element}"
O operador booleano OR pode ser usado em uma instrução de consequência usando o símbolo barra vertical (|), por exemplo: removeField "866" if (not exists "866.8.0|99". Se a barra vertical fizer parte do valor, use quatro barras invertidas (\\\\) como escape, por exemplo: removeField "866" if (exists "866.8.0\\\\|99")
Existe um problema conhecido em que "|” não funciona como caractere de escape. Isto será corrigido em um release futuro.
Lista de Ações
A tabela abaixo oferece uma lista de ações disponíveis.
| Ação | Formato/Exemplo | Comentário |
|---|---|---|
| Substituir campos e subcampos por outros campos e subcampos | changeControlField "<tag>" to "<new tag>" Exemplo: changeControlField "007" to "008"
|
Altera o identificador da etiqueta de um campo de controle; não modifica o conteúdo. |
| changeField "<tag>" to "<new tag>" Exemplo: changeField "245" to "246"
|
Altera o identificador da etiqueta; não modifica indicadores ou subcampos. | |
| changeSubField "<tag>.<code>" to "<new code>" changeSubFieldOnlyFirst "<tag>.<code>" to "<new code>"
changeSubField "<tag>.<code>" to "<new code>"
Exemplo: changeSubField "035.b" to "a"
|
Altera os subcampos (ou somente o primeiro subcampo, ou todos exceto o primeiro subcampo) "<code>" para o subcampo "<new code>" no campo "<tag>". | |
| changeFirstIndicator "<tag>" to "<value>" changeSecondIndicator "<tag>" to "<value>"
Exemplo: changeFirstIndicator "245" to "3"
|
Define o valor do indicador especificado na etiqueta <tag>. | |
| combineFields "<tag>" excluding "<comma-separated subfield list>" Exemplo: combineFields "852" excluding "a,b"
|
Combina todos os campos do número especificado. Copia todos os subcampos da segunda e das linhas posteriores para a primeira linha, exceto os subcampos nomeados; somente as primeiras ocorrências de subcampos excluídos são copiadas e apenas se ainda não existirem na primeira linha. | |
| Adicionar campos e subcampos | addField "<tag>.<code>.<value>" addField "<tag>.{<ind1>,<ind2>}.<code>. <value>"
Exemplo: addField "999.a.RESTRICTED"
|
Adiciona o campo ao registro MARC. Define o valor do subcampo para o valor indicado. |
| addControlField "<tag>.<value>" Exemplo: addControlField "008.820305s1991####nyu###########001#0#eng##"
|
Adiciona o campo de controle ao registro MARC. | |
| addSubField "<tag>.<code>.<value>" addSubField "<tag>.{<ind1>,<ind2>}.<code>.<value>"
Exemplo: addSubField "245.h.[Journal]"
|
Adiciona o subcampo <code> com valor <value> ao campo <tag>. Se o campo não existir, nada é feito. | |
| addSystemNumber "<element>" from "<tag>" prefixed by "<prefix tag>" Exemplo: addSystemNumber "035.a" from "001" prefixed by "003"
|
Torna o conteúdo do campo de dados <element> igual ao do segundo campo de controle <prefix tag> entre parênteses, seguido pelo conteúdo do primeiro campo de controle <tag>.
Por exemplo, se 001 tiver o valor 9945110100121 e 003 tiver o valor DAV, a condição do exemplo à esquerda produzirá 035 com o valor ‡(DAV)9945110100121.
|
|
| Copiar campos | copyField "<tag>" to "<new tag>" copyField "<tag>.<code>" to "<new tag>.<new code>"
copyField "<tag>" to "<new tag>.{<ind1>,<ind2>}"
Exemplo: copyField "971.a" to "100.u"
|
Copia o campo para outro campo Na primeira versão, os subcampos não são especificados (<code> e <new code>) e o novo campo contém todos os mesmos subcampos do campo antigo. Na segunda versão, se apenas <new code> não estiver especificado, o novo subcampo será o mesmo especificado por <code>. copyField cria um campo separado em vez de adicioná-lo a um campo existente. Você pode combinar o novo campo com qualquer campo existente (veja combineFields).
|
| Remover campos e subcampos | removeControlField "<tag>" Exemplo: removeControlField "009"
|
Remove todas as ocorrências do campo de controle. Observe que, se você remover o campo de controle 008, o Alma o recriará imediatamente se você não o fizer. Considere adicionar o campo novamente após removê-lo, por exemplo: rule "remove 008"
when (TRUE) then removeControlField "008" addControlField "008.######s2013####xx######r#####000#0#eng#d" end |
| removeField "<tag>" Exemplo: removeField "880"
|
Remove todas as ocorrências do campo <tag>. | |
| removeSubField "<tag>.<code>" Exemplo: removeSubField "245.h"
|
Remove todas as ocorrências do subcampo <code> do campo indicado. | |
| Substituir texto em campos ou subcampos | replaceControlContents "<tag>.{<position>,<length>}. <value>" with "<new value>" Exemplo: replaceControlContents "LDR.{7,1}.s" with "m"
|
Substitui <value> com "<new value>" na posição inicial <position> por <position>+<length> do campo de controle <tag>. Substitui somente o texto equivalente a <value>. |
| replaceContents "<tag>.<code>.<value>" with "<new value>" replaceContentsOnlyFirst "<tag>.<code>.<value>" with "<new value>"
replaceContentsExceptFirst "<tag>.<code>.<value>" with "<new value>"
Exemplo: replaceContents "245.h.[Journal]" with "[Book]"
|
Substitui as expressões equivalentes (todas as instâncias da expressão no primeiro subcampo equivalente, ou todas as expressões em todos os subcampos equivalentes, exceto o primeiro) a <value> no subcampo <code> do campo "<tag>" por "<new value>". A expressão ou parte dela que não equivale a <value> não é modificada. | |
| replaceSubFieldContents "<tag>.<code>" with "<tag>.<code>" Exemplo: replaceSubFieldContents "245.b" with "100.a"
|
Substitui o conteúdo do subcampo pelo conteúdo de outro subcampo. | |
|
replaceFixedContents "<tag>.{<1_ind>,<2_ind>}.<code>.{<position>,<length>}.<value>" with "<new value>" Exemplo: replaceFixedContents "100.{1,2}.a.{0,8}.20150226" with "20220724” |
Substitui <value> por <new value> nos campos de posições fixas UNIMARC e CNMARC 1XX. Relevante somente para campos UNIMARC/CNMARC 1XX. |
|
| Adicionar texto em subcampos |
prefix "<tag>.<code>" with "<value>" Exemplo: prefix "035.b" with "(OCoLC)"
|
Adiciona um prefixo ao valor de subcampo "<code>" no campo "<tag>". O novo valor será <value> seguido pelo valor antigo.
|
| prefixSubField "<tag>.<code>" with "<source tag>.<source code>" Exemplo: prefixSubField "910.a" with "906.a"
|
Adiciona o valor do subcampo "<source code>" no campo "<source tag>" como um prefixo para o subcampo "<code>" no campo "<tag>". O novo valor será o valor do subcampo "<source code>" no campo "<source tag>" seguido pelo valor antigo.
|
|
| suffix "<tag>.<code>" with "<value>" Exemplo: suffix "035.b" with "(OCoLC)"
|
Adiciona um sufixo ao valor de subcampo "<code>" no campo "<tag>". O novo valor será o valor antigo seguido por <value>.
|
|
| suffixSubField "<tag>.<code>" with "<source tag>.<source code>" Exemplo: suffixSubField "910.a" with "907.c"
|
Adiciona o valor do subcampo "<source code>" no campo "<source tag>" como um sufixo para o subcampo "<code>" no campo "<tag>". O novo valor será o valor antigo seguido pelo valor do subcampo "<source code>" no campo "<source tag>".
|
|
| Manter informações da instituição em registros bibliográficos e de autoridades Por exemplo, esta sintaxe pode ser usada em regras de normalização selecionadas na Lista de Tarefas de Configuração de Metadados Bibliográficos MARC 21 para normalizar os registros bibliográficos da Área da Rede ao salvar.
Esta funcionalidade está em construção. Para habilitar esta sintaxe, entre em contato com o Suporte da Ex Libris.
|
addCreatingAgency "<tag>.<code>" Exemplo: addCreatingAgency "040.a”
|
Adiciona o código ISIL da instituição que criou o registro ao subcampo em "<code>" no campo "<tag>". |
| addModifyingAgency "<tag>.<code>" Exemplo: addModifyingAgency "040.d"
|
Adiciona o código ISIL da instituição que modificou o registro ao subcampo no "<code>" do campo "<tag>". Se já houver uma instituição que modificou o registro no "<tag>.<code>", isso adicionará outro código ISIL da instituição. | |
| replaceModifyingAgency "<tag>.<code>" Exemplo: replaceModifyingAgency "040.d"
|
Adiciona o código ISIL da instituição que modificou o registro ao subcampo no "<code>" do campo "<tag>". Se já existir uma instituição que modificou o registro no "<tag>.<code>", todas serão substituídas. | |
| Dividir subcampos | splitSubField "<tag>.{ind1,ind2}.<code>.<delimiter>" to "<tag>.{<ind1>,<ind2>}.<code>" addSeq "<code>" Exemplo 1: splitSubField "866.a.;" to "555.{0,0}.a" addSeq "8"
Exemplo 2: splitSubField "555.a. – " to "859.{0,0}.a" addSeq "8"
Exemplo 3: splitSubField "859.a.\\\\."
Exemplo 4: splitSubField "999.a.;" to "555.a" addSeq "8"
|
A etiqueta é obrigatória. Os indicadores são opcionais.
Como a divisão é no nível do subcampo, o código é obrigatório.
O delimitador pode ser qualquer expressão. Se o delimitador não existir, o subcampo completo é copiado como a primeira (e única) ocorrência e a sequência é adicionada.
O componente to é opcional. Se especificado, múltiplas ocorrências do tag.code to são criadas, cada uma com dados até o delimitador. Veja os exemplos 1 e 2. Se o componente to não estiver especificado, o subcampo será dividido nos mesmos subcampos adicionais do mesmo campo, conforme mostrado no exemplo 3.
O componente addSeq é opcional. Não é relevante se o componente to não estiver especificado. Quando addSeq estiver especificado, o subcampo com uma sequência será adicionado, como no Exemplo 1; e se o subcampo já existir no campo original, uma sequência (precedida por um ponto) será adicionada a esse campo, como no Exemplo 2.
|
|
correctDuplicateSubfields "<tag>" "<code>" Exemplo: Remove os subcampos x, y, z duplicados dos campos 610 e 630. |
Corrige subcampos duplicados (por exemplo, com o mesmo código E o mesmo valor), mantendo a primeira ocorrência e removendo as demais do registro atual, de acordo com os campos e subcampos informados como parâmetros. Você pode usar recordHasDuplicateSubfields para criar o conjunto que será fornecido à sua regra de normalização que usa correctDuplicateSubfields. Veja o Exemplo 6 para mais informações. Para deduplicação de subcampos com valores diferentes, consulte: |
|
|
correctDuplicateSubfields "<tag>" "<code>" Exemplo: Moves subfields 9 and 2 to the end of field 650. |
Move a primeira ocorrência de cada subcampo para o final do campo e remove todas as outras ocorrências do mesmo subcampo. Se mais de um subcampo for especificado, eles serão colocados no final, na mesma sequência identificada na regra. Neste exemplo, o subcampo 9 é colocado no final, seguido do subcampo 2. Observe que a condição if não é suportada com a ação moveSubfieldsToEndOfField. |
|
|
Corrigir campos duplicados para o registro atual |
correctDuplicateFields "{fields}" Exemplo: correctDuplicateFields "610,630,650" |
Essa ação usa um parâmetro, campos, que contém valores de campo separados por vírgula, como 610, 630, 650. Esta ação corrige os campos duplicados do registro atual de acordo com os campos informados como parâmetros. |
|
Localizar campos duplicados (Regras de Seleção; veja Trabalhando com Regras de Seleção) |
recordHasDuplicateFields "{fields}" Exemplo: recordHasDuplicateFields "610,630,650" |
Essa ação usa um parâmetro, campos, que contém valores de campo separados por vírgula, como 610, 630, 650. Esta ação pode ser verdadeira ou falsa. Ela retorna verdadeiro se forem encontrados campos duplicados no registro atual, de acordo com os campos informados como parâmetros. |
Caracteres Especiais e Curingas
Embora o uso de expressões regulares nas Regras de Normalização do Alma não seja totalmente suportado no momento, algumas expressões regulares podem ser usadas - para ver exemplos, consulte Exemplos da Regra de Normalização do Alma.
O separador do subcampo ($$) não pode aparecer na regra, nem mesmo no nome.
Um caractere de # (jogo da velha) no início de uma linha indica que o restante da linha é um comentário, e o mesmo é ignorado ao processar a regra.
O asterisco (*) é usado para fazer equivalência de qualquer expressão, incluindo as de comprimento zero. Por exemplo, "<tag>.<*>.<value>" aplica-se a todos o subcampos na etiqueta <tag> que tenham o valor <value>. * é usado para truncagem, portanto, faz equivalência do máximo de caracteres possíveis da expressão. Por exemplo, se você tem uma expressão "a b c b d b e", o padrão "b*b" equivale a "b c b d b", não apenas "b c b".
Indicadores vazios (mas não campos ou subcampos) são identificados por um hífen (-). Por exemplo, "<tag> {-,<ind2>}" retorna todos os campos em que a etiqueta MARC é <tag>, o primeiro indicador não está definido e o segundo indicador é <ind2>.
Se o texto de um subcampo contiver um ponto como último caractere, use quatro barras invertidas para corresponder ao ponto. Por exemplo:
rule "Replace '1 v.' to 'Leaves' in $a (unconditional)"
when
(TRUE)
then
replaceContents "300.a.1 v\\\\." with "Leaves"
end
when
(TRUE)
then
replaceContents "300.a.1 v\\\\." with "Leaves"
end
Aspas duplas podem ser usadas (somente) em condições. Para usar aspas duplas como parte de uma condição, use aspas simples ao redor do texto da regra (') em vez de aspas duplas ("). Dessa forma, você pode usar aspas duplas dentro do texto após uma barra dupla invertida (\\).
rule "populate 008 7-10 2016"
when
(exists '245.{*, }.c.\"')
then
replaceControlContents "008.{7,4}" with "2016"
end
when
(exists '245.{*, }.c.\"')
then
replaceControlContents "008.{7,4}" with "2016"
end
Datas em hebraico podem ser usadas (somente) em condições. (O hebraico é lido da direita para a esquerda, portanto, as barras invertidas duplas no exemplo a seguir estão antes das aspas duplas.)
rule "populate 008 7-10 2016"
when
((exists '260.{*, }.c.תשע\\"ו') OR (exists '264.{*, }.c.תשע\\"ו'))
then
replaceControlContents "008.{7,4}" with "2016"
end
when
((exists '260.{*, }.c.תשע\\"ו') OR (exists '264.{*, }.c.תשע\\"ו'))
then
replaceControlContents "008.{7,4}" with "2016"
end
- Curingas não podem ser usados como o primeiro caractere de uma condição ou valor.
- Para usar uma barra invertida literal (\), use outra barra invertida como caractere de escape: \\.
- Use quatro barras invertidas (\\\\) como caractere de escape para um ponto quando este for o último caractere da expressão. Quando o ponto é seguido imediatamente por outro caractere, não são necessárias quatro barras invertidas (como em addField "907.a.F.L.T\\\\."). No entanto, é uma prática recomendada sempre usar as quatro barras invertidas na regra de normalização para garantir os resultados desejados mais consistentes. Veja os seguintes exemplos.
- Conforme observado acima, se aspas duplas ou simples forem usadas em uma condição que usa aspas simples como caractere de escape, você deverá usar barras invertidas duplas como caractere de escape para as aspas duplas ou simples.
- Se o símbolo de barra vertical fizer parte da condição, use quatro barras invertidas como caractere de escape, por exemplo: removeField "866" if (exists "866.8.0\\\\|99"). Isso é necessário somente ao usar um símbolo de barra vertical na condição.
Exemplo: Usar o Ponto em uma Regra de Normalização com replaceContents
Exemplo de registro com pontos:
245 00 $$a Feminist literary theory. : $$b a reader / $$c edited by Mary Eagleton.
246 0# $$a F.L.T.
Regra de normalização para o registro do exemplo acima:
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
when
(TRUE)
then
replaceContents "245.a.\\\\." with ""
replaceContents "246.a.\\\\." with ""
end
Veja exemplos de antes e depois na figura abaixo.
Exemplos de Antes e Depois
Exemplo: Usar o Ponto em uma Regra de Normalização com addField
Veja abaixo o exemplo de um registro ao qual pontos devem ser adicionados:
906 $$a Architecture.
907 $$a F.L.T.
Veja abaixo a regra de normalização para o registro do exemplo acima usando a prática recomendada de sempre incluir barras:
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
salience 100
when
TRUE
then
addField "906.a.Architecture\\\\."
addField "907.a.F\\\\.L\\\\.T\\\\."
end
Veja na figura abaixo os exemplos de antes e depois do registro.
Exemplos de Antes e Depois
Exemplos da Regra de Normalização
Para ver uma lista com mais de 50 exemplos de regras de normalização e outros documentos relacionados, consulte Regras de Normalização.