Version majeure 1.0.0#

Date de publication : 19 juin 2023.

Sur GitHub : MTES-MCT/metadata-postgresql.

Plume v1.0.0 est la première version de Plume officiellement considérée comme stable.

Une nouvelle version de l’extension PostgreSQL PlumePg, la v0.3.0, est diffusée en parallèle.

Avertissement : Tous les utilisateurs de l’extension PostgreSQL PlumePg doivent impérativement mettre à jour cette dernière en version 0.3.0 pour qu’elle reste reconnue par Plume.

Import de métadonnées INSPIRE / ISO 19139#

Plume v1.0.0 enrichit et consolide la fonctionnalité d’import de fiches de métadonnées ISO 19139, tant sous forme de fichier que via un service CSW.

Si tant est qu’elles soient représentées dans les formes prévues par le Guide de saisie du CNIG, Plume prend désormais en charge toutes les métadonnées obligatoires INSPIRE à l’exception des informations suivantes :

Type de la ressource.

Plume assimile toujours les tables et les vues à des jeux de données. Le type de la ressource dont on récupère les métadonnées est ignoré.
Identificateur de ressource unique.

Plume attribue un identifiant pérenne de jeu de données à chaque table ou vue qui fait l’objet d’une fiche de métadonnées. Cet identifiant est préservé lors de la récupération de métadonnées externes, considérant que la table ou vue PostgreSQL est un jeu de données différent de celui qui était décrit par la fiche ISO. L’identifiant de ce dernier n’est pas conservé pour l’heure.
Encodage des caractères.
Système de référence par identifiant géographique.
Système de référence temporel.
Cohérence topologique.
Conformité (prise en charge partielle).

Plume ne contrôle pas le champ (scope) de la conformité. L’information est toujours présumée valable pour la table/vue dont les métadonnées sont en cours d’édition.

De plus, dans la mesure où peu de jeux de données catalogués ont un résultat de conformité explicite, Plume considère que la mention d’un standard signifie en elle-même que les données respectent ce dernier, sauf si un résultat de test négatif est fourni.

Les informations libres sur la conformité ne sont pas retranscrites.
Métadonnées concernant les métadonnées.

Ces informations ne sont pas récupérées pour l’heure, car Plume ne propose aujourd’hui aucune métadonnée sur les métadonnées à l’exception de la date de dernière mise à jour de la fiche (qui est mise à jour automatiquement à chaque enregistrement). Cf. issue #9 pour les discussions en cours sur ce sujet.

Lorsque les recommandations du CNIG ne sont pas respectées par le catalogue, il est possible que les informations soient perdues ou mal identifiées. Par exemple, une licence dont l’URI n’a pas été spécifié par l’attribut xlink:href d’un élément gmx:Anchor sera vraisemblablement renseignée sur la priorité générique dct:rights (Contraintes légales) de la distribution et non sur dct:license (Licence).

Référence : issue #27.

Catégories de métadonnées communes#

Plume v1.0.0 consolide le schéma des métadonnées communes avec l’ajout de sources de vocabulaire contrôlé et quelques changements - principalement des ajouts - sur les catégories disponibles :

