Test SEMICeu XSL dev branch

[streino]

On a discuté avec data.gouv de passer le moissonneur csw-iso-19139 sur la branche de dev de SEMICeu pour bénéficier des correctifs récents.

=> Test de la branche dev + diff de résultats avec la branche main ?

[streino]

La branche dev est passé en XSLT 2.0 et par conséquent n'est plus compatible avec la lib python lxml utilisée par data.gouv SEMICeu/iso-19139-to-dcat-ap#49. Fonctionne (testé) avec la lib saxonche après correction de SEMICeu/iso-19139-to-dcat-ap#47.

Donc en fonction de SEMICeu/iso-19139-to-dcat-ap#49 (en consultation jusqu'à fin septembre), soit :

• La branche dev revert en XSLT 1.0 => on peut directement basculer sur la branche dev sans rien changer.
• La branche dev maintient la montée de version à XSLT 2.0 => data.gouv devra remplacer lxml par saxonche avant qu'on puisse basculer.

[streino]

Au niveau du diff entre les branches dev et master, je vois deux changements à creuser éventuellement :

1. Avoid failure when multiple resource identifier are set SEMICeu/iso-19139-to-dcat-ap#42

   Resource URI can be an http or https URI based on:

   • codeSpace + code value
   • code value
     The first URI found is used.

   Diff dev..master.
   Affecte "Présenter des identifiants de jeux de données exploitables".

2. Revise usage of Licenses and Rights SEMICeu/GeoDCAT-AP#113

   • dct:license -> dct:rights
   • dct:accessRights -> dct:rights

   Diff dev..master.
   Affecte "Séparer la licence des conditions d'accès". A priori pas de changement majeur, juste les balises à mettre à jour dans les préconisations ?

@alhyss ?

[alhyss]

Le premier changement paraît bienvenu. Avant, pour les identifiants représentés avec gmd:RS_Identifier le XSLT concaténait le code et l'espace de nommage pour générer dct:identifier, mais il ne le faisait pas pour l'URI du dataset. On se retrouvait avec un nœud anonyme.

Dans ces conditions, il n'y a plus lieu de privilégier gmd:MD_Identifier dans les préconisations, et Géo-IDE pourrait revenir sur gmd:RS_Identifier s'ils le souhaitent.

Un autre apport est la prise en charge des identifiants matérialisés par un élément gmx:Anchor - du moins pour l'URI du dataset, car je ne vois pas l'équivalent pour le calcul de dct:identifier.

J'ai l'impression que le deuxième point a des conséquences très importantes.

Sur le fond, je suis plutôt d'accord avec le fait d'utiliser dct:rights pour une condition d'usage qui n'a pas été spécifiée sous forme d'URI avec un élément gmx:Anchor. Le problème, c'est que, en pratique, tant que nos catalogues n'auront pas appliqué la préconisation Faciliter la reconnaissance des licences, toutes nos licences vont passer sur dct:rights. Il faudra au moins s'assurer que pour sa propre moulinette de reconnaissance des licences data.gouv.fr prenne non seulement en compte dct:license, mais aussi dct:rights.

Le fait d'appliquer le même raisonnement à dct:accessRights me paraît plus discutable, mais admettons. Quoi qu'il en soit nous aurons le même problème que pour les licences : comme en pratique aucun de nos catalogues n'utilise d'élément gmx:Anchor pour spécifier les restrictions INSPIRE, même ces dernières vont être mappées sur dct:rights. Si on veut y remédier, il va falloir ajouter une préconisation Faciliter la reconnaissance des restrictions d'accès INSPIRE et faire en sorte qu'elle soit appliquée...

Le bon côté, c'est que ça rend la question de la séparation conditions d'usage et conditions d'accès moins prégnante à court terme, vu que pour l'heure tout finit de toute façon sur dct:rights.

Ce changement-là mérite vraiment d'être creusé.