Raisonnement (12/11/2021 & 07/12/2021)

Dans cette séance, vous allez continuer à travailler sur une trace issue de Github, mais l’objectif est maintenant de raisonner sur cette trace. Vous utiliserez le moteur d’inférences de GraphDB, et le jeu de règles qu’il fournit pour OWL2-RL.

Pour cela, nous vous fournissons une trace préalablement générée (celle du dépôt Github w3c/json-ld-syntax). L’archive contient plusieurs fichiers datés, chacun ne contenant que les éléments plus récents que le précédent. Dans les premières parties du TP, vous ne travaillerez qu’avec le fichier le plus ancien. Dans la partie Raisonnement incrémental, vous utiliserez les autres fichiers.

Rendu du TP

Vous répondrez aux questions de ce TP dans Tomuss. Normalement, vous devez voir une ligne « TP-DynCo-raisonnement » contenant des cases numérotées dans lesquelles vous pourrez entrer vos réponses. Les questions sont numérotées ci-dessous.

• Les opérations à réaliser sont indiquées dans des boîtes intitulées « Votre travail ».

• Les informations à faire figurer dans Tomuss sont indiquées dans des boîtes intitulées « Rapport ».

Ce TP est à rendre avant le 12 décembre 2021 à 23h59.

Références

• CM sur le raisonnement (et les références qu’il contient)

• Spec OWL2RL, section raisonnement

Pour démarrer :

• Téléchargez le zip situé ici

• Créez un nouveau repository dans votre instance de GraphDB, avec un ruleset OWL2RL (sans optimisation) et insérez-y les données du premier fichier contenu dans le zip (json-ld-syntax-2019-01-01.nq)

Raisonnement RDF-S

Inférences par héritage

Le modèle conceptuel de la Fig. 1 n’est pas matérialisé dans votre dataset. En particulier, les relations d’héritage entre les classes OpenIssue, ClosedIssue et Issue n’existent pas. En fait, la classe Issue elle-même n’existe pas dans votre dataset. Vous allez la créer et en déduire automatiquement les instances.

Votre travail

Exprimez, en RDF-S, le fait que ex:OpenIssue et ex:ClosedIssue dérivent de ex:Issue.

Rapport

1. Indiquez la requête SPARQL envoyée pour insérer cette information dans le dataset.

Cela doit raccrocher toutes les instances de ces 2 classes à leur classe mère. Vous allez donc les compter pour vérifier :

Votre travail

Requêtez ensuite votre dataset pour déterminer le nombre d’instances de ex:Issue présentes dans le dataset.

Rapport

2. Indiquez la requête SPARQL envoyée.

3. Indiquez le résultat obtenu.

Par ailleurs, cela doit également créer la classe ex:Issue. Vous allez essayer d’en savoir un peu plus sur cette classe :

Votre travail

Requêtez votre dataset pour déterminer les types de la ressource ex:Issue (vous allez en trouver plusieurs).

Rapport

4. Indiquez la requête SPARQL envoyée.

5. Indiquez le résultat obtenu.

6. Expliquez à quoi correspondent les différents types, et comment ils ont été obtenus.

Inférences par propriétés

Un autre moyen de déduire les types des ressources est d’analyser leurs relations dans un graphe. Les propriétés sont des indicateurs qui peuvent être utilisés dans ce but :

Votre travail

• Exprimez, en RDF-S, le fait qu’un prédicat ex:comment a pour sujet une ex:Issue.

• Exprimez, en RDF-S, le fait qu’un prédicat ex:comment a pour objet un ex:Comment.

• De la même manière, et pour toutes les autres classes dont le nom est entre parenthèses sur la Fig. 1, donnez un IRI à ces classes (dans l’espace de noms ex:) et ajoutez des contraintes sur les propriétés concernées. L’objectif est de permettre à GraphDB d’inférer le type des instances de ces classes.

Rapport

7. Indiquez la requête SPARQL envoyée pour insérer ces informations dans le dataset.

Pour vérifier :

Votre travail

Requêtez votre dataset pour déterminer le nombre de tickets, de commentaires et de labels présents dans le dataset.

Rapport

8. Indiquez les requêtes SPARQL envoyées.

9. Indiquez les résultats obtenus.

Raisonnement OWL

Expressions de classes

Dans un premier temps, vous allez rajouter quelques contraintes en OWL pour préciser la sémantique des classes et des propriétés de votre dataset :

Votre travail

• Exprimez le fait qu’une ressource ne peut pas être à la fois une instance de ex:Issue et de ex:Label.

• Exprimez le fait qu’une ex:Issue ne peut pas être à la fois ouverte et fermée.

• Définissez une classe ex:VisitorIssue, qui correspond aux tickets dont la ex:authorAssociation vaut « NONE ».