Ajout de la catégorie dqv:hasQualityMeasurement, prévue par GeoDCAT-AP v2 pour la représentation de la précision des données sous des formes plus variées que dcat:spatialResolutionInMeters. Elle autorise notamment la saisie des échelles équivalentes, qui sont très utilisées dans les métadonnées INSPIRE des données vectorielles. Référence : issue #137.
Suppression de la catégorie dct:distribution / cnt:characterEncoding (encodage de la distribution). Elle présente un intérêt limité dans le contexte de PostgreSQL, où l’encodage est défini à l’échelle de la base, et pose par ailleurs des problèmes de gestion, car il s’agit d’un vocabulaire constitué de valeurs littérales et non d’URI, ce qui n’est pas habituel en RDF et nécessiterait de mettre en place un système spécifique pour cette seule catégorie.
La catégorie dcat:distribution / dcat:accessURL n’est plus marquée comme obligatoire, considérant que Plume a vocation à documenter un patrimoine local, dont les jeux de données ne sont pas nécessairement publiés et peuvent donc légitimement ne pas avoir d’URL d’accès. Même dans ce cas, il peut être pertinent de définir une distribution du jeu de données pour spécifier par exemple les conditions d’usage des données.
Nouvelles sources de vocabulaires contrôlés pour les thèmes (dcat:theme) : Thème (Ecosphères), Champ géographique (INSPIRE), Jeu de données prioritaire (INSPIRE). La description de la catégorie a également été amendée.
La couverture géographique (dct:spatial) admet désormais des valeurs issues de vocabulaires contrôlées, avec prise en charge des vocabulaires suivants : Unité territoriale administrative française (UE), Département français (INSEE), Région française (INSEE), Territoire singulier (INSEE), Unité territoriale administrative (UE), Commune française (INSEE).
Nouvelles sources de vocabulaires contrôlés pour les catégories relatives à la conformité (dct:conformsTo, dcat:distribution / dct:conformsTo et dcat:distribution / dcat:accessService / dct:conformsTo) : Système de référence de coordonnées EPSG utilisé sur le territoire français (OGC), Système de référence de coordonnées (IGN).
Le schéma des métadonnées communes indique désormais que la fonctionnalité de calcul est activable manuellement pour la catégorie dct:conformsTo. Il reste possible d’inhiber cette possibilité avec des modèles personnalisés.
Nouvelle source de vocabulaire contrôlé pour les formats (dcat:distribution / dct:format, dcat:distribution / dcat:compressFormat et dcat:distribution / dcat:packageFormat) : Type de média (IANA).
Nouvelles sources de vocabulaires contrôlés pour les conditions d’accès (dct:accessRights, dcat:distribution / dct:accessRights et dcat:distribution / dcat:accessService / dct:accessRights) : Restriction de sécurité sur les données (ISO 19115/19139), Limitation d’accès ou d’usage des données (ISO 19115/19139).
Nouvelle source de vocabulaire contrôlé pour les licences (dcat:distribution / dct:license) : Licence (SPDX).
Modification du libellé et de la description de la catégorie dcat:distribution / dct:rights, qui admet désormais une source de vocabulaire contrôlé : Limitation d’accès ou d’usage des données (ISO 19115/19139). Il est désormais plus clairement établi que cette catégorie Contraintes légales peut être utilisée pour toute contrainte d’ordre juridique qui n’aurait pas pu être exprimée avec dcat:distribution / dct:accessRights et dcat:distribution / dct:license.
Modification du libellé et de la description pour la catégorie dcat:distribution / adms:status (Statut).
Nouvelle source de vocabulaire contrôlé pour les catégories relatives à des index géographiques (dct:spatial / skos:inScheme et dcat:distribution / dcat:accessService / dct:spatial / skos:inScheme) : Série de codes géographiques (ISO 3166).
Les catégories permettant de spécifier la précision sous la forme d’une distance en mètres admettent désormais plusieurs valeurs, considérant notamment qu’une même table ou vue peut avoir plusieurs champs de précisions différentes (dcat:spatialResolutionInMeters, dcat:distribution / dcat:spatialResolutionInMeters et dcat:distribution / dcat:accessService / dcat:spatialResolutionInMeters).
Nouvelle source de vocabulaire contrôlé pour les types de services (dcat:distribution / dcat:accessService / dct:type) : Type de service de données géographiques (INSPIRE).

Certaines des nouvelles sources de vocabulaires contrôlés correspondent à des extraits d’autres sources, regroupant les valeurs jugées les plus utiles. Ce système vise principalement à réduire les temps de calcul en chargeant des vocabulaires de plus petite taille. Pour cette raison, il est généralement souhaitable de n’inclure dans les modèles que les vocabulaires réduits s’il est certain qu’ils seront suffisants. Lorsqu’un même terme est présent dans deux vocabulaires, il sera toujours reconnu dès lors que l’un des deux au moins est actif, quel que soit le vocabulaire dans lequel il avait été trouvé au moment de la saisie.

Exclusion de sources de vocabulaires contrôlés#

En raison de leur volume (jusqu’à 5.2Mo pour la liste des communes), certains vocabulaires contrôlés imposent un temps de chargement conséquent lors de la première ouverture d’une fiche de métadonnées en édition. Lorsqu’ils ne sont en pratique pas utilisés pour la documentation du patrimoine de données, cela dégrade inutilement l’expérience utilisateur. La version 1.0.0 apporte une première réponse à cette question en excluant certains vocabulaires des modèles pré-configurés et en l’absence de modèle. L’administrateur devra par conséquent créer des modèles personnalisés s’il souhaite se servir de ces vocabulaires.

À noter que certains de ces vocabulaires sont quoi qu’il arrive mobilisés lors de l’import de fiches de métadonnées INSPIRE, ce qui explique un temps de chargement prolongé, notamment lors du premier import réalisé après l’ouverture de Plume.

Référence : issue #136.

Modèles pré-configurés#

PlumePg v0.3.0 apporte les modifications suivantes aux modèles pré-configurés, également appliquées par Plume v1.0.0 à ses copies locales des modèles :

