Merci de cette dépêche sur ces sujets plutôt en retrait dans ces lieux, si ce n'est Thomas Dᴏᴜɪʟʟᴀʀᴅ qui en parle régulièrement pour nous instruire sur la vie de WikiData. Je vais aller un peu hors sujet de la dépêche et pousser quelques grognements à partir des extraits infra.
[...] ce domaine et la recherche autour ont dans un premier temps donné naissance à des technologies normalisées par le W3C [...]
[...] est un langage qui ressemble beaucoup à SQL, dont il reprend d'ailleurs des mots clés et des constructions, étendu pour pouvoir gérer des relations qui ne sont pas définies à la manière des schémas de données SQL classiques [...]
[... SPARQL] délègue ainsi le typage des données qu'il manipule à RDF et RDFS. [...] Il y aurait beaucoup à dire sur le typage dans le web sémantique, mais c'est hors cadre de cet article. Ça concerne la notion d'ontologie formelle, et les couches plus hautes de la pile du web sémantique comme OWL et les moteurs d'inférences. Ces couches rajoutent la possibilité de faire des schémas de données plus avancées, et la possibilité de déduire des triplets qui ne sont pas explicites dans le dépôt grâce à des règles logiques.
Ça dévisse
En creusant un peu divers documents traitant du Web Sémantique (WS), il devient apparent que la communauté autour souhaite vivement attirer les individus habitués au WWW. La perspective de passer d'une toile de pages à une toile d'URIs ne manque pas de fringuant, un de ses effets de bord coïncidant avec les thèmes souvent abordés ici pourrait être la sortie de la googlisation rampante. Toutefois, il me semble que les dévs. SQL n'ont pas massivement migré vers SPARQL, au contraire, ce dernier reste un langage confidentiel si l'on se fie à une pifométrie comme celle-ci : plus de 365 kilo-questions versus environ 3 kilos. Il n'y aurait même pas la possibilité de mettre cette disproportion (perçue) sur le dos de la jeunesse, les initiatives de normalisation du WS ayant débuté quelques années après celles sur le WWW.
Tout cela pour en arriver à un ensemble de questions qui me taraudent et que j'aimerais poser à vous qui êtes plus au fait de ce qui se fait dans le WS.
Est-ce justifié de continuer à chercher de « faciliter la vie » aux aficionados du SQL ? Si oui, pourquoi faire et pour quoi faire ?
Pourquoi se trimbaler un système de typage qui est, si ce n'est bancal, volontairement bridé alors que si l'on pousser à fond du côté des ontologies, on pourrait augmenter significativement son expressivité ?
Est-ce la même volonté de louvoyer vers des « dévs. standards » qui est derrière la monoculture Java qui semble régner dans ce milieu ? Dès qu'on examine l'outillage, on ne manquera sans doute pas de remarquer que les outils Java se sont taillés une part de lion dans le WS.
Hors-sujet approfondi
Bien que les logiques de description soient déjà limitées, notamment par rapport aux logiques d'ordres supérieurs, il est étonnant de voir un langage comme OWL encore réduit dans ses implémentations pratiquement à son sous-ensemble compatible avec la Programmation Orientée Objet. Là où il serait légitime de s'attendre à ce qu'un tel langage soit implémenté dans des langages plus ou moins proches de son cadre théorique1, on se retrouve avec une API officielle déclinée en Java. Lorsqu'un contributeur de ladite API s'interroge à haute voix s'il ne faudrait pas accorder sa chance au monde hors JVM, il se heurte à un silence assourdissant.
Lors de mes premiers pas dans les ontologies, c'était enthousiasmant d'apprendre que l'on pourrait vérifier la cohérence d'une base de connaissances de façon complètement automatique, qu'on se permettrait de lâcher un moteur d'inférence sur un amas de triplets afin d'observer de la connaissance cachée émerger. Quelques temps après, déchanter n'était pas si difficile, ayant constaté, comme tant d'autres, qu'on passe surtout un temps non-négligeable à contourner les plus de 220 kilo-classes de l'API d'OWL pour la faire dialoguer correctement avec des outils souvent codés en C++. Finalement, le fait que WikiData décide de ne pas s'entêter dans cette direction n'est pas si paradoxal.
Pour parer à la traditionnelle rengaine du « code la fonctionnalité manquante par toi-même », j'admets tout de go mon incompétence. C'est dans ce sens que les efforts que font les personnes derrière WikiData sont vraiment admirables. D'ailleurs en tentant de jouer avec l'exemple de la dépêche à l'aide de quelques paquets codés en Haskell, on se rend compte de l'étendue du parcours que ces derniers ont encore à faire : le nœud RDF de WikiData est accessible en TLS, la page pointée par un http:// étant redirigée vers un https:// ; normal dirait-on, on est en 2017 après tout. Sauf que le paquet Haskell qui gère les nœuds RDF utilise actuellement une implémentation du HTTP qui date du début des années 2000 ne supportant pas le HTTPS. Le contournement que j'avais imaginé était de passer par DBpedia dont le nœud passe en HTTP mais son jeu de données ne semble pas englober tout WikiData. Ce qui m'amène à d'autres questions :
au niveau de leurs backends, quelle est la différence entre WikiData et DBpedia ?
on lit dans le texte que « [sur WikiData], on n'en est pas du tout » porté vers OWL et des inférences ; pourquoi alors le schéma du graphe de WikiData comporte des choses comme celles de l'extrait ici-bas ?
Pour mémoire, la tentative en Haskell évoquée plus haut est celle-ci :
{-# LANGUAGE OverloadedStrings #-}importDatabase.HSparql.ConnectionimportDatabase.HSparql.QueryGeneratormain::IO()main=do(Justt)<-selectQuery"http://dbpedia.org/sparql"selectFatherlessprinttselectFatherless::QuerySelectQueryselectFatherless=dowdt<-prefix"wdt"(iriRef"http://www.wikidata.org/entity/")person<-varfather<-varconcept<-varlang<-var-- Cette ligne retourne un graphe vide probablement parce que-- les arcanes de DBpedia diffèrent de celles de WikiData.-- S'il y avait eu des résultats, filtrer les nœuds blancs aurait été une formalité.-- _ <- triple person (wdt .:. "P22") father-- On se rabat sur cette ligne pour explorer la notion de « patternel » dans diverses langues._<-triple(wdt.:."P22")conceptlang-- L'exhaustivité n'est pas requise.limit100returnSelectQuery{queryVars=[concept,lang]}
Échantillon de sorties :
"Vater""de""father""en""その項目は主題に対し男性の親""ja"-- Pour les amateurs du kan'ji qui postent de temps en temps ici...."isä""fi"-- Pour mupuf (voir http://www.mupuf.org/blog/2016/11/07/learning-finnish/)..."père""fr"..."lien familial, parent direct de sexe masculin""fr""male parent""en"..."Papa""fr"...
Pour voir jusqu'où on peut aller avec des outils versatiles, se référer par exemple à Swish de G. Klyne dans cet article qui date, certes mais dont l'intuition est des plus actuelles.
Voir par exemple dans les archives ici, là ou là-bas. ↩
# De l'art de râler
Posté par gipoisson . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 10. Dernière modification le 02 janvier 2017 à 11:20.
Sommaire
Merci de cette dépêche sur ces sujets plutôt en retrait dans ces lieux, si ce n'est Thomas Dᴏᴜɪʟʟᴀʀᴅ qui en parle régulièrement pour nous instruire sur la vie de WikiData. Je vais aller un peu hors sujet de la dépêche et pousser quelques grognements à partir des extraits infra.
Ça dévisse
En creusant un peu divers documents traitant du Web Sémantique (WS), il devient apparent que la communauté autour souhaite vivement attirer les individus habitués au WWW. La perspective de passer d'une toile de pages à une toile d'URIs ne manque pas de fringuant, un de ses effets de bord coïncidant avec les thèmes souvent abordés ici pourrait être la sortie de la googlisation rampante. Toutefois, il me semble que les dévs. SQL n'ont pas massivement migré vers SPARQL, au contraire, ce dernier reste un langage confidentiel si l'on se fie à une pifométrie comme celle-ci : plus de 365 kilo-questions versus environ 3 kilos. Il n'y aurait même pas la possibilité de mettre cette disproportion (perçue) sur le dos de la jeunesse, les initiatives de normalisation du WS ayant débuté quelques années après celles sur le WWW.
Tout cela pour en arriver à un ensemble de questions qui me taraudent et que j'aimerais poser à vous qui êtes plus au fait de ce qui se fait dans le WS.
Hors-sujet approfondi
Bien que les logiques de description soient déjà limitées, notamment par rapport aux logiques d'ordres supérieurs, il est étonnant de voir un langage comme OWL encore réduit dans ses implémentations pratiquement à son sous-ensemble compatible avec la Programmation Orientée Objet. Là où il serait légitime de s'attendre à ce qu'un tel langage soit implémenté dans des langages plus ou moins proches de son cadre théorique1 , on se retrouve avec une API officielle déclinée en Java. Lorsqu'un contributeur de ladite API s'interroge à haute voix s'il ne faudrait pas accorder sa chance au monde hors JVM, il se heurte à un silence assourdissant.
Lors de mes premiers pas dans les ontologies, c'était enthousiasmant d'apprendre que l'on pourrait vérifier la cohérence d'une base de connaissances de façon complètement automatique, qu'on se permettrait de lâcher un moteur d'inférence sur un amas de triplets afin d'observer de la connaissance cachée émerger. Quelques temps après, déchanter n'était pas si difficile, ayant constaté, comme tant d'autres, qu'on passe surtout un temps non-négligeable à contourner les plus de 220 kilo-classes de l'API d'OWL pour la faire dialoguer correctement avec des outils souvent codés en C++. Finalement, le fait que WikiData décide de ne pas s'entêter dans cette direction n'est pas si paradoxal.
Pour parer à la traditionnelle rengaine du « code la fonctionnalité manquante par toi-même », j'admets tout de go mon incompétence. C'est dans ce sens que les efforts que font les personnes derrière WikiData sont vraiment admirables. D'ailleurs en tentant de jouer avec l'exemple de la dépêche à l'aide de quelques paquets codés en Haskell, on se rend compte de l'étendue du parcours que ces derniers ont encore à faire : le nœud RDF de WikiData est accessible en TLS, la page pointée par un
http://étant redirigée vers unhttps://; normal dirait-on, on est en 2017 après tout. Sauf que le paquet Haskell qui gère les nœuds RDF utilise actuellement une implémentation du HTTP qui date du début des années 2000 ne supportant pas le HTTPS. Le contournement que j'avais imaginé était de passer par DBpedia dont le nœud passe en HTTP mais son jeu de données ne semble pas englober tout WikiData. Ce qui m'amène à d'autres questions :Fin de l'aparté
Pour mémoire, la tentative en Haskell évoquée plus haut est celle-ci :
Échantillon de sorties :
Pour voir jusqu'où on peut aller avec des outils versatiles, se référer par exemple à Swish de G. Klyne dans cet article qui date, certes mais dont l'intuition est des plus actuelles.
Voir par exemple dans les archives ici, là ou là-bas. ↩