Enrichissement sémantique du nom de la ressource

5.2.4. Enrichissement sémantique du nom de la ressource

Les ressources partagées par le peer sont principalement les fichiers. Dans le chapitre précédent (Cf. Chapitre 4), nous avons donnés une description de ce concept. Dans un système P2P, Le nom du fichier constitue l’élément de base pour le processus de recherche et d’intégration. Afin de traiter une requête extérieure, plusieurs approches accomplissent une transformation des requêtes envoyées par les autres peers. Cela permet d’avoir une nouvelle requête traitable par le peer. Cette approche assure les correspondances sémantiques entre les différentes requêtes des peers, et permet de traiter la requête, à condition que le mapping local le permette. (Cf. figure V.9.(a)).

contexte du P2P actuel. Nous avons vu que les plateformes de partage des fichiers utilisent des techniques de localisation et de recherche qui se basent essentiellement sur le nom du fichier (Cf. Chapitre 2). La transformation de requête au niveau de chaque peer ne permet guère de bénéficier de toutes ces techniques qui font le succès de ce paradigme. Au contraire, cela pousse à proposer pour chaque nouvelle approche, une nouvelle technique de recherche et de localisation.

Notre solution dans ce point consiste à enrichir les noms des fichiers, plutôt que la transformation des requêtes reçues. Chaque nom du fichier est modifié selon le mapping local. Le nouveau nom est utilisé directement par la plateforme en cours. Cela permet de bénéficier de toutes les plateformes existantes et de garder les techniques de localisation sans modification. (Cf. figure V.9.(b)).

Figure V.9 : Différence entre la transformation de requête et l’enrichissement

La méthode Enrichissement_Noms () est responsable de l’établissement de l’enrichissement sémantique. L’algorithme d’enrichissement est une variante de celui de la transformation de requête. La différence réside dans le déclenchement et l’effet final. L’enrichissement intervient lors de la mise à jour du mapping. Contrairement, la transformation de requête utilisateur s’effectue au moment de l’envoi de la requête. Le résultat final de l’enrichissement est un nouveau nom de fichier. Cela permet d’avoir en permanence des noms enrichis avec la dernière mise à jours du mapping. L’algorithme suivant présente la méthode d’enrichissement des noms de fichiers.

Entrée : NFi nom initial d’un fichier Sortie : NFE nom enrichi d’un fichier Soit VTI le vecteur des termes initiaux Soit VTF le vecteur des termes finaux Début

// Préparation du tableau des termes initiaux VTI ← Extraction_Termes (NFi)

Pour chaque terme t ∈ VTI faire Début

Equivalent = SimTermes (t, Domaine) Ajouter_Termes(Equivalent, VTF) Fin Pour

//Elimination de redondance dans le vecteur VTF ; // VTFi ≠VTFj

Enlever_Redondance(VTF)

//Création du nouveau nom enrichi NFE ←’ ’

Pour chaque terme t ∈ VTF faire

NFE = NFE + ‘_’ + t // composition des termes finaux Fin Pour

NFE = NFE +’_’+ Domaine Sauvegarder le nouveau nom Mise à jour du profil.

Fin

L’aspect dynamique du composant Intégrateur comprend plusieurs scénarios d’exécution possibles. Seulement, le scénario le plus important est celui de l’exécution d’une requête utilisateur. Ce scénario intervient à plusieurs niveaux et fait participer l’ensemble des mécanismes évoqués. La figure V.10 présente le diagramme UML

Interaction Overview qui modélise ce scénario.

6. CONCLUSION

L’intégration de données dans un contexte P2P nécessite une adaptation spéciale qui permet la prise en charge des caractéristiques de ce paradigme. Bien que plusieurs approches soient proposées dans ce sens, chacune d’elles présente des lacunes qui influent sur la solution proposée. Pour cela, nous avons considéré dans ce chapitre une extension de l’architecture de peer en ajoutant un composant dédié à l’intégration. Ce composant fournit deux nouveaux services, à savoir, la navigation entre les plateformes et l’intégration des ressources. Dans notre approche, les peers peuvent naviguer entre des plateformes hétérogènes. En plus, les peers collaborent afin de créer dynamiquement le mapping sémantique. Ce dernier est nécessaire pour la transformation de requêtes. L’approche collaborative est associée à un modèle de confiance complexe qui améliore considérablement la prise de décision dans la gestion du mapping.

Notre approche a l’avantage de prendre en charge les caractéristiques du paradigme P2P en assurant une intégration complète des ressource et des plateformes hétérogènes. En effet, l’ontologie et le composant Peer Intégrateur ont permis de remédier les problèmes d’intégration sémantiques, tout en gardant les spécificités du contexte du P2P.

Figure V.10 : L’exécution d’une requête utilisateur

Aspects techniques pour l’implantation et étude de cas

1. INTRODUCTION

Le passage entre les phases de modélisation et de réflexion théorique vers le codage final de l’application constitue l’aboutissement du travail. Il est très important de faire un choix judicieux des technologies à utiliser et des techniques de programmation les plus adaptées au contexte. Cette implémentation permet aussi de valider la contribution proposée en l’appliquant dans une étude de cas appropriée.

Dans ce chapitre, nous nous focalisons sur deux principaux axes : 1) Les aspects techniques de l’implantation de notre contribution. 2) L’application de l’approche dans une étude de cas.

Nous commençons par présenter rapidement les technologies utilisées, à savoir,

XML, SOAP, l’environnement de développement et les frameworks spécialisées telle

que Jena pour la gestion de l’ontologie OWL .Ces aspects sont importants dans la mise en œuvre du prototype de l’application. Ensuite, nous proposons une étude de cas dans le cadre de l’intégration des ressources torrents dans un système P2P multi plateformes. Nous proposons d’utiliser notre application Torrent Integrator afin qu’on puisse couvrir les points importants de notre contribution. Cela permet de montrer l’apport de notre contribution dans ce contexte. Dans chaque étape de l’étude de cas, nous présentons le fonctionnement réel des méthodes ainsi que des portions de code sources pour plus d’éclaircissement. Le chapitre se termine par une conclusion.