Analyse sémantique et transformation de graphe

Pour réaliser les tests suivants, un ensemble de fichiers RDF a été généré. Dans ces derniers, les sujets d’intérêts de chaque personne sont établis de manière

aléa-1. https://github.com/owlcs/owlapi

2. https://github.com/protegeproject/swrlapi

3. https://github.com/protegeproject/swrlapi-drools-engine 4. http://jfact.sourceforge.net/

4.1. Temps de réponse des composants et performance 91

toire. Les sujets et les lieux en lien avec les contenus sont établis de manière aléatoire aussi afin d’obtenir des ensemble de données variables.

Les expériences ont été conduites avec un nombre de passagers variable (10 à 60, capacité maximale du bus), différents nombre de contenus à diffuser (10 à 100) et différents nombres de sujet d’intérêt possibles (de 10 à 50). Le nombre de lieux possibles a été fixé à 25 pour ces tests.

Les différentes données extraites de ces expériences sont présentées en Figure 4.1 et Figure 4.2. Le temps de réponse moyen y est présenté en fonction du nombre de passagers du bus (avec un nombre de sujets d’intérêt fixé dans le premier cas, et variable dans le second cas).

Le temps de réponse pour l’inférence sémantique est montrée en bleu foncé. Le temps de réponse de la partie graphe est montré en orange pour le temps de géné-ration du graphe à partir de l’ontologie et en gris pour le temps de transformation du graphe.

4.1.2.1 Analyse du temps de réponse pour une variation de nombre de contenus à diffuser

Si l’on s’intéresse au temps de réponse de la partie purement sémantique, dif-férents point sont à considérer. Tout d’abord, il faut noter que plus le nombre de contenus à gérer à la fois augmente, plus le temps de réponse augmente proportion-nellement. Cela est dû à la complexité à gérer pour déterminer quel contenu devrait être diffusé pour quelles entités. En effet, plus il y a de contenus à considérer à la fois dans le système, plus les éléments liés à considérer (lieux, sujets d’intérêt) sont nombreux et vont ralentir le traitement.

D’un autre côté, le temps de réponse de la partie graphe (relativement à la transformation, la génération ayant un temps presque négligeable par rapport au reste) augmente proportionnellement au nombre d’entités à gérer (ici il s’agit des passagers et du bus). En effet, pour un ensemble de contenus donné et de sujets d’intérêt liés, le temps de réponse de la transformation de graphe augmente de moins de 250 ms en moyenne (Figure 4.1a) jusqu’à un peu plus de 2 s quand il y a 100 contenus à diffuser en un seule fois et dans le pire cas (Figure 4.1c). Cela est dû au besoin d’agréger plus de contenus étant donné que potentiellement il y a plus de personnes intéressées par le même type de contenu dans ce cas précis. De plus, cette opération est prise en charge par une couche de règles qui sera répétée jusqu’à non applicabilité. De fait, plus y a de contenu à agréger plus le temps de réponse va augmenter car la règle s’appliquera plus de fois.

Le pire cas dans la Figure 4.1c prend au total jusqu’à presque 3,5 secondes pour s’exécuter avec 60 passagers considérés et 100 contenus à diffuser à la fois. Dans ce cas précis, environ 5340 axiomes sont considérés dans l’ontologie et le graphe RFC à transformer contient plus de 500 éléments. Cependant, il faut noter que dans le cas d’utilisation considéré dans cette thèse, de tels nombre ne devraient pas être atteints : la diffusion de plus de 50 contenus à la fois (en une seule itération) sur ter-minal d’affichage saturerait complètement les utilisateurs. Une possibilité serait de

(a) 10 contenus (b) 50 contenus

(c) 100 contenus

Figure 4.1 – Temps de réponse moyen basé sur le nombre de passagers pour diffé-rents nombres de contenus à diffuser en même temps (10 / 50 / 100)

multiplier les terminaux d’affichage qui afficheraient en parallèle plusieurs contenus, mais même dans ce cas-là, il serait difficile d’afficher plus de 50 contenus différents à la fois. De plus, ce cas extrême dans les résultats est atteint en considérant une seule et unique boucle du système autonomique. Cependant, le système est sensé effectuer des boucles en permanence de manière autonome et devrait prendre les décisions avant que de tels nombres soient atteints.

4.1.2.2 Analyse du temps de réponse pour une variation du nombre de sujets d’intérêt

De plus, il est intéressant de remarquer un autre comportement du système dans d’autres cas comme présenté en Figure 4.2.

4.1. Temps de réponse des composants et performance 93

(a) 10 contenus (b) 100 contenus

Figure 4.2 – Temps de réponse moyen basé sur le nombre de passagers pour dif-férents nombres de contenus à diffuser (10 et 100) en fonction du nombre de sujets d’intérêt possibles

En effet, même si en moyenne sur tous les tests le pire cas peut prendre jusqu’à 3,5 secondes (cf. Figure 4.1c), si l’on se concentre sur un cas en particulier où il y a 100 contenus à diffuser pour 60 passagers et que l’on considère non pas le nombre de passagers mais le nombre de sujets d’intérêts possibles dans le système ; on observe un comportement différent du système et notamment de la grammaire de graphes. Le temps de réponse dans ce cas – et particulièrement celui de la transformation de graphe – peut prendre jusqu’à 5,8 secondes en moyenne pour 10 sujet d’intérêts possibles là où avec 50 sujets d’intérêts possibles le système ne prendra qu’en moyenne 2,5 secondes à s’exécuter (cf. Figure 4.2b).

Ce comportement peut être expliqué par le mode d’application nécessaire des règles de la grammaire de graphes utilisée. En effet, les règles de la grammaire sont appliquées par couches de règles ce qui implique que tant qu’une règle peut s’ap-pliquer, les règles suivantes ne seront pas appliquée et cela peut ralentir le système qui ne peut appliquer qu’une seule couche de règles à la fois. De fait, quand il y a peu de sujets d’intérêts, le système se retrouve à agréger potentiellement beau-coup de contenus : la transformation de graphe détermine quels contenus envoyer au terminal du bus et quels contenus envoyer individuellement. Et donc, dans ce cas le nombre de contenus à diffuser étant élevé avec 10 sujets d’intérêt possibles, il y aura potentiellement une proportion significative de passagers intéressés par le même contenu, ce qui entraîne une transformation longue car il faut faire le lien entre ce contenu et toutes les entités ou presque.

consi-déré (50 par exemple), le temps de réponse moyen de la partie graphe diminue grandement (environ 1,5 secondes contre plus de 4,5 secondes auparavant) (Fi-gure 4.2b). Cela est dû au fait qu’il y a une plus grande diversité de sujets d’intérêt et que donc le contenu agrégé sera moins important à cause d’une plus grande diversité d’intérêts chez les passagers.

On peut également observer cette tendance dans le cas où l’on ne diffuse que 10 contenus à la fois (4.2a) mais dans une moindre mesure étant donné que le temps de réponse global demeure autour de 1,5 secondes en moyenne.

4.1.3 Analyse du temps de réponse dans une gestion complexe de