Skip to main content
ExLibris
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    Travailler avec des règles de normalisation

    Translatable
    Pour travailler avec les règles de normalisation, vous devez avoir le rôle suivant :
    • Administrateur de catalogue
    • Gestionnaire de catalogue
    • Catalogueur
    Les règles de normalisation sont utilisées pour modifier ou mettre à jour les métadonnées bibliographiques à différentes étapes, par exemple lorsque la notice est enregistrée dans l'Éditeur de métadonnées, importée via le profil d'importation, importée à partir d'une ressource de recherche externe, ou modifiée à partir du menu « Améliorer la notice » dans l'Éditeur de métadonnées. Les règles de normalisation sont rédigées selon une syntaxe spécifique, afin de créer des règles définissant des modications spécifiques à appliquer aux notices. Vous pouvez par exemple modifier ou supprimer des champs. Vous pouvez également procéder à ces modifications ou suppressions sous condition, sous réserve du respect ou non d'une autre condition dans la notice bibliographique.
    Les règles de normalisation peuvent être appliquées à des notices individuelles dans l'Éditeur de métadonnées ou à un groupe de notices :
    Les règles de normalisation sont créées en suivant une syntaxe de programmation spécifique et à l'aide de la fenêtre de modification accessible dans l’Éditeur de métadonnées sous l'onglet Règles.
    Rules_Tab_Editing_Window_NewUI_02_TC_NL.png
    Onglet Règles Fenêtre de modification
    En plus de créer votre propre programme de règles de normalisation, vous pouvez également copier/coller des règles existantes dans la fenêtre de modification ou utiliser les exemples prédéfinis (Onglet Règles) pour développer vos règles de normalisation. Voir Syntaxe des règles de normalisation pour des informations concernant la syntaxe des règles de normalisation et pour voir des exemples que vous pouvez copier dans la fenêtre de modification.
    À l'aide de la fonction de prévisualisation dans l’Éditeur de métadonnées, vous pouvez :
    • Consulter les règles de normalisation et les notices de métadonnées côte-à-côte
    • Prévisualiser le résultat d'une règle lorsqu'elle est exécutée sur une notice de métadonnées
    • Basculer entre la règle et la prévisualisation des modifications
    • Modifier les règles et les tester immédiatement
    • Pour un rapide aperçu des règles de normalisation, regardez la vidéo Règles de normalisation (6:00).
    • Pour obtenir des informations détaillées, assorties d'exemples, sur les règles de normalisation, regardez la vidéo Règles de normalisation (1 h).

    Créer des règles de normalisation

    Cette section décrit comment créer une règle de normalisation ou copier une règle de la Zone de communauté, comment travailler avec des règles déjà créées et comment prévisualiser le résultat d'une règle lorsqu'elle est exécutée sur une seule notice de métadonnées. Pour plus d'informations, voir la zone Règles de normalisation sur cette page.
    Veuillez noter que les règles de normalisation concernant les notices IZ liées à la NZ peuvent uniquement être appliquées aux champs locaux. Pour appliquer des règles de normalisation à ces notices, exécutez les règles de normalisation et les processus de normalisation uniquement dans l'institution du réseau.
    Pour les membres des consortiums de la Zone réseau, les utilisateurs peuvent déterminer si les nouvelles règles sont enregistrées localement ou dans une institution réseau. Pour régler ceci, ouvrez la section Notices ou Modèles, et accédez à Nouveau > Options de placement. Veuillez noter que cette sélection s'effectue par utilisateur.
    Pour créer une nouvelle règle de normalisation :
    1. Sur la page Éditeur de métadonnées (Ressources > Catalogage > Ouvrir l'Éditeur de métadonnées), ouvrez la section Règles.
    2. Pour créer une règle de normalisation pour une notice MARC ou Dublin Core, sélectionnez Nouveau > Normalisation. La boîte de dialogue Normalization Rules Properties (New Rule) s'ouvre.
      Normalization_rule_properties_dialog_3_NL.png
      Boîte de dialogue Propriétés des règles de normalisation
    3. Saisissez un nom et une description pour la règle de normalisation.
      Le mot « règle » ne doit pas être en majuscule s'il est utilisé dans le nom de la règle. S'il est en majuscule, la règle ne fonctionnera pas.

      N'utilisez pas de barre oblique inversée (\) dans le nom de la règle ! Sinon, la règle ne pourra pas être utilisée pour la fonctionnalité Filtrer un ensemble.
    4. Pour créer une règle de normalisation pour une notice MARC, sélectionnez Drool. Pour créer une règle de normalisation pour une notice DC (Dublin Core), sélectionnez 'XSL'.
    5. Sélectionnez une option d'accès, Privé ou Partagé. Si vous sélectionnez Privé, vous seul pouvez travailler sur la règle, qui ne peut pas être incluse dans un processus de normalisation. Si vous sélectionnez Partagé, votre règle sera partagée entre les catalogueurs. Dans ce cas, la règle peut être vue par plus d'un utilisateur à la fois. Si deux personnes ou plus ouvrent la règle pour la modifier, un message d'avertissement apparaît lorsque l'une d'elles essaie d'enregistrer des modifications. (Vous avez le choix entre conserver vos changements ou autoriser un autre utilisateur à effectuer et enregistrer ses changements.)
    6. Cliquez sur EnregistrerLe panneau de l'Éditeur de métadonnées s'ouvre.
      Vous pouvez inclure la syntaxe d'une règle existante (Modifier > Ajouter une règle > {type de règle}) ou définir une règle (pour plus de détails, voir Syntaxe des règles de normalisation).
    7. Cliquez sur Enregistrer. La règle est ajoutée à la liste des fichiers de règle dans l'onglet Règles de normalisation.
    Pour copier/contribuer des règles de normalisation dans la Zone de communauté :
    1. Sur la page Éditeur de métadonnées (Ressources > Catalogage > Ouvrir l'Éditeur de métadonnées), sélectionnez l'onglet Règles et agrandissez le dossier Normalisation
    2. Pour copier, ouvrez le dossier Communauté. Faites un clic droit sur la règle que vous souhaitez copier, puis cliquez sur Dupliquer
      La boîte de dialogue Dupliquer règle s'ouvre. Indiquez votre nom et description, et indiquez si vous souhaitez l'enregistrer en tant que règle privée (disponible uniquement pour vous) ou partagée (disponible pour tous les utilisateurs de votre institution). 
      Le nom et l'e-mail de contact de l'utilisateur Alma qui a ajouté la règle à la CZ sont indiqués dans la boîte de dialogue, vous pouvez contacter cet utilisateur en cas de question. 
    3. Pour contribuer votre propre règle à la CZ, faites un clic droit sur la règle et sélectionnez Contribuer dans la CZ
      La boîte de dialogue Partage de règle s'ouvre. Indiquez un nom descriptif et une description, puis sélectionnez Enregistrer pour enregistrer la règle dans la CZ. 
    Pour travailler sur un fichier de règles de normalisation existant :
    1. Sur la page Éditeur de métadonnées (Ressources > Catalogage > Ouvrir l'Éditeur de métadonnées), cliquez sur l'onglet Règles et agrandissez le dossier Normalisation pour afficher les règles enregistrés.
    2. Cliquez sur la règle sur laquelle vous souhaitez travailler et sélectionnez l'une des options suivantes :
      • Modifier – Ouvre la fenêtre de texte et affiche la syntaxe de la ou des règles, que vous pouvez alors modifier (pour plus de détails, voir Syntaxe des règles de normalisation).
      • Supprimer – Cliquez sur Oui pour confirmer la suppression du fichier de règles.
      • Dupliquer – Duplique le fichier de règles sélectionné, ce qui vous permet de le modifier et de l'enregistrer comme nouvelle règle sans que le fichier d'origine soit modifié.
      • Propriétés – Ouvre la boîte de dialogue Propriétés des règles de normalisation, vous permettant de modifier les propriétés du fichier de règles.
    3. Pour renommer la règle, la dupliquer, donner au double le nom souhaité, puis supprimer l'ancienne règle. 
    Pour obtenir un aperçu et enregistrer et tester le résultat d'une règle :
    1. Localisez la notice bibliographique avec laquelle vous souhaitez travailler (à l'aide de Recherche dans le répertoire ou de l'onglet Notices de l’Éditeur de métadonnées) et ouvrez-la dans l'Éditeur de métadonnées.
    2. Appuyez sur (F6) ou cliquez sur l'icône Scinder l'éditeur.
    3. Sélectionnez l'onglet Règles dans le panneau de gauche et agrandissez le dossier Normalisation.
    4. Faites un clic-droit sur la règle que vous souhaitez prévisualiser ou tester dans le dossier Privé ou Partagé (et non Communauté) et sélectionnez Modifier.
      Edit normalizaiton rule.png
      La règle s'affiche sur le panneau droit de l’Éditeur de métadonnées.
      Normalization_Rule_Preview_14_NL.png
    5. Cliquez sur Prévisualiser. La règle est appliquée à la notice et le résultat est affiché.

      Pour mettre à jour des notices Réseau, la normalisation doit être exécutée par l'institution Réseau (et non par un membre). Une institution ne peut pas mettre à jour des notices Réseau. La normalisation ne sera donc appliquée qu'aux champs locaux (les extensions locales du membre). Lorsque vous prévisualisez une règle pour la notice du réseau, le message suivant s'affiche : Notez que les règles ne s'appliqueront qu'aux champs locaux lors de l'exécution du processus de normalisation.

    • Cliquez sur Appliquer les changements pour enregistrer les modifications concernant la notice ou cliquez sur Retour aux règles de normalisation pour continuer à les modifier. 
    • Lorsque les modifications apportées à la règle de normalisation sont finalisées, cliquez sur Enregistrer et tester pour enregistrer la version finale de votre règle de normalisation. Pour plus de détails, voir Testing Normalization Rules for External Data Sources.

    Règles de normalisation pour les notices Dublin core

    Dans l'Éditeur de métadonnées, voici les différents types de règles liées à Dublin Core :

    • Règles d'indication XSL
    • Règle de normalisation XSL

    La règle de normalisation XSL ne prend pas en charge la valeur discovery:local.

    Les règles de normalisation Dublin Core ne peuvent pas être rédigées dans un format de règle de normalisation standard, mais uniquement au format XSL. Cela signifie que vous pouvez composer directement le XSL dans l'Éditeur de métadonnées (comme expliqué ci-dessus), ou bien le composer sur Notepad (ou une autre application externe de votre choix), puis le copier dans l'Éditeur de métadonnées. 

    Vous pouvez voir les exemples ci-dessous de règles de normalisation XSL dans la Zone de communauté, dans l'Éditeur de métadonnées :

    • EXL – Changez la valeur dc:language en à English
    • EXL – Règle générique pour remplacer la chaîne dans une notice Dublin Core
    • EXL_Add_field_accessRights
    Pour rédiger un XSL pour Dublin Core :
    1. Rédigez le XSL dans une application externe de votre choix.
    2. Ouvrez l'Éditeur de métadonnées > section Règles
    3. Copiez et collez le XSL dans l'Éditeur de métadonnées et enregistrez la règle.

    Règles de normalisation pour Primo VE et Esploro

    Outre des règles de normalisation Alma, vous pouvez créer des règles de normalisation pour Primo VE et Esploro. Pour créer ces règles, cliquez sur Nouveau, puis sélectionnez :

    • Normalisation (Découverte) - Cette option s'affiche uniquement lorsque Primo VE est défini dans le système. Sélectionnez cette option si vous créez des règles de normalisation DC ou XML pour des notices bibliographiques qui sont chargées dans Primo VE et pas gérées dans Alma. Pour plus d'informations concernant la syntaxe de ces règles, voir Syntaxe des règles de normalisation pour les formats DC et XML.

    • Normalisation (Recherche) - Cette option s'affiche uniquement lorsque Esploro est défini dans le système. Pour obtenir des détails, voir Managing Asset Normalization Rules (Esploro).

    Syntaxe des règles de normalisation

    La règle peut contenir une ou plusieurs autres règles. Chaque règle contient une condition et une ou plusieurs actions à appliquer aux notices. Les actions sont appliquées à une notice si la notice remplit la condition. Chaque action peut être appliquée à un seul champ au sein d'une notice. Les actions sont effectuées dans l'ordre dans lequel elles apparaissent au sein de la règle.
    Lorsque vous définissez une règle contenant elle-même plusieurs règles, vous devez utilisez le facteur de priorité. Les actions stipulées dans la règle avec la plus haute priorité sont effectuées en premier. Par exemple, l'action dans la règle avec la priorité 2 ci-dessous est effectuée avant l'action dans la règle avec priorité 1. Pour des exemples de la manière dont la priorité peut être utilisée dans les règles de normalisation, voir Exemple de règle de normalisationNotez que la priorité (ou l'importance) n'est nécessaire que lorsque les champs des règles sont les mêmes. Sinon, lorsque chaque règle s'applique à des champs différents, plusieurs règles sont exécutées de haut en bas.
    Apprenez-en plus sur la création des règles de normalisation dans la vidéo Règles de normalisation (11 mins).
    Apprenez comment créer des règles de normalisation qui effacent des champs spécifiés dans des notices ou qui changent le contenu de ces champs dans la vidéo Syntaxe de la routine de normalisation pour supprimer ou changer du contenu (9:57 mins).
    When
    (<conditions sur la notice MARC>) then
    Action
    End
    <conditions sur la notice MARC> contient une ou plusieurs clauses booléennes qui s'appliquent à la notice. Si <conditions sur la notice MARC> renvoie VRAI, la règle est appliquée à la notice ; sinon, la règle n'est pas appliquée et la notice n'est pas traitée.
    • “When” doit être le seul mot sur la première ligne. La condition doit être placée sur une ligne séparée.
    • Vous pouvez utiliser plusieurs conditions sur l'ensemble de la notice dans la condition « When » uniquement.  Chaque règle doit avoir une seule action (après la ligne « Then »). Si vous souhaitez utiliser plusieurs actions après la ligne « Then », divisez ceci en plusieurs règles, chacune avec une seule action.  
    • Veuillez noter que bien qu'il soit autorisé d'inclure plusieurs opérateurs booléens dans les règles, lorsqu'un grand nombre d'opérateurs booléens sont sélectionnés, il est probable que les performances ralentissent. Ainsi, chaque règle devrait inclure au maximum 200 opérateurs booléens.
    • Si rien n'est spécifié, la condition fonctionne au niveau de la notice. Si vous souhaitez que la condition s'applique à chaque champ MARC21 de manière séparée, la condition doit être spécifiée pour chaque champ. Par exemple, lorsqu'il y a plusieurs champs MARC21 avec la même étiquette.
    Veuillez noter qu'il n'est pas possible d'utiliser un nombre impair de barres obliques inversées, comme par exemple \z ou \\\z. L'utilisation d'une seule barre oblique inversée est néanmoins prise en charge dans les séquences d'échappement suivantes :
    • \b
    • \t
    • \n
    • \f
    • \r
    • \"
    • \'
    • \\
    Il est généralement recommandé d'utiliser deux barres obliques inversées (\\) pour les séquences d'échappement.
    Utiliser un nombre impair de barres obliques inversées entraînera l'apparition de l'erreur suivante :  "Invalid escape sequence (valid ones are \b \t \n \f \r \" \' \\ )"
    Les exemples suivants vous montrent les corrections qui peuvent être apportées aux règles, tout en conservant le comportement de la règle existante, lorsque cette erreur survient :
    • remplacer \\\ par \\
    • remplacer \. par .
    • remplacer \ par \\
    • remplacer \( par (
    • remplacer \) par )
    • remplacer \\\| par \\|

    Éléments de la notice

    Les conditions et les actions s'appliquent aux éléments de la notice, tels que la notice MARC, les champs (un ou plus), les indicateurs, les sous-champs (un ou plus) et le contenu des champs/sous-champs.
    Pour tester une condition ou appliquer une action à un élément de la notice, la syntaxe de l'élément doit être de la forme suivante :
    Syntaxe
    Expression Signification
    "<tag>", "<new tag>" Représente une étiquette de champ, par exemple, 001, 245, etc.
    "<oldCode>", "<newCode>" Représente le code d'un sous-champ, par exemple, a, b, c.
    "<element>" pour un champ de données Des valeurs possibles pour le champ de données sont les suivantes :
    • FIELD – par exemple : 245
    • FIELD_VALUE – par exemple : 245.value*
    • FIELD_INDICATOR – par exemple : 245.{1,2}
    • FIELD_SUBFIELD_CODE – par exemple : 245.a
    • FIELD_INDICATOR_SUBFIELD_CODE – par exemple : 245.{1,2}.a.
    • FIELD_SUBFIELD_CODE_VALUE – par exemple : 245.a.value*
    • FIELD_INDICATOR_SUBFIELD_CODE_VALUE – par exemple : 245.{1,2}.a.value*
    "<element>" pour un champ de contrôle Des valeurs possibles pour un champ de contrôle sont les suivantes :
    • FIELD_POSITION_LENGTH – par exemple : LDR.{17,3}
    • FIELD_POSITION_LENGTH_VALUE – par exemple : LDR.{17,3}.eng
    "<element>" pour un champ de position fixe

    Les valeurs suivantes sont les valeurs possibles pour un champ UNIMARC/CNMARC 1XX de position fixe :

    • FIELD – par exemple : 100
    • FIELD_VALUE – par exemple : 100.{*,*}.*.{*,*}.value*
    • FIELD_INDICATOR – par exemple : 100.{1,2}
    • FIELD_SUBFIELD_CODE – par exemple : 100.a
    • FIELD_INDICATOR_SUBFIELD_CODE – par exemple : 100.{1,2}.a
    • FIELD_SUBFIELD_CODE_VALUE – par exemple : 100.a.value*
    • FIELD_INDICATOR_SUBFIELD_CODE_VALUE – par exemple : 100.{1,2}.a.{*,*}.value*
    • FIELD_POSITION_LENGTH – par exemple : 100.{*,*}.a.{17,3}
    • FIELD_POSITION_LENGTH_VALUE – par exemple : 100.{*,*}.a.{17,3}.*

    Pertinent uniquement pour les champs UNIMARC/CNMARC 1XX.

    CONDITION au niveau de la notice Les options suivantes sont les options de condition possibles : Voir la section suivante (Conditions) pour des informations importantes.
    • VRAI – toujours vrai
    • not exists "{element}" – vrai si l'élément n'existe pas (pour les champs de données)
    • not existsControl "{element}" – vrai si l'élément n'existe pas (pour les champs de contrôle)
    • exists "{element}" – vrai si l'élément existe au moins une fois (pour les champs de données)
    • existsControl "{element}" – vrai si l'élément existe au moins une fois (pour les champs de contrôle)
    • existsMoreThanOnce "{element}" – vrai si l'élément existe plus d'une fois Pour voir un exemple d'utilisation de cette condition, consultez Règles d'indication pour notices MARC - Exemples de syntaxe.
    • contains – vrai si l'élément contient une valeur. Utilisé pour les règles de fusion.

    Les options suivantes sont les options de condition possibles pertinentes uniquement pour les champs UNIMARC/CNMARC 1XX :

    • existsFixedField "{element}" - vrai si l'élément n'existe pas (pour les données des champs de position fixes 1XX )
    • not existsFixedField "{element}" - vrai si l'élément n'existe pas (pour les données des champs de position fixes 1XX)

    Condition

    Les conditions peuvent concerner la règle dans sa globalité (WHEN) ou à un niveau d'action spécifique (IF). La même condition aura des conséquences différentes en fonction du niveau sur lequel elle est définie.
    • Clause WHEN – définit une condition qui doit être remplie par la notice dans sa globalité, cela permet de déterminer si la notice peut être choisie pour l'application de la règle
    • Clause IF (dans une action) – définit une condition qui s'applique à un seul champ, cela permet de déterminer si une action spécifique sera ou non exécutée sur ce seul champ
    Les conditions peuvent être :
    • containsScript – Utilisez cette condition afin de détecter une langue spécifique. La condition containsScript utilise la liste fixée suivante de langues pour lesquelles vous pouvez lancer une vérification : Arabe, Arménien, Bengali, Bopomofo, Braille, Buhid, Langues autochtones canadiennes, Cherokee, Cyrillique, Devanagari, Éthiopien, Géorgien, Grec, Gujarati, Gurmukhi, Han, Hangul, Hanunoo, Hébreu, Hiragana, Hérité, Kannada, Katakana, Khmer, Laotien, Latin, Limbu, Malayalam, Mongolien, Birman, Ogham, Oriya, Runic, Sinhala, Syriaque, Tagalog, Tagbanwa, TaiLe, Tamoul, Telegu, Thaana, Thai, Tibétain, et Yi. Voir les exemples de syntaxe suivants :
      la règle "CJK est-il dans l'Autorité
      lorsque
      containsScript "Han" "1**"
      puis
      définir l'indication."vrai"
      fin
    • exists <element> – Il existe au moins une correspondance
      • exists <element> – S'applique aux champs de données Dans le cas d'une condition SI, l'élément de l'action et l'élément testé par la condition doivent tous les deux être le même champ (de données).
      • existsControl <element> – S'applique aux champs de contrôle Dans le cas d'une condition SI, l'élément de l'action et l'élément testé par la condition doivent tous les deux être le même champ (de contrôle).
    • existsMoreThanOnce <element> – Plusieurs correspondances ont été trouvées. S'applique aux champs de données. Dans le cas d'une condition SI, l'élément de l'action et l'élément testé par la condition doivent tous les deux être le même champ (de données).
    • not exists <element> – Aucune correspondance trouvée
      • not exists <element> – S'applique aux champs de données. Dans le cas d'une condition SI, l'élément de l'action et l'élément testé par la condition doivent tous les deux être le même champ (de données).
      • not existsControl <element> – S'applique aux champs de contrôle. Dans le cas d'une condition SI, l'élément de l'action et l'élément testé par la condition doivent tous les deux être le même champ (de contrôle).
    • recordHasDuplicateSubfields (pour les règles d'indication; voir Travailler avec des règles d'indication) – Indique vrai si des sous-champs (sous-champs et leur contenu) dupliqués sont trouvés pour la notice actuelle selon les champs, sous-champs et caractères à ignorer (charsToIgnore) qui ont été définis dans le format suivant :
      recordHasDuplicateSubfields "<tag>" "<code>" "<charsToIgnore>"
      Des étiquettes multiples (champs) peuvent être spécifiées, séparées par des virgules. Des codes multiples (sous-champs) peuvent être spécifiés sans espace pour les séparer. Un ou plusieurs caractères (alphanumériques ou ponctuation) sans espace pour les séparer peuvent être spécifiés en tant que caractères à ignorer à la fin du contenu des sous-champs en cours d'évaluation pour duplication. Voir l'Exemple 6 pour plus d'informations.
      Pour les notices qui remplissent la condition recordHasDuplicateSubfields (retourne vrai), un ensemble des notices est créé.
    Chaque action de clause IF peut avoir l'un des formats suivants :
    • Est appliqué lorsqu'une condition spécifique n'est pas vraie, par exemple : addControlField "{element}" if(not exists "{condition}")
    • Est appliqué lorsqu'une condition spécifique est vraie, par exemple : addControlField "{element}" if(exists "{condition}")
    • S'applique sans condition, par exemple : addControlField "{element}"
    L'opérateur booléen OU peut être utilisé dans une déclaration de conséquence en utilisant le symbole de la barre verticale (|), par exemple : removeField "866" if (not exists "866.8.0|99"). Dans les cas où la barre verticale fait partie de la valeur, vous devez utiliser quatre barres obliques (\\\\) pour fermer la chaîne, par exemple : removeField "866" if (exists "866.8.0\\\\|99")
    Nous savons que la barre verticale | n'est pas placée dans une séquence d'échappement. Ce problème doit être résolu dans les versions à venir. 

    Liste d'actions

    Le tableau suivant fournit une liste des actions disponibles.
    Liste d'actions
    Action Format / Exemple Commentaire
    Remplacer les champs et les sous-champs par d'autres champs et sous-champs changeControlField "<tag>" to "<new tag>"
    Exemple : ChangeControlField "007" to "008"
    Change l'identifiant de l'étiquette d'un champ de contrôle ; ne modifie pas le contenu.
    changeField "<tag>" to "new tag"
    Exemple : changeField "245" to "246"
    Change l'identifiant de l'étiquette ; ne modifie pas les indicateurs ou les sous-champs.
    changeSubField "<tag>.<code>" to "<new code>"
    changeSubFieldOnlyFirst "<tag>.<code>" to "<new code>"
    changeSubFieldExceptFirst "<tag>.<code>" to "<new code>"
    Exemple : changeSubField "035.b" to "a"
    Change les sous-champs (ou uniquement le premier sous-champ, ou bien tous les sous-champs sauf le premier) "<code>" en sous-champ "<new code>" dans le champ "<tag>".
    changeFirstIndicator "<tag>" to "<value">
    changeSecondIndicator "<tag>" to "<value">
    Exemple : changeFirstIndicator "245" to "3"
    Définit la valeur de l'indicateur spécifié dans l'étiquette <tag>.
    combineFields "<tag>" excluding "<comma-separated subfield list>"
    Exemple : combineFields "852" excluding "a,b"
    Combine tous les champs d'un numéro spécifique. Copie tous les sous-champs à partir de la seconde et des lignes subséquentes à la première ligne, sauf les sous-champs nommés : seules les occurrences des sous-champs exclus sont copiées, et seulement s'ils n'existent pas sur la première ligne.
    Ajouter des champs et sous-champs addField "<tag>.<code>.<value>"
    addField "<tag>.{<ind1>,<ind2>}.<code>. <value>"
    Exemple : addField "999.a.RESTRICTED"
    Ajoute le champ à la notice MARC. Définit la valeur du sous-champ à la valeur indiquée.
    addControlField "<tag>"."<value>"
    Exemple : addControlField "008.820305s1991####nyu###########001#0#eng##"
    Ajoute le champ de contrôle à la notice MARC.
    addSubfield "<tag>.<code>.<value>"
    addSubfield "<tag>.{<ind1>,<ind2>}.<code>.<value>"
    Exemple : addSubfield "245.h.[Journal]"
    Ajoute le sous-champ <code> avec la valeur <value> dans le champ <tag>. Si le champ n'existe pas, rien n'est fait.
    addSystemNumber "<element>" from "<tag>" prefixed by "<prefix tag>"
    Exemple : addSystemNumber "035.a" from "001" prefixed by "003"
    Ajuste les données du champ <element> au contenu du deuxième champ de contrôle <prefix tag> entre parenthèses suivi du contenu du premier champ de contrôle <tag>.
    Par exemple, si le champ 001 a la valeur 9945110100121 et si le champ 003 a la valeur DAV, la condition de l'exemple à gauche indiquera 035 avec la valeur ‡(DAV)9945110100121.
    Copier des champs copyField "<tag>" to "<new tag>"
    copyField "<tag>.<code>" to "<new tag>.<new code>"
    copyField "<tag>" to "<new tag>.{<ind1>,<ind2>}"
    Exemple : copyField "971.a" to "100.u"
    Copie des champs vers un autre champ. Dans la première version, les sous-champs ne sont pas précisés (<code> et <new code>), et le nouveau champ contient les mêmes sous-champs que l'ancien champ. Dans la seconde version, si seul le champ <new code> n'est pas indiqué, le nouveau sous-champ est identique à celui spécifié par le champ <code>.
    copyField créé un champ séparé plutôt que de l'ajouter à un champ existant. Vous pouvez souhaiter combiner le nouveau champ à n'importe quels champs existants (voir combineFields).
    Supprimer des champs et sous-champs removeControlField "<tag>"
    Exemple : removeControlField "009"
    Supprime toutes les occurrences du champ de contrôle.

    Veuillez noter que si vous supprimez le champ de contrôle 008, Alma le recrée immédiatement si vous ne vous en chargez pas vous-même. Pensez à ajouter à nouveau ce champ après l'avoir supprimé, par exemple :

    rule "remove 008"
    when
    (TRUE)
    then
    removeControlField "008"
    addControlField "008.######s2013####xx######r#####000#0#eng#d"
    end
    removeField"<tag>"
    Exemple : removeField "880"
    Supprime toutes les occurrences du champ <tag>.
    removeSubfield "<tag>.<code>"
    Exemple : removeSubfield "245.h"
    Supprime toutes les occurrences du sous-champ <code> du champ indiqué.
    Remplacer du texte dans les champs et sous-champs replaceControlContents "<tag>.{<position>,<length>}.
    <value>" with "<new value>"
    Exemple : replaceControlContents "LDR.{7,1}.s" with "m"
    Remplace <value> par "<new value>" dans la position de départ <position> jusqu'à <position>+<length> dans le champ de contrôle <tag>. Remplace uniquement le texte qui correspond à <value>.
    replaceContents "<tag>.<code>.<value>" with "<new value>"
    replaceContentsOnlyFirst "<tag>.<code>.<value>" with "<new value>"
    replaceContentsExceptFirst "<tag>.<code>.<value>" with "<new value>"
    Exemple : replaceContents "245.h.[Journal]" with "[Book]"
    Remplace les chaînes correspondantes (ou chaque instance de la chaîne de caractères correspondante dans le premier sous-champ correspondant ou bien toutes les chaînes de caractères correspondantes dans tous les sous-champs correspondants sauf pour le premier sous-champ correspondant) <value> dans le sous-champ <code> du champ "<tag>" avec "<new value>". La chaîne ou la partie de la chaîne qui ne correspond pas à <value> n'est pas modifiée.
    replaceSubFieldContents "<tag>.<code>" with "<tag>.<code>"
    Exemple : replaceSubFieldContents "245.b" with "100.a"
    Remplace le contenu du sous-champ avec le contenu d'un autre sous-champ.

    replaceFixedContents "<tag>.{<1_ind>,<2_ind>}.<code>.{<position>,<length>}.<value>" with "<new value>"

    Exemple : replaceFixedContents "100.{1,2}.a.{0,8}.20150226" avec "20220724"

    Remplace <value> par <new value> dans les champs de position fixe UNIMARC et CNMARC 1XX.

    Pertinent uniquement pour les champs UNIMARC/CNMARC 1XX.

    Ajouter du texte dans des sous-champs
     
    prefix "<tag>.<code>" with "<value>"
    Exemple : prefix "035.b" with "(OCoLC)"
    Ajoute un préfixe à la valeur du sous-champ "<code>" dans le champ "<tag>".
    La nouvelle valeur sera <value> suivie par l'ancienne valeur.
    prefixSubField "<tag>.<code>" with "<source tag>.<source code>"
    Exemple : prefixSubField "910.a" with "906.a"
    Ajoute la valeur du sous-champ "<source code>" dans le champ "<source tag>" comme préfixe au sous-champ "<code>" dans le champ "<tag>".
    La nouvelle valeur sera la valeur du sous-champ "<source code>" dans le champ "<source tag>" suivie par l'ancienne valeur.
    suffix "<tag>.<code>" with "<value>"
    Exemple : suffix "035.b" with "(OCoLC)"
    Ajoute un suffixe au sous-champ "<code>" dans le champ "<tag>".
    La nouvelle valeur sera l'ancienne valeur suivie par <value>.
    suffixSubField "<"<tag>"code>" with "<source tag>.<source code>"
    Exemple : suffixSubField "910.a" with "907.c"
    Ajoute la valeur du sous-champ "<source code>" dans le champ "<source tag>" comme suffixe au sous-champ "<code>" dans le champ "<tag>".
    La nouvelle valeur sera l'ancienne valeur suivie de la valeur du sous-champ "<source code>" dans le champ "<source tag>".
    Maintenir les informations de l'agence dans des notices bibliographiques et d'autorité
    Par exemple, cette syntaxe peut être utilisée dans les règles de normalisation qui sont sélectionnées dans la Liste des tâches de configuration des métadonnées bibliographiques MARC 21 pour normaliser les notices bibliographiques de la Zone réseau lors de leur enregistrement.
    Cette fonctionnalité est en construction. Pour activer cette syntaxe, contactez le Support Ex Libris.
    addCreatingAgency "<tag>.<code>"
    Exemple : addCreatingAgency "040.a"
    Ajoute le code ISIL de l'agence de création au sous-champ "<code>" dans le champ "<tag>".
    addModifyingAgency "<tag>.<code>"
    Exemple : addModifyingAgency "040.d"
    Remplace le code ISIL de l'agence à l'origine de la modification au sous-champ "<code>" dans le champ "<tag>". S'il existe déjà une agence à l'origine de la modification dans "<tag>.<code>", ceci ajoute un autre code d'agence ISIL.
    replaceModifyingAgency "<tag>.<code>"
    Exemple : replaceModifyingAgency "040.d"
    Remplace le code ISIL de l'agence à l'origine de la modification au sous-champ "<code>" dans le champ "<tag>". S'il existe déjà des agences à l'origine de la modification dans "<tag>.<code>", elles sont toutes remplacées.
    Couper les sous-champs splitSubField "<tag>.{ind1,ind2}.<code>.<delimiter>" to "<tag>.{<ind1>,<ind2>}.<code>" addSeq "<code>"
    Exemple 1 : splitSubField "866.a.;" to "555.{0,0}.a" addSeq "8"
    Exemple 2 : splitSubField "555.a. – " to "859.{0,0}.a" addSeq "8"
    Exemple 3 : splitSubField "859.a.\\\\."
    Exemple 4 : splitSubField "999.a.;" to "555.a" addSeq "8"
    Cette étiquette est obligatoire.
    Les indicateurs sont optionnels.
    Comme la coupure a lieu au niveau du sous-champ, le code est obligatoire.
    Le séparateur peut être n'importe quelle chaîne. Si aucun séparateur n'existe, le sous-champ est copié en entier comme première (et unique) occurrence et la séquence est ajoutée.
    Le composant to est optionnel. S'il est précisé, plusieurs occurrences du code to sont créés, chacune contenant les données jusqu'au séparateur. Voir les exemples 1 et 2. Si le composant to n'est pas précisé, le sous-champ est divisé selon les mêmes sous-champs supplémentaires dans le même champ, comme indiqué dans l'exemple 3.
    Le composant addSeq est optionnel. Il n'est pas important si le composant to n'est pas précisé. Lorsque le composant addSeq est renseigné, le sous-champ avec la séquence sera ajouté comme dans l'exemple 1. Si le sous-champ existe déjà dans le champ original, une séquence (commençant par un point) est ajoutée à ce champ comme indiqué dans l'exemple 2.

    Supprimer les sous-champs dupliqués

    correctDuplicateSubfields "<tag>" "<code>"

    Par exemple : 

    Élimine les sous-champs x, y et z dupliqués des champs 610 et 630. 
    règle "Éliminer les duplicatas" 
    priorité 1 
    lorsque 
    (VRAI) 
    ensuite 
    correctDuplicateSubfields "610,630" "xyz" 
    fin

    Corrige les sous-champs en double (par exemple, les sous-champs ayant le même code ET la même valeur= en conservant la première occurrence et en supprimant les autres de la notice actuelle, en fonction des champs et sous-champs transmis en tant que paramètres.

    Vous pourrez utiliser recordHasDuplicateSubfields pour créer l'ensemble que vous fournirez à votre règle de normalisation qui utilise correctDuplicateSubfields. Voir l'Exemple 6 pour plus d'informations.

    Pour dédupliquer les sous-champs ayant différentes valeurs, voir : 
    How to remove all but one of several similar subfields in the same field in MD Editor.

    Déplacer les sous-champs

    moveSubfieldsToEndOfField "<tag>" "<code>"

    Par exemple : 

    Déplace les sous-champs 9 et 2 à la fin du champ 650.
    règle "Déplace les sous-champs à la fin du champ" 
    priorité 1 
    lorsque 
    (VRAI) 
    ensuite 
    moveSubfieldsToEndOfField "650" "92" 
    fin

    Déplace la première occurrence de chaque sous-champ à la fin du champ et supprime toutes les autres occurrences du même sous-champ.

    Si plus d'un sous-champ est spécifié, ils sont placés à la fin dans la même séquence que celle identifiée dans la règle. Dans cet exemple, le sous-champ 9 e placé à la fin, suivi du sous-champ 2.

    Veuillez noter que la déclaration if n'est pas prise en charge avec l'action moveSubfieldsToEndOfField.

    Corriger les champs dupliqués pour la notice actuelle

    correctDuplicateFields "{fields}"

    Par exemple :

    correctDuplicateFields "610,630,650"

    Cette action prend un paramètre, les champs, qui contient des valeurs de champ séparées par des virgules, telles que 610,630,650.

    Cette action corrige les champs dupliqués de la notice actuelle, en fonction des champs transmis en tant que paramètres.

    Trouver des champs dupliqués

    (Règles d'indication ; voir Travailler avec des règles d'indication)

    recordHasDuplicateFields "{fields}"

    Par exemple :

    recordHasDuplicateFields "610,630,650"

    Cette action prend un paramètre, les champs, qui contient des valeurs de champ séparées par des virgules, telles que 610,630,650.

    Cette action peut renvoyer la valeur vrai ou faux. Elle renvoie la valeur vrai si des champs dupliqués ont été trouvés pour la notice actuelle, en fonction des champs transmis en tant que paramètres.

    Jokers et caractères spéciaux

    Bien que l'utilisation d'expressions régulières ne soit pas actuellement entièrement prise en charge dans les règles de normalisation d'Alma, certaines expressions régulières peuvent être utilisées. Pour voir des exemples, consultez Exemples de règle de normalisation d'Alma.
    Le délimiteur de sous-champ ($$) ne peut s'afficher n'importe où dans la règle, y compris dans le nom de la règle.
    Un caractère dièse (#) au début d'une ligne indique que le reste de la ligne correspond à un commentaire et doit être ignoré lors du traitement de la règle.
    L'astérisque (*) est utilisé pour correspondre à n'importe quelle chaîne de caractères, y compris une chaîne vide. Par exemple, "<tag>.<*>.<value>" s'applique à tous les sous-champs de l'étiquette <tag> dont la valeur est <value>. * est "gourmand", donc il assortit autant de caractères que possible dans la chaîne de caractères. Par exemple, si vous avez une chaîne de caractères "a b c b d b e", le motif "b*b" assortit "b c b d b", et non pas seulement "b c b".
    Les indicateurs vides (mais pas les champs ou sous-champs) sont indiqués par un trait d'union (-). Par exemple, "<tag> {-,<ind2>}" renvoie tous les champs dans lesquels l'étiquette MARC est <tag>, le premier indicateur n'est pas défini et le deuxième indicateur est <ind2>.
    Si le texte d'un sous-champ contient un point comme dernier caractère, utilisez quatre barres obliques inversées pour compléter le point. Par exemple :
    rule "Replace '1 v.' to Leaves $$a (unconditional)"
    when
    (TRUE)
    then
    replaceContents "300.a.1 v\\\\." with "Leaves"
    end
    Des guillemets doubles peuvent être utilisés dans des conditions (uniquement). Pour utiliser des guillemets doubles dans une condition, utilisez des guillemets simples pour encadrer du texte dans la règle (') à la place des guillemets doubles ("). De cette manière, vous pouvez utiliser des guillemets doubles à l'intérieur d'un texte à la suite de deux barres obliques inversées (\\).
    rule "populate 008 7-10 2016"
    when
    (exists '245.{*, }.c.\"')
    then
    replaceControlContents "008.{7,4}" with "2016"
    end
    Des dates en hébreu peuvent être utilisées dans les conditions (uniquement). (l'Hébreu se lit de droite à gauche, de telle sorte que les deux barres obliques inversées dans l'exemple suivant se trouvent avant les guillemets doubles)
    rule "populate 008 7-10 2016"
    when
    ((exists '260.{*, }.c.תשע\\"ו') OR (exists '264.{*, }.c.תשע\\"ו'))
    then
    replaceControlContents "008.{7,4}" with "2016"
    end
    • Des caractères spéciaux ne peuvent pas être utilisés comme premier caractère d'une condition ou d'une valeur.
    • Pour utiliser une barre oblique inversée littéralement (\), faites-la précéder d'une autre barre oblique inversée : \\
    • Utilisez quatre barres obliques inversées (\\\\) pour faire échapper un point lorsqu'il s'agit du dernier caractère de la chaîne de caractères. Lorsque le point est immédiatement suivi d'un autre caractère, il n'a pas besoin d'être précédé par quatre barres obliques inversées (tel que dans addField "907.a.F.L.T\\\\."). Toutefois, la meilleure pratique est de toujours utiliser les quatre barres obliques inversées dans les règles de normalisation pour garantir les meilleurs résultats possibles en fonction des résultats désirés. Voir les exemples suivants.
    • Comme mentionné ci-dessus, si des guillemets doubles sont utilisés dans une condition (uniquement) qui est échappée à l'aide de guillemets simples ou si des guillemets simples sont utilisés dans une condition qui est échappée à l'aide de guillemets simples, vous devez échapper en plus les guillemets doubles ou les guillemets suivis de deux barres obliques inversées.
    • Dans les cas où la barre verticale fait partie de la condition, faites-la précéder de quatre barres obliques inversées (\\\\), par exemple : removeField "866" if (exists "866.8.0\\\\|99") Ceci est nécessaire uniquement si vous utilisez le symbole de la barre verticale dans la condition.

    Exemple : Utiliser un point dans une règle de normalisation avec replaceContents

    Exemple de notice avec des points :
    245 00 $$a Feminist literary theory. : $$b a reader / $$c edited by Mary Eagleton.
    246 0# $$a F.L.T.
    Règle de normalisation pour l'exemple de notice ci-dessus :
    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
    Voir le schéma ci-dessous pour les exemples "avant" et "après".
    Before_and_After_Examples_of_Normalization_Rule with_Periods_Using_ replaceContents_02.png
    Exemples Avant et Après

    Exemple : Utiliser un point dans une règle de normalisation avec addField

    Ci-dessous est un exemple de notice à laquelle des points doivent être ajoutés.
    906 $$a Architecture.
    907 $$a F.L.T.
    Ci-dessous est une règle de normalisation pour l'exemple de notice ci-dessous en utilisant la meilleure méthode qui est de toujours ajouter les barres :
    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
    Voir le schéma ci-dessous pour les exemples de notice "avant" et "après".
    Before_and_After_Examples_of_Normalization_Rule with_Periods_Using_ addField_02.png
    Exemples Avant et Après

    Exemple de règle de normalisation

    Pour une liste de plus de 50 exemples de règles de normalisation et d'autres documents sur les règles de normalisation, voir Règles de normalisation.
    • Was this article helpful?