Interrogation et visualisation des résultats

Interrogation et visualisation des résultats

 Interrogation des connaissances incertaines

Le module de traitement de requêtes est un composant essentiel d’un système de gestion de données et de connaissances. Les principaux éléments d’un tel module sont la définition d’un langage de requête déclaratif et expressif, les analyses syntaxiques et sémantiques de ces requêtes, leur exécution et la présentation des résultats. Compte tenu de son statut de recommandation du W3C et sa popularité, aussi bien au sein du grand public par le biais de SPARQL endpoints que par des plateformes de développement d’applications pour le Web Sémantique (e.g., Apache Jena, Sesame), nous avons sélectionné le langage SPARQL. Par ailleurs, l’adoption de la plateforme Apache Jena et en particulier son composant ARQ (i.e., moteur de requête SPARQL), nous permet de bénéficier de l’ensemble des opérations d’analyses, d’optimisation et d’exécution des  requêtes au travers d’appels à des APIs. Ceci, nous permet de faire abstraction des détails de l’exécution des requêtes qui imposent généralement des composants de traduction dans une algèbre, de définition des plans logiques et de l’exécution du plan physique le plus performant. À la suite de ces choix technologiques, il devient possible d’interroger en SPARQL directement nos graphes. Néanmoins, les résultats que nous obtenons avec cette approche ne nous permettent pas de considérer les aspects incertains associés aux ressources de nos graphes. En effet, notre représentation de l’incertitude a deux impacts sur notre mode de requêtage : le premier concerne l’incapacité de répercuter l’incertitude présente dans les graphes sur les résultats de la requête. Ainsi, il ne sera pas possible d’exprimer que l’élément d’un tuple d’une réponse est incertain avec un certain niveau de confiance ; le second impact est une conséquence logique du mode d’exécution des requêtes SPARQL. Celui-ci correspond à une recherche des motifs des triplets de la requête dans un graphe RDF. Cette opération permet d’associer des termes du graphe aux variables des requêtes et retourne un ensemble de tuples traduisant ces associations. Pour être satisfiables, nos requêtes doivent donc prendre en compte la topologie du graphe telle qu’obtenue après les modifications imposées par la représentation de l’incertitude. Ces modifications correspondent à l’intégration des patrons décrits dans le chapitre 3, section 3.2.2. À partir de ce constat, deux solutions se présentent à nous : 1. soit nous demandons à l’utilisateur du système de prendre en compte le graphe représentant les incertitudes pour exprimer ses requêtes ; cette solution ne nous semble pas acceptable pour les deux raisons suivantes : (i) premièrement, l’effort attendu par l’utilisateur est trop important. En effet, la définition de requêtes SPARQL à partir d’un graphe RDF est une tâche suffisamment difficile, essentiellement à cause de l’absence d’un schéma. De plus, cette tâche est rendue plus ardue par la présence de triplets supplémentaires concernant les incertitudes. (ii) deuxièmement, la perspective de générer des requêtes SPARQL de manière interactive à partir de notre représentation des graphes RDF rendrait la requête très lourde. 2. ou bien nous développons une solution automatique, dirigée par les patrons d’incertitude, ceci en réécrivant les requêtes. La solution de réécriture que nous présentons par la suite facilite donc la tâche de l’interprétation des requêtes de l’utilisateur, elle permet également de quantifier la fiabilité des tuples de l’ensemble des résultats d’une requête.

Réécriture de requêtes

