`owl:versionInfo` ou `dcat:version` ?

[alhyss]

DCAT v2 ne spécifiait pas de propriétés pour nommer et décrire la version d'un jeu de données. DCAT-AP avait donc ajouté les siennes, respectivement owl:versionInfo pour le nom et adms:versionNotes pour la note de version avec DCAT-AP 2.1.0.

GeoDCAT-AP étendait l'usage de owl:versionInfo à d'autres objets que dcat:Dataset, notamment les standards - dct:Standard.

DCAT v3 - qui est encore à l'état de "working draft" pour l'heure - prévoit d'utiliser adms:versionNotes pour les notes, avec une nouvelle propriété pour le nom : dcat:version. Ces propriétés sont utilisables pour tous les types de ressources définis par DCAT v3, ce qui n'inclut pas les objets dct:Standard.

Dans l'état actuel, Plume suit l'approche de GeoDCAT-AP et utilise owl:versionInfo pour les objets dcat:Dataset et dct:Standard, mais ce n'est vraisemblablement pas une solution pérenne. Abandonner owl:versionInfo est d'autant plus justifiable pour les jeux de données que cette propriété est supposée être utilisée comme annotation dans le contexte d'une ontologie, les jeux de données ne sont pas dans son domaine d'application. Un standard pourrait l'être.

Deux possibilités :

1. Remplacer dès à présent owl:versionInfo par dcat:version, au moins pour les jeux de données, en anticipant sur l'approbation et la mise en oeuvre de DCAT v3. À court terme, cette approche est plutôt défavorable du point de vue de l'interopérabilité avec les autres systèmes européens.
2. Prévoir dans Plume un système de remplacement de propriétés obsolètes qui ne s'applique pas seulement aux métadonnées importées, mais également aux fiches de métadonnées chargées depuis le serveur PostgreSQL. Il pourrait s'agir soit d'une mise à jour légère appliquée au chargement des fiches (qui serait enregistrée dans le descriptif PostgreSQL à la première modification de la fiche), soit d'une mise à jour massive via PlumePg pour ceux qui l'utilisent. Idéalement, ce mécanisme devrait tenir compte de la possibilité de cas plus complexes qu'une simple substitution de prédicat, où un ensemble de triplets devrait être remplacé par un nouvel ensemble.

[alhyss]

@WREATCHED @GilGuillouet Je serais preneuse de vos avis sur le sujet ci-dessus. Pour ma part, je pense la seconde solution préférable, bien qu'elle soit plus lourde en termes de développement. C'est exactement le cas que je voulais éviter quand je parlais de contrôler le modèle de métadonnées pour s'assurer qu'il soit stabilisé, tout en sachant que le problème finirait par survenir, car les standards évoluent.

La solution 1 serait triviale à implémenter si nous partons du principe qu'il n'y a pas à assurer de rétro-compatibilité. Il faut pour ça impérativement que ce soit fait pour la v1. (avec rétro-compabilité, ça reviendrait à mettre en place le dispositif de la solution 2 et y recourir immédiatement, ce qui ne présente aucun intérêt)

Pour la solution 2, il n'y aurait pas d'urgence. Il faut seulement que ce soit fait d'ici septembre.

Choisir la solution 1 pourrait autoriser à ne pas développer le mécanisme de la solution 2 immédiatement, mais ça ne fait que repousser l'échéance.

[WREATCHED]

Il est évident pour moi que seule la solution 2 répond à une solution pérenne. Je m'interroge sur comment techniquement mettre une solution en place pour les changements des standards.

• Comment détecter ou être informé de ces standards ?
• Les solutions techniques pourront telles imaginer les futurs changements ? là je suis un peu dubitatif.

[alhyss]

• Comment détecter ou être informé de ces standards ?

Par de la veille, je ne vois pas d'autre solution. Il faudra notamment se tenir au courant :

