Schémas de métadonnées descriptives

Maarch RM permet de déclarer des jeux de métadonnées utilisables pour définir la structure des métadonnées descriptives des unités d'archives, principalement dans les profils d'archives.

Chaque schéma de description implique un ensemble de comportements de l'application pour les opérations d'enregistrement et de gestion des métadonnées :

• écriture : inscription au registre, modification et contrôle de cohérence,
• lecture : recherche, ressortie et affichage,
• suppression.

Il existe 3 moyens de déclarer ces modèles :

• via l'administration avec un dictionnaire de données interne
• par l'ajout de classes de description implémentées (php)
• par le déploiement de schémas externes dans des technologies tierces (JSON, XSD)

Ces trois méthodes peuvent être combinées afin de répondre à l'ensemble des besoins du métier.

Origine des schémas

Dictionnaire interne

Cette méthode permet à l'administrateur fonctionnel de déclarer, via l'interface d'administration, une liste de champs de description.

Elle est adaptée aux besoins simples car limitée à des types de données scalaires : chaînes de caractères, dates, nombres et indicateurs (booléens).

Cf Données descriptives

Les profils d'archive et unités d'archive s'appuyant sur ce dictionnaire interne voient toujours les métadonnées gérées par le système de gestion de base :

• stockage en base de données comme un objet agrégé à l'entrée de registre de l'archive (table recordsManagement.archive, colonne description)
• moteur de recherche de base sur mot-clés et plein-texte sur métadonnées
• moteur de présentation dynamique

Cette méthode, utilisée par défaut, ne nécessite aucune configuration particulière.

Classes de description intégrées

Cette méthode nécessite l'implémentation de classes de description, sous la forme de fichiers source en langage PHP placés dnas le répertoire "Model" de l'un des bundles activés pour l'application.

Une classe comporte un jeu de propriétés qui décrivent les champs d'un dictionnaire de données adapté par exemple à un domaine métier.

Cette méthode requiert que du code logiciel soit produit, elle est donc plutôt mise en oeuvre au cours de projets d'intégration, pour des applications qui nécessitent l'utilisation de plusieurs schémas de description ayant des spécificités métier ou techniques.

Une implémentation du schéma SEDA dans sa version 1 et sa version 2.1 sont intégrées à l'extension Archives Publiques.

Schémas externes

Cette méthode permet de déclarer via la configuration des schémas de métadonneés disponibles dans l'un des formats acceptés.

Dans cette première version du système, seul le JSONSchema est implémenté, cf le site officiel du projet.

Configuration

La section [recordsManagement] comporte la directive complexe descriptionScheme qui déclare les schémas disponibles.

Il s'agit d'un tableau associatif qui fait correspondre un identifiant de schéma et une confiuration de schéma répondant aux spécification suivantes :

Exemple de déclaration du modèle SEDA 2 avec une extension de champs complémentaires dans un schéma JSON externe

descriptionSchemes = "{
    'seda2' : {
       'label' : 'SEDA 2',
       'type' : 'php',
       'uri' : 'seda2/Content',
       'controller' : '',
       'presenter' : '',
       'extension' : {
            'type' : 'json',
            'uri' : '%laabsDirectory%/data/maarchRM/customFieldsSeda.json'
       }
   }
}"

Extension au dictionnaire interne

La valeur spéciale extension pour l'identifiant de schéma permet d'étendre le dictionnaire de données interne du logiciel, au lieu d'ajouter un schéma complémentaire.

Les définitions ainsi intégrées viendront compléter ou modifier les champs décrits dans le dictionnaire de données interne accessibles dans l'écran de gestion des données descriptives.

descriptionSchemes = "{
  'extension' : {
    'label' : 'non utilisé',
    'type' : 'php',
    'uri' : 'contact/contact'
  }
}"

Recherche floue

Par défaut, l'application fournit un moteur de recherche simple avec 3 critères :

• le texte des métadonnées et éventuellement du contenu d'information (voir indexation fulltext)
• l'identifiant métier de l'archive
• la date de production

Le premier critère réalise une recherche approchante sur l'ensemble du texte collecté par l'application soit dans les métadonnées, soit dans le texte extrait des documents numériques. Le second critère utilise une égalité stricte entre la valeur recherchée et la métadonnée "Identifiant d'archive" (originatorArchiveId). Le troisième utilise une plage de date comparée à la métadonnées "Date de production" (originatingDate).

Le paramètre fuzzyIdSearchFields permet de modifier le comportement de l'application pour le second critère, en fournissant une liste de champs de description dans lesquels le moteur de recherche standard doit rechercher l'identifiant fournie comme critère, en plus du champ de base.

Par exemple pour les archives publiques utilisant un dictionaire SEDA 2, les identifiants des descriptions peuvent être ajoutés comme suit :

fuzzyIdSearchFields = "[
    'archiverArchiveId',
    'description.originatingSystemId',
    'description.archivalAgencyArchiveUnitId'
]"

Avec cette configuration, le moteur de recherche utilisera aussi la cote fournie par le service d'archives ainsi que l'identifiant du système d'origine présent potentiellement dans la description des archives.

Le paramètre fuzzyDateSearchFields permet de modifier le comportement de l'application pour ce troisième critère, en fournissant une liste de champs de description dans lesquels le moteur de recherche standard doit rechercher la date fournie comme critère, en plus du champ de base.

Par exemple pour les archives publiques utilisant un dictionaire SEDA 2, les dates des descriptions peuvent être ajoutées comme suit :

fuzzyDateSearchFields = "[
    'depositDate',
    'description.startDate',
    'description.endDate',
    'description.createdDate',
    'description.sentDate',
    'description.receivedDate',
    'description.acquiredDate',
    'description.transactedDate',
    'description.registeredDate'
]"

Avec cette configuration, le moteur de recherche utilisera aussi la date de dépôt ainsi que les 8 dates présente potentiellement dans la description des archives.

Attention ces mécanismes ajoutent autant de critères de recherche à la requête transmise par l'application à la base de données que d'entrées dans la liste et peut avoir un impact important sur les performances de recherche.