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 :

Propriété Type Description
label string Obligatoire. Intitulé affiché à l'utilisateur pour le choix d'un schéma
type string Obligatoire. Type de schéma, pour l'instant soit php, soit json
uri string Obligatoire. Uri ou chemin d'accès au schéma. Pour le type php, il s'agit d'un nom de classe de modèle au format bundle/class, pour le json d'un chemin vers le fichier au format JSONSchema
controller string Classe de contrôleur qui sera utilisée par le système pour les opérations (création, modification, lecture, suppression, recherche). La classe de contrôleur doit implémenter l'interface bundle\recordsManagement\Controller\descriptionInterface. Si ignoré, le système utilisera le moteur par défaut gérant le stockage en base de données dans une colonne de type json du registre des archives.
presenter string Classe de présentation qui sera utilisée par le système pour la présentation des métadonnées descriptives. Si ignoré, le système utilisera le moteur par défaut gérant la présentation dynamique basée sur le modèle.
extension object Définition d'un sou-modèle d'extension comportant uniquement les propriétés type et uri. Cette mécanique de surcouche permet d'ajouter de nouveaux champs ou de remplacer des champs existant dans le modèle de base.

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'
  }
}"

results matching ""

    No results matching ""