• De l'avancée des travaux du W3C sur DCAT v3. Réf : https://www.w3.org/TR/vocab-dcat-3/.
• Des productions du groupe de travail de l'OGC qui va standardiser une déclinaison de DCAT adaptée aux données géographiques, GeoDCAT. Réf : https://www.ogc.org/requests/public-comment-requested-geodcat-standards-working-group-charter/. Ça démarre tout juste, ils n'ont encore rien produit.
• Des évolutions des profils applicatifs de la commission européenne, DCAT-AP et sa déclinaison géographique GeoDCAT-AP. Réf : https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic/solution/dcat-application-profile-data-portals-europe (DCAT-AP) et https://semiceu.github.io/GeoDCAT-AP/releases/ (GeoDCAT-AP).

S'il y a des évolutions des standards ISO 19139/19115 ou d'INSPIRE, cela pourra aussi supposer des ajustements dans le mapping ISO/DCAT mis en œuvre par Plume. Surtout, le groupe de travail de l'OGC sur GeoDCAT produira certainement des recommandations en la matière, qu'il serait souhaitable de suivre, et il est prévu que le groupe de travail Métadonnées du CNIG publie également les siennes.

• Les solutions techniques pourront telles imaginer les futurs changements ? là je suis un peu dubitatif.

On ne peut pas prévoir ce qui va changer, mais je vais mettre en place un système de mapping généraliste. Pour gérer un nouveau changement, il faudra déclarer :

• le ou les chemins des catégories de métadonnées obsolètes ;
• soit le nouveau chemin, quand c'est un cas simple comme celui évoqué ici ;
• soit une fonction qui crée les nouveaux triplets à partir des anciens, pour les cas plus complexes.

Ceci ne vaut évidemment que lorsque le changement est purement technique, avec la possibilité d'automatiser le changement de représentation.

S'il n'y a ni nouveau chemin ni fonction, ça voudra dire que la catégorie n'est plus une catégorie commune. À voir si je crée un statut de catégorie commune obsolète ou si la catégorie est alors gérée comme catégorie locale... Dans les deux cas, il s'agira de faire en sorte de ne pas perdre l'information, ce sera à l'administrateur de décider ce qu'il fait.

[WREATCHED]

OK

[alhyss]

NB. Pour le mapping à minima qui est fait aujourd'hui, uniquement pour les imports depuis des sources externes.

Mapping de prédicats : https://github.com/MTES-MCT/metadata-postgresql/blob/ed78d1b87c4a2c77479b7946ee738bf455bb5b6d/plume/rdf/namespaces.py#L57

Mapping de classes : https://github.com/MTES-MCT/metadata-postgresql/blob/ed78d1b87c4a2c77479b7946ee738bf455bb5b6d/plume/rdf/namespaces.py#L73

[alhyss]

J'ai implémenté un mécanisme très simple, qui suppose qu'à chaque évolution du schéma des métadonnées communes soit ajoutée une fonction de "translitération" portant le décorateur plume.rdf.transliterations.transliteration et capable d'ajuster un graphe de métadonnées selon le nouveau schéma. Toutes les fonctions sont appliquées systématiquement à toutes les fiches de métadonnées issues du serveur PostgreSQL ou d'une source externe, ce qui pourrait poser des problèmes de performance s'il y en avait beaucoup ou si elles étaient mal optimisées. Leur nombre devrait rester limité cependant.

Cf. Documentation de référence et Aide-mémoire.

Pour l'heure, aucune translitération n'est active. Celle pour owl:versionInfo est écrite (translit_owl_version_info), mais il faudra que le décorateur ne soit plus en commentaire pour qu'elle soit prise en compte.

Je n'ai pas touché aux mappings avec PREDICATE_MAP et CLASS_MAP, parce qu'ils ne sont pertinents que pour les métadonnées issues de sources externes (pas la peine de les appliquer à des fiches déjà propres) et sont bien optimisés du point de vue du temps de calcul. Le nouveau système vient en complément pour les modifications qui doivent aussi être appliquées aux métadonnées provenant du serveur et/ou qui sont plus complexes qu'une substitution de propriété ou de classe.