Le fichier metadata.txt commençant dater un peu maintenant, ci-après quelques propositions d'évolutions à débattre.
name
name=Plume
Essentiellement esthétique, mais je trouve ça plus joli que PLUME, et peut-être plus adapté au fait que toutes les lettres ne sont pas des initiales ?
description
description=Saisie et consultation des métadonnées du patrimoine PostgreSQL
Le stockage est secondaire pour l'utilisateur et, foncièrement, ce n'est pas Plume qui s'en charge mais le serveur PostgreSQL du service... Autant mettre l'accent sur les deux principales fonctionnalités de Plume : la saisie et la consultation.
about
about=Plume, pour PLUgin MÉtadonnées, est un plugin de consultation
et saisie des métadonnées pour les tables et vues PostgreSQL.
Les métadonnées sont stockées au format RDF (JSON-LD) dans
les descriptifs PostgreSQL des objets. L'utilisateur y accède en
cliquant sur les couches dans l'explorateur ou dans le panneau
des couches. Plume prend en charge les tables, tables partionnées,
tables étrangères, vues et vues matérialisées.
Plume se base sur le profil GeoDCAT-AP 2.0 de DCAT v2, qui
constitue un socle de métadonnées communes et échangeables,
tout en permettant une large personnalisation des catégories de
métadonnées présentées à l'utilisateur lorsqu'il est couplé avec
l'extension PostgreSQL PlumePg.
C'est un copier-coller de ce que j'ai écrit dans le README.txt du Git.
D'ailleurs, est-ce qu'il faut vraiment retirer les accents ? Ça me perturbe pas mal pour un fichier supposé être encodé en UTF-8 et j'ai trouvé pas mal d'exemples d'extensions disponibles sur le dépôt officiel pour lesquelles il y a des caractères spéciaux dans about : des caractères slovènes - Vtičnik etc - pour le plugin AGIS, de l'espagnol avec des accents pour le plugin Andalusian Population... Même dans description, il y a parfois des accents, comme pour BD Topo Importer.
category
Tu avais mis Tools, mais est-ce que c'est (encore) un terme reconnu ? La documentation de la 3.16 ne liste que Raster, Vector, Database et Web. S'il fallait que Plume apparaisse dans un autre menu que Extension, alors Database serait sans doute le plus adapté, mais la laisser dans Extension avec les plugins Asgard me semble assez logique ? Dans ce cas, et même si ça revient au même en pratique, mieux vaut peut-être supprimer ce champ optionnel plutôt que de laisser un mot-clé (potentiellement) invalide ?
tags
tags=postgresql,metadata,geodcat-ap
À voir s'il faut s'y tenir mais, d'après la doc, les mots-clés sont supposés être en anglais.
repository
Est-ce que ça ne devrait pas plutôt être l'URL du Git ? J'ai l'impression que c'est ce que font tous les autres plugins.
Pas super de pointer vers l'intranet... Pour l'instant (tant que nous n'avons pas de doc utilisateur, notamment) le moins pire est peut-être encore de mettre l'URL du Git ?
Je ne sais jamais s'il faut mettre le nom de la personne et/ou de l'organisation dans ce champ, j'ai l'impression que les deux se font. En admettant qu'il y ait les noms des personnes, est-ce qu'il est possible de faire aussi apparaître le mien ?
Si on voulait avoir l'organisation, on pourrait imaginer quelque chose de ce genre, si ce n'est pas trop long :
author=Ministères français de la transition écologique, de la cohésion des territoires et de la mer - Didier Leclerc et Leslie Lemaire (SNUM).
changelog
Mon intention n'est pas de masquer tout le travail qui a été fait, mais je me dis que, pour les versions qui seront diffusées, il serait préférable de ne pas garder à cet endroit l'historique qui retrace toutes les étapes du développement. C'est trop d'informations inutiles pour les utilisateurs. Je pense qu'il vaut mieux présenter uniquement les versions auxquelles ils auront effectivement eu accès.
Deux questions, sinon :
est-ce que c'est normal d'avoir : et pas = après changelog ?
Le fichier
metadata.txt
commençant dater un peu maintenant, ci-après quelques propositions d'évolutions à débattre.name
Essentiellement esthétique, mais je trouve ça plus joli que
PLUME
, et peut-être plus adapté au fait que toutes les lettres ne sont pas des initiales ?description
Le stockage est secondaire pour l'utilisateur et, foncièrement, ce n'est pas Plume qui s'en charge mais le serveur PostgreSQL du service... Autant mettre l'accent sur les deux principales fonctionnalités de Plume : la saisie et la consultation.
about
C'est un copier-coller de ce que j'ai écrit dans le README.txt du Git.
D'ailleurs, est-ce qu'il faut vraiment retirer les accents ? Ça me perturbe pas mal pour un fichier supposé être encodé en UTF-8 et j'ai trouvé pas mal d'exemples d'extensions disponibles sur le dépôt officiel pour lesquelles il y a des caractères spéciaux dans
about
: des caractères slovènes - Vtičnik etc - pour le plugin AGIS, de l'espagnol avec des accents pour le plugin Andalusian Population... Même dansdescription
, il y a parfois des accents, comme pour BD Topo Importer.category
Tu avais mis
Tools
, mais est-ce que c'est (encore) un terme reconnu ? La documentation de la 3.16 ne liste queRaster
,Vector
,Database
etWeb
. S'il fallait que Plume apparaisse dans un autre menu queExtension
, alorsDatabase
serait sans doute le plus adapté, mais la laisser dansExtension
avec les plugins Asgard me semble assez logique ? Dans ce cas, et même si ça revient au même en pratique, mieux vaut peut-être supprimer ce champ optionnel plutôt que de laisser un mot-clé (potentiellement) invalide ?tags
À voir s'il faut s'y tenir mais, d'après la doc, les mots-clés sont supposés être en anglais.
repository
Est-ce que ça ne devrait pas plutôt être l'URL du Git ? J'ai l'impression que c'est ce que font tous les autres plugins.
Je me demande aussi si le mieux est de pointer sur la page d'accueil du dépôt (https://github.com/MTES-MCT/metadata-postgresql) ou sur le répertoire qui contient véritablement le plugin (https://github.com/MTES-MCT/metadata-postgresql/tree/main/plume).
homepage
Pas super de pointer vers l'intranet... Pour l'instant (tant que nous n'avons pas de doc utilisateur, notamment) le moins pire est peut-être encore de mettre l'URL du Git ?
Ou alors on ne met pas du tout cette information pour le moment. C'est une métadonnée optionnelle de toute façon.
tracker
Tant que nous ne serons pas en production, c'est sans doute le Git plutôt que SPS qui servira pour les tickets. Donc la page des issues du Git ?
author
Je ne sais jamais s'il faut mettre le nom de la personne et/ou de l'organisation dans ce champ, j'ai l'impression que les deux se font. En admettant qu'il y ait les noms des personnes, est-ce qu'il est possible de faire aussi apparaître le mien ?
Si on voulait avoir l'organisation, on pourrait imaginer quelque chose de ce genre, si ce n'est pas trop long :
changelog
Mon intention n'est pas de masquer tout le travail qui a été fait, mais je me dis que, pour les versions qui seront diffusées, il serait préférable de ne pas garder à cet endroit l'historique qui retrace toutes les étapes du développement. C'est trop d'informations inutiles pour les utilisateurs. Je pense qu'il vaut mieux présenter uniquement les versions auxquelles ils auront effectivement eu accès.
Deux questions, sinon :
:
et pas=
aprèschangelog
?