search

assemblee-virtuelle / semapps

A toolbox to create semantic web applications
https://semapps.org
Apache License 2.0
87 stars 8 forks source link

Avoir une complétion sur wikidata #43

Closed GuillaumeAV closed 2 years ago

GuillaumeAV commented 5 years ago

Un enjeu majeur. Wikipedia est une base de connaissance planétairement utilisée et reconnue comme faisant autorité. Elle peut constituer un tiers de confiance. Si nous faisons tous référence aux URIs Wikidata / DBpedia pour taguer nos contenus, alors nous créerons des liens entre nos données par delà les systèmes d'informations, par delà les langues, par delà les continents. Et nous permettrons la construction de requêtes sparql sur des systèmes d'information liés et potentiellement fédérés. Alors il deviendra possible de se passer de Google pour trouver ce que l'on cherche ;-)

tfrancart commented 4 years ago

D'expérience dans Sparnatural, une autocompletion directement sur Wikidata est difficillement faisable du fait des problèmes de performance actuels du service Wikidata.

Voilà le thread où j'avais posé la question à Wikidata : https://lists.wikimedia.org/pipermail/wikidata/2019-October/013573.html, avec quelques pistes d'implémentation techniques, en attaquant directement l'API Mediawiki sous-jacente.

DBpedia fonctionne mieux.

srosset81 commented 4 years ago

Pour le meetup du 20 mai, nous allons faire un premier test de lier des données depuis l'interface React-Admin. Il suffira d'ajouter l'URL de l'endpoint SPARQL dans les configurations du data provider.

srosset81 commented 3 years ago

Information de @GuillaumeAV:

Pour DBPedia, voici le service qu'on utilisait dans SemApps v1 : https://wiki.dbpedia.org/lookup POur wikidata, la doc de l'API peut être utile ? https://www.wikidata.org/w/api.php

srosset81 commented 3 years ago

Conclusion du jour:

tfrancart commented 3 years ago

Laissez tomber DBPedia et concentrez-vous sur Wikidata. Wikidata a un champ de recherche avec autocompletion qui fonctionne bien, cela doit être exposé par une API. Ca me semblerait à première vue plus simple de développer un composant custom branché sur l'API de wikidata que de réindexer tout Wikidata dans un ElasticSearch;

Le mar. 5 janv. 2021 à 16:46, Sébastien Rosset notifications@github.com a écrit :

