search

PnX-SI / GeoNature

Application de saisie et de synthèse des observations faune et flore
GNU General Public License v3.0
99 stars 101 forks source link

Accès aux données avec le Web Sémantique (LOD, RDF, JSON-LD, Turtle, ...) #996

Open jmvanel opened 4 years ago

jmvanel commented 4 years ago

Mon objectif concret actuel est de mélanger les données ouvertes de biodiversité avec les Données Liées Ouvertes (LOD) : Wikidata.org, dbPedia.org, Taxref-LD, et mes propres observations en tant que botaniste: Premiers travaux sur la Flore de Reyrieux

Comme vous le savez probablement, le LOD est un moyen de créer des liens sémantiques entre des ensembles de données, avec des vocabulaires auto-descriptifs relativement standards. Comme pour les API Web ordinaires, c'est également un moyen de découpler les données et les applications. Ainsi, la connexion des données de geonature aux syntaxes et vocabulaires LOD standard peut conduire à de nombreux cas d'utilisation imprévus. Mon premier cas d'utilisation actuel est de créer des cartes avec à la fois mes observations botaniques LOD et les observations geonature (et inaturalist.org ).

A titre d'exemple j'ai commencé à mapper le JSON de inaturalist.org aux vocabulaires LOD standard dans le projet ci-dessous, en utilisant la technique JSON-LD (voir https://json-ld.org/), qui fournit une «grille de lecture» LOD pour les données JSON simples: https://github.com/jmvanel/rdf-convert/tree/master/inaturalist.org

J'espère avoir votre bénédiction.

Pour rendre les choses plus fluides techniquement, il y a quelques choses que vous pouvez faire. Vous pouvez exposer le côté JSON-LD de vos URL JSON de l'une des manières décrites dans la spec JSON-LD: https://www.w3.org/TR/json-ld/#modifying-behavior-with-link-relationships ou ajouter simplement une clé "@context" dans le JSON.

Pour continuer concrètement

La discussion qui suit nous permis de faire connaissance; pour continuer concrètement:

camillemonchicourt commented 4 years ago

Bonjour,

en effet très intéressant. Un travail dans ce sens a été initié avec la première version du module EXPORT. Voir la documentation sur cette partie : https://github.com/PnX-SI/gn_module_export#export-rdf-au-format-s%C3%A9mantique-darwin-sw Ainsi que l'info sur le module : https://framalistes.org/sympa/arc/geonature-info/2020-06/msg00000.html Et l'exemple sur le serveur de démo : http://demo.geonature.fr/geonature/api/exports/semantic_dsw

Au plaisir d'avoir plus de détails sur ce que vous souhaitez faire et comment y contribuer ?

jmvanel commented 4 years ago

C'est dommage que ce travail avec Darwin Core ait été fait indépendamment de l'API existante. Avec toutes les réserves qu'on peut faire sur Darwin Core, complexe, et je ne pense pas qu'il existe des vrais jeux de données avec Darwin Core, encore moins des API RDF. En tout cas sur leur site, on n'en mentionne aucun.

De toute façons, le LOD c'est fait pour créer des liens, pas pour fournir un gros dump rempli de noeuds anonymes. En l'occurrence liens entre une observation, un auteur, un taxon. Mais il faut que ces 3 choses aient un URI de données, et de préférence que cet URI de données soit aussi consultable par HTML, via la négociation de contenu. C'est ainsi que ça marche sur semantic-forms , Site naturaliste, jardins, biodiversité, et sur dbPedia.org ou Wikidata.org . Voici un exemple (réel) d'observation très simple, mais qui applique ces bonnes pratiques : Castanea sativa - Châtaignier commun = https://semantic-forms.cc:1953/ldp/1596471868615-872101958815313 Cela lie l'observation à un taxon TAXREF, à un évènement ( l'observateur est logé dans une base annexe qui versionne tout, mais il devrait y être ). Cet URI, cliqué dans le navigateur , renvoie une vue HTML de la donnée, et avec les entêtes HTTP Accept: qui conviennent, renvoie aussi du Turtle , et autres formats RDF (négociation de contenu). Par commodité pédagogique ;) , on peut aussi voir ce Turtle dans le navigateur : http://semantic-forms.cc:1952/download?url=https%3A%2F%2Fsemantic-forms.cc%3A1953%2Fldp%2F1596471868615-872101958815313&syntax=Turtle

Les principes étant rappelés, ce qu'il faudrait avoir dans geonature, c'est un accès RDF pour chaque page observation, personne utilisateur, taxon. Je pensais partir de l'API JSON pour l'enrichir "de l'extérieur" via JSON-LD, mais puisque le projet Geonature est déjà sur les rails RDF, il faut l'enrichir "de l'intérieur" via JSON-LD . C'est à dire une approche incrémentale , dans l'API JSON:

  1. ajouter les clés spéciales JSON-LD : @id (le plus important), @base , @type , cf https://www.w3.org/TR/json-ld/#keywords
  2. écrire un contexte JSON, la grille de lecture RDF du JSON, et référer son URL via @context
  3. ce faisant, on sera amené tout naturellement à réutiliser des ontologies existantes, et éventuellement en écrire une petite ontologie Quelles ontologies existantes ? FOAF et / ou schema.org , TAXREF-LD, Darwin Core, éventuellement ma petite ontologie pour observations : https://github.com/deductions/deductions.github.io/blob/master/nature_observation.owl.ttl#L17 qui va avec une specification de formulaire: https://github.com/deductions/deductions.github.io/blob/master/nature_observation.form.ttl

On peut alors ajouter un entête HTTP Accept: application/ld+json sur l'API JSON. Ensuite, on peut mettre en place les négociations de contenu sur les pages HTML ou redirection, cerise sur le gâteau .

Je peux amorcer la pompe sur les 3 étapes. Pour cela je propose de commencer par écrire un exemple de JSON existant avec ajout de @id (le plus important), @base , @type . Ensuite les développeurs Python (qui ?) peuvent implémenter cela.

Quelles sont les instances non démo de GeoNature ? Où est la doc. de l'API?

jmvanel commented 4 years ago

Travail en cours, besoin de concertations avec les gestionnaires de GeoNature: https://github.com/jmvanel/rdf-convert/tree/master/geonature

camillemonchicourt commented 4 years ago

OK super, même si de mon côté je n'ai pas les compétences pour apporter à la réflexion. A discuter avec @amandine-sahl après les congés.

jmvanel commented 4 years ago

Mes petites questions simples ci-dessus

  1. Quelles sont les instances non démo de GeoNature ? TROUVÉ' ! https://lite.framacalc.org/9efn-geonature-users , un vrai carnet d'adresse ! Cependant j'ai l'impression que ce sont surtout des instances de l'ancienne version, pas celle de demo...
  2. Où est la doc. de l'API? TROUVÉ ! http://docs.geonature.fr/development.html#api
  3. Quid de l'API de GeoNature-citizen ? ( http://demo.geonature.fr/geonature/#/ est une instance de GeoNature-atlas )

Pour la 2, je pense après réflexion que c'est une API purement applicative, d'ailleurs je l'ai découverte en regardant l'outil de dev. du navigateur :) . Alors j'ajouterai la question : où est implémentée cet API ? Je ne trouve pas d'API pour organisation ( nommé "organisme" dans l'API , mais c'est ambigu dans un contexte naturaliste ! ).