Pour le moment, notre système ne prend en compte qu’un seul texte à la fois dans le mode de requêtage. Nous obtenons donc l’assurance que les graphes manipulés soient de tailles relativement réduites, i.e., des dizaines de nœuds au maximum. Nos traitements  sont alors effectués en mémoire vive et ne souffrent pas d’échanges avec les disques. Il convient de développer une approche efficace de réécriture des requêtes. Une approche naïve de cette dernière peut amener à une explosion combinatoire des blocs de la clause WHERE des requêtes SPARQL, e.g., par utilisation des mots clés UNION ou OPTIONAL. En effet, chaque triplet de la requête doit être réécrit afin de vérifier si éventuellement il y a incertitude sur chaque élément. Ceci est la conséquence de l’absence de connaissances sur les incertitudes associées aux ressources du graphe RDF et correspondants aux triplets des requêtes posées. Cette explosion combinatoire a deux effets sur le mode de requêtage : (i) les performances d’exécution se dégradent considérablement en raison de la difficulté à les optimiser, (ii) la requête devient très difficile à comprendre par l’utilisateur/administrateur car elle est bruitée par de nombreux blocs. En dirigeant la réécriture des requêtes par l’analyse des patrons d’incertitude, nous garantissons qu’une recherche efficace des triplets incertains est effectuée et qu’un minimum de blocs du type UNION est créé dans la reformulation de la requête. Notre approche se déroule en deux étapes : la première concerne les prédicats alors que la deuxième est relative aux ressources. Suivant notre modélisation RDF, il nous est possible d’isoler les cas d’incertitudes grâce aux patrons (voir le figure 3.6) définis dans le chapitre précédent. Nous remarquons que le patron #3 est le seul à modifier le lien habituel entre le sujet et son objet. Nous commençons par extraire toutes les propriétés présentes dans la requête originale et stockons ce résultat dans la liste P. Nous cherchons ensuite si ces propriétés sont associées à des incertitudes dans le graphe RDF. Cette recherche s’effectue à l’aide de la requête présentée dans le Listing 4.1 où la variable ?prop correspond à une propriété de la liste P. Cette requête permet de lister l’ensemble des triplets ayant des prédicats incertains dans le graphe RDF considéré. PREFIX gs : < http :// www . geolsemantics . com / onto # > Select ? prop Where { ? s gs : hasUncertainProp ? u . ? u gs : weight ? weight . ? u ? prop ? o . } Listing 4.1 – requête SPARQL de détection de prédicats incertains Le résultat retourne les prédicats incertains que nous stockerons dans une structure de données du type ensemble, c’est-à-dire n’acceptant pas de doublons, dénotée Ep. Si cet ensemble est vide, aucune reformulation de requête n’est nécessaire et la requête originale peut être exécutée. Dans le cas d’un ensemble non vide, pour chaque prédicat incertain issu de Ep, nous ajoutons un bloc de type UNION dans la requête utilisateur. Cette reformulation suit le motif décrit dans le Listing 4.2. À noter, que cette réécriture combine 93 Chapitre 4 – Interrogation et visualisation des résultats les résultats certains aux résultats incertains et étend la liste des variables distinguées (i.e., les variables présentes dans le résultat de la requête, i.e., de la clasue SELECT) par l’ajout d’une variable ?weight caractérisant l’incertitude des blocs UNION ajoutés. PREFIX gs : < http :// www . geolsemantics . com / onto # > Select … ? weight Where { { … ? s ? p ? o. … } UNION { … ? s gs : hasUncertainProp ? u . ? u ? p ? o. ? u gs : weight ? weight . … } } Listing 4.2 – Exemple de réécriture de requête SPARQL avec prise en compte des prédicats incertain. Une fois la requête user_query réécrite avec prise en compte des éventuels prédicats incertains, elle est exécutée. Il convient maintenant de considérer les deux autres patrons (voir la figure 3.6) impliquant une incertitude, c’est-à-dire les #1 et #2. Ceux-ci concernent les incertitudes portant sur les ressources, i.e., le sujet et l’objet d’un triplet. Pour ce faire, chaque triplet résultant est analysé indépendamment, afin de vérifier s’il y a incertitude sur les ressources. Une fois de plus, la modélisation adoptée nous permet de préciser si l’incertitude se situe au niveau du sujet ou de l’objet du triplet. En effet, la requête présentée dans le Listing 4.3 permet de vérifier si la ressource désignant le sujet du triplet est incertaine alors que la requête dans Listing 4.4 identifie les incertitudes au niveau de l’objet du triplet. À la présentation du résultat final, nous sommes donc en mesure d’indiquer s’il y a incertitude ou non, et de donner le poids associé. PREFIX gs : < http :// www . geolsemantics . com / onto # > Select ? s ? weight Where { ? s ? p ? o. ? u gs : isUncertain ?s . ? u gs : weight ? weight . } Listing 4.3 – requête SPARQL de détection de sujets incertains

Prise en compte de la confiance accordée à la source

Dans ce que nous avons présenté dans la section précédente, la confiance accordée à la source n’a pas été prise en compte, aussi nous proposons à l’utilisateur de l’inclure en option. Dans cette section, nous présentons notre approche pour calculer la fiabilité de l’information en prenant en compte le degré de confiance accordé à la source. Il est évident que les triplets incertains contenus dans le graphe de connaissances doivent prendre en compte ces paramètres. Cependant, d’autres triplets seront impactés. En particuliers les événements et les interactions entre entités nommées. Cette tâche est alors divisée en trois étapes : 1. déterminer les triplets impactés par la confiance accordée à la source. Pour cela nous nous reposons sur notre ontologie, étant donné que tous les individus de notre ?m ?p ?l ?weight idMovement1 idMarie1 idRome1 0.7 0.5 idMovement1 idJohn1 idRome1 0.5 Table 4.2 – Résultats finaux avec prise en compte des incertitudes. 97 Chapitre 4 – Interrogation et visualisation des résultats ?p ?weight idMarie1 0.35 idJohn1 0.5 Table 4.3 – Résultats finaux avec prise en compte et combinaison des incertitudes. graphe de connaissances correspondent à la description faite dans l’ontologie ; 2. vérifier si les événements décrits apparaissent dans la base de connaissances (si les faits et les événements ont déjà été insérés dans la base, ont été validés et sont sûrs). Si c’est le cas, il n’y a pas de raison de les remettre en cause. De même, la confiance accordée aux entités nommées n’a pas à être recalculée ; 3. calculer le degré de fiabilité de ces triplets. Le degré de confiance est considéré comme une métadonnée qui doit se répercuter sur l’ensemble du graphe et pas seulement, sur les enfants directs. Nous appliquons alors la même approche Bayesienne que celle décrite en section 3.3 incertitude parent/enfant. Nous multiplions le poids associé au triplet par le degré de confiance accordée à la source.