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).
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, colonnedescription) - 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'
}
}"