• Définissez une classe ex:VisitorOpenIssue, qui correspond aux tickets ouverts dont la ex:authorAssociation vaut « NONE ».

Rapport

10. Indiquez la requête SPARQL envoyée pour insérer cette information dans le dataset.

Raisonnement sur les classes

Vous allez maintenant utiliser ces informations supplémentaires pour déduire des connaissances de plus haut niveau, que vous pourrez par exemple utiliser pour caractériser le dataset.

Dans un premier temps, vous allez vérifier le fait que votre base ne contient pas de contradiction, par rapport aux axiomes que vous venez d’ajouter (en particulier les axiomes de disjonction). Pour cela :

Votre travail

Exécutez la requête SPARQL suivante:

PREFIX sys: <http://www.ontotext.com/owlim/system#>
INSERT DATA { [] sys:consistencyCheckAgainstRuleset "owl2-rl" }

• En cas de succès, cela signifie que votre base est cohérente et vous pouvez continuer le TP.

• En cas d’erreur, cela signifie que votre base contient des contradictions (indiquées dans le message d’erreur). Revenez en arrière pour en trouver la cause (qui peut venir d’axiomes insérés plus tôt dans le TP) et la corriger.

Vous allez maintenant comparer les résultats obtenus en requêtant votre dataset avec et sans raisonnement :

Votre travail

• Écrivez une requête SPARQL qui n’utilise pas la classe ex:VisitorIssue, listant les tickets dont la ex:authorAssiciation est « NONE ».

• Écrivez une requête SPARQL listant les instances de ex:VisitorIssue, et vérifiez que le résultat est le même.

Raisonnement sur les propriétés

Ajoutons des contraintes sur certaines propriétés.

Votre travail

• Exprimez le fait que deux ressources qui possèdent des s:url distinctes sont elles-même distinctes.

• Vérifiez (comme précédemment) que cela ne crée pas de contradiction dans la base.

Rapport

11. Indiquez la requête SPARQL envoyée pour insérer cette information dans le dataset.

De la meme manière que pour les classes, vous pouvez également créer des propriétés de plus haut niveau :

Votre travail

• Ajoutez une propriété s:contributor qui relie directement un ticket (ex:Issue) aux auteurs de ses commentaires

Rapport

12. Indiquez la requête SPARQL envoyée pour insérer cette information dans le dataset.

13. Requêtez le dataset pour connaître le nombre de contributeurs qui ont commenté des tickets « visiteurs ».

14. Indiquez le résultat obtenu.

Raisonnement incrémental

Dans cette partie, vous allez faire évoluer le dataset et observer les indicateurs mis en place dans les questions précédentes au cours du temps. Pour simuler cette évolution, vous avez à votre disposition 6 autres fichiers N-Quads générés à différentes dates. Notez que les tickets et commentaires apparaissant dans chaque fichiers sont ceux qui ont été créés ou modifiés depuis la date du fichier précédent. En particulier, un ticket peut apparaître comme ouvert dans un fichier, et apparaître comme fermé dans un fichier ultérieur.

On se place ici dans un scénario où vous voulez construire un outil de reporting vous permettant d’extraire des indicateurs sur les tickets ouverts et les plus commentés, et de les voir évoluer à travers le temps.

Votre travail

• Créez une requête SPARQL qui renvoie les informations suivantes pour toutes les ex:VisitorOpenIssue de votre dataset :

  • titre (s:name)

  • nombre de commentaires distincts

  • nombre de commentateurs distincts

• Exécutez cette requête pour chaque « évolution » de la trace. Pour simuler cette évolution, vous devez à chaque étape :

  • ajouter dans un graphe nommé http://example.org/ns#tmp le contenu du nouveau fichier N-Quads;

  • exécutez une requête SPARQL (toujours la même) qui supprime du graphe par défaut le type ex::OpenIssue de tous les tickets ayant le type ex:ClosedIssue dans le graphe nommé;

  • exécutez une requête SPARQL (toujours la même) qui insère tous les triplets du graphe nommé dans le graphe par défaut;

  • exécuter une requête SPARQL (toujours la même) qui vide le graphe nommé.

Indication

On fait ici plusieurs hypothèses simplificatrices:

• seul le type des tickets est susceptible de changer,

• un ticket fermé n’est jamais ré-ouvert.

Rapport

15. A l’aide de votre tableur préféré, construisez un graphique sur lequel vous ferez figurer, à chaque étape, les différents tickets et les nombres de commentaires pour chacune d’eux

16. A l’aide de votre tableur préféré, construisez un graphique sur lequel vous ferez figurer, à chaque étape, les différents tickets et les nombres de commentateurs pour chacune d’eux

17. Eventuellement, vous pouvez vous fendre d’une conclusion que vous inspirent ces graphiques