Code source wiki de Remplir efficacement les champs clés d'une notice bien
Version 3.1 par Joséphine Ducruet le 2025/07/23 11:51
Masquer les derniers auteurs
| author | version | line-number | content |
|---|---|---|---|
| |
3.1 | 1 | (% class="mark small" %)**Versions 3.5 et ultérieurs**(%%) |
| |
2.1 | 2 | |
| 3 | |||
| 4 | |(% style="width:840px" %)((( | ||
| 5 | (% class="box" %) | ||
| 6 | ((( | ||
| 7 | La qualité des données saisies dans les notices Biens est essentielle pour assurer une **gestion fiable**, une **traçabilité réglementaire** et une **valorisation cohérente** des collections patrimoniales dans Flora. | ||
| 8 | |||
| 9 | Certains champs jouent un rôle structurant : ils conditionnent l’unicité des notices, leur bon rattachement aux modules transverses (récolement, mouvements, registres…), ou encore l’affichage des informations dans les exports, éditions ou interfaces publiques. | ||
| 10 | |||
| 11 | Cette page vous guide sur les **champs à ne pas négliger**, leur fonction, les **bonnes pratiques de saisie associées**, et les **erreurs courantes à éviter**. L’objectif : garantir des notices complètes, homogènes et conformes aux exigences documentaires et réglementaires de votre établissement. | ||
| 12 | ))) | ||
| 13 | |||
| 14 | ((( | ||
| |
3.1 | 15 | = Préfixe + numéro d'inventaire : la clé d’une notice bien identifiée = |
| |
2.1 | 16 | |
| 17 | * Le **préfixe** permet de différencier les inventaires de plusieurs musées ou ensembles au sein d’une même base Flora. Il doit être **saisi systématiquement** dans les notices Biens. | ||
| 18 | * Le **numéro d’inventaire** doit être **unique pour chaque préfixe **et est **obligatoire**. | ||
| 19 | * **Le couple //préfixe + numéro d’inventaire// garantit l’unicité du bien dans la base.** | ||
| 20 | |||
| 21 | [[Saisie d'un préfixe et du numéro d'inventaire>>image:1753262658351-198.png||data-xwiki-image-style-alignment="center" data-xwiki-image-style-border="true"]] | ||
| 22 | |||
| 23 | = Domaine musée vs Domaine SMF : à chacun son rôle = | ||
| 24 | |||
| 25 | Deux champs permettent de caractériser le domaine d’un bien dans Flora, mais ils répondent à **des usages différents**. Bien les distinguer permet d’assurer à la fois une **cohérence documentaire interne** et une **conformité aux exigences nationales** (notamment pour l’export vers POP). | ||
| 26 | |||
| 27 | **Domaine SMF** (Service des Musées de France) | ||
| 28 | |||
| 29 | * Champ lié à un **thésaurus contrôlé**. | ||
| 30 | * Utilisé pour répondre aux **normes nationales** de description. | ||
| 31 | * Permet de caractériser un bien selon un ou plusieurs domaines (support, fonction, discipline, culture...). | ||
| 32 | * Plusieurs domaines peuvent être associés à un même objet. | ||
| 33 | * Recommandé pour l’inventaire réglementaire et les exports normalisés. | ||
| 34 | |||
| 35 | **Domaine musée ** | ||
| 36 | |||
| 37 | * Champ lié à un** thésaurus local**, géré par l’établissement. | ||
| 38 | * Permet de **créer sa propre arborescence de domaines**, si celle du SMF ne convient pas ou n’est pas assez précise. | ||
| 39 | * Données exportées vers **POP** en tant que valeur complémentaire. | ||
| 40 | * Utile pour une **gestion interne plus fine ou adaptée** à la spécificité du fonds. | ||
| 41 | |||
| 42 | >(% class="small" %)Exemple : un musée souhaite distinguer "Mobilier scolaire" ou "Photographie missionnaire", non prévus dans la liste SMF. | ||
| 43 | |||
| 44 | (% class="box successmessage" %) | ||
| 45 | ((( | ||
| 46 | **Bonnes pratiques** | ||
| 47 | |||
| 48 | * **Ne pas confondre** les deux champs : | ||
| 49 | → //Domaine SMF// = cadre normatif national (thésaurus fermé) | ||
| 50 | → //Domaine musée// = cadre local, plus souple | ||
| 51 | * **Remplir en priorité le champ Domaine SMF**, lorsqu’une ou plusieurs valeurs du thésaurus conviennent. | ||
| 52 | * **Compléter avec Domaine musée** si nécessaire, pour affiner ou contextualiser le classement. | ||
| 53 | * Ne pas dupliquer la même valeur dans les deux champs sans raison : utilisez //Domaine musée// pour **compléter**, pas pour **copier**. | ||
| 54 | * Utiliser les autres champs spécialisés pour affiner la description (matériaux, dénomination, période, lieu…). | ||
| 55 | ))) | ||
| 56 | |||
| |
3.1 | 57 | = Création, exécution, attribution… ne mélangez pas tout = |
| |
2.1 | 58 | |
| 59 | Le bloc **Création – Exécution** permet de saisir les **informations relatives à la création du bien**, qu’il s’agisse d’une production certaine, d’une exécution partielle, d’une attribution ou d’une ancienne hypothèse. | ||
| 60 | |||
| 61 | Ce bloc est **répétable** autant de fois que nécessaire : chaque itération correspond à **un seul type de relation** entre le bien et ses auteurs, datations ou éléments de genèse. Tous les champs saisis dans un bloc donné doivent être **homogènes et cohérents** avec ce type défini. | ||
| 62 | |||
| 63 | (% class="box successmessage" %) | ||
| 64 | ((( | ||
| 65 | **Bonnes pratiques** | ||
| 66 | |||
| 67 | * Créer **un bloc distinct par type de relation** (ex. : une pour la création, une autre pour une attribution). | ||
| 68 | * Saisir dans chaque bloc **uniquement les éléments liés à ce type** : auteurs, dates, genèse, etc. | ||
| 69 | * Ne pas mélanger dans un même bloc des informations relevant de plusieurs types (ex. création confirmée + attribution). | ||
| 70 | * Multiplier les blocs si nécessaire pour refléter **plusieurs hypothèses ou étapes** dans la création du bien. | ||
| 71 | * Vérifier que chaque bloc est **cohérent et lisible indépendamment**, avec un type bien défini. | ||
| 72 | ))) | ||
| 73 | |||
| |
3.1 | 74 | >(% class="small" %)Exemple d'un bien avec création, exécution et commanditairele bien dispose de **trois types d’informations distinctes** liées à sa fabrication : |
| 75 | |||
| 76 | ((( | ||
| 77 | >((( | ||
| |
2.1 | 78 | * (% class="small" %)une **création** par un auteur inconnu, |
| 79 | * (% class="small" %)une **exécution** par une imprimerie identifiée, | ||
| 80 | * (% class="small" %)une **commande** passée par une compagnie maritime. | ||
| 81 | |||
| 82 | (% class="small" %)Pour structurer correctement ces données dans Flora, le **bloc Création-Exécution a été répété trois fois** : | ||
| 83 | chaque itération correspond à **un seul type** (Création, Exécution, Commanditaire), avec ses propres auteurs, fonctions, dates et lieux. | ||
| |
3.1 | 84 | ))) |
| |
2.1 | 85 | |
| 86 | [[Bloc de type création>>image:1753264102881-855.png||data-xwiki-image-style-alignment="center" data-xwiki-image-style-border="true"]] | ||
| 87 | |||
| 88 | |||
| 89 | [[Bloc de type exécution>>image:1753264130960-668.png||data-xwiki-image-style-alignment="center" data-xwiki-image-style-border="true"]] | ||
| 90 | |||
| 91 | |||
| 92 | [[Bloc de type commanditaire>>image:1753264165513-746.png||data-xwiki-image-style-alignment="center" data-xwiki-image-style-border="true"]] | ||
| 93 | |||
| |
3.1 | 94 | >(% class="small" %) En visualisation de la notice, les informations apparaissent **de manière claire et structurée**, sans mélange entre les statuts des différents acteurs. |
| |
2.1 | 95 | |
| 96 | |||
| 97 | [[Visualisation de la notice avec les trois types de bloc>>image:1753264230554-282.png||data-xwiki-image-style-alignment="center" data-xwiki-image-style-border="true"]] | ||
| 98 | ))) | ||
| 99 | ))) | ||
| 100 | )))|(% style="width:300px" %)((( | ||
| 101 | |||
| 102 | ))) | ||
| 103 | |||
| 104 |