Appariement RDF : une phase de pré-selection

Afin d’améliorer la découverte en termes de pertinence et de performance, je propose de procéder en deux phases. Une première phase de pré-sélection de description sémantique basée sur un appariement RDF, ensuite, une deuxième phase d’appariement sémantique fonctionnel.

L’appariement sémantique fonctionnel est déjà présenté dans le chapitre 5. Je donne dans la suite plus d’informations concernant l’appariement RDF.

Ces deux grandes phases proposées se complètent bien qu’elles soient rattachées à deux approches différentes en termes de découverte. La première phase est caractérisée par un ap- pariement basé sur l’appariement des descriptions RDF (RDF-based Matching) entre la requête et les services Web offerts. La deuxième phase est caractérisée par un appariement basé sur les annotations sémantiques des descriptions YASAWSDL (YASA-based Matching) entre la requête et les services Web publiés.

La découverte démarre par la soumission d’une description YASAWSDL de la requête à l’an- nuaire sémantique. De son coté, le registre sémantique fonctionnel stocke des descriptions RDF. Pour réussir l’appariement entre requête et descriptions RDF, la description YASAWSDL requise est transformée en une requête RDF sémantique. Une vue globale des phases de la découverte est illustrée dans la Figure 6.11.

120 L’annuaire des services Web sémantiques

FIGURE6.11 – Vue globale des phases de la découverte.

En se basant sur les descriptions RDF stockées, vues souvent comme des graphes, je pro- pose de ne pré-sélectionner que celles qui correspondent au "graphe" de la requête. Cette pré- sélection vise à alléger la tâche d’appariement sémantique fonctionnel jugée souvent comme coûteuse. Pour cela, je construis une requête SPARQL à partir de la requête utilisateur, ensuite j’interroge la base de données des descriptions pour sélectionner uniquement les services qui m’intéressent d’un point de vue structurel.

En effet, cet appariement se base sur la ressemblance de graphes RDF. Il permet ainsi la récupération du groupe de services proches structurellement en termes d’éléments WSDL et d’annotations sémantiques puisque chacune de ces données est représentée dans le graphe RDF. Un tel choix est très important voire vital afin d’éviter de comparer la requête à tous les services Web disponibles. Une fois ce sous-ensemble de services Web sélectionnées, le match- maker sémantique fonctionnel effectue les appariements sémantiques fonctionnels nécessaires entre le YASAWSDL requis et les YASAWSDL offerts (voir Figure 6.12).

6.5 Conclusion 121

Le principe d’appariement RDF est simple : une description RDF publiée est à retenir si et seulement si son graphe couvre le graphe de la description RDF de la requête. En effet :

1. Ceci peut être exprimé en SPARQL,

2. Ceci assure que pour chaque élément de la requête, il existe un élément dans l’offre annoté sémantiquement, donc que je peux comparer dans la deuxième phase jusqu’au dernier niveau d’appariement (potentiellement jusqu’aux inputs/outputs),

3. Ceci vérifie qu’il existe au moins autant d’opérations, d’inputs et d’outputs dans l’offre que dans la demande.

Je souligne ici que parfois certains nœuds ne sont pas annotés sémantiquement dans la requête ou dans l’offre. Pour assurer la conformité de la requête, nous avons conçu un générateur de requêtes SPARQL qui prend en entrée le graphe d’une interface d’un service Web requis et retourne une requête SPARQL correspondante. La Figure 6.13 représente un exemple d’une description YASAWSDL d’une requête et la Figure 6.14 représente son code SPARQL (de la requête). 1 <wsdl:interface name="Interface1"> 2 <wsdl:operation name="Operation1" 3 serviceConcept="Effect" modelReference="confirmation" /> 4 <wsdl:operation name="Operation2" 5 pattern="http://www.w3.org/ns/wsdl/in-out"> 6 <wsdl:output messageLabel="Output1" 7 serviceConcept="Postcondition modelReference="checked""/> 8 </wsdl:operation> 9 </wsdl:interface>

FIGURE6.13 – Description YASAWSDL d’une requête.

1 PREFIX rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#> 2 PREFIX xsd:<http://www.w3.org/2001/XMLSchema#>

3 SELECT ?service 4 WHERE {

5 ?service ?r1 ?interface .

6 FILTER regex (xsd:string(?r1), "hasInterface") . 7 ?interface ?r2 ?op1 .

8 FILTER regex (xsd:string(?r2), "hasInterfaceOperation") . 9 ?interface ?r3 ?op2 .

10 FILTER regex (xsd:string(?r3), "hasInterfaceOperation") . 11 ?op2 ?r4 ?opt1 .

12 FILTER regex (xsd:string(?r4), "hasOutput") . 13 FILTER(!sameTerm(?op1,?op2))}

FIGURE6.14 – Code SPARQL de la requête.

6.5

Conclusion

Dans ce chapitre, j’ai présenté l’annuaire des services Web sémantiques. J’ai repris en détails l’architecture et les rôles de ses composants. Ensuite, j’ai présenté les phases de publication et de découverte. Des détails concernant la réalisation de cet annuaire, les expérimentations de ses performances ainsi que son intégration au sein du projet national de recherche ANR SemEUsE [91] sont les sujets de la prochaine partie de ce manuscrit.

Chapitre 7

Réalisation

Sommaire

7.1 Introduction . . . 123 7.2 Préparation d'un banc d'essai de l'approche sémantique . . . 124 7.2.1 Génération de collections de test pour la description et la découverte . . 124 7.2.2 Intégration du banc d'essai de la découverte . . . 126 7.3 Evaluations de la découverte sémantique de services Web . . . 128 7.3.1 Types d'évaluations . . . 128 7.3.2 Temps moyen de réponse aux requêtes . . . 129 7.3.3 Temps d'exécution . . . 130 7.3.4 Précision . . . 132 7.3.5 Rappel . . . 133 7.3.6 Rapport Rappel/Précision . . . 134 7.4 Exploitation de la réalisation dans un cas d'utilisation . . . 135 7.4.1 Développement de l'annuaire sémantique de services Web . . . 136 7.4.2 Déploiement de l'annuaire sémantique de services Web . . . 139 7.4.3 Cas d'utilisation : Collaboration pour résoudre une crise NRBC . . . 139 7.4.4 Intégration de l'annuaire sémantique dans l'architecture SemEUsE et

exploitation pour l'étude de cas . . . 141 7.5 Conclusion . . . 144

7.1

Introduction

La réalisation de nos contributions a été faite sur trois grandes étapes. Une première étape a été nécessaire pour concevoir et implémenter les algorithmes et les composants gérant la des- cription, le stockage et la découverte des services Web sémantiques au sein de l’architecture de l’annuaire sémantique. Une deuxième étape a consisté à préparer un banc d’essai pour l’en- semble des contributions. Et la troisième étape évalue les performances de l’appariement et la découverte de l’annuaire sémantique de services afin de valider son intégration au sein du bus de services du projet ANR SemEUsE1_{. Ce chapitre ne reprend pas les détails techniques des} développements du code source et de déploiement. Il est dédié plutôt à la présentation des dé- marches de réalisation des mécanismes et des processus pour mesurer les performances d’un système d’appariement et de découverte basé sur notre approche et d’en effectuer la mise au

1. SemEUsE : SemantiquE pour bUs de sErvices (http ://www.semeuse.org)

124 Réalisation

point et l’évaluation. Ceci nous a servi pour valider l’approche ainsi que de s’assurer que les performances soient meilleures que celles d’autres approches.

Dans ce chapitre, je présente la démarche de préparation d’un banc d’essai pour l’approche sémantique que je propose (Section 7.2). Le banc d’essai nécessite une génération de collections de test pour la description et la découverte (Section 7.2.1) et l’intégration du banc d’essai dans une plate-forme spécifique d’évaluations (Section 7.4.4). Puis, je présente les évaluations des performances de notre approche de découverte sémantique des services Web (Section 7.3). En- suite, je résume un cas d’utilisation et le travail réalisé pendant le déploiement de notre approche de découverte dans le cadre de l’annuaire sémantique de services Web (Section 7.4). Enfin, je présente une conclusion pour ce chapitre (Section 7.5).