ajout d’un modèle INSPIRE constitué de toutes les métadonnées utilisées lors de l’import depuis des fiches de métadonnées INSPIRE/ISO 19139 ;
application automatique du modèle Basique au lieu de Classique aux tables des schémas préfixés de 'c_' ;
ajout des conditions d’accès au modèle Basique (dct:accessRights) ;
ajout des contraintes légales au modèle Classique (dcat:distribution / dct:rights) ;
ajout de l’état du jeu de données (adms:status) à tous les modèles pré-configurés.

Référence : issue #16.

Les utilisateurs ont désormais accès aux modèles pré-configurés (chargés à partir des copies locales) lorsque PlumePg est activé sur la base cible mais ne définit aucun modèle. Référence : issue #131.

RDFLib#

Plume v1.0.0 intègre la version 6.3.2 de RDFLib et met notamment à profit les fonctionnalités de contrôle des types de valeur qui avait été introduites par la version 6.2.0. Références : issue #120.

Cette évolution a nécessité la correction d’une anomalie de RDFLib qui affectait les comparaisons de chemins d’URI. Références : issue Plume #119, issue RDFLib #2281.

Suivi des modifications des tables#

PlumePg v0.3.0 met a disposition une fonction, z_plume.stamp_create_triggers, qui permet d’activer massivement l’enregistrement des dates de modification des tables d’un ou plusieurs schémas. Elle pourra notamment être mise à profit pour gérer les tables qui existaient déjà lorsque le suivi est activé.

Cf. documentation technique pour plus de détails.

Références : issue #114.

Corrections d’anomalies et divers#

Suppression des avertissements « Si vous poursuivez, les modifications non enregistrées seront perdues. » lorsque l’utilisateur change de langue ou de modèle en mode lecture. De tels avertissements pouvaient notamment apparaître lorsque le modèle inclut du calcul automatique. La fiche de métadonnée peut alors effectivement avoir été modifiée, pour autant il ne paraît pas nécessaire de le signaler considérant que l’utilisateur n’a pas la possibilité d’enregistrer les changements. Référence : issue #117.

Consolidation de la gestion de ces mêmes avertissements après l’import de métadonnées depuis une source externe. Référence : issue #105.

Les liens inclus dans les fiches de métadonnées sont de nouveau activables avec un simple clic gauche. Référence : issue #128.

La bibliothèque importlib-metadata utilisée pour les versions de QGIS distribuées avec Python 3.7 est désormais intégrée en version 4.13.0, dernière version compatible avec Python 3.7, et non plus dans sa version la plus récente. Ce changement rétablit la possibilité d’installer Plume avec les versions les plus anciennes de QGIS. Référence : issue #145.

Suppression d’une syntaxe introduite par Python 3.8 qui faisait échouer le chargement de Plume sous les versions de QGIS distribuées avec Python 3.7. Référence : issue #143.

Amélioration de la fonctionnalité qui transforme les infobulles affichées au survol des couches dans l’explorateur, afin qu’elle réagisse correctement pour les tables et vues avec un champ de géométrie dont le référentiel de coordonnées n’est pas défini. Référence : issue #139.

Correction d’une anomalie qui empêchait l’activation de Plume lorsque PlumePg n’était pas installée. Référence : issue #138.

Amélioration de la gestion du chemin de l’utilitaire pip, qui permet l’installation des bibliothèques Python intégrées à Plume. Au lieu d’être présumé accessible, ce qui n’est pas toujours le cas en pratique, il est désormais déterminé grâce à la variable d’environnement PYTHONHOME. Référence : issue #130.

Consolidation de la gestion des bibliothèques intégrées pour prendre en compte le cas d’une nouvelle installation de Plume avec un fichier de configuration QGIS3.ini copié depuis un environnement dans lequel, pour la même version de QGIS, Plume était installé. Plume vérifie désormais la présence de la principale bibliothèque, RDFLib, avant même d’aller lire dans le fichier de configuration le paramètre qui indique si les bibliothèques sont présentes et à jour. En l’absence de RDFLib, le processus de mise à jour sera lancé quoi qu’il arrive. Référence : issue #125.

Correction d’une anomalie qui provoquait une erreur non gérée lors de l’import d’une fiche de métadonnées via un service CSW avec un modèle incluant du calcul automatique sur au moins un champ. Référence : issue #122.

Amélioration de la syntaxe des commandes d’import. Référence : issue #126.

Suppression des composants visibles de Plume dans les menus et barres d’outils de QGIS lors du déchargement du plugin. Référence : issue #123.

Le champ unilang des tables z_plume.meta_categorie et z_plume.meta_template_categories de PlumePg est désormais de type booléen (et non texte), comme il aurait toujours dû l’être. Référence : issue #110.