Un petit problème est que l'API renvoie HTTP 403 pour des appels ne provenant pas d'un navigateur. Pour tester, je dois envoyer le bon cookie obtenu via l'onglet Network de l'outil de développement du navigateur. J'espère que ça pourra être changé.

Que sont ces 2 champs dans occtax/ ? Le taxon et le nom mentionné ?

        "cd_nom": 60015,
        "cd_ref": 60015,

En JSON-LD , il faut ajouter:

    "@id": "http://taxref.mnhn.fr/lod/taxon/60015/13.0",
camillemonchicourt commented 4 years ago
jmvanel commented 4 years ago

Merci pour toutes ces précisions. Connaissez vous quelques instances de GeoNature de la même version que demo ?

J'ai essayé le module EXPORT via le lien donné http://demo.geonature.fr/geonature/api/exports/swagger/1 , mais je ne trouve pas la doc. correspondante. J'ai essayé "naïvement" 222 réponses avec Famille=Lamiaceae , mais ça ne donne rien . curl -X GET "http://demo.geonature.fr/geonature/api/exports/api/1?limit=222&Famille=Lamiaceae" \ -H "accept: application/json"

En tous cas je continue à privilégier l'API interne, bien documentée, assez simple, et réellement utilisée (par le site lui-même). Voici ce que ça donne pour l'instant avec un @context JSON-LD , et en supposant qu'on ajoute quelques clés JSON "@id" et "@type" par ci par là :
https://github.com/jmvanel/rdf-convert/blob/master/geonature/occtax.cmw.ttl Je trouve que c'est pas mal pour un début ! Mais comme dit plus haut, pour avancer avec l'API interne, et en admettant que les données par l' API ne sont pas moins publiques que ce qu'on obtient dans l'application sans être authentifié, il faudrait :

  1. ajouter quelques clés JSON "@id" et "@type"
  2. pouvoir avoir une réponse de l'API sans cookie
camillemonchicourt commented 4 years ago

OK, à voir avec @amandine-sahl plus tard, car je ne maîtrise pas assez le sujet.

orovellotti commented 4 years ago

Je peux peut être aider avant le retour de @amandine-sahl.

Nous avons opté pour un export RDF statique plutôt que de servir une API Json LD pour l'instant. C'est un premier pas. Le développement d'une API externe serait effectivement utile mais reste à faire/financer et il faut ensuite s'engager à maintenir cette API en fonction dans chaque instances.

Pour aller vers une vision "Web de Donnée" il faudrait soit:

Vous pouvez prototyper avec les données RDF PNE mentionnées ci dessus et nous serions tous je pense très intéressés par vos résultats.

Olivier

jmvanel commented 4 years ago

En fait ce qu'il bien voir c'est que JSON-LD c'est du vrai JSON, qui peut être très proche du JSON actuel de l'API interne, Pour cela, je vous propose quelques modifs qui ne devraient pas être perturbantes pour l'utilisation dans l'appli. GeoNature: https://github.com/jmvanel/rdf-convert/blob/master/geonature/occtax.jsonld

Les données RDF PNE je ne sais pas les trouver (voir plus haut) , ni par l'API interne ( est -ce la même API que l'instance demo ? ), ni par l'export mentionné par Camille .

La maintenance, effectivement, si on part sur enrichir l'API interne, et si celle-ci change, il faudra faire quelque chose ... IL y a de la maintenance pour n'importe quelle liaison Web des Données, alias LOD. Mais on est dans un projet Open Source, chacun peut proposer des pull request :) .

En tous cas le LOD ce n'est pas du top down , c'est le contraire, chacun publie des URL de données, qui contiennent des URI qui se réfèrent à d'autres documents téléchargeables (des référentiels comme Wikidata, dbPedia, TAXREDF-LD, ..., ou simples pages statiques comme Jean-Marc Vanel = http://jmvanel.free.fr/jmv.rdf#me ), et ainsi récursivement. Après, il a des bases SPARQL qu'on peut remplir avec les données qui intéressent, encore faut il qu'elles sont disponibles en RDF. C'est ce que je fais avec http://semantic-forms.cc:1952/ , où par exemple je n'ai pas chargé tout TAXREF-LD mais seulement les taxons qui sont liés dans une observation. Mais il est facile de faire une recherche SPARQL fédérée entre la base locale et par exemple TAXREF-LD. Les requêtes fédérées sont une grande force de SPARQL. "consolider toutes les données" de plusieurs instances GeoNature : une fois que leur API parle RDF (JSON-LD en l'occurrence), c'est juste une tâche pour un crawler RDF, pas besoin d'un gros dump qui rassemble peut-être trop de données pour certains utilisateurs. On bien on peut générer ce dump RDF via l'API en énumérant toutes les entités.

camillemonchicourt commented 4 years ago

OK merci pour ces précisions.

Pour les données de production du PNE, grâce au module EXPORT (https://github.com/PnX-SI/gn_module_export), elles sont disponibles sous forme de fichiers CSV et GPKG sous licence ouverte (https://www.data.gouv.fr/fr/datasets/observations-de-biodiversite-faune-flore-du-parc-national-des-ecrins/).

Et comme sur le serveur de démo (http://demo.geonature.fr/geonature/api/exports/semantic_dsw), elles sont aussi disponibles au format RDF sous forme d'API : https://geonature.ecrins-parcnational.fr/api/exports/semantic_dsw Ou sous forme de fichier, généré par une commande dédiée : https://geonature.ecrins-parcnational.fr/api/static/exports/dsw/export_dsw.ttl

Voir la documentation du module EXPORT sur la partie RDF : https://github.com/PnX-SI/gn_module_export#export-rdf-au-format-s%C3%A9mantique-darwin-sw

orovellotti commented 4 years ago

Bonsoir

J’espère que vous avez réussit à obtenir le fichier au format RDF en suivant la documentation.

https://github.com/PnX-SI/gn_module_export

Nous sommes particulièrement intéressé par les cas d’utilisations que vous pourriez nous faire remonter.

Si vous avez réussit a croiser les Taxref -ld et les occurrences de taxon de geonature pour en faire émerger un usage pour les naturalistes nous aimerions tous être mis dans la boucles.

Eg: Quelles sont les occurrences d’epèces à status ? Quels est le groupe le plus observé au PNE ?

jmvanel commented 4 years ago

Oui , @orovellotti , j'ai récupéré le fichier TTL du PNE :) . Et , bonne chose, l'entête HTTP annonce Turtle: 

wget --method=HEAD https://geonature.ecrins-parcnational.fr/api/static/exports/dsw/export_dsw.ttl
Mode « spider » activé. Vérification de l’existence d’un fichier distant.
--2020-08-12 16:37:03--  https://geonature.ecrins-parcnational.fr/api/static/exports/dsw/export_dsw.ttl
...
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 3155479 (3,0M) [text/turtle]
Le fichier distant existe.

Je peux donc le charger dans ma base SPARQL . C'est très rapide, et ça dit: RDF document: 53000 triples, 9000 subjects , 41 predicates, 14437 objects, 0 objects from page URI.

Par contre cet URL (en quoi est différent ? ) ne marche pas : https://geonature.ecrins-parcnational.fr/api/exports/semantic_dsw Ca renvoie 

Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request

Reason: Error reading from remote server

Le fichier TTL du PNE

Non seulement il n'y a presque que des noeuds anonymes, mais il y en a beaucoup trop: 

jmv@jmv-SMBIOSation:~/data/Biologie/GeoNature$ grep 'foaf:nick' export_dsw.pne.ttl |sort|uniq|wc
    114     518    4390
jmv@jmv-SMBIOSation:~/data/Biologie/GeoNature$ grep 'foaf:nick' export_dsw.pne.ttl |wc
   2000    8536   71420

De plus c'est foaf:name qui convient et non foaf:nick .

Et, horreur, en faisant la même analyse avec les taxons, on s'aperçoit qu'il n'y en a qu'un, Alnus alnobetula, mais 1000 blocs dwc:Taxon de 6 lignes chacun :

jmv@jmv-SMBIOSation:~/data/Biologie/GeoNature$ grep 'dwc:taxonID' export_dsw.pne.ttl |wc
   1000    2000   65872
jmv@jmv-SMBIOSation:~/data/Biologie/GeoNature$ grep 'dwc:taxonID' export_dsw.pne.ttl |sort|uniq
            dwc:taxonID <http://taxref.mnhn.fr/lod/taxon/81563/12.0>,
    dwc:taxonID <http://taxref.mnhn.fr/lod/taxon/81563/12.0>,

On voit donc que c'est un simple échantillon de Turtle, et non un dump complet des données d'observation. Mais aussi cela témoigne d'une qualité de données faible par rapport aux bonnes pratiques data et LOD en particulier. Au final, voici un bloc Turtle dwc:Identification : 

_:N11e657add455454e982027abcc0de59b a dwc:Identification ;
    dsw:identifies _:N3d330897edec4e61a01f5a995d2ff892 ;
    dsw:toTaxon [ a dwc:Taxon ;
            dwc:nameAccordingTo "Taxref V11" ;
            dwc:scientificName "Alnus alnobetula (Ehrh.) K.Koch, 1872" ;
            dwc:taxonID <http://taxref.mnhn.fr/lod/taxon/81563/12.0>,
                81563 ;
            dwc:vernacularName "aucun"@fr ] ;
    dwc:identificationRemarks "None" ;
    dwc:identificationVerificationStatus "Inconnu" ;
    dwc:identifiedBy [ a foaf:Agent,
                foaf:Person ;
            foaf:nick "SALOMEZ Pierre" ] .

Et par quoi il devrait être remplacé:

_:N11e657add455454e982027abcc0de59b a dwc:Identification ;
    dsw:identifies _:N3d330897edec4e61a01f5a995d2ff892 ;
    dsw:toTaxon  <http://taxref.mnhn.fr/lod/taxon/81563/12.0> ;
    dwc:identifiedBy _:SALOMEZ_Pierre .
_:SALOMEZ_Pierre a foaf:Person;
            foaf:name "SALOMEZ Pierre" .

Je me suis dit, il y a peut-être d'autres taxons qui ne référencent pas Taxref, alors j'ai lancé cette requête , mais ça renvoie zéro résultat : 

prefix dwc: <http://rs.tdwg.org/dwc/terms/>
SELECT * WHERE { GRAPH ?G {
  ?S a dwc:Taxon .
  FILTER( ! EXISTS { ?S  dwc:nameAccordingTo "Taxref V11" } )
} }

Divers

La documentation du module EXPORT sur la partie RDF : https://github.com/PnX-SI/gn_module_export#export-rdf-au-format-s%C3%A9mantique-darwin-sw est difficile à lire , car il semble que presque tout est consacré au déploiement et non à l'usage .

TAXREF-LD 13 est sorti.

A suivre

Pourvu qu'on aie les données, ces questions sont faciles à répondre en SPARQL :

Quelles sont les occurrences d’espèces à status ? Quel est le groupe le plus observé au PNE ? (mais que faut -il entendre par groupe ? famille, genre ? )

camillemonchicourt commented 4 years ago

Bonsoir,

merci pour ces retours.

Il est possible que j'ai eu un soucis lors de la génération du fichier https://geonature.ecrins-parcnational.fr/api/static/exports/dsw/export_dsw.ttl, ce qui expliquerait des soucis que vous évoquez. Ou alors il faut que nous le fassions évoluer comme vous suggérez. Je ne maîtrise pas assez le sujet pour y répondre. On en reparle quand les personnes compétentes sur le sujet auront pu regarder ça.

Par contre je ne comprends pas pourquoi l'export RDF en API ne fonctionne pas chez vous, car je viens de tester à nouveau avec succès sur https://geonature.ecrins-parcnational.fr/api/exports/semantic_dsw

Nous avions aussi noté que TAXREF-LD version 13 était sorti mais pas encore pu y bosser.

jmvanel commented 4 years ago

@camillemonchicourt , effectivement j'ai pu accéder à /exports/semantic_dsw dans la soirée , mais maintenant ce n'est plus le cas:

wget --method=HEAD https://geonature.ecrins-parcnational.fr/api/exports/semantic_dsw
Mode « spider » activé. Vérification de l’existence d’un fichier distant.
--2020-08-13 06:28:42--  https://geonature.ecrins-parcnational.fr/api/exports/semantic_dsw
Résolution de geonature.ecrins-parcnational.fr (geonature.ecrins-parcnational.fr)… 188.165.118.86
Connexion à geonature.ecrins-parcnational.fr (geonature.ecrins-parcnational.fr)|188.165.118.86|:443… connecté.
requête HTTP transmise, en attente de la réponse… 502 Proxy Error
Le fichier distant n’existe pas — lien mort.
jeudi 13 août 2020, 06:29:36 (UTC+0200)

J'ai alors chargé ce nouveau document que j'ai téléchargé hier soir :

RDF document: 53000 triples, 9000 subjects , 41 predicates, 13821 objects, 0 objects from page URI Les mêmes chiffres ronds (?!).

Un premier exemple de requête:

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
prefix dsw: <http://purl.org/dsw/>
prefix dwc: <http://rs.tdwg.org/dwc/terms/>
prefix foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?S ?taxonID ?scientificName ?naturaliste  WHERE { GRAPH ?G {
  ?S a dwc:Identification .
  ?S dsw:toTaxon / dwc:taxonID ?taxonID .
  ?S dsw:toTaxon / dwc:scientificName ?scientificName .
  ?S dwc:identifiedBy / foaf:nick ?naturaliste .
} } LIMIT 100

qui renvoie:

"S" | "naturaliste" | "scientificName" | "taxonID"
-- | -- | -- | --
1c77daf00b2e39aae228ec5fb7440ba1 | "THOMAS Bernard" | "Populus alba L., 1753" | http://taxref.mnhn.fr/lod/taxon/115110/12.0
1c77daf00b2e39aae228ec5fb7440ba1 | "THOMAS Bernard" | "Populus alba L., 1753" | "115110"^^http://www.w3.org/2001/XMLSchema#integer
4a03f8ac543bf042ae0869f4eb1ba214 | "GONSOLIN Gabriel" | "Juniperus communis subsp. communis L., 1753" | http://taxref.mnhn.fr/lod/taxon/136969/12.0
4a03f8ac543bf042ae0869f4eb1ba214 | "GONSOLIN Gabriel" | "Juniperus communis subsp. communis L., 1753" | "136969"^^http://www.w3.org/2001/XMLSchema#integer

Ce qui montre qu'on peut parfaitement utiliser ces données , MAIS ... comme indiqué dans le message précédent, ça ne respecte pas les bonnes pratiques RDF. Le dwc:taxonID numérique est à supprimer.

Cette requête fédérée fait la même chose et montre comment accéder à TAXREF-LD à la source officielle: 

PREFIX ...
SELECT ?S ?taxonID ?scientificName ?naturaliste  WHERE { GRAPH ?G {
  ?S a dwc:Identification .
  ?S dsw:toTaxon / dwc:taxonID ?taxonID .
  SERVICE <https://taxref.i3s.unice.fr/sparql> {
    ?taxonID rdfs:label ?scientificName .  }
  ?S dwc:identifiedBy / foaf:nick ?naturaliste .
} } LIMIT 100

Ca dure un peu plus longtemps, mais reste acceptable, et c'est la bonne façon de faire. Bien sûr on peut aussi charger TAXREF-LD sur la même base SPARQL . A NOTER: le SERVICE officiel est http://taxref.mnhn.fr/sparql , mais il est momentanément indisponible (signalé).

A SUIVRE: les 2 thèmes de requête suggérés par @orovellotti .

camillemonchicourt commented 4 years ago

OK super, et merci pour ces précisions et cette analyse précieuse. On va voir comment on peut donc améliorer les exports RDF, c'est noté dans le dépôt du module Export (https://github.com/PnX-SI/gn_module_export/issues/81).

jmvanel commented 4 years ago

@camillemonchicourt , j'avais vu , car la notification github marche bien.

Le dump Turtle avec le vocabulaire Darwin est utilisable, mais je continue à penser que partir de l'API existante est la bonne manière:

On verra au retour de la chargée de l'API ...

jmvanel commented 4 years ago

SUITE : les 2 thèmes de requête suggérés par @orovellotti

 Plantes à statut

Prenons une plante rare et voyante, présente dans les relevés PNE RDF: Daphne cneorum. Voici qu'on a dans TAXREF-LD (téléchargeable depuis https://github.com/frmichel/taxref-ld/tree/master/dataset ) :+1: 

<http://taxref.mnhn.fr/lod/taxon/94423/12.0>
        taxrefprop:hasStatus  [ a                       taxrefstatus:RedListStatus ;
                                rdfs:label              "IUCN Red List status RE" ;
                                dct:coverage            <http://taxref.mnhn.fr/lod/location/INSEER42> ;
                                dct:description         "Daphne cneorum has IUCN Red List status RE" ;
                                dct:source              <http://taxref.mnhn.fr/lod/bib/186028> ;
                                taxrefprop:statusValue  wdt:Q10594853 ;
                                wdt:P248                <http://taxref.mnhn.fr/lod/bib/186028> ;
                                wdt:P3005               <http://taxref.mnhn.fr/lod/location/INSEER42>
                              ] ;
        taxrefprop:hasStatus  [ a                       taxrefstatus:RedListStatus ;
                                rdfs:label              "IUCN Red List status EN" ;
                                dct:coverage            <http://taxref.mnhn.fr/lod/location/INSEER54> ;
                                dct:description         "Daphne cneorum has IUCN Red List status EN" ;
                                dct:source              <http://taxref.mnhn.fr/lod/bib/267074> ;
                                taxrefprop:statusValue  wdt:Q11394 ;
                                wdt:P248                <http://taxref.mnhn.fr/lod/bib/267074> ;
                                wdt:P3005               <http://taxref.mnhn.fr/lod/location/INSEER54>
                              ] ;
        taxrefprop:hasStatus  [ a                      taxrefstatus:LegalStatus ;
                                rdfs:label             "Legal status RV82" ;
                                dct:coverage           <http://taxref.mnhn.fr/lod/location/INSEER82> ;
                                dct:description        "Daphne cneorum has legal status RV82" ;
                                dct:source             <http://taxref.mnhn.fr/lod/status/PR/RV82> ;
                                taxrefprop:statusType  taxrefstatus:Protection ;
                                wdt:P248               <http://taxref.mnhn.fr/lod/status/PR/RV82> ;
                                wdt:P3005              <http://taxref.mnhn.fr/lod/location/INSEER82>
                              ] ;
etc ...........................

Au vu de ceci, on peut écrire la requête, avec un morceau de la requête n°1 : 

prefix dct:   <http://purl.org/dc/terms/>
prefix taxrefstatus: <http://taxref.mnhn.fr/lod/status/>
prefix taxrefprop: <http://taxref.mnhn.fr/lod/property/>
...
SELECT  ?TAXON ?scientificName ?description WHERE { GRAPH ?G {
SERVICE <https://taxref.i3s.unice.fr/sparql> {
  ?TAXON taxrefprop:hasStatus ?STATUT .
  ?STATUT taxrefprop:statusType taxrefstatus:Protection .
  ?STATUT dct:description ?description .
}
  ?S a dwc:Identification .
  ?S dsw:toTaxon / dwc:taxonID ?TAXON .
  ?S dsw:toTaxon / dwc:scientificName ?scientificName .
}} LIMIT 100

NOTE: la variable ?STATUT est indispensable pour assurer que description et status soient dans le même bloc taxrefprop:hasStatus Résultat:

"TAXON" | "description" | "scientificName"
-- | -- | --
http://taxref.mnhn.fr/lod/taxon/82620/12.0 | "Anemone hepatica has legal status RV23" | "Hepatica nobilis Schreb., 1771"
http://taxref.mnhn.fr/lod/taxon/82620/12.0 | "Anemone hepatica has legal status RV11" | "Hepatica nobilis Schreb., 1771"
http://taxref.mnhn.fr/lod/taxon/82620/12.0 | "Anemone hepatica has legal status RV43" | "Hepatica nobilis Schreb., 1771"
http://taxref.mnhn.fr/lod/taxon/100956/12.0 | "Helianthemum nummularium has legal status RV53" | "Helianthemum nummularium (L.) Mill., 1768"

etc ...

frmichel commented 4 years ago

Bonjour, je plonge dans cette discussion animée.

D'abord bravo pour ce travail du PNE, c'est super de voir cela aboutir. Ci-dessous j'essaie de reprendre les éléments discutés sur lesquels je peux ajouter mes 2 cents.

Modélisation de l'export GeoNature en RDF

Une première chose : Darwin-SW est probablement un bon choix pour les observations, par contre attention je viens de voir qu'il y a une version 1.1 en préparation (https://github.com/darwin-sw/dsw/tree/master) dans laquelle dsw:toTaxon est deprecated et remplacée par dwciri:toTaxon (http://rs.tdwg.org/dwc/iri.htm). Donc il faudrait peut-être faire le point sur les évolutions et les liens avec le namespace dwciri, quitte à être un peu en avance de phrase.

Je rejoins @jmvanel sur plusieurs points:

_:N11e657add455454e982027abcc0de59b a dwc:Identification ;
    dsw:identifies _:N3d330897edec4e61a01f5a995d2ff892 ;
    dwciri:toTaxon  <http://taxref.mnhn.fr/lod/taxon/81563/12.0> ;
    dwc:identifiedBy _:SALOMEZ_Pierre .

_:SALOMEZ_Pierre a foaf:Person;
    foaf:name "SALOMEZ Pierre" .

<http://taxref.mnhn.fr/lod/taxon/81563/12.0> a dwc:Taxon ;
    dwc:nameAccordingTo "Taxref V12" ;
    dwc:scientificName "Alnus alnobetula (Ehrh.) K.Koch, 1872" ;
    dwc:taxonID 81563 ;
    dwc:vernacularName "tartampion"@fr.

API JSON vs. JSON-LD

Est-ce qu'une API Web "classique" doit devenir une API JSON-LD en ajoutant un @profile et @id ? C'est possible mais est-ce nécessaire, ou désirable, pas sûr. D'abord, même si ça semble transparent a priori, il faut s'assurer que les applis existantes vont continuer à fonctionner normalement avec ce genre d'ajout. Elles devraient, mais entre le théorie et la pratique... Vérifier également que ça ne va pas perturber les outils Swagger (OpenAPI).

De plus, ça peut tout-à-fait avoir du sens de faire co-exister des API Web et des services orientés LOD : la convergence n'est pas une fatalité. Au MNHN il y a l'API TAXREF et TAXREF-LD, et il n'y a aucune nécessité de fusionner. Ils sont complémentaires.

JSON-LD n'est pas la réponse à tout : ça permet d'interpréter des champs JSON standards comme des prédicats de vocabulaires, des valeurs comme des IRI etc. Par contre, impossible de concaténer des champs ou remanier complètement la forme du document JSON. Donc la représentation RDF cible est contrainte par la forme JSON de l'API existante. C'est pour cette raison que j'ai développé les SPARQL micro-serivces : cela permet de créer un petit SPARQL endpoint qui encapsule une API web. En plus d'un profile JSON-LD, il utilise une requêtre CONSTRUCT pour transformer, si besoin, l'allure du graph résultat. Le MNHN l'utilise déjà pour 16 API (GBIF, CoL, Tropicos, Worms, Fishbase, PESI, Zoobank etc.) pour comparer TAXREF aux autres bases via l'appli TAXREF-Web. Une limitation : un SPARQL micro-service matérialise le graphe à requêter à chaque fois, donc c'est bien adapté à des requêtes très ciblées (exemple : les observations pour une taxon précis), mais si on veut requêter un grand nombre d'observations en même temps, ça va prendre du temps, voire échouer dans les cas extrêmes (j'ai un cas qui fonctionne avec des documents JSON de 600.000 lignes, ça prend environ 1 minute). Et je peux faire comme pour le MNHN : héberger les services pour vous.

Bref, bien réfléchir à toutes les options avant de se lancer dans la modification de l'API.

jmvanel commented 4 years ago

Pas grand'chose à (re)dire sur le message clair et nuancé de @frmichel ; juste une faute de frappe, à la place de "en ajoutant un @Profile et @id" , lire "en ajoutant un @context et @id" (et aussi @type ) , cf https://www.w3.org/TR/json-ld11/#keywords . Personnellement je garderais un seul triplet sur taxon, dans le but d'éviter les redondances, puisque dans la plupart des usages, on aura besoin de toute façon d'aller chercher certaines parties de TAXREF-LD ; <http://taxref.mnhn.fr/lod/taxon/81563/12.0> rdfs:label "Alnus alnobetula" .

jmvanel commented 4 years ago

SUITE : thème de requête suggéré par @orovellotti

Quel est le groupe le plus observé au PNE ?

Le design pattern SPARQL pour classer par comptage , cf https://github.com/jmvanel/semantic_forms/tree/master/sparql

select ( count(?S) AS ?count ) ?CLASS
where {
  ?S a ?CLASS
} GROUP BY ?CLASS
ORDER BY DESC (?count)

Ici on va compter les triplets ?X dwc:taxonID ?TAXON .

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
prefix dsw: <http://purl.org/dsw/>
prefix dwc: <http://rs.tdwg.org/dwc/terms/>
prefix taxrefprop:  <http://taxref.mnhn.fr/lod/property/>
prefix taxrefrk:    <http://taxref.mnhn.fr/lod/taxrank/>
select ( count(?TAXON) AS ?count ) ?TAXON ?NOM
where { 
  ?X dwc:taxonID ?TAXON .
  ?TAXON rdfs:label ?NOM .
}  GROUP BY ?TAXON  ?NOM
ORDER BY DESC (?count)
LIMIT 20

Résultat:

"NOM" | "TAXON" | "count"
"Larix decidua" | http://taxref.mnhn.fr/lod/taxon/105042/12.0 | "86"^^http://www.w3.org/2001/XMLSchema#integer
"Rhododendron ferrugineum" | http://taxref.mnhn.fr/lod/taxon/117679/12.0 | "64"^^http://www.w3.org/2001/XMLSchema#integer
"Juniperus communis subsp. communis" | http://taxref.mnhn.fr/lod/taxon/136969/12.0 | "60"^^http://www.w3.org/2001/XMLSchema#integer
"Vaccinium myrtillus" | http://taxref.mnhn.fr/lod/taxon/128345/12.0 | "58"^^http://www.w3.org/2001/XMLSchema#integer
"Festuca acuminata" | http://taxref.mnhn.fr/lod/taxon/98039/12.0 | "52"^^http://www.w3.org/2001/XMLSchema#integer
"Carex sempervirens" | http://taxref.mnhn.fr/lod/taxon/88865/12.0 | "50"^^http://www.w3.org/2001/XMLSchema#integer
"Amelanchier ovalis" | http://taxref.mnhn.fr/lod/taxon/82103/12.0 | "48"^^http://www.w3.org/2001/XMLSchema#integer
"Patzkea paniculata" | http://taxref.mnhn.fr/lod/taxon/717369/12.0 | "46"^^http://www.w3.org/2001/XMLSchema#integer
"Urtica dioica" | http://taxref.mnhn.fr/lod/taxon/128268/12.0 | "46"^^http://www.w3.org/2001/XMLSchema#integer
"Nardus stricta" | http://taxref.mnhn.fr/lod/taxon/109366/12.0 | "44"^^http://www.w3.org/2001/XMLSchema#integer
"Juniperus communis subsp. nana" | http://taxref.mnhn.fr/lod/taxon/136974/12.0 | "40"^^http://www.w3.org/2001/XMLSchema#integer
"Vaccinium uliginosum subsp. microphyllum" | http://taxref.mnhn.fr/lod/taxon/142047/12.0 | "40"^^http://www.w3.org/2001/XMLSchema#integer
"Trifolium alpinum" | http://taxref.mnhn.fr/lod/taxon/127219/12.0 | "38"^^http://www.w3.org/2001/XMLSchema#integer
"Berberis vulgaris" | http://taxref.mnhn.fr/lod/taxon/85774/12.0 | "32"^^http://www.w3.org/2001/XMLSchema#integer
"Geum montanum" | http://taxref.mnhn.fr/lod/taxon/100208/12.0 | "32"^^http://www.w3.org/2001/XMLSchema#integer
"Sorbus aucuparia" | http://taxref.mnhn.fr/lod/taxon/124308/12.0 | "32"^^http://www.w3.org/2001/XMLSchema#integer
"Betula pendula" | http://taxref.mnhn.fr/lod/taxon/85903/12.0 | "30"^^http://www.w3.org/2001/XMLSchema#integer
"Achnatherum calamagrostis" | http://taxref.mnhn.fr/lod/taxon/79970/12.0 | "24"^^http://www.w3.org/2001/XMLSchema#integer
"Carex myosuroides" | http://taxref.mnhn.fr/lod/taxon/88708/12.0 | "24"^^http://www.w3.org/2001/XMLSchema#integer
"Pinus mugo subsp. uncinata" | http://taxref.mnhn.fr/lod/taxon/138840/12.0 | "22"^^http://www.w3.org/2001/XMLSchema#integer

SI on veut maintenant avoir un classement des familles observées, on faire ceci. La relation hiérarchique en taxonomie est modélisée par rdfs:subClassOf dans TAXREF-LD . Pour le reste, regarder comment le rang taxonomique est exprimé dans n'importe quel taxon, par exemple http://taxref.mnhn.fr/lod/taxon/115110/12.0 . On a donc cette requête : 

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
prefix dsw: <http://purl.org/dsw/>
prefix dwc: <http://rs.tdwg.org/dwc/terms/>
prefix taxrefprop:  <http://taxref.mnhn.fr/lod/property/>
prefix taxrefrk:    <http://taxref.mnhn.fr/lod/taxrank/>
select ( count(?FAMILLE) AS ?count ) ?FAMILLE ?NOM
where {
  ?X dwc:taxonID ?TAXON .
  SERVICE <https://taxref.i3s.unice.fr/sparql> {
    ?TAXON rdfs:subClassOf + ?FAMILLE.
    ?FAMILLE taxrefprop:hasRank taxrefrk:Family .
    ?FAMILLE rdfs:label ?NOM .
} }  GROUP BY ?TAXON  ?NOM
ORDER BY DESC (?count)
LIMIT 20

Le + après rdfs:subClassOf signifie que l'on veut parcourir la relation sous-classe au moins une fois ou plus . Voir aussi l'article "Sortir toutes les espèces de fourmis avec TAXREF" = http://semantic-forms.cc:1952/ldp/1595512363536-12373987020911520 Hélas cette requête en version fédérée n'aboutit pas, car elle dure trop longtemps, dû aux accès réseau; il faut tout avoir sur la même base : PNE et TAXREF-LD .

Entre temps l'URL RDF PNE est redevenu actif (en fait il est intermittent) : https://geonature.ecrins-parcnational.fr/api/exports/semantic_dsw mais sur mon site ça donne SocketTimeoutException: Read timed out J'ai donc chargé les 2 Turtle à partir de fichiers téléchargés. Et alors le résultat familles est : 

"FAMILLE"   "NOM"   "count"
http://taxref.mnhn.fr/lod/taxon/187444/12.0 "Poaceae"   "254"^^http://www.w3.org/2001/XMLSchema#integer
http://taxref.mnhn.fr/lod/taxon/187311/12.0 "Rosaceae"  "202"^^http://www.w3.org/2001/XMLSchema#integer
http://taxref.mnhn.fr/lod/taxon/187379/12.0 "Ericaceae" "198"^^http://www.w3.org/2001/XMLSchema#integer
http://taxref.mnhn.fr/lod/taxon/187213/12.0 "Pinaceae"  "148"^^http://www.w3.org/2001/XMLSchema#integer
http://taxref.mnhn.fr/lod/taxon/187227/12.0 "Asteraceae"    "134"^^http://www.w3.org/2001/XMLSchema#integer
http://taxref.mnhn.fr/lod/taxon/187215/12.0 "Cupressaceae"  "104"^^http://www.w3.org/2001/XMLSchema#integer
http://taxref.mnhn.fr/lod/taxon/187235/12.0 "Fabaceae"  "102"^^http://www.w3.org/2001/XMLSchema#integer
http://taxref.mnhn.fr/lod/taxon/187488/12.0 "Cyperaceae"    "94"^^http://www.w3.org/2001/XMLSchema#integer
http://taxref.mnhn.fr/lod/taxon/187249/12.0 "Salicaceae"    "62"^^http://www.w3.org/2001/XMLSchema#integer
http://taxref.mnhn.fr/lod/taxon/187255/12.0 "Betulaceae"    "56"^^http://www.w3.org/2001/XMLSchema#integer
http://taxref.mnhn.fr/lod/taxon/187240/12.0 "Lamiaceae" "48"^^http://www.w3.org/2001/XMLSchema#integer
http://taxref.mnhn.fr/lod/taxon/187262/12.0 "Urticaceae"    "46"^^http://www.w3.org/2001/XMLSchema#integer
http://taxref.mnhn.fr/lod/taxon/187290/12.0 "Ranunculaceae" "40"^^http://www.w3.org/2001/XMLSchema#integer
http://taxref.mnhn.fr/lod/taxon/187230/12.0 "Brassicaceae"  "38"^^http://www.w3.org/2001/XMLSchema#integer
http://taxref.mnhn.fr/lod/taxon/187292/12.0 "Berberidaceae" "32"^^http://www.w3.org/2001/XMLSchema#integer
http://taxref.mnhn.fr/lod/taxon/187226/12.0 "Apiaceae"  "28"^^http://www.w3.org/2001/XMLSchema#integer
http://taxref.mnhn.fr/lod/taxon/187285/12.0 "Caryophyllaceae"   "24"^^http://www.w3.org/2001/XMLSchema#integer
http://taxref.mnhn.fr/lod/taxon/187471/12.0 "Juncaceae" "24"^^http://www.w3.org/2001/XMLSchema#integer
http://taxref.mnhn.fr/lod/taxon/187418/12.0 "Plantaginaceae"    "20"^^http://www.w3.org/2001/XMLSchema#integer
http://taxref.mnhn.fr/lod/taxon/187464/12.0 "Liliaceae" "20"^^http://www.w3.org/2001/XMLSchema#integer

A SUIVRE .

Plus tard je chargerai tout ça sur ma base SPARQL publique http://semantic-forms.cc:1952/ , et vous pourrez essayer des requêtes. Utiliser le requêteur http://yasgui.triply.cc/ avec le endpoint (service) http://semantic-forms.cc:1952/sparql .

orovellotti commented 4 years ago

Merci pour votre travail et tout ces commentaires.

1/ Modifier l’export RDF** Serait il possible d’avoir toutes les modifications à apporter and une seule issue. Je peux voir si quelqu’un chez nous peut apporter les modifications nécessaires dans une PR.

2/ Json - Ld / URI

Ca me semble être tres intéressant de penser l’architecture de l’écosystème en terme d’api exposant des URIS dereferentiable (userHub, TaxHub, geoNature, followDem ...)

Cela permettrais je pense d’éviter les manipulations de copie de données (geoNature citizen > geonature ou followDem > geonature etc ..) mais ça nécessite un très gros travail de fond sur tous ces éléments.

3/usage Je serais très curieux de savoir si il est possible de sortir de notre champs de la bidodiversite et aller lier les données médicales par exemple (pudmed)

Nous pourrions alors trouver tous les usages connus des taxons present dans un parc et démonter son utilité en terme de service ecosystemiques.

jmvanel commented 4 years ago

A SUIVRE .

Plus tard je chargerai tout ça sur ma base SPARQL publique http://semantic-forms.cc:1952/ , et vous pourrez essayer des requêtes. Utiliser le requêteur http://yasgui.triply.cc/ avec le endpoint (service) http://semantic-forms.cc:1952/sparql .

C'est fait!

orovellotti commented 3 years ago

Bonjour Jean Marc & Franck

Est ce que qu'il existe un outil équivalent au "Federated Query" SPARQL qui permettrait de requêter plusieurs API Json-LD facilement?

Nous pourrions alors envisager de faire un POC sur un GeoNature Citizen et un GeoNature par exemple ou un Follow Dem et un Citizen ?

Merci

frmichel commented 3 years ago

Bonjour Olivier, bonjour à tous,

Est ce que qu'il existe un outil équivalent au "Federated Query" SPARQL qui permettrait de requêter plusieurs API Json-LD facilement?

Peux-tu préciser ce que tu entends par "requêter plusieurs API Json-LD facilement" ?

En soit, requêter plusieurs API JSON-LD c'est comme dire que tu veux fédérer des documents RDF (qu'ils soient en Turtle, JSON-LD ou autre). Pour "requêter" il te faut un langage de requête, par exemple SPARQL.

S'il s'agit de fusionner les documents JSON-LD venant des APIs, alors ça peut se faire simplement en utilisant n'importe quelle lib JSON-LD : tu download les documents JSON-LD, tu les charges dans un triple store et tu fusionnes tout en un seul graphe.

Et sinon, les SPARQL micro-services encapsulent des API JSON (donc aussi JSON-LD) dans un endpoint SPARQL dédié. Il te reste à écrire la requête SPARQL fédérée qui  les invoque tous et fait sens de tout ça.

C'est exactement ce que je fais dans la démo : http://sparql-micro-services.org/demo-sms?param=Delphinapterus%20leucas avec les API JSON de GBIF, EoL, BHL Flickr etc.

Franck.

jmvanel commented 3 years ago

@orovellotti , c'est une bonne question; les API Json-LD sont des services hybrides: on les requête comme un API REST ordinaire, mais elles renvoient des triplets RDF.
Si ta question porte sur des outils JSON purs genre assistant de requête, je ne cultive pas de compétence particulière pour ça. @frmichel a bien dit comment faire, soit via API Javascript JSON-LD, soit son outil SPARQL microservice. Il y a aussi mon moteur JSON-LD 1.1 en service web générique: http://semantic-forms.cc:1952/json2rdf?src=http://demo.geonature.fr/geonature/api/occtax/releve/164&context=https://raw.githubusercontent.com/jmvanel/rdf-convert/master/geonature/context.jsonld

Mais rien de tout ceci ne peut marcher, car actuellement l'API GeoNature, même en lecture seule, nécessite un token, comme je l'ai signalé depuis le début.

Une remarque plus fondamentale sur les données lors d'un mashup (fusion). Pour fusionner tout en un seul graphe, et que cela aie un intérêt, il faut qu'on aie des URI communs. Or actuellement dans les données GeoNature il n'y a que les URI et ID TAXREF. On pourrait avoir en outre: des personnes observatrices, des organisations, des milieux naturels (base habref), des communes pour les observations. habref est intéressant, mais il n'est pas traduit en RDF à ma connaissance.

En conclusion je dirais c'est facile à faire, mais il faut que le projet GeoNature 1) ouvre son API 2) que ce soit du JSON-LD .

frmichel commented 3 years ago

Mais rien de tout ceci ne peut marcher, car actuellement l'API GeoNature, même en lecture seule, nécessite un token, comme je l'ai signalé depuis le début.

Une précision : je n'ai pas vérifié de quel type token il s'agît, mais dans un SPARQL microservice on peut configurer l'ajout d'entêtes http quelconques (voir exemple), voire faire une extension qui requête un service avec un clé privée pour obtenir un token puis le réutiliser plus tard etc. Le code est prévu pour permettre ce genre de hack, une sorte de plugin en plus basique.

Une remarque plus fondamentale sur les données lors d'un mashup (fusion). Pour fusionner tout en un seul graphe, et que cela aie un intérêt, il faut qu'on aie des URI communs. Or actuellement dans les données GeoNature il n'y a que les URI et ID TAXREF. On pourrait avoir en outre: des personnes observatrices, des organisations, des milieux naturels (base habref), des communes pour les observations. habref est intéressant, mais il n'est pas traduit en RDF à ma connaissance.

Je plussoie. Qui plus est, JSON-LD reste "limité" dans la mesure où on ne peut pas complètement transformer le JSON pour faire une représentation RDF différente : en gros, un champ JSON -> une propriété. Dans la réalité, JSON-LD 1.1 est un peu plus riche que cela, néanmoins on est très contraint pas le format JSON source. Du coup, aligner les URI est déjà un pb, comme l'a indiqué @jmvanel, et aligner en plus le format des différentes API vers une représentation RDF commune ou au moins compatible, est un autre problème.

Pour remédier à cela, dans les microservices, on peut appliquer un context JSON-LD et/ou une requête SPARQL construct, cette dernière nous permet de faire vraiment ce qu'on veut. C'est ce qui permet au MNHN de générer la même représentation RDF à partir des APIs de GBIF, WoRMS, Alagebase, IUCN, Tropicos, Sandre etc. : Olivier Gargominy les utilisent dans l'appli TaxrefWeb pour comparer les infos de taxonomie, habitats etc., venant de tous ces gens là à la fois (une 15aine d'API).

Franck.

camillemonchicourt commented 3 years ago

Pour l'API interne de GeoNature, elle est liée à son fonctionnement propre, après authentification. Et pas forcément taillée et optimisée pour des interrogations externes.

Par contre, le module Export est vraiment plus orienté pour cela, diffusion des données sous différentes formes et adaptables à volonté. Dans ce module, on créé des vues dans la BDD, cela génère des exports sous forme de fichier, sous forme d'API json filtrable mais aussi RDF. En effet les API du module Export sont protégés derrière une authentification (exemple : https://demo.geonature.fr/geonature/api/exports/swagger/2). Mais nous avons le besoin identifié de pouvoir définir que certaines API du module EXPORT sont ouverts et publics.

jmvanel commented 3 years ago

Je comprends que ce n'est pas facile d'ouvrir une API qui n'a pas été prévue pour. Logiquement l'API devrait offrir autant d'informations qu'un utilisateur n'ayant que des droits de lecture. Afin d'être en phase avec les Données Ouvertes Liées (LOD). Il faut vraiment qu'on en parle, qu'on fasse cette réunion dont on a parlé. Il faut savoir qui a développé le module Export, où est le code source, pour quel(s) cas d'usage, qui sont les utilisateurs, actuels et potentiels. Il a bien besoin d'être amélioré. D'autre part les 2 voies envisagées (API JSON-LD, et module Export) ne sont pas les seuls possibles par rapport au web Sémantique.

orovellotti commented 3 years ago

Nous avons eu une discussion rapide ce matin avec @amandine-sahl

Il semble que le cas des mises à jour dans plusieurs GeoNature, et a plusieurs niveaux, corresponde à besoin fort et soit un cas d'usage intéressant pour démontrer l’utilité du SEMWEB.

Le projet Filtered Push qui semble apporter des solutions à ce problème: https://wiki.filteredpush.org/wiki/User:Bob_Morris

J'aimerais votre opinion la dessus pour rédiger le challenge pour Hack4Nature en ce sens et avoir cette fameuse réunion.

Je pose ici une ontologie découverte pendant le TDWG pour information: Plinian Core is a set of vocabulary terms that can be used to describe different aspects of biological species information. Under "biological species Information" all kinds of properties or traits related to taxabiological and non-biologicalare included. Thus, for instance, terms pertaining descriptions, legal aspects, conservation, management, demographics, nomenclature, or related resources are incorporated: http://www.visualdataweb.de/webvowl/#iri=https://datos.iepnb.es/def/sector-publico/medio-ambiente/pliniancore/3.0.0

jmvanel commented 3 years ago

Pas d'avis sur https://wiki.filteredpush.org/wiki/FilteredPush, sauf que ça parait compliqué . le "cas des mises à jour dans plusieurs GeoNature, et a plusieurs niveaux" demande à être précisé ; c'est probablement évident si on connaît GeoNature ; y a -t-il une issue ?

Quand pouvez vous commencer sur l'amélioration de l'existant RDF ?

OWL Plinian : je demande à voir des données ! Personnellement je suis partisan de se lier à des URI dbPedia ou Wikidata au lieu de créer des URI comme http://datos.iepnb.es/def/sector-publico/medio-ambiente/pliniancore#Fruit qui ne sont rattachées à rien . Je veux bien une ObjectProperty pliniancore:Dispersal , avec : pliniancore:Dispersal rdfs:range pliniancore:DispersalType ( A NOTER: la propriété Dispersal devrait être en minuscule ) mais les DispersalType doivent des URI dbPedia ou Wikidata . La raison d'être des données liées c'est précisément de créer des liens.

orovellotti commented 2 years ago

Pour relancer ce sujet, je découvre aujourd'hui ce projet de Plazi avec une approche Knowledge graph.

OpenBiodiv: A Knowledge Graph for Literature-Extracted Linked Open Data in Biodiversity Science

https://www.mdpi.com/2304-6775/7/2/38/htm

Ils présenterons tout ça au TDWG.