Conclusion du jour:

  • DbPedia Lookup (suggéré par @GuillaumeAV https://github.com/GuillaumeAV) ne marche plus. Wikidata est à jour.
  • Faire une requête SPARQL sur Wikidata c'est compliqué et surtout ça peut demander beaucoup de temps.
  • Solution la plus simple: passer par Elasticsearch. On pourrait indexer tout Wikidata avec un outil comme https://github.com/MoritzGoeckel/Wikidata-to-ElasticSearch (à intégrer éventuellement comme un service Moleculer). Ensuite on pourrait faire les même requêtes Elasticsearch que pour les autres instances SemApps.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/assemblee-virtuelle/semapps/issues/43#issuecomment-754718109, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAU2H4JBCZVB4XTTKVZ5HWLSYMX5RANCNFSM4JK37TQQ .

--

Thomas Francart - SPARNA Web de données | Architecture de l'information | Accès aux connaissances blog : blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/thomasfrancart tel : +33 (0)6.71.11.25.97, skype : francartthomas

srosset81 commented 3 years ago

Merci @tfrancart ! Effectivement les requêtes par API sur Wikidata semblent très rapides, cela ne semble pas nécessaire de réindexer tout sur Elasticsearch. https://www.wikidata.org/w/api.php?action=wbsearchentities&format=json&language=fr&type=item&search=s%C3%A9mantique https://www.wikidata.org/w/api.php?action=wbgetentities&format=json&ids=Q39645

D'autres problèmes se posent néanmoins autour de la complétion Wikidata. Actuellement quand on va sur une ressource SemApps, on récupère toutes les données (propriétés et relations) via un simple appel GET à l'API LDP. Pour une données Wikidata, cela ne sera pas possible car, pour une compétence (par exemple), on ne pourra pas récupérer immédiatement les données des utilisateurs sur l'instance qui ont cette compétence.

Il faudrait potentiellement faire une requête SPARQL sur tous les triples qui ont pour objet la donnée Wikidata, puis déterminer la relation inverse. C'est possible mais cela va demander à ce que React-Admin fasse une requête SPARQL plutôt qu'un simple GET sur une ressource LDP, lorsque l'on détermine que la ressource est une donnée Wikidata.

tfrancart commented 3 years ago
  1. Un moyen simple serait d'importer au moment de l'install la liste de compétences de Wikidata pour les charger dans les données, comme ça on fonctionne tout en local, sans développement custom (mais désynchronisé de Wikidata, quite à resynchroniser périodiquement)
  2. Autre idée qui me vient : avoir un paramètre ou un élément de config qui indique qu'une certaine propriété dans l'ontologie prend ses valeurs dans (une certaine classe de) Wikidata, de façon à déclencher à la fois une recherche et un affichage custom pour la valeur de cette propriété

Le mer. 6 janv. 2021 à 00:23, Sébastien Rosset notifications@github.com a écrit :

Merci @tfrancart https://github.com/tfrancart ! Effectivement les requêtes par API sur Wikidata semblent très rapides, cela ne semble pas nécessaire de réindexer tout sur Elasticsearch.

https://www.wikidata.org/w/api.php?action=wbsearchentities&format=json&language=fr&type=item&search=s%C3%A9mantique

https://www.wikidata.org/w/api.php?action=wbgetentities&format=json&ids=Q39645

D'autres problèmes se posent néanmoins autour de la complétion Wikidata. Actuellement quand on va sur une ressource SemApps, on récupère toutes les données (propriétés et relations) via un simple appel GET à l'API LDP. Pour une données Wikidata, cela ne sera pas possible car, pour une compétence (par exemple), on ne pourra pas récupérer immédiatement les données des utilisateurs sur l'instance qui ont cette compétence.

Il faudrait potentiellement faire une requête SPARQL sur tous les triples qui ont pour objet la donnée Wikidata, puis déterminer la relation inverse. C'est possible mais cela va demander à ce que React-Admin fasse une requête SPARQL plutôt qu'un simple GET sur une ressource LDP, lorsque l'on détermine que la ressource est une donnée Wikidata.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/assemblee-virtuelle/semapps/issues/43#issuecomment-754961345, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAU2H4MBYN6GCX4337AORGTSYONONANCNFSM4JK37TQQ .

--

Thomas Francart - SPARNA Web de données | Architecture de l'information | Accès aux connaissances blog : blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/thomasfrancart tel : +33 (0)6.71.11.25.97, skype : francartthomas

srosset81 commented 3 years ago

Solution trouvée suite à 2h de réunions aujourd'hui avec @simonLouvet:

On va garder une référence vers la source, via deux types de prédicats:

(Nom précis des prédicats à brainstormer, ainsi que l'ontologie qui sera inventée ou reprise)

La resource locale (p.ex. https://data.virtual-assembly.org/skills/webdev) est considérée comme une ressource "augmentée", qui contient des données mappées sur Wikidata et des données locales. Elle pourrait ressembler à ça:

{
  "@context": "...",
  "@id": "https://data.virtual-assembly.org/skills/webdev",
  "synchronizedWith": "https://www.wikidata.org/wiki/Q386275", // URI de la source
  "pair:label": "programmation web", // Donnée mappée sur wikidata
  "pair:description": "type de développement de logiciel", // Donnée mappée sur wikidata
  "pair:hasSkill": "https://data.virtual-assembly.org/users/srosset" // Donnée locale
}

Saisie de nouvelles données

Lorsqu'on fait une recherche sur un champ avec complétion Wikidata, on appelle l'API de Wikidata (cf. ci-dessus). On soumets au serveur un ou plusieurs URIs Wikidata.

On pourrait éventuellement utiliser un middleware Moleculer pour transformer les données avant qu'elles n'atteignent l'action ldp.resource.post (si c'est possible, ce serait bien d'utiliser le même mécanisme pour l'upload des fichiers)

L'autre option, sans doute plus simple, serait d'importer tous les éléments de Wikidata concernant, par exemple, les compétences. Mais il faut voir si c'est possible et de quelle manière. @tfrancart tu le mentionnais comme une solution, as-tu un exemple de requête qui permettrait de retourner toutes les ressources "compétence" sur Wikidata ?

Avantages

Il y a plusieurs avantages à cette solution:

(Je laisse reposer ça le weekend et je verrai la semaine prochaine si je vais dans plus de détails de spécification)

GuillaumeAV commented 3 years ago

C'est génial tout ça !!!!!

Le ven. 19 févr. 2021 à 19:20, Sébastien Rosset notifications@github.com a écrit :

Solution trouvée suite à 2h de réunions aujourd'hui avec @simonLouvet https://github.com/simonLouvet:

On va garder une référence vers la source, via deux types de prédicats:

  • synchronizedWith: pour indiquer que les donnes de la ressources sont synchronisées avec la source.
  • forkedFrom: pour indiquer que les données ont été importées mais qu'elles ont depuis été modifiées

(Nom précis des prédicats à brainstormer, ainsi que l'ontologie qui sera inventée ou reprise)

La resource locale (p.ex. https://data.virtual-assembly.org/skills/webdev) est considérée comme une ressource "augmentée", qui contient des données mappées sur Wikidata et des données locales. Elle pourrait ressembler à ça:

{

"@context": "...",

"@id": "https://data.virtual-assembly.org/skills/webdev",

"synchronizedWith": "https://www.wikidata.org/wiki/Q386275", // URI de la source

"pair:label": "programmation web", // Donnée mappée sur wikidata

"pair:description": "type de développement de logiciel", // Donnée mappée sur wikidata

"pair:hasSkill": "https://data.virtual-assembly.org/users/srosset" // Donnée locale }

Saisie de nouvelles données

Lorsqu'on fait une recherche sur un champ avec complétion Wikidata, on appelle l'API de Wikidata (cf. ci-dessus). On soumets au serveur un ou plusieurs URIs Wikidata.

  • Si le serveur détecte qu'une ressource dans le triple store a déjà cette URI comme source, il transforme l'URI vers l'URI de la ressource augmentée (https://www.wikidata.org/wiki/Q386275 => https://data.virtual-assembly.org/skills/webdev)
  • Si le serveur ne détecte aucune ressource avec cette URI comme source, il l'importe en mappant les données wikidata sur les données PAIR (selon un mécanisme à définir). L'inférence service s'occupera d'ajouter le lien inverse (pair:hasSkill dans notre exemple).

On pourrait éventuellement utiliser un middleware Moleculer pour transformer les données avant qu'elles n'atteignent l'action ldp.resource.post (si c'est possible, ce serait bien d'utiliser le même mécanisme pour l'upload des fichiers)

L'autre option, sans doute plus simple, serait d'importer tous les éléments de Wikidata concernant, par exemple, les compétences. Mais il faut voir si c'est possible et de quelle manière. @tfrancart https://github.com/tfrancart tu le mentionnais comme une solution, as-tu un exemple de requête qui permettrait de retourner toutes les ressources "compétence" sur Wikidata ?

Avantages

Il y a plusieurs avantages à cette solution:

  • On respecte le principe du web sémantique, car on ne fait pas une copie de données en changeant l'URI.
  • On garde une trace claire de la source des données. Cela peut permettre à des logiciels de trouver toutes les ressources "augmentées" qui font référence à la même donnée Wikidata.
  • On peut être en mode "synchronisation", ou on peut aussi décider de les modifier si on en a besoin (on passe alors en mode "fork", avec le prédicat forkedFrom au lieu de synchronizedWith). Il y aurait un joli travail à faire au niveau UX pour indiquer à l'utilisateur qu'en modifiant une ressource, elle ne sera plus synchronisée avec la ressource d'origine.
  • Il sera facile de créer un service qui recherche toutes les ressources qui ont le label synchronizedWith et qui regarde si les données sources ont été mises à jour.
  • On pourrait utiliser le même principe de synchronisation avec d'autres types de données que l'on veut synchroniser (Gogocarto, YesWiki), sans avoir à gérer des systèmes d'imports/webhooks parfois coûteux. Cela pourrait aussi permettre de synchroniser des données avec d'autres serveur SemApps (?)

(Je laisse reposer ça le weekend et je verrai la semaine prochaine si je vais dans plus de détails de spécification)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/assemblee-virtuelle/semapps/issues/43#issuecomment-782251511, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABO75HCIGJ3HN2WAPQABDBDS72TWNANCNFSM4JK37TQQ .

srosset81 commented 3 years ago

@tfrancart @GuillaumeAV @simonLouvet

J'essaie de m'occuper aujourd'hui de plus spécifier ce chantier. J'ai cependant une première remarque à chaud: les données de Wikidata me semblent très pauvres. La description d'une ressource Wikidata se limite à une petite ligne.

Par exemple pour web developement, on a juste "type de développement de logiciel". Pour gestion de projet, on a "initiation, la planification, le contrôle et le contrôle et la réalisation de projets" (le français n'est même pas bon).

Il y a plein de liens sémantiques vers d'autres ressources (par exemple practiced by) mais je ne sais pas à quel point on va pouvoir en faire usage.

Il me semble que DbPedia était plus riche, en tout cas les données importées sur SemApps v1 l'étaient.

Du coup je me demande à quel point ces données vont être pertinentes en terme d'usage... Cela va éviter de créer des données arbitraires, mais en terme d'enrichissement de données, ça va être léger.

L'essentiel de la solution qu'on n'a trouvée n'est pas liée à Wikidata en particulier: elle permet de synchroniser des données où qu'elles soient. Donc je peux quand même avancer sur ce point...

GuillaumeAV commented 3 years ago

Huum c'est chelou tout de même ... Ca vaudrait le coup de contacter Maxime Lathuillères, un ami et expert de wikidata, à l'origine de https://inventaire.io qui est basé dessus. Le wiki https://wiki.inventaire.io/wiki/Main_Page d'inventaire.io vaut le détour, de même que la présentation de la stack https://inventaire.github.io/stack/, dans laquelle on trouve leur implémentation en node.js d'un module wikidata https://meta.wikimedia.org/wiki/Grants:Project/Maxlath/WikidataJS. Je me demande s'il n'y a pas tout ce qu'il faut d'ailleurs !! Maxime : max@maxlath.eu

Le jeu. 11 mars 2021 à 05:46, Sébastien Rosset notifications@github.com a écrit :

@tfrancart https://github.com/tfrancart @GuillaumeAV https://github.com/GuillaumeAV @simonLouvet https://github.com/simonLouvet

J'essaie de m'occuper aujourd'hui de plus spécifier ce chantier. J'ai cependant une première remarque à chaud: les données de Wikidata me semblent très pauvres. Contrairement à DbPedia qui inclus un ou plusieurs paragraphes de description, la description Wikidata se limite à une petite ligne.

Par exemple pour web developement https://www.wikidata.org/wiki/Q386275, on a juste "type de développement de logiciel". Pour gestion de projet https://www.wikidata.org/wiki/Q179012, on a "initiation, la planification, le contrôle et le contrôle et la réalisation de projets" (le français n'est même pas bon).

Il y a plein de liens sémantiques vers d'autres ressources (par exemple practiced by) mais je ne sais pas à quel point on va pouvoir en faire usage.

Du coup je me demande à quel point ces données vont être pertinentes en terme d'usage... Cela va éviter de créer des données arbitraires, mais en terme d'enrichissement de données, ça va être léger. Il me semble que DbPedia était plus riche, en tout cas les données importées sur SemApps v1 l'étaient.

L'essentiel de la solution qu'on n'a trouvée n'est pas liée à Wikidata en particulier: elle permet de synchroniser des données où qu'elles soient. Donc je peux quand même avancer sur ce point...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/assemblee-virtuelle/semapps/issues/43#issuecomment-795276116, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABO75HDRB26LQI4FZLXM6HLTC5JGBANCNFSM4JK37TQQ .

-- Guillaume Rouyer +33 (0)6 28 34 54 99 http://assemblee-virtuelle.orghttp://virtual-assembly.org

https://www.facebook.com/grouyer https://twitter.com/Guillaume_AV

tfrancart commented 3 years ago

Non c'est tout à fait normal. Il n'y a pas de descriptions détaillées dans Wikidata, juste des libellés, des synonymes, et de micro-définitions, tout cela en multilingue. Et des assertions bien sûr. Mais pas de description "encyclopédique" et textuelle comme Wikipedia. Wikidata est fait pour de la data structurée. Ceci dit il est possible de rebondir dans une requête entre Wikidata et l'entrée correspondancte dans DBPedia... mais c'est un peu de gymnastique.

Pour faire de l'autocompletion basique ca peut néanmoins suffire, il faut tester.

Thomas

Le jeu. 11 mars 2021 à 09:10, Guillaume @.***> a écrit :

Huum c'est chelou tout de même ... Ca vaudrait le coup de contacter Maxime Lathuillères, un ami et expert de wikidata, à l'origine de https://inventaire.io qui est basé dessus. Le wiki https://wiki.inventaire.io/wiki/Main_Page d'inventaire.io vaut le détour, de même que la présentation de la stack https://inventaire.github.io/stack/, dans laquelle on trouve leur implémentation en node.js d'un module wikidata https://meta.wikimedia.org/wiki/Grants:Project/Maxlath/WikidataJS. Je me demande s'il n'y a pas tout ce qu'il faut d'ailleurs !! Maxime : @.***

Le jeu. 11 mars 2021 à 05:46, Sébastien Rosset @.***> a écrit :

@tfrancart https://github.com/tfrancart @GuillaumeAV https://github.com/GuillaumeAV @simonLouvet https://github.com/simonLouvet

J'essaie de m'occuper aujourd'hui de plus spécifier ce chantier. J'ai cependant une première remarque à chaud: les données de Wikidata me semblent très pauvres. Contrairement à DbPedia qui inclus un ou plusieurs paragraphes de description, la description Wikidata se limite à une petite ligne.

Par exemple pour web developement <https://www.wikidata.org/wiki/Q386275 , on a juste "type de développement de logiciel". Pour gestion de projet https://www.wikidata.org/wiki/Q179012, on a "initiation, la planification, le contrôle et le contrôle et la réalisation de projets" (le français n'est même pas bon).

Il y a plein de liens sémantiques vers d'autres ressources (par exemple practiced by) mais je ne sais pas à quel point on va pouvoir en faire usage.

Du coup je me demande à quel point ces données vont être pertinentes en terme d'usage... Cela va éviter de créer des données arbitraires, mais en terme d'enrichissement de données, ça va être léger. Il me semble que DbPedia était plus riche, en tout cas les données importées sur SemApps v1 l'étaient.

L'essentiel de la solution qu'on n'a trouvée n'est pas liée à Wikidata en particulier: elle permet de synchroniser des données où qu'elles soient. Donc je peux quand même avancer sur ce point...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/assemblee-virtuelle/semapps/issues/43#issuecomment-795276116 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABO75HDRB26LQI4FZLXM6HLTC5JGBANCNFSM4JK37TQQ

.

-- Guillaume Rouyer +33 (0)6 28 34 54 99 http://assemblee-virtuelle.orghttp://virtual-assembly.org

https://www.facebook.com/grouyer https://twitter.com/Guillaume_AV

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/assemblee-virtuelle/semapps/issues/43#issuecomment-796551838, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAU2H4OERQYG6GHPCUUHXNDTDB3HXANCNFSM4JK37TQQ .

--

Thomas Francart - SPARNA Web de données | Architecture de l'information | Accès aux connaissances blog : blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/thomasfrancart tel : +33 (0)6.71.11.25.97, skype : francartthomas

GuillaumeAV commented 3 years ago

@srosset81 @simonLouvet Est-ce qu'il y a eu des mises à jour sur la spec autour de ce chantier ?

srosset81 commented 3 years ago

Non. Je continue à réfléchir à ces prédicats synchronizedWith et forkedFrom, notamment pour s'assurer que le code pourra être utilisé dans le plus grand nombre de cas.

Je me suis dit (pas plus tard que cette nuit !) que ça pourrait être aussi un bon moyen de copier des ressources d'un SemApps à un autre. Lorsqu'on crée une ressource, on pourrait choisir, soit de la créer à partir de zéro, soit d'indiquer un URI d'une ressource existant sur une autre instance SemApps (ou sur la même instance, si ça peut avoir du sens). On aurait alors le choix entre deux modes de copie: Synchronisation ou Fork (à voir comment on l'explicite pour l'utilisateur lambda). On aurait ainsi quelque chose un peu similaire à l'import de profile de SemApps v1, sauf que l'import pourrait resté synchronisé avec l'original (à moins qu'on soit en mode fork...)

GuillaumeAV commented 3 years ago

Oui c'est tip top ça ! Préoccupé quoique content que ca t'occupe ton esprit la nuit ;)

srosset81 commented 3 years ago

Quelques remarques suite à une réunion avec @simonLouvet aujourd'hui: