Support consommation DCAT depuis un appel CSW de Geonetwork #913
Comments
ThomasG77
changed the title
ThomasG77
changed the title
ThomasG77
changed the title
#111) * Update content and style to manage warning box See also etalab/template-jekyll#18 * Update articles/_moissonnage/dcat.md Co-authored-by: Alexandre Bulté <[email protected]> * Update articles/_moissonnage/dcat.md Co-authored-by: Alexandre Bulté <[email protected]> * Update articles/_moissonnage/dcat.md Co-authored-by: Alexandre Bulté <[email protected]> * Update articles/_moissonnage/intro.md Co-authored-by: Alexandre Bulté <[email protected]> * Update articles/_moissonnage/intro.md Co-authored-by: Alexandre Bulté <[email protected]> * Remove line due to remove outdated sentence * Update articles/_moissonnage/dcat.md Co-authored-by: maudetes <[email protected]> Co-authored-by: Alexandre Bulté <[email protected]> Co-authored-by: maudetes <[email protected]>
|
Je plussoie le besoin ici :-) |
|
Bonjour, J'ai un client (https://data.naturefrance.fr/geonetwork) qui souhaite résoudre la question d'ici la fin de l'année. Est-ce que cela ne vaudrait pas la peine de prévoir un point sur la question, tous ensemble, afin d'éviter le risque de développements redondants/inadaptés ? |
|
Bonjour à tous ! |
|
Bonjour ! Au vu des résultats du framadate, on pourrait avoir un créneau rapidement, le mardi 25 octobre à 10h. Je propose le lien suivant pour la visio : https://webinaire.numerique.gouv.fr//meeting/signin/8636/creator/4868/hash/b6a2db989ee04e2b2fd3aa812f2f4ea339588585 |
|
Suite à notre réunion quelques exemples côté GeoNetwork pour les tests:
Remarques:
|
|
Oh, mince, désolé d'avoir raté la réunion, mon agenda me fait des blagues en ce moment |
|
Compte rendu sur le point de synchro d'hier. N'hésitez pas à commenter si il manque des infos ou comporte des erreurs : Compte rendu du point de synchronisationParticipantsFrançois Prunayre, Grégory Delobelle, Benoist Fontaîne, Benoît Lardeau, Florent Gravin, François Prunayre, Olivier Guyot, Julien Daranlot, Thomas Gratier, Estelle Maudet HistoriqueL'endpoint dédié DCAT (/rdf/search) avait été développé il y a une dizaine d'année et se basait sur une API interne qui utilisait Lucène. A ce jour, trois options nous semblent possibles pour assurer une consommation de GeoNetwork v4 par data.gouv.fr, via différentes expositions de flux DCAT. Options de consommation DCATOGC API RecordIl y a des travaux en cours pour l'ajout d’OGC API Record pour fournir un service de recherche au-dessus du catalogue, qui permet de fournir des sorties json, html, et éventuellement DCAT rdf-xml, etc. CSW endpointLe endpoint CSW de GeoNetwork permet de retourner des résulats au format DCAT (voir la description de ce ticket). endpoint DCAT dédié dans GeoNetwork-coreLa dernière solution évoquée serait de migrer l'endpoint DCAT dédié ( Autres considérations
Next steps
|
|
Pour être plus clair pour le cas du tag <dcat:distribution rdf:resource="https://apps.titellus.net/geonetwork/srv/api/records/da165110-88fd-11da-a88f-000d939bc5d8/attachments/basins.zip"/>alors que sur nos tests côté OREME, sur l'ancien endpoint, celui-ci est de la forme <dcat:Distribution xmlns:dcat="http://www.w3.org/ns/dcat#"
rdf:about="https://sig.oreme.org/geonetwork/records/19e9f6cc-1af6-41ca-9947-1d2744b90a7c#WWW%3ALINK-1.0-http--link-See%20Noccaea%20caerulescens%20information%20on%20OSU%20OREME%20website">
<dcat:accessURL>https://oreme.org/observation/pollumine/noccaea-caerulescens</dcat:accessURL>
<dct:title xmlns:dct="http://purl.org/dc/terms/">See Noccaea caerulescens information on OSU OREME website</dct:title>
<dct:format xmlns:dct="http://purl.org/dc/terms/">WWW:LINK-1.0-http--link</dct:format>
</dcat:Distribution>Il faut aussi noter que la casse diffère: |
|
Bonjour à tous !
Exemple: J'ai rajouté ces points manquants dans un gist pour tester le moissonnage: https://gist.github.com/maudetes/41606ce9fc2d974a343449bf96c14d65. Vous pouvez consulter le résultat du moissonnage de ce gist par datagouv sur cette orga de test : https://demo.data.gouv.fr/fr/organizations/test-geonetwork-v4/ @fxprunayre, est-ce que les champs manquants pourraient être rajoutés au mapping de manière assez simple côté GeoNetwork ? |
Ajouté (cf. geonetwork/geonetwork-microservices#59)
Par exemple : <dcat:CatalogRecord rdf:about="https://sextant.ifremer.fr/geonetwork/srv/metadata/88a2a7a6-8b2d-49b8-9a17-914aea7ed278">
<dct:identifier>88a2a7a6-8b2d-49b8-9a17-914aea7ed278</dct:identifier>
....
<foaf:primaryTopic>
<dcat:Dataset rdf:about="https://sextant.ifremer.fr/geonetwork/srv/metadata/88a2a7a6-8b2d-49b8-9a17-914aea7ed278#resource">
<dct:title>Variance de krigeage annuelle de la densité de l'espèce Mullus barbatus au stade adulte dans le Golfe du Lion (MEDITS, 1994-2019)</dct:title>
<dct:identifier>DOI:10.12770/88a2a7a6-8b2d-49b8-9a17-914aea7ed278</dct:identifier>
Est-ce que vous connaissez des outils pour valider les sorties DCAT ? et quelle "classe de conformité" choisir ? |
Avoir un Nous n'avons pas connaissance d'autres outils que ceux cités ci-dessus pour valider des sorties DCAT. |
|
Bonjour à tous ! Je pense qu'un point de synchronisation sur les solutions proposées pourrait être pas mal ensuite, à voir si on fait un point en petit comité datagouv x GeoNetwork dans un premier temps ou ouvert plus largement selon le besoin. |
|
Suite à la sortie de la version 4.2.2 de GeoNetwork https://apps.titellus.net/geonetwork et https://apps.titellus.net/geonetwork/api sont à jour. |
|
Bonjour, Merci @fxprunayre pour les évolutions dans
Ya t-il une option meilleure que l'autre entre Merci pour vos inputs. |
|
Bonjour, Merci @fxprunayre pour les évolutions et la mise à jour de app.titellus.net ! Consommation CSWMalheureusement, je ne peux pas faire de requête GetRecords sur apps.titellus.net. Je me prends en effet une erreur Consommation API OGC RecordsL'identifiant du nœud semble bien fonctionner. Il faut que l'on discute la solution à privilégier entre ces deux alternatives, mais cela n'était pas encore tranché à ce stade. |
|
Concernant l'appel CSW sur apps.titellus.net, ce n'est pas vraiment que "ca ne marche pas", le rapport indique echo '<?xml version="1.0" encoding="UTF-8"?><csw:GetRecords xmlns:csw="http://www.opengis.net/cat/csw/2.0.2" xmlns:gmd="http://www.isotc211.org/2005/gmd" service="CSW" version="2.0.2" resultType="results" outputSchema="http://www.w3.org/ns/dcat#"><csw:Query typeNames="gmd:MD_Metadata"><csw:ElementSetName>full</csw:ElementSetName><csw:Constraint version="1.1.0"><Filter xmlns="http://www.opengis.net/ogc"><PropertyIsEqualTo><PropertyName>documentStandard</PropertyName><Literal>iso19139</Literal></PropertyIsEqualTo></Filter></csw:Constraint></csw:Query></csw:GetRecords>' >| demo-csw-dcat.xml
curl -H "Content-Type: application/xml" --data-binary @demo-csw-dcat.xml https://apps.titellus.net/geonetwork/srv/eng/csw
En effet, d'un point de vue INSPIRE, il est obligatoire. D'un point de vue ISO, non. Donc ça dépendra du "type" de fiche ...
Non. Comme indiqué en réunion et dans les échanges précédents, l'une repose sur des travaux initiés en 2012 (https://trac.osgeo.org/geonetwork/wiki/proposals/DCATandRDFServices) avec un mapping un peu amélioré depuis selon les schémas (principalement ISO19139, non disponible pour Dublin-core, pour ISO19110, ...). L'autre (https://github.com/geonetwork/geonetwork-microservices/tree/main/modules/services/ogc-api-records) propose un flux DCAT avec un mapping à partir du document de l'index GeoNetwork. Mapping qui peut surement être amélioré selon les objectifs (eg. geonetwork/geonetwork-microservices#65). |
après avoir relu attentivement le ticket, si je comprends bien tant que opendatateam/udata#2800 n'est pas mergée le support csw-dcat n'est pas pleinement opérationnel ? Il serait intéressant de savoir si https://demo.data.gouv.fr fait tourner cette branche, je vois juste actuellement Sur https://www.data.gouv.fr la version est actuellement par contre je 'pense' que le support du moissonage dcat via ogc-api-records est fonctionnel/testable ? |
|
@maudetes si vous voulez faire des tests 'a grande échelle' pour ogc api records, https://demo.georchestra.org/ogc-api-records/collections/main/items?f=dcat est disponible et vient juste d'être déployé avec georchestra/ansible#114. Le geonetwork 4.2.2 de cette instance de demo moissonne les geonetwork de toutes les instances georchestra listées sur https://www.georchestra.org/community.html (donc environ ~15k MD), et le microservice ogc-api-records est en version 4.2.2. https://demo.georchestra.org/geonetwork/srv/fre/csw?SERVICE=CSW&VERSION=2.0.2&REQUEST=GetRecords&outputSchema=http://www.w3.org/ns/dcat%23&typenames=gmd:MD_Metadata&elementSetName=full&resultType=results est aussi disponible pour des tests de moissonage csw-dcat. |
|
@jeanpommier, j'ai validé le moissonneur. Une erreur SSL a cependant lieu lors du moissonnage. Je n'ai pas enquêté, mais @landryb En effet, il est déjà possible de tester le moissonnage via OGC API Records sur les différents environnements. La plateforme de demo déploie bien opendatateam/udata#2800, et il est donc aussi possible de réaliser des tests sur https://demo.data.gouv.fr/ pour le moissonnage CSW-DCAT. Je me suis permise de créer deux organisations avec les moissonneurs correspondants pour tester georchestra sur demo : https://demo.data.gouv.fr/fr/organizations/georchestra-ogc-api-records/ et https://demo.data.gouv.fr/fr/organizations/georchestra-csw/. Je peux vous rajouter comme administrateur sur demande (action
qui retourne cette erreur : La même requête sans le Enfin, je lève un point d'attention sur les flux de moissonnage à mettre en place en production pour éviter des doublons de moissonnage, mais ça peut faire l'objet d'une discussion dédiée, et nous pouvons tester le fonctionnement du moissonnage en attendant. |
|
Ha, mince, oui, je crois qu'il y a un souci avec leurs certificats SSL. J'ai changé l'URL pour pointer sur mon serveur de dev, ça permettra déjà de voir. Pouvez-vous relancer le moissonnage ? Serait-il possible que j'aie la main dessus, ça éviterait sans doute qq aller-retours ? Merci en tous cas ! |
|
ah, pardon, je viens de voir qu'il est programmé en cron, donc y'a plus qu'à attendre voir. Merci ! |
Fait, j'essaierai de comprendre les requetes faites en regardant les logs serveur
Pas du tout étant donné que https://demo.georchestra.org/ogc-api-records/collections/main/items?f=dcat en renvoie 10 a cause de la pagination et qu'il y'a théoriquement au moins 10k records.. est-ce que udata supporte la pagination ? ceci dit dans le format dcat je ne vois pas d'informations sur la 'taille' du dataset a parcourir... alors qu'elle est présente dans les formats xml ou json cf https://demo.georchestra.org/ogc-api-records/collections/main/items?f=json il y'a bien plus de records dans le rdf avec https://demo.georchestra.org/ogc-api-records/collections/main/items?f=dcat&limit=100 mais il faut bien que le client ait un moyen de connaitre la taille de l'ensemble a paginer, a parcourir avec
J'imagine que c'est le backend datagouv qui envoie le SortBy dans le POST ? L'erreur est.. étonnante. Je laisserais les experts geonetwork se pencher dessus.. coté serveur, je vois des hits a 2h du matin venant de python-request, je suppose que ce sont les requetes udata ? un host sur l'ip semble le confirmer:
Oui ca c'était une évidence, mais cette problématique a toujours été présente :) |
|
@jeanpommier, la nouvelle URL fonctionne et il y a bien le même nombre de jeux de données moissonnés que sur la plateforme cible :) Je vous laisse me faire un retour sur le résultat du moissonnage côté contenu. @landryb, merci de vos retours. Pour la pagination, cet endpoint ne semble pas retourner d'éléments de pagination en effet. Côté data.gouv.fr, nous supportons la pagination Hydra, comme spécifié dans la documentation de notre moissonneur DCAT. Côté geonetwork, est-ce qu'il a été envisagé d'ajouter des éléments de pagination ? Concernant le contenu de la requête, c'est bien dans la requête du moissonneur que on utilise le sortBy, comme recommandé ici. Et les appels à 2h du matin semblent bien venir de udata :) Je veux bien l'avis de @fxprunayre sur ces deux points si c'est possible ? 🙏 |
|
Merci. Oui ça a l'air de marcher. Je ne vois pas les images (aperçus) par contre, c'est normal ? Concernant l'URL précédente, avez-vous une idée du pb ? Le certificat a l'air bien reconnu par les navigateurs. Se pourrait-il que ce soit dû à des certificat CA périmés côté python (udata) ? Je n'ai pas la main sur les serveurs de test-data.naturefrance.fr (ni de data.naturefrance.fr), donc je ne sais pas trop comment ils les ont configurés. |
|
@maudetes Le pb de certificat me semble bien être du côté du MNHN, ils sont sur le coup. En attendant, je fais le test avec mon serveur de dev. Donc je confirme, le moissonnage se passe bien, le nombre d'enregistrements matche. Les métadonnées du catalogue sont assez limitées (on est loin d'un ISO valide), cependant je m'interroge à propos de deux éléments :
Merci ! |
|
Merci @jeanpommier pour ce retour, concernant le soucis de certificat et les métadonnées moissonnées.
On n'a pas de méta-données d'image associée à des JDDs sur data.gouv.fr aujourd'hui, donc on ne moissonne pas ces images. Cependant, même si non moissonnée par data.gouv.fr, l'image semble bien exposée dans la métadonnée
En regardant le contenu exposé en DCAT, je vois deux soucis :
|
|
OK, merci, je vais regarder cette histoire de licence. Merci pour l'analyse détaillée |
|
Bonjour à toutes et tous, Pour avancer sur ce sujet, et avoir une première version fonctionnelle (mais améliorable) des deux options en prod, est-ce qu'il serait possible d'avoir un retour côté GeoNetwork (@fxprunayre ou @fgravin peut-être?) sur les points soulevés par les tests de moissonnage de GeoOrchestra (en particulier dans ce commentaire):
Par ailleurs, j'invite ceux qui voudraient à se manifester pour mener des tests sur des plateformes GeoNetwork v4 sur la plateforme de demo https://demo.data.gouv.fr/. Plus on a de tests sur des plateformes réelles, mieux c'est 😊 |
|
suite a pas mal de bricolages lors du community sprint georchestra (cette nuit, ce matin..), https://demo.georchestra.org a été redéployé depuis un build maison produit depuis le fork georchestra/geonetwork rebasé sur le tag 4.2.4 upstream de geonetwork (cf branche https://github.com/landryb/geonetwork/tree/georchestra-gn4.2.x). Le jar du microservice ogc-api-records a aussi été upgradé pour utiliser la version https://github.com/geonetwork/geonetwork-microservices/releases/tag/4.2.4-0.
enfin, si je remets pour le csw-dcat, faire le meme POST avec le a chaque requete CSW, dans le log de geonetwork j'ai: a priori, ce problème viendrait du fait que cette MD est multilingue ? bref.. pour ce qui est de georchestra, on progresse :) |
|
de ce que je vois des 3 derniers moissonages de https://demo.georchestra.org/ogc-api-records/collections/main/items?f=dcat on est passé a 25 MD, certaines sont en erreur de validation ( dans le log du microservice OAPIR j'ai bien vu passer une requete vers ES pour 1000 records et selon le log apache 7mo de données auraient été renvoyés au moissoneur dcat: @maudetes si tu veux trigger un moissonage a la main pour voir ce qui remonte... pas de changement sur le moissonage CSW, toujours 0. |
|
@landryb merci pour le travail d'enquête et d'analyse ! En effet, il y a quelques soucis sur des URLs non valides (sur l'exemple c'est le TLD i2 qui est invalide). La prévisualisation échoue en effet pour des raisons de timeout dans le cas de gros catalogues. |
|
merci pour le test, je viens de voir les résultats prometteurs. J'ai mis je ne connais pas du tout les mappings, mais de quel champ inspire/iso19139 est sensé venir autre point de vigilance: si j'ai bien compris, c'est a l'entité fournissant le point de moissonage de ne faire remonter que les métadonnées locales au catalogue, pas les données moissonnées si elles remontent déjà par un autre chemin. On ne peut pas faire un filtre dans la configuration coté moissoneur. il faudra donc bien le spécifier dans la documentation pour l'adminstrateur du service moissoné (eg eventuellement monter un point d'accès OAPIR spécifique moissonnage par data.gouv sur une url distincte), et proposer des exemples de filtre de configuration du service OAPIR pour exclure les fiches de MD moissonnées depuis une autre source précise, qui générerait des doublons. edit: pour ceux qui veulent voir ce qui est effectivement moissonné, cf https://demo.data.gouv.fr/fr/organizations/georchestra-ogc-api-records/#/datasets |
Il s'agit de l'identifiant de la ressource en ligne |
|
En effet, la question des identifiants à exposer n'est pas encore tranchée.
Côté udata, aujourd'hui on ne moissonne pas les amds:Identifier, on se contente uniquement de moissonner et d'exposer un unique dct:Identifier. Par contre, ça ne me semble pas très difficile, clairement souhaitable et en phase avec les recommandations si je les ai bien comprises. Il serait intéressant d'avoir un avis du CNIG sur le sujet. Le bon endroit pour remonter ces questions serait ce repo https://github.com/cnigfr/metadonnee ? Pour la question de la pagination, à voir ce qui est faisable côté GeoNetwork pour conserver l'ordre des records, mais côté udata, on supporte la pagination Hydra. Si un catalogue de millier de jeu peut être moissonné, la pagination peut être itérée en deuxième itération. Sur le fait de ne faire moissonner que les données locales au catalogue, on avait en effet évoqué les possibilités de subportal côté GeoNetwork (dans le dernier compte rendu), mais des liens de documentation seraient bienvenus sur la section GeoNetwork de notre doc de moissonnage DCAT (pas encore mis à jour pour la v4). |
de ce que j'y comprends, faire un subportal pour n'avoir qu'un sous-ensemble des MD ne servirait que pour les moissonages CSW-DCAT, étant donné que le microservice OAPIR tape directement sur l'index ES il n'a pas connaissance des subportals configurés dans geonetwork.. il faudrait donc 'filtrer' pour créer le sous-ensemble lors de la requete envoyée a ES.. et donc faire une instance dédiée du microservice. |
Je pense que les Après effectivement, lorsqu'on parcourt une collection issue d'un sous portail, on ne trouve aucune fiche. Il doit y avoir un problème d'implémentation ou de configuration peut-être. Pour moi, un subportal donne un entry point pour les api GN4, CSW et OGC Records. |
Aaah oui très juste, ca me revient, j'avais oublié ce détail.
oui j'avais aussi vu des bugs en étudiant https://dev.geo2france.fr/ogc-api-records/collections - pour les 'portails thématiques' (eg subportals) chacun faisait remonter toutes les métadonnées de l'index (donc pas de filtrage), et chacun des |
|
Dans le cas de l'endpoint dcat, il est aussi possible de fournir un endpoint DCAT filtré avec des paramètres d'intérêt, ex https://demo.georchestra.org/ogc-api-records/collections/main/items?f=dcat&limit=100&q=incendie, mais je ne sais pas si c'est suffisamment puissant/fin pour les besoins. |
|
le moissonage de la nuit dernière du microservice OGC a échoué: coté logs apache, j'ai un http://http.cat/406: et coté logs microservice, a priori il y'aurait une limite par défaut a 15k records dans la conf de l'index ou d'ES: je vais remettre la limite a 15k coté client pour le prochain moissonage... mais ca montre clairement le besoin d'une pagination pour ce type de moissonage :) |
Oui il faut clairement gérer la pagination. Il faudra trouver un financement et l'implémenter. Je ne sais pas si c'est un besoin du BRGM @fxprunayre ? Au moins, comme c'est un micro service tu devrais pouvoir le scaler et ne pas faire tomber ton GN, ni l'index si tu te débrouilles bien 😏 |
|
Pour le moissonnage csw-dcat, dans la majorité des cas, les mentions de licences n'étaient pas reconnues. Le contenu des balises gmd:MD_LegalConstraints/gmd:otherConstraints est copié en dct:license quel que soit sa parenté (useConstraints, accessConstraints), ce qui passe mal avec udata (et à raison je dirais). J'ai essayé d'améliorer la façon de gérer ces blocs. Il y a une PR en cours sur Geonetwork : geonetwork/core-geonetwork#7176 |
|
Bonjour, Je reviens avec quelques nouvelles sur le sujet du moissonnage des GeoNetwork v4 par data.gouv.fr. CSW-DCAT en productionTout d'abord, suite aux tests concluants réalisés, la pull request pour le moissonnage de GeoNetwork v4 via CSW avec schéma DCAT a été mergée côté data.gouv.fr et déployée en production ! 🚀 Certaines questions de mapping en DCAT des métadonnées ne sont pas forcément résolues, et des itérations sont bien évidemment à prévoir par la suite, mais cette première version est fonctionnelle. Il est donc maintenant possible de moissonner les portails GeoNetwork 4 sur data.gouv.fr via CSW. Vous êtes les bienvenus pour créer vos moissonneurs (sur demo.data.gouv.fr d'abord pour test) en choisissant le moissonneur CSW-DCAT. Autres considérationsLe moissonnage via OGC API Records est toujours en phase de test, avec certaines questions sur les identifiants ou la pagination pas encore résolues. Je vais donc clôturer ce ticket, mais au besoin, des tickets dédiés seront créés pour les itérations futures, pour plus de lisibilité. |
github-project-automation
bot
moved this from 👀 Review
to ✅ Done
in 🚀 Produit data.gouv.fr [Archivé]
L’amélioration que vous avez en tête
Le endpoint Geonetwork DCAT directement consommable tel que documenté sur etalab/doc.data.gouv.fr@f8a0b32#r75959289 n'est plus disponible à partir de la version 4.0 de Geonetwork car il est possible d'avoir une sortie sérialisé DCAT via le end-point CSW (https://github.com/geonetwork/core-geonetwork/wiki/DCAT-enhancements)
Il faut donc au choix rétablir le end-point tel qu'il était en faisant une PR dans Geonetwork mais c'est peu probable sinon il n'aurait pas été déprécié soit il faut voir comment adapter notre consommation du DCAT via l'appel depuis le endpoint CSW.
En dehors des aspects techniques, il faut voir la charge que cela implique pour nous ou le BRGM qui envisageait à un moment de passer par Geonetwork. Cela peut impliquer aussi l'équipe Geonetwork selon si des modifications doivent être faites sur la base de code du projet lui-même.
Constatations techniques préliminaires pour investiguer
Pour avoir une idée du retour de l'appel CSW comparativement à celui existant (attention, ici on tape sur un serveur avec une version 4.2.1 de Geonetwork
J'ai fait un test sur le catalogue de l'OREME qui sont en version 3.10 actuellement (ce qui me permettrait de comparer la sortie dcat actuelle encore supportée et celle via le endpoint CSW
Sortie DCAT "legacy" via https://sig.oreme.org/geonetwork/srv/eng/rdf.search
VS sortie "nouvelle" via le endpoint CSW
Problème dans ce 2nd cas: pas de records retournés. Nous avons enlevé le filtre iso19139 avec pour avoir des records
The text was updated successfully, but these errors were encountered: