Contrôler les bonnes pratiques et publier un instrument de recherche
1. Hiérarchie des règles applicables à un instrument de recherche en XML/EAD
2. Contrôler les Bonnes Pratiques
2.1. Contrôles bloquants
2.2. Contrôles non bloquants
3. Publier un instrument de recherche
3.1. Publication à l’unité
3.2. Publication par lot
3.3.Publication partielle d’un instrument de recherche
3.4.Dépublication
Un instrument de recherche doit respecter un certain nombre de règles qui sont détaillées dans cette fiche. PiXML permet de les contrôler avant de le publier et le rendre visible dans BnF Archives et manuscrits (BAM).
1. Hiérarchie des règles applicables à un instrument de recherche en XML/EAD
Un instrument de recherche au format XML/EAD doit être à la fois « bien formé », c’est-à-dire conforme à la syntaxe XML, et « valide », c’est-à-dire respectant les règles définissant la description archivistique encodée selon la DTD EAD 2002 (définition de type de document EAD).
PiXML contrôle automatiquement la conformité et la validité de l'instance EAD en cours d'édition au moment de l'enregistrement, que ce soit à partir de l’éditeur intégré (XEditor) ou suite à une édition externe. Ce contrôle est renouvelé à chaque demande de publication dans BAM.
En outre, le Guide des bonnes pratiques de l'EAD en bibliothèque émet des préconisations sur l'utilisation du format EAD dans le contexte de la description de manuscrits ou de fonds d'archives dans les bibliothèques françaises. Cela permet de fournir un cadre d’utilisation garantissant, au niveau national, la cohérence des données à des fins d’indexation, d’affichage et de recherche dans des outils mutualisés tels que le Catalogue Collectif de France.
PiXML intègre un contrôle des bonnes pratiques les plus importantes, jugées fondamentales pour la qualité et l'interopérabilité des données. Il peut être déclenché à la demande grâce au bouton Contrôler les bonnes pratiques de l'affichage de travail de PiXML pour générer un rapport d’erreurs. Il est également réalisé, silencieusement (sans rapport d’erreurs), à chaque demande de publication unitaire d'un instrument de recherche dans BAM.
Deux types d’erreurs peuvent être détectées :
- les erreurs bloquantes (signalées en rouge) sont à corriger obligatoirement en vue de la publication de l'instrument de recherche : celui-ci ne pourra pas être publié tant qu'elles ne seront pas corrigées ;
- les erreurs non bloquantes (signalées en jaune) n'empêchent pas la publication de l'instrument de recherche mais il est vivement recommandé de les corriger dans le but d'améliorer la qualité des données.
Il est conseillé de s'assurer régulièrement qu’un instrument de recherche en cours de production ou de révision est conforme aux bonnes pratiques, afin de limiter le nombre de corrections éventuelles lors de la demande de publication.
Toutes les recommandations du Guide des bonnes pratiques de l’EAD en bibliothèque ne font pas l’objet d’un contrôle, mais les catalogueurs sont vivement incités à les consulter régulièrement pour les mettre en œuvre au mieux. En cas de doute sur l’interprétation d’une bonne pratique, il est recommandé de se rapprocher du coordinateur de proximité de son département, de la Coordination du domaine catalogue à la DCO, et si besoin de la coordinatrice des données EAD au département des Métadonnées.
Le contrôle des bonnes pratiques ne s’applique pas aux composants destinés à Mandragore (sur fond mauve dans l’affichage de travail), qui présentent le caractère d’un « projet spécifique » au sens du Guide des bonnes pratiques, et respectent des règles particulières.
2. Contrôler les Bonnes Pratiques
La fonction Contrôler les Bonnes Pratiques peut être déclenchée à tout moment en cliquant sur le bouton en haut de la page d'affichage de travail d'un instrument de recherche, au même niveau que la fonction Prévisualiser l'IR : il est conseillé, avant toute publication, d'utiliser ces deux fonctionnalités pour vérifier à la fois que l'instrument de recherche est conforme aux bonnes pratiques et qu'il s'affiche correctement dans BAM.
Le contrôle des Bonnes Pratiques peut s'employer à tous les niveaux de l'instrument de recherche : au niveau d'un composant seul, d'une branche ou de l’instrument de recherche complet. Dans l'exemple ci-dessous on souhaite appliquer le contrôle à une branche :
Le rapport signale d'abord les erreurs bloquantes (qui doivent être corrigées avant toute publication), puis les erreurs non bloquantes. Les erreurs sont affichées par ordre de gravité, et regroupées pour afficher ensemble les erreurs de même type. Des liens cliquables permettent d'accéder rapidement aux composants dans lesquels sont situées les erreurs à corriger.
2.1. Contrôles bloquants
Les bonnes pratiques contrôlées sont les suivantes.
|
Élément contrôlé |
Message d'erreur affiché par PiXML |
Remarque |
|---|---|---|
|
Identification de l'organisme responsable de l'accès intellectuel au(x) document(s) |
||
|
Absence de <repository> dans <archdesc> (et <repository> n'est pas non plus présent dans un <c>) |
L'élément <archdesc> doit contenir un <repository> pour indiquer les informations sur l'institution de conservation. |
L'élément <repository> (Organisme responsable de l’accès intellectuel) est obligatoire. Il est saisi au niveau <archdesc>, sauf cas exceptionnels : fonds dont la gestion est répartie entre deux institutions, IR de présentation des fonds. Dans ce cas, <repository> peut être saisi au niveau d'un composant <c>. Un contrôle non bloquant est prévu pour ce cas de figure. |
|
Identification du document |
||
|
Absence de <unittitle> ou <unitid> dans <did> |
<did> ne contient pas de <unittitle> ou de <unitid>. Veuillez ajouter au moins un <unittitle> ou un <unitid> dans votre <did>. |
Tout composant doit être identifié par un intitulé documentaire (<unititle>) et/ou une cote (<unitid>). |
|
Absence d'attribut @type dans <unitid> |
<unitid> ne comporte pas d'attribut @type. Veuillez compléter l'attribut avec les valeurs suivantes : cote, ancienne cote, division. |
Chaque élément de cote (<unitid>) doit être qualifié. |
|
Présence de plusieurs <unitid type="cote"> dans un composant <archdesc> |
L'élément <archdesc> contient plusieurs <unitid type="cote">. Un seul <unitid type="cote"> est autorisé par <archdesc>. |
Le document ne peut porter qu'une seule cote actuelle (<unitid type="cote">). |
|
Présence de plusieurs <unitid type="cote"> dans un composant <c> |
L'élément <c> contient plusieurs <unitid type="cote">. Un seul <unitid type="cote"> est autorisé par <c>. |
Le document ne peut porter qu'une seule cote actuelle (<unitid type="cote">). |
|
Identification des langues |
||
|
Absence de l'élément <language> dans <langmaterial> |
L'élément <langmaterial> ne contient pas d'élément <language>. Cet élément est recommandé pour encoder la langue du document et est accompagné de l'attribut @langcode pour coder la langue décrite. |
La langue du document doit être encodée dans <langmaterial> avec une ou plusieurs balises <language > dotées de l’attribut @langcode. |
|
Absence d'attribut @langcode dans <language> |
L'élément <language> n'a pas d'attribut @langcode. Ce dernier est nécessaire pour coder la langue décrite. |
La langue mentionnée en <language> doit être normalisée dans l’attribut @langcode (référentiel ISO 639-2). |
|
Contrôle sur les <dao> pour Gallica (règles spécifiques à la BnF) |
||
|
Présence de <dao> dans <did> |
L'élément <dao> doit se trouver hors de <did>. |
Les objets archivistiques numériques (<dao>) doivent être renseignés en dehors de <did>. |
|
Absence d'attribut @href dans <dao> |
L'élément <dao> doit porter un attribut @href. |
L'élément <dao> contient obligatoirement un attribut @href qui donne le lien vers le document numérisé dans Gallica ou Gallica Intramuros. |
|
L'attribut @href dans <dao> ne correspond pas à une URL Gallica ou Gallica Intramuros |
La valeur de l'attribut @href sur <dao> doit correspondre à une URL Gallica ou Gallica intramuros. |
À la BnF, l’élément <dao> est exclusivement utilisé pour établir le lien entre l’instrument de recherche et la version numérisée, ou nativement numérique, accessible dans Gallica. L'attribut @href contient obligatoirement une URL renvoyant vers Gallica ou Gallica Intramuros. Si on souhaite renvoyer vers une version numérisée du document dans une autre bibliothèque numérique, on utilise un élément <extref>. |
|
Contrôle sur les liens hypertextuels |
||
|
Absence d'attribut @href dans <extref> |
L'élément <extref> doit porter un attribut @href. |
L'élément <extref> permet d’encoder une référence externe et doit obligatoirement contenir un attribut @href qui donne l'URL de la ressource cible. |
|
Absence de l'attribut @target dans <ref> |
L'élément <ref> doit porter un attribut @target. |
L'élément <ref> permet d’encoder une référence interne à l’instrument de recherche et doit obligatoirement contenir un attribut @target qui donne l'identifiant du composant cible. |
2.2. Contrôles non bloquants
|
Élément contrôlé |
Message d'erreur affiché par PiXML |
Remarque |
|---|---|---|
|
Métadonnées de l'instrument de recherche |
||
|
Absence d'élément <profiledesc> dans <eadheader> |
L'élément <profiledesc> est vivement conseillé dans le <eadheader>. |
L'élément <profiledesc> est fortement recommandé par le Guide des bonnes pratiques. Il permet de donner des informations concernant l'encodage de l'instrument de recherche, sa langue de rédaction et les règles de description adoptées. |
|
Absence de l'élément <language> dans <language> |
L'élément <langusage> ne contient pas d'élément <language>. Cet élément est recommandé pour encoder la langue de l'instrument de recherche et est accompagné de l'attribut @langcode pour coder la langue décrite. |
La langue dans laquelle l'instrument de recherche est rédigé doit être encodée dans <langusage> avec une ou plusieurs balises <language> dotées de l’attribut @langcode. Il s’agit normalement du français. |
|
Identification de l'organisme responsable de l'accès intellectuel au(x) document(s) |
||
|
Absence de <repository> dans <archdesc> (mais <repository> est présent dans un <c>) |
L'élément <repository> est saisi de préférence au niveau <archdesc> pour indiquer les informations sur l'institution de conservation. Le seul cas de figure où <repository> peut être saisi au niveau des composants <c> concerne les fonds répartis sur plusieurs sites ou institutions. |
L'utilisation de <repository> (organisme responsable de l’accès intellectuel) dans un composant <c> est admise uniquement dans des cas exceptionnels : fonds dont la gestion est répartie entre deux institutions, IR de présentation des fonds. Dans tous les autres cas <repository> doit être saisi au niveau <archdesc>. Le contrôle est non bloquant afin de permettre la publication des quelques IR concernés. |
|
Absence de <corpname> dans <repository> |
L'élément <repository> doit contenir un <corpname> pour renseigner le nom de l'institution de conservation. |
Le nom de l'organisme responsable de l'accès intellectuel au(x) document(s) est obligatoirement saisi dans un élément <corpname>. On utilise les attributs @source et @authfilenumber afin de donner le numéro RCR propre à chaque département, sauf pour les IR décrivant des numérisations réalisées à partir de documents appartenant à des tiers non institutionnels (Collections privées, plus rarement Collections partenaires). Le contrôle est non bloquant afin de permettre la publication des quelques IR concernés. |
|
Identification du niveau de description |
||
|
Absence d'attribut @level dans <c> |
L'élément <c> ne contient pas d'attribut @level. Veuillez ajouter l'attribut avec les valeurs suivant le référentiel. |
L'identification du niveau de description est obligatoire ; toutefois au vu des volumétries à reprendre le contrôle n'est pas bloquant. |
|
Conditions d’accès, statut juridique de l’unité documentaire |
||
|
Absence de l’élément <legalstatus> dans <archdesc> |
L'élément <legalstatus> doit être présent dans l'instrument de recherche pour préciser le statut juridique des documents ("Document patrimonial" par exemple). Sa valeur doit être précisée avec un @type. |
Le statut patrimonial et la nature du propriétaire des unités documentaires décrites doivent être encodées dans <legalstatus> dotées de l’attribut @type. |
|
Absence d'attribut @type dans <legalstatus> |
L'élément <legalstatus> doit être précisé avec un @type. |
|
|
Identification du document |
||
|
Présence d’un <unitid type= "ancienne cote"> sans <unitid type="cote"> |
Une "ancienne cote" doit être accompagnée d'une 'cote'. |
Une ancienne cote ne suffit pas à identifier un composant. La cote actuelle doit toujours figurer. |
|
Encodage des dates |
||
|
Absence d'attribut @normal dans <unitdate> (ou attribut vide) |
<unitdate> ne comporte pas de @normal. |
La date est obligatoirement donnée sous forme normalisée dans l'attribut @normal, en suivant la norme ISO 8601. Voir la fiche Éléments <unitdate> et <date> : saisie de l'attribut @normal à la BnF. Toutefois au vu des volumétries à reprendre le contrôle n'est pas bloquant. |
|
Absence d'attribut @normal dans <date> |
<date> ne comporte pas d'attribut @normal. |
La date est obligatoirement donnée sous forme normalisée dans l'attribut @normal, en suivant la norme ISO 8601. Attention, seules les dates importantes pour la compréhension des documents doivent être indexées dans <date>. Voir la fiche Éléments <unitdate> et <date> : saisie de l'attribut @normal à la BnF. Toutefois au vu des volumétries à reprendre le contrôle n'est pas bloquant. |
|
Valeur de @normal dans <unitdate> non conforme à la norme ISO 8601 |
La valeur de l'attribut @normal de <unitdate> ne suit pas la norme ISO. Merci de suivre le format suivant : AAAAMMJJ ou AAAAMM ou AAAA ou AAAAMMJJ/AAAAMMJJ ou AAAAMM/AAAAMM ou AAAA/AAAA. |
La date est obligatoirement donnée sous forme normalisée dans l'attribut @normal, en suivant la norme ISO 8601. Voir la fiche Éléments <unitdate> et <date> : saisie de l'attribut @normal à la BnF. |
|
Encodage des noms |
||
|
Absence des attributs @role et @normal dans <persname> |
L'élément <persname> doit avoir les attributs @role et @normal pour préciser le rôle ainsi que la forme normalisée de l'entité. |
Les attributs @normal et @role doivent être systématiquement utilisés pour donner une valeur normalisée et indiquer la relation entre la personne et le document décrit. Toutefois au vu des volumétries à reprendre, le contrôle est non bloquant. |
|
Absence des attributs @source et @authfilenumber dans <persname> |
L'élément <persname> doit avoir les attributs @source et @authfilenumber pour préciser une fiche d'autorité pour l'entité ainsi qu'un identifiant pérenne. |
Chaque fois que cela est possible, on se lie à une entité Personne et identité publique. Dans ce cas, les attributs @source et @authfilenumber sont automatiquement remplis lors du report automatique. Voir la fiche Lien avec les notices d'autorité dans un instrument de recherche. |
|
Absence des attributs @role et @normal dans <corpname> (sauf si <corpname> est contenu dans <repository>) |
L'élément <corpname> doit avoir les attributs @role et @normal pour préciser le rôle ainsi que la forme normalisée de l'entité. |
Les attributs @normal et @role doivent être systématiquement utilisés pour donner une valeur normalisée et indiquer la relation entre la collectivité et le document décrit (sauf si <corpname> est dans <repository> : dans ce cas les attributs ne sont pas employés). Toutefois au vu des volumétries à reprendre, le contrôle est non bloquant. |
|
Absence des attributs @source et @authfilenumber dans <corpname> |
L'élément <corpname> doit avoir les attributs @source et @authfilenumber pour préciser une fiche d'autorité pour l'entité ainsi qu'un identifiant pérenne. |
Chaque fois que cela est possible, on se lie à une entité Collectivité. Dans ce cas, les attributs @source et @authfilenumber sont automatiquement remplis lors du report automatique. Voir la fiche Lien avec les notices d'autorité dans un instrument de recherche. |
|
Absence des attributs @role et @normal dans <famname> |
L'élément <famname> doit avoir les attributs @role et @normal pour préciser le rôle ainsi que la forme normalisée de l'entité. |
Les attributs @normal et @role doivent être systématiquement utilisés pour donner une valeur normalisée et indiquer la relation entre la famille et le document décrit. Toutefois au vu des volumétries à reprendre, le contrôle est non bloquant. |
|
Absence des attributs @source et @authfilenumber dans <famname> |
L'élément <famname> doit avoir les attributs @source et @authfilenumber pour préciser une fiche d'autorité pour l'entité ainsi qu'un identifiant pérenne. |
Chaque fois que cela est possible, on se lie à une entité Famille. Dans ce cas, les attributs @source et @authfilenumber sont automatiquement remplis lors du report automatique. Voir la fiche Lien avec les notices d'autorité dans un instrument de recherche. |
|
Absence des attributs @role et @normal dans <geogname> |
L'élément <geogname> doit avoir les attributs @role et @normal pour préciser le rôle ainsi que la forme normalisée de l'entité. |
Les attributs @normal et @role doivent être systématiquement utilisés pour donner une valeur normalisée et indiquer la relation entre le lieu et le document décrit. Toutefois au vu des volumétries à reprendre, le contrôle est non bloquant. |
|
Absence des attributs @source et @authfilenumber dans <geogname> |
L'élément <geogname> doit avoir les attributs @source et @authfilenumber pour préciser une fiche d'autorité pour l'entité ainsi qu'un identifiant pérenne. |
Chaque fois que cela est possible, on se lie à uneentité Lieu. Dans ce cas, les attributs @source et @authfilenumber sont automatiquement remplis lors du report automatique. Voir la fiche Lien avec les notices d'autorité dans un instrument de recherche. |
|
Présence d'éléments <name> |
Nous vous conseillons de préciser la valeur de <name> en le remplaçant par <persname> en cas d'un nom de personne, <corpname> en cas d'un nom d'organisation ou <famname> en cas d'un nom de famille. |
Les éléments <name> issus de la rétroconversion doivent être remplacés par les éléments d'indexation appropriés. Toutefois au vu des volumétries à reprendre, le contrôle est non bloquant. Seuls les noms propres typés comme des noms communs dans Rameau (noms de marques commerciales, noms d'animaux célèbres, noms astronomiques, ethnonymes, événements, et noms propres de choses) doivent être indexés en <name>. |
|
Usage de l'élément <note> |
||
|
Utilisation de l'élément <note> sans @type="absent" |
L'élément <note> est déconseillé sauf pour indiquer l'absence d'un document avec l'attribut @type="absent". Veuillez ajouter cet attribut ou utiliser une balise plus précise. |
L'élément <note> est utilisé uniquement pour signaler l’absence permanente du document décrit (disparition constatée, destruction accidentelle, transfert définitif ou dépôt). L’attribut TYPE a toujours pour valeur « absent ». |
|
Utilisation de l'élément <note> avec @type="provenance" |
L'élément <note> porte un attribut @type="provenance". Il est vivement conseillé de redistribuer les informations contenues dans les éléments <custodhist> ou <acqinfo>. |
L'élément <note> est utilisé uniquement pour signaler l’absence permanente du document décrit (disparition constatée, destruction accidentelle, transfert définitif ou dépôt). L’attribut TYPE a toujours pour valeur « absent ». Si l'attribut @type a pour valeur « provenance », il s'agit d'une mention issue de la rétroconversion du CGM. Dans ce cas transférer les mentions en <custodhist> ou <acqinfo> suivant le cas. |
|
Contrôle sur les liens hypertextuels |
||
|
La valeur de l'attribut @actuate dans <dao> est différente de « onrequest » |
La valeur de l'attribut @actuate sur <dao> est incorrecte. Elle doit correspondre à 'onrequest'. |
La valeur de l'attribut @actuate doit toujours être « onrequest » afin de laisser le choix à l'utilisateur d'accéder à la ressource cible en cliquant sur le lien hypertextuel. Par défaut, elle est à « onload » dans XEditor. Elle doit donc systématiquement être modifiée. |
|
La valeur de l'attribut @show dans <dao> est différente de « new » |
La valeur de l'attribut @show sur <dao> est incorrecte. Elle doit correspondre à 'new'. |
La valeur de l'attribut @show doit toujours être « new » afin de commander l'ouverture de la ressource cible dans une nouvelle fenêtre. Par défaut, elle est déjà à « new » dans XEditor : elle ne doit donc pas être modifiée. |
|
La valeur de l'attribut @actuate dans <extref> est différente de « onrequest » |
La valeur de l'attribut @actuate sur <extref> est incorrecte. Elle doit correspondre à 'onrequest'. |
La valeur de l'attribut @actuate doit toujours être « onrequest » afin de laisser le choix à l'utilisateur d'accéder à la ressource cible en cliquant sur le lien hypertextuel. Par défaut, elle est à « onload » dans XEditor. Elle doit donc systématiquement être modifiée. |
|
La valeur de l'attribut @show dans <extref> est différente de « new » |
La valeur de l'attribut @show sur <extref> est incorrecte. Elle doit correspondre à 'new'. |
La valeur de l'attribut @show doit toujours être « new » afin de commander l'ouverture de la ressource cible dans une nouvelle fenêtre. Par défaut, elle est déjà à "new" dans XEditor : elle ne doit donc pas être modifiée. |
|
Divers |
||
|
Présence d'éléments vides |
Les éléments vides doivent être supprimés. |
|
3. Publier un instrument de recherche
La création ou modification d’un instrument de recherche de PiXML n’est visible, dans BAM et/ou Mandragore, qu’à partir du moment où la publication (ou republication) de l’instrument de recherche est demandée. La publication ou la republication concerne toujours un instrument de recherche entier (et pas seulement une branche ou un composant).
La mise à jour de BAM et de Mandragore (notices et index de recherche) est quotidienne. Elle intervient en début de matinée, du lundi au vendredi. Toute publication ou dépublication produit donc généralement ses effets le lendemain matin. La prise en compte des modifications dans d’autres applications, comme Gallica ou le Catalogue collectif de France, peut intervenir après un délai plus important.
3.1. Publication à l’unité
La publication dans BAM peut être demandée depuis la page d’informations sur l’instrument de recherche, ou depuis l’affichage de travail d’un instrument de recherche (voir la fiche Identifier, visualiser, exporter un instrument de recherche).
La publication dans Mandragore peut être demandée uniquement depuis l’affichage de travail (pour les agents habilités).
Ces deux fonctions sont indépendantes : la publication dans BAM ne provoque pas la publication dans Mandragore, et réciproquement. Il est cependant conseillé de veiller à la cohérence des informations mises à disposition du public dans les deux applications.
Avant toute publication dans BAM, il est conseillé de relire l’instrument de recherche concerné, contrôler les bonnes pratiques et prévisualiser son affichage public.
La demande de publication commence par un contrôle automatique de la conformité du contenu XML, de la validité de l’EAD, et d’un contrôle des bonnes pratiques limité aux erreurs bloquantes. En cas d’échec de l’un de ces contrôles, la publication est annulée (après affichage d’un message d’erreur). Le rapport d’erreur est généré seulement en présence d’une erreur bloquante.
3.2. Publication par lot
Les coordinateurs de proximité peuvent être amenés à publier un ensemble d’instruments de recherche pour des raisons d’administration (par exemple suite à une insertion de donnée par DPI ou à une numérisation). PiXML met à disposition plusieurs outils pour cela :
- la publication d’un dossier entier (par clic droit dans le mode navigation) permet de (re)publier tous les instruments de recherche contenus dans le dossier et ses sous-dossiers ;
- la sélection pour publication (à partir du bandeau supérieur) permet de cliquer, dans le mode navigation sur plusieurs instruments de recherche à publier ensemble. La liste des IR sélectionnés s’affiche dans le volet de droite et il est possible d’en retirer des IR sélectionnés par erreur ; la demande de publication n’est effective qu’une fois cliqué sur le bouton Valider ;
- la publication par liste (à partir du bandeau supérieur) permet d’importer une liste d’instruments de recherches (identifiés par leur identifiant PiXML ou par leur EADID) au format CSV. Elle est notamment très utile pour la republication d’instruments de recherches contenant de nouveaux documents numérisés à partir d’une extraction SIPIL (voir la fiche Création et gestion d’une filière de numérisation depuis PiXML).
Dans le cadre d’une publication par lot, PiXML traite chaque instrument de recherche successivement en arrière-plan. Il est possible de visualiser l’avancement de ce traitement en utilisant la console de publication (accessible depuis le bandeau supérieur). La colonne source distingue les demandes réalisées à l’unité (I), par sélection manuelle (MS), par liste (L) ou par publication du dossier (D).
Pendant la durée du traitement, toute nouvelle demande de publication est mise sur liste d’attente. Il est donc déconseillé de publier par lot un nombre trop important d’instruments de recherche (environ 500 maximum), au risque de bloquer les demandes de publications pendant plusieurs heures (ou jours).
Attention : en publiant un lot d’instruments de recherches, il peut être difficile de vérifier si l’un d’entre eux n’est pas en cours d’édition, avec des modifications non achevées qui ne devraient pas être visibles dans BAM. Ces fonctionnalités sont à utiliser avec précaution par les coordinateurs de proximité.
Remarque : la publication par lot n’est pas adaptée en catalogage courant, car le contrôle des bonnes pratiques n’est pas activé. Cela permet en particulier de republier des corpus d’IRs issus de la rétroconversion sans faire toutes les corrections nécessaires dans le cas d’une nouvelle création ou modification.
3.3. Publication partielle d’un instrument de recherche
Lorsqu’il est indispensable de publier une partie d’un instrument de recherche alors que le reste est encore en cours de rédaction, il faut utiliser l’attribut AUDIENCE = "internal" sur le ou les composants à masquer à la publication. Pour rappel, l’attribut AUDIENCE = "internal" est hérité pour les composants fils. Il est vivement recommandé de prévisualiser l’instrument de recherche pour s’assurer que le résultat est bien conforme.
Attention : si les composants masqués étaient précédemment publiés, ils vont disparaître de BAM.
3.4. Dépublication
À partir de sa première publication, tout instrument de recherche est consultable et citable en utilisant son identifiant ARK, sa pérennité fait l’objet d’un engagement de la BnF.
La fonction de dépublication temporaire (de façon exceptionnelle) ou définitive (en vue de la suppression et/ou du remplacement d’un instrument de recherche) est à utiliser aussi rarement que possible. On se reportera à la fiche Dépublier, Supprimer, Rediriger un instrument de recherche.