U N MODÈLE D AGENT SÉMANTIQUE - Les Thèses de l'INSA de...

NO D’ORDRE 2010-ISAL-9999 ANNÉE 2010

THÈSE

UN MODÈLE D’AGENT SÉMANTIQUE.

APPLICATION AUX COMMUNAUTÉSVIRTUELLES DE CONNAISSANCES.Présentée devant :L’Institut National des Sciences Appliquées de LyonPour obtenir :Le grade de docteurSpécialité :InformatiqueFormation doctorale :Informatique

École doctorale :InfomathsPar :Julien SUBERCAZE

SOUTENANCE DEVANT LE JURY SUIVANT :

Olivier BOISSIER, Professeur des universités, ENS Mines de Saint-Etienne . . . . . . . . . . . . . . . . . . . RapporteurFabien GANDON, Chargé de recherche HDR, INRIA Sophia-Antipolis . . . . . . . . . . . . . . . . . . . . . . . . .RapporteurPierre MARET, Professeur des Universités, Université de Lyon . . . . . . . . . . . . . . . . . . . . . . . . Directeur de thèseJacques CALMET, Professeur des Universités, Université de Karlsruhe . . . . . . . . . . . . . . . . . . . . . . ExaminateurChristo EL MORR, Professeur des Universités, York University . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ExaminateurBernard ESPINASSE, Professeur des Universités, Université d’Aix Marseille . . . . . . . . . . . . . . . . . ExaminateurFrédérique LAFOREST, Mcf. HDR, Université de Lyon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examinateur

Laboratoire d’InfoRmatique en Image et Systèmes d’information

À Loane

Avant-propos

Remerciements

En premier lieu je tiens à remercier Pierre qui a su me diriger tout au long de cettethèse. De Karlsruhe à Lyon en passant par de nombreux autres endroits, cette thèse auraété un voyage agréable en ta compagnie. C’est avec un très grand plaisir que j’ai travailléà tes côtés.

Une mention particulière à Romain, pour ces années de partage de bureau et desoirées. Je tiens aussi à remercier Adrien et Johan pour ces séminaires en équipe, aussiintéressant scientifiquement que personellement.

Je remercie Christo pour son accueil chaleureux et pour nos discussions passion-nantes autour d’un capuccino second cup ou d’une andouillette lyonnaise. Je souhaiteremercier Jacques Calmet pour m’avoir fait découvrir le monde de la recherche. Je re-mercie aussi Pravin et toute l’équipe du Telemedecine group de l’université de Twentepour cette collaboration enrichissante. Je n’oublie pas non plus tous les gens avec qui j’aieu l’occasion de travailler tout au long de cette thèse, notamment tous mes collègues dudépartment informatique de l’UJM et du LaHC. Je remercie aussi les rapporteurs pourles critiques constructives et les améliorations du manuscrit.

Je pense aussi bien évidemment à ma famille, que je n’ai pas eu l’occasion de voiraussi souvent que je l’aurais souhaité pendant ces années de thèse. A tous mes amis,François (×2), Marc-Antoine, Yoann-Nicolas, Cédric et tous les autres, pour ces soiréeslyonnaises, parisiennes ou bretonnes.

Je remercie aussi Dunhill, les cafetières Krups, Yves Simon, Boris Vian, les Doors etMagma. Leur soutien indéfectible m’a permis de mener à terme cette rédaction. Merciaussi aux nombreux pots de thèses du LIRIS ainsi qu’au ministère de l’enseignementsupérieur et de la recherche pour son soutien financier.

Pour conclure, un très grand merci à Loane pour m’avoir subi et soutenu pendanttoute la rédaction de ce manuscrit.

6

Résumé

LA gestion des connaissances regroupe de nombreuses techniques visant à identifier,transmettre, créer, représenter, organiser les connaissances au sein d’une organi-

sation. L’avènement des supports numériques et de l’informatique a très largementcontribué à l’essor de cette discipline. Les supports numériques permettent comme tousles supports classiques (écriture, imprimerie) la copie et la transmission de l’information,mais la révolution entraînée par ces supports est dûe tout d’abord au faible espace destockage qu’ils nécessitent, et enfin surtout par la possibilité de traitement automatiquedes informations qu’ils contiennent. Suite à l’avènement de l’informatique dans lesorganisations au cours des années 70, puis plus largement dans les années 80, s’estposé le problème de comment gérer, organiser et transmettre toutes les informationsqui étaient désormais disponibles numériquement et sur lesquelles les machines étaientcapables d’effectuer des traitements. C’est le début de la gestion des connaissances ausens moderne du terme.

La gestion des connaissances est une discipline à la frontières de multiples domainestels que les sciences sociales, les sciences cognitives, l’informatique et les sciences ettechnologies de l’information. Dans le cadre de cette thèse, notre domaine d’étudese restreint à l’approche mécaniste de la gestion des connaissances, qui considère laconnaissance comme étant un élément qui peut être traité automatiquement par uneunité de calcul, donc de manière mécanique.

Les outils de gestion des connaissances ont longtemps suivi une approche centralisée,comparable à celle de l’informatique. En quelques décennies, l’ordinateur personnel estvenu compléter les mainframes et autres puissants serveurs, sans toutefois les remplacertotalement ; de la même manière, la gestion décentralisée des connaissances est venuecontrebalancer l’hégémonie des approches centralisées.

Les travaux récents dans le domaine la gestion décentralisée des connaissances baséesur le paradigme agent ont posé les jalons d’une nouvelle branche de la gestion desconnaissances, dont les spécificités notables, par rapport à l’approche centralisée, sont laprise en compte de la nature distribuée et de l’aspect social de la connaissance au seindes organisations. C’est sur ce paradigme multi-agent que se baseront nos travaux.

Dans cette thèse, nous allons tout d’abord analyser les fondements théoriques de lagestion des connaissances, en analysant les différentes définitions de la connaissancequi y sont employées. Nous montrons que les définitions de la connaissance qui sous-tendent les systèmes de gestion de connaissances, centralisés comme décentralisés nesont pas compatibles avec une approche mécaniste de la gestion des connaissances.Pour résoudre ce problème, nous proposons de nous baser sur une définition de laconnaissance issue du domaine de l’épistémologie, qui au-delà d’un cadre formel plusstrict, permet d’introduire la notion de connaissance empirique au sein des agents.

7

Ensuite nous mettons en application cette définition de la connaissance au sein d’uneapproche multi-agent en déterminant les composants requis par les agents pour sup-porter cette représentation. La difficulté réside dans la définition du modèle d’agent quidevra supporter les deux types de connaissances, empiriques et justifiables. A cette fin,nous proposons une représentation des connaissances basée sur la logique en tirant partides avancées dans le domaine du web sémantique. Les standards du web sémantiqueOWL-DL et SWRL possèdent de solides fondements logiques et nous montrons qu’ilssont parfaitement adaptés à nos besoins de représentation. OWL-DL supporte des rai-sonnements en monde ouvert qui sont plus en phase avec les connaissances humaineset nous utilisons le langage de règles SWRL qui permet de manipuler des concepts OWLet nous permettra d’exprimer les connaissances empiriques.

Nous définissons le modèle d’agent et présentons une implémentation que nous illus-trons au travers d’exemples. Afin d’illustrer notre approche, nous utilisons ce modèlepour y intégrer un mécanisme de transmission des connaissances. Nous nous plaçonspour cela dans un contexte de partage des connaissances que sont les VKC ou commu-nautés virtuelles de connnaissances. Notre proposition se situe donc à la frontière detrois domaines que sont la gestion des connaissances, les systèmes multi-agents et leweb sémantique.

8

Notes

Table des matières

Avant-propos 5Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Table des matières . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1 Introduction 17

2 Scénarios motivants 212.1 Communautés virtuelles de connaissances . . . . . . . . . . . . . . . . . 252.2 Scénario 1 : Assistants personnels . . . . . . . . . . . . . . . . . . . . . . . 312.3 Scénario 2 : Communautés virtuelles mobiles . . . . . . . . . . . . . . . . 392.4 Scénario 3 : Projet DRPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3 Etat de l’art 593.1 Connaissances et gestion des connaissances . . . . . . . . . . . . . . . . . 613.2 Représentation des connaissances et Web Sémantique . . . . . . . . . . . 713.3 Agents et Systèmes multi-agents . . . . . . . . . . . . . . . . . . . . . . . 843.4 Analyse et mise en perspective . . . . . . . . . . . . . . . . . . . . . . . . 1223.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

4 Un modèle d’agents sémantiques 1354.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1374.2 Programmation des agents . . . . . . . . . . . . . . . . . . . . . . . . . . . 1404.3 Structure de contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1454.4 Représentation des connaissances empiriques . . . . . . . . . . . . . . . . 1484.5 Exécution d’un scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1494.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

5 Communautés Virtuelles de Connaissances à base d’agents 1555.1 Conception de l’ontologie . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

10 TABLE DES MATIÈRES

5.2 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1685.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

6 Implémentation 1756.1 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1776.2 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1786.3 Exécution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1816.4 Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1836.5 Base de connaissances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1896.6 Conclusion et discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

7 Conclusion 1937.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1967.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

A Annexe : Ontologie 199

A.1 Ontologie sous forme d’expression . . . . . . . . . . . . . . . . . . . . . . 201A.2 Ontologie au format N3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

B Annexe : Langages de communication agents 209Langages de communication agents

B.1 Langages de programmation agents . . . . . . . . . . . . . . . . . . . . . 211

C Annexe : Liste des publications 213

Bibliographie 231

Table des figures

2.1 Diagramme de classe simplifié des agents . . . . . . . . . . . . . . . . . . 302.2 Description du framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.3 Foot pressure sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.4 Interface utilisateur de l’agent personnel . . . . . . . . . . . . . . . . . . . 382.5 Communication entre les agents . . . . . . . . . . . . . . . . . . . . . . . 382.6 Modèle économique pour les communautés virtuelles mobiles . . . . . . 412.7 Vue globale de la plate-forme technique . . . . . . . . . . . . . . . . . . . 442.8 Vue d’ensemble des composants de la plate-forme collaborative . . . . . 502.9 Création d’une nouvelle communauté . . . . . . . . . . . . . . . . . . . . 512.10 Un membre choisissant la visibilité de ses documents, soit pour des

membres ou pour des communautés . . . . . . . . . . . . . . . . . . . . . 522.11 Edition des mots-clés après extraction . . . . . . . . . . . . . . . . . . . . 532.12 Un membre choisissant la visibilité de ses documents, soit pour des

membres ou pour des communautés . . . . . . . . . . . . . . . . . . . . . 54

3.1 Processus d’extraction de connaissances mettant en exergue l’abstraction[SILVENT03] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.2 Approche distribuée de la gestion de connaissance [Bonifacio02a] . . . . 703.3 Les différentes couches du Web Sémantique . . . . . . . . . . . . . . . . . 763.4 Un agent dans son environnement [Wooldridge99] . . . . . . . . . . . . 863.5 Architecture BDI [Georgeff89] . . . . . . . . . . . . . . . . . . . . . . . . . 923.6 Critères d’analyse des structures internes des agents . . . . . . . . . . . . 953.7 Diagramme de flot des agents AGENT-0 [Shoham91] . . . . . . . . . . . 973.8 Architecture JASDL ([Klapiscak09]) . . . . . . . . . . . . . . . . . . . . . . 1003.9 Cycle délibératif des agents 3APL [Hindriks99] . . . . . . . . . . . . . . 1023.10 Squelette d’un agent 3APL . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033.11 Architecture des agents dans S-APL [Katasonov08] . . . . . . . . . . . . 1043.12 Architecture du système Nuin [Dickinson03] . . . . . . . . . . . . . . . . 1063.13 Plate-forme FIPA : Architecture abstraite . . . . . . . . . . . . . . . . . . . 1083.14 Architecture de la plate-forme JADE . . . . . . . . . . . . . . . . . . . . . 1083.15 Modèle Sémantique des agents dans AgentOWL . . . . . . . . . . . . . . 1103.16 Architecture globale de SEAGENT . . . . . . . . . . . . . . . . . . . . . . 1113.17 Sociétés pour la gestion de la mémoire [Gandon02] . . . . . . . . . . . . 113

12 TABLE DES FIGURES

3.18 Composants principaux de KEx [Bonifacio03] . . . . . . . . . . . . . . . . 1153.19 Processus de décision des agents dans CONOISE [Norman04] . . . . . . 1163.20 Architectures interne et externe de ABITS [Capuano00] . . . . . . . . . . 1193.21 Composants nécessaires aux agents pour la mise en œuvre des connais-

sances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1283.22 Rôles du raisonneur selon les types de connaissances . . . . . . . . . . . 129

4.1 Architecture des agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1384.2 EBNF du langage interprété. Ce langage est un sous ensemble de SWRL 1424.3 Actions selon les couches de l’architecture . . . . . . . . . . . . . . . . . 1444.4 Interpréteur des agents, inspiré de [Shoham91] . . . . . . . . . . . . . . . 1454.5 Ontologie résultante de l’architecture . . . . . . . . . . . . . . . . . . . . . 1474.6 Ontologies des agents : hiérarchie des actions . . . . . . . . . . . . . . . . 1484.7 Exemple illustratif (a), Scénario . . . . . . . . . . . . . . . . . . . . . . . . 1504.8 Exemple illustratif (b), Structure de données de la séquence d’actions . . 1514.9 Exemple illustratif (c), Flux de la transition de l’état sDebut vers l’état A 152

5.1 Execution de envoyerMessage dans la communauté c0 . . . . . . . . . . . . 1605.2 Diagrame de séquence du protocole envoyerMessage de la communauté 0 1615.3 Relation ternaire, impossible à représenter en OWL . . . . . . . . . . . . 1635.4 Introduction de la classe AP, pour représenter la relation rp . . . . . . . . 1635.5 Exemple : utilisation des communautés virtuelles de connaissances. Sé-

quence d’actions transmise par Carmen à Julio . . . . . . . . . . . . . . . . 1725.6 Exemple : diagramme des messages échangés par les agents lors de l’exé-

cution du scénario sur la plate-forme JADE . . . . . . . . . . . . . . . . . 173

6.1 Diagramme de classe d’un agent . . . . . . . . . . . . . . . . . . . . . . . 1796.2 Diagramme de séquence de l’initialisation d’un agent . . . . . . . . . . . 1826.3 Diagramme d’activité UML des agents . . . . . . . . . . . . . . . . . . . . 1846.4 Diagramme de classes des actions . . . . . . . . . . . . . . . . . . . . . . 188

Liste des tableaux

3.1 Représentation des connaissances dans JASON . . . . . . . . . . . . . . . 983.2 Comportement des agents dans JASON . . . . . . . . . . . . . . . . . . . 993.3 Représentation des connaissances dans JASDL . . . . . . . . . . . . . . . 1013.4 Comportement des agents dans JASDL . . . . . . . . . . . . . . . . . . . 1013.5 Représentation des connaissances dans Argonaut . . . . . . . . . . . . . 1013.6 Comportement des agents dans Argonaut . . . . . . . . . . . . . . . . . . 1023.7 Représentation des connaissances dans 3APL . . . . . . . . . . . . . . . . 1033.8 Comportement des agents dans 3APL . . . . . . . . . . . . . . . . . . . . 1033.9 Représentation des connaissances dans S-APL . . . . . . . . . . . . . . . 1053.10 Comportement des agents dans S-APL . . . . . . . . . . . . . . . . . . . . 1053.11 Représentation des connaissances dans Nuin . . . . . . . . . . . . . . . . 1053.12 Comportement des agents dans Nuin . . . . . . . . . . . . . . . . . . . . 1063.13 Représentation des connaissances dans JADE . . . . . . . . . . . . . . . . 1093.14 Comportement des agents dans JADE . . . . . . . . . . . . . . . . . . . . 1093.15 Représentation des connaissances dans AgentOWL . . . . . . . . . . . . 1103.16 Comportement des agents dans AgentOWL . . . . . . . . . . . . . . . . . 1103.17 Représentation des connaissances dans SEAGENT . . . . . . . . . . . . . 1113.18 Comportement des agents dans SEAGENT . . . . . . . . . . . . . . . . . 1123.19 Représentation des connaissances dans CoMMA . . . . . . . . . . . . . . 1143.20 Comportement des agents dans CoMMA . . . . . . . . . . . . . . . . . . 1143.21 Représentation des connaissances dans KEx . . . . . . . . . . . . . . . . . 1163.22 Comportement des agents dans KEx . . . . . . . . . . . . . . . . . . . . . 1163.23 Représentation des connaissances dans CONOISE-G . . . . . . . . . . . 1173.24 Comportement des agents dans CONOISE-G . . . . . . . . . . . . . . . . 1173.25 Représentation des connaissances dans les systèmes d’EIAH . . . . . . . 1203.26 Comportement des agents dans les systèmes d’EIAH . . . . . . . . . . . 1203.27 Représentation des connaissances dans Bibster . . . . . . . . . . . . . . . 1213.28 Comportement des agents dans Bibster . . . . . . . . . . . . . . . . . . . 1213.29 Récapitulatif des représentations des connaissances . . . . . . . . . . . . 1233.30 Récapitulatif des comportments agents . . . . . . . . . . . . . . . . . . . 124

B.1 Paramètres des messages FIPA ACL . . . . . . . . . . . . . . . . . . . . . 212

Liste des définitions

3.1 La connaissance, selon Platon . . . . . . . . . . . . . . . . . . . . . . . . . 623.2 La connaissance, selon Johnson . . . . . . . . . . . . . . . . . . . . . . . . 643.3 La connaissance, selon Davenport et Prusak . . . . . . . . . . . . . . . . . 643.4 Raisonneur correct et complet . . . . . . . . . . . . . . . . . . . . . . . . . 833.5 Agent, définition faible de Wooldrigde et Jennings . . . . . . . . . . . . . 853.6 Agent, définition forte de Wooldrigde et Jennings . . . . . . . . . . . . . 853.7 Agent , définition de Jennings, Wooldridge et Sycara . . . . . . . . . . . . 853.8 Agent rationnel, définition de Russell et Norvig . . . . . . . . . . . . . . 86

1Introduction

18 Chapitre 1. Introduction

LES modèles de réprésentation des connaissances des agents logiciels sont principale-ment basés sur une approche technologique. Dans le but de revenir à une définition

épistémologique de la connaissance distinguant connaissance empirique et justifiable,nous proposons un modèle d’agent qui maintient cette définition au niveau techniqueen s’appuyant sur les outils du web sémantique.

La gestion des connaissances regroupe de nombreuses techniques visant à identifier,transmettre, créer, représenter, organiser les connaissances au sein d’une organisation.L’avènement des supports numériques et de l’informatique a très largement contribué àl’essor de cette discipline. Les supports numériques permettent comme tous les supportsclassiques (écriture, imprimerie) la copie et la transmission de l’information, mais larévolution entraînée par ces supports est dûe tout d’abord au faible espace de stockagequ’ils nécessitent, et enfin surtout par la possibilité de traitement automatique des infor-mations qu’ils contiennent. Suite à l’avènement de l’informatique dans les organisationsau cours des années 70, puis plus largement dans les années 80, s’est posé le problèmede comment gérer, organiser et transmettre toutes les informations qui étaient désormaisdisponibles numériquement et sur lesquelles les machines étaient capables d’effectuerdes traitements. C’est le début de la gestion des connaissances au sens moderne duterme.

La gestion des connaissances est une discipline à la frontières de multiples domainestels que les sciences sociales, les sciences cognitives, l’informatique et les sciences ettechnologies de l’information. Dans le cadre de cette thèse, notre domaine d’étudese restreint à l’approche mécaniste de la gestion des connaissances, qui considère laconnaissance comme étant un élément qui peut être traité automatiquement par uneunité de calcul, donc de manière mécanique.

Les premiers systèmes de gestion des connaissances, plus connus sous le nom deKMS (pour Knowledge Management System en anglais), sont apparus vers la fin des années70. Le premier outil de Ron Acksyn et Don McCracken datant de 1978 [Barclay97].Les outils de gestion des connaissances ont longtemps suivi une approche centralisée,comparable à celle de l’informatique. En quelques décennies, l’ordinateur personnel estvenu compléter les mainframes et autres puissants serveurs, sans toutefois les remplacertotalement ; de la même manière, la gestion décentralisée des connaissances est venuecontrebalancer l’hégémonie des approches centralisées.

L’approche décentralisée de la gestion des connaissances a émergé grâce aux re-cherches dans le domaine de l’informatique qui l’ont précédées. En effet l’approchedécentralisée de la gestion des connaissances se base notamment sur le paradigme dessystèmes multi-agents qui est apparu à la fin des années 80 [Ferber89] (bien que lesprincipes des SMA soient connus dès les années 70, mais non formalisés tels quels[Wooldridge09]). Plus de 10 ans plus tard, les acteurs du domaine gestion des connais-sances décentralisées se basant sur le paradigme des systèmes multi-agent se réunis-

19

saient pour la première édition du workshop AMKM (Agent Mediated KnowledgeManagement [van Elst04a]) lors de la conférence AAAI en 2003.

Les travaux présentés dans cette série de conférence posent les jalons d’une nouvellebranche de la gestion des connaissances, dont les spécificités notables, par rapport àl’approche centralisée, sont la prise en compte la nature distribuée et de l’aspect socialde la connaissance au sein des organisations. C’est sur ce paradigme multi-agent que sebaseront nos travaux. Le domaine des systèmes multi-agents englobe de nombreusesdisciplines (Intelligence artificielle distribuée, simulation, négociation, coordination)

Dans cette thèse, nous présentons tout d’abord le cadre des communautés virtuellesde connaissances (VKC) qui sont un outil décentralisé d’échanges de connaissances entreagents autonomes. Nous introduisons le cadre théorique des VKC puis trois scénariosd’application de ces communautés. Nous analysons ensuite les limitations rencontréesdans ces travaux pour définir le cadre de notre problématique concernant l’échange detous les types de connaissances des agents, en particulier celles éxécutables.

Nous étudions les fondements théoriques de la gestion des connaissances, en analy-sant les différentes définitions de la connaissance qui y sont employées. Nous montronsque les définitions de la connaissance qui sous-tendent les systèmes de gestion deconnaissances, centralisés comme décentralisés ne sont pas compatibles avec une ap-proche mécaniste de la gestion des connaissances. Pour résoudre ce problème, nousproposons de nous baser sur une définition de la connaissance issue du domaine del’épistémologie, qui au-delà d’un cadre formel plus strict, permet contrairement aux ap-proches existantes [Bonifacio03, Ehrig03, Laclavik06b] d’introduire la notion de connais-sance empirique au sein des agents et de faire le lien avec la notion de connaissancesexécutables. Parallèlement nous étudions les architectures d’agent afin de mettre enlumière les limitations induites par la conception des agents concernant l’échange desconnaissances.

Ensuite nous mettons en application cette définition de la connaissance dans desagents sémantiques en nous aidant de l’analyse précédente concernant les architecturesd’agent.. La difficulté réside dans la définition du modèle d’agent qui devra supporter lesdeux types de connaissances, empiriques et justifiables. A cette fin, nous proposons unereprésentation des connaissances basée sur la logique en tirant parti des avancées dansle domaine du web sémantique. Les standards du web sémantique OWL-DL et SWRLpossèdent de solides fondements logiques et nous montrons qu’ils sont parfaitementadaptés à nos besoins de représentation. OWL-DL supporte des raisonnements enmonde ouvert qui sont plus en phase avec les connaissances humaines [Damasio06] etnous utilisons le langage de règles SWRL qui permet de manipuler des concepts OWLet nous permettra d’exprimer les connaissances empiriques.

Nous définissons le modèle d’agent et présentons une implémentation que nousillustrons au travers d’exemples. Afin d’illustrer notre approche, nous utilisons ce modèle

20 Chapitre 1. Introduction

pour y intégrer un mécanisme de transmission des connaissances. Nous nous plaçonspour cela dans un contexte de partage des connaissances entre que sont les VKC oucommunautés virtuelles de connnaissances. Notre proposition se situe donc à la frontièrede trois domaines que sont la gestion des connaissances, les systèmes multi-agents et leweb sémantique.

Le manuscrit est structurée de la manière suivante :– Le chapitre 4 présente le contexte dans lequel s’inscrivent nos recherches. Nous

présentons tout d’abord la notion de communauté virtuelle puis nous décrivonsles scénarios qui ont motivé nos recherches.

– Dans le chapitre 3, nous présentons un état de l’art des trois domaines qui nousintéressent, à savoir la gestion des connaissances, les systèmes multi-agents et leweb sémantique. Nous étudions dans ce chapitre les différents liens existants entreces trois domaines.

– Au chapitre 4, nous détaillons notre proposition et nous présentons un modèled’agent supportant une définition épistémologique de la connaissance. Nousdétaillons les différentes étapes de la construction de ce modèle, de la définitionvers les composants requis, puis nous détaillons l’implémentation du modèle.

– Le chapitre 5 présente la mise en œuvre de mécanismes d’échanges de connais-sance inter-agents sur notre modèle en l’appliquant au paradigme des communau-tés virtuelles de connaissances. Nous présentons une formalisation ensembliste,puis ontologique de ces communautés, puis nous détaillons leur modèle en tantque connaissances des agents sémantiques.

– Le chapitre 6 décrit la mise en œuvre de notre modèle d’agent sémantique. Nousdécrivons les choix techniques et la conception logicielle du prototype d’agentsémantique.

– Nous présentons les conclusions de cette thèse, ainsi que les différentes perspec-tives qu’offrent ces travaux au chapitre 7.

2Scénarios motivants

22 Chapitre 2. Scénarios motivants

Plan du chapitre

2.1 Communautés virtuelles de connaissances . . . . . . . . . . . . . . . . 252.1.1 Abstraction Orientée Agent . . . . . . . . . . . . . . . . . . . . 262.1.2 La connaissance d’entreprise . . . . . . . . . . . . . . . . . . . 262.1.3 Communautés virtuelles de connaissances . . . . . . . . . . . 282.1.4 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.2 Scénario 1 : Assistants personnels . . . . . . . . . . . . . . . . . . . . . 312.2.1 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.2.2 L’application réveil . . . . . . . . . . . . . . . . . . . . . . . . . 362.2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.3 Scénario 2 : Communautés virtuelles mobiles . . . . . . . . . . . . . . 392.3.1 Etat de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.3.2 Modèle économique . . . . . . . . . . . . . . . . . . . . . . . . 402.3.3 Spécifications des services . . . . . . . . . . . . . . . . . . . . . 432.3.4 Plate-forme technique . . . . . . . . . . . . . . . . . . . . . . . 452.3.5 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.4 Scénario 3 : Projet DRPI . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.4.1 Communautés virtuelles . . . . . . . . . . . . . . . . . . . . . . 482.4.2 Design de la plate-forme et implémentation . . . . . . . . . . . 492.4.3 Gestion des connaissances . . . . . . . . . . . . . . . . . . . . . 512.4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552.5.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

23

La définition du contexte et l’introduction à la problématique, sont les deux objectifsde ce chapitre. Dans une première partie nous introduirons le concept de communautésvirtuelles de connaissances auquel nous ferons appel tout au long de cette thèse. Leconcept de communauté virtuelles de connaissances (notée VKC par la suite, pourVirtual Knowledge Communities) a été introduit par Maret et Calmet [Maret04b] puisutilisé à plusieurs reprises pour des applications qui sont décrites dans les trois sectionssuivantes.

Il est important de situer la problématique dans laquelle se positionne les VKC.La gestion de connaissances au sein des organisations est un problème récent qui aété abordé selon des perspectives diverses telles que l’informatique, la gestion desconnaissances, la psychologie . . .. Les recherches menées par Maret et Calmet sur lamodélisation des connaissances d’entreprises ont mis l’accent sur une approche informa-tique basée sur le paradigme agent afin de prendre en compte l’aspect décentralisé desconnaissances. Pour comprendre l’approche qui sous-tend la réflexion engagée sur ledomaine de la gestion des connaissances d’entreprise, il est primordial d’introduire toutd’abord le concept d’abstraction orientée agent (AOA) définie par Calmet [Calmet04],qui sera le prisme au travers duquel l’analyse et les spécifications seront conduites. Lestravaux de Maret et Calmet [Maret04a] ont conduit à un certain nombre de définitionssur la connaissance d’entreprise qui sont présentées en section 2.1.2. Ces définitionsposent les fondations des communautés virtuelles de connaissances [Maret04b] quenous présentons en détail, ainsi que leur implémentation.

Nous présentons ensuite les travaux que nous avons mené au début de cette thèseet qui mettent en œuvre ce concept de communautés virtuelles de connaissances. Cestravaux ont été mené en collaboration avec des membres de l’université de Tokyo auJapon [Subercaze07], l’université de Twente aux Pays-Bas [Pawar08, Subercaze08] etYork University au Canada [El Morr09, Elmorr08]. Ces scénarios illustrent l’utilisationdes communautés virtuelles de connaissance dans différents cas.

Le premier scénario se place dans le cadre des applications sensibles au contexte. Cesapplications sensibles au contexte sont basées sur la capture d’information provenant del’environnement ainsi que de l’utilisateur. Les informations de contexte sont fourniespar des capteurs qui peuvent être soit fixe ou mobile, que ce soit pour capturer desinformations concernant l’environnement ou bien l’utilisateur. Ces applications sen-sibles au contexte sont elles aussi fixes ou mobiles, elles peuvent être exécutés aussibien sur une machine fixe disposant d’une puissance de calcul élevé que sur une ma-chine portable disposant de ressources plus limitées.De telles applications requiert ledéveloppement de framework supportant les contraintes de mobilité. L’intégration desdonnées provenant des capteurs est un problème complexe, spécialement dans le cadred’applications déployées sur des plates-formes mobiles. En effet, les capteurs fournissentdes données hétérogènes et l’utilisation de ces do En utilisant l’aspect décentralisé etautonome des agents, nous proposons un framework basé sur des agents qui permet la


fusion de données de capteurs (ainsi que l’échange d’informations de contexte) et quisupporte l’intégration de nouvelles sources. Après la présentation du framework, nousen présentons une application utilisant des capteurs portables, des transmetteurs ainsique des machines portables. Nous ferons appel au concept des communautés virtuellesde connaissance pour les échanges entre les différents agents. Nous présentons toutd’abord le Framework, puis une application autour d’un scénario de la vie courante,l’application "Réveil" qui permet d’éviter de rater sa station de métro. Ce scénario estdétaillé en section 2.2

Dans le scénario que nous de décrire, la capacité de traitement des systèmes mobilesétait un facteur limitant quant aux possibilités de réalisation. L’augmentation de lapuissance de calcul des systèmes mobiles nous a conduit à changer notre vision descommunautés virtuelles mobiles l’année suivante. Jusqu’alors, les limitations imposéespar la puissance de calcul ne permettait que de réaliser des traitements simples et/oude consommer des services depuis un système mobile de type téléphone portable ouPDA. Les évolutions technologiques récentes permettent de réaliser des calculs plusimportants. Il est alors naturel de considérer un système mobile non plus comme unsimple consommateur de services, mais aussi comme un potentiel fournisseur de ser-vices. Nos recherches se sont focalisés sur la réalisation d’applications commercialesorientées services. Pour cela nous proposons un modèle économique pour les commu-nautés virtuelles mobiles dans lesquelles les systèmes mobiles sont consommateursmais aussi producteurs de services [Pawar08, Subercaze08]. Nous détaillons dans cesecond scénario en section 2.3 les pré-requis au niveau des services, l’architecture requiseet l’implémentation open-source de la plate-forme technique. Puis nous donnons unexemple d’application dans le domaine de l’informatique médicale mobile.

Le troisième scénario présente l’application des communautés virtuelles dans lecadre du projet DRPI. Le projet DRPI est un projet international visant à surveiller lesviolations des droits des handicapés dans le monde. Le projet est divisé par pays. Nostravaux se sont focalisés sur la partie DRPI Canada, qui est un des membres fondateursdu projet. Ce projet rassemble des acteurs académiques aussi bien que des membres de lacommunauté des handicapés. L’approche holistique choisie par le comité de pilotage duprojet DRPI se concrétise par une communication continue et un partage des ressources,méthodologies et approches des quatre thèmes du projet. Ces quatre thèmes définisci-après, doivent permettre de couvrir et d’obtenir les informations sur les nombreuxtypes de discrimination dont peuvent souffrir les handicapés :

– Surveillance des expériences personnelles : des personnes souffrant d’un handicapsont impliquées dans la surveillance et peuvent faire part de leurs expériencespersonnnelles de discrimination.

– Surveillance des médias : les productions médiatiques concernant le handicap sontanalysées à travers le prisme des droits de l’homme.

– Surveillance des aspects juridiques : le statut actuel et l’évolution de la législation

Section 2.1. Communautés virtuelles de connaissances 25

sont suivis pour s’assurer du respect des droits fondamentaux des personnessouffrant d’un handicap.

– Surveillance des statistiques et sondages : le but est ici de s’assurer que les données,sondages et statistiques sont recueillies dans le respect de la législation concernantles handicapés.

Il est aussi fondamental de construire un partage de la connaissance au sein de la commu-nauté, pour promouvoir une prise de conscience des discriminations dont sont victimesles handicapés, afin qu’il participent eux aussi aux respects de leurs droits. Dans cecontexte, un système complexe est requis pour faciliter la collaboration d’un spectre variéde participants autour des quatre thèmes énoncés ci-dessus : chercheurs, représentantsde la communauté, législateur et grand public. Nous présentons ce scénario en section2.4.

Nous présentons nos conclusions à la fin de ce chapitre et présentons une analysedes sections exposées ci-dessous qui introduit la problématique de cette thèse.

2.1 Communautés virtuelles de connaissances

Le concept de communauté virtuelles de connaissances (notée VKC par la suite,pour Virtual Knowledge Communities) a été introduit par Maret et Calmet [Maret04b]puis utilisé à plusieurs reprises pour des applications [] qui sont décrites dans les troissections suivantes.. Nous présentons ici le concept en détail ainsi que certains exemplesd’application.

Il est important de situer la problématique dans laquelle se positionne les VKC.La gestion de connaissances au sein des organisations est un problème récent qui aété abordé selon des perspectives diverses telles que l’informatique, la gestion desconnaissances, la psychologie . . .. Les recherches menées par Maret et Calmet sur lamodélisation des connaissances d’entreprises ont mis l’accent sur une approche informa-tique basée sur le paradigme agent afin de prendre en compte l’aspect décentralisé desconnaissances. Pour comprendre l’approche qui sous-tend la réflexion engagée sur ledomaine de la gestion des connaissances d’entreprise, il est primordial d’introduire toutd’abord le concept d’abstraction orientée agent (AOA) définie par Calmet [Calmet04],qui sera le prisme au travers duquel l’analyse et les spécifications seront conduites. Nousintroduisons le concept d’AOA dans la sous-section suivante.

Les travaux de Maret et Calmet [Maret04a] ont conduit à un certain nombre de défini-tions sur la connaissance d’entreprise qui sont présentées en section 2.1.2. Ces définitionsposent les fondations des communautés virtuelles de connaissances [Maret04b] quenous présentons en détail en section 2.1.3.

Les sections suivantes sont des résumés des travaux publiés dans [Maret04a,Maret04b, Calmet04].


2.1.1 Abstraction Orientée Agent

L’abstraction orientée agent (AOA) est une transition entre le niveau individuel(agent) et le niveau global de la société d’agents. L’AOA se base sur la théorie classique deWeber en sociologie qui définit une société comme résultante de l’ensemble des actions deses membres [Weber68]. L’AOA définit un agent comme une entité dotée d’une base deconnaissances ainsi que d’un mécanisme de décision. La base de connaissances contientl’ensemble des connaissances de l’agent qui sont relatives à l’organisation dans laquelleil évolue. Cette base de connaissances est constituée de quatre composants appelléesannotations : ontologies,communication, cognition et sécurité. Le mécanisme de décisionde l’agent est relatif aux buts et tâches de l’agent. Il génère des fonctions d’utilité quimesurent l’efficacité des décisions de l’agent. Ces fonctions d’utilité sont structurés enclasses. Les spécialisations de ces fonctions sont faites au cours de l’implémentation.

2.1.2 La connaissance d’entreprise

L’approche des connaissances d’entreprise suit la même abstraction que celle utilisépour l’AOA. L’hypothèse principale est que l’activité d’une entreprise est définie autravers de la mémoire d’entreprise. Cette mémoire d’entreprise comprend tous les"morceaux" d’information disponibles dans l’entreprise, des technologies requises pourconcevoir un produit jusqu’au politique de gestion des ressources humaines ou decommunication externe. Cette approche est résumée par les définitions suivantes :

Définition 1 Une entreprise est composée d’agents (individus et automates). Les agentspossèdent des connaissances

Définition 2 Les connaissances d’un agent sont annotées. Les annotations sont desclasses ou types structurant la connaissance.

Définition 3 Les clusters sont des sous-ensemble cohérents des connaissances desagents. Les clusters sont définis par des filtres.

Définition 4 Les actions et les décisions d’un agent sont prises par le mécanisme dedécision selon ses connaissances. Ces actions et décisions sont évaluées par lesfonctions d’utilité.

Définition 5 La mémoire d’entreprise est constituée de l’ensemble des connaissancesdétenu par l’ensemble des agent qui constituent l’entreprise. Cette mémoire estcomposée des connaissances stockées et obtenues par des communications internesou externes.Ces caractéristiques sont suffisantes pour aborder le problème de la gestion desconnaissances qui nous intéresse ici. Nous n’exposons pas plus en détail l’AOA etinvitons le lecteur si il souhaite plus de détails à consulter [Calmet04].

Le but est ici d’éviter toute séparation entre agents et connaissance. La connaissancen’est pas extérieure aux agents mais elle leur est propre. Les agents sont détenteurs des


connaissances de l’entreprise. La première définition implique ques les individus (hu-mains) et machines sont considérés selon le même niveau d’abstraction. La connaissancen’est pas prise en compte au sens d’un système de base de données mais comme unparadigme centré sur l’agent (individu ou automate). La communication est un élémentnécessaire pour chaque agent, les automates doivent être capables de communiquerentre eux et les individus doivent disposer d’une interface utilisateur.

La définition 2 élargit le cadre classique de la base de connaissances d’un agent.Classiquement celui-ci est restreint à l’utilisation d’ontologies. L’AOA permet, à l’aidedes trois composants additionnels : cognition, communication et sécurité ; d’aborderde manière globale la définition d’un agent. Le composant de cognition regroupe lescapacités de raisonnement de l’agent. Ce raisonnement peut-être de nature logique,pragmatique ou encore heuristique. Le composant de sécurité gère les aspects légaux,cryptographiques et de confiance. La partie communication gère quant à elle l’ensembledes protocoles, messages, etc qui permettent à l’agent de communiquer. Cette énuméra-tion des composants n’entend pas être exhaustive et peut être étendue. C’est le rôle de lanotion d’annotation dans les définitions. Les annotations se réfèrent à la structure desconnaissances de l’agent. Un élément de connaissance i peut être annoté par différentesannotations a1...an qui lui confèrent des propriétés. On peut ainsi imaginer un messagequi soit annoté du point de la communication (protocole, structure) mais aussi du pointde la sécurité (respect des lois, etc). Le mécanisme d’annotations permet d’étendre lesannotations d’une connaissance à un domaine ou composant autre que ceux définis ici(cognition, sécurité, communication) et qui serait introduit à postériori.

Dans la définition 3, un cluster est un sous-ensemble des connaissances des agents.Un cluster peut être compris comme une vue externe des connaissances, en vue d’unéchange entre les agents. Le cluster constitue le passage d’une vision interne à l’agentà un élément transmissible à d’autres agents. Pour un composant de connaissanceconsistué de C concepts, l’ensemble CL des clusters est défini de la manière suivante :

– ∀ci ∈ C : k = (ci, {ci}, ∅) ∈ CL (chaque concept est un cluster)– k = (Tete, Sousclusters, Relations) ∈ CL, ou Sousclusters ∈ 2CL\∅ est l’ensemble

des clusters présents dans k. Tete ∈ Sousclusters est non vide. Relations définit lesrelations présentes au sein du cluster ainsi qu’à l’extérieur.

La définition 4 signifie que les agents sur leurs connaissances pour prendre desdécisions. Les agents définissent des fonctions d’utilité qui permettent de mesurerl’efficacité de leurs actions en fonction de leur but, de l’environnement et leurs états.

La raison derrière la cinquième définition est que la mémoire d’entreprise comprendles connaissances propres aux agents mais aussi celles auxquelles ils peuvent avoir accés.De ce fait le point de vue social est mis en avant. Ce concept ne définit pas de visionobjective de la connaissance, mais une approche locale à chaque agent. Il ne peut ainsiêtre fait l’hypothèse que les connaissance d’un agent soient complètes, ou cohérentesavec celles d’autres agents.


2.1.3 Communautés virtuelles de connaissances

Les communautés virtuelles de connaissances ont été introduites en tant que moyend’échange de connaissances au sein d’une société composée d’agents définis selon lestermes de la section précédente, c’est-à-dire possédant une base de connaissances et unmécanisme de décision. De plus, chaque agent possède au moins un but ou une tâche àaccomplir au sein de cette société. L’appartenance à une communauté ne remplace lebut initial pour lequel l’agent a été introduit dans le système. Le but des communautésvirtuelles de connaissance est d’augmenter l’efficacité des échanges de connnaissance entre lesagents afin de permettre aux agents de réaliser plus rapidement leur but. L’objectifsecondaire est d’obtenir au travers de ces échanges, de nouvelles connaissances apprisesou déduites, à l’aide des capacités de raisonnement (composant de cognition) de chaqueagent. De manière similaire aux processus d’entreprises, les communautés virtuellesde connaissances se doivent d’être dynamique. Les agents doivent ainsi pouvoir créer,rejoindre et alimenter les communautés de manière dynamique.

Une communauté de connaissances est composée d’un thème, de membres et d’unespace d’échanges de messages. Le thème d’une communauté est un cluster C ∈ CL. Lesagents participant à la communauté sont sensés échanger des messages autour du thèmede la communauté. Tout agent ne respectant pas ces clauses peut se voir exclu de lacommunauté. Les messages sont échangés au travers d’un sytème permettant d’accéderaux messages reçus et d’en envoyer de nouveaux (tampon de messages). Le contenu desmessages est composé d’un cluster et d’instances.

Les actions relatives aux communautés sont aux nombre de 5 : créer, réorienter,terminer, rejoindre une communauté et échanger des connaissances. La création ouinitiation de la communauté peut être effectuée par n’importe quel agent, cet agentdevient alors le leader de la communauté. La crétion d’une communauté se fait parla création d’un cluster, d’un tampon de messages (buffer) et de la promotion de lacommunauté. La promotion d’une communauté se fait au travers d’une communautéspéciale, la communauté des communautés. Tous les agents appartiennent à cette dernière,qui est similaire à un système de pages jaunes. Le créateur de la communauté envoieun message contenant le cluster qui est le thème de la communauté. Ce cluster peutcontenir des concepts et aussi des instances. Les agents recherchant une communautés’adresse à la communauté des communautés.

Une réorientation est une action nécessaire, au vu de la nature dynamique descommunautés. La réorientation consiste en l’envoi d’un message à la communautédes communautés pour une mise à jour du thème dans la liste des communautés. Ladissolution d’une communauté intervient par la volonté du leader. Celui-ci efface alorsle tampon des messages puis retire du système de pages jaunes l’entrée correspondanteà la communauté. Les échanges au sein de la communauté se font par accés au tamponde messages et par envoi de cluster et/ou d’instances dans ce tampon.


Les capacités des agents à interpréter les connaissances acquises, à échanger desconnaissances sont considérées comme des connaissances en tant que telles. Ces capacitéssont propres à chaque agent et peuvent par conséquent différer dans les fonctionnalitéset dans l’implémentation. Ce choix de conception est volontaire et permet de prendre encompte la décentralisation des capacités des agents.

La régulation des communautés est un problème social que l’on retrouve dansle cas des communautés virtuelles. Pour prendre en compte la notion de régulationchaque agent fondant une communauté peut spécifier les politiques de sécurité et deconfidentialité qui s’y appliquent. Ces politiques spécifient entre autres la manièredont les agent rejoignent, participent aux communautés. Le rôle de ces politiques estd’adresser les problèmes de sécurité qui peuvent apparaitre lorsque des agents malicieuxsont présents dans le système.

2.1.4 Implémentation

Le but du prototype est de réaliser un système fonctionnel au sein duquel des agentspossédant des connaissances hétérogènes peuvent créer, terminer, participer à des com-munautés virtuelles de connaissances. L’accent est mis sur le partage, en particulier surles correspondances entre les ontologies hétérogènes décrivant des concepts similairesainsi que sur les mécanismes des communautés (appartenance, participation).

Le prototype permet la création de plusieurs agents sur des machines réparties,chaque agent possédant ses propres connaissances et son propre mécanisme de décision.Ce mécanisme de décision est entre autres invoqué lors de la création ou de la partici-pation à des communautés. Chaque agent possède ses concepts personnels, ainsi quedes ontologies normalisées et un ensemble de correspondances entre les deux. L’utilisa-tion des agents est centrée utilisateur, les agents disposant d’une interface graphiquepermettant à l’utilisateur d’entrer de nouveaux buts, de nouveaux concepts/instancesou de nouvelles correspondances. L’agent agit ensuite pour l’utilisateur, selon les butsassignés.

La plate-forme JADE [Bellifemine99] a été choisie pour réaliser l’implémentationdu prototype. Le choix de JADE se justifie par la capacité des agents à échanger desmessages selon le standard FIPA-ACL [ACL-FIPAml] et par la possibilité d’utiliser pourchaque agent des ontologies définies par l’utilisateur. Les agents ont été créé en étendantla classe jade.core.Agent.

La classe principale du système est la classe CommunityAgent qui est une classeabstraite définissant les méthodes des agents participant aux communautés. Deux im-plémentations de cette classe abstraite ont été réalisées : la classe IndividualAgentet SocialAgent. Ces deux implémentations sont opposées dans le comportement del’agent. l’agent individualiste cherchera à rejoindre une communauté et à y participer


FIGURE 2.1 – Diagramme de classe simplifié des agents

seulement si il a besoin de connaissances qui pourrait s’y trouver. Une fois les connais-sances acquises, il quittera la communauté (ou la terminera si il en est l’instigateur).L’agent social créera des communautés dans le but désintéressé de partager ses connais-sances. Il rejoindra de la même manière toutes les communautés qui le concernent.

Chaque CommunityAgent possède exactement un objet PersonalKnowledge.La classe PersonalKnowledge étend la classe KnowledgeClusterOntology quireprésente une ontologie décrivant les concepts, instances et clusters possibles. D’au-cun peuvent considérer la classe KnowledgeClusterOntology comme une méta-ontologie. Les connaissances personnelles d’un agent sont constituées des ontologiespersonnelles KnowledgeCluster ainsi que des instances personnelles de la classeAbsContentElementList. La figure 2.1 représente les différentes classes énumérées.

Les communications entre agents se fait par passage de messages. Les mes-sages sont de type jade.lang.acl.ACLMessage : inform ou request. Troistypes de messages request peuvent être envoyés par les CommunityAgent :joinCommunity, readFromBuffer (qui demande de lire le tampon de mes-sages) et KnowledgeCluster (l’agent souhaite envoyer un cluster à la commu-nauté). Nous distinguons quatre types de messages inform : les messages conte-nant unKnowledgeCluster ou des instances qui sont partagés par un agent,updateRole lors de la mise à jour d’un ou des roles des agents, leavingCommunityet communityDead permettent de quitter et de fermer une communauté.

2.1.5 Conclusion

L’analyse de la structure d’un sytème de gestion de connaissances selon l’approcheAOA de Calmet a permis de donner des définitions de la connaissance d’entreprise Apartir de ces définitions et suivant la même approche d’abstraction que pour l’AOA,le concept résultant de l’analyse sont les communautés virtuelles de connaissances

Section 2.2. Scénario 1 : Assistants personnels 31

qui fournissent un cadre de travail prenant en compte les différents aspects d’autono-mie, de décentralisation, de modélisation des connaissances ainsi que des mécanismesd’échanges. Le concept de communautés virtuelles de connaissances permet de dif-fuser et d’étendre les connaissances d’une société d’agents. La connaissance n’est paslimitée au domaine d’intérêt de chaque agent mais comprend aussi les connaissancesdes mécanismes d’échanges, de "traduction" des ontologies et du comportement social(individualiste, social). L’implémentation d’un prototype a permis de mettre en œuvreles différents aspects.

La base de connaissances ne contient pas seulement des ontologies, mais aussi troisautres composants (cognition, communication et sécurité). Cependant, l’implémenta-tion montre une différence de traitement entre les différents composants. En effet lesontologies sont les seules parties de la base de connaissances qui sont échangeablesentre les agents. Les trois autres composants sont programmés sont internes à l’agent.En premier lieu on pourrait croire que c’est le langage d’implémentation des agents quine permet pas réutiliser le code de chacun des composants. Mais ces agents, basés surJADE, sont programmés en JAVA, le JAVA proposant des fonctionnalités de réflectiondans le package java.lang.reflect et offre la possibilité de transférer des portionsde code exécutables entre des programmes JAVA. Cette limitation dans le transfertdes connaissances provient de l’architecture des agents JADE. Les agents sont conçuspour échanger des messages au format FIPA-ACL et pour gérer de manière internedes ontologies. Les parties exécutables qui sont les comportements (dans le packagejade.core.behaviours) ne sont pas conçus pour être échangés et intégrés dans lesagents.

L’implémentation a permis de mettre en lumière deux problèmes. Le premier estl’hétérogénéité des composants de la base de connaissances. Les formalismes de repré-sentation des connaissances au sein de l’implémentation sont hétérogènes : les ontologiessont au format RDF, les composants responsables de la communication, cognition etsécurité sont programmés en JAVA (une partie de la sécurité est en RDF, pour la descrip-tion des politiques). Cette hétérogénéité combiné aux limitations de l’architecture JADE,rend une partie de la connaissance seulement interne aux agents.

Le deuxième problème découle du premier et pose des questions plus théoriques. Ladistinction entre les parties échangeables et non échangeables de la base de connaissancessoulève plusieurs questions : une connaissance qui n’est pas échangeable est-elle uneconnaissance ? si oui, dans quelle mesure est-elle utile pour le système ? Quand peut-onparler de connaissance ?

2.2 Scénario 1 : Assistants personnels


Les applications sensibles au contexte sont basées sur la capture d’information pro-venant de l’environnement ainsi que de l’utilisateur. Les informations de contexte sontfournies par des capteurs qui peuvent être soit fixe ou mobile, que ce soit pour capturerdes informations concernant l’environnement ou bien l’utilisateur. Ces applicationssensibles au contexte sont elles aussi fixes ou mobiles, elles peuvent être exécutés aussibien sur une machine fixe disposant d’une puissance de calcul élevé que sur une ma-chine portable disposant de ressources plus limitées.De telles applications requiert ledéveloppement de framework supportant les contraintes de mobilité.

L’intégration des données provenant des capteurs est un problème complexe, spécia-lement dans le cadre d’applications déployées sur des plates-formes mobiles. En effet,les capteurs fournissent des données hétérogènes et l’utilisation de ces données au seinde l’application est prédéfinie avant le développement de l’application.

La majorité des frameworks sont conçus pour permettre le développement d’ap-plications statiques sensibles au contexte . Les frameworks les plus avancés sont lessuivants : [Pinyapong04] qui est dédié au profil utilisateur, [Gellersen02] spécialisé dansl’intégration de sources hétérogènes, [Biegel04] réalise la fusion des données de capteursà l’aide de réseaux bayésiens, [Henricksen04] qui propose un outil de développementrapide d’applications pervasises centrées sur la modélisation de contexte et [Salber98]qui prend en compte l’historique du contexte de chaque utilisateur.

Le désavantage majeur de tout ces frameworks est qu’aucun ne permet d’intégrersimplement l’arrivée de nouveaux types de données provenant de nouveaux capteurs.Dans la plupart des cas, l’application doit être entièrement repensée.

En utilisant l’aspect décentralisé et autonome des agents, nous proposons un fra-mework basé sur des agents qui permet la fusion de données de capteurs (ainsi quel’échange d’informations de contexte) et qui supporte l’intégration de nouvelles sources.Après la présentation du framework, nous en présentons une application utilisant descapteurs portables, des transmetteurs ainsi que des machines portables. Nous feronsappel au concept des communautés virtuelles de connaissance pour les échanges entreles différents agents. Nous présentons tout d’abord le Framework, puis une applicationautour d’un scénario de la vie courante, l’application "Réveil" qui permet d’éviter derater sa station de métro.

2.2.1 Framework

Bien que l’utilisation des capteurs dans les applications sensibles au contexte soit unechose nécessaire, on constate un manque d’approche globale dans les infrastructuresdédiées au développement de ces applications. De plus, pour intégrer pleinement lesdonnées fournies par les capteurs, le point de vue de l’architecture de l’applicationen terme de composants doit-être pris en compte, mais aussi le traitement de ces don-


nées ainsi que l’échange des données de contexte entre ces différents composants puisfinalement leur interprétation sémantique.

Pour permettre une intégration efficace de ces différents niveaux de traitement nousproposons une infrastructure (voir figure 2.2) basée sur les trois concepts suivants :

– Les applications sensibles au contexte requiert une autonomie des composantsqui permet de décentraliser le traitement des données. En terme de paradigme, lanotion de système multi-agent est parfaitement adéquate avec ce point de vue.

– Nous proposons deux types d’agents : les agents de contexte qui sont respon-sables de la capture des données de contexte, de leur interprétation et de leurdissémination au sein du système (section 2.2.1.1), et les agents personnels quipossèdent des connaissances sur l’utilisateur (son profil) et qui sont chargés defournir le service sensible au contexte à l’utilisateur final (section 2.2.1.2).

– Les agents possèdent une représentation des connaissances basées sur des ontolo-gies. Les échanges entre les agents seront effectués au travers des communautésvirtuelles de connaissances que nous avons décrites dans la section précédente.

FIGURE 2.2 – Description du framework

2.2.1.1 Agent de contexte

Nous considérons qu’une application sensible au contexte est un système complexed’aide à la décision. Les décisions sont basées sur les connaissances extraites des donnéesdes capteurs ainsi que sur les préférences de l’utilisateur. Les données des capteurshétérogènes peuvent être intégrées de différentes manières. [Sharma98] propose troisniveaux d’intégration :

1. Fusion des données : Les données brutes sont fusionnées avant tout autre type detraitement. C’est l’intégration au plus bas niveau, elle n’est possible que dans lecas de capteurs capturant le même type de données. Par exemple dans le cas des


rangées de microphones, la fusion à bas niveau permet de réduire le pourcentaged’erreur.

2. Fusion des caractéristiques : Chaque signal ou donnée brute est interprété en tantque caractéristique (température, pression, niveau d’activité, . . .). Ces interpréta-tions sont ensuite les entrées du système de décision.

3. Fusion au niveau décision : Pour chaque donnée extraite une décision est calcu-lée (proposer X ou Y à l’utilisateur), ces décisions sont ensuite fusionnées, pourdéterminer la décision finale.

Les applications sensibles au contexte qui nous intéressent intègrent des données dedifférentes natures, ce qui exclut de facto la fusion à bas niveau dans notre système. Lafusion au niveau décision requiert un temps de calcul plus élevé que celle au niveaucaractéristiques, chaque donnée de capteur devant suivre le cycle complet de traitement(interprétation, décision, puis fusion). Nous choisissons que la fusion des données decapteur doit être effectué au niveau des caractéristiques. Ce niveau de fusion est satisfai-sant en terme de possibilités d’évolution, puisqu’il intègre des données de différentesnatures et il est aussi adapté au application mobile qui dispose d’une puissance de calcullimitée.

Nous distinguons quatre niveaux dans l’architecture des agents de contexte :

1. Capteur : Ils capturent les informations environnementales et délivrent soit unsignal électrique soit une sortie discrète.

2. Récepteur : Transmet les données du capteur au premier niveau de traitement.

3. Interpréteur : Ce niveau joue un rôle crucial dans l’analyse des données fourniespar le capteur. A ce niveau, le signal est transformé en données contextuelles. Parexemple à partir du signal fourni par un accéléromètre, l’interpréteur peut fournirle contexte du porteur de l’accéléromètre : marcher, courrir, être immobile . . .. Dansce cas précis, ce module est aussi nommé HBR pour Human Behavioral Recogntionou Reconnaissance du Comportement Humain en français.

4. Synthétiseur : La partie innovante dans notre approche. Le synthétiseur trans-forme les données fournies par l’interpréteur afin de les rendre échangeables avecles autres agents du système.

Le bénéfice en terme de développement d’applications apparait avec l’introductiondu synthétiseur, qui permet l’échange entre les différents agents qui composent l’ap-plication. L’intégration de nouveaux capteurs et de nouvelles données dans le systèmene nécessite pas de redéfinir totalement la structure ni les composants de l’application.Les changements concernant les informations fournies par les capteurs sont définiesdans les couches d’un nouvel agent de contexte ou intégrées dans un agent existant.C’est l’utilisation de la décentralisation et de l’autonomie des agents qui permet cettesouplesse dans l’application.


De plus, un agent de contexte étant capable de communiquer avec d’autres agents, enparticulier d’autres agents de contexte, il lui est possible d’agréger les informationsfournies par d’autres agents afin d’améliorer son interprétation de l’environnement.

2.2.1.2 Agent Personnel

L’agent personnel est en contact direct avec l’utilisateur, il est donc implémenté surune machine mobile de type téléphone portable ou PDA et il joue le rôle d’assistantpersonnel. Cet agent rassemble les informations de contexte fournies par les agents decontexte et fournit un service à l’utilisateur final. Cet utilisateur est décrit sous la formed’un profil qui contient des informations sur les préférences de l’utilisateur, des donnéespersonnelles, ainsi qu’un historique des actions de l’utilisateur. Le processus de décisionde l’agent se base sur le profil de l’utilisateur ainsi que sur les données fournies par lesagents de contexte. Ce processus est défini par des prédicats qui peuvent être soit entrésau moment de la conception de l’application, soit par l’utilisateur final. L’utilisation derègles a été choisie pour son temps de calcul de réduit, ainsi que pour la faible taille enmémoires.

2.2.1.3 Echanges d’informations à base d’agents

Les systèmes composés d’entités distribuées et hétérogènes (capteur, PDA, agentslogiciels) requiert des mécanismes d’échanges d’information qui sont efficaces. Uneapproche orientée agent permet de prendre en compte la nature distribuée des entités,elle doit être complétée de mécanismes d’échanges d’information.

Le concept de communautés virtuelles de connaissances a été proposé par Maret[Maret04b]. Les principes de ces communautés sont les suivants. Chaque agent possèdesa propre base de connaissance basée sur des ontologie et il possède aussi ses méca-nismes de traitement de ses propres connaissances et de celles qu’il reçoit au travers deséchanges avec les autres agents. Lorsque les agents désirent échanger des connaissances,ils recherchent une communauté axée autour du thème qui les intéresse. Si une tellecommunauté n’existe pas, l’agent crée une communauté et la déclare dans un systèmede pages jaunes. Les échanges ont lieu pendant la durée de vie de la communauté, quipeut-être finie ou infinie. La sécurité des échanges est garantie par les politiques desécurité associées à chaque communauté.

Ces communautés virtuelles de connaissances ont été implémenté sur la plate-formeJADE [Bellifemine99] et JADE-LEAP pour des applications mobiles. Les connaissancesdes agents sont définies en RDF et les messages sont transmis au format FIPA-ACL[ACL-FIPAml]. L’agent qui initie une communauté devient le leader de cette commu-


nauté, il spécifie la thématique de la communauté ainsi que les politiques d’échanges etde sécurité. Les échanges sont faits au travers d’un système de tableau noir, en fonctionde leurs droits au sein de la communauté, les agents peuvent lire et/ou écrire sur letableau.

2.2.2 L’application réveil

Nous avons implémenté notre framework dans une application apepllée "Réveillemoi". Le scénario est le suivant. Un passager du métro s’endort pendant le trajet quil’amène à son domicile. L’application doit-lui permettre de ne pas rater son arrêt demétro. La solution proposée est de détecter le niveau d’activité de l’utilisateur à l’aidede capteurs portables et si nécessaire de le réveiller en faisant sonner son téléphoneportable lorsqu’il s’approche de la station désirée.

Cette application requiert différents composants : des transmetteurs dans les stationsde métro, des capteurs d’activité ainsi qu’un téléphone portable. Chacun implémentesoit un agent personnel, soit de contexte, et utilise les fonctionnalités des VKC.

2.2.2.1 Implémentation des agents de contexte

Deux agents de contexte sont requis dans cette application. Le premier est celui quiest relié à un transmetteur et qui fournit le nom de la station de métro ou il est basé.Cet agent est spatialement immobile. Le second agent est relié à capteur de pression auniveau du pied et il fournit le niveau d’activité de l’utilisateur.

Transmetteur

Cette application nécessite l’installation de bornes wi-fi dans chaque station de métro.Un agent contextuel gère une commaunuté virtuelle de connaissances dont le thème estla station de métro. Pour notre application, ce transmtteur fournit seulement le nom dela station, mais ces fonctionnalités peuvent être étendues pour fournir d’autres élémentsaux voyageurs tels qu’un plan de la station, les horaires de métro . . .. Les connaissancestransmises sont les suivantes :

– Concept : Nom de station– Instance : ’Ginza’

Capteur

Nous avons utilisé un capteur de pression au niveau du pied qui mesure le niveaud’activité d’un voyageur [Sugimoto06] (voir figure 2.3). La sortie du capteur est unsignal électrique qui ne possède aucune signification brute. Ce signal est envoyé à un


composant embarqué sur lequel est déployé un agent de contexte implémenté sur JADE-LEAP qui détermine si l’utilisateur est endormi ou non. Un algorithme de type HBR estutilisé pour déterminer l’état de l’utilisateur. Cet agent de contexte associé au capteurest aussi en charge de la diffusion de cette information au travers des VKC. Une versionsimplifiée des connaissances transmises est indiquée ci-dessous.

FIGURE 2.3 – Foot pressure sensor

– Concept : Niveau d’activité– Valeur possible : ’debout’, ’assis’, ’dort’, ...– Valeur actuelle : ’dors’

2.2.2.2 Implémentation de l’agent personnel

L’agent personnel est aussi implémenté sur JADE-LEAP et est exécuté sur téléphoneportable. Le profil de l’utilisateur contient sa station d’arrivée. Cette information peutêtre entrée par l’utilisateur ou déduite de son agenda. Cet agent peut initier et rejoindredes communautés virtuelles.

Lorsque le métro approche d’une station, l’agent personnel recherche la communautéinitiée par le transmetteur, il rejoint la communauté et récupère le nom de la station. Sil’utilisateur se trouve à la station désirée, l’agent de contexte située dans le téléphone créeune communauté autour du niveau d’activité de l’utilisateur. L’agent de contexte reliéau capteur de pression rejoint la communauté et fournit le niveau d’activité enregistré.Si l’utilisateur est endormi, le téléphone se met alors à sonner. Le prototype a étéimplémenté sur un nokia N91, l’interface utilisateur est présenté en figure 2.4.

L’agent personnel possède les connaissances suivantes :

– Concepts : niveau d’activité, Destination souhaitée, Position actuelle, règles dedécision

– exemples d’instances :– nieau d’activité : inconnu


FIGURE 2.4 – Interface utilisateur de l’agent personnel

– Destination souhaitée : ’Ginza’– Position actuelle : ’Shibuya’– Règles de décision : IsSameLocation(Location1, Location2) ; IntentionDescrip-

tion(Desired location, Actual location)

FIGURE 2.5 – Communication entre les agents

2.2.3 Conclusion

L’utilisation des capteurs personnels dans les applications mobiles sensibles aucontexte est un domaine de recherche prometteur. Le framework proposé, basé surdes échanges de connaissances entre des agents de contexte et des agents personnelsau sein de communautés permet l’intégration dynamique de nouveaux capteurs sansrespécification de l’application. L’intégration d’un second capteur d’activité dans le

Section 2.3. Scénario 2 : Communautés virtuelles mobiles 39

cadre du scénario applicatif du réveil nécessite seulement la mise en place d’un agent decontexte lié à ce second capteur et de la modification des règles de décision de l’agentpersonnel pour gérer les cas ou les deux capteurs fourniraient des niveaux d’activitédifférents. Cette approche décentralisée permet de tirer pleinement parti de l’aspectautonomie que présente l’approche agents et le scénario du réveil permet d’illustrer sonfonctionnement. Le synthétiseur est le composant innovant de cette approche qui permetde transformer les informations de l’agent en connaissances échangeables avec les autresagent. Ces échanges basés sur les VKC permettent l’ajout dynamique de nouveauxcapteurs et mettent en lumière l’aspect dynamique et flexible des VKC.

[Subercaze07]

2.3 Scénario 2 : Communautés virtuelles mobiles

Dans l’exemple précédent, la capacité de traitement des systèmes mobiles était unfacteur limitant quant aux possibilités de réalisation. L’augmentation de la puissance decalcul des systèmes mobiles nous a conduit à changer notre vision des communautésvirtuelles mobiles l’année suivante. Jusqu’alors, les limitations imposées par la puissancede calcul ne permettait que de réaliser des traitements simples et/ou de consommer desservices depuis un système mobile de type téléphone portable ou PDA. Les évolutionstechnologiques récentes permettent de réaliser des calculs plus importants. Il est alorsnaturel de considérer un système mobile non plus comme un simple consommateur deservices, mais aussi comme un potentiel fournisseur de services.

Nos recherches se sont focalisés sur la réalisation d’applications commerciales orien-tées services. Pour cela nous proposons un modèle économique pour les communau-tés virtuelles mobiles dans lesquelles les systèmes mobiles sont consommateurs maisaussi producteurs de services [Pawar08, Subercaze08]. Nous détaillons les pré-requisau niveau des services, l’architecture requise et l’implémentation open-source de laplate-forme technique. Puis nous donnons un exemple d’application dans le domainede l’informatique médicale mobile.

2.3.1 Etat de l’art

Le travail présenté en [ElMorr07] regroupe les différentes tendances au sein descommunautés virtuelles mobiles dans les catégories suivantes : centrées sur la technologie,centrées sur l’utilisateur et centrées sur le business . Une analyse entre les dépendances descatégories est ensuite réalisée. Pour Leimister et. al. [Leimeister04], un modèle écono-mique doit considérer des facteurs externes comme les facteurs techniques ou légaux.Pour motiver ce point de vue, une analyse de deux communautés virtuelles utilisantce modèle économique est faite en [Leimeister04]. Comme indiqué en [Schubert05], un


modèle économique sert à comprendre les composants fondamentaux d’une activitécommerciale, existante ou future. Le modèle économique présenté en [Schubert05] prenden compte les aspects sociaux et commerciaux des communautés virtuelles. La plate-forme de communauté est mise en place par les fournisseurs de services ou les vendeursqui souhaitent faire la promotion ou la vente de services ou de produits. En se basant surdes informations telles que les préférences des utilisateurs, leur réseau social, le vendeurfournit des services ou produits personnalisés. Du point de vue mobile, la communautéprésentée en [Schubert05] est asynchrone, c’est-à-dire que les membres propagent lesmessages à leurs amis quand ils le souhaitent. L’application présentée est un système delocation dans le domaine des loisirs. Une extension du modèle économique présentée en[Schubert05] est fournie pour cette application, afin de prendre en compte les aspectsmobiles et sensibles au contexte.

Pour profiter de l’aspect mobile dans des scénarios tels que ceux des encombrementsde traffic, [Kawash05] propose un système innovant de collaboration basé sur le conceptde spot. Ce modèle collaboratif a été appliqué par [Kawash05] pour développer des com-munautés autour des problématique de transport public. Pour étendre les communautésvirtuelles en partant d’un point de vue fixe vers la mobilité, [Farooq02] propose un sys-tème sans-fil nommé MOOsburg++. Combiné avec des systèmes de géopositionnement,MOOsburg++ permet de fournir des penses-bêtes liés à des localisations précises.

Notre travail se distingue des travaux présentés sur les points suivants :

1. Le business model prend en considération le fait que les acteurs mobiles puissentêtre fournisseur de contenu et de services.

2. La plate-forme de communauté utilise les informations de contexte des membrespour le recommander des produits, services . . .

3. Une approche orientée service pour l’implémentation de l’architecture dans la-quelle les membres utilisent leurs systèmes mobiles pour offrir des services com-merciaux ou des échanges de contenu.

2.3.2 Modèle économique

Dans le modèle économique proposé nous définissons tous d’abord trois typesd’acteurs primaires : consommateurs, fournisseurs et la plate-forme de communauté. Lesfournisseurs et consommateurs peuvent être indifféremment fixes ou mobiles. Lesfounisseurs sont divisés en sous-catégories : les fournisseurs de services commerciaux,les vendeurs de produits, les fournisseurs de contenus sociaux, les fournisseurs de supportcommunautaire ainsi que les fournisseurs de service internet. Les consommateurs sont définisde manière duale aux fournisseurs : consommateurs de service commerciaux, consommateursde produits, consommateur de contenu. La plate-forme communautaire fournit les élémentset foncionnalités nécessaires aux intéractions entre consommateurs et fournisseurs.


FIGURE 2.6 – Modèle économique pour les communautés virtuelles mobiles

Dans ce travail, nous axons notre recherche sur le rôle des utilisateurs mobiles en tantque fournisseurs de services, produits et contenu mais aussi en tant que consommateurs.Nous présentons ici deux exemples simple pour justifier ce concept. Pour un exempleplus détaillé, voir le cas d’étude en section 2.3.5.

Utilisateur mobile comme consommateur d’un service commercial : L’utilisateur mobileprend une photographie d’un code barre au dos d’un livre et envoie cette image àun service qui lui fournit des informations détaillées sur l’auteur, l’ouvrage et unecomparaison des prix.

Utilisateur mobile comme fournisseur d’un service commercial : L’utilisateur mobile utiliseson téléphone pour controler la qualité de service (QoS) et fournir des données à unservice de cartographie de QoS [Wac06] qui analyse et compile les informations fournispar de nombreux appareils mobiles, et fournit une carte du réseau.

Le fournisseur d’accés à internet (ISP) fournit la connectivité qui permet aux acteursd’intéragir entre eux. Son rôle étant limité dans notre étude, nous ne le détailleronspas et n’y porteront pas plus d’attention. La figure 2.6 présente les différents acteurs :consommateurs, fournisseurs, plate-forme communautaire ainsi que l’ISP. Les flotsd’échanges, de contenus, financiers et de produits sont aussi décrits. La section suivantedécrit en particulier le rôle central de la plate-forme communautaire.


2.3.2.1 Plate-forme communautaire :

La plate-forme communautaire fournit l’infrastructure ainsi que les fonctionnalitéspour créer des relations sociales et faciliter les transactions financières et de contenusentre les fournisseurs et les consommateurs. La plate-forme permet aux fournisseursde services (produits) de lister et de promouvoir leurs services (produits). Le serviced’intéraction sociale au sein de la plate-forme fournit les outils pour créer les relationssociales entre les membres. La plate-forme est aussi le seul point de contact pour leséchanges financiers entre les consommateurs et les fournisseurs.

Une des fonctionnalités importantes de la plate-forme communautaire est le servicede recommandation sensible au contexte qui utilise les informations de contexte (localisation,. . .) des fournisseurs et consommateurs pour leur recommander des services ou des pro-duits en s’appuyant sur leur contexte. Par exemple si différents fournisseurs proposentun service d’ambulance, le patient utilisera le service le plus proche. L’utilisation desinformations de contexte des utilisateurs mobiles est aussi utile pour offrir des publicités,contenus adéquats.

2.3.2.2 Fluxs de produits, services et de contenus

Nous définissons trois types de mode d’intéraction pour les échanges de contenuentre les acteurs :

Publier : Le mode d’intéraction Publier est utilisé par le fournisseur de servicescommerciaux, de produits ou de contenu social et par le fournisseur du service deplate-forme communautaire pour publier les offres de service, de produit et de contenu.La plate-forme communautaire fournit les différents mécanismes (par exemple la listedes services, produits, contenu dans les sous communautés appropriées ou sur le profilde l’utilisateur) pour publier ces informations.

Réponse à une requète : Le mode réponse à une requète est utilisé par les consommateurset par la plate-forme communautaire pour intéragir avec les fournisseurs. La plate-forme communautaire sert donc essentiellement de médiateur entre les fournisseurs etconsommateurs. Le service de médiation pour les aspects commerciaux offert par la plate-forme communautaire facilite les intéractions enter consommateurs et fournisseurs.Le service traite et fait suivre les requêtes des consommateurs vers les fournisseurs ;de même pour la réponse des fournisseurs vers les consommateurs. Le traitementeffectué par le service de médiation est principalement la génération de revenus pour laplate-forme communautaire (voir section 2.3.2.4). Le consommateur de services de typesociaux ou de contenu utilise ce mode d’intéraction pour demander l’accés au contenupublié par les membres de la communauté.

Abonnement-Notification : Ce mode d’intéraction est semblable au précédent. La


différence se situe dans la notion d’abonnement. Le consommateur s’abonne puis reçoitde manière régulière ou non des informations, jusqu’à résiliation de son abonnement.Par exemple un consommateur de service social s’abonne à un service pour savoir quandun membre est connecté.

2.3.2.3 Bénéfices de l’approche

Le modèle économique que nous avons décrit est bénéficiable à tous les acteurs quile composent et ce pour les raisons que nous détaillons ci-après :

Considération de la mobilité : La prise en compte du facteur de mobilité pour les acteursaussi bien producteur que consommateur a pour conséquence la mise en œuvre deservice accessible partout et à chaque instant. De plus, les membres de la communautépeuvent accéder à des fonctionnalités de type réseaux sociaux sur leurs mobiles.

Mise en relation : La fonction de mise en relation qui est fournie par la plate-formecommunautaire établit la concordance ou non d’intérêts entre les membres de la commu-nauté et/ou avec les fournisseurs de produits/services. La plate-forme communautairepropose des sous communautés appropriées aux membres et suggèrent aux membres denouveaux contacts pour intéragir. La sensibilité au contexte dans la fonction de mise enrelation permet de trouver le meilleur service en fonction du contexte du consommateur.

Service de médiation pour les aspects commerciaux : Le service de médiation pour lesaspects commerciaux s’occupe des transactions commerciales pour le consommateur.Par exemple il peut lui éviter d’entrer de nombreuses fois ses coordonnées bancaires.

2.3.2.4 Source de revenus

Le modèle que nous proposons a un potentiel pour la génération des revenus àpartir de ventes d’abonnements, d’affiliation et de partage des revenusu entre la plate-forme communautaire et le fournisseur de services ainsi que par la publicité. Pourplus de détails concernant l’aspect de génération des revenus, nous nous référerons à[Leimeister04, Rothaermel01].

2.3.3 Spécifications des services

De nos jours, l’approche SOA est une choix populaire dans le développement desapplications car il facilite le développement, déploiement et l’usage de services spécifiés,flexibles et réutilisables dont les interfaces sont indépendantes du langage d’implémen-tation. Nous avons choisi le paradigme SOA pour le design de communautés virtuellesmobiles. Pour être viable, la plate-forme supportant les communautés virtuelles né-


FIGURE 2.7 – Vue globale de la plate-forme technique

cessitent un certain nombre de spécification en termes de services, afin de supporterl’intégration des consommateurs et producteurs, fixes ou mobiles.

Nous présentons ici un nombre restreint de services basiques dédiés au support desfournisseurs et consommateur mobiles, puisque c’est l’apport majeur de notre approche.La définition de service dans cette section doit être comprise au sens de l’approche SOAet non plus au sens du modèle économique présenté dans les sections précédentes.

2.3.3.1 Services pour la plate-forme communautaire

Nous décrivons ici les spécifications relatives à la plate-forme de communauté, tellequ’elle est représentée en figure 2.7.

Service de gestion des membres : Ce service fournit les fonctionnalités telles que l’en-registrement des nouveaux membres, la gestion des profils, les rôles des membres(producteur, consommateur), login et gestion des sessions.

Service d’annuaire : Ce service fournit un annuaire qui permet de lister les offrescommerciales de produit ou de services, à la manière d’un service de pages jaunes.

Gestion de communauté : Ce service est composé des différentes fonctionnalitésrequises pour créer, rejoindre, accéder aux sous-communautés de la plate-forme, ainsique pour la publication, la lecture ou l’abonnement aux flux de ces communautés.

Service d’intéraction sociale : Ce service gère les intéractions entre les membres dela communautés. Ce qui inclut des fonctionnalités telles que le dialogue en direct, lesnotifications, et la souscription aux flux d’un membre.


Service de mise en relation sensible au contexte : Ce service est utilisé pour trouverdes membres potentiels pour les nouvelles sous-communautés. Le service de mise enrelation est vital au bon fonctionnement du modèle économique décrit ci-dessus. Siun membre de communauté est intéressé par un type particulier de service (qui peutcomprendre plusieurs instances de service), le service de mise en relation choisira selonle contexte de l’utilisateur lequel de ces services lui sera proposé, selon l’approche définidans [Hesselman06].

Service de médiation pour les aspects commerciaux : Le rôle du service de médiationest de fournir aux membres l’accés aux différents services et produits listés dans laplate-forme et de gérer les transactions au nom des membres. A cette fin, le servicede médiation est constitué d’un module centralisé de facturation. La plate-forme decommunauté contient une base de données qui contient entre autres les profils desutilisateurs, la liste des services et produits ainsi que les informations de facturation. Lesintéractions sociales entre les membres sont aussi stockées dans cette base de données.

2.3.3.2 Spécification sur le système mobile

Les services basiques suivants sont requis sur le système mobile pour permetrrel’utilisation de la plate-forme communautaire.

Service d’échange de contenu : ce service a pour but d’envoyer le contenu (textuel,visuel) généré par l’utilisateur du dispositif mobile à la plate-forme communautaire afinque ce contenu soit publié dans les communautés adéquates. De la même manière ceservice d’échange s’abonne et reçoit les informations des communautés auxquelles lemembre appartient. Ce service transforme le dispositif mobile en producteur de contenusocial et en consommateur de services commerciaux ou sociaux.

Service mobile commercial : le rôle de ce service est de permettre au dispositif mobile dedevenir un fournisseur de services commerciaux. Ce service peut réutiliser le composantsocial décrit ci-dessus dans le cadre des échanges de contenus. En dehors de ce cas, lesfonctionnalités supplémentaires doivent être implémentées sur la machine, en fonctionde la nature du service, que nous ne précisons pas ici.

Service d’information de contexte : Ce service obtient les informations de contexte(localisation) à partir du dispositif mobile de l’utilisateur et envoie ces informations entemps-réel à la plate-forme communautaire. Ces informations sont ensuite utilisées parle service de mise en relation.

2.3.4 Plate-forme technique

Notre choix technologique pour l’implémentation des services au niveau de la plate-forme communautaire sont les Services Web. Ce choix d’architecture SOA se justifie


par l’interopérabilité et la facilité de déploiement des Services Web. A la différence desservices situés sur le réseau fixe dont les problématiques sont classiques, l’utilisation et lamaintenance de services moibles posent un certain nombre de problèmes en particulierdues à la connectivité intermittente, à la limitation des ressources ainsi qu’à la mobilitéde l’utilisateur. Comme cela a été identifié dans [Pawar07], il existe trois approchesdifférentes pour la problématique des services mobiles : les micro-services, les micro-host et la Mobile Service Platform (MSP). Notre choix s’est porté sur la technologie MSP,tout d’abord pour son support des flux de contenu ainsi que pour la connaissancetechnologique que nous en avions. MSP est un middleware basé sur un proxy situé dansle système de surrogate Jini 1. Les spécifications initiales de MSP ne supportant pas unearchitecture SOA, nous avons étendu cette dernière pour intégrer la gestion des servicesweb. La mise en place d’un service nomadique (service fourni par un composant mobile)en utilisant MSP se fait à l’aide de deux composants :

1. Une application réalisant le service, située sur le mobile, que l’on nomme servicesur mobile.

2. Une représentation du service sur la partie fixe du réseau que l’on nomme surrogateou substitut.

Le substitut fonctionne comme un proxy pour le service sur mobile et intervient dansla découverte de services réseaux. Un hôte substitut permet de gérer plusieurs substituts.L’architecture MSP est composée des éléments suivants :

1. MSP-I/O qui se trouve sur le système mobile et intéragit avec le service fourni.

2. MSP-Interconnect est déployé sur le substitut hôte et intéragit avec le substitut.

3. MSP-Messages spéficie la structure des messages échangés entre le mobile et lesubstitut. Ces échanges se font en utilisant le protocole HTTP.

L’architecture de notre plate-forme technique est présentée en figure 2.7. La plate-forme communautaire est une extension du logiciel open source Dolphin 2, développé enPHP. Dolphin a été installé sur un serveur Apache et une base de données MySQL. Ducôté de la plate-forme communautaire, les web services ont été implémenté en PHP. Lesservices commerciaux mobiles, d’information de contexte sont développés en tant queservice nomadique. Pour l’interopérabilité entre les services mobiles et la plate-formecommunautaire, des interfaces spéciales ont dues être développées pour permettre auclient Jini de fonctionner en tant que service web et le substitut en tant que client deservice web. Pour réaliser ces interfaces nous avons utilisé Eclipse WTP.

1. http://www.jini.org2. http://www.boonex.com/dolphin/

http://www.jini.org

http://www.boonex.com/dolphin/


2.3.5 Application

Le cas présenté ici se situe dans le domaine de l’informatique de santé mobile (m-health). Bob le patient et Alice l’ambulancière rejoignent la plate-forme communautaire.Le centre de santé local crée une sous-communauté nommé HCC (pour Health CareCommunity en anglais). Le service de mise en relation recommande à Alice, Bob etd’autres membres de rejoindre la communauté HCC. Bob et Alice rejoignent la com-munauté en mettant à jour leur profil avec les informations nécessaires à HCC (lestroubles dont souffre Bob, . . .). Le service de mise en relation recommeade à chacun derejoindre le réseau social de l’autre, en se basant sur les informations fournis au profilHCC. Bob, Alice et d’autres peuvent ainsi établir des liens, se rencontrer, pour partagerleurs expériences. Pendant ce temps, le HCC annonce qu’il met à disposition un systèmede télé-surveillance des patients atteint d’épilepsie. Pour faciliter cette surveillance,différents fabricants de réseaux de capteurs corporels (BAN pour Body Area Network)qui jouent ici le rôle de fournisseurs de produits, proposent leur produits. Le système derecommandation propose à Bob un BAN compatible avec son PDA. Bob (consommateurde produit) achète le BAN et s’abonne au service de télé-surveillance via la plate-formecommunautaire. Alors que Bob est atteint d’une crise épilepsie, le BAN détecte la criseet transmet les informations via son PDA à la plate-forme communautaire. Le servicede télé-surveillance recherche alors l’ambulance la plus proche de Bob. Le système demise en relation sensible au contexte lui indique alors qu’Alice est la plus proche de Bob.HCC invoque alors le service d’Alice (service commercial) pour qu’Alice fournisse lessoins d’urgence à Bob.

2.3.6 Conclusion

Au cours de ces travaux, nous avons étudié le modèle économique des communau-tés virtuelles au sein desquelles les utilisateurs mobiles pouvaient être non seulementconsommateur, mais producteur de services. Nous avons sur une approche orientéeservices pour la réalisation de notre plate-forme technique basé sur ce modèle écono-mique. Nous avons concentré notre travail sur l’aspect service mobile ainsi que sur lesspécifications de la plate-forme communautaire. L’utilisation combinée des données decontexte ainsi que service mobile permet la création de fonctionnalités avancées au seinde la plate-forme communautaire.

Ces travaux permettent de mettre en lumière le potentiel économique des commu-nautés virtuelles, notamment dans les applications mobiles. Les communautés virtuellesde connaissances sont ici un sous ensemble de la communauté, puisqu’elle recouvrela partie contenu social des intéractions, néammoins elles présentent un fort potentieléconomique que le modèle économique présenté permet d’exploiter.


2.4 Scénario 3 : Projet DRPI

But : partage de documents entre chercheurs et échanges par voie électronique.Contexte du projet. Role du VKN. Mise en place de la plate-forme [Elmorr08,Subercaze09, El Morr09]

Le projet DRPI 3 (Disability Rights Promotion International ) est un projet internationalvisant à surveiller les violations des droits des handicapés dans le monde. Le projet estdivisé par pays. Nos travaux se sont focalisés sur la partie DRPI Canada, qui est un desmembres fondateurs du projet. Ce projet rassemble des acteurs académiques aussi bienque des membres de la communauté des handicapés.

L’approche holistique choisie par le comité de pilotage du projet DRPI se concré-tise par une communication continue et un partage des ressources, méthodologies etapproches des quatre thèmes du projet. Ces quatre thèmes définis ci-après, doivent per-mettre de couvrir et d’obtenir les informations sur les nombreux types de discriminationdont peuvent souffrir les handicapés :

– Surveillance des expériences personnelles : des personnes souffrant d’un handicapsont impliquées dans la surveillance et peuvent faire part de leurs expériencespersonnnelles de discrimination.

– Surveillance des médias : les productions médiatiques concernant le handicap sontanalysées à travers le prisme des droits de l’homme.

– Surveillance des aspects juridiques : le statut actuel et l’évolution de la législationsont suivis pour s’assurer du respect des droits fondamentaux des personnessouffrant d’un handicap.

– Surveillance des statistiques et sondages : le but est ici de s’assurer que les données,sondages et statistiques sont recueillies dans le respect de la législation concernantles handicapés.

Il est aussi fondamental de construire un partage de la connaissance au sein de lacommunauté, pour promouvoir une prise de conscience des discriminations dont sontvictimes les handicapés, afin qu’il participent eux aussi aux respects de leurs droits.Dans ce contexte, un système complexe est requis pour faciliter la collaboration d’unspectre varié de participants autour des quatre thèmes énoncés ci-dessus : chercheurs,représentants de la communauté, législateur et grand public.

2.4.1 Communautés virtuelles

Les communautés virtuelles (VC par la suite) ont reçues une certaine attention dela part des communautés en informatique, sociologie, psychologie, ainsi que d’autresdisciplines [Preece00]. Une communauté virtuelle est une forme de système social, il

3. http://www.yorku.ca/drpi/

http://www.yorku.ca/drpi/

Section 2.4. Scénario 3 : Projet DRPI 49

hérite de certaines des caractéristiques de notre système social [Weissman00]. Les com-munautés virtuelles peuvent être classées selon différentes perspectives [El Morr07,Kawash05, Stein05], parmi les différents types de VC, existe celui de réseau de connais-sance (Knowledge Network en anglais). Les réseaux de connaissance sont des communau-tés au sein desquelles les participants capturent, accèdent, utilisent, créent et définissentdes connaissances [Merali01]. Notre propos est de spécifier et d’implémenter un ré-seau de connaissances pour la génération et la dissémination de connaissances dans lecontexte du projet DRPI. Notre plate-forme VC-KM (gestion de connaissance et commu-nauté virtuelles) est un modèle hybride qui supportent différents niveaux d’approches[Jansen02]. Dans chaque thème de recherche du projet, les chercheurs et les membresde la communauté gèrent des activités complexes extrêmement variables alors que ladissémination d’une partie des connaissances au grand public doit se faire avec sim-plicité. Beaucoup de plate-formes de communautés virtuelles existent, notamment enopen-source. Malheureusement aucune n’est adaptée au besoin de notre projet en termede relation entre les membres, gestion de la confidentialité (complexe ici avec les dif-férents types de membres), édition collaborative sde documents , partage à différentsniveaux de granularité. De plus, aucun des sites ne vérifie le niveau d’accessibilité auxhandicapés requis par ce projet.

2.4.2 Design de la plate-forme et implémentation

Dans le domaine du handicap, les outils et resources pour la collecte de donnéessont épars, de même que les outils et méthodes pour les différents niveaux d’analyse(individuel, systèmique) et particulièrement ceux dédiés au contexte canadien. Undes besoins importants est de permettre un apprentissage continu et permettre dedévelopper les capacités d’analyse dans le contexte de la surveillance des droits (àl’aide de manuel, vours, exercices, livres . . .). De manière interne aux chercheurs, lacommunauté doit permettre aux chercheurs de collaborer efficacement, de vérifier etvalider les propositions. La communauté doit faciliter la création de connaissances ainsique la recherche au sein de la plate-forme. En effet les productions attendues sont trèsnombreuses et la recherche d’information jouera un rôle primordial pour le succés dela plate-forme. Notre plate-forme a été conçue autour des aspects suivants (voir figure2.8) :

1. Création de connaissance

2. Découverte de connaissance

3. Dissémination des connaissances

4. Gestion des membres et des accés


Communauté

virtuelle de

Création de

connaissances

Dissémination

des Découverte de

connaissancesvirtuelle de

connaissances

des

connaissances

Gestion de

communauté

connaissances

FIGURE 2.8 – Vue d’ensemble des composants de la plate-forme collaborative

2.4.2.1 Implémentation de la plate-forme

La plate-forme a été développé sous la forme d’une application Web en JAVA hé-bergée dans un container de Servlet Tomcat et d’une base de données sous Derby. Lesfonctionnalités classiques de gestion des membres ont été développées, ainsi qu’unsystème de création de communautés.

Cinq communautés ont ensuite été créées, quatre autour des thèmes du projet etrestreintes aux participants, la cinquième étant ouverte au grand public. Deux niveauxont été créé, administrateur et membre. Chaque administrateur gère sa communauté, unsuper administrateur gérant la plate-forme globale (voir fig 2.9). Chaque membre peutensuite devenir non seulement consommateur mais aussi producteur de contenu. Lacommunauté publique est la seule qui ne nécessite pas l’approbation de l’administrateurpour pouvoir la rejoindre. Les membres des communautés autre que celle publique, sontessentiellement des chercheurs, donc producteurs de contenu. Néanmoins ils sont aussiconsommateurs des informations échangées et produites par leurs collègues.

Les administrateurs et les membres des communautés peuvent envoyer des docu-ments sur la plate-forme et assigner une visibilité à chacun de leur fichier (voir figure2.10). Chaque membre peut décider si son document est visible par un membre ou par


FIGURE 2.9 – Création d’une nouvelle communauté

une communauté. Le droit individuel étant prioritaire sur le droit global. Il est doncpossible d’exclure un membre d’une communauté pour la visibilité d’un document.

2.4.2.2 Ergonomie et accessibilité

Pour s’assurer de l’ergonomie du portail, nous avons suivi les guide des bonnespratiques du département de la santé américaine 4 et nous avons utilisé un code XHTMLqui satisfait aux normes W3C ainsi qu’un nombre réduit d’images pour ne pas pénaliserles handicapés visuels. L’apparence du site est claire et légère (en temps de chargement),de conception classique avec un menu à gauche et une navigation possible par raccourciclavier.

2.4.3 Gestion des connaissances

Deux tendances prédominent actuellement la conception de la gestion des connais-sances, l’approche centrée utilisateur et l’approche centrée technologie de l’information.En nous basant sur les expériences passées [Davenport99] nous avons appliqué un cer-tain nombre de bonnes pratiques pour la réalisation de notre plate-forme spécifique audomaine de la santé et du handicap. Notre approche étant essentiellement technique,ces pratiques simples telles qu’une structure flexible pour l’application, une accessibilitéavancée ont été mises en œuvre des spécifications jusqu’à l’implémentation.

Au sein de la plate-forme de nombreux utilisateurs produisent un large nombrede documents qui seront répartis entre les différentes communautés. Deux problèmes

4.


FIGURE 2.10 – Un membre choisissant la visibilité de ses documents, soit pour desmembres ou pour des communautés


FIGURE 2.11 – Edition des mots-clés après extraction


FIGURE 2.12 – Un membre choisissant la visibilité de ses documents, soit pour desmembres ou pour des communautés

majeurs ont été identifiés et nous avons développé des solutions pour les résoudre. Toutd’abord, la recherche de documents dans un grand ensemble de documents hétérogènes(plate-forme) est un problème important. L’utilisateur doit pouvoir accéder rapidementet efficacement au contenu qu’il recherche. Ensuite, le nombre de membres du projetétant amené à croître rapidement, un certain nombre de productions risque de passerinaperçu, noyé dans la masse du contenu. Par conséquent il est important de faciliter larecherche et la découverte de connaissances au sein de la plate-forme.

Pour résoudre ce problème, nous avons conçu un système de description des docu-ments et des utilisateurs qui permet de

1. notifier les utilisateurs quand un document qui les intéressent potentiellement aété mis en ligne

2. faciliter la recherche d’information

3. détecter des similarités de profils entre les utilisateurs

Les étapes de ce processus sont décrites en figure 2.12. Le document est tout d’abord misen ligne par utilisateur. Le système d’extraction automatique propose des mots-clés àl’utilisateur qui choisit d’en rajouter ou d’en supprimer (fig 2.11). Ensuite le document estindexé par la plate-forme. Les utilisateurs ayant un profil correspondant à la descriptiondu document sont prévenus par email (système dit push).

Section 2.5. Conclusion 55

A terme, nous utiliserons les données de navigation pour extraire les centres d’intéretde l’utilisateur [Widyantoro01]. Nous avons utilisé le système KEA pour extraire lesmots-clés d’un document. Le modèle a tout d’abord été entrainé sur une cinquantainede documents annotés par nos soins. Les résultats de ce modèle d’extraction dédié àl’informatique médicale et au handicap sont très bons.

2.4.4 Conclusion

La création d’une plate-forme Web supportant les communautés virtuelles deconnaissances relatives au projet DRPI a permis d’assurer le lien entre chercheurs,étudiants et membres de la communautés. L’utilisation des communautés s’est faiteici dans un cadre statique, le nombre de communauté étant fixe et n’évoluant pas aucours du temps. Ce contexte particulier nous a conduit à développer une approche ducomportement de l’utilisateur ainsi que de l’analyse des documents qui nous a amenéà réaliser un système avancé de type push. Ce système permet d’augmenter grande-ment la dissémination des connaissances en comparaison avec un système classique derecherche.

2.5 Conclusion

La présentation du cadre théorique ainsi que de trois scénarios d’application apermis de préciser le cadre de nos travaux. L’analyse de la structure d’un sytème degestion de connaissances selon l’approche AOA de Calmet a permis de donner desdéfinitions de la connaissance d’entreprise A partir de ces définitions et suivant lamême approche d’abstraction que pour l’AOA, le concept résultant de l’analyse sont lescommunautés virtuelles de connaissances qui fournissent un cadre de travail prenanten compte les différents aspects d’autonomie, de décentralisation, de modélisationdes connaissances ainsi que des mécanismes d’échanges. Le concept de communautésvirtuelles de connaissances permet de diffuser et d’étendre les connaissances d’unesociété d’agents. La connaissance n’est pas limitée au domaine d’intérêt de chaque agentmais comprend aussi les connaissances des mécanismes d’échanges, de "traduction" desontologies et du comportement social (individualiste, social). L’implémentation d’unprototype a permis de mettre en œuvre les différents aspects.

Les trois scénarios ont mis en valeur le potentiel d’applications qui découlent descommunautés virtuelles de connaissances.Le framework proposé dans le premier scéna-rio, basé sur des échanges de connaissances entre des agents de contexte et des agentspersonnels au sein de communautés permet l’intégration dynamique de nouveaux cap-teurs sans respécification de l’application. L’intégration d’un second capteur d’activitédans le cadre du scénario applicatif du réveil nécessite seulement la mise en place d’un


agent de contexte lié à ce second capteur et de la modification des règles de décisionde l’agent personnel pour gérer les cas ou les deux capteurs fourniraient des niveauxd’activité différents. Cette approche décentralisée permet de tirer pleinement parti del’aspect autonomie que présente l’approche agents et le scénario du réveil permet d’illus-trer son fonctionnement. Le synthétiseur est le composant innovant de cette approchequi permet de transformer les informations de l’agent en connaissances échangeablesavec les autres agent. Ces échanges basés sur les VKC permettent l’ajout dynamique denouveaux capteurs et mettent en lumière l’aspect dynamique et flexible des VKC.

Dans le deuxième scénario nous avons étudié le modèle économique des communau-tés virtuelles au sein desquelles les utilisateurs mobiles pouvaient être non seulementconsommateur, mais producteur de services. Nous avons sur une approche orientée ser-vices pour la réalisation de notre plate-forme technique basé sur ce modèle économique.Nous avons concentré notre travail sur l’aspect service mobile ainsi que sur les spécifica-tions de la plate-forme communautaire. L’utilisation combinée des données de contexteainsi que service mobile permet la création de fonctionnalités avancées au sein de laplate-forme communautaire. Ces travaux permettent de mettre en lumière le potentieléconomique des communautés virtuelles, notamment dans les applications mobiles. Lescommunautés virtuelles de connaissances sont ici un sous ensemble de la communauté,puisqu’elle recouvre la partie contenu social des intéractions, néammoins elles présententun fort potentiel économique que le modèle économique présenté permet d’exploiter.

Le troisième scénario a montré la conception et l’implémentation d’une plate-formeWeb supportant les communautés virtuelles de connaissances relatives au projet DRPI,plate-forme qui permet d’assurer le lien entre chercheurs, étudiants et membres de lacommunautés. L’utilisation des communautés est faite ici dans un cadre statique, lenombre de communauté étant fixe et n’évoluant pas au cours du temps. Ce contexteparticulier nous a conduit à développer une approche du comportement de l’utilisa-teur ainsi que de l’analyse des documents qui nous a amené à réaliser un systèmeavancé de type push. Ce système permet d’augmenter grandement la dissémination desconnaissances en comparaison avec un système classique de recherche.

2.5.1 Discussion

Dans la définition des VKC donnée dans la première section, la base de connaissancesne contient pas seulement des ontologies, mais aussi trois autres composants (cognition,communication et sécurité). Cependant, l’implémentation montre une différence detraitement entre les différents composants. En effet les ontologies sont les seules partiesde la base de connaissances qui sont échangeables entre les agents. Les trois autrescomposants sont programmés sont internes à l’agent. En premier lieu on pourrait croireque c’est le langage d’implémentation des agents qui ne permet pas réutiliser le code dechacun des composants. Mais ces agents, basés sur JADE, sont programmés en JAVA, le


JAVA proposant des fonctionnalités de réflection dans le package java.lang.reflectet offre la possibilité de transférer des portions de code exécutables entre des programmesJAVA. Cette limitation dans le transfert des connaissances provient de l’architecture desagents JADE. Les agents sont conçus pour échanger des messages au format FIPA-ACLet pour gérer de manière interne des ontologies. Les parties exécutables qui sont lescomportements (dans le package jade.core.behaviours) ne sont pas conçus pourêtre échangés et intégrés dans les agents.

L’implémentation a permis de mettre en lumière deux problèmes. Le premier estl’hétérogénéité des composants de la base de connaissances. Les formalismes de repré-sentation des connaissances au sein de l’implémentation sont hétérogènes : les ontologiessont au format RDF, les composants responsables de la communication, cognition etsécurité sont programmés en JAVA (une partie de la sécurité est en RDF, pour la des-cription des politiques). Cette hétérogénéité combiné aux limitations de l’architectureJADE, rend une partie de la connaissance seulement interne aux agents. Le deuxièmeproblème découle du premier et pose des questions plus théoriques. La distinctionentre les parties échangeables et non échangeables de la base de connaissances soulèveplusieurs questions : une connaissance qui n’est pas échangeable est-elle une connais-sance ? si oui, dans quelle mesure est-elle utile pour le système ? Quand peut-on parlerde connaissance ? Ces questions levées par un problème technique sont en fait d’ordrethéorique et touchent à la nature même de la connaissance. De la même manière quel’AOA s’inscrit dans le cadre d’une théorie sociologique, il nous apparait important depréciser le cadre épistémologique dans lequel nous nous plaçons. Notre état de l’art seporte donc en premier lieu sur la notion de connaissance et de comment cette connais-sance peut être mise en œuvre au sein d’un système informatique. Nous discutons danscette partie de la notion de connaissance au sens théorique, c’est-à-dire dans le domainede l’épistémologie ainsi que le domaine de la connaissance appliquée qu’est la gestiondes connaissances.

La distinction entre les composants échangeables et non échangeables (au sensd’échange entre agents et non au sens d’interchangeable) de la base de connaissancesse fait selon un critère simple. Les ontologies sont statiques et ne donnent pas lieu àune exécution de code. Les autres composants sont des composants exécutables par lamachine. Le but que nous nous fixons au cours de cette thèse, est de réussir à unifierla base de connaissance, au sein d’un même formalisme afin de permettre l’échangede n’importe quelle connaissances. Nous avons vu que la limitation était imposée parl’architecture des agents JADE et par l’hétérogénéité des connaissances dans la base. Unenouvelle architecture d’agent supportant une nouvelle base de connaissances doit êtremis en œuvre. Les deux domaines qui nous concernent, les agents (pour l’architecture) etla représentation des connaissances (pour l’hétérogénéité) sont étudiés dans les sectionssuivantes de l’état de l’art.


Les trois scénarios ont mis en évidence les domaines d’application variés des com-munautés virtuelles de connaissance. La mobilité, les applications sensibles au contexte,le partage de documents et de connaissances sont autant de domaines ou nous avonsmis en œuvre ces communautés. Chacun de ces scénarios a montré un cas d’applicationdifférent, nécessitant le développement de composants additionnels : sur JADE-LEAPdans le premier scénario, d’interface pour les services Web dans le second et d’une plate-forme web pour le dernier. Pour les deux premiers, ce sont les problèmes de mobilitéqui ont entrainé des extensions du prototype existant. Le dernier projet nous montreun chemin qui intéresse plus nos recherches. En effet les VKC ne sont pas seulementun espace d’échanges de messages comme nous l’avons vu dans la première partie dece chapitre. Une première constatation s’impose. Les VKC fonctionnant à l’aide d’untampon de messages ne sont qu’un instance de la classe des VKC. Ces VKC comprennenttous les modes d’échanges entre agents. Se pose alors la question de la définition, dela formalisation de ces communautés au sens plus large. Ces communautés une foisformalisée peuvent alors devenir une connaissance. Savoir utiliser une communautédoit alors devenir une connaissance échangeables entre deux agents .

En résumé notre thèse se propose de répondre aux problèmes suivants :– Intégrer tous les éléments de la base de connaissances pour les rendre échangeables

et utilisables par les agents. Concevoir une architecture d’agent à cette fin.– Comment les agents peuvent-ils intégrer ces nouveaux types de connaissances

dans leurs bases de connaissances.– Formaliser et rendre les communautés virtuelles de connaissances utilisables et

échangeables pour les agents que nous aurons définis.

L’universalité des hommes se repaît de l’apparence comme de la réalité ; souventmême l’apparence les frappe et les satisfait plus que la réalité même.

Nicolas Machiavel - "Discours sur la première Décade de Tite-Live"

3Etat de l’art

60 Chapitre 3. Etat de l’art

Plan du chapitre

3.1 Connaissances et gestion des connaissances . . . . . . . . . . . . . . . 613.1.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.1.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.1.3 Gestion des connaissances distribuées . . . . . . . . . . . . . . 683.1.4 Conclusion de l’état de l’art sur la gestion des connaissances . 70

3.2 Représentation des connaissances et Web Sémantique . . . . . . . . . 713.2.1 Web Sémantique . . . . . . . . . . . . . . . . . . . . . . . . . . 723.2.2 Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723.2.3 Historique du Web Sémantique . . . . . . . . . . . . . . . . . . 733.2.4 Standards du Web Sémantique . . . . . . . . . . . . . . . . . . 753.2.5 Raisonneurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823.2.6 Conclusion de l’état de l’art sur le Web Sémantique . . . . . . 83

3.3 Agents et Systèmes multi-agents . . . . . . . . . . . . . . . . . . . . . . 843.3.1 L’agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843.3.2 Les systèmes multi-agents . . . . . . . . . . . . . . . . . . . . . 863.3.3 Domaines d’applications . . . . . . . . . . . . . . . . . . . . . . 873.3.4 Différents niveaux d’approche . . . . . . . . . . . . . . . . . . 873.3.5 Approche abstraite . . . . . . . . . . . . . . . . . . . . . . . . . 883.3.6 Architectures standards . . . . . . . . . . . . . . . . . . . . . . 893.3.7 Critères d’analyses . . . . . . . . . . . . . . . . . . . . . . . . . 943.3.8 Langages de programmation agents . . . . . . . . . . . . . . . 963.3.9 Plates-formes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1073.3.10 Applications agents basés sur des connaissances . . . . . . . . 1113.3.11 Conclusion de l’état de l’art sur les agents . . . . . . . . . . . . 121

3.4 Analyse et mise en perspective . . . . . . . . . . . . . . . . . . . . . . . 1223.4.1 Agents et composants . . . . . . . . . . . . . . . . . . . . . . . 1233.4.2 Echanges des différents types de connaissances . . . . . . . . 1263.4.3 Un modèle unifié des connaissances et des comportements . . 127

3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1303.5.1 Conclusion de l’analyse . . . . . . . . . . . . . . . . . . . . . . 133

Section 3.1. Connaissances et gestion des connaissances 61

LA gestion distribuée des connaissances est un domaine qui se situe à l’intersectionde plusieurs champs de recherche. Au nombre de trois, ces domaines existent in-

dépendemment de notre domaine d’étude. Nous allons présenter dans ce chapitre cesdifférents domaines. Nous commencerons tout d’abord par l’épistémologie qui est lascience de la connaissance, que nous mettrons en parallèle avec l’approche moderne dela gestion des connaissances dans les organisations. Nous présenterons ensuite les tech-niques de représentation des connaissances. Le dernier domaine que nous présenteronsest le paradigme multi-agents ainsi que ses applications au domaine de la gestion desconnaissances.

3.1 Connaissances et gestion des connaissances

LA notion de connaissance en informatique peut être abordée de différentes ma-nières, selon des considérations théoriques ou opérationnelles. L’épistémologie

est la science de la connaissance, et elle préexiste évidemment à l’informatique. Avecl’avènement de l’informatique, on peut distinguer plusieurs branches de recherches. lagestion des connaissances, issue du monde l’entreprise. L’épistémologie appliquée àl’informatique, qui s’interroge sur la notion de connaissance dans les systèmes informa-tiques. Le domaine de la représentation des connaissances, s’occupent des formalismespermettant de représenter les connaissances. L’extraction des connaissances, qui traitedes manières automatisables de découvrir des connaissances à partir de données. Cetteliste n’entend pas être exhaustive, mais donne un aperçu du panel des recherches autourde la connaissance et de l’informatique.

Nos recherches portent sur les différents types de connaissance et la manière de lestransférer entre agents (voir discussion, chapitre précédent).

La gestion des connaissances est un domaine de recherche très actif depuis les années90, époque à laquelle lui a été donné son nom actuel. Cependant ce champ a existéauparavant sous différents noms. C’est dans ces différents courants que l’on trouve sesracines. La gestion des connaissances telle que nous la connaissons aujourd’hui est trèsliée aux technologies numériques et aux réseaux. Pour mieux comprendre ce champ derecherche nous donnons plusieurs définitions pour introduire le cadre dans lequel nousnous plaçons. Nous présenterons ensuite un historique de la gestion des connaissances.

3.1.1 Définitions

Pour aborder l’état de l’art de la gestion des connaissances, il nous faut tout d’abordintroduire le concept de connaissance. Nous allons aborder cette question en deux temps.Tout d’abord la philosophie de la connaissance ou épistémologie a fourni tout au longde l’histoire un certain nombre de définitions et de discussions. Nous détaillerons les


différentes approches philosophiques et épistémologiques. L’apparition de la gestiondes connaissances au cours de années 80 a donné lieu à une autre approche, pluspragmatique, de la connaissance. Nous présenterons et discuterons les définitions dela connaissance au sens de la gestion de connaissance, puis nous établirons les pointscommuns et différences dans ces deux approches.

3.1.1.1 Théorie de la justification

Une des premières définitions nous vient de Platon dans son Théétète [Platon.94](201d) :

Définition (La connaissance, selon Platon). « La connaissance est une opinion droite pourvuede raison ».

Une opinion droite pour Platon est une opinion qui est vraie dans le sens ou ellecoincide avec la réalité. Pour autant cette coincidence avec la réalité pourrait être acciden-telle, dans ce cas la connaissance n’aurait pas de valeur pour Platon. Il donne l’exemplede la plaidoirie mensongère de l’avocat qui peut convaincre ses jurés à l’aide d’argu-ments faux. Pour autant cette plaidoirie ne constitue pas une connaissance puisque sesfondements sont erronnés. Platon pose donc la restriction suivante : l’opinion droitedoit être « pourvue de raison ». Si par exemple je regarde la position de la lune poursavoir si le Paris Saint-Germain gagnera la coupe de France cette année, il se peut quel’interprétation que j’en fasse soit cohérente avec la défaite du club, pour autant je n’aipas de raison de croire que la position de la lune puisse m’indiquer la victoire ou défaitedu Paris Saint-Germain. Le terme "pourvue de raison" n’est donc pas ici par le fruit duhasard. La raison, pour Platon, doit permettre d’établir la validité de la connaissance.C’est-à-dire, que l’on doit être capable, par un raisonnement logique, de convaincrel’interlocuteur de la véracité de notre propos. Ce raisonnement, ne doit donc pas êtreerronné ou volontairement fallacieux.

La distinction est faite par Platon entre les connaissances qui sont « empiriques »,c’est à dire qui relèvent d’une connaissance empirique et les connaissances démontrablesque l’on a énoncées ci-dessus. Les connaissances empiriques ou empiriques, commepar exemple connaître le chemin d’un point A à un point B relèvent de l’opinion droiteet ne nécessitent pas de démonstration. Si quelqu’un me demande le chemin pouraller au point B, je peux lui donner le chemin que je connais, pour autant je ne peuxpas lui démontrer que je connais ce chemin. Mon interlocuteur doit expérimenter lechemin pour être convaincu de ma connaissance de ce chemin. Ces connaissances sontdonc distinctes des connaissances qui nécessitent une « opinion droite pourvue deraison », puisqu’elles ne nécessitent pas de « raison valable », seule l’expérience peutalors convaincre l’interlocuteur.


La théorie classique de la connaissance, ou épistémologie, se base sur la définitionde la connaissance comme une croyance vraie et justifiée (justified true belief ou JTB enanglais). Une connaissance est donc une chose dont on peut donner une démonstrationqu’elle est connaissance (à l’exception des connaissances empiriques). De manière fo-melle, cette définition dite de la croyance vraie justifiée s’exprime de la manière suivante,un sujet S sait qu’une proposition P est vraie si et seulement :

1. P est vraie

2. S croit que P est vraie

3. la croyance de S dans p est justifiée

Cette définition était globalement acceptée jusqu’à ce qu’en 1963 le philosopheEdmund Gettier, exhibe des contres-exemples à cette définition. Contre-examples danslesquels des croyances peuvent à la fois être vraies et justifiées sans pour autant constituerune connaissance [Gettier63]. Voici un contre-exemple « à la Gettier » :

Alice a un ami Bob qui possède une guitare Stratocaster avec laquelle iljoue depuis des années. Alice pense donc que Bob joue sur une Fender. MaisAlice ne sait pas que Bob avait brisé sa Stratocaster dans un accés de folie lorsd’un concert et que pour la remplacer son choix s’est porté sur une Telecaster,c’est à dire un autre modèle de la marque Fender. Alice sait-elle que Bob joueavec une guitare de marque Fender ou bien le croit-elle seulement ?

Dans ce type d’exemple, la connaissance, même justifiée est seulement dûe à un ha-sard. Les travaux de Gettier ont une forte influence sur l’épistémologie et la philosophieanalytique moderne [Pacherie04], qui ont eu pour conséquences, non pas l’abandonde la définition de la connaissance comme JTB mais au contraire, sa mise en placecomme définition minimale sur laquelle sont venus se greffer de nouvelles conditionsqui excluent les contre-exemple de Gettier [Goldman86]. D’autres théories plus récentes,basées sur des redéfinitions du fait et de la vérité ont permis de nouvelles définitions dela connaissance, par exemple en s’inspirant des travaux du physicien Werner Heisenberg[Vilmer05].

Il existe d’autres théories de la connaissance, notamment sensorielle chez Locke oubasée sur la perception chez Hume. Ces définitions ne sont pour autant pas adaptablesà un système informatique, qui utilise une approche mécaniste de la connaissance.Notre travail se concentrera donc sur les définitions de la connaissance se basant sur lajustification.

Ainsi, en épistémologie, on a observé l’importance de la notion de justification (etdonc de démonstration) pour établir une connaissance vraie. Les exemples de Gettieront montré la limite de cette théorie basée sur une vérité « correspondantiste », c’est àdire où « une vérité est conçue comme correspondance entre un jugement subjectif et unfait objectif » [Vilmer05]. La notion de perception de la réalité, qui reviendra notamment


comme un de nos fondements lorsque nous aborderons les systèmes multi-agents,intervient ici dans le jugement subjectif que l’on a de la réalité.

3.1.1.2 Formalisme en intelligence artificielle

Comme le note Bachimont [Bachimont96] dans sa thèse, les systèmes à base deconnaissances doivent définir la nature de la connaissance pour déterminer la manièrede les opérationnaliser. Dans ses travaux, Bachimont se base sur les systèmes logiquesinférentiels. Il critique le formalisme de représentation des connaissances dans unesyntaxe formelle, en particulier sur la sémantique dont il permet de rendre compte, pourproposer un symbolisme emprunté à la langue naturelle, qui conjugue l’interprétabilitéet l’effectivité du symbolique.

La traduction de langage naturel dans un langage formel est un problème nécessairedans le traitement automatique des connaissances. Des interfaces sont toujours requisespour intéragir entre l’homme et la machine. Cette traduction s’opère dans deux sens pourles systèmes formels, tout d’abord la formalisation qui va de l’homme vers la machine,puis l’interprétation de la machine vers l’homme. Le principe des systèmes formels estleur capacité inférentielle qui permettent d’expliciter des connaissances certes existantesdans le système formalisé, mais qui ne sont pas encore apparus aux yeux de l’utilisateurhumain.

Les problèmes aux interfaces ne sont pas ici l’objet de cette thèse et nous nousfocalisons sur la représentation de connaissances qui ne sont pas inférentielles, maisexécutables au sens des agents, c’est-à-dire produisant un effet sur l’environnement. Cetype de connaissances n’entre pas dans le cadre d’un système formel inférentiel.

3.1.1.3 Connaissance au sens de la gestion des connaissances

Nous allons maintenant nous écarter du domaine de la philosophie pour étudier lesdéfinitions qui sont à l’œuvre dans le domaine de la gestion des connaissances.

La définition donnée par Samuel Johnson au 18 ième siècle [Boswell05] sert souventde base à la définition des connaissances au sens de l’entreprise :

Définition (La connaissance, selon Johnson). « La connaissance est de deux types, soit nousconnaissons nous-mêmes le sujet, ou alors nous savons comment trouver de l’information surcelui-ci. ».

Davenport et Prusak donnent quant à eux une définition de la connaissance par lanégative [Davenport00] :

Définition (La connaissance, selon Davenport et Prusak). « La connaissance, n’est ni desdonnées, ni de l’information. Elle est reliée aux deux. La différence entre données, information


et connaissance est une question de degré. Quoiqu’il en soit ces termes ne sont pas inter-échangeables. ».

De ces deux définitions de la connaissance, on note que le terme information est pré-sent dans chacune. Si on suit la première définition et que l’on accède à de l’informationsur un sujet, on a alors une connaissance de celui-ci. Dans cette définition la différenceentre connaissance et information reste floue. C’est la possession de l’information quien fait une connaissance. Cette définition indique donc qu’une connaissance ne seraiten fait qu’une information sur un sujet. La définition de Davenport, plus récente, a vuentre temps la naissance de l’informatique et l’apparition du concept de données et de lathéorie de l’information. La connaissance est définie par opposition avec les données etl’information, que l’on considère alors selon un degré d’abstraction :

abstraction(Donnees) < abstraction(In f ormation) < abstraction(Connaissance)

Dans le cadre de Davenport, ces définitions sont sans rapport avec celles de leurdomaines d’origine respectifs (base de données et théorie de l’information, que ce soitcelle de Shannon ou celle algorithmique de Kolmogorov). Les définitions suivantes sontdonnées par Davenport [Davenport00] :

Donnée : une donnée est un élément brut, qui n’est pas reliée à un contexte ou àune quelconque interprétation. Prenons la donnée 30 envoyée par un capteur. Si on neconnait pas le contexte (est-ce un capteur de température, de pression ?), cette donnéene contient aucune information, elle n’indique rien.

Information : une information est une ou plusieurs données associées à un contexte.En reprenant l’exemple précédent, en ajoutant le type de capteur, par exemple un capteurde température et la localisation de ce capteur, on dispose maintenant d’une information :la température dans la pièce x est de 30 degrés celsius.

Connaissance : la notion de connaissance est définie par dérivation, intéprétation etexploitation des données. Cette définition est certes peu claire, les auteurs ne prétendantpas remplacer les définitions des épistémologistes mais veulent fournir une définitionapplicable de la connaissance. La notion d’utilisation est parfois utilisée pour établir ladifférence entre information et donnée [Balmisse02]. Dans l’exemple précédent, si l’onsait que cette pièce est une chambre d’hôpital, on sera amené à prendre les décisions quis’imposent (climatisation, évacuation des patients), la température étant trop élevée.

Ce schéma d’oppostion entre données, information et connaissances est aussi trèscourant dans la fouille de données. La figure 3.1 issue de [SILVENT03] en est un exemple.

Certains auteurs proposent de rajouter un niveau au dessus de celui de la connais-sance, qui est nommée sagesse et qui décrit l’art de prendre les décisions [Hey04,Rowley07]. Ces définitions du domaine du KM (Knowledge Management), sont trèsloins des discussions philosophiques qui précèdent. Leurs buts sont purement applica-


FIGURE 3.1 – Processus d’extraction de connaissances mettant en exergue l’abstraction[SILVENT03]

tifs, c’est à dire qu’il s’agit de mettre en place des outils de gestion des connaissances ausein des organisations.

3.1.1.4 Discussion sur ces définitions

De nombreuses questions se posent aux vues des deux approches, épistémologiqueset gestion des connaissances, qui ne semblent liées que par le terme connaissance. Nousnous intéressons alors au problème suivant : pourquoi n’y a t-il pas de rapport ou denotions communes entre ces deux concepts et comment est-il possible de trouver un lienentre les deux ?

Les deux approches diffèrent fondamentalement, l’approche philosophique aborde leproblème par un questionnement logique, avec une approche scientifique, qui supportela réfutation (cf les contre-exemples de Gettier). L’approche pragmatique du KM ne pré-tend pas remplacer les définitions des épistémologues mais se fixe comme but de mettreen application des outils de gestion des connaissances. Dans l’approche épistémologique,les notion de vérité et de réalité sont les piliers qui soutiennent les définitions.

Pour le KM, les notions de vérité et de justification sont absentes, cette approchese focalisant sur différents niveaux d’abstraction (données, information, connaissance).L’orientation est clairement donnée vers le traitement automatisé par des moyens numé-riques et nous montrerons en section 3.2.4.3 que la logique fera une apparition tardivecomparé à l’approche philosophique, mais deviendra un point crucial dans l’approcherécente, notamment par le biais des technologies du web sémantique qui seront utiliséespour la représentation des connaissances. Mais si la notion de vérité est absente desdéfinitions du KM, c’est qu’elle est présupposée. On considère que les connaissances quiseront intégrées au système de gestion sont vraies. C’est en fait un des fondements tacitede cette approche.

Dans le domaine du KM, si les définitions de données, information et connaissancesont largement acceptées, cependant, comme le montre T.D Wilson dans son célèbrearticle « The Nonsense of Knowledge Management » [Wilson02]le domaine du KMa constitué une bulle économique, en créant un effet de mode autour du KM, afin


d’en tirer des profits économiques. Cette dérive a conduit comme le montre Wilsona la prolifération de nombreuses "techniques" et "théories" douteuses. Wilson tendà présenter le KM comme un "buzz" marketing dénué de liens à un problème réel.Cependant, au delà des dérives économiques et marketing apparues au milieu desannées 90, nous pensons que les problème posés par le KM sont bien réels, que ce soitpour une organisation ou d’un point de vue plus global :

– Comment chacun peut-il accéder aux connaissances ?– Comment transférer des connaissances ?– Comment acquérir des connaissances ?– Comment utiliser ces connaissances pour prendre de meilleures décisions ?Après avoir posé les définitions de la connaissance dans le domaine de la gestion des

connaissances, nous allons présenter un bref historique du domaine et nous détailleronsensuite les outils et méthodes appliqués dans ce domaine.

3.1.2 Historique

La gestion des connaissances voit son histoire intimement liée à celle des supportset celle des avancées techniques dans le domaine de ces supports. Les connaissanceshumaines ont d’abord eu une transmission orale, puis l’écriture a permi la pérenni-sation du savoir. L’avènement de l’imprimerie a permi de diffuser plus largement lesconnaissances. La transmission de connaissances tacites, regroupant souvent les connais-sances empiriques, comme par exemple les savoir-faire artisanaux, a été rapidementinstitutionnalisé. On trouve trace dès le dix-huitième siècle d’une institutionnalisationde cette transmission de connaissances par le biais du compagnonnage (les premiersécrits allemands traitent des « Wandergesellen », qui sont comparables au compagnon-nage français). Certains historiens situent le début du compagnonnage à la constructiondes églises médiévales en Angletterre. Ces immenses chantiers auraient été l’occasionde mettre en place la transmission des connaissances artisanales. Cette méthode detransmission perdure encore de nos jours notamment chez les charpentiers allemands.

En ce qui concerne les connaissances qui se transmettent par le biais du langage, ledernier grand changement, après l’écriture et l’imprimerie est intervenu avec l’avène-ment de l’informatique qui a eu pour conséquence la dématérialisation du support etune massification de l’accés à l’information. Les technologies de l’information ont permisune révolution dans les années 1980, lorsqu’une très grande majorité d’entreprises s’estéquipée d’outils numériques. Stankovsky établit l’apparition de la gestion des connais-sances en tant que discipline académique en 1995 [Stankovsky05], sous l’influence dessciences cognitives et de la psychologie [Wiig00].

Le but de la gestion de connaissances telle qu’on l’étudie actuellement est double. Ilest tout d’abord de pérenniser les connaissances d’une organisation et d’améliorer sagestion, et deuxièmement de pouvoir évaluer la valeur du capital des connaissances


détenues par l’organisation. Pour ce faire, de nombreux outils et méthodes de gestionet d’évaluation ont été développés. Dans notre travail, le premier point, c’est à direla pérennisation, transmission et gestion des connaissances sera le seul objet de notreattention. Le deuxième concerne des considérations économiques, qui sont ici hors denotre propos.

3.1.2.1 Outils et Méthodes

Les outils électroniques de gestion de connaissance sont au départ des systèmes des-tinés à être utilisé par les managers pour disséminer l’information (Manager InformationSystem ou MIS). Ils ont ensuite évolué vers des outils d’aide à la décision (Decision Sup-port Systems ou DSS), puis sont devenus des systèmes capables de délivrer l’informationen temps-réel aux junior ou middle managers (Executive Information System ou EIS),c’est à dire des niveaux de hiérarchie inférieurs. Finalement l’évolution et l’intégrationde ces systèmes se cristallisent dans les outils de gestion intégrée des connaissances(Knowledge Management Systems ou KMS) dont les objectifs sont de créer, rassembler,organiser et disséminer les connaissances au sein de l’organisation [Alavi99].

Les premiers outils modernes de gestion de connaissance se basent sur une approchecentralisée, autour d’un dépôt de connaissances, mis en place et maintenu par desexperts. Les outils de travail collaboratifs électroniques font leur première apparitionnotable avec l’utilisation de Lotus Notes par PriceWaterHouse Coopers en 1989 [Alavi99],puis les KMS se sont généralisés en se basant sur des frameworks centralisés, de plus enplus nombreux au fil des années.

Ehrig montre que l’approche centralisée est coûteuse [Ehrig03] et que son coût demaintenance est élevée. Vers le milieu des années 90, de nouvelles approches sont déve-loppées, notamment celle de l’entreprise comme système de connaissances distribuées,qui est issue des travaux de Tsoukas [Tsoukas96]. Tsoukas montre qu’au sein d’uneorganisation il est impossible qu’une entité puisse détenir toutes les connaissances, etque par conséquent les connaissances sont non seulement distribuées géographique-ment et au niveau des entités qui les détiennent, mais aussi que cette distribution faitpartie d’un contexte sur lequel l’organisation n’a pas de contrôle (le marché, les autresorganisations, . . . ). Ces travaux signent le départ d’une nouvelle approche, antagonistede l’approche centralisée, dans laquelle les entités participant à une organisation jouentun rôle premier.

3.1.3 Gestion des connaissances distribuées

Une fois le verrou de la centralisation identifié, les premières approches distribuéesont été mises en oeuvre. En 1999 dans [Alavi99], les auteurs montrent que 36% desKMS utilisent des filtres ou agents. Cependant le mélange dans une même catégorie des


notions de filtres et d’agents ne permet pas de conclure quant à l’utilisation des agentsdans les KMS. Les approches purement décentralisées apparaissent en 2002 avec lestravaux de Bonifacio, tout d’abord dans des travaux théoriques sur les « KnowledgeNodes » [Bonifacio02c] puis par le système Kex [Bonifacio02b]. On peut aussi noterl’existence du framework SWAP, qui est apparu en 2003 [Ehrig03].

Bonifacio démontre que l’approche centralisée des KMS se réfère à une vision objec-tiviste de l’épistémologie combinée à un paradigme traditionnel de contrôle managérial[Bonifacio02a]. C’est à dire une gestion des connaissances basée sur une volonté dedisposer de connaissances « objectives », en admettant l’existence d’une telle objectivité.Cette approche a pour conséquence de figer la représentation des connaissances sur unmodèle unique. Les systèmes centralisés maintenus par des experts en sont l’exemplele plus pertinent, dans ces systèmes les ontologies de domaines créées par l’expertconstituent le modèle unique de représentation des connaissances.

En analysant la structure de ces KMS, Bonfacio montre que l’organisation interneet la hiérarchie au sein des KMS est semblable à l’organisation et à la hiérarchie descompagnies [Bonifacio02a]. Cette approche de contrôle hiérarchique est incompatibleavec la nature distribuée de la connaissance. En effet les échanges de connaissance dansles organisations entre les membres ne transitent pas dans la pratique par les cheminsde sa structure hiérarchique, les échanges entre les employés étant très nombreux. L’ap-proche distribuée permet donc de prendre en compte les aspects distribués du stockageet des échanges au sein des organisations. L’approche de Bonifacio se base sur uneapproche différente de la notion même de connaissance. La notion d’autonomie est cen-trale dans l’approche de Bonifacio, chaque communauté maintient une représentationdes connaissances, la notion de coordination entre les communautés permet l’échangede connaissances entre différentes représentation. Chaque communauté possède uncontexte qui est une représentation explicite du schéma d’interprétation de la commu-nauté. Un lien entre deux communautés, donc entre deux contextes est un "mapping"entre ces concepts.

L’approche de Bonifacio s’est traduite concrètement par le projet d’EDAMOK (En-abling Distributed and Autonomous Management of Knowledge) qui est la première archi-tecture de gestion de connaissances distribuées [Bonifacio02a]. La figure 3.2 présentel’approche distribuée au sein d’EDAMOK.

L’architecture reproduit le processus social dit de négotiation du sens en utilisant desprotocoles de communication entre des agents intelligents au sein de communautés.Ces communautés sont centrées autour d’un concept et les participants suivent unprocessus de négotiation pour s’accorder sur le sens commun (c’est à dire l’intersection)de ce concept. Le rôle de ces agents est aussi de faciliter les recherches en effectuant desmatching avec le contexte (c’est à dire l’interprétation) d’autres communautés. Ce rôle


FIGURE 3.2 – Approche distribuée de la gestion de connaissance [Bonifacio02a]

de médiateur permet d’étendre les requêtes et de donner des résultats plus précis pourl’utilisateur local.

Le système KEX que nous présentons en section 3.3.10.3 est la plate-forme implémen-tant l’approche distribuée de EDAMOK. Parallèlement les systèmes d’information multi-agents se développent et on assiste à partir de 2003 à la réunion des deux domaines lorsdes éditions du symposium AMKM [van Elst04b, Virginia Dignum04, van Diggelen05].D’autres plates-formes de gestion distribuées de connaissances suivront alors EDAMOK,elles sont présentées en détail en section 3.3.10.

3.1.4 Conclusion de l’état de l’art sur la gestion des connaissances

Nous avons abordé différents points dans cette partie, tout d’abord les définitions dela connaissance en épistémologie et dans le domaine de la gestion des connaissances.Puis nous avons présenté les approches centralisées et décentralisées de gestion desconnaissances.

La définition de la connaissance qui est utilisée dans l’approche appliquée de lagestion de connaissances repose sur des considérations informatiques et non épisté-mologiques. La définition de la connaissance qui se fait par opposition aux donnéeset aux informations, se base sur une succession de traitements informatiques. Prenons

Section 3.2. Représentation des connaissances et Web Sémantique 71

l’exemple d’un capteur de température dans une pièce : les données sont acquises d’uncapteur et représentent une suite de bits, sans signification. Ces données sont ensuitetraitées pour en calculer la température mesurée par le capteur, ce qui constitue alorsl’information. Si l’on extrait d’un relevé de température fournie par le capteur un modèlequi décrit l’évolution de la température dans cette pièce, on a alors extrait une connais-sance à partir des informations. Ces définitions, par niveau d’abstraction, sont en fait lesétapes successives d’un traitement des données suivant un chemin d’abstraction. Maisle but d’un système de gestion de connaissances est, comme de nombreux systèmesinformatique, de délester l’utilisateur humain de tâches automatisables par la machine.C’est donc une définition de la connaissance qui est aussi pour l’utilisateur qui doitprévaloir, plutôt qu’une approche technique. Ce raisonnement ne s’applique pas seule-ment à la définition de la connaissance en tant que "tout ce qui n’est pas information oudonnées", mais à toute définition de la connaissance qui est imposée par la structure dela machine qui est amenée à traiter les connaissances. La définition épistémologique ("Laconnaissance est une opinion droite pourvue de raison) nous semble être plus proche dufonctionnement "humain", c’est donc cette définition qui selon nous, doit être au centredes systèmes de gestion des connaissances.

Les travaux de Bonifacio ont mis en évidence la notion d’autonomie de la connais-sance et ont ouvert la voie à la gestion décentralisée des connaissances. Cependantl’autonomie de la représentation des connaissances se limite au domaine de la commu-nauté. Cette autonomie de représentation doit être étendue complètement jusqu’auxentités qui composent les communautés. Les techniques de représentation des connais-sances sont précisément l’objet de la prochaine partie.

3.2 Représentation des connaissances et Web Sémantique

Les systèmes de représentations des connaissances et les systèmes de bases dedonnées décrivent et raisonnent sur des aspects du monde réel. Le but de ces systèmes estde pouvoir stocker de manière électronique les connaissances. Certains de ces systèmessont basés sur des paradigmes logiques, comme le Prolog, les Frame-Logics et le WebSémantique, nous restreindrons notre domaine d’étude à ces systèmes. On caractériseces systèmes par les hypothèses qui sont faites, sur la nature des connaissances et sur lalogique qui y est utilisée. On distingue les caractéristiques suivantes [Hustadt94] :

Monde Fermé Toutes les informations qui ne sont pas connues comme vraies sontfausses. C’est le principe du tiers exclu.

Monde Ouvert Il peut exister des faits qui soient vrais et qui ne sont pas contenus dansle systèmes

Domaine fermé Il n’existe pas d’autres objets dans le monde que ceux désignés par lesvariables du système.


Domaine ouvert Il existe plus d’objets que ceux décrits dans le système.

Consistant Un système est consistant si il n’existe pas de propositions qui puissent êtreen contradiction.

Paraconsistant Système logique qui tolère les inconsistances. Ces systèmes sont consi-dérés comme inintéressant par les spécialistes de la logique [Girard07]. Nous leslaisserons donc volontairement en dehors de notre étude.

De nombreux formalismes et outils ont été développés pour répondre à cette ques-tion 1 et il serait long et fastidieux de les lister. Actuellement, les standards et technologiesissus du Web Sémantique, basés sur la notion d’ontologies tendent à supplanter les autrestechniques de représentation.

3.2.1 Web Sémantique

Le World Wide Web grossit à une vitesse très grande (26 millions de pages indexéespar Google en 1998, un milliard de milliard en 2008 2) et la recherche d’informationau sein du réseau est rendue difficile par la structure des pages internet. En effet lesliens dans le web classique sont des liens entre des pages et ces liens ne contiennent pasplus d’information que le lien lui-même. Les pages étant écrites en langage naturel (i.e.français, chinois, anglais, ...), les mécanismes de recherche d’information sont basés surdes analyses statistiques des pages et sur les liens qui les relient entre elles. Le pagerankde Google est l’exemple le plus célèbre à jour. Le but du web sémantique n’est pas deremplacer le web classique, mais d’y apporter une structure, afin que les informationspuissent être traitées automatiquement par une machine.

3.2.2 Ontologies

Le concept d’ontologie en informatique, est très largement inspiré de son sens philo-sophique. En philosophie l’ontologie est l’étude de l’être en tant qu’être, c’est à dire lespropriétés générales de ce qui existe. De la même manière le terme informatique définitune ontologie comme un ensemble de termes et de propriétés [Gruber93].

Les ontologies ont initialement été développées comme technique de représentationdes connaissances vers la fin des années 80. Le but d’une ontologie est de modéliser unensemble de connaissances dans un domaine donné.

Une ontologie est un ensemble structuré des termes et concepts représentant le sensd’un champ d’informations, que ce soit par les métadonnées d’un espace de noms, ou

1. http://en.wikipedia.org/wiki/Category:Knowledge_representationaccédé le 09/11/09

2. http://googleblog.blogspot.com/2008/07/we-knew-web-was-big.htmlaccédé le 09/11/09

http://en.wikipedia.org/wiki/Category:Knowledge_representation

http://googleblog.blogspot.com/2008/07/we-knew-web-was-big.html


les éléments d’un domaine de connaissances. L’ontologie constitue en soi un modèlede données représentatif d’un ensemble de concepts dans un domaine, ainsi que lesrelations entre ces concepts. Elle est employée pour raisonner à propos des objets dudomaine concerné.

3.2.3 Historique du Web Sémantique

Un lien entre deux pages web peut s’écrire d’une des deux manières suivantes enHTML :

<a href=’http://www.bnf.fr’>

Bibliothèque nationale de France

</a>

<link title=’Bibliothèque nationale de France’

href=’http://www.bnf.fr’>

Bibliothèque nationale de France</link>

Cet exemple illustre la nature du lien qui lie les pages internet, qui est un lien qui necontient pas d’information. De plus il se trouve dans une page écrite en langage naturel,donc très difficile à analyser automatiquement avec une machine. L’idée qui sous-tendle web sémantique est de structurer le contenu du web, en particulier avec l’idée detyper les liens qui relient les informations afin de permettre le traitement automatique.Pour cela, le formalisme des ontologies se prètent parfaitement à cet exercice. Avantl’avènement des technologies actuelles du web sémantique, de nombreux projets quifont maintenant figure de pionniers présentaient déjà l’idée de fusionner les technologiesdu web et les ontologies. Nous présentons ici quelques uns des projets dont les idéespréfiguraient les standards actuels du consortium W3C.

Le projet SHOE [Heflin00] pour Simple HTML Ontology extension est une extensiondu langage HTML qui permet d’annoter une page HTML en se basant sur le vocabulairedéfini dans les ontologies importées. La page web suivante est un exemple de page nonannotée :

<HTML>

<HEAD>

<TITLE> My Page </TITLE>

</HEAD>

<BODY>

<P> Hi, this is my web page.

I am a graduate student and a research assistant.


<P> Also, I’m 52 years old.

<P> My name is George Stephanopolous.

<P> Here is a pointer to my <A

HREF="http://www.cs.umd.edu/smith"> graduate advisor.</A>

<P> And <A HREF="http://www.cs.umd.edu/papers/paper.ps">

is a paper I recently wrote.

<h3> Brun Hilda </h3>

Brun Hilda is a visiting lecturer here from Germany who doesn’t

have her own web page. However, because I am such a nice

person, I have agreed to let part of my web page space

belong to her. She is 23.

</BODY>

</HTML>

Pour annoter cette page en utilisant le vocabulaire de l’ontologie http://www.cs.umd.edu/projects/plus/SHOE/onts/cs.html, à l’aide du code suivant, placéavant la balise fermante </BODY> :

<INSTANCE KEY="http://www.cs.umd.edu/users/george/">

<USE-ONTOLOGY

ID="cs-dept-ontology"

URL="http://www.cs.umd.edu/projects/plus/SHOE/onts/cs.html"

VERSION="1.0"

PREFIX="cs">

<CATEGORY NAME="cs.GraduateStudent">

<CATEGORY NAME="cs.ResearchAssistant">

<RELATION NAME="cs.name">

<ARG POS=TO VALUE="George Stephanopolous">

</RELATION>

<RELATION NAME="cs.age">

<ARG POS=TO VALUE="52">

</RELATION>

<RELATION NAME="cs.advisor">

<ARG POS=TO VALUE="http://www.cs.umd.edu/users/smith">

</RELATION>

<INSTANCE KEY="http://www.cs.umd.edu/users/george/#BRUN">

<CATEGORY NAME="cs.Lecturer">

<RELATION NAME= "cs.name">

http://www.cs.umd.edu/projects/plus/SHOE/onts/cs.html

http://www.cs.umd.edu/projects/plus/SHOE/onts/cs.html


<ARG POS=TO VALUE="Brun Hilda">

</RELATION>

<RELATION NAME="cs.age">

<ARG POS=TO VALUE="23">

</RELATION>

</INSTANCE>

</INSTANCE>

Le principe de SHOE est d’ajouter une couche au langage HTML pour y introduire unedescription sémantique manipulable par une machine. La représentation ci-dessus estune reformulation du texte écrit en langage naturel dans le formalisme SHOE et il ne sesubstitue pas au contenu HTML précédent, mais il en constitue une annotation.

Le raisonnement logique proposé par SHOE est similaire à celui des clauses de Hornsans la négation. Suivant le même principe de mélanges d’annotations et de HTML,Ontobroker [Decker98] est un outil basé sur la logique des Frame ou F-Logic. Parmi lesautres outils, on citera Concerto [Zarri99], LogicWeb [Loke98], qui s’appuient sur unedémarche identique à celle de SHOE et Ontobroker.

3.2.4 Standards du Web Sémantique

Les standards du web sémantique sont issus du consortium W3C qui a été créé en1994 par Tim Berners-Lee avec le soutien du CERN et du MIT 3. Les standards dont nousparlerons ici, ne sont pas des standards au sens normes de la commission européenneou ISO, mais des standards industriels qui sont en fait des recommandations de bonnespratiques.

Les différents standards du web sémantique sont résumés dans la figure 3.3 commu-nément appellée Semantic Web Layer Cake ou Gâteau en couches du web sémantique. Cettefigure montre l’empilement des différentes couches, les couches supérieures se basantsur les standards des couches inférieures.

Les couches inférieures présentent les standards déjà connus dans le web hypertexte :URI pour l’identification des ressources, Unicode comme standard d’encodage, XMLpour la structuration des documents et les Namespace pour la réutilisation des balisesde sources différentes.

XML Query et XML Schema sont des outils permettant l’exécution de requètes surles documents XML (XML Query) et la définition de la structure de ces documents (XMLSchema). Le RDF est un modèle de graphe qui permet de décrire des ressources Web

3. Pour plus de détails, le lecteur se référera à http://www.w3.org/History.html

http://www.w3.org/History.html


FIGURE 3.3 – Les différentes couches du Web Sémantique

sous forme de triplets. Le langage OWL (couche ontologie) étend la portée du RDF (etRDFS) en y ajoutant les logiques de description pour décrire les relations entre les entités.Les requètes doivent permettre de manipuler et de naviguer dans les ressources décritesen RDF/OWL et les règles permettent de compléter les descriptions des relations quiétaient impossibles en OWL.

La couche "confiance" repose sur des protocoles cryptographiques et doit assurerla sécurité et la confiance à l’aide de signature digitale des ressources RDF/OWL. Lescouches "confiance" et "cryptographie" ne sont pour l’instant qu’au stade préliminaire.

3.2.4.1 XML

Le XML (eXtensive Markup Language) est un langage de balisage générique. Ila été développé par le World Wide Web consortium (W3C) pour faciliter l’écritureet l’échanges de données structurées dans un format texte. Adopté en 1998 en tantque recommandation par le W3C, le XML a connu depuis un essor considérable. Tousles langages de programmation modernes fournissent des API de validation, parsing,manipulation de données XML, ce qui a largement contribué à son développement.

Les balises en XML sont définies dans un espace de noms, c’est à dire que leséléments qui composent un document XML peuvent être définies de manière externe.Cette fonctionnalité du XML permet une grande souplesse d’utilisation et une grandeinteropérabilité.

On distingue trois types de nœud dans un document XML.

Tag Ce sont des délimiteurs, les tags ouvrant commencent par "<" et terminent par ">",les tags fermant commencent par "</". Les tags vident se terminent par "/>".

Element Contenu entre les tags ouvrant et fermant. C’est texte dans l’exempel : "<élé-ment>Texte</élément>"

Attributs Paire nom/valeur. Exemple : <élément attribut="valeur"></élément>

Ils sont illustrés dans le code ci-dessous tiré de Wikipedia 4 :

<?xml version="1.0" encoding="UTF-8"?>



<élément-document xmlns="http://exemple.org/" xml:lang=";fr">

<élément>Texte</élément>

<élément>élément répété</élément>

<élément>

<élément>Hiérarchie récursive</élément>

</élément>

<élément>Texte avec

<élément>un élément</élément>

inclus</élément>

<élément/>

<élément attribut="valeur"></élément>

</élément-document>

3.2.4.2 RDF

Le Resource Description Framework (RDF) est une famille de spécifications duW3C [Klyne04]. Initialement prévu pour représenter un modèle de données pour lesmétadonnées.

Un document RDF est un ensemble de triplets de la forme suivante :

(sujet, prédicat, objet)

– Le sujet est la ressource à laquelle s’applique le prédicat.– Le prédicat est une propriété qui s’applique au sujet– L’objet est la ressource liée au sujet par le prédicat– Un littéral est un objet.

Un exemple de triplets est le suivant :

Exemple 3.1 Exemple de Triplet RDF

(Frédéric L. adore le Web 2.0)– Sujet : Frédéric L.– Prédicat : Adore– Objet : Le Web 2.0

Le sujet et l’objet d’un prédicat peuvent être identifiés par des URI ou peuvent êtredes nœuds anonymes. Par contre un prédicat est nécessairement identifié par une URI.

4. http://fr.wikipedia.org/wiki/XML accédé le 12/10/2009

http://fr.wikipedia.org/wiki/XML


Pour écrire des documents RDF, on dispose de nombreuses syntaxes. La plus couranteest le RDF/XML qui est une sérialisation du RDF en XML.

3.2.4.3 OWL

Le langage d’ontologie pour le Web (Ontology Web Language) 5 est une famille delangages dédiés à l’écriture d’ontologies. On peut le considérer comme la suite logiquedes travaux sur les langages SHOE et DAML+OIL [Horrocks03]. Une ontologie OWLdécrit un ensemble d’axiomes qui placent des contraintes sur des individus appartenantà des classes ainsi que les types de relations entre eux.

La définition des concepts OWL fait appel aux logiques de description, pour per-mettre d’obtenir une fondation plus solide que pour RDF. OWL permet l’égalité entredes propriétés, les concepts de classes équivalentes, d’égalité de deux ressources, deleurs différences, du contraire, de symétrie et de cardinalité.

Les logiques de descriptions diffèrent selon les constructeurs qu’elles possèdent(conjonction, négation, . . .), les trois langages d’OWL sont basés sur des logiques dedescription différentes. Ces trois langages sont : OWL-Lite, OWL-DL et OWL-Full,classés ici par ordre d’inclusion selon l’expressivité de leur logique de description.

OWL-Lite : Le langage OWL de base, qui supporte peu de fonctionnalités. La cardinalitéest par exemple limité à 0 et 1. Bien que d’expressivité très limitée, le dévelop-pement des outils pour OWL Lite s’est montré aussi coûteux que pour OWL-DLqui est pourtant bien plus expressif. De fait OWL-Lite, qui était dédié à une utili-sation simple, par exemple pour la rédaction de taxonomies, est maintenant trèsminoritairement utilisé.

OWL-DL : ce langage a été conçu pour permettre le maximum d’expressivité tout engardant les propriétés de décidabilité, de complétude et l’existence d’algorithmesefficaces pour l’implémentation de raisonneurs. Tous les constructeurs OWL sontprésents dans OWL-DL, mais ils sont soumis à certaines restrictions qui garan-tissent la décidabilité et la complétude.

OWL-Full : est basé sur une sémantique quelque peu différente de OWL-DL, puis-qu’il assure une interopérabilité avec RDF Schema. OWL-Full ne garantit pas lespropriétés de décidabilité et de complétude.

Parmi ces trois langages, OWL-DL est indéniablement le plus utilisé puisqu’il ga-rantit la décidabilité et la complétude. De plus, il existe de nombreux raisonneurs pourl’inférence de connaissances au sein d’ontologies OWL-DL. Parmi ceux-ci, on citera :

1. Pellet [Sirin07]

2. Fact++ [Tsarkov06]

5. http://www.w3.org/TR/owl-guide/

http://www.w3.org/TR/owl-guide/


3. RacerPro [Haarslev07]

Tout comme RDF, la syntaxe la plus courante pour OWL est la sérialisation XML.

OWL est un des piliers des standards du Web Sémantique. Sa maturité en faitmaintenant une technologie de choix non seulement pour des projets académiques maisaussi industriels 6 [Lacy04, Anicic07, Lacy05].

3.2.4.4 SWRL

Le langage de règles pour le web sémantique (Semantic Web Rule Language) estune proposition de langage [Horrocks04] dont les spécifications ont été soumises auW3C par un consortium composé du CNRC (Conseil national de recherches Canada), del’université de Stanford ainsi que de l’entreprise Network Inference.

SWRL combine les langages OWL-DL et Rule-ML [Boley01]. Etonnament, le consor-tium a proposé un langage qui n’est pas décidable, ce qui rend l’implémentation deraisonneurs SWRL impossible. Pour l’implémentation de raisonneurs, un sous ensemblede règles SWRL est utilisé, qui est appellé SWRL-DL. La construction de SWRL-DL enpartant de OWL-DL est explicité dans [Parsia05].

Règles en SWRL

Une règle SWRL se décompose en deux parties : antécédents et conséquents (aussicommunément appellées conditions et conclusion). La syntaxe abstraite des règles est lasuivante :

rule ::= ’Implies(’ [ URIreference ] { annotation }

antecedent consequent ’)’

antecedent ::= ’Antecedent(’ { atom } ’)’

consequent ::= ’Consequent(’ { atom } ’)’

La règle suivante en syntaxe naturelle :

pereDe(x, y) ∧ f rereDe(x, z)⇒ oncleDe(z, y)

peut s’écrire selon différentes syntaxes. Nous présentons ici les syntaxes XML et RDFpour l’écriture de cette requète.

syntaxe XML

l’exemple 3.2 présente la représentation de cette règle en syntaxe XML.

6. Workshop sur les applications de OWLhttp://www.webont.org/owled/

http://www.webont.org/owled/


Exemple 3.2 Exemple de règle SWRL : Syntaxe XML

<ruleml:imp><ruleml:_rlab ruleml:href="#exemple"/><ruleml:_body><swrlx:individualPropertyAtom swrlx:property="pereDe"><ruleml:var>x</ruleml:var><ruleml:var>y</ruleml:var>

</swrlx:individualPropertyAtom><swrlx:individualPropertyAtom swrlx:property="frereDe"><ruleml:var>z</ruleml:var><ruleml:var>x</ruleml:var>

</swrlx:individualPropertyAtom></ruleml:_body><ruleml:_head><swrlx:individualPropertyAtom swrlx:property="oncleDe"><ruleml:var>z</ruleml:var><ruleml:var>y</ruleml:var>

</swrlx:individualPropertyAtom></ruleml:\_head></ruleml:imp>

Syntaxe RDF

L’exemple 3.3 montre la représentation de cette même règle en syntaxe RDF :

Lien entre OWL et SWRL

La syntaxe de SWRL se base sur celle d’OWL, les entités intervenant dans les condi-tions et conclusions des règles SWRL peuvent être définies dans une ontologie OWL.Pour établir le lien entre les SWRL et OWL, on définit une règle comme un axiomeOWL :

axiom ::= rule

Conclusion sur SWRL

Bien que toujours à l’état de proposition de standards, de nombreux raisonneursont été développé pour SWRL (Pellet, Bossam, . . .), ainsi que des outils d’édition derègles (SWRLTab pour Protégé). L’adoption rapide par la communauté du SWRL laisseentendre qu’il devrait s’imposer en tant que standard pour les règles du Web Sémantique,au détriment de son concurrent le WRL (Web Rule Language) [Ma08].


Exemple 3.3 Exemple de règle SWRL : Syntaxe RDF

<swrl:Variable rdf:ID="x"/><swrl:Variable rdf:ID="y"/><swrl:Variable rdf:ID="z"/><ruleml:Imp>

<ruleml:body rdf:parseType="Collection"><swrl:IndividualPropertyAtom><swrl:propertyPredicate rdf:resource="pereDe"/><swrl:argument1 rdf:resource="#x" /><swrl:argument2 rdf:resource="#y" />

</swrl:IndividualPropertyAtom><swrl:IndividualPropertyAtom><swrl:propertyPredicate rdf:resource="frereDe"/><swrl:argument1 rdf:resource="#z" /><swrl:argument2 rdf:resource="#x" />

</swrl:IndividualPropertyAtom></ruleml:body><ruleml:head rdf:parseType="Collection"><swrl:IndividualPropertyAtom><swrl:propertyPredicate rdf:resource="oncleDe"/><swrl:argument1 rdf:resource="#z" /><swrl:argument2 rdf:resource="#y" />

</swrl:IndividualPropertyAtom></ruleml:head></ruleml:imp>


3.2.4.5 RIF

Le format d’échange de règles (Rule Interchange Format ou RIF) est un ensemblede standards et d’outils pour permettre l’échange des règles sur le Web. Les standardsRIF sont maintenus par le RIF Working Group 7 qui est un groupe de travail du W3C.Depuis sa création en novembre 2005, 3 standards ont vu le jour :

– Core : Le noyau, ce dialecte est le sous ensemble minimal à tout les moteurs derègles. Le noyau supporte les fonctionnalités suivantes :– Clauses de Horn– Appartenance dans la condition– Listes basiques– Egalité dans la condition– Données typées

– BLD (Basic Logic Dialect) : Dans ce dialecte, dit dialecte basique, les conditions etconclusions des règles sont monotones. Il n’est pas possible de changer la valeurd’un prédicat. BLD supporte les fonctionnalités suivantes (en plus de celles dunoyau) :– Egalité dans la conclusion– Fonctions logiques– Listes ouvertes– Appartenance dans la conclusion

– PRD (Production Rule Dialect) : Dans ce dialecte des règles de production, lesconditions et conclusions des règles sont non-monotones. Les fonctionnalités sontles suivantes :– Révision– Appartenance dans la conclusion– Négation

Le but du RIF est de permettre l’échange des règles entre différents systèmes autravers d’une syntaxe commune. La seule syntaxe du RIF (à la différence de RDF parexemple) est basée sur XML. La philosophie de RIF est de ne pas restreindre les outilsdu web sémantique à l’utilisation d’un seul type de logique. Pour favoriser la communi-cation de règles entre des partenaires (commerciaux ou non), le groupe de travail s’estfixé comme but l’adoption des standards présentés ainsi que leur mise en œuvre. Denombreux projets d’implémentation sont actuellement en cours de développement 8.

3.2.5 Raisonneurs

Pour utiliser concrètement les standards du Web Sémantique, des outils de raison-nement logique sont nécessaires. Ces outils, appellés raisonneurs sont des logiciels

7. http://www.w3.org/2005/rules/wiki/RIF_Working_Group8. http://www.w3.org/2005/rules/wiki/Implementations

http://www.w3.org/2005/rules/wiki/RIF_Working_Group

http://www.w3.org/2005/rules/wiki/Implementations


capables d’inférer les conséquences logiques d’un ensemble d’axiomes et de règles. Denombreuses propriétés caractérisent les raisonneurs et nous présentons ici celles quisont en lien avec nos travaux.

Définition (Raisonneur correct et complet). Un raisonneur est dit correct et complet si ilpossède une procédure de décision qui est

– Correcte : donne toujours des réponses correctes– Complète : donne toutes les réponses possibles

La complétude étant algorithmiquement coûteuse à obtenir, elle est parfois sacrifiéesur l’autel de l’efficacité. Il existe donc des raisonneurs efficaces mais non complets. Denombreux raisonneurs affichent, pour des raisons commerciales, ces propriétés commeétablies, certaines recherches tendent à prouver le contraire [Weithoener06]. Le fait que leraisonneur soit dit correct est un pré requis naturel pour l’utilisation d’un cadre logique.Un raisonneur qui ne présenterait pas des réponses correctes, ne permettrait d’accorderde valeur aux inférences produites, puisqu’il serait impossible de savoir si elles sontjustes ou non. Une procédure d’inférence complète est capable d’inférer tout ce qui peutêtre inféré. Cette propriété de complétude est usuellement considérée comme moinsimportante, la correction étant la première propriété recherchée dans un raisonneur.Même si il est possible de se contenter d’un sous-ensemble des inférences possibles, onrecherchera toujours un raisonneur possédant les deux propriétés de correction et decomplétude.

Une liste de raisonneurs OWL est donnée par le W3C 9. Nous ne détaillons pas ici lescaractéristiques des différents raisonneurs, mais justifions dans le chapitre concernantl’implantation du choix du raisonneur utilisé.

3.2.6 Conclusion de l’état de l’art sur le Web Sémantique

L’ensemble des technologies du Web Sémantique n’est pas encore arrivé à maturité,notamment à cause des problèmes induits par l’utilisation de ces logiques de descrip-tion. La non-monotonie de ces logiques ainsi que l’hypothèse de monde ouvert ontconsidérablement freiné le développement de ces technologies qui jusqu’à l’OWL étaitextrêmement simple. Le fait qu’aucun langage de règles n’ait encore été choisi commestandard par le W3C (même si on peut parier sur le SWRL) montre que la technologien’est pas encore matûre pour une utilisation industrielle ou grand public. Cependantl’état actuel des travaux est très encourageant, et si les promesses initiales du Web Sé-mantique ne seront jamais tenues, il aura permis l’accélération du développement deformats et de technologies pour la représentation des connaissances. On peut penser quetout comme le langage KQML [Finin94] qui a été utilisé à d’autres fins que celles pourlesquelles il a été conçu, les technologies et standards du Web Sémantique trouveront (et

9. http://www.w3.org/2007/OWL/wiki/Implementations

http://www.w3.org/2007/OWL/wiki/Implementations


trouvent déjà) un champ d’application dans toutes les applications touchant à la gestionde connaissances.

Le fonctionnement des systèmes inférentiels comme ceux du web sémantique fait ànotre sens, parfaitement écho à la théorie de la justification que nous avons présentéeau chapitre précédent. En effet dans un tel système logique, il est possible de justifierpar l’utilisation de raisonneur de la validité d’une proposition au regard d’un systèmed’axiomes et de règles de dérivation. Les raisonneurs permettent aussi de vérifier laconsistance d’un système et d’exhiber les points de discorde en cas de non consistance.Le langage OWL, basé sur les logiques de description et par conséquent sur l’hypothèsed’un monde ouvert nous parait parfaitement adapté à nos besoins de représentation etd’inférence dans le cadre de nos recherches.

La partie suivante fait le point sur les systèmes multi-agents, domaine dans lequelles technologies du Web Sémantique sont particulièrement présentes.

3.3 Agents et Systèmes multi-agents

Nous avons vu prédécemment l’évolution des recherches en gestion des connais-sances. Historiquement, les systèmes informatisés de gestion des connaissances ontévolué d’une approche centralisée vers une approche distribuée. Les terme d’agentset de systèmes multi-agents ont déjà été évoqués, notamment dans le contexte de lagestion décentralisée des connaissances en section 3.1.3. Nous allons présenter ici, leparadigme multi-agent et nous allons étudier plus en détails les architectures des agentsmanipulant des connaissances.

Nous présentons différents définitions du terme agent, qui est loin de faire consensus.Puis nous présentons différents types d’architectures standards du domaine et indiquonsles domaines d’application des systèmes multi-agents. Nous définissons ensuite lescritères correspondant à nos besoins dans l’étude et nous analysons les approchesexistantes dans trois sous-domaines : les langages de programmation agent, les plates-formes agents et les applications basées sur des agents utilisant des connaissances.

L’étude des protocoles de communications entre agents n’est pas nécessaire à la com-préhension. Le lecteur intéressé trouvera en annexe B une description de ces protocoles.

3.3.1 L’agent

Il serait hasardeux de dire qu’il existe à proprement parler une définition consensuelledu concept d’agent, chaque auteur donnant sa propre définition, en fonction de sondomaine de recherche et de son point de vue. Nous présentons ici, deux définitionsd’agents qui sont les plus communes dans le domaine des agents. Wooldridge et Jennings

Section 3.3. Agents et Systèmes multi-agents 85

proposent deux notions d’agents, une première définition dite "faible" et une deuxièmedéfinition plus forte [Wooldridge95]. Nous présentons ensuite la définition proposéepar Boissier, ainsi que les différents types d’architectures qu’il définit.

Définition (Agent, définition faible de Wooldrigde et Jennings). « Un agent est une entitédisposant des propriétés suivantes :

– Autonomie : un agent opère sans intervention humaine et possède le contrôle de cesdécisions.

– Capacité sociale : un agent intéragit avec les autres agents par le biais de moyens decommunications.

– Réactivité : un agent est capable de percevoir son environnement et d’agir sur ce dernier.– Pro-activité : un agent n’agit pas seulement en réponse à son environnement, il est

capable de prendre des initiatives. ».

Si les trois premières notions sont présentes dans toutes les définitions d’agents,la capacité de pro-activité ne l’est pas. Les agents purement réactifs, qui réagissent demanière déterministe à un état de l’environnement ne font pas preuve de cette capacité.Les architectures plus évoluées, quant à elles, intègrent toutes cette notion de pro-activitéou prise d’initiative.

Définition (Agent, définition forte de Wooldrigde et Jennings). « la notion forte d’agentscomprend les propriétés énoncés dans la définition faible auxquelles s’ajoute le fait que l’agent estconceptualisé ou implémenté selon des méthodes appliquées usuellement aux humains. ».

Cette deuxième définition est quelque peu restrictive puisqu’elle limite les agents àdes entités dont le fonctionnement est inspiré par les mécanismes présents chez l’homme.On retrouve dans les agents qui respectent cette définition, les agents émotionnels quipeuvent reproduire des émotions humaines ainsi que tout les agents qui sont en contactdirect avec l’utilisateur humain. L’architecture d’agent basée sur la logique (décrite ensection 3.3.6.1), du même auteur que cette définition, en est un parfait contre-exemple.

Jennings donne dans [Jennings98] une autre définition de l’agent :

Définition (Agent , définition de Jennings, Wooldridge et Sycara). « Un agent est un sys-tème informatique, situé dans un environnement, qui est capable d’actions flexibles et autonomespour accomplir les tâches qui lui sont assignées. ».

Boissier propose une définition minimale de l’agent : "Un agent est un programmeinformatique autonome, plongé dans un environnement qu’il est capable de percevoiret sur lequel il est capable d’agir". Puis il propose trois types d’architecture pour classerles agents [Boissier01] :

– Architecture d’agent autonome : architecture possédant des capacités de perceptionet d’action sur son environnement. Ne possède pas explicitement de capacité decoopération.


– Architecture d’agent interagissant : possède des capacités d’intéraction avecd’autres agent du système. Possède éventuellement des descriptions des agents etpeut les influencer par envoi de messages.

– Architecture d’agent social : l’agent social est le niveau supérieur de l’agent inter-agissant. Les entités organisationnelles sont formalisées et prises en compte parl’agent.

Russel et Norvig proposent une définition d’agents rationnels [Norvig03], c’est àdire d’un cas particulier d’agents, orientés vers un but :

Définition (Agent rationnel, définition de Russell et Norvig). « Pour chaque séquencepossible de perceptions, un agent rationnel sélectionnera une action qui maximisera sa mesure deperformance, étant donnée l’information apportée par la séquence de perceptions et quelles quesoient les connaissances dont dispose l’agent. ».

Dans ces définitions on retrouve de nombreux points communs et on peut sanshésiter dire qu’un agent est une entité qui est douée d’autonomie, d’une capacité àpercevoir l’environnement et d’une capacité d’action. Les autres attributs des agentsne font pas consensus, certains voient la capacité d’apprentissage comme fondamentale,pour d’autres cette capacité est même inutile, elle peut être indésirable. La figure 3.4montre la représentation d’un agent dans son environnement telle que proposée parWooldridge [Wooldridge99] et illustrant les trois attributs énoncés précédemment.

FIGURE 3.4 – Un agent dans son environnement [Wooldridge99]

3.3.2 Les systèmes multi-agents

Un système comprenant plusieurs agents est une société artificielle d’agents. Au seinde cette société, les agents peuvent être amenés à coopérer. Les agents peuvent aussi se


trouver dans une situation de compétition. Ce qui amène à la distinction par Zambonelli[Zambonelli01] entre deux classes de systèmes multi-agents :

– Résolution distribuée de problèmes : Dans ces systèmes les agents ont été conçuspour travailler coopérativement à la résolution d’un objectif commun.

– Systèmes ouverts : Système dans lesquels les agents ne partagent pas nécessaire-ment un but commun et peuvent être en compétition. Les agents peuvent dynami-quement entrer et quitter le système.

3.3.3 Domaines d’applications

Le paradigme multi-agents a été appliqué avec succés à de nombreux problèmesdans des domaines variés. On trouve notamment des applications dans le domaine dela gestion de la chaîne logistique [Swaminathan98, Fox00], gestion des connaissances[Maret04b], planification [Gaborit96], intéractions homme-machine, etc. Les conférences« Practical Applications of Agents and Multi-Agent Systems » 10sont très orientées versles applications pratiques et les démonstrations des systèmes multi-agents. Les actes deces conférences fournissent de nombreux exemples d’application des systèmes multi-agents à des cas réels.

3.3.4 Différents niveaux d’approche

Les systèmes multi-agents peuvent être abordés à différents niveaux. Nous allonsdécrire ces niveaux, du plus général vers le plus précis. Pour mieux comprendre, onpourrait faire le parallèle avec le domaine de l’économie, entre les approches de microé-conomie et de macroéconomie. La microéconomie analyse le comportement au niveaud’entités individuelles telles que le consommateur et voit l’économie comme la sommedes actions de ces entités, c’est à-dire d’un point de vue émergent. La macroéconomiese situe quant à elle au niveau de grands agrégats économiques telles que l’inflation, lechômage, . . . Le problème de l’économie est donc abordé par le haut, au travers d’unevision plus globale.

Dans l’approche la plus globale, on considère le système multi-agent dans sonensemble, on parle alors de société d’agents [Shoham95]. Le comportement global estdéterminé par l’ensemble des agents. Cette approche est notamment considérée dans lecadre d’applications collaborative où les agents travaillent ensemble à l’accomplissementd’une tâche, ou pour l’observation de phénomènes émergents dûs aux intéractions desdifférents agents.

A l’inverse de cette approche globale de société d’agents, il existe plusieurs approchesqui se concentrent sur l’agent en tant qu’entité individuelle. L’étude des architectures

10. http://www.paams.net

http://www.paams.net


d’agents est une de ces approches. L’architecture des agents désigne les composants etleur organisation en vue de la réalisation d’un agent en tant qu’entité autonome.

Un exemple de recherche au niveau agent sont les systèmes autonomes ou "autono-mic computing" introduite par IBM en 2001 [Horn01, Kephart03, Ganek03]. Ce domainese focalise sur l’architecture d’agents autonomes mais en lui ajoutant des propriétés sup-plémentaires telles que l’auto-guérison (self-healing), auto-protection (self-protecting). . ..

Notre approche au cours de ce travail se concentre au niveau micro, c’est-à-dire auniveau de l’agent en lui-même. Nous présentons dans la section suivante les différentesarchitectures standards d’agents. Nous nous intéresserons ensuite à la capacité de ré-flexivité, dont nous présenterons les fondements logiques ainsi que des architecturesd’agents supportant cette propriété.

3.3.5 Approche abstraite

On peut formaliser simplement les considérations précédentes sur les composantsd’un système multi-agent. On commence d’abord par définir l’environnement danslequel évolue les agents. L’environnement E est défini comme un ensemble d’étatsd’environnement e1, e2, . . .. A tout moment l’environnement se trouve dans l’un de sesétats. La capacité d’action d’un agent sur l’environnement est défini par l’ensemble desactions : A = a1, a2, . . ..

Wooldridge propose de définir un agent comme une fonction qui a une séquenced’états d’envrionnement associe des actions : agent : seq(E) → A ou seq(E) est l’en-semble des séquences d’éléments de E. Le caractère discret et séquentiel (évolutionsuivant le temps) de l’environnement est une conséquence de cette définition. l’environ-nement est régi par la fonction caractéristique de l’environnement : env : E× A → S,qui décrit la transition de l’environnement lorsque une action a ∈ A est appliqué àl’environnement s ∈ S.

On définit ensuite la perception d’un agent comme sa capacité à observer l’état del’environnement : obs : E→ P ou P est l’ensemble des perceptions possibles.

Dans sa définition des agents, Wooldridge n’introduit pas la notion de perceptionpour les agents réactifs, ce qui implique leur omnipotence (une connaissance parfaite ettotale de l’environnement). Nous préfèrerons considérer pour la suite que tout agentest doté d’une fonction de perception. Dans le cadre des agents réactifs par exemple,un capteur de température constitue une perception de l’environnement, qui peut êtreerronnée et d’une précision finie.

A partir de ces définitions on peut caractériser quelques architectures simplesd’agents :


– Réactive : L’agent purement réactif réagit à l’état actuel de l’environnement, il estdonc caractérisé par la fonction suivante : E→ A.

– Agents à états : On considère maintenant que l’agent est doté d’une représentationinterne de données qui leur permet de sauvegarder des informations concernantl’environnement ainsi qu’un historique interne. Soit I l’ensemble des états internesde l’agent. On dénote P l’ensemble des perceptions possibles de l’agent sur l’envi-ronnement. Un agent à états est alors caractérisé au moins par les deux fonctionssuivantes :– Sélection de l’action : actionI → A– Sélection de l’état suivant : suivantIxP→ I

3.3.6 Architectures standards

Nous avons présenté les agents de manière abstraite jusqu’ici, en décrivant leurspropriétés et les concepts sous-jacents à la notion d’agent. Dans cette partie nous allonsprésenter différentes architectures concrètes, au sens ou ces architectures sont implémen-tées et utilisées dans des applications ou des prototypes de recherche. Nous considérons5 classes d’agents, qui sont organisés chronologiquement.

– Agents basés sur la logique : Les décisions sont effectuées par des déductionslogiques sur l’état interne de l’agent.

– Agents Réactifs : Les décisions de l’agent sont des conséquences directes de l’étatde l’environnement.

– Agents Pro-actifs : ont comportement orienté vers un but et ils sont capables deprendre des initiatives afin de satisfaire le but assigné.

– Architectures en couches : dans lesquelles la décision est faite par différentescouches, les différentes couches permettent des raisonnements à différents niveauxd’abstraction.

– Architectures BDI : pour "Belief Desire Intention" ou Croyance Désir Intentionen français. Les décisions sont prises selon les désirs, croyances et intentions del’agent.

3.3.6.1 Architectures basées sur la logique

Cette approche s’est développé au sein de l’approche symbolique en intelligenceartificielle, et dans la continuité des recherches de la programmation logique qui ontamené au développement de Prolog, qui sera très largement utilisée pour l’implémen-tation des agents basés sur la logique. L’agent est capable de manipuler des symbolesqui représentent des formules logiques. Wooldridge propose l’architecture suivante[Wooldridge99] : on définit l’état interne d’un agent comme un ensemble E de formulesde la logique du premier ordre, qui appartient à l’ensemble de tout les ensembles des


formules de la logique du premier ordre. On notre E1,E2, . . . les états possibles de l’agent.Le comportement de l’agent est déterminé par les règles de déduction ρ.

Une action a ∈ A, sera exécutée si l’agent peut prouver que son exécution n’est pascontradictoire avec son état interne et les règles de déduction ρ. Pour cela on définitun prédicat Execute(a), qui correspond au résultat d’exécution de l’action a. Si E `ρ

Execute(a), c’est à dire si on peut déduire Execute(a) de l’état E à l’aide des règles dedéduction ρ, alors l’action a est valide, et doit être exécutée. De la même manière touteaction dont la non exécution ne peut pas être prouvée est valide : E 6`ρ Execute(a).

Si cette architecture permet de donner une approche formelle et logique à la construc-tion du comportement de l’agent, de nombreux problèmes importants la rende qua-siment impossible à implémenter. En effet, dans le modèle, l’agent doit énumérer laliste d’actions possibles est vérifier que leur exécution serait déductible. Cette opérationde déduction est à elle seule extrèmement couteuse en temps. Le second problème estcelui de l’ordonnancement des actions. En effet, plusieurs règles de déduction appar-tenant à ρ peuvent être valides sur E, ainsi plusieurs actions peuvent être éxecutablesen même temps. Au niveau de l’implémentation, puisque l’agent dispose d’un nombrefini de processeurs, il faut établir une séquence d’exécutions des actions. Une solutionest de prioriser les règles de déduction, c’est-à-dire d’ordonner les élements de ρ, pourobtenir une séquence d’actions. Cependant les différentes implémentations existantesde Prolog ne permettent pas de donner de priorité aux règles. Une même exécutiondonnera le même ensemble de résultats mais l’ordonnancement est variable selon lechemin d’exploration.

Les architectures basées sur la logique telles que proposées sont certes très éléganteset d’un formalisme agréable à la lecture, elles sont malheureusement trop coûteuses entemps de calcul pour être efficace.

3.3.6.2 Réactives

A l’inverse du développement du calcul symbolique en intelligence artificielle, deschercheurs ont voulu développer au cours de la fin des années 80 une approche quisoit plus adaptée et orientée vers une réactivité rapide à l’environnement. Une volontémajeure de cette approche était de lier le plus fortement possible le comportement avecl’environnement. On définit cette approche dite réactive comme étant de la forme :

situation −→ action

Les règles qui associent la situation à l’action sont donc des règles directes et iln’y a pas manipulation symbolique complexe, ni aucune représentation symboliqueà l’inverse de l’approche précédente. Le problème de l’ordonnancement des actions,comme pour les agents basés sur des architecture se pose aussi ici. En effet les actions


sont des conséquences de règles dont les conditions (l’état de l’environnement) peuventêtre communes à plusieurs règles. Pour résoudre ce problème, Wooldridge proposed’introduire une relation d’ordre total ≺ sur l’ensemble des couples (p, a), ou p estla perception d’une situation et a une action. Dans le cas ou plusieurs règles sontapplicables, l’éxecution de la règle de plus haute priorité est executée.

Wooldridge propose un algorithme en O(n2) (ou n est le nombre de règles, oucouples (p, a)) en calculant l’ensemble des actions exécutables, puis de sélectionner lecouple (p, a) de priorité maximale [Wooldridge99]. Les algorithmes choisis par Wool-dridge ne sont pas explicités mais nous proposons une solution en O(n) en parcourantune seule fois les couples (p, a) :

début1Données: B ensemble des règles de comportementsEntrées: s perception de l’environnement actuelSorties: (c, a) couple de priorité maximaletemp←− (0, 0)2

pour chaque (x, y) ∈ B faire3

si x == s alors4

si temp ≺ (x, y) alors5

temp←− (x, y)6

fin7

On remarque que pour la relation ≺ l’ordre total n’est pas requis, on peut réduire à unordre partiel entre tout couple (s, x) (s, y) avec s la perception de l’environnement etet ∀s ∈ P; x ∈ A, (0, 0) ≺ (s, x). En effet les couples n’ont besoin d’être comparé quelorsque s est identique, c’est-à-dire pour une même perception. Tout autre comparaisonentre deux perceptions ne sera pas effectuée par l’agent et devient par conséquentsuperflue. Dans notre algorithme (0, 0) est la valeur d’initialisation qui est l’élément leplus petit des couples (s, x).

L’approche réactive gagne donc en simplicité, complexité et vitesse d’exécution parrapport à l’approche logique, mais se limite à l’exécution de comportements basiques. Ilest impossible d’exécuter des comportements plus complexes avec cette architecture,comme par exemple les comportements où l’agent prend des initiatives pour accomplirun but, que nous présentons dans la section suivante. Les architectures réactives sontadaptées aux agents dont les ressources sont limitées.


3.3.6.3 Proactives

A l’inverse des architectures réactives, les agents proactifs sont des agents qui ontune capacité d’initiatives et qui ne répondent pas seulement à un stimulus de l’environ-nement.

3.3.6.4 BDI

L’architecture BDI (Beliefs, Desires, Intentions) est l’architecture la plus populaire.Son fondement réside dans les théories de l’intention du philosophe Bratman. L’axioma-tisation de cette théorie et son implémentation est due à Rao et Georgeff [Rao95]. Unagent BDI est un agent intelligent qui est caractérisé par les concepts suivants :

– Croyances : Les connaissances de l’agent sur le monde qui l’entoure.– Désirs : Les objectifs que l’agent souhaite accomplir.– Intentions : Les actions en cours d’exécution pour accomplir les désirs de l’agent.L’architecture suivante est la première architecture d’agents BDI, proposée en 1989

par Georgeff [Georgeff89].

FIGURE 3.5 – Architecture BDI [Georgeff89]

L’approche BDI a donné lieu à de nombreuses implémentations, dans son état del’art [Mascardi05], Mascardi présente en 2005 neufs langages et systèmes implémentantl’architecture BDI.


Nous présentons plus en détails en section B.1 certains de ces langages.

3.3.6.5 Agent basés sur des connaissances

Dans cette section nous allons considérer une approche symbolique, c’est à dire unereprésentation des connaissances des agents à l’aide de symboles explicites, contraire-ment à l’architecture connectionniste présentée à la section précédente. Ces agents baséssur des connaissances sont une catégorie d’agents intelligents. La spécificité de cetteclasse d’agents est de pouvoir manipuler des connaissances.

Les agents basés sur des connaissances disposent au moins des deux composantssuivants :

– Une base de connaissances– Un mécanisme d’inférenceLa base de connaissance contient la représentation du monde que se fait l’agent. La

représentation des connaissances au sein des agents est constituée de phrases appartenantau langage de représentations. Le mécanisme d’inférence, basée sur une logique, permetà l’agent de d’inférer de nouvelles connaissances à partir de celles dont il dispose.

Le comportement des agents basés sur des connaissances utilise les connaissances del’agent pour décider des actions que l’agent va exécuter. Ce comportement peut être misen œuvre à l’aide des différentes architectures que nous avons décrites précedemment.

Réflexivité

En programmation, la réflexivité est la capacité d’un programme à examiner et mo-difier ses structures au cours de son exécution. Cette propriété intéressante est présentedans la plupart des langages de programmation récents tels que JAVA, .NET, PHP 5,Python, . . .. Pour les agents basés sur des connaissances, le concept de réflexivité sedéfinit de manière similaire. Nous décrivons dans une première partie les fondementslogique du concept de réflexivité (et sa proxémie avec le concept d’introspection dansle domaine de la logique). Puis nous étudions en détail les architectures ou modèlesd’agents réflexifs présents dans la littérature.

Architectures et modèles d’agents réflexifs

La mise en œuvre du concept de réflexivité dans des architectures d’agents a donnélieu à différentes approches que nous allons décrire successivement. Tout d’abord uneapproche logique, qui suit les définitions présentés précédemment. Costantini et sescoauteurs présentent une architecture d’agents réflexifs basés sur le langage ReflexiveProlog [Costantini92].

L’application présentée est la résolution du problème des trois hommes sages. Ceproblème est un exemple classique d’utilisation de méta-raisonnement et dans le cadred’agents, de l’utilisation de la réflexivité. Le problème est le suivant :


Un roi veut savoir lequel de trois hommes est le plus sage, il pose un chapeau sur la tête dechacun des sages. Chacun pouvant voir le chapeau des autres sans pouvoir voir le sien. Il leur ditalors : "Vous avez chacun un chapeau, il est soit de couleur blanche ou noire, et il y a au moinsun chapeau blanc", en fait, tout les chapeaux sont blancs. Il leur demande ensuite successivementla couleur de leur chapeau. Le premier et le second répondent qu’ils ne savent pas, le troisièmerépond alors "le mien est blanc". Pour déterminer la couleur de son chapeau, le troisième sage faitle raisonnement suivant : "si mon chapeau est noir, dans ce cas le second sage verrait un chapeaublanc et un chapeau noir. Il conclurait alors, que si son chapeau est noir, le premier aurait concluque son chapeau est blanc, mais il a dit qu’il ne savait pas, son chapeau serait donc blanc. Puisquele deuxième n’a rien dit, mon chapeau est donc noir".

Cet problème est résolu par des approches de logique de la connaissance communeou bien par métaprogrammation. Costantini propose ici de résoudre le problème àl’aide d’une nouvelle approche, par communication entre les agents (les sages) qui estadaptable à N sages.

Approche par composants

La seconde approche de la réflexivité est par échange de composants. Dans cetteapproche on considère les comportements des agents comme des modules qui sontéchangeables entre les agents, chaque agent a donc connaissance de sa propre structureet des modules qui la composent. Il est donc en mesure de raisonner sur son architec-ture, d’en extraire des modules et de les modifier. Les architectures telles que S-APL(section 3.3.8.6) et SEAGENT (section 3.3.9.3) utilisent un mécanisme de composition decomportements pour créer des comportements complexes à partir de "briques" simples.

Approche BDI

Dans les architectures BDI, les comportements des agents sont régis par des plans, quiconstituent la séquence des actions a éxécuter pour atteindre un but donné. Antona et sesco-auteurs ont proposé un mécanisme d’échanges de plan entre les agents [Ancona04a]qui a été adapté à JASON [Ancona04b].

3.3.7 Critères d’analyses

Les sections précédentes ont présenté de manière générale le domaine des agents etdes systèmes multi-agents. L’étude qui va suivre s’oriente plus particulièrement sur lescritères qui intéressent nos travaux. Nous nous intéressons plus particulièrement

Nous étudierons plus particulièrement certains critères qui nous intéresserons pourformuler notre proposition. Les langages de programmation d’agents, ainsi que certainesplates-formes présentées en section 3.3.9, ont en commun deux choses. Tout d’abordl’agent possède une représentation de son environnement et de ses connaissances (oucroyances selon les architectures). D’autre part l’agent est doté de comportements qui se


basent sur une des architectures présentées précédemment (logique, connectionniste,basé sur des connaissances), ou sur des architectures ad hoc, dédiées aux cas particuliersétudiés.

Afin d’étudier de manière systématique et afin de pouvoir de comparer les différentesapproches, nous spécifions ici les critères qui nous concernent pour la représentationdes connaissances et pour l’expression des comportements. Ces critères sont représentésdans la figure 3.6.

Agent

Représentation des

connaissances

• Technologie

• Logique

Comportement

• Décision

• Logique

• Complétude (domaine

ouvert/fermé)

• Hypothèse de monde

ouvert/fermé

• Réflexivité

FIGURE 3.6 – Critères d’analyse des structures internes des agents

Les critères de représentation de connaissances sont basés sur les capacités et l’ex-pressivité de la base de connaissance de l’agent. Tout d’abord nous nous intéressonsà la technologie utilisée puis explicitons les différents aspects impliqués par le choixtechnologique. La réprésentation peut représenter un domaine fermé si tout les types deconnaissances sont connus au départ. Dans le cas contraire le domaine est dit ouvert, denouveaux types de connaissances peuvent apparaître au cours de l’évolution du système.Ce critère est un outil intéressant pour évaluer les capacités d’un système. Ensuite nousétudions le type de raisonnement employé en différenciant monde ouvert et mondefermé. La logique en monde fermé (type base de données, Prolog) stipule que c’est quin’est pas explicitement vrai est faux. A l’opposé, la logique en monde ouvert ce quin’est pas explicitement faux ni explicitement vrai est inconnu. Nous discuterons dansl’analyse du choix de monde ouvert ou fermé dans la représentation des connaissances.Si le système est basé sur la logique, nous nous intéressons au type de logique employépour évaluer l’expressivité de la base de connaissance. La logique utilisé au sein d’unagent peut intervenir à la fois dans l’inférence de la base de connaissance, mais aussi


dans le processus de décision d’un agent (i.e. dans son comportement). Il est aussipossible que deux logiques différentes soient utilisées. Ce qui explique la présence de lacolonne logique dans chacun des tableaux qui vont suivre.

Concernant le comportement de l’agent, l’architecture utilisée est un aspect impor-tant de classification (BDI, réactive, . . .). Dans les cas ou la logique est utilisée dans leprocessus de l’agent, nous nous intéressons au type de logique utilisée. Des logiquesplus ou moins expressives, décidables ou indécidables, influent particulièrement sur lescapacités d’un agent. La capacité de réflexivité d’un agent, c’est-à-dire d’acquérir desconnaissances sur son propre état d’exécution, sur ses connaissances permet d’augmenterles capacités des agents. L’échange de comportement qui est une de nos problèmatiquesest intimement liée à la notion de réflexivité, nous accordons une importance certaine àce critère.

Nous étude se base sur trois sous domaines des systèmes multi-agents, du plus géné-rique au plus particulier. En premier lieu nous étudions les langages de programmationagents qui intègrent la notion de connaissance. Nous étudions ensuite les plates-formesd’agents qui pour certaines spécifient un certain type de représentation des connais-sances et/ou un certain de type de comportement. Puis nous étudions les applicationsutilisant des agents intégrant des bases de connaissances. Nous concluons cette étudepar un récapitulatif des critères étudiés et une discussion.

3.3.8 Langages de programmation agents

La spécificité des agents à conduit à vouloir développer des langages ou approchesspécifiques pour la programmation. En effet si les premiers agents sont développés àpartir de langages de programmation classiques. On voit très rapidement une branche dela recherche en agents autonomes s’intéresser à la problématique de la programmationdes agents. Nous présentons dans cette section les langages d’agents qui intègrent lanotion de connaissance au sein des agents, notre étude n’a pas pour vocation de listerexhaustivement les langages de programmation agent 11. L’Agent Oriented Programmingqui est le premier langage que nous présentons est présent ici pour des raisons histo-riques. Les deux langages suivants AgentSpeak et 3APL) sont des langages communsdu monde agent ; nous présentons deux extensions d’AgentSpeak/Jason (JASDL etArgonaut) qui sont d’un intérêt particulier pour nos travaux puisqu’ils réalisent l’inter-face entre AgentSpeak et le langage OWL. Les langages S-APL et Nuin ne sont pas deslangages courants mais présentent de même l’intéret de mettre en œuvre des ontologiesau sein des agents. Le langage Jazzyk propose une approche intéressante de jonctionentre comportement et connaissance.

11. Pour plus d’information, le lecteur trouvera dans les travaux de Bordini [Bordini05b] un état de l’arttrès complet sur la programmation d’agents.


3.3.8.1 Agent Oriented Programming

L’idée d’un langage de programmation dédié aux agents se concrétise en 1991 parl’Agent Oriented Programming (AOP) de Shoham [Shoham91] dans lequel il présente lepremier langage d’agent appellée AGENT-0. L’approche de Shoham introduit 3 conceptsprincipaux qui sont les états mentaux de l’agent. Ces trois classes d’états mentaux sont :croyance, capacité et engagement.

– Croyance : représentation logique de la vision du monde de l’agent.– Capacité : les actions que l’agent est capable d’exécuter.– Engagement : garantie que l’agent exécutera une action à un temps donné.

FIGURE 3.7 – Diagramme de flot des agents AGENT-0 [Shoham91]

AGENT-0 fut un langage précurseur en son temps, il n’est plus utilisé dans desprojets de recherche, mais il a ouvert la voie à de nombreux successeurs qui se sont trèslargement inspirés de ces travaux précurseurs.

3.3.8.2 AgentSpeak et Jason

AgentSpeak est un langage de programmation d’agents basé sur l’architecture BDI[Rao96]. Avant AgentSpeak de nombreuses implémentations de l’architecture BDI


avaient été utilisé. La nouveauté d’AgentSpeak réside dans le fait que les trois atti-tudes principales de l’agent (Croyance, Désir et Intention) ne sont plus représentéespar des structures de données mais par des opérateurs modaux. AgentSpeak marquel’entrée de la logique dans le monde de la programmtion agents. Non plus d’un point devue pratique par l’utilisation de Prolog, mais par la définition logique de l’architectureBDI. Une version étendue d’AgentSpeak est utilisée pour la programmation des agentsdans Jason.

L’implémentation de Jason est réalisée en JAVA. Le langage interprété par Jason estdonnée en [Bordini05a]. Ce langage couvre les notions de plans, croyances, évènementstels que définis dans AgentSpeak, mais ne couvre pas l’intégralité de l’éxécution ducode d’un agent. En effet lors de l’éxécution d’un agent Jason, les fonctions réalisant untraitement sont créées par le designer en Java (voir l’exemple du robot dans [Bordini05a],ou des mineurs dans [Bordini07]). Le langage Jason peut être comparé au BPEL dansles services Web ; c’est un langage qui permet d’orchestrer les différentes actions quielles, dans le cas de Jason sont implémentées en Java. L’orchestration se fait au sens del’architecture BDI que nous avons présentée précédemment.

Jason seul, présente pour notre problème les limitations communes aux nombreuxlangages d’agents, en particulier la dichotomie entre le langage définissant les comporte-ments (AgentSpeak) et les actions (ici en Java). Cette dichotomie pose des problèmesd’interopérabilité entre agents, l’échange de comportements en AgentSpeak nécessitel’échange des fonctions en Java, ce qui en soit n’est pas impossible (avec la réflexivité deJava) mais n’est pas mis en œuvre dans Jason, une extension de Jason propose l’échangede plans entre agents [Ancona04a], mais aucune implémentation n’est fournie. De plusJason utilise une représentation dans un format interne pour la base de connaissancede l’agent (format AgentSpeak) qui est limitant dans son expressivité, comparé aux lan-gages d’ontologies. Se basant sur une représentation de type Prolog, les connaissancessont représentées sous forme d’assertions dans le domaine des clauses de Horn.

Cependant il existe deux extensions de Jason qui se rapprochent de ce que nousrecherchons. JASDL et Argonaut proposent l’intégration d’OWL dans Jason, de deuxmanières différentes. Nous détaillons ces deux extensions dans les sections suivantes.

ConnaissanceReprésentation Logique Complétude Monde

JASON AgentSpeak(type Prolog) Horn Non Fermé

TABLE 3.1 – Représentation des connaissances dans JASON


ComportementDécision Logique Réflexivité

JASON BDI/AgentSpeak Horn Non 12

TABLE 3.2 – Comportement des agents dans JASON

3.3.8.3 JASDL

JASDL (Jason AgentSpeak-DescriptionLogic) utilise les techniques de Jason et l’OWL-API pour fournir les fonctionnalités de programmation agent ainsi que les raisonnementssur les ontologies [Klapiscak09]. L’approche de JASDL diffère des travaux préliminairesde Moreira [Moreira06] qui suggèrent des changements dans la sémantique opération-nelle pour intégrer AgentSpeak dans OWL. Ces travaux préliminaires avaient établi uncadre théorique mais aucune implémentation n’avait été fournie. Les avantages attendussont les suivants :

– Requètes plus expressives sur la base des croyances.– Meilleure mise-à-jour des croyances. Seuls des croyances consistantes avec celles

existantes peuvent être rajoutées.– En utilisant le principe de subsomption des concepts, la recherche de plans est

améliorée.– Partage des connaissances au format OWL.Cette approche nécessite la définition de l’architecture BDI en termes de concepts

OWL, ce qui à notre avis, par son complexité, n’a pu être implémenté. JASDL proposeune approche plus simple en utilisant une correspondance entre la partie AgentSpeakde Jason et la partie des axiomes OWL. L’utilisation d’un raisonneur OWL est aussiintégrée. L’archictecture de JADSL est décrite en figure 3.8.

Si JASDL propose une intégration d’OWL avec Jason, il est toujours nécessaire lors dela définition de nouvelles actions, de les définir à la fois dans le langage AgentSpeak et enOWL. L’échange des connaissances au sens de l’AOA est alors limité par les définitionslocales des actions en AgentSpeak. Ces actions sont en effet propres à chaque agent et nesont pas échangeables.

L’utilisation d’OWL avec AgentSpeak permet la représentation de connaissances auformat OWL (ainsi que l’utilisation d’un raisonneur sur ces connaissances), ainsi quela généralisation de plans au format OWL. Le moteur de décision de l’agent restant auniveau AgentSpeak.

Tout comme l’approche proposée dans [Moreira06], JASDL, bien que plus simpledans la proposition ne fournit pas d’implémentation. On pourra aussi noter qu’il estreproché à Nuin de ne pas fournir d’implémentation ([Klapiscak09]), ce qui est pourtantle cas depuis 2004 13.

13. voir http://web.archive.org/web/*/http://www.nuin.org pour plus de détails.

http://web.archive.org/web/*/http://www.nuin.org


FIGURE 3.8 – Architecture JASDL ([Klapiscak09])



JASDL OWL et AgentSpeak DL et Prolog Non Fermé

TABLE 3.3 – Représentation des connaissances dans JASDL


JASDL BDI/AgentSpeak Horn Non

TABLE 3.4 – Comportement des agents dans JASDL

3.3.8.4 Argonaut

Le but fixé par Argonaut est d’utiliser Jason et Jena afin de rendre possible lesapplications sensibles au contexte en utilisant les capacités de représentations et deraisonnement des ontologies. A cette fin, l’intégration de Jena est faite de manièreexterne à Jason. Les composants BDI de l’architecture Jason ne sont pas modifiés pourl’occasion.

Les agents peuvent alors échanger des information de contexte représentés au formatOWL. L’intéraction entre Jason et les ontologies sont faites au travers de Jena, parl’intégration de deux fonctions dans la base d’actions internes des agents. Les résultatsdes requètes sur les ontologies sont transformées pour être intégrés dans la base decroyances de l’agent.

Cette approche utilise certes OWL, mais d’une manière externe à l’architecture del’agent. L’objectif visé est ici les application sensibles au contexte. Seule une partiedes connaissances est représentée en OWL, les connaissances ne concernant pas lesproblématiques de contexte sont au niveau AgentSpeak. L’utilité de cette approche parrapproche à une définition en AgentSpeak n’est pas mise en avant et les bénéfices ne sontpas montrés. Aucune implémentation d’Argonaut n’est fournie, il est donc impossiblede tester le fonctionnement du système.


Argonaut OWL DL et Prolog Non Fermé

TABLE 3.5 – Représentation des connaissances dans Argonaut



Argonaut BDI/AgentSpeak Horn Non

TABLE 3.6 – Comportement des agents dans Argonaut

3.3.8.5 3APL

3APL est un langage expérimental de programmation d’agents développé à l’univer-sité d’Utrecht aux Pays-Bas [Hindriks99]. 3APL reprend les concepts de de croyances etde capacités de AGENT-0 et rajoute les concepts de buts et de plans. Les agents 3APLsuivent un processus délibératif pour élaborer les plans qui vont conduire à la réalisationdes buts assignés à l’agent. Le cycle de délibération de l’agent est présenté dans la figure3.9.

FIGURE 3.9 – Cycle délibératif des agents 3APL [Hindriks99]

Pour compléter les buts qui lui sont assignés, l’agent peut disposer de règles deplanification dites règles PG ainsi que de règle de révision du plan, qui sont les règles PR.Le squelette d’un agent 3APL est présenté en figure 3.10. Il illustre les 6 composantes del’agent. Bien que développé en JAVA, 3APL fonctionne avec une syntaxe de type Prolog,pour le stockage des informations ainsi que pour les opérations logiques. Le langage3APL est un mélange de programmation impérative et de programmation logique. Dela programmation impérative, on retrouve par exemple les fonctions récursives alorsque la partie logique est utilisée pour les requètes sur la base de connaissance. Lesconnaissances des agent 3APL sont représentées dans le langage 3APL qui est trèssimilaire au langage de programmation logique de type Prolog.


PROGRAM "agent"BELIEFBASE {}CAPABILITIES {}GOALBASE {}PLANBASE {}PG-RULES {}PR-RULES {}

FIGURE 3.10 – Squelette d’un agent 3APL


3APL type Prolog Horn Non Fermé

TABLE 3.7 – Représentation des connaissances dans 3APL

3.3.8.6 S-APL

Les avancées des technologies du Web Sémantique se retrouvent aussi dans leursapplications aux agents, notamment dans la réalisation de langages de programm-tion agents. Le design Semantic Agent Programming Language [Katasonov08] est orientévers une description ontologique non seulement de l’environnement mais des agentseux-mêmes. On retrouve une représentation sémantique des agents dans AgentOWL[Laclavik06b]. La représentation des agents dans leur propre base de connaissancesentraine une capacité de réflexité pour les agents.

S-APL se situe à la jonction d’AgentSpeak, d’un raisonneur sémantique, en l’occur-rence Closed World Machine (CWM [Berners-Lee00]) et de l’architecture BDI. S-APLutilise le RDF (en notation N3) comme langage de représentation. Les inférences sontfaites par le raisonneur CWM, dans une logique du premier ordre en monde fermé (sansla négation 14). L’architecture en couches de S-APL (figure 3.11 se base sur la descriptionsémantique de comportement (dans la couche belief data storage) qui utilise des com-portements réutilisables programmés en JAVA, les RAB pour Reusable Atomic Behaviour.

14. Pour plus de détails sur CWM, le lecteur se reportera à http://www.w3.org/2000/10/swap/doc/paper/


3APL Règles(type Prolog) Horn Non

TABLE 3.8 – Comportement des agents dans 3APL

http://www.w3.org/2000/10/swap/doc/paper/

http://www.w3.org/2000/10/swap/doc/paper/


FIGURE 3.11 – Architecture des agents dans S-APL [Katasonov08]

L’envoi des messages en utilisant la classe JAVA ubiware.shared.MessageSenderBehavior,se fait en S-APL de la manière suivante :

{sapl:I sapl:do java:ubiware.shared.MessageSenderBehavior}

sapl:configuredAs {

p:receiver sapl:is :John.

p:content sapl:is {:get :temperatureIn :room1}

sapl:Success sapl:add {:John :informs :temperature}

}

Le message ci-dessus est envoyé à John et l’informe de la température dans lapièce n°1. En cas de succés, l’agent ajoute dans ses croyances que John a été in-formé de la température. Ce message illustre le mélange d’appel à des classes JAVA(ubiware.shared.MessageSenderBehavior) et de langage S-APL.

L’architecture proposée par S-APL permet un échange sémantique de comporte-ment entre les agents, cependant on peut regretter que S-APL n’utilise pas OWL et serestreigne à une représentation en RDF et à une logique du premier ordre en mondefermé, nettement moins expressive que la logique de description d’OWL-DL.

3.3.8.7 Nuin

Nuin est une architecture d’agent conçue pour le développement d’applicationsorientées web sémantique et basées sur des agents [Dickinson03]. Les agents Nuin pos-



S-APL RDF Premier ordre Non Fermé

TABLE 3.9 – Représentation des connaissances dans S-APL


S-APL CWM Premier ordre Oui

TABLE 3.10 – Comportement des agents dans S-APL

sèdent une architecture BDI et sont programmés dans un langage propriétaire NuinScriptbasé sur Prolog et AgentSpeak(L). Le rôle de NuinScript est de combler certains pro-blèmes d’AgentSpeak concernant l’échec de plans (l’échec d’un élément entraine l’échecdu plan en AgentSpeak, ce qui peut être problématique 15. La logique utilisé dans leprocessus de décision de Nuin est celle de l’interpréteur Prolog, qui est une logiquedu premier ordre restreinte aux clauses de Horn. La communication entre les agentsest effectuée par la plate-forme JADE. Les connaissances des agents Nuin peuvent êtrereprésentée à l’aide de différents formats. RDF est le format de base de représentation,KIF et OWL sont aussi supportés. A chaque format de représentation est associé unraisonneur. Plusieurs formats de représentation peuvent coexister, de même que plu-sieurs raisonneurs associés à ces formats. Les exemples données dans [Dickinson03] citel’utilisation de RDF, DAML-OIL et OWL.

Les agents Nuin permettent de manipuler des connaissances représentées dans lesformats du web sémantique, mais tout comme S-APL, Nuin se restreint à l’utilisationd’une logique du premier ordre. Dans [Dickinson03], les auteurs indiquent que les agentsNuin ne requiert qu’un fichier RDF pour être exécuté. Ce fichier de configuration contienten fait le lien vers le fichier de script NuinScript qui contient le programme exécutablepar l’agent. Ce langage propriétaire qui n’est pas compatible avec les formats du websémantique restreint les capacités des agents à raisonner sur leur propre architecture.


Nuin Variable Variable Non Fermé

TABLE 3.11 – Représentation des connaissances dans Nuin

15. Pour une description plus avancée des limitations d’AgentSpeak(L), le lecteur se reportera à[Dickinson03], section 3.1.2.


FIGURE 3.12 – Architecture du système Nuin [Dickinson03]


Nuin BDI (NuinScript) Horn Non

TABLE 3.12 – Comportement des agents dans Nuin

3.3.8.8 Jazzyk

Le langage Jazzyk créé par Peter Novák [Novák08a], est un langage de program-mation d’agents dont la fonctionnalité principale est d’exploiter différents systèmesde représentations de connaissance (Knowledge Representation ou KR par la suite) enutilisant différents modules d’interface entre ces KR. Jazzyk implémente le principe desBehavioural State Machines (BSM). Le principe des BSM ressemble fortement à celui desarchitectures BDI, les états sont les états mentaux des agents qui sont des modules KR.Un des aspects importants des BSM est la différence strictre entre la notion de couchede représentation de connaissance et de couche comportementale. En effet pour gérerdes modules de KR hétérogènes, l’auteur a choisi de ne pas représenter les comporte-ments comme des connaissances reliées à un module KR. La couche responsable ducomportement est donc distincte de celle de la représentation de connaissances.

L’évaluation des critères d’analyse variant en fonction des modules de KR intégrésdans les agents, nous ne présentons pas de comparaison ici. On notera l’existence d’unmodule utilisant des logiques non monotones [Novak08b].


3.3.8.9 Conclusion sur les langages de programmation d’agents

Les langages dédiés aux agents ont évolué, notamment sous l’impulsion des travauxde Rao vers une utilisation de la programmation logique comme outil principal desinterpréteurs. Les clauses de Horn sont donc majoritairement utilisées, du fait de leursupport par les langages de type Prolog qui sont utilisés pour les interpréteurs. Deslangages plus récents tel que S-APL, Picola [Buhler03] ou Qu-Prolog [Clark01] utilisentune approche similaire.

Les composants principaux ont peu évolué, si la notion d’engagement définie parShoham a été abandonnée, les architectures délibératives de 3APL et de AgentSpeakse basent sur les notions de croyance et de capacité. Les langages plus récents commeJazzyk ou S-APL se concentre sur la problématique émergente de la représentationinterne de connaissances et le rapport au comportment de l’agent. Les approches sontdiamétralement opposées, S-APL décrit de manière sémantique les comportements alorsque Jazzyk sépare distinctement les notions de connaissances et de comportement.

3.3.9 Plates-formes

Une plate-forme d’agents est un ensemble d’outils logiciels permettant le dévelop-pement de systèmes multi-agents. Une plate-forme est notamment responsable de lagestion du cycle de vie des agents, du transport des messages entre les agents ainsique de la découverte des agents et des services. Certaines plates-formes spécifient leslangages de représentation des connaissances ou certaines éléments du comportementdes agents, c’est pourquoi nous les présentons ici.

La FIPA a proposé une architecture abstraite [FIPA02] pour la description des plates-formes multi-agents. Le but de la FIPA est de favoriser l’interopérabilité entre desplates-formes utilisant des mécanismes de communication différents. Pour permettrecette intéropérabilité, les comités de normalisation FIPA ont focalisé leur travail sur lespoints suivants :

– Découverte de services– Interopérabilité du transport de messages– Support de différentes représentations ACL– Support de différents contenus de messages– Support de différents systèmes de pages jaunesLes spécifications se sont regoupés en quatre points, décrits dans la figure 3.13

Les plates-formes que nous présentons par la suite implémentent les spécificationsde la FIPA.


FIGURE 3.13 – Plate-forme FIPA : Architecture abstraite

3.3.9.1 JADE

Développée par la Telecom Italia, la plate-forme JADE [Bellifemine99] respecte lesnormes d’interopérabilité de la FIPA en implémentant le langage FIPA-ACL commelangage de communication entre les agents. Une plate-forme JADE est formée d’un ouplusieurs containeurs, qui peuvent intéragir entre eux. Une plate-forme comporte deuxagents initiaux, le DF pour directory facilitator, qui fournit un système de pages jauneset l’AMS pour Agent Management System, qui contrôle la plate-forme.

FIGURE 3.14 – Architecture de la plate-forme JADE

Comportement des agents

Les comportements des agents sont implémentés en JAVA peuvent être de différentstypes :

– Simples– Réception de messages– Cycliques– Ticker (réactif)

– Composés de plusieurs comportements


– parralèle– séquentiel

JADE offre aussi de nombreuses librairies tierces-parties, parmi lesquelle se trouveJADEx [Pokahr05], qui introduit une architecture BDI dans les agents JADE. JADExdiffèrent des architectures BDI classique dans le sens ou la représentation des buts sefait d’une manière objet et non logique.

Les comportements des agents JADE sont développés selon une approche objet(au détriment des classiques approches logiques que nous avons vu dans la sectionprécédente), en implémentant un ou plusieurs des types de comportements cités ci-dessus. Malgré l’utilisation de JAVA, JADE n’a pas été conçue pour permettre uneréflexivité, aucun échange de comportement n’est possible entre agent JADE.

Les connaissances des agents sont nativement géré en RDF par JADE sans utilisationspécifique de raisonneur. JADE étant une plate-forme ouverte, l’utilisation d’outils plusavancés est laissée au choix du concepteur d’applications.


JADE RDF Non N/A N/A

TABLE 3.13 – Représentation des connaissances dans JADE


JADE Java N/A Non

TABLE 3.14 – Comportement des agents dans JADE

3.3.9.2 AgentOWL

AgentOWL est une librairie tierce partie pour JADE qui remplace l’utilisation deRDF par OWL pour la représentation des connaissances de l’agent. Cette extensionpermet d’étendre les capacités de représentation de l’agent. Dans AgentOWL, OWL estutilisé comme mode de représentation des connaissances et non de comportement. Lecomportement des agents reste programmé en JAVA exactement de la même manièreque pour JADE.

Les agents AgentOWL possèdent une représentation de leur propre architecture dansun modèle sémantique (fig. 3.15 qui est l’élément minimal de leur base de connaissance[Laclavik06a]. Ce modèle sémantique permet aux agents de raisonner sur leur proprearchitecture. AgentOWL est basé sur Jena et propose l’utilisation d’inférences du moteur


FIGURE 3.15 – Modèle Sémantique des agents dans AgentOWL

Jena. Cette librairie ne modifie pas le fonctionnement des comportements des agentsJADE, qui reste basé sur une approche objet.


AgentOWL OWL DL Non Ouvert

TABLE 3.15 – Représentation des connaissances dans AgentOWL


AgentOWL Java N/A Oui

TABLE 3.16 – Comportement des agents dans AgentOWL

3.3.9.3 SEAGENT

SEAGENT est un framework spécialisé dans le développement d’agents utilisant lestechnologies du web sémantique [Dikenelli05]. Compatible avec le langage FIPA-ACL,SEAGENT utilise un langage appellé SEAGENT Content Language comme langagede communication agent. La représentation interne des connaissances se fait à l’aided’OWL, la description des services fournis par les agents. L’architecture globale dela plate-forme est semblable à celle de JADE, à laquelle on ajoute un Semantic ServiceMatcher pour la découverte de service, en plus du DF (service de pages jaunes).


FIGURE 3.16 – Architecture globale de SEAGENT

SEAGENT propose de définir de manière sémantique les comportements réutili-sables des agents à l’aide d’OWL, ces comportements, d’une manière similaire à JADE,sont programmés en JAVA. SEAGENT n’utilise OWL que pour la représentation desconnaissances, un raisonneur simple OntoLog est utilisé pour le matching dans le com-posant Semantic Service Matcher. Cependant aucune information n’est fournie sur lescapacités du raisonneur ni sur le type de logique utilisée. L’utilisation des techniques deraisonnement OWL se limite donc à la découverte des services au sein de la plate-formeSEAGENT, les agents eux-mêmes ne possèdent pas de tels mécanismes. Pour résumer onpeut comparer SEAGENT à une plate-forme de type JADE dans laquelle une surcouchede description sémantique des services a été ajoutée.


SEAGENT OWL 16 N/A N/A Ouvert

TABLE 3.17 – Représentation des connaissances dans SEAGENT

3.3.10 Applications agents basés sur des connaissances



SEAGENT Java N/A Oui

TABLE 3.18 – Comportement des agents dans SEAGENT

Dans les parties précédentes, nous avons successivement abordé la gestion deconnaissances, les systèmes multi-agents et le Web Sémantique. Nous allons maintenantdécrire les applications qui se situent à l’intersection de ces trois domaines. En effet,nous avons pu voir au cours de ce chapitre les différents liens entre ces trois domaines semettre en place. La gestion de connaissances qui a évolué vers une approche distribuée,les apports du Web Sémantique pour la représentation des connaissances et les systèmesmulti-agents comme mise en œuvre de l’approche distribuée.

Les agents basés sur des connaissances que nous avons présentés en section 3.3.6.5, sesituent à l’intersection de ces domaines. Ces agents sont constitués de deux composantsprincipaux. Le premier étant la base de connaissance, qui contient la représentation dumonde de l’agent. Le second étant son mécanisme de décision, ou comportement quidirige les actions de l’agent en vue d’un but précis. Ces actions sont déterminées parinférences sur la base de connaissances [Calmet04]. Ce type d’agent est particulièrementadapté à la gestion des connaissances distribuées. L’accent sera mis dans cette partie surla représentation des connaissances ainsi que sur la modélisation des comportements.

Les agents basés sur des connaissances sont utilisés dans de nombreux domainesmettant en jeu leurs capacités spécifiques liées à leurs architectures. Nous traiteronstout d’abord des systèmes d’information multi-agents puis des systèmes de gestion deconnaissance basés sur des agents. Les deux domaines étant intimement liées. Nousprésenterons ensuite les applications de ces agents dans le cadre des organisationsvirtuelles et des environnements informatiques pour l’apprentissage humain (EIAH).

3.3.10.1 Système d’information multi-agents

Le concept de Système d’Information Multi-Agents (SIMA) ou Agent-Oriented Infor-mation Systems (AOIS), est apparu en 1999 avec l’organisation du premier workshopAOIS 17 lors de la conférence Agents’99.Dans [Strugeon08], les auteurs proposent uneméthodologie visant au développement de SIMA. Ils proposent de combiner les avan-tages des deux domaines (systèmes d’information et systèmes multi agents) en utilisantune méthodologie séparant au départ l’analyse des services et des agents pour ensuiteles intégrer. Dans le cadre des SIMA, les auteurs ont identifié trois caractéristiquesprincipales que doivent posséder les agents :

1. Intéraction avec les utilisateurs

17. http://www.aois.org/

http://www.aois.org/


2. Intéraction avec les sources de données

3. Matching entre les données et les besoins des utilisateurs

Cette méthodologie identifie ensuite les différentes étapes dans l’analyse des agentsselon les trois critères énoncés ci-dessus. Tout d’abord la spécification des rôles, buts,compétences et connaissances des agents. Suivent ensuite, le design du comportementdes agents suivant l’analyse faite à l’étape précédente et enfin l’implémentation et le testde ces comportements.

Les agents d’information, qui représentent une version simplifiée des agents ba-sées sur des connaissances, dans le sens ou ils manipulent des informations et nondes connaissances ont été utilisé avec succés dans le cadre des SIMA. De nombreusesapplications dans le domaine des assistants personnels [Modi04] ainsi que pour les ser-vices d’urgence [Chen04] ou encore pour les communautés virtuelles [Bryl06]. Dans cesapplications, l’architecture interne n’est pas explicitée, l’approche rôles/organisationsétant préférée.

3.3.10.2 Projet Comma

FIGURE 3.17 – Sociétés pour la gestion de la mémoire [Gandon02]

Le projet CoMMA (Corporate Memory Management through Agents [Perez00]) estun projet européen IST qui a démarré en Février 2000 et terminé en 2002. Le projet visaità développer et tester un système multi-agent de gestion de la mémoire d’entreprisebasé sur les formats du web sémantique. Gandon [Gandon02] propose dans le cadredu système CoMMA (Corporate Memory Management through Agents), d’utiliser une


approche multi-agents combinée avec les technologies du Web Sémantique dans le cadrede la gestion de connaissances d’une mémoire organisationnelle distribuée. Dans cesystème, les agents sont basés sur des technologies du web sémantique, en particulierle RDF. Dans son approche, l’auteur montre que la nature distribuée des SMA est enparfaire adéquation avec les besoins d’une mémoire organisationnelle. L’organisation duSMA est obtenu par raffinement successifs, en partant d’une société globale, puis en seg-mentant en sociétés imbriquées pour finalement atteindre le niveau minimal des agents.Ces raffinements successifs permettent de définir au plus bas niveau, les intéractions,rôles et protocoles dans l’organisation de la société d’agents.La mémoire d’entreprise estconstituée de documents annotés selon une ontologie définie en RDFS. Ce sont ces anno-tations qui sont gérées par CoMMA,. La recherche d’information se base sur le moteurCorese [Corby04] qui permet de manipuler RDFS et les graphes conceptuels. Le systèmemulti-agent intègre des agents utilisateurs, et des agents intermédiaires. Ces agents sontorganisés dans quatre sociétés, dont les noms et rôles sont décrits dans la figure 3.17. Leprototype du système a été implémenté en JAVA, en utilisant la plate-forme JADE.


CoMMA Documents et métadonnées Non Oui N/A

TABLE 3.19 – Représentation des connaissances dans CoMMA


CoMMA Ad hoc N/A Non

TABLE 3.20 – Comportement des agents dans CoMMA

3.3.10.3 KEx

KEx [Bonifacio03] propose une approche basé sur 2 rôles et 5 services pour la gestionde connaissance distribuées dans un environnement pair-à-pair. L’architecture globaledu système est donnée par la modélisation en rôles et intéractions. Dans KEx les agentspeuvent être soit "chercheur" (seeker dans le texte) ou bien "fournisseur" (provider).Chaque agent peut fournir un ou plusieurs des services suivant en se basant sur sesconnaissances :

– Normalisation et enrichissement du contexte : le service effectue une normali-sation linguistique du contexte utilisateur en utilisant des outils de traitementautomatique du langue naturel et la base Wordnet.

– K-federation : une fédération est un regroupement d’agents qui apparaissent alorscomme un agent unique dans le système. Les requètes sont alors distribuées dansla fédération puis les réponses sont agrégées.


– Propagation de requètes : dans KEx, lorsqu’un agent reçoit une requète il peut lareformuler sémantiquement à l’aide de son propre contexte utilisateur. La nouvellerequète est alors transmise aux agents connus possédant le même contexte.

– Apprentissage : lors de la réception d’une réquète, un agent peut choisir d’intégrerles mappings sémantiques utilisés dans la requèete. De même, ces mappingspeuvent être intégrés par l’agent qui a émis la requète lorsqu’il en reçoit la réponse.

Dans le système KEx, tout les agents possèdent la même architecture (Fig. 3.18) :

FIGURE 3.18 – Composants principaux de KEx [Bonifacio03]

Les agents possèdent des connaissances stockées sous formes de documents (do-cument repository) ainsi que des connaissances strucuturées de manière sémantiquedans le context repository qui servent entre autre à décrire les documents. Cependant leprocessus de décision des agents, n’est pas explicité. De nombreux choix d’implémenta-tions ne sont pas explicités : dans quelles circonstances un agent choisit-il d’enrichir unerequète ? comment choisit-il de créer une fédération ? D’un point de vue technique, lacommunication entre les agents est effectuée en utilisant le framework JXTA.

On notera que les différents langages d’agents présentés en section B.1 ne sont pasutilisés dans les différents systèmes que nous avons étudié dans cette section. Les com-portements des agents peuvent pourtant être décrits selon des architectures standardstelle que BDI. Les plates-formes qui gèrent les problèmes de communication entre agents,telles que JADE ou JXTA sont par contre très majoritairement utilisées.



KEx Documents et métadonnées Non Oui N/A

TABLE 3.21 – Représentation des connaissances dans KEx


KEx Ad hoc N/A Non

TABLE 3.22 – Comportement des agents dans KEx

3.3.10.4 Organisations virtuelles

Les organisations virtuelles ou plus souvent entreprises virtuelles sont des alliancestemporaires d’entreprises partageant leurs ressources et compétences dans le but parexemple d’exploiter une niche de marché ou de proposer un service mettant en jeuleurs différents ressources ou compétences. Les agents basés sur des connaissancesont été dans les prototypes CONOISE [Norman04] et CONOISE-G [Patel06]. Ces proto-types s’intéressent plus particulièrement au processus de formation des organisationsvirtuelles.

Le mécanisme de décision interne à chaque agent est basé sur le principe de satis-faction de contraintes (CSP). Ce mécanisme est couplé à un système d’enchères pourl’allocation des contrats au sein de l’organisation.

FIGURE 3.19 – Processus de décision des agents dans CONOISE [Norman04]

Pour faire face aux problèmes de confiance et de sécurité dans la formation des


organisations virtuelles, CONOISE a été étendu et renommé CONOISE-G [Patel06].Dans le cas d’information non vérifiable, de présence d’intrus ou d’agents malicieuxdans une organisation virtuelle, l’architecture de CONOISE-G permet la reformationdynamique d’une nouvelle organisation. Martinez et Al. [Martinez01] ont identifié lesdifférences services nécessaires à la gestion et au contrôle d’une organisation virtuelleexistante dans le cadre d’une approche multi-agents.

Dans ces applications au cadre des organisations virtuelles, les agents détiennentdes connaissances sur le prix, la qualité des services des autres agents, l’enchaînementdes services, leurs besoins.Ces connaissances détenues par les agents sont complètes etstructurées. De plus les agents disposent d’un niveau de confiance

Les décisions relatives au mécanisme d’enchères sont prises par un algorithme derésolution de contraintes (CSP). L’implémentation du prototype [Patel05] est faite à l’aidede JADE et les connaissances des agents sont représentées en RDF. L’implémentation del’algorithme de CSP n’est pas explicitée.

Les agents CONOISE étant dédiés à une tâche bien précise selon leurs rôles (broker,médiateur, confiance), les auteurs n’ont pas eu besoin de proposer un modèle sémantiquepour ces agents. Ces agents ne possèdent donc pas de réflexivité.


Conoise-G RDF Non Oui Fermé

TABLE 3.23 – Représentation des connaissances dans CONOISE-G


Conoise-G Ad hoc N/A Non

TABLE 3.24 – Comportement des agents dans CONOISE-G

3.3.10.5 Apprentissage électronique

L’apprentissage électronique, aussi appellé apprentissage en ligne ou e-learningest défini comme (Union européenne 18) "l’utilisation des nouvelles technologies mul-timédias de l’Internet pour améliorer la qualité de l’apprentissage en facilitant d’unepart l’accès à des ressources et à des services, d’autre part les échanges et la collabo-ration à distance". Les systèmes informatiques utilisés pour l’apprentissage en lignesont nommmés du terme anglais LCMS (Learning Content Management System). Dansla majorité des systèmes existants on retrouve des fonctionnalités tels que la mise en

18. http://ec.europa.eu/education/archive/elearning/summit.pdf

http://ec.europa.eu/education/archive/elearning/summit.pdf


ligne de contenu, évaluation par QCM, texte à trous, ... Les enseignants et étudiantscommuniquent par l’intermédiaire des moyens de communications électroniques.

Au sein des LCMS, les systèmes multi-agents peuvent intervenir dans les différentesparties d’un LCMS. Ils peuvent fournir un recherche personnalisée aux utilisateurs ense basant sur leurs spécifications [Pankratius04]. Shi et al. [Shi02] proposent de rem-placer l’enseignant par un agent intelligent qui s’adapte à l’étudiant. En se basant surune approche connectionniste (carte auto adaptative) qui modélise le comportmentde l’étudiant, l’agent est capable de proposer un environnement personnalisé d’ap-prentissage. Les agents tuteurs sont communément utilisés pour la modélisation ducomportement de l’étudiant ainsi que pour la prise de décision dans un cadre didactique[Ritter95, Ritter96]. Ces agents tuteurs ont ensuite été étendus pour permettre la commu-nication et la coopération afin d’améliorer leurs performances. [Ritter97]. De nombreusesapproches proposent des plates-formes multi-agents génériques pour l’apprentissage[Capuano00, Vassileva99, Machado99, Cobo07].

Les agent de la plate-forme I-Help [Vassileva99] utilise une représentation partagéede leurs connaissances, ce qui garantit la consistance des connaissances du système. Lacommunication s’effectue en utilisant le langage KQML. L’évaluation des buts ainsi quela prise de décision sont opérées par un raisonneur Prolog. La logique utilisée dans laprise de décision est donc celle des clauses de Horn.

Dans ABITS [Capuano00] (Fig. 3.20), les connaissances sont représentées suivantle schéma IEEE LTSC LOM à l’aide de graphes conceptuels. Ce choix des graphesconceptuels peut paraître étrange puisque le schéma IEEE LTSC LOM est entre autrebasé sur Dublin Core dont une spécification RDF existe déjà. De plus les métadonnéessont quant à elles représentées en RDF. Bien qu’il existe des méthodes de mapping deRDF et des graphes conceptuels (tel que Corese [Corby00]), ces méthodes ne sont pasmentionnées. La communication entre agents se fait selon le format d’échange standarddes graphes conceptuels (CGIF). Les agents ABITS peuvent modéliser l’état cognitifet les préférences d’apprentissage de chacun des étudiants par un modèle basé sur lalogique floue. Les différentes préférences (pré-établies) de l’étudiant sont représentéspar une nombre flou. La logique floue utilisée n’est pas non plus spécifiée, alors qu’ilen existe de très nombreuses (monoïdale, basique, Lukasiewicz, . . .). La plate-formeproposée est intéressante du point de vue agents (autonomes et multi-agents), mais estdesservie par le manque d’exemples et l’absence d’implémentation qui aurait permis delever certaines ambiguités.

La plate-forme de communication d’agents pédagogiques (PACF dans le texte)[Machado99], utilise le format KQML pour la communication inter-agents. En interneles agents utilisent une représentation JAVA qui est transmis par sérialisation. Ces procé-dés, sont peu adaptés à l’interopérabilité. La transformation des connaissances dans unlangage de bas niveaux posent de sérieux problèmes d’interopérabilité puisque seuls


FIGURE 3.20 – Architectures interne et externe de ABITS [Capuano00]

des agents programmés en JAVA sont capables de les manipuler. La sérialisation estaussi un choix peu judicieux, puisque ce mécanisme ne permet pas la rétro-compatibilitédu format.

AgentGeom [Cobo07] est une plate-forme d’apprentissage dédiée aux problèmes ma-thématiques et notamment géométriques. L’idée principale qui sous-tend la conceptionde la plate-forme est de pouvoir aider l’étudiant pas à pas dans la résolution de pro-blèmes géométriques. Cette aide se concrétise par l’envoi de messages d’un agent tuteur,dans un processus argumentatif avec l’étudiant. La nature complète des connaissances(un problème à résoudre et les différentes étapes successives pour y arriver) simplifienettement la tâche qui incombe à l’agent tuteur, si l’on compare avec les plates-formesprécédemment décrites. La sélection des messages à envoyer se fait par le parcours d’unarbre de la résolution du problème. Cet arbre contient les actions à effectuer en fonctionde l’état d’avancement de l’étudiant.

Ces plates-formes utilisent différentes représentations des connaissances et ne sontmajoritairement pas basées sur des technique avancées de représentation de connais-sance. Ceci s’explique en grande partie par le fait que ces contributions sont majoritai-rement antérieures à la popularisation des standards actules du web sémantique telsque RDF ou OWL. Toutefois, les contributions plus récentes telles que [Wang05] se pro-posent d’utiliser les outils du web sémantique dans la représentation des connaissances.[Wang05] propose d’utiliser OWL comme langage de représentation des connaissancespour vérifier la sémantique des communications entre l’étudiant et le professeur. Cepen-


dant l’application proposée n’a pas été implémentée, il est donc impossible d’analyserles critères relatifs à la décision des agents (logique,monde, . . .).

Nous présentons dans le tableau ci-dessous, un récapitulatif des différents systèmesétudiés selon les critères énoncés en 3.3.7.


ABITS CG/RDF Non Oui N/AI-Help Prolog Horn Oui N/APACF Java Oui Non N/A

AgentGeom Arbres Non Oui N/A

TABLE 3.25 – Représentation des connaissances dans les systèmes d’EIAH


ABITS Ad hoc N/A NonI-Help Ad hoc N/A NonPACF Ad hoc N/A Non

AgentGeom Ad hoc N/A Non

TABLE 3.26 – Comportement des agents dans les systèmes d’EIAH

3.3.10.6 Autres Applications

Nous décrivons dans cette partie, des applications mettant en œuvre des agentsbasés sur des connaissances, dont le domaine d’application ne rentre dans aucun descadres énumérés ci-dessus.

Bibster

Bibster [Haase05] est une implémentation de l’architecture SWAP [Ehrig03]. Le butde Bibster est de proposé aux chercheurs de partager leurs ressources bibliographiquesen utilisant un système pair à pair. Dans Bibster les références bibliographiques sontles connaissances échangées à travers le systèmes. Leur description est fixée par deuxontologies. La première ontologie (SWRC) décrit les différents aspects génériques desmétadonnées bibliographiques, la deuxième ontologie (Hiérarchie des thèmes ACM)décrit les différentes catégories pour la littérature dans le domaine de l’Informatique. Lesconnaissances échangées sont en fait des entrées bibliographiques au format RDF. Lesontologies de domaine sont fixées dans l’application, les agents échangent des instancesde ces ontologies. Les agents Bibster sont des pairs utilisant la plate-forme pair-à-pairJXTA de SUN pour la communication. L’architecture des agents est identique à tous


les agents. Les connaissances échangées entre les agents concernent exclusivement desressources bibliographiques qui sont formalisés de manière statique. Les connaissancessont donc consistantes au sein de l’application Bibster.


Bibster RDF Non Oui N/A

TABLE 3.27 – Représentation des connaissances dans Bibster


Bibster Java N/A Non

TABLE 3.28 – Comportement des agents dans Bibster

3.3.11 Conclusion de l’état de l’art sur les agents

Nous avons focalisé notre étude sur deux classes de critères, la représentation desconnaissances et les comportements des agents. Le tableau 3.29 permet de mettre enperspective les différentes approches de représentation des connaissances, le tableau3.30 décrit quant à lui les approches en matière de comportement.

La problématique de représentation des connaissances au sein des agents suit ledéveloppement des technologies du web sémantique qui ont permi, grâce tout d’abordà RDF puis à OWL d’améliorer les capacités de représentation des agents. Les moteursd’inférence logique liées à ces technologies permettent aux agents la découverte denouvelles connaissances à partir de celles déjà existantes. Cependant ces capacités nesont pas pleinement utilisées, notamment OWL, comme on peut le voir dans SEAGENTou AgentOWL, puisque la capacité de représentation n’est pas utilisée avec la logique dedescription qui est à la base de ce langage. On a donc une sous-utilisation des capacitésde représentation et d’inférence. Toujours d’un point de vue logique, l’hypothèse demonde fermé est très largement utilisée et comme nous l’avons vu en section 3.2 ellen’est pas cohérente avec la représentation que nous nous faisons du monde. L’approchelogique au niveau des connaissances, en tant que système inférentiel est présente dansles trois domaines que nous avons étudiés. Ce n’est pas une surprise car les outilsdisponibles (Prolog ou logique de description) s’intègre sans difficulté technique danstout type d’architecture. Il est plus étonnant de noter que les technologies plus récentes(bien que OWL soit une recommandation W3C depuis Février 2004) sont en premier lieuintégrées dans les approches génériques (langages de programmation et plates-formes),les applications dédiées utilisant des technologies plus anciennes.


Les comportements des agents sont souvent disjoints de leur base de connaissance,un langage comme Jazzyk y met par exemple un point d’honneur. Les applications dé-diées fonctionnent à l’aide de langage objet, majoritairement le JAVA, ce qui exclut toutesémantique dans les comportements d’agents. Pour pallier ce manque, les approchesde S-APL ou SEAGENT proposent une description sémantique de ces comportements,pour la découverte et la composition de comportements en utilisant des mécanismesinspirés des Web Services. Dans les trois domaines étudiés, les langages de program-mation du comportement et ceux de la représentation de connaissance sont différentsdans la très grande majorité des cas, sauf pour les architectures BDI. Dans le cas précisdes architectures, le lien entre base de connaissance et comportement est réalisé auniveau des croyances (B de BDI). L’implémentation de cette architecture se base surl’utilisation de raisonneur de type Prolog, ce qui restreint par conséquent la logiqueutilisée pour la base de connaissances à la logique du premier ordre. Les logiques dedescription utilisée dans OWL sont dotées d’une expressivité plus grande mais ellesn’ont pas été implémentées dans les architectures BDI. Les différentes tentatives (JASDL,Argonaut) n’ont pas pu fournir d’implémentation. L’unification du comportement et dela base de connaissance autour d’OWL reste donc un problème ouvert. La question de lareflexivité dans les architectures est souvent ignorée dans le cadre des langages agentsalors que c’est à ce niveau qu’on pourrait s’attendre à la voir apparaître. Seuls S-APL etune extension de Jason (non implémentée) proposent cette fonctionnalité, mais aucun demanière satisfaisante. La dualité langage de raisonnement et langage d’implémentationdes fonctions est le facteur limitant à l’échange des comportements entre agents dans lesdeux cas.

En conclusion, l’utilisation des technologies du web sémantique est un standardincontestable dans le monde agent pour la représentation des connaissances. Cependantl’utilisation des capacités de raisonnement n’est pas encore utilisée dans la réalisationdes comportements des agents. Nous discutons dans l’analyse en section suivante desmoyens d’aborder ce problème.

3.4 Analyse et mise en perspective

L’analyse de l’état de l’art se structure autour des questions que nous avons posées àla fin du chapitre précédent. Tout d’abord nous analyserons la perspective de l’architec-ture des agents, en vue de permettre l’échange des différents composants d’une basede connaissance. L’échange de ces composants introduit des problèmes d’intégrationsdans la base de connaissances des agents. Lors d’intéraction avec d’autres agents, ilest souhaitable de disposer d’un processus permettant de choisir ou non d’intégrer cesnouvelles connaissances. En nous basant sur les notions définies en épistémologie nousdiscutons des approches pouvant apporter des pistes pour ce problème.

Section 3.4. Analyse et mise en perspective 123


Langages de programmation agentsJASON AgentSpeak(type Prolog) Horn Non FerméJASDL OWL et AgentSpeak DL et Prolog Non Fermé

Argonaut OWL DL et Prolog Non Fermé3APL type Prolog Horn Non FerméS-APL RDF Premier ordre Non FerméNuin Variable Variable Non Fermé

Agents au sein des plates-formesJADE RDF Non N/A N/A

AgentOWL OWL DL Non OuvertSEAGENT OWL 19 N/A N/A Ouvert

ApplicationsCoMMA Documents et métadonnées Non Oui N/A

KEx Documents et métadonnées Non Oui N/AConoise-G RDF Non Oui Fermé

Bibster RDF Oui FerméABITS CG/RDF Non Oui N/AI-Help Prolog Horn Oui N/APACF Java Oui Non N/A

AgentGeom Arbres Non Oui N/A

TABLE 3.29 – Récapitulatif des représentations des connaissances

3.4.1 Agents et composants

Nous avons recherché dans trois catégories (langages de programmation agent, plate-forme agents et des applications basées sur des agents) une architecture supportant nosbesoins d’échange de connaissances. A la question d’une architecture agent pouvantsupporter l’échange des différents composants de l’AOA, nous avons vu qu’aucune desarchitectures proposées ne permet de le faire. Toutes les architectures d’agents qui ont étéprésentées utilisent en grande majorité un langage de bas niveau pour le comportementet un langage du web sémantique pour représenter la base de connaissances (S-APL,VKC, Nuin). Dans les architectures de type BDI (Jason, 3APL, Jadex), on retrouveune approche similaire dans la dualité des langages au sein des agents. Chaque agentpossède au moins deux langages, un qui permet d’exprimer le comportement au sens del’approche BDI (i.e. AgentSpeak) et un langage de plus bas niveau (Java). Les applicationsque nous avons présenté en section 3.3.10 souffre toutes de limitations semblables.

La volonté d’unification se retrouve dans des approches comme JASDL, dans letravaux de Moreira, Argonauts et S-APL. Cependant aucune ne permet d’unifier com-portement et connaissance. S-APL, le seul de ces langages dont une implémentation est



Langages de programmation agentsJASON BDI/AgentSpeak Horn Non 20

JASDL BDI/AgentSpeak Horn NonArgonaut BDI/AgentSpeak Horn Non

3APL Règles(type Prolog) Horn NonS-APL CWM Premier ordre OuiNuin BDI (NuinScript) Horn Non

Agents au sein des plates-formesJADE Java N/A Non

AgentOWL Java N/A OuiSEAGENT Java N/A Oui

ApplicationsCoMMA Ad hoc N/A Non

KEx Ad hoc N/A NonConoise-G Ad hoc N/A Non

Bibster Ad hoc N/A NonABITS Ad hoc N/A NonI-Help Ad hoc N/A NonPACF Ad hoc N/A Non

AgentGeom Ad hoc N/A Non

TABLE 3.30 – Récapitulatif des comportments agents

fournie, propose de réutiliser des composants Java partagé entre les agents. L’appel à unlangage de bas niveau est toujours présent.

Dans la conclusion de l’article présentant JASDL, il est mis en avant que JASDLpermet de définir des nouvelles intéractions au niveau de l’ontologie, mais qu’à la dif-férence d’Argonauts ou les implémentations de ces intéractions doivent être faites enJAVA, celle de JASDL sont réalisées en AgentSpeak, soit un niveau au dessus. De plus,il est très important de noter que hormis S-APL, les approches précédentes (JASDL etArgonauts) n’ont pas été implémentées. Si nous n’en connaissons pas les raisons exactes,notre hypothèse est que la complexité de l’approche BDI, combinée à celle d’OWL doitêtre très difficile à mettre en œuvre. A la lumière de ces considérations, deux problèmesd’architecture ne permettent pas la réalisation de l’échange des composants d’une basede connaissance. Tout d’abord, l’utilisation de deux langages pour les agents, un pourles comportements et un pour les connaissances ou pour les actions est limitant. Mais onpourrait contourner cette difficulté en réalisant deux modules réflexifs, l’un pour chaquelangage. De nombreuses architectures sont réalisées en Java, il suffirait par exemple dansle cas de JASDL de permettre l’échange lié de plans, croyances et d’implémentationsd’action. Cette approche ne nous parait satisfaisante. D’un point de vue de conception


logicielle, il est plus simple d’utiliser seulement un seul langage. En terme de représenta-tion de connaissances, OWL s’est imposé dans de nombreuses architectures récentes et ilnous semble être un choix judicieux. Nous sommes alors tentés de résoudre le problèmede la même manière que Moreira [Moreira06]. Le second problème intervient alors, parla complexité de la réalisation. Le fait qu’aucune implémentation ait été proposée peutêtre une raison suffisante de ne pas vouloir définir une architecture BDI utilisant unraisonneur OWL. En effet l’architecture BDI est séduisante par ses possibilités, mais elleest complexe à mettre en œuvre avec des logiques de description. Il est plus judicieuxdans une approche que nous souhaitons implémentable de procéder plus simplement.

A l’aide du langage de règles SWRL, dont la syntaxe est compatible avec OWL(c’est-à-dire que l’on peut définir une ontologie contenant des éléments OWL et SWRLdans le même fichier), il est possible de définir un comportement sous forme de règlesexécutables par un interpréteur. L’architecture BDI étant complexe à implémenter etn’étant pas requise pour notre approche, le premier prototype des VKC fonctionnant avecdivers types de comportements, nous pouvons nous orienter sur une autre approche.

Il faut noter que le langage SWRL ne permet pas à lui seul de programmer des agents(absence de fonctions d’entrées/sorties entre autres). L’utilisation d’un langage de plusbas niveau est alors nécessaire. Le problème de la définition de nouvelles actions etleurs implémentations dans des langages de plus bas niveau que OWL (par exempleAgentSpeak ou Java) peut être résolu de manière simple. JASDL ou S-APL proposentde définir parallèlement de nouvelles actions en des déclarant dans les ontologies et endonnant une implémentation liée à cette déclaration (en JAVA pour S-APL, AgentSpeakpour JASDL). Nous proposons de définir un nombre fini d’actions dont on établitla correspondance entre l’ontologie et l’implémentation. Pour définir de nouvellesactions, on les compose à partir des actions prédéfinies dans l’ontologie. Le but de cetteapproche est d’avoir un interpréteur universel à tous les agents, capables d’éxécuter uncomportement reçu lors d’une intéraction, sans avoir à transmettre d’implémentationdans un langage de bas niveau. Toutes les actions basiques sont communes aux agents.Les actions complexes sont réalisées à l’aide de ces briques de base.

En ce qui concerne la structure de l’agent, nous avons vu que l’architecture BDIsemblait difficile à mettre en œuvre en OWL, de plus elle n’est pas requise pour notreimplémentation. C’est pourquoi nous proposons d’utiliser le concept des machinesétendues à état finis (EFSM), pour représenter les comportements des agents. Pour leconfort du lecteur, nous donnons ci-après un bref rappel de cette notion.Les EFSMsont des versions étendues des automates finis classiques, ce qui signifie concrètementqu’à chaque transition est associée un ensemble d’actions qui seront exécutées lors de latransition [Cheng93]. Ces automates se définissent formellement de la manière suivante :

Une EFSM est un 7-tuple M = (I, O, S, D, F, U, T) avec– S un ensemble de symboles d’états,


– I un ensemble de symboles d’entrées,– O un ensemble de symboles de sorties,– D un espace linéaire de dimension n D1 × . . .× Dn,– F un ensemble de fonctions d’activations fi : D → {0, 1},– U un ensemble de fonctions de mise à jour ui : D → D,– T un relation de transition, T : S× F× I → S×U ×Oune EFSM est dite déterministe, si et seulement si T est une application de S× F×

I dans S × U ×O. C’est-à-dire qu’à chaque triplet état, symboles d’entrée, fonctiond’activation, on associe un seul triplet état, symboles de sortie, fonction de mise à jour.Plus simplement, lorsque les conditions (F) sont remplies pour la transition (T) de lamachine d’un état vers le suivant (les états sont notés S), un ensemble d’opérations Uest effectué.

Les EFSM nous fournissent un cadre permettant de réaliser simplement des com-portements d’agents définis seulement en OWL et SWRL, donc au niveau sémantique.Nous présentons dans le chapitre suivant notre proposition de modèle d’agent se basantsur les EFSM.

3.4.2 Echanges des différents types de connaissances

Le point central de notre approche est de rendre possible l’échange entre agents desdifférents composants qui constituent la base de connaissances d’un agent. Dans le casdes connaissances représentées de manière logique, le fonctionnement des raisonneursfait écho à la théorie de la justification. Cependant le cas des connaissances qui nerelèvent pas du domaine logique est encore ouvert. La question de la justification deces connaissances lors d’un échange entre agent est cruciale. Quelles sont les raisonsou justifications qui doivent inciter un agent à accepter certaines connaissances (nonlogiques) et à en refuser d’autres ?

La spéficité des agents gérant des connaissances par rapport aux systèmes basés surdes connaissances est la capacité d’action. Si l’on considère ce qui relève de l’action desagents (comportement de l’agent, plans dans les architectures BDI) comme connaissanceéchangeable, il est nécessaire de faire intervenir un processus de justification dans leséchanges de telles connaissances.L’étude de la théorie de la justification concernant lesconnaissances empiriques nous donne une solution par l’expérimentation. L’exemplede la connaissance du chemin, dont l’interlocuteur ne peut être convaincu qu’en ex-périmentant ce chemin 21 (cf page 62) est tout à fait adaptable à un système d’agentcommuniquant.

21. Il est possible d’argumenter le fait que le chemin est justifiable de manière logique par la connaissanced’une carte, auquel cas c’est la carte qui devra être soumise à l’expérience pour être justifiée.


A cette fin, nous proposons une différentiation des connaissances au niveau de l’agentselon le niveau auquel elles interviennent dans l’architecture. Nous avons précédemmentexclu les architectures BDI de notre approche, les considérations qui suivent s’appliquentaux autres architectures 22. Les connaissances empiriques entrainent (par définition del’expérience) une exécution d’actions de la part de l’agent expérimentant, actions qui ontdes conséquences sur son environnement. D’un point de vue de conception logicielle,ces connaissances étant exécutables, elles font partie des comportements de l’agent. Lesconnaissances justifiables logiquement sont placées dans la partie classique de la basede connaissances de l’agent et ne sont pas exécutées. Cependant cette différentiationdes connaissances sur le plan de l’exécution ne doit pas entrainer une différence dansla représentation et le stockage. En effet les connaissances empiriques peuvent faireintervenir des concepts définis dans les connaissances empiriques.

En nous basant sur la définition épistémologique de la connaissance et les réflexionsprécédentes, nous abordons la question de la mise en œuvre de ces connaissances sousl’angle de l’architecture des agents en partant du niveau de la définition de la connais-sance ou nous avons établi la distinction entre connaissance justifiables logiquementet connaissance empiriques. Au niveau de l’agent, nous devons disposer de capacitésde représentation pour chacun des types de connaissance. Dans le premier cas, un for-malisme logique doit être supporté, dans le second cas, aucun formalisme précis n’estprescrit.La figure 3.21 résume les différents éléments constituant les agents.

Pour résumer, nous avons identifié deux types de connaissances, les connaissancesjustifiables au sens de la logiqe et les connaissances empiriques qui nécessitent uneexpérience pour leur validation. Pour être utilisable par des agents, nous spécifions ainsiles quatre composants suivants nécessaires aux agents :

– Une base de connaissances supportant un formalisme logique– Un raisonneur pour la vérification des connaissances justifiables– Une base de connaissances pour les connaissances empiriques– Une moteur d’éxécution pour la vérification des connaissances empiriquesLa section suivante présente les étapes de simplification et d’unification des compo-

sants.

3.4.3 Un modèle unifié des connaissances et des comportements

Notre approche nous permet de considerér un agent comme étant composé deconnaissances justifiables et empiriques. Il est souhaitable de disposer d’un modèleunique pour ces connaissances, ou à défaut, d’un modèle de représentation cohérentet compatible entre des deux types de connaissances. Par ailleurs, les connaissancesempiriques étant validées par l’expérience, elles consistent en une série d’actions que

22. Dans les architectures BDI, connaissance et comportement sont liés, ce qui n’est pas le cas ici


Connaissances

démontrables

Connaissance: Opinion droite et

justifiée

Connaissances

empiriques

Formalisme logique

pour la représentation

des connaissances

Connaissance exécutable par l’agent

Méthode d’évaluation

Connaissance

Représentation

niveau agent

Moteur logiqueBase de connaissance

supportant un

formalisme logique

Composants

de l’agent

Moteur d’exécution

et de vérification des

actions

Base de connaissance

pour les connaissance

empiriques

FIGURE 3.21 – Composants nécessaires aux agents pour la mise en œuvre des connais-sances

l’agent peut exécuter. Il s’agit donc d’un comportement de l’agent. Ceci nous conduitdonc à la recherche d’une modélisation unifiée de connaissance et de comportements.

Notre proposition est alors de représenter toutes les connaissances selon le mêmeformalisme, que ces connaissances soient justifiables de manière logique ou alors em-piriques. La représentation des connaissances empiriques n’impose pas à priori deformalisme très restrictif, comparé aux connaissances justifiables qui nécessitent unereprésentation basée sur la logique et l’utilisation d’un raisonneur sémantique. Il se posealors la question de comment le formalisme basé sur la logique peut-il aussi être utilisépour représenter les comportements de l’agent ?

En partant du souhait de transposer une définition épistémologique de la connais-sance dans les systèmes de gestion distribuées des connaissances, nous avons spécifiéles composants nécessaires à la réalisation de ces agents. Puis en étudiant les architec-tures existantes, nous avons identifié une analogie entre les besoins de représentationdes connaissances vérifiables par l’expérience et les comportements des agents. L’in-novation de notre proposition de modèle d’agents sémantique se situe au niveau de lareprésentation sémantique des comportements d’agents en tant que connaissance. Noussouhaitons que toutes les connaissances des agents soient représentées dans le même


formalisme et utilise un raisonneur commun. La section sur les agents et composants(section3.4.1) a montré que les comportements peuvent être réalisés en utilisant leslangages OWL et SWRL, le langage OWL étant utilisé pour la base de connaissancesclassique (connaissances justifiables).

Nous pouvons donc utiliser un seul raisonneur pour les deux types de connais-sance. Pour les connaissances justifiables, le raisonneur est utilisé de manière classique,pour inférer de nouvelles connaissances, mais aussi pour justifier l’ajout de nouvellesconnaissances. Lorsqu’un agent souhaite intégrer des connaissances reçues, il vérifierala consistance avec celles qui possède déjà et les intégrera le cas échéant. Dans le casde non consistance, l’agent utilise les fonctions d’explication du raisonneur pour déter-miner la cause de non consistance. L’agent peut ensuite engager un dialogue avec soninterlocuteur pour argumenter de la validité ou non des connaissances. L’argumentationdans les systèmes multi-agents est un vaste domaine de recherche qui est en dehors dupropos de nos travaux qui sont focalisés sur l’agent seul 23. Concernant les connaissancesempiriques, le processus de justification nécessite l’exécution du comportement (enchai-nement des règles de l’EFSM) correspondant à la connaissance, puis de la vérificationd’une propriété à l’issue de cette éxécution. La figure 3.22 résume le rôle du raisonneurlogique en fonction de chacun des types de connaissances. La réalisation concrète del’architecture puis de l’impleméntation va suivre cette volonté de représentation descomportements et des connaissances dans le même formalisme.

Découverte de

connaissances

Expliquer par

Justification déductive

Maintenir la

consistance

Connaissances justifiablesExplication

Déduction

Base de

connaissancesRaisonneur

consistance

Exécution de

comportements

Comportements

Enchaînement de règles

Vérification de consistance

Connaissances

expérimentables

Moteur logique

Vérification

des propriétés

FIGURE 3.22 – Rôles du raisonneur selon les types de connaissances

23. le lecteur intéressé pourra se reporter à la série des ateliers ArgMas : http://www.mit.edu/~irahwan/argmas/

http://www.mit.edu/~irahwan/argmas/

http://www.mit.edu/~irahwan/argmas/


3.5 Conclusion

Nous avons présenté les trois domaines à l’intersection desquels se trouve domainede recherche : la gestion des connaissances, le web sémantique et les systèmes multi-agents. Notre analyse s’est axé sur les problématiques définies à la fin du chapitre un :l’intégration de tous les éléments de la base de connaissances des agents afin de les rendreéchangeables, étudier l’implication de l’échange des nouveaux types de connaissance etla formalisation des communautés virtuelles de connaissance.

Nous avons abordé différents points dans le domaine des connaissances et et de lagestion des connaissances, tout d’abord les définitions de la connaissance en épistémo-logie et dans le domaine de la gestion des connaissances. Puis nous avons présenté lesapproches centralisées et décentralisées de gestion des connaissances. La définition de laconnaissance qui est utilisée dans l’approche appliqué de la gestion de connaissancesrepose sur des considérations informatiques et non épistémologiques. La définition de laconnaissance qui se fait par opposition aux données et aux informations, se base sur unesuccession de traitement informatique. Prenons l’exemple d’un capteur de températuredans une pièce : les données sont acquises d’un capteur et représentent une suite debits, sans signification. Ces données sont ensuite traitées pour en calculer la températuremesurée par le capteur, ce qui constitue alors l’information. Si l’on extrait d’un relevé detempérature fournie par le capteur un modèle qui décrit l’évolution de la températuredans cette pièce, on a alors extrait une connaissance à partir des informations. Ces défi-nitions, par niveau d’abstraction, sont en fait les étapes successives d’un traitement desdonnées suivant un chemin d’abstraction. Mais le but d’un système de gestion connais-sances est, comme de nombreux systèmes informatique, de délester l’utilisateur humainde tâches automatisable par la machine. C’est donc une définition de la connaissancequi est aussi pour l’utilisateur qui doit prévaloir, plutôt qu’une approche technique. Ceraisonnement ne s’applique pas seulement pas à la définition de la connaissance entant que "tout ce qui n’est pas information ou données", mais à toute définition de laconnaissance qui est imposée par la structure de la machine qui est amenée à traiter lesconnaissances. La définition épistémologique ("La connaissance est une opinion droitepourvue de raison) de la théorie de la justification nous semble être plus proche du fonc-tionnement "humain", c’est donc cette définition qui selon nous, doit être au centre dessystèmes de gestion des connaissances. Les travaux de Bonifacio ont mis en évidence lanotion d’autonomie de la connaissance et ont ouvert la voie à la gestion décentralisée desconnaissances. Cependant l’autonomie de la représentation des connaissances se limiteau domaine de la communauté. Cette autonomie de représentation doit être étenduecomplètement jusqu’aux entités qui composent les communautés.

A l’étude des technologies du Web Sémantique, nous avons constaté que l’ensembledes technologies n’est pas encore arrivé à maturité, notamment à cause des problèmesinduits par l’utilisation de ces logiques de description. La non-monotonie de ces logiques


ainsi que l’hypothèse de monde ouvert ont considérablement freiné le développement deces technologies qui jusqu’à l’OWL était extrêmement simple. Le fait qu’aucun langagede règles n’ait encore été choisi comme standard par le W3C (même si on peut pariersur le SWRL) montre que la technologie n’est pas encore matûre pour une utilisationindustrielle ou grand public. Cependant l’état actuel des travaux est très encourageant,et si les promesses initiales du Web Sémantique ne seront jamais tenues, il aura permisl’accélération du développement de formats et de technologies pour la représentationdes connaissances. On peut penser que tout comme le langage KQML [Finin94] qui aété utilisé à d’autres fins que celles pour lesquelles il a été conçu, les technologies etstandards du Web Sémantique trouveront (et trouvent déjà) un champ d’applicationdans toutes les applications touchant à la gestion de connaissances. Le fonctionnementdes systèmes inférentiels comme ceux du web sémantique fait à notre sens, parfaitementécho à la théorie de la justification que nous avons présentée au chapitre précédent. Eneffet dans un tel système logique, il est possible de justifier par l’utilisation de raisonneurde la validité d’une proposition au regard d’un système d’axiomes et de règles dedérivation. Les raisonneurs permettent aussi de vérifier la consistance d’un système etd’exhiber les points de discorde en cas de non consistance. Le langage OWL, basé surles logiques de description et par conséquent sur l’hypothèse d’un monde ouvert nousparait parfaitement adapté à nos besoins de représentation et d’inférence dans le cadrede nos recherches.

Dans l’étude des agents et des systèmes multi-agents, nous avons focalisé notre étudesur deux classes de critères, la représentation des connaissances et les comportementsdes agents. La problématique de représentation des connaissances au sein des agentssuit le développement des technologies du web sémantique qui ont permi, grâce toutd’abord à RDF puis à OWL d’améliorer les capacités de représentation des agents. Lesmoteurs d’inférence logique liées à ces technologies permettent aux agents la découvertede nouvelles connaissances à partir de celles déjà existantes. Cependant ces capacités nesont pas pleinement utilisées, notamment OWL, comme on peut le voir dans SEAGENTou AgentOWL, puisque la capacité de représentation n’est pas utilisée avec la logique dedescription qui est à la base de ce langage. On a donc une sous-utilisation des capacitésde représentation et d’inférence. Toujours d’un point de vue logique, l’hypothèse demonde fermé est très largement utilisée et comme nous l’avons vu en section 3.2 ellen’est pas cohérente avec la représentation que nous nous faisons du monde. L’approchelogique au niveau des connaissances, en tant que système inférentiel est présente dansles trois domaines que nous avons étudiés. Ce n’est pas une surprise car les outilsdisponibles (Prolog ou logique de description) s’intègre sans difficulté technique danstout type d’architecture. Il est plus étonnant de noter que les technologies plus récentes(bien que OWL soit une recommandation W3C depuis Février 2004) sont en premier lieuintégrées dans les approches génériques (langages de programmation et plates-formes),les applications dédiées utilisant des technologies plus anciennes.


Les comportements des agents sont souvent disjoints de leur base de connaissance,un langage comme Jazzyk y met par exemple un point d’honneur. Les applications dé-diées fonctionnent à l’aide de langage objet, majoritairement le JAVA, ce qui exclut toutesémantique dans les comportements d’agents. Pour pallier ce manque, les approchesde S-APL ou SEAGENT proposent une description sémantique de ces comportements,pour la découverte et la composition de comportements en utilisant des mécanismesinspirés des Web Services. Dans les trois domaines étudiés, les langages de program-mation du comportement et ceux de la représentation de connaissance sont différentsdans la très grande majorité des cas, sauf pour les architectures BDI. Dans le cas précisdes architectures, le lien entre base de connaissances et comportement est réalisé auniveau des croyances (B de BDI). L’implémentation de cette architecture se base surl’utilisation de raisonneur de type Prolog, ce qui restreint par conséquent la logiqueutilisée pour la base de connaissances à la logique du premier ordre. Les logiques dedescription utilisée dans OWL sont dotées d’une expressivité plus grande mais ellesn’ont pas été implémentées dans les architectures BDI. Les différentes tentatives (JASDL,Argonaut) n’ont pas pu fournir d’implémentation. L’unification du comportement et dela base de connaissances autour d’OWL reste donc un problème ouvert. La question dela reflexivité dans les architectures est souvent ignorée dans le cadre des langages agentsalors que c’est à ce niveau qu’on pourrait s’attendre à la voir apparaître. Seuls S-APL etune extension de Jason ([Ancona04b], non implémentée) proposent cette fonctionnalité,mais aucun de manière satisfaisante. La dualité langage de raisonnement et langaged’implémentation des fonctions est le facteur limitant à l’échange des comportementsentre agents dans les deux cas. l’utilisation des technologies du web sémantique est unstandard incontestable dans le monde agent pour la représentation des connaissances.Cependant l’utilisation des capacités de raisonnement n’est pas encore utilisée dans laréalisation des comportements des agents.

L’analyse qui a suivi a montré que l’utilisation des langages du web sémantiquepermettait la mise en place des deux types de connaissances (justifiables et empiriques)au sein d’une architecture d’agents. Tout d’abord nous avons établi le rapprochemententre le caracètre exécutable des connaissances empiriques (qui produisent une action)et les comportements des agents. L’architecture BDI qui établit un lien direct entreprocessus de décision, comportement et connaissance semblait toute indiquée pourremplir cette tâche. Cependant les tentatives infructueuses d’implémentation d’une tellearchitecture ont orienté notre choix sur une architecture basée autour des machinesétendues à état finis (EFSM).

Nous avons ensuite montré que les langages OWL et SWRL permettaient la réa-lisation d’une base de connaissances homogène permettant de décrire à la fois lesconnaissances justifiables et empiriques. L’utilisation d’un raisonneur unique pour l’in-férence des connaissances, la justification des deux types de connaissance ainsi que


l’exécution des comportements est alors possible. Nous présentons dans le chapitresuivant, une architecture réalisant cette unification.

3.5.1 Conclusion de l’analyse

Dans cette analyse, nous avons établi montré que l’utilisation des langages du websémantique permettait la mise en place des deux types de connaissances (justifiables etempiriques) au sein d’une architecture d’agents. Tout d’abord nous avons établi le rap-prochement entre le caracètre exécutable des connaissances empiriques (qui produisentune action) et les comportements des agents. L’architecture BDI qui établit un lien directentre processus de décision, comportement et connaissance semblait toute indiquéepour remplir cette tâche. Cependant les tentatives infructueuses d’implémentation d’unetelle architecture ont orienté notre choix sur une architecture basée autour des machinesétendues à état finis (EFSM).

Nous avons ensuite montré que les langages OWL et SWRL permettaient la réa-lisation d’une base de connaissances homogène permettant de décrire à la fois lesconnaissances justifiables et empiriques. L’utilisation d’un raisonneur unique pour l’in-férence des connaissances, la justification des deux types de connaissance ainsi quel’exécution des comportements est alors possible.

L’homme est infiniment grand par rapport à l’infiniment petit et infiniment petitpar rapport à l’infiniment grand ; ce qui le réduit presque à zéro.

Vladimir Jankélévitch

4Un modèle d’agents sémantiques

136 Chapitre 4. Un modèle d’agents sémantiques

Plan du chapitre

4.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1374.1.1 Base de connaissances et Comportements . . . . . . . . . . . . 1384.1.2 Interpréteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1394.1.3 Actions de bas niveau et plate-forme . . . . . . . . . . . . . . . 139

4.2 Programmation des agents . . . . . . . . . . . . . . . . . . . . . . . . . 1404.2.1 Syntaxe du langage . . . . . . . . . . . . . . . . . . . . . . . . . 1414.2.2 actions SWRL standards . . . . . . . . . . . . . . . . . . . . . . 1414.2.3 Actions spécifiques aux agents . . . . . . . . . . . . . . . . . . 1434.2.4 Définition de nouvelles actions . . . . . . . . . . . . . . . . . . 145

4.3 Structure de contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1454.3.1 Modèle sémantique des agents . . . . . . . . . . . . . . . . . . 146

4.4 Représentation des connaissances empiriques . . . . . . . . . . . . . . 148

4.5 Exécution d’un scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Section 4.1. Architecture 137

L’ANALYSE de l’état de l’art précédent a abouti sur une architecture d’agent séman-tique utilisant les machines étendues à états finis pour représenter les compor-

tements sous formes de règles SWRL. Cependant SWRL ne contient pas toutes lesfonctionnalités nécessaires à la programmation d’un agent. SWRL est un langage derègles sémantique, qui est dépourvu de toutes actions de bas niveaux (accés aux fichiers,communication réseau, . . .). Pour pallier ce manque, nous choisissons une architectureen couhes qui permet l’utilisation d’un langage de plus bas niveau pour compléter lesfonctions manquantes à la réalisation de l’agent. Nous présentons cette architecture dansla section suivante.

La programmation des EFSM requiert la définition de règles spécifiques SWRL et dela mise en place d’un interpréteur qui exécutera les règles et les actions présentes dans leconséquent. La grammaire du langage ainsi que la structure de contôle de l’interpréteurfont l’objet des sections 4.2 et 4.3. Les spécifications issues de l’interpréteur permettentde définir le modèle sémantique des agents (section 4.3.1) qui permet la réflexivité, lesagents ayant connaissance de leur propre structure. Puis nous présentons l’extension dumodèle pour le support des connaissances empiriques.

Enfin nous présentons l’exécution d’un scénario pour illustrer le fonctionnement pasà pas de l’interpréteur et les intéractions entre les différentes couches de l’interpréteur.

4.1 Architecture

La construction d’une architecture en couches est un choix dû au fait que le langagede règles ne contienne pas toutes les fonctionnalités nécessaires à la programmation d’unagent. SWRL est un langage de règles sémantique, qui est dépourvu de toutes actionsde bas niveaux (accés aux fichiers, communication réseau, . . .). Pour pallier ce manque,nous choisissons une architecture en ccouhes qui permet l’utilisation d’un langage deplus bas niveau pour compléter les fonctions manquantes à la réalisation de l’agent.Cette approche, dans le cas du choix de SWRL comme langage de règles, se justifiepar la difficulté d’extension d’un interpréteur SWRL. De plus, pour la communicationinter-agents, il est souhaitable par souci d’intéropérabilité de respecter les standardFIPA-ACL. De nombreuses implémentations de ces standards existent, notamment enJAVA.

L’architecture des agents (Fig. 4.1) est composée des trois couches suivantes :

1. Base de connaissances et de Comportements

2. Interpréteur

3. Actions de bas niveau et Plate-Forme


Base de connaissances et de comportements

Interpréteur

Teste les transitionsSéquences d’actions Messages reçus

(sémantisés)

OWL - SWRL

JAVA

Pellet

JenaInterpréteur

Actions de bas niveau

Intéraction avec la plate-forme

Messages reçusDémarre les actions

Jena

JAVA

JADE

FIGURE 4.1 – Architecture des agents

4.1.1 Base de connaissances et Comportements

Cette couche, dite sémantique, est la plus haute couche de l’architecture. Elle contientl’ensemble des connaissances de l’agent, justifiables et empiriques. Ces connaissancessont composées de concepts OWL (classes, instances, propriétés et opérations) et derègles SWRL pour les connaissances justifiables. Les connaissances empiriques sontdécrits à l’aide des mêmes termes OWL et SWRL, dans une ontologie que nous définironsà la partie 4.3.1.

Les comportements de l’agent sont écrits à l’aide de règles SWRL, nous expliciteronsensuite l’écriture des comportements. Notons dès à présent qu’un avantage significatifde notre approche est l’usage de SWRL, dont la syntaxe étend celle de OWL. En effetles termes de la base de connaissances de l’agent sont directement manipulés dansles règles décrivant les comportements (cf Section 3.2.4.4), aucune transformation desconnaissances pour les manipuler à l’aide de règles n’est requise.

Section 4.1. Architecture 139

4.1.2 Interpréteur

L’intérpréteur constitue la structure de contrôle ainsi que l’interface entre les couchesde haut et bas niveaux. L’interpréteur comprend un le raisonneur tel que décrit dans lafigure 3.22 qui intéragit avec la couche sémantique pour les différentes actions( déclen-chement des règles décrivant le comportement de l’agent, vérification de consistance,explication, . . .). Si des actions de bas niveaux doivent être exécutées, l’interpréteur gèreles appels à la couche inférieure. Nous détaillons le fonctionnement de l’interpréteurdans la section 4.3.

4.1.3 Actions de bas niveau et plate-forme

Les actions exécutables par l’agent se séparent en plusieurs catégories. On distingued’une part les actions du langage de règles SWRL qui sont exécutées par le raisonneuret d’autre part celles les actions de bas niveau. Ces actions de bas-niveau, comme nousl’avons indiqué précédemment sont les actions requises au fonctionnement d’un agentet qui ne sont pas disponibles parmi les prédicats de SWRL. Au sein de ces actions debas niveau, on distingue deux catégories d’actions selon leur portée : les actions interneset les actions externes. Les actions internes concernent les actions dont l’effet porte surl’agent lui-même alors que les actions externes concernent les intéractions de l’agentavec son environnement. Une action interne modifie l’état de l’agent alors qu’une actioninterne intéragit avec l’environnement et ne modifie pas l’état interne de l’agent.

Actions internes

La base de connaissances des agents est exprimée en OWL, c’est à dire en utilisantles concepts suivants : classes, propriétés et individus. A chacun de ces concepts, sontassociées trois opérations : création,modification et suppression. Seulement la premièrede ces opération est supportée SWRL. Comme seule la création est possible en SWRL, laliste suivante montre les opérations qui doivent être effectuées par la couche basse del’architecture :

– modification/suppression de propriétés– modification/suppression del’appartenance à une classe– modification/suppression d’individus

Actions externes

Ce sont les actions exécutées par les agents pour intéragir avec son environnement.Nous considérons que les agents évoluent dans un environnement électronique. Ce quirestreint donc les actions possibles à l’échange de messages entre agents. Il y a doncdeux actions basiques, l’envoi et la réception de messages. Les actions relatives à lacommunication se basent sur une plate-forme d’agents. Les messages sont structurésselon la spécification FIPA-ACL (nous proposons une implémentation basée sur JADE


dans le chapitre 6). Lors de la réception d’un message, celui-ci est stocké dans la filedes messages reçus dans la base de connaissance. Les agents sont compatibles avec laspécification FIPA ACL 1. En plus des éléments standards, tels que émetteur, destinataireet contenu, la spécification FIPA-ACL impose de nombreux paramètres tels que l’URIde l’ontologie utilisée et la performative. A l’aide de ces deux actions, il est possiblede construire des intéractions complexes (cf spécification FIPA). Les actions externespermettent aussi l’intéraction avec une plate-forme d’agents.

4.2 Programmation des agents

L’ordonnancement des règles n’étant pas possible en SWRL, il faut utiliser un autremoyen qu’un ensemble de règles pour décrire le comportement d’un agent. Les machinesà états finis étendues proposent une solution adaptée à la programmation d’agents àl’aide de règles.La structure des agents se basent sur le formalisme des machines ouautomates à états finis étendues déterministes (deterministic EFSM). Les séquencesd’action qui représentent un comportement seront décrites sous forme de machines àétats finis étendues.

Dans le cadre des agents sémantiques, on établit les correspondances suivantes,les symboles d’entrées sont les symboles reçus par l’agent, ceux de sortie sont ceuxenvoyés par l’agent. Les fonctions d’activation sont les conditions portant sur l’étatinterne de l’agent, c’est-à-dire sa base de connaissances. Les actions de mise à jour, sontun ensemble d’actions qui sera exécuté par l’agent à l’issue de la transition. L’espace Dest ici l’espace des propositions représentables dans la base de connaissances, c’est à direl’union des ontologies OWL et des règles SWRL.

On peut représenter une machine à états finis étendues sous forme d’un ensemblede règles du type suivant :

condition, etat→ etat, miseajour (4.1)

Avec condition qui regroupe les fonctions d’activation et les messages recus, et mise àjour qui regroupe les messages expédiés ainsi que les modifications apportées à la basede connaissances de l’agent.

Il est important de noter que la notion d’état dans notre cas est purement artificielle.Elle sert à permettre l’ordonnancement des règles et ne doit pas être comprise commeun état mental de l’agent.

1. http://www.fipa.org/repository/aclspecs.html

http://www.fipa.org/repository/aclspecs.html

Section 4.2. Programmation des agents 141

4.2.1 Syntaxe du langage

La syntaxe des règles acceptées par l’interpréteur est basée sur celle de SWRL.L’ensemble des règles constitue un sous-ensemble des règles SWRL définies dans[Horrocks04] :

SAM ⊂ SWRL

La syntaxe des règles est donnée en notation EBNF (Extended Backus Normal Form)dans la figure 4.2. Les règles contiennent deux éléments principaux, l’antécédent (SA-Mantecedent) et le conséquent (SAMconsequent). L’antécédent contient les conditions dedéclenchement de la règle. Ces conditions portent sur l’état courant de l’agent ainsique sur des concepts de sa base de connaissance. Ces dernières conditions sont faculta-tives (atom*). Une transition peut s’exécuter sans poser de conditions explicites sur lesconnaissances de l’agent. Ce type de transition est dénotée transition libre.

Le conséquent des règles spécifie la séquence d’actions de bas niveaux qui doiventêtre exécutées, les opérations effectuées par des primitives SWRL (par exemple l’asser-tion) ainsi que l’état d’arrivée de la transition. Cette liste spécifiée par a-list est liée auconséquent par aActions. Les éléments non-terminaux de la grammaire sont définis dansl’ontologie du modèle d’agent. Ces éléments sont les suivants :

– EtatCourant : classe qui définit l’état courant de l’agent. Présent dans l’antécédentde la règle, il constitue une condition d’activation.

– EtatSuivant : classe qui définit l’état suivant de l’agent. Présent dans le conséquentde la règle, il indique à l’interpréteur la variable qui définit l’état suivant.

– ValeurEtat : relation qui associe un état à une valeur.– finListe : élément de fin de liste pour les actions.– aNomParametre : associe un paramètre à un nom.– aValeurParametre : associe un paramètre nommé à une valeur.Les paramètres des différentes actions sont définies par aNomParametre et aValeurPa-

rametre.

4.2.2 actions SWRL standards

Les actions existantes en SWRL (SWRL built-ins en anglais) se répartissent en septcatégories [Horrocks04] :

1. Comparaison

2. Mathématiques

3. Booléens, valeurs

4. Chaînes de caractères

5. Date, temps et durée

6. URI


SAMrule ::= ’Implies(’ URIreference{ annotation }SAMantecedent SAMconsequent ’)’

SAMantecedent::= EtatCourant(’i-variable’)’ValeurEtat’(’i-variable’ ’i-variable’)’ atom*

SAMconsequent::= EtatSuivant’(’i-variable’)’aActions’(a-list’)’ atom*ValeurEtat’(’i-variable’ ’i-variable’)’

a-list ::= aContenu(action) aSuivant(a-list)| finListe

action ::= URIreferenceaNomParametre(a-name)

a-name ::= aValeurParametre(i-object i-object)

atom ::= description ’(’ i-object ’)’| dataRange ’(’ d-object ’)’| individualvaluedPropertyID’(’ i-object i-object ’)’| datavaluedPropertyID’(’ i-object d-object ’)’| sameAs ’(’ i-object i-object ’)’| differentFrom’(’ i-object i-object ’)’| builtIn’(’ builtinID { d-object } ’)’

builtinID ::= URIreference

endlist ::= URIreference

i-object ::= i-variable | individualID

d-object ::= d-variable | dataLiteral

i-variable ::= ’I-variable(’ URIreference ’)’

d-variable ::= ’D-variable(’ URIreference ’)’

FIGURE 4.2 – EBNF du langage interprété. Ce langage est un sous ensemble de SWRL

Section 4.2. Programmation des agents 143

7. Listes (type listes RDF)

Il est important de noter que les listes ne sont disponibles que avec OWL-Full, qui estnon décidable. Nous avons précédemment choisi la décidabilité (OWL-DL et SWRL-DL),par conséquent il faut retirer les listes des actions SWRL disponibles. Notre approcherequiert l’utilisation de liste, pour représenter les connaissances empiriques ainsi que lescomportements, nous utilisons donc une ontologie tierce OWLList [Drummond06] quipermet de définir des séquences en OWL-DL.

4.2.3 Actions spécifiques aux agents

Les actions spécifiques sont celles qui sont requises pour la réalisation d’agents et quin’existent pas en SWRL. Nous avons déjà énoncé deux catégories, les actions internesdont le résultat est une modification de l’état interne de l’agent et les actions externesdont le résultat influe sur l’environnement extérieur des agents. Dans le cadre d’échangesde connaissance dans lequel nous nous sommes placé, ces actions se restreignent à deséchanges de messages avec les entités du système.

Actions internes :

Les connaissances justfiables sont représentées à l’aide des concepts OWL (classes,propriétés, individus. . .). Pour chacun de ces concepts on doit disposer des trois opérationélémentaires, à savoir : création,modification,suppression. A l’issue de l’éxécution d’unerègle SWRL, seule la création (par assertion) est possible. L’hypothèse de monde ouvertentraîne le non support des négations comme but ou négation par l’échec. En pratiqueil est donc possible de faire l’assertion de propriétés sur des individus ou des classesdans le conséquent d’une règle. L’exemple suivant issue du document SWRL montrel’assertion possible de la propriété oncle par la composition des propriétés parent et frère :

parent(?x, ?y) ∧ f rre(?y, ?z)⇒ oncle(?x, ?z)

Mais les règles suivantes sont impossibles. La première présente un cas de négationl’échec et la suivante un cas d’inférence non-monotonie. Il est par conséquent impossiblede supprimer une information dans le conséquent de la règle. Cependant cette opérationpeut-être d’une grande utilité dans le cas qui nous concerne.

¬Personne(?x)⇒ NonHuman(?x)

parent(?x, ?y) ∧ f rre(?y, ?z)⇒ ¬tante(?x, ?z)

On peut contourner la restriction pour cette dernière règle en spécifiant que les domainesde oncle et tante sont disjoints.


Les actions internes déléguées à la couche inférieure de l’architecture sont les sui-vantes :

– Ajout,modification,supression de propriétés– Modification, suppression de l’appartenance à une classe– Ajout,modification,supression d’invidivus– Ajouter, modifier, supprimer les domaines de définition d’une propriété.

Actions externes :

Comme nous l’avons énoncé prédécemment, les actions externes sont restreintes auxéchanges avec les entités du système.Les communications inter-agents ont été normalisésdans la norme FIPA-ACL (voir annexe B), les agents se basent sur la norme ACL pour lastructure des messages.

Les messages reçus sont stockés dans une liste de type OWLList. Les actions ex-ternes sont les suivantes : envoiMessage et messagerecu. La première action prend enparamètre tout les champs d’un message standard FIPA-ACL, on peut citer entre autresémetteur,destinataire,ontologie, performative. La seconde action permet d’accéder auxmessages reçus qui sont stockés dans la liste.

A partir de ces simples intéractions, toujours en suivant les spécifications de laFIPA il est possible de construire des échanges de nature complexe tels que propos-tion,abonnement,contrat. Les différents champs du message sont représentés dans labase de données OWL en utilisant les propriétés hasPerformative, hasContent, hasSender .

Actions Internes Actions Externes

Fonctions

SWRL

� Assertions

�Comparaisons

� Mathématiques

� Chaînes de caractères

� Booléens

� Date, temps et durée

� URI

X

Fonctions

de bas

niveaux

� URI

�Création

� Classes

� Individus

� Relations

� Modification : idem

� Suppression : idem

�Envoi de messages

�Réception de messages

�Interactions avec la plate-forme

FIGURE 4.3 – Actions selon les couches de l’architecture

Section 4.3. Structure de contrôle 145

4.2.4 Définition de nouvelles actions

Le modèle présenté dans la section précédente spécifie une liste d’actions de basepour la gestion de connaissance et l’échange de messages. La définition de nouvellesactions se fait par composition d’actions atomiques. Une seconde méthode qui auraitété d’étendre l’ensemble des actions de bas niveaux pose un problème d’interopérabi-lité entre les agents qui ne partageraient pas tous les mêmes actions. L’approche parcomposition est donc celle qui est retenue.

Ces nouvelles actions sont une composition d’actions de bas niveaux et de primitivesSWRL. Ces actions, sont de type composées (voir Fig 4.6). Pour définir ces nouvellesactions, nous utilisons le même principe que pour réprésenter le comportement d’unagent. Les actions composées sont un ensemble de règles constituant une machine àétats finis étendue.

4.3 Structure de contrôle

InterpréteurClock

Base de connaissances

et

Comportement

Moteur de

règlesNoms et paramètres

des actions

Règles et états

Messages reçus

InterpréteurClock

Actions interne

Messages reçus

Messages sortants

Actions

externes

Paramètres

Des messages

Paramètres

Des actions

FIGURE 4.4 – Interpréteur des agents, inspiré de [Shoham91]


L’interpréteur que nous proposons repose sur le principe des EFSM que nous avonsprésenté précédemment. Les transitions entre les états sont décrites par des règles SWRL.Dans ces règles on peut effectuer des actions existantes dans SWRL (primitives SWRL).Les actions qui ne sont pas incluses dans les primitives SWRL seront exécutées par lescouches basses de l’architecture. Le cycle de l’interpréteur est décrit dans l’algorithme 1.

Algorithm 1: Cycle de l’interpréteur

début1

etatCourant←− sDebut;2

tant que etatCourant 6= sFin faire3

temp←− valeurEtatSuivant();4

si temp 6= etatCourant alors5

enlevePropriete(etatCourant, aValeur);6

listeActions←− getlisteActions();7

si executeAction(listeActions) alors8

ajoutePropriete(etatCourant, temp) ;sinon ajoutePropriete(etatCourant, erreur)9

fin10

Les états entre les transitions sont explicites. L’interpréteur est initialisé à l’étatsDebut qui est l’état de départ pour chaque comportement. sFin étant l’état final. Lecycle se termine quand etatCourant = sFin (ligne 3). Si une transition est active, alors lavaleur de l’état suivant sera différente de celle de l’état actuel. L’interpréteur fait appelau moteur de règles (cf figure 4.4) à la ligne 5, pour obtenir la valeur de la variableetatSuivant. L’état courant est alors réinitialisé, et l’interpréteur récupère ensuite la listedes actions de bas niveau à exécuter. Si ces dernières sont exécutées avec succès, alorsl’état suivant est activée et le cycle continue. En cas d’erreur lors de l’exécution de cesactions, l’interpréteur place dans l’agent dans un état d’erreur.

4.3.1 Modèle sémantique des agents

. Ces règles portent sur des concepts fixés par l’architecture spécifiée dans la partie4.1 et dont la syntaxe a été donné dans la partie précédente. Les concepts OWL ainsidéfinis, représentent le modèle sémantique des agents. Ces agents possèdent donc unereprésentation de leur propre architecture dans leur base de connaissance. Construit àpartir des spécifications données dans les parties 4.1 et 4.3, le modèle OWL résultant estprésenté dans la figure 4.5.

Les différents états possibles de l’agent sont des instances de la classe State. Il existedeux états spéciaux sDebut et sFin, le premier étant l’état initial, le second, l’état final.

Section 4.3. Structure de contrôle 147

Chaque comportement d’agent doit débuter par sDebut et terminer par sFin, la relationentre comportement et état du schéma 4.6, montre la nécessité de ces deux états parti-culiers pour chaque comportement. La liste des actions à exécuter lors d’une transitionainsi que les messages reçus sont des instances de listes de type OWLList 2. Les actionsde bas niveaux sont des instances la classe Action

Agents

nom : StringAdresse : String

Agent Courant

<<interface>>I/O

1

1

Pile d'exécution Comportement0,1 1..*

possède

11

Etat

nom : String

Etat Courant Règle SAM

ListeActions

1

2..*

1

1..*

Actions

run() : void

nom : String

1

0..*

Action interne Action externe

Connaissance Empirique

1

0..*possède0,1

1

1

1

Propriété

valeur : String

1 1

Entrée Sortie

<<realize>> <<realize>>

FIGURE 4.5 – Ontologie résultante de l’architecture

La figure 4.6 décrit l’ontologie résultante de l’architecture que nous avons spécifiéeprécédemment.

2. http://www.co-ode.org/ontologies/lists/

http://www.co-ode.org/ontologies/lists/


Action

Composed ActionAtomic Action

ActionList

subClassOf subClassOf

isa

Internal Action External Action

subClassOf subClassOf

disjointWih

disjointWih

FIGURE 4.6 – Ontologies des agents : hiérarchie des actions

4.4 Représentation des connaissances empiriques

Les connaissances empiriques ont été définies comme étant une séquence d’actionsassociée à une propriété. A l’issue de l’exécution de cette séquence d’actions, la propriétédoit être vérifiée. Ces connaissances sont représentées de la manière suivante dans labase de connaissances :

– Une séquence d’actions du même type qu’un comportement (OWLList d’Actions)– La propriété qui doit être vraie à l’issue de l’éxécution

– Les paramètres et leur types (variables et classes).– Une requète– Des exemples de valeur de paramètres et des résultats attendus à l’issue de la

requète (optionnel)Lorsqu’un agent reçoit une connaissance empirique, il l’éxécute de la manière sui-

vante : tout d’abord il initialise les paramètres de l’éxécution. Puis il exécute la séried’actions de la même manière qu’un comportement, en exécutant les actions lors detransition entre les états. A la fin de cette exécution, la base de connaissances de l’agent aété modifiée, soit de manière interne, soit par la réception de messages issus d’échangesavec des agents. La requète sur la base de connaissances permet d’obtenir le résultat decette exécution, puis soit d’afficher le résultat à l’utilisateur qui confirmera ou invaliderale résultat. L’agent émetteur de la connaissance peut choisir de fournir des paramètres àtitre d’exemple pour justifier de sa bonne foi.

Section 4.5. Exécution d’un scénario 149

Exemple : fonction factorielle

Prenons le cas d’un agent nommé Alice disposant des connaissances de base, c’est àdire de son propre modèle et des actions standards définies précédemment. Il disposedes opérations mathématiques standards fournies par SWRL 3 : addition, multiplication,puissance, . . .. Un deuxième agent, Bob, sait quant à lui, en plus des connaissancesdont dispose Alice, calculer la factorielle d’un entier. Il utilise l’algorithme standard demultiplication successive.

La fonction mathématique swrlb :add est vraie si la somme du premier et dudeuxième argument est égale au troisième. Pour obtenir la somme de 3 et 5 dans lavariable n, on appelle la fonction somme ceci : swrlb :add(3,5,n).

L’algorithme en langage s’écrit alors de la manière suivante (on omet volontairementla variable intermédiaire dans les additions en précédant la destination par ? ) :

Paramètre : n, de type xsd : integer

Variables : i, j, k, de type xsd : integer, initialisées à 1.

Etats : sDebut, sFin et un état intermédiaire A.

Règles 1. etatcourant=Sdebut AND i < n⇒ etatsuivant=A AND swrlb :add(j,1, ?k)AND swrlb :mult(j,k, ?j) AND swrlb :add(i,1, ?i)

2. etatcourant=A AND i < n⇒ etatsuivant=sDebut

3. etatcourant=A AND i = n⇒ etatsuivant=sFin

Requète : Comparaison de la valeur de j avec celle de l’exemple.

Exemples : [(3,6),(5,120)]

4.5 Exécution d’un scénario

Pour illustrer le mécanisme de fonctionnement des agents, nous allons détailler pasà pas l’exécution d’un comportement simple. Prenons l’exemple suivant, l’agent Aliceveut envoyer une question à l’agent Bob. Alice s’enregistre auprès des pages jaunes dela plate-forme (nous proposons dans la section suivante une implémentation basée surJADE). Bob répond ensuite à Alice. Si le message que reçoit Alice est de Bob. S’il s’agit dela réponse à son message précédent, alors Alice ajoute la réponse de Bob dans sa base deconnaissances. L’EFSM correspondant au comportement d’Alice est illustré par la figure4.7. La colonne de gauche montre les actions de bas niveau exécutées lors des transition.Les conditions de déclenchement des transitions se trouvent dans la colonne de droite.La première transition est libre de condition, elle est exécutée lors du démarrage d’Alice.registerDF est alors exécuté, c’est à dire Alice s’enregistre auprès du système de pagesjaunes. Si l’action retourne vrai, alors l’instruction suivante, c’est à dire l’envoi d’un

3. http://www.daml.org/2004/04/swrl/builtins.html#8.2 accédé le 23/12/2009

http://www.daml.org/2004/04/swrl/builtins.html#8.2


sDebut

1. RegisterDF

2. EnvoiMessage

Paramètre Valeur

Performative Query

aRecu(?x)

^ aPerformative(x,Answer)

^ aEmetteur(x, Bob)

^ hasContent(x,?y)

AddIndividual

Paramètre Valeur

Individu ?y

A sFin

Contenu Select ?x

Destinataire «Bob»

FIGURE 4.7 – Exemple illustratif (a), Scénario

message à Bob, est exécutée. La règle qui décrit cette transition est la suivante :

EtatCourant(?x)

∧ValeurEtat(x, sDebut)∧ EtatSuivant(?y)

⇒ ValeurEtat(y, A)

∧ aContenu(SequenceActions, registerDF)∧ aSuivant(SequenceActions, item)

∧ aContenu(item, EnvoiMessage)∧ aNomDeParametre(EnvoiMessage, Destinataire)∧ aValeurDeParametre(Destinataire, Bob)

. . . idem avec les autres parametres∧ aSuivant(item, f inDeListe)

Pour vérifier si une nouvelle transition doit être exécutée, l’interpréteur (la coucheintermédiaire) interroge la base de connaissances de l’agent pour connaître la valeurde EtatSuivant. Si cette dernière est différente de la valeur de EtatCourant cela signifiequ’une transition doit être exécutée. L’interpréteur lit ensuite les valeurs des actionscontenues dans SequenceActions ainsi que leur paramètres respectifs. La séquence d’ac-tion correspondant à la première transition de la figure 4.7 est illustrée dans la figure 4.8.L’action EnvoiMessage possède trois paramètres dont les valeurs sont indiquées par lapropriété aValeurParametre.

La règle spécifiant la deuxième transition contient des conditions sur le messagereçu. Il faut en effet vérifier que le message a été envoyé par Bob et qu’il a été envoyé enréponse au message d’Alice. On vérifie donc les propriétés Emetteur et Performatives surle dernier message reçu.

EtatCourant(?x)

Section 4.5. Exécution d’un scénario 151

∧ValeurEtat(x, A)

∧ EtatSuivant(?y)∧ aRecu(?z)

∧ aPer f ormative(z, Answer)∧ aEmetteur(z, Bob)∧ aContenu(z, ?w)

⇒ ValeurEtat(y, sEnd)∧ aContenu(ActionSequence, AjoutInstance)∧ aSuivant(ActionSequence, f inDeListe)∧ aNomDeParametre(AjoutInstance, nom)

∧ aValeurDeParametre(nom, w)

Nous détaillons ensuite les échanges entre les différentes couches de l’architecture pourl’exécution de la première transition.

EnvoiMessage

PerformativeDestinataire Contenu

aNomParametreaNomParametre aNomParametre

Bob Question Select ?x from..

aValeurParametreaValeurParametreaValeurParametre

{RegisterDF,

EnvoiMessage}

RegisterDF

aSuivant aSuivant

aContenu aContenu

EnvoiMessage

{EnvoiMessage} {}

FIGURE 4.8 – Exemple illustratif (b), Structure de données de la séquence d’actions

4.5.0.1 Exécution d’une transition

L’exécution d’une transition fait intervenir les 3 couches de l’architecture. Leséchanges entre les couches lors de la première transition sont représentés dans la figure4.9. Tout d’abord l’interpréteur interroge la couche sémantique pour connaitre la va-leur de EtatSuivant. On a alors EtatSuivant = A. Comme A 6= sDebut, l’interpréteurrécupère ensuite la séquence des actions de bas niveau à exécuter. SequenceAction =

RegisterDF, EnvoiMessage. L’interpréteur fait alors appel à la fonction de bas niveauRegisterDF. Si celle-ci est exécutée avec succés, les paramètres de EnvoiMessage sont


ensuite récupérés et l’action est appellée avec ses paramètres. Si elle est exécutée avecsuccès, l’interpréteur modifie l’état de l’agent dans la couche sémantique pour queEtatCourant = A. La transition est alors terminée et le cycle d’exécution reprend par lacomparaison des valeurs de EtatSuivant et EtatCourant.

Base de

connaissance

Couche

intermédiaireV

ale

ur

de

Se

qu

en

ceA

ctio

ns?

A

{Re

gis

terD

F

En

vo

iMe

ssa

ge

}

Eta

tCo

ura

nt

= A

Va

leu

r d

e

Eta

tSu

iva

nt?

Exe

cute

Re

gis

er

DF

Exe

cute

En

vo

iMe

ssa

ge

Actions

atomiquesE

xecu

te

Re

gis

er

Exe

cute

En

vo

iMe

ssa

ge

FIGURE 4.9 – Exemple illustratif (c), Flux de la transition de l’état sDebut vers l’état A

4.6 Conclusion

Le modèle et l’architecture d’agent que nous avons présenté résulte de l’applicationd’une définition épistémologique de la connaissance. Les connaissances des deux typesont été représentés à l’aide du formalisme fourni par les standards OWL et SWRL. Lelangage de règles SWRL ne permettant la programmation d’agents, nous avons proposéune architecture en couches pour compléter avec les fonctions requises en terme decommunication et de gestion de la base de connaissances. Pour compléter les fonctionsrequises, nous avons spécifié un nombre fini d’actions qui est commun à tous les agents.L’utilisation d’un nombre fini d’action permet une interopérabilité complète entre lesagents sémantiques en évitant le problème de double définition des actions (au niveausémantique et opérationnel).

Notre approche a été de représenter les connaissances empiriques en nous basant surla représentation des comportements de l’agent, c’est-à-dire sous forme de connaissancesexécutables. L’architecture que nous avons spécifiée permet de représenter toutes lesconnaissances de l’agent au même niveau d’abstraction et de disposer de méthodesadaptées à la justification des connaissances au sein d’un système multi-agents dédié àla gestion des connaissances.


La problématique posée en début de chapitre, la mise en œuvre d’une définition épis-témologique de la connaissance basée sur la distinction entre connaissances empiriqueset connaissances justifiables a été réalisée au travers d’un modèle d’agent sémantique.Le modèle permet de prendre en compte les différents aspects de la connaissance et deles rendre échangeables entre les agents.

Si l’objectif fixé a été atteint, des bénéfices non attendus ont été obtenus lors dela réalisation. Tout d’abord, le fait de ne pas dépendre d’un langage de bas-niveauen particulier, tout agent implémentant le modèle et les actions de bas niveaux (enC++, JAVA ou autre langage), sera capable d’échanger ses connaissances et surtout sesconnaissances empiriques et comportements. Le deuxième avantage est l’unicité dela base de connaissances, qui en plus des connaissances classiques, contient aussi lescomportements de l’agent.

Un homme qui cherche la vérité se fait savant ; un homme qui veut laisser sasubjectivité s’épanouir devient peut-être écrivain. Mais que doit faire un hommequi cherche quelque chose situé entre les deux ?

Robert Musil - "L’homme sans qualité"

5Communautés Virtuelles de Connaissances à

base d’agents

156 Chapitre 5. Communautés Virtuelles de Connaissances à base d’agents

Plan du chapitre

5.1 Conception de l’ontologie . . . . . . . . . . . . . . . . . . . . . . . . . . 1575.1.1 Formalisation Ensembliste . . . . . . . . . . . . . . . . . . . . . 1575.1.2 Ontologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1635.1.3 Agents Sémantiques et ontologie des communautés virtuelles

de connaissances . . . . . . . . . . . . . . . . . . . . . . . . . . 167

5.2 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1685.2.1 Description du scénario . . . . . . . . . . . . . . . . . . . . . . 1695.2.2 Conclusion de l’exemple . . . . . . . . . . . . . . . . . . . . . . 172

5.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Section 5.1. Conception de l’ontologie 157

Pour formaliser les VKC, nous avons choisi de procéder tout d’abord par une for-malisation à l’aide de l’outil mathématique commun que représentent les ensembles etrelations. L’expressivité et la simplicité de ce cadre formel ont été déterminant dans notrechoix. De plus, il ne se restreint pas à l’utilisation d’une technologie, mais permet aucontraire de définir en amont les éléments qui seront implémentés dans une technologie.Notre formalisation se base sur notre expérience dans le domaine, sur les recherchesthéoriques de Calmet et Maret ainsi que sur les différentes implémentations que nousavons décrites dans le premier chapitre.

Pour compléter le lien entre cette formalisation et les agents, nous définissons uneontologie des commaunutés virtuelles de connaissances qui est intégrable dans la basede connaissances de ces agents. Pour ce faire, nous traduisons les ensembles par desclasses et les fonctions par des relations. Nous présentons ensuite différents exempled’utilisation de cette ontologie.

Dans la description formelle des communautés virtuelles de connaissances, nousintroduisons le concept de protocoles qui va permettre d’établir le lien avec les connais-sances échangeables par les agents sémantique. Nous représentons ces protocoles sousformes de règles interprétables par les agents SAM, afin de rendre opérationnelle l’utili-sation des communautés sous forme d’ontologie.

Nous présentons ensuite une application qui illustre les atouts de notre approche etpermet de montrer une mise en œuvre des différents concepts que nous avons définis.Le but de l’exemple est d’illustrer la transmission d’une connaissance empirique (l’utili-sation de communautés de connaissances, décrite par l’ontologie) puis son utilisationpour permettre à un agent d’acquérir des connaissances.

5.1 Conception de l’ontologie

Nous présentons dans les sections suivantes la définition de l’ontologie des com-munautés virtuelles de connaissance en commencant par la formalisation ensemblise,puis la réalisation de l’ontologie et finalement le lien avec le modèle d’agent sémantiquedéfini au chapitre précédent.

5.1.1 Formalisation Ensembliste

Pour formaliser les VKC, nous avons choisi de procéder tout d’abord par une for-malisation à l’aide de l’outil mathématique commun que représentent les ensembles etrelations. L’expressivité et la simplicité de ce cadre formel ont été déterminant dans notrechoix. De plus, il ne se restreint pas à l’utilisation d’une technologie, mais permet aucontraire de définir en amont les éléments qui seront implémentés dans une technologie.Notre formalisation se base sur notre expérience dans le domaine, sur les recherches


théoriques de Calmet et Maret ainsi que sur les différentes implémentations que nousavons décrites dans le premier chapitre.

Le premier ensemble que nous définissons est celui des agents qui composent lescommunautés (dénoté ensemble M). Ces agents peuvent être autonomes ou dirigéspar un utilisateur humain. Les communautés regroupent des agents autour d’un (ouplusieurs) élément(s) commun(s), que l’on nomme le thème. L’ensemble de ces élémentsest appellé S pour ensemble des sujets. Nous avons vu dans le premier chapitre que lesagents n’ont pas tous les mêmes fonctions au sein d’une communauté, par exemple leleader peut dissoudre une communauté alors qu’un membre ne peut que la quitter. Cesfonctions (leader,membre,. . .) sont liées à des actions possibles au sein de la communauté(dissoudre, rejoindre, envoyer un message). Nous noterons les fonctions ou rôles commeappartenant à l’ensemble R, l’ensemble A contient l’ensemble des actions possibles. Pourlier les agents aux rôles et les rôles aux actions, nous définisson les relations rr et rp.

L’ensemble le plus intéressant au sens de nos travaux est celui des protocoles (en-semble P). Nous entendons par protocoles les règles de communication qui régissent lesintéractions au sein d’une communauté. Notre but est de tirer partie de la possibilitéd’échange de connaissance exécutable entre les agents au sein de cette formalisation.Nous souhaitons en effet que les connaissances des communautés soient "opération-nelles" pour les agents. Ces protocoles appartenant à l’ensemble P décrivent l’implémen-tation des actions auxquelles nous les associons par la relation rp.

Nous proposons la formalisation suivante pour les VKC : unee communauté c appar-tenant à l’ensemble des communautés C est un tuple : c ∈ C = {M, R, A, P, S, rr, ra, rp}où M, R, A, P, S sont des ensembles et rr, ra, rp sont des relations entre ces ensembles.

Ensembles

– M est un ensemble d’agents, qui décrit les agents appartenant à la communauté.Une communauté possède au moins un agent, qui est le créateur de cette commu-nauté. |M| ≥ 1.

– R est un ensemble de rôles possibles au sein de la communauté.– A est un ensemble d’actions, qui sont les actions possibles dans la communauté.

Les actions classiques sont rejoindre,quitter, . . .. Pour que la notion de communautéait un sens, A doit être non vide. Auquel cas on aurait une commaunuté vidée detoute action possible, dans laquelle seule le créateur est membre.

– P est un ensemble de protocoles. Un protocole décrit les règles d’échanges entredeux agents au sein de la communauté. A chaque action on associe un protocolequi permet de réaliser cette action. A chaque communauté c est aussi associéun protocole, qui décrit le fonctionnement de la communauté, c’est-à-dire l’or-donnancement des actions. Par exemple, on commence d’abord par rejoindre lacommunauté, ensuite on échange des messages, puis on quitte la communauté. Lacardinalité de P est supérieure ou égale à un (conséquence de A non vide).


– S est un ensemble de sujets qui sont le centre d’intérêt de la communauté.

Relations

– rr ⊆ M× R est une relation entre l’ensemble des agents M et l’ensemble des rôlesR. Cette relation décrit les rôles associés à chaque agent au sein d’une communauté.A chaque agent on associe au moins un rôle. Cependant certains rôles peuvent êtreinoccupés au sein d’une communauté. De ce fait la relation rr est totale à gauche 1.

– ra ⊆ R × A est une relation entre l’ensemble R des rôles et l’ensemble A desactions. A chaque rôle on associe les actions qui sont permises dans la communauté.Chaque rôle disposant au moins d’une actions dans la communauté, la relation rr

est totale à gauche.– rp ⊆ R× A× P est la relation qui à chaque couple (rôle,action) associe un proto-

cole. Prenons par exemple l’action de rejoindre la communauté, le protocole seradifférent si l’agent est membre ou créateur, dans le premier cas il sera émetteur dela requête, dans le second cas, il traitera la requête.

5.1.1.1 Communauté zéro

La communauté zéro c0 ∈ C ou communauté minimale est la plus petite commu-nauté que l’on puisse construire, dans laquelle il y a un transfert possible d’informationsentre les membres. D’aucun pourrait penser intuitivement que la communauté minimalecontient 3 actions, rejoindre,envoyermessage,quitter, on peut en fait définir une commu-nauté avec seulement deux actions envoyermessage,quitter. Cette communauté fonctionnecomme une mailing-list ou l’envoi d’un message sur la liste entraine l’ajout commemembre de la liste. Pour quitter la liste, on envoie un message au créateur de la listequi retire l’agent de la liste. La figure 5.1 illustre cet exemple. Bob est le créateur de lacommunauté, Chuck et Dave sont des membres de la liste. Alice envoie un message àBob selon le protocole associé à envoyerMessage et au participant, Bob suit le protocoleassocié au créateur et transfère le message aux membres de la liste. Finalement Alice estajoutée comme membre de la liste par Bob.

Pour les protocoles, ils seront notés avec un + à la fin si l’agent qui va executerl’action associée est émetteur de l’action, et - si il est destinataire.

En reprenant la formalisation précédente on obtient :– M = {Alice, Bob, Chuck, Dave}– R = {createur, membre}– A = {envoyerMessage, quitter}– P = {envoyerMessage+, quitter+, envoyerMessage−, quitter−}– |S| ≥ 1, le sujet de la communauté.

1. Une relation R ⊆ X× Y est dite totale à gauche ssi pour tout x dans X il existe un y dans Y tel que(x, y) ∈ R.


Alice Bob

Chuck

DaveNouveau membre

Créateur

membre

membremessage

FIGURE 5.1 – Execution de envoyerMessage dans la communauté c0

– Associations rôles agent :– (Alice, membre) ∈ rc

– (Bob, crateur) ∈ rc

– (Chuck, membre) ∈ rc

– (Dave, membre) ∈ rc

– Associations rôles actions :– (createur, quitter) ∈ rc

– (createur, envoyerMessage) ∈ rc

– (membre, quitter) ∈ rc

– (membre, envoyerMessage) ∈ rc

– Associations rôles, actions et protocoles :– (createur, envoyerMessage, envoyerMessage−) ∈ rp

– (createur, createur, quitter−) ∈ rp

– (membre, quitter, quitter+) ∈ rp

– (membre, envoyerMessage, envoyerMessage+) ∈ rp

5.1.1.2 Protocoles

Les protocoles spécifient les règles de communication entre les différents agents. Achaque action dans la communauté est associée un protocole. Ce protocole décrit lesrègles de communication d’agents en spécifiant le contenu des messages échangés lorsde cette communication.

5.1.1.3 Exemple : Communauté 0

Pour illustrer notre propos nous décrivons les règles d’envoi d’un messsage dans lecadre de la communauté-0 présentée ci-dessus. La spécification du protocole d’envoisous forme de diagramme séquence est présentée en figure 5.2.


Communauté 0 : Broadcast

membre créateur

Envoi message

Membre 1 Membre N

Broadcast du message

FIGURE 5.2 – Diagrame de séquence du protocole envoyerMessage de la communauté 0

5.1.1.4 Vue d’une communauté

Chaque agent ne possède pas la même vision de la communauté. En effet, en fonctionde son rôle et de son historique dans la communauté, un agent ne possèdera pas lesmêmes informations que ses homologues. Prenons toujours pour exemple la commu-nauté zéro, Alice qui vient de rejoindre la communauté, ne sait pas que Bob et Chuck sontmembres de la communauté, de même elle ne sait quels sont les messages qui ont étééchangés avant son entrée dans la communauté. Par contre Bob qui est le créateur decommunauté, connaît la liste de tous les membres et possède un historique de tous lesmessages.

Concernant les protocoles qui régissent la communauté, il n’est pas nécessaire quechaque agent ait connaissance de tous les protocoles. Il est même souhaitable pour desraisons de sécurité que chaque agent ne possède que les protocoles qui sont nécessairesà son intéraction avec la communauté.

5.1.1.5 Efficacité des VKC

Les VKC sont un moyen de partager des connaissances entre les agents, selonles protocoles d’échanges utilisés les VKC peuvent être plus ou moins efficaces. Pour


mesurer l’efficacité de ces communautés nous définissons l’efficacité de l’échange desconnaissances de la manière suivante :

– One note At l’ensemble des agents présents dans la communauté au temps t.– On note KT,i,t l’ensemble des connaissances reçues par l’agent i sur le thème T au

temps t.– On note fiK → [0, 1] la fonction de l’ensemble des connaissance K vers l’intervalle[0, 1] qui représente l’intérêt de l’agent i pour une connaissance. Zéro indique unintérêt nul et un un intérêt maximal.

– On note KgT,t l’ensemble des connaissances échangées sur le thème T au sein dela communauté au temps t.

On définit alors l’efficacité de la distribution des connaissances par la formule sui-vante (adaptée de nos travaux [Calmet06]) :

EKDT(t) =∑i∈At

| f (KT,i,t||KgT,t|

|At|(5.1)

Par définitions la fonction EKD prend ses valeurs dans [0, 1]. Elle est maximalequand tout les agents trouvent un intérêt dans toutes les connaissances échangées dansle système et minimale quand aucune connaissance n’est intéressante. L’EKD donne unemesure de l’évolution au cours du temps de cette efficacité. Son intégrale normalisée

sur le temps∫ t2

t1 EKDT(dt)t2−t1 indique l’efficacité moyenne dans la période entre t1 et t2. De la

même manière, sa dérivée dEDKT(t)dt indique la variation instantanée de l’efficacité.

5.1.1.6 Conclusion

Dans cette partie nous avons présenté une formalisation ensembliste des VKC baséessur les travaux précédents et sur des éléments identifiés lors de différentes implémenta-tions. A la lumière des travaux réalisés sur l’échange de connaissances qui peuvent êtreexécutées par un agent, nous avons défini une formalisation des VKC qui permet deprendre en compte cette notion afin d’opérationnaliser cette connaissance des VKC. Lanotion de protocole a été définie pour intégrer des connaissances exécutables au sein dela formalisation. Nous avons ensuite décrit la communauté zéro, qui est la communautéla plus simple que l’on puisse réaliser avec notre formalisation et qui permet d’illustrernotre approche et l’utilisation de protocoles. La prochaine étape est d’adapter cetteformalisation au format OWL qui est celui manipulé par nos agents. C’est l’objet de laprochaine sous-partie.


5.1.2 Ontologie

Nous avons présenté une formalisation ensembliste des communautés virtuelles deconnaissances, ainsi qu’une spécification plus précise des protocoles, s’appuyant surles règles qui régissent le comportement des agents. Pour compléter le lien entre cetteformalisation et les agents, nous définissons une ontologie des commaunutés virtuellesde connaissances qui est intégrable dans la base de connaissances de ces agents. Pour cefaire, nous traduisons les ensembles par des classes et les fonctions par des relations.

Le changement par rapport à la formalisation ensembliste concerne la relation ter-naire rp qui ne peut exprimer directement en OWL. En OWL les relations sont pardéfinition binaires. Pour contourner cette limitation, nous introduisons une classe in-termédiaire qui possède les deux propriétés requises. Pour la relation rp, ceci se traduitpar l’ajout de la classe intermédiaire AP (pour Action Protocole). Cette méthode faitpartie, avec deux autres des méthodes de conception préconisée par le W3C dans lanote 2 concernant les relations n-aires . les figures 5.3 et 5.4 montrent le fonctionnementde cette classe intermédiaire.

Rôles

Protocoles

Actions

FIGURE 5.3 – Relation ternaire, impossible à représenter en OWL

Rôles

Protocoles

Actions

APhasAP

hasAction

hasProtocol

FIGURE 5.4 – Introduction de la classe AP, pour représenter la relation rp

2. http://www.w3.org/TR/swbp-n-aryRelations/

http://www.w3.org/TR/swbp-n-aryRelations/


Classes

Les différentes classes de l’ontologie sont en partie celles définies lors de la forma-lisation ensembliste. La classe Agent représente un agent. La classe LeaderAgent

est une sous-classe de Agent et représente les agents ayant le rôle de leader dans lacommunauté. La classe Role décrit les différents rôles possibles qui sont liés à desactions (classe CommunityAction) et des protocoles (classe Role. La classe AP permetde représenter la relation ternaire entre un rôle, une action et un protocole. Finalementla classe Topic décrit le sujet ou thème d’une communauté. Le tableau suivant liste ces

classes.

Nom Description

AP Thing Action/Protocole pour relation ternaireAgent Thing AgentCommunity Thing Communauté virtuelle de connaissancesCommunityAction Thing Action, associée à une communautéLeaderAgent Agent Agent de type leaderLeaderRole Roles Rôle de leaderProtocol Thing Protocole de communicationRole Thing Roles dans la communautéTopic Thing Sujet/Thème

Relations

Les relations de l’ontologie sont de même très proches des relations introduites précé-demment. La relation hasTopic associe une communauté à un sujet. Une communautéest reliée à ses membres par les relations inverses memberOf et hasMember. Les rôlessont à la fois liées aux agents et aux communautés. La relation entre rôles et agentsest donnée par memberHasRole. Celle avec les communautés est décrite par hasRoleet son inverse roleOf. Les rôles sont aussi liés aux actions et aux protocoles qui leursont associés par l’intermédiaire des relations hasAP, hasAction et hasProtocol quireprésentent la relation ternaire.

Nom Source But Description

hasTopic Community Topic associe une communauté à un sujethasAP Roles AP relation associant des actions et protocoles à un rôlehasAction AP CommunityAction associe un AP à une actionhasProtocol AP Protocols associe un AP à un protocolehasMember Community Agent défini les membres d’une communautémemberOf Agent Community inverse de hasMemberhasRole Community Role associe un rôle à une communautéroleOf Community Role inverse de hasRolememberHasRole Agent Roles associe un rôle à un agent

L’ontologie est donnée sous forme d’expression ainsi qu’au format N3 en annexe A.


5.1.2.1 Vue des agents

La vue d’une communauté dans la base de connaissances d’un agent se traduitpar les différentes instances des classes qu’il possède. Dans l’exemple précédent de lacommunauté zéro, les agents Alice et Bob possèdent les différentes vues suivantes :Alice – Topic : le sujet de la communauté

– Roles : membre, créateur– Membres : Alice,Bob– MemberHasRole : Alice→ membre

Bob→ createur– Actions : envoyerMessage+,quitter

Bob – Topic : le sujet de la communauté– Roles : membre, créateur– Membres : Alice,Bob,Chuck,Dave,– MemberHasRole : Bob→ createur

Alice→ membreChuck→ membreDave→ membre

– Actions : envoyerMessage+,envoyerMessage-,quitterChuck – Topic : le sujet de la communauté

– Roles : membre, créateur– Membres : Alice,Bob,Chuck,Dave– MemberHasRole : Alice→ membre

Bob→ createur– Actions : envoyerMessage+,quitter

Dans le cas d’une communauté centralisée telle que la communauté-0, il apparaît queseul le créateur de la communauté possède une vue complète de la communauté. Dansle cas de communautés décentralisées, le créateur possède l’ensemble des protocoles decommunication, cependant il ne connaît pas l’intégralité des agents appartenant à lacommunauté et possède de ce fait une vue partielle.

La notion de vue de la communauté est capitale puisqu’elle permet de maintenir laconnaissance d’une communauté tout au long de sa durée de vie.

5.1.2.2 Un exemple : Yahoo ! Groups

Afin d’illustrer l’utilisation de notre formalisation, nous allons décrire le fonctionne-ment du service de groupes de discussion fourni par Yahoo ! 3. Les groupes Yahoo ! ontété créé en 1998 et font partie des 5 applications les plus utilisées du réseau Yahoo !. Lesgroupes Yahoo offrent les fonctionnalités suivantes aux utilisateurs :

3. http://fr.groups.yahoo.com

http://fr.groups.yahoo.com


– Messages : Envoie par mail au groupe. Possibilité de suppression d’un message.– Album Photo : Organisé en album– Stockage de fichier– Annuaire de liens : description de chaque lien, organisé en répertoire– Sondages– Base de données : possibilité de créer 10 tables– Liste des membres– Calendrier– Promotion : boîte HTML pour la promotion du siteLes créateurs et managers du groupe peuvent quant à eux accéder aux fonctionnalités

supplémentaires suivantes :– Invitation : pour inviter des membres– Gestion des membres : validation et suppression de comptes– Gestion des messages : validation et suppression– Options : message d’accueil, . . .Pour représenter les communautés virtuelles que constituent les Yahoo ! Groups

avec l’ontologie définie précédemment, nous allons tout d’abord identifier les différentsrôles au sein des communautés. Les rôles de membres, manager et créateur sont ceuxspécifiés par Yahoo ! Groups. A ces 3 rôles s’ajoutent celui de Yahoo ! en tant qu’hébergeurdes communautés et fournisseur d’un service de recherche de ces communautés. Lacardinalité du créateur est de 1, puisqu’il ne peut y avoir qu’un seul créateur, il en estde même pour l’hébergeur. Les rôles de manager et utilisateur ne sont pas limités ennombre.

Les fonctionnalités décrites précédemment permettent de définir les actions, toutd’abord celles associées aux membres, manager et créateur (au nombre de 29) :

– Messages : {EnvoiMessage, SuppressionMessage}– Album Photo : {CréerAlbum, SupprimerAlbum, AjouterPhoto, SupprimerPhoto}– Stockage de fichier : {CréerRépertoire, SupprimerRépertoire, AjouterFichier, Supprimer-

Fichier}– Annuaire de liens : {CréerRépertoireAnnuaire, SupprimerRépertoireAnnuaire, Ajouter-

Lien, SupprimerLien, EditerLien}– Sondages : {CréerSondage, SupprimerSondage, AjouterRéponse, FinVote}– Base de données : {CréerTable, SupprimerTable, AjouterValeur, SupprimerValeur}– Liste des membres : {AfficherListe, VoirProfil}– Calendrier : {AjouterEvenement, SupprimerEvenement, EditerEvenement}– Promotion : {CréerBoîte}Les 6 actions réservées aux managers et au créateur :– Invitation : {InviterMembre}– Gestion des membres : {ValiderMembre, SupprimerMembre}– Gestion des messages : {ValiderMessage, SupprimerMessage}


– Options : {DéfinirMessageAccueil}Enfin l’action DissolutionCommunauté qui met un terme à la communauté est ré-

servée au créateur et à l’hébergeur. L’ontologie des Yahoo ! Groups contient donc29+6+1 = 35 actions. Les relations rôles actions sont au nombre de 101 : 29 ×|{membre, createur, manager}|+ 6× |{manager, createur}|+ 1× |{createur, hebergeur}|.L’ontologie possède deux fois plus de protocoles que d’action, chaque action ayant unprotocole pour l’émetteur et un pour le récepteur. A noter que l’hébergeur est ici le seulrécepteur des actions.

Cet exemple permet d’illustrer l’utilisation de l’ontologie que nous de définir dansun cas concret d’un réseau de communautés existant et très largement utilisé.

5.1.2.3 Conclusion

La transformation de la formalisation ensembliste en une ontologie OWL est unprocessus qui a nécessité peu de modifications par rapport à la version de départ. Lesformalismes étant relativement proches dans le concept, seule la relation ternaire adu être transformée. Les spécificités de OWL, telles que les relations inverses et lesrestrictions sur les relations permettent d’exprimer pleinement notre approche descommunautés dans une ontologie qui est manipulable par les agents.

Chaque agent possède une vue différente de la communauté puisque chaque agentselon rôle ou le moment ou il a rejoint la communauté, ne possède pas les mêmesinformations. Nous avons illustré ce concept à l’aide de la communauté zéro. L’exempledes Yahoo ! Groups a quant à lui illustré le fonctionnement de l’ontologie ainsi que sonexpressivité pour décrire un cas réel.

5.1.3 Agents Sémantiques et ontologie des communautés virtuelles de connais-sances

Dans la description formelle des communautés virtuelles de connaissances, un pointreste à éclaircir. En effet, nous n’avons donné aucune précision quant à la nature desprotocoles. Ces protocoles décrivent les mécanismes de communication entre les agentsainsi que les actions à effectuer à la récéption d’un message. Ces protocoles sont doncreprésentables comme des comportements pour les agents SAM, puisqu’ils contiennentdes actions à effectuer. Nous allons donc représenter ces protocoles sous formes de règlesinterprétables par les agents SAM.

En utilisant les spécifications sur les agents SAM, nous pouvons définir plus préci-sément la notion de protocoles pour ces agents. Les messages échangés par les agentsutilisent la norme FIPA-ACL et les différents champs qui les composent sont définisdans l’annexe C.


L’expression des protocoles sous forme de règles éxécutables, permet de décriretotalement l’implémentation d’une communauté, et de transformer cette formalisationen une formalisation « utilisable » en opposition avec une formalisation « descriptive ».

En reprenant l’exemple du protocole de la communauté-0 à la figure 5.2 nous pou-vons maintenant décrire ce protocole sous forme de règles SWRL telles que définies auchapitre précédent. La notation " ?x" signifie que x est utilisée comme variable (mode -en notation Prolog) dans la règle.

Emetteur : Envoi un message au créateur de la communauté, avec une performative derequète, le contenu du message est celui du message à transférer et le protocole dumessage est "envoyerMessage" comme défini ci-dessus.

⇒ creator(?y) ∧message(?x) ∧ hasContent(x, content)

∧hasPer f ormative(x, ”request”) ∧ hasProtocol(x, ”envoyerMessage”)

∧hasReceiver(x, y) ∧ sendMessage(x)

Createur : Si un message respectant les spécifications de la règle est reçu alors le messageest transmis à tout les membres de la communauté et l’émetteur du messagedevient alors membre de communauté.

receivedMessage(?x) ∧ hasSender(?y)

∧hasPer f ormative(x, ”request”) ∧ hasProtocol(x, ”envoyerMessage”)

⇒ member(y) ∧member(?w)

∧hasReceiver(x, w) ∧ sendMessage(x)

5.1.3.1 Conclusion

Les protocoles sont des séquences exécutables par l’agent, suivant les spécificationsque nous avons donné au chapitre précédent. Ils permettent une description séman-tique complète de la communauté, qui ne se restreint pas à une simple spécificationde concepts, mais le fait qu’ils contiennent un code exécutable par l’agent rend cettereprésentation sémantique des communautés opérationnelle et directement utilisablepar les agents. C’est un des apports principaux de notre approche. La représentationsémantique des comportements des agents que nous avons défini au chapitre précédentpermet d’embarquer du code sémantique au sein d’une ontologie et par conséquent dedonner une implémentation de la communauté.

5.2 Application

Dans ce chapitre nous avons défini une formalisation, puis une ontologie des commu-nautés de connaissance au format OWL. Au chapitre précédent, nous avons défini une

Section 5.2. Application 169

architecture d’agents sémantiques, qui permet, premièrement l’unification des connais-sances et des comportement dans les formats du web sémantique et deuxièmement, lareprésentation et l’échanges de connaissances empiriques et justifiables.

Le but de cette application est d’illuster au travers d’un exemple les atouts de notreapproche et de mettre en œuvre les différents concepts que nous avons défini. Nousavons vu dans la section 5.1.1.2, un premier lien entre l’architecture des agents et l’onto-logie des communautés de connaissance. Les protocoles qui définissent les intéractionsentre les agents au sein d’une communauté sont en fait des actions exécutables directe-ment par les agents. Nous allons poursuivre dans cet exemple l’illustration des différentsconcepts au travers d’un échange de connaissances entre agents.

Le but de l’exemple est d’illustrer la transmission d’une connaissance empirique(l’utilisation de communautés de connaissances, décrite par l’ontologie en annexe A)puis son utilisation pour permettre à un agent d’acquérir des connaissances.

5.2.1 Description du scénario

Ce scénario présente l’intégration d’agents SAM au sein d’un environnement hété-rogène, dans lequel des agents de différentes natures évoluent et communiquent parl’intermédiaire de messages respectant la norme FIPA-ACL. Cet exemple permet demettre en œuvre les concepts d’échanges de connaissances empiriques et de représenta-tion ontologique des communautés de connaissance, tels que nous les avons énoncésdans les chapitres précédents.

Dans ce scénario l’agent Julio, cherche à répondre à « La grande question sur lavie, l’univers et le reste » 4. Au début de ce scénario, l’agent Julio connaît seulementl’agent Carmen. Il lui demande si elle connaît la réponse à la fameuse question. Carmenne connaît certes pas la réponse mais elle pense qu’il existe sûrement une communautéde connaissances autour de ce thème. Elle indique alors à Julio le fonctionnement deces communautés de connaissances. Jusqu’ici Julio n’avait pas connaissance du conceptmême de communautés de connaissances. Il apprend grâce à Carmen l’existence et lefonctionnement de ces communautés. Au sein du système dans lequel Julio et Carmenévoluent, d’autres agents (au nombre de 3 dans cet exemple) intéragissent au sein decommunautés virtuelles de connaissances. L’agent Julio, qui connaît désormais le fonc-tionnement des communautés de connaissances, va pouvoir rejoindre la communautésur le thème qui l’intéresse et finalement pouvoir obtenir la réponse tant désirée.

4. http://fr.wikipedia.org/wiki/La_grande_question_sur_la_vie,_l%27univers_et_le_reste

http://fr.wikipedia.org/wiki/La_grande_question_sur_la_vie,_l%27univers_et_le_reste

http://fr.wikipedia.org/wiki/La_grande_question_sur_la_vie,_l%27univers_et_le_reste


Agents

Le scénario présente deux agents sémantiques, Julio et Carmen ainsi que trois agentnon sémantiques PagesJaunes, PenséesProfondes et Loonquawl. Les agents dits sémantiquespossède l’architecture que nous avons défini au chapitre précédent. Les agents nonsémantiques ne possède pas cette architecture.

Communautés

Les communautés de connaissances au sein du système possèdent les propriétéssuivantes :

– Les agents intéragissent au sein d’une communauté par le biais d’un tableaunoir qui est hébergé par l’agent créateur de la communauté. Les agents peuventlire et écrire des messages sur ce tableau, qui est structuré sous forme de pile.Cette implémentation est présentée dans [Maret04b]. Nous représentons cetteimplémentation comme une instance de notre modèle de commaunuté définiprécédemment.

– Le créateur de la communauté maintient la liste des agents membres de la commu-nauté.

– Les communautés sont listées au sein d’un annuaire de communautés, aussiappellé la « Communauté des communautés ». L’annuaire propose un serviced’enregistrement des communautés, chaque communauté est associée à un thème.Du point de vue de la représentation des connaissances, le thème est une classeOWL.

La communauté des commaunutés peut-être vue comme le point d’entrée d’un forumdistribué. Chaque discussion autour d’un thème est hébergée par un agent différent et lemode de discussion est identique pour toutes les discussions.

Transmission d’une connaissance empirique

La connaissance transmise par Carmen est double, elle indique ce que sont les com-munautés de connaissances et comment y participer. Ce que sont ces communautés estdécrit par une instance des concepts de l’ontologie des VKC. Le comment est décrit parune connaissance empirique, tel que spécifiée en section 4.4 :

– Une séquence d’action (voir figure 5.5) :

1. Charger l’ontologie décrivant les communautés.

2. Exécuter le protocole de recherche de communauté dans les pages jaunes(communauté de communautés).

3. Si une communauté existe, exécuter le protocole pour rejoindre. Sinon créerune communauté.

4. Procéder à l’échange de connaissances selon les protocoles de la communauté.

Section 5.2. Application 171

– La propriété qui doit être vraie à la fin de l’exécution : l’appartenance à unecommunauté (si il n’existe pas de communauté, elle est alors créée par l’agent). Lecode SPARQL de cette propriété est donnée dans l’exemple 5.1

Exemple 5.1 Requète SPARQL : Appartenance de l’agent courant à une com-munauté

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>PREFIX agentModel: <http://liris.cnrs.fr/julien.subercaze/ontologies/agentModel.owl#>PREFIX vkc: <http://liris.cnrs.fr/julien.subercaze/ontologies/vkc.owl#>PREFIX myc: <http://liris.cnrs.fr/julien.subercaze/ontologies/testvkc.owl#>

SELECT count(?Community)WHERE {

?Community rdf:type vkc:Community .?Community vkc:hasmembers myc:ME .

}

Après utilisation de la connaissance transmise sur les communautés virtuelles, l’agentqui utilise cette connaissance doit être en mesure de rejoindre une communauté. Larequète de l’exemple 5.1 renvoie le nombre de communautés auquel l’agent courant,identifié par ME, appartient. Si ce nombre est supérieur à zéro, alors l’agent a pu utilisé laconnaissance qui lui a été transmise. Nous verrons par la suite qu’à l’issue de l’exécutionde la séquence d’actions, la propriété est vérifiée.

Déroulement

Au cours du scénario, l’agent Julio va tout d’abord intéragir avec Carmen qui luitransmettra sa connaissance des communautés virtuelles de connaissances. Parallèle-ment Penséesprofondes crée une communauté autour du thème de la Grande question dela vie, il déclare l’existence communauté aux PagesJaunes. Longhorn souhaite partager laréponse qu’il possède avec d’autres agents connaît le fonctionnement des communautésvirtuelles de connaissances. Il recherche la communauté adéquate pour partager sonsavoir. Il contacte alors les PagesJaunes puis rejoint la communauté initiée par Pensées-profondes et partage son message qui est inscrit sur le tableau de la communauté. Julioa appris par Carmen, l’existence et le fonctionnement des communautés, il contactealors les Pagesjaunes, rejoint la communauté initiée par Penséesprofondes puis récupère laréponse déposée par Longhorn. Les messages échangés entre les agents dans ce scénariosont illustrés par la figure 5.6.


Obtenir la liste des

communautés sur

le thème

|Communautés|>0

|Communautés|=0

Echange de

connaissances

Création de la

communauté

Choix de la

communauté

Communauté

L’agent doit-il

rester dans la

communauté ?

Evaluation interne

de l’agent

Changer

Rester

N’appartient pas

à une commaunuté

Communauté

Appartient à

une communauté

FIGURE 5.5 – Exemple : utilisation des communautés virtuelles de connaissances. Sé-quence d’actions transmise par Carmen à Julio

5.2.2 Conclusion de l’exemple

Au travers des intéractions avec les différents agents de la communauté, l’agentJulio a acquis un savoir-faire qui lui a permis d’obtenir la réponse à la grande questionfondamentale de la vie. Cet exemple a permi de montrer les possibilités ouvertes parl’échange de connaissance empirique et de montrer une utilisation pratique de l’ontolo-gie décrivant les communautés de connaissances. Deux caractéristiques principales ontété mises en évidence : la transmission et l’utilisation de connaissance empirique et ladescription de communautés virtuelles de connaissance à l’aide du formalisme définidans ce chapitre.

5.3 Conclusion

Nous avons présenté une formalisation ensembliste des VKC basées sur les travauxprécédents et sur des éléments identifiés lors de différentes implémentations. A la


FIGURE 5.6 – Exemple : diagramme des messages échangés par les agents lors del’exécution du scénario sur la plate-forme JADE

lumière des travaux réalisés sur l’échange de connaissances qui peuvent être exécutéespar un agent, nous avons défini une formalisation des VKC qui permet de prendreen compte cette notion afin d’opérationnaliser la connaissance des VKC. La notionde protocole a été définie pour intégrer des connaissances exécutables au sein de laformalisation. Nous avons ensuite décrit la communauté zéro, qui est la communauté laplus simple que l’on puisse réaliser avec notre formalisation et qui permet d’illustrernotre approche et l’utilisation de protocoles.

La transformation de la formalisation ensembliste en une ontologie OWL est unprocessus qui a nécessité peu de modifications par rapport à la version de départ. Lesformalismes étant relativement proches dans le concept, seule la relation ternaire adu être transformée. Les spécificités de OWL, telles que les relations inverses et lesrestrictions sur les relations permettent d’exprimer pleinement notre approche descommunautés dans une ontologie qui est manipulable par les agents.

Chaque agent possède une vue différente de la communauté puisque chaque agentselon rôle ou le moment ou il a rejoint la communauté, ne possède pas les mêmesinformations. Nous avons illustré ce concept à l’aide de la communauté zéro. L’exempledes Yahoo ! Groups a quant à lui illustré le fonctionnement de l’ontologie ainsi que sonexpressivité pour décrire un cas réel.

Nous avons ensuite présenté l’intégration des protocoles avec le concept d’agentsémantique. Les protocoles sont des séquences exécutables par l’agent, suivant les spéci-


fications que nous avons données au chapitre précédent. Ils permettent une descriptionsémantique complète de la communauté, qui ne se restreint pas à une simple spécifica-tion de concepts, mais le fait qu’ils contiennent un code exécutable par l’agent rend cettereprésentation sémantique des communautés opérationnelle et directement utilisablepar les agents. C’est un des apports principaux de notre approche. La représentationsémantique des comportements des agents que nous avons défini au chapitre précédentpermet d’embarquer du code sémantique au sein d’une ontologie et par conséquent dedonner une implémentation de la communauté.

Finalement nous avons présenté un exemple illustratif, détaillant les protocoles et lesintéractions entre les agents. Cet exemple a permis de montrer les possibilités ouvertespar l’échange de connaissance empirique et de montrer une utilisation pratique de l’on-tologie décrivant les communautés de connaissances. Deux caractéristiques principalesont été mises en évidence : la transmission et l’utilisation de connaissance empirique etla description de communautés virtuelles de connaissance à l’aide du formalisme définidans ce chapitre.

The brain is a computing machine connected with a spirit.

Kurt Gödel, in A logical journey : from Gödel to philosophy

6Implémentation

176 Chapitre 6. Implémentation

Plan du chapitre

6.1 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

6.2 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

6.3 Exécution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1816.3.1 Initialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1816.3.2 Comportements . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

6.4 Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1836.4.1 Gestion des ontologies . . . . . . . . . . . . . . . . . . . . . . . 1836.4.2 Entrées/Sorties . . . . . . . . . . . . . . . . . . . . . . . . . . . 1856.4.3 Connaissance empirique . . . . . . . . . . . . . . . . . . . . . . 1866.4.4 Communications . . . . . . . . . . . . . . . . . . . . . . . . . . 1866.4.5 Appel des actions . . . . . . . . . . . . . . . . . . . . . . . . . . 187

6.5 Base de connaissances . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1896.5.1 Base minimale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

6.6 Conclusion et discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 1916.6.1 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Section 6.1. Choix techniques 177

LA réalisation d’un prototype est une étape importante dans la validation de notreapproche. Nous présentons dans ce chapitre les différents éléments de l’implémen-

tation de notre protoype. Dans une première partie nous détaillons et motivons les choixtechniques. Ensuite nous entrons dans le cœur même de l’application en décrivant lastructure de classes, nous énumérons et décrivons de manière systèmatique les classeset méthodes. Nous présentons ensuite les différentes étapes d’exécution d’un agent, soninitialisation et le fonctionnement de l’interpréteur SAM. Cet interpréteur fait appelaux actions de bas niveau qui complètent les actions SWRL. Nous détaillons en section6.4 les actions de bas niveaux ainsi que le mécanisme d’appel de ces actions. Ensuitenous présentons la structure de la base de connaissances qui permet d’exécuter descomportements sémantiques. Nous listons les différents éléments spécifiés au cours dessections précédentes.

Les difficultés rencontrées lors du développement du prototype font l’objet de lasection 6.6. Nous discutons au sein de cette même section des limitations techniquesdu prototype et des moyens, le cas échéant de les dépasser. Nous terminons par lesperspectives offertes par le développement de ce prototype et présentons les futurs axesde développement.

6.1 Choix techniques

Les contraintes de réalisation du prototype étaient extrêmement faibles. Seul lesupport du langage FIPA-ACL pour l’interopérabilité avec l’ancien prototype étaitrequis. Nos critères de choix se sont donc avant tout portés sur la qualité et la simplicitédes librairies.

Dans la continuité du prototype développé dans le cadre des communautés deconnaissance nous avons choisi la plate-forme JADE pour implémenter notre prototype.Les limitations montrées dans la section 2.1 étaient dues à l’implémentation des agentsau sein de la plate-forme JADE mais non à la plate-forme elle-même. L’expérience de laplate-forme ainsi que la perspective de faire cohabiter simplement les agents des VKCavec les agents sémantiques ont motivé ce choix.

Le choix du raisonneur s’est fait entre les différents raisonneurs proposant un sup-port SWRL : RacerPro, Bossam, Pellet, KAON2 et Fact++. Bossam et RacerPro n’étantplus maintenu depuis 2007, ils ont été rapidement écarté. L’utilisation de JADE nousimposant une API Java, Fact++ (développé en C++) a été écarté. KAON2 et Pellet (tousdeux en JAVA et offrant un support DL-Safe) possèdent deux approches différentes. lepremier utilise un système déductif de type "Forward Chaining" alors que le secondutilise une approche par tableau calcul. Le but de notre prototype étant de fournir unepreuve de concept et non de manipuler de grandes ontologies, la méthode de raisonne-ment importait peu. Le support de SWRL (des fonctions built-ins) était au départ du


développement très partiel pour les deux raisonneurs. Le critère de sélection s’est doncfait sur la qualité du développement du projet, les exemples fournis, l’activité du forumde support et c’est Pellet qui a finalement remporté nos suffrages.

Pour la base de connaissances, nous avons utilisé la librairie AgentOWL de Laclavik[Laclavik06b] qui propose un support OWL (en se basant sur Jena) pour les agentsJADE. Afin d’intégrer un support pour OWL et SWRL dans la base de connaissances desagents, nous avons étendu la librairie AgentOWL pour permettre d’intégrer le supportdu raisonneur Pellet au modèle Jena. L’échange de règles SWRL au travers d’une APIJava a nécessité l’utilisation de l’API Protege, Jena ne supportant pas l’ajout de règlesau modèle. En utilisant les compatibilités entre les deux modèles, nous maintenons unereprésentation homogène. Une ontologie du projet Nuin [Dickinson03] a été intégréeafin de représenter les messages FIPA-ACL au format OWL. L’ontologie OWLList deDrummond [Drummond06] nous permet de représenter des séquences en OWL.

Les diagrammes de séquence et de classes ont été réalisés à l’aide des pluginsMaintainJ 1 et ObjectAID 2 pour Eclipse.

6.2 Classes

La classe SWRLAgent est la classe centrale de notre implémentation du modèle SAM.Elle étend la classe abstraite SemanticAgent qui étend elle-même la classe Agent deJADE. Cette classe SemanticAgent possède un attribut mem de type KnowledgeBasequi représente la base de connaissances.

La seule implémentation de KnowledgeBase est la classe SWRLMemory qui per-met de gérer la base de connaissances OWL et SWRL de l’agent. Cette classe estadaptée de OWLMemory de la librairie AgentOWL de Michal Laclavik [Laclavik06a].Le champ config définit les paramètres d’initialisation de la base de connaissances(URL des fichiers de connaissances et de comportement). Le champ model de typecom.hp.hpl.jena.ontology.OntModel représente la vue JAVA de la base deconnaissances de l’agent. Le choix de Jena est du au choix du raisonneur Pellet. Eneffet Pellet a été conçu pour être utilisé comme un raisonneur associé à un modèle Jena.Pour cela nous initialisons le modèle Jena avec le raisonneur Pellet en utilisant la factoryModelFactory :

model = ModelFactory.createOntologyModel(PelletReasonerFactory.THE_SPEC);

Le modèle Jena est stocké en mémoire, il est cependant parfois nécessaire d’utiliserun modèle de la librairie Protégé API pour certaines actions non disponibles dansl’API Jena. Les deux modèles étant interchangeables, la librairie ProtegeOWL permet

1. http://www.maintainj.com2. http://www.objectaid.com

http://www.maintainj.com

http://www.objectaid.com

Section 6.2. Classes 179

<<

Java C

lass>

>

ThreadedBehaviourFactory

jade.c

ore

.behavio

urs

<<

Java C

lass>

>

SWRLAgent

agent.core

.sw

rlagent

num

: in

t

SW

RLA

gent(

)

chain

Rule

s()

: void

extr

actP

ara

mete

r(S

trin

g,H

ashM

ap<

Str

ing,S

trin

g>

): S

trin

g

setu

p()

: void

execute

Actions(I

ndiv

idual):

void

execute

Action(S

trin

g,H

ashM

ap<

Str

ing,S

trin

g>

): v

oid

retr

ieveP

ara

mete

rs(I

ndiv

idual):

HashM

ap<

Str

ing,S

trin

g>

noC

hild

Behavio

ur(

): b

oole

an

sta

ckS

ize()

: in

t

popB

ehavio

ur(

): v

oid<

<Java C

lass>

>

SemanticAgent

agent.core

.onto

<<

Java I

nte

rface>

>

KnowledgeBase

agent.core

.mem

ory

config:

Config

model: O

ntM

odel

setM

odel(O

ntM

odel):

void

getM

odel():

OntM

odel

<<

Java C

lass>

>

SWRLMemory

agent.core

.mem

ory

config:

Config

model: O

ntM

odel

SW

RLM

em

ory

(Str

ing,S

trin

g)

getB

ase()

: S

trin

g

initM

odel():

OntM

odel

perf

orm

Infe

rence(S

trin

g,b

oole

an):

void

mem

ory

2sw

rl()

: void

setM

odel(O

ntM

odel):

void

getM

odel():

OntM

odel

<<

Java C

lass>

>

TickerBehaviour

jade.c

ore

.behavio

urs

<<

Java C

lass>

>

SimpleBehaviour

jade.c

ore

.behavio

urs

<<

Java C

lass>

>

Behaviour

jade.c

ore

.behavio

urs

<<

Java C

lass>

>

MessageBehaviour

agent.core

.sw

rlagent

MessageB

ehavio

ur(

Agent,

long)

onT

ick()

: void

<<

Java C

lass>

>

SemanticBehaviour

agent.core

.sw

rlagent

done:

boole

an

action()

: void

done()

: boole

an

<<

Java C

lass>

>

Agent

jade.c

ore

-tbf��

+m

em

��

#m

yA

gent

��

FIGURE 6.1 – Diagramme de classe d’un agent


d’importer un modèle Jena et d’exporter un modèle Protégé au format Jena. L’appelau raisonneur Pellet étant requis par l’interpréteur qui est le composant principal del’agent, le modèle Jena est la représentation permanente de la base de connaissances. Lesdifférentes méthodes de la classe sont décrites ci-dessous :

getBase : URL du fichier contenant la base de connaissances.

initModel : Initialisation du modèle en fonction de la configuration config.

performInference : Héritée de AgentOWL, réalise une inférence. Le fichier contenant larègle est passé en paramètre, ainsi qu’un booléen indiquant si l’on souhaite garderla trace des propositions inférées.

memory2swrl : sauvegarde la base de connaissances sous la forme d’un fichier. Le nomet chemin du fichier sont définis dans config.

setModel : accesseur permettant de remplacer le modèle courant par celui passé enparamètre.

getModel : accesseur permettant de consulter le modèle présent.

Pour gérer l’arrivée des messages et leur mise en file au sein de la base de connais-sances, un processus dédié y est affecté en plus de celui dédié au comportement classiquede l’agent. Au niveau de l’architecture JADE il est possible d’affecter plusieurs com-portements à un agent à l’aide de la classe ThreadedBehaviourFactory. Un agentSWRLagent possède un objet tbt de type ThreadedBehaviourFactory pour gérerces comportements. Les comportements sont ensuite executés de manière parallèle. Lesdeux comportements utilisés sont SemanticBehaviour en charge du comportementprincipal de l’agent et MessageBehaviour en charge de la gestion des messages.

MessageBehaviour est un comportement de type TickerBehaviour. Ce typede comportement est exécuté de manière périodique par l’invocation de la méthodeonTick(). Dans l’architecture JADE, un agent possède une queue de messages acces-sible par différentes méthodes. Le rôle de ce comportement est de transférer les messagesreçus de la couche JADE à la couche sémantique, en convertissant les messages ACLreçus en instance OWL de la classe message.

Le comportement SemanticBehaviour est un comportement de typejade.core.behaviours.SimpleBehaviour, c’est-à-dire un comportement simplequi est appellé une fois. Ce comportement appelle l’interpréteur du langage SAM situédans la méthode chainRules de la classe SWRLAgent.

La classe SWRLAgent contient les méthodes implémentant l’interpréteur du langageSAM. En tant qu’agent de type jade.core.agent.Agent, la méthode setup est invo-quée lors de l’initialisation de l’agent. Cette méthode initialise la base de connaissancesen créant l’objet mem de type SWRLMemory. La méthode principale est chainRules quienchaîne les règles selon l’algorithme présenté en figure 1. Pour gérer la pile d’appel

Section 6.3. Exécution 181

des comportements, la méthode chainRules fait appel aux méthodes stackSize,noChildBehaviour et popBehaviour. La méthode noChildBehaviour renvoievraie si le comportement courant est le seul comportement executé, c’est-à-dire qu’iln’est pas le fils d’un comportement qui l’a invoqué. La méthode stackSize renvoie lataille de la pile d’appel, et zéro quand noChildBehaviour renvoie vraie. Le rôle dela méthode popBehaviour est de retirer le comportement courant de la pile d’appel,l’ancien comportement père se retrouve alors comportement courant. Dans le cas ou iln’y a pas de comportement père, l’agent termine.

La méthode chainRules fait appel au raisonneur Pellet qui exécute les fonc-tions SWRL de haut niveau, puis cette méthode extrait du conséquent des règles laséquence des actions à exécuter ainsi que leurs paramètres respectifs. La méthodeexecuteActions exécute la séquence d’actions associée à une règle. Pour cela ellefait appel à la méthode retrieveParameters pour extraire les paramètres de l’actioncourante à exécuter, puis invoque la méthode executeAction qui appelle l’action àexécuter. Nous détaillons les actions en section 6.4. La figure 6.1 présente les différentesclasses décrites.

6.3 Exécution

L’exécution d’un agent sémantique se fait en deux temps, tout d’abord l’initialisationde l’agent qui comprend le chargement de la base de connaissances et le lancementde l’interpréteur. La deuxième phase, le régime permanent est celui de l’exécution ducomportement sémantique de l’agent par l’interpréteur.

6.3.1 Initialisation

Lors du démarrage de l’agent SWRLAgent, comme toute classe héritant dejade.core.agent.Agent, la méthode setup est invoquée. Cette méthode ini-tialise la base de connaissances SWRLMemory qui fait appel à la configurationchargée par la classe Config. Les deux comportements SemanticBehaviour etMessageBehaviour sont appellés l’un après l’autre, chacun dans un processus séparé,géré par la classe ThreadedBehaviourFactory. Le diagramme de séquence en figure6.2 décrit l’initialisation d’un agent.

6.3.2 Comportements

Les deux processus (comportement au sens de JADE) SemanticBehaviour etMesssageBehaviour nécessitent la synchronisation des ressources partagées. Le pro-cessus de l’interpréteur SAM peut accéder potentiellement à toute la base de connais-


FIGURE 6.2 – Diagramme de séquence de l’initialisation d’un agent

sances . Le processus de gestion des messages n’accède quant à lui qu’à la file demessages. Il était donc nécessaire de synchroniser l’accés à cette file, ce qui est réalisé demanière classique par un mutex (primitive d’exclusion mutuelle).

L’exécution du comportement de gestion des messages MessageBehaviour sefait de manière régulière (temps paramétrable, fixé par défaut à 250ms). La méthodeonTick qui est invoqué par la factory des comportements regarde si la file des mess-sages de l’agent est non vide en appellant la méthode getCurQueueSize de la classejade.core.agent.Agent. Dans le cas ou un ou plusieurs messages sont présentsdans cette liste, les messages sont convertis dans au format OWL puis intégré à la listedes messages en attente de la base de connaissances. Nous avons réutilisé l’ontologieFIPA-ACL définie par Ian Dickinson pour le framework Nuin 3 [Dickinson03]. La struc-ture de séquence des messages au sein de la base de connaissances n’étant pas définieen OWL (à la différence des listes RDF), nous avons fait appel à l’ontologie OWLList deDrummond [Drummond06]. Cette même ontologie est aussi utilisée pour représenterles séquences d’actions. Dans le cas ou un message est présent dans la liste de l’agent(au niveau agent JADE), l’agent essaye d’acquérir le mutex de la file des messages. Unefois acquis, l’agent ajoute un message en fin de liste.

Le comportement SemanticBehaviour exécute l’interpréteur SAM par l’invoca-tion de la méthode chainRules. Cette méthode enchaîne les règles SAM en partant

3. http://www.nuin.org/ontology/fipa-acl.owl

http://www.nuin.org/ontology/fipa-acl.owl

Section 6.4. Actions 183

de l’état BEGIN. Un comportement SAM termine si l’état courant est END 4. Un com-portment pouvant invoquer un autre comportement, une pile des appels est maintenueau niveau de la base des connaissances. Une variable currentBehaviour pointe versle comportement courant. La propriété calledBy permet de lier les comportementsau sein de la pile d’appel. Lorsque que l’interpréteur détecte END comme état courant,il évalue la longueur de la pile d’appel, puis le cas échéant dépile le comportementterminé (à l’aide de la méthode popBehaviour) puis exécute le comportement père.Pour maintenir le contexte des comportements empilés, chacun possède une valeurcurrentState qui indique la valeur de l’état courant au moment ou un comportementfils a été invoqué. Toutes les autres variables sont considérées comme globale à la basede connaissances. L’exécution d’une règle de transition est effectuée dans un premiertemps par le raisonneur Pellet qui exécute les actions de haut niveau (SWRL built-ins,voir fig). L’interpréteur SAM détecte ensuite le changement de la valeur NextStatedans la base de connaissances, il charge alors la liste des actions qui se situe au niveaude la variable AL (pour Action List). Cette liste est une OWLsList, tout comme la listedes messages reçus. L’exécution de la séquence d’actions se fait en exécutant une à uneles actions par l’invocation de la méthode executeAction. Nous décrivons dans lasection suivante le mécanisme d’appel de ces actions et nous en donnons la liste. Lafigure 6.3 présente le diagramme d’activité des agents SAM (sans le comportement degestion des messages).

6.4 Actions

Les actions de bas niveau sont invoquées par l’interpréteur dans l’ordre spécifié parla liste. Les actions qui doivent être exécutées sont liées par la propriété hasNext, lesparamètres sont liées à l’action (qui est une instance de l’action qu’elle représente) par lapropriété hasParameterName qui définit le nom du paramètre. Ce nom prend ensuiteune valeur avec owl:hasValue.

Toutes les actions de bas niveau sont des instances de la classe agent.core.actions.Action.Ces actions implémentées sont au nombre de 19. Elles sont séparées en 4 catégories :gestion des ontologies, entrées/sorties, connaissance empirique et communications.Nous détaillons ces actions dans les sections suivantes.

6.4.1 Gestion des ontologies

Les actions de manipulation des ontologies : création, modification et suppressionpour chacun des types de ressources doivent être implémentées dans les actions de

4. Les éléments END, BEGIN et OUTPUT sont des éléments de la base de connaissances OWL, ils sontdéfinis en section 6.5


Diagramme d’activité des agentsRouge : appel au raisonneur Pellet

Vert : appel aux fonctions de bas niveau

Initialisation de l’agent : démarrage de l’agent JADE

Chargement de la base des connaissances

Chargement du comportementDémarrage

Exécution première règle:1 Lecture de l’état suivant

2 Exécution des fonctions sémantiques

Etatcourant= début

Etatsuivant = END Etatsuivant <> END

Lecture de laliste des actions

Taille = 0

Lecture de la taille de la piledes comportements

Dépiler

Taille<>0Lecture de

l’action à exécuter

Pas d’action

Mise à jourÉtatcourant=etatsuivant

Action présente

Récupération des paramètres

Exécution de l’action

Passage à l’action suivante

FIGURE 6.3 – Diagramme d’activité UML des agents

bas niveaux. Nous avons montré en section 4.2.3 que certains de ces actions peuventêtre effectuées par le raisonneur. Cependant l’ordre d’exécution des actions est fixé. Leraisonneur étant appellé en premier, les actions de haut niveau seront effectuées avantcelles de bas niveau. Il se peut que l’on souhaite effectuer certaines actions (comme parexemple affecter une propriété ou une valeur à un individu) après l’exécution des actionsde haut niveau. Ces fonctions existent donc dans les actions de haut et bas niveaux. Les


autres fonctions de gestion des ontologies sont définies exclusivement à bas niveau. Letableau suivant liste toutes les actions de gestion des ontologies.

Nom Paramètres Description

CreateIndivudalclass : URI de la classe Création d’un individuname : nom de l’individu

ModifyIndividualoldName : ancien nom Modification d’un individunewName : nouveau nom

DeleteIndividual name : nom de l’individu Suppression d’un invididu

CreateClass name : nom de la classe Création d’une classe

ModifyClassoldName : ancien nom Modification d’une classenewName : nouveau nom

DeleteIndividual nom de la classe : nom de la classe Suppression d’une classe

CreateProperty name : nom de la propriété Création d’une propriété

ModifyPropertyparam1 : paramètre 1 Modification de la propriétéparam2 : paramètre 2type : type de la modification

DeleteProperty name : nom de l’individu Suppression d’un invididu

La méthode modifyProperty doit permettre d’effectuer les opération de modifica-tion suivante sur une propriété :

– Changement du nom– Changement de la classe/Individu de départ– Changement de la valeur d’arrivée (classe/individu/littéral)– Révocation de l’application de la propriété sur une classe/individuCes méthodes de gestion des ontologies ont été partiellement implémentées, au fur

et à mesure des besoins pour la mise en œuvre des scénarios. Elles devront à terme êtretotalement implémentées.

6.4.2 Entrées/Sorties

Deux actions qui n’étaient pas spécifiés initialement ont été rajoutées. La première,DisplayValue permet d’afficher une valeur sur la sortie standard. Si la ressource estune classe, son nom est affiché. Si la ressource est un individu, on afficher son nom etdans le cas ou il possède une valeur (hasValue), on affiche cette valeur. La seconde action,SaveMemoy a pour but de sauvegarder l’état de la base de connaissances dans un fichier.Le nom de ce fichier est spécifié dans la configuration de l’agent à son lancement.


DisplayValue uri : URI de la ressource Affiche une valeur à l’écranSaveMemory Aucun Sauvegarde la base de connaissances dans un fichier


6.4.3 Connaissance empirique

Pour valider les connaissances empiriques ou justifiables, nous avons défini deuxactions qui sont CheckConsistency et RunQuery. La première permet de vérifier laconsistance de la base de connaissances. La méthode de vérification de la consistancefait appel à validate de com.hp.hpl.jena.rdf.model.InfMOdel. Le résultat durapport de validation (méthode isValid()) est placée dans OUTPUT. Cette action estutilisé pour choisir d’intégrer ou non de nouvelles connaissances dans la base, si ellessont consistantes avec la base. La seconde action permet d’exécuter une requète SPARQLsur la base de connaissances, le résultat étant aussi stocké dans OUTPUT. Elle est utiliséepour valider les comportements empiriques selon la méthode définie en section 4.4.L’action LoadBehaviour permet de charger un comportement et de l’exécuter. C’est lafonction qui est appellée lorsqu’un comportement fait appel à un autre comportement.Le comportement courant est alors placé dans la pile d’appel. Son contexte qui estconstitué de son état courant est sauvegardé. Le comportement appellé est alors exécuté.


RunQueryquery : requète Exécute une requète SPARQL.

Le résultat est stocké dans OUTPUTLoadBehaviour uri : uri Chargement d’un comportement

CheckConsistencyressources : URI Vérifie la consistance(Optionnel) de la base de connaissances

avec les ressources (optionnel)

6.4.4 Communications

Les agents communiquent entre eux en utilisant le support de la plate-forme JADE.Nous avons pour cela implémenter la méthode SendMessage, qui prend en paramètreun individu de la classe OWL représentant les messages FIPA-ACL ainsi que son des-tinataire (ce paramètre s’est révélé être superflu puisque contenu dans l’ontologie dumessage, mais a été conservé par souci de rétrocompatibilité). Les messages sont ajoutéspar le comportement messageBehaviour dans une file de message. Le système depages jaunes de JADE (Directory Finder) sera noté ici DF. Deux actions permettentd’intéragir avec le DF, RegisterDF et AskDF. La première action permet d’enregistrerl’agent courant auprès du système de pages jaunes. La seconde permet quant à elle derechercher des services dans le DF.



RegisterDF Aucun Enregistre l’agent au DFAsKDF ServiceName : nom du service Requète d’existence de service

SendBehaviourdest : agent récepteur Envoi d’un comportementcontent : URI/nom du fichier à un agent

SendBMessagedest : agent récepteur Envoi d’un messagecontent : URI du message

ReceiveMessage sender : expéditeur Réception avec attente active

La méthode ReceiveMessage est utilisée dans le cas ou l’on souhaite attendreexplicitement l’arrivée d’un message d’un expéditeur précis avant de continuer letraitement.

La figure 6.4 présente 13 de ces actions, l’inteface Action étant au centre, les classesétant groupé par catégories sur chaque coté. Les 6 actions non représentées sont cellesde création, modification et suppression des classes et propriétés.

6.4.5 Appel des actions

Lorsque l’interpréteur récupère les actions à exécuter depuis la base de connais-sances, il en connait le nom et les paramètres sous forme de chaînes de caractères.Ces actions doivent ensuite être exécutées par l’interpréteur. L’exécution de ces ac-tions par l’interpréteur se fait par les mécanismes de réflection de JAVA. Les actionsprennent deux paramètres ; l’agent qui les exécute ainsi que l’ensemble des paramètresde l’action qui est représenté par une Hashmap. L’appel d’une action se fait par l’intermé-diaire de la méthode executeAction de la classe SWRLAgent. Le nom de l’action estpassé à la méthode ainsi que les paramètres (actionName et parameters). Une classeJAVA de type Class typée sur l’interface Action est instanciée à l’aide de la méthodeClass.forName du package java.lang.reflect. Une instance de l’action est en-suite créée par un appel à la méthode newInstance sur la classe précédemment créée.L’action est ensuite exécutée en appellant sa méthode run avec en argument l’agent cou-rant et les paramètres de la fonction. Le code JAVA de cette méthode executeActionest donné dans le listing 6.1.

Listing 6.1– executeAction de la classe SWRLAgent

1 protec ted synchronized void executeAct ion ( S t r i n g actionName ,2 HashMap<Str ing , Str ing > parameters ) {3

4 Class <Action > c l a s s e ;5 t r y {6 c l a s s e = ( Class <Action >) Class . forName ( " agent . core . a c t i o n s . " +

actionName + " Action " ) ;7 Action a c t = ( Action ) c l a s s e . newInstance ( ) ;


<<Java Interface>>Action

agent.core.actions

run(SWRLAgent,HashMap<String,String>): void

<<Java Class>>AskDFAction

agent.core.actions

run(SWRLAgent,HashMap<String,String>): void<<Java Class>>

CreateIndividualActionagent.core.actions

run(SWRLAgent,HashMap<String,String>): void<<Java Class>>RegisterDFActionagent.core.actions


<<Java Class>>SendMessageAction

agent.core.actions


<<Java Class>>SendBehaviourAction

agent.core.actions


<<Java Class>>SaveMemoryAction

agent.core.actions


<<Java Class>>DisplayValueAction

agent.core.actions


<<Java Class>>DeleteIndividualAction

agent.core.actions


<<Java Class>>ReceiveMessageAction

agent.core.actions


<<Java Class>>LoadBehaviourAction

agent.core.actions


<<Java Class>>ModifyIndividualAction

agent.core.actions


<<Java Class>>CheckConsistencyAction

agent.core.actions


<<Java Class>>RunQueryActionagent.core.actions


FIGURE 6.4 – Diagramme de classes des actions

Section 6.5. Base de connaissances 189

8 a c t . run ( t h i s , parameters ) ;9 } ca tch ( Exception e ) {

10 e . p r i n t S t a c k T r a c e ( ) ;11 }12 }

6.5 Base de connaissances

La base de connaissances avant l’exécution d’un agent se trouve dans deux fichiers,cette structure est héritée de la librairie AgentOWL qui différenciait les concepts etinstances dans deux fichiers séparés. Dans notre approche le comportement initial etle reste de la base de connaissances sont dans deux fichiers distincts. Les fichiers sontaccessibles soit par URI soit par leur emplacement local.

6.5.1 Base minimale

Dans les sections précédentes nous avons spécifié ou évoqué différents éléments dela base de connaissances. Nous listons ici les différentes classes, valeurs et propriétésrequises pour le fonctionnement de l’agent. Ces éléments constituent l’ontologie dumodèle de l’agent. Cette ontologie doit être importée dans la base de connaissances. Cesont les valeurs de ces ressources qui seront accédées et modifiées par l’interpréteurpour exécuter le comportement des agents.

Classes

Le modèle des agents SAM définit six classes (au sens OWL), qui sont les classesreprésentant les agents, les états, les valeurs des états, les actions, les comportements,les actions éxecutables. La classe agent décrit les agents évoluant dans la société. Dansl’implémentation l’agent possède une valeur (owl :hasValue) qui est son adresse dansla plate-forme JADE. Les états sont décrits par la classe State, la valeur de l’état estune chaîne de caractère. Deux valeurs sont spéciales, BEGIN et END qui spécifient lecommencement et la fin d’un comportement.

La classe Action décrit les actions de bas niveaux exécutables par l’interpréteur.La classe ExecAction est une classe similaire à Action, les valeurs des individusde ExecAction sont des individus de Action. Cette "copie" s’avère nécessaire pourpouvoir exécuter dans la même séquence d’action deux fois la même action avec desparamètres différents 5. La classe Behaviour représente les comportements des agents.

5. Prenons l’exemple d’envoi du même message à deux destinataires différents dans la même séquenced’actions. Il est nécessaire d’avoir deux instances de SendMessage possédant des paramètres différents.Pour cela nous avons introduit la classe ExecAction. Dans ce cas précis, les deux instances de ExecAtionont toutes deux la même valeur : SendMessage mais possèdent des paramètres différents.


Nom restriction Description

Agent Représente un agentState Prend une valeur de type String Etat au sens des EFSMAction Action de bas niveauBehaviour Prend une valeur de type String ComportementExecAction Même valeur que Action Action de bas niveau

A ces classes que nous avons définies, s’ajoutent les classes importées des ontologiesOWLList et FIPA-ACL (ontologie représentant les messages FIPA ACL).

Individus

Deux individus de la classe State sont nécessaires pour le fonctionnement. Cesont les états CurrentState et NextState. Le rôle de ces états est de donner lavaleur de l’état courant et celle de l’état suivant dans le cas ou une règle est active.Ces individus sont lus par l’interpréteur JAVA (dans la méthode chainRules) pourdéterminer l’exécution d’une transition. Les 19 actions décrites dans la partie précédentessont des individus de la classe Action. Il existe un comportement particulier qui est lecomportement courant de l’agent, représenté par CurrentBehaviour et qui prend sesvaleurs dans les individus de classe comportement. De la même manière il existe uneliste d’actions particulières : la liste des actions qui doivent être exécutées. Cette liste AL(pour ActionList) est un individu de la classe OWLList. Similairement, pour représenterla file de réception des messages, on utilise ML (pour MessageList) lui aussi individu dela classe OWLList.

Nom Classe Description

CurrentState StateNextState State{SendMessage,. . . } Actions L’ensemble des 19 actionsCurrentBehaviour Behaviour Comportement courantAL OWLList Liste des actions à exécuterML OWLList Liste des messageOUTPUT Object Résultat du traitement

Propriétés

Les propriétés nécessaires au fonctionnement d’un agent sont au nombre de trois.La propriété calledBy, de cardinalité 1, sert à représenter l’appel d’un comportementà un autre. La propriété behaviourLocation permet de donner l’emplacement d’uncomportement, soit par son chemin sur le disque, soit par URI. La dernière propriétéhasParameterName indique pour une action à exécuter le nom d’un paramètre, quidoit nécessairement pointer sur un individu, puisque ce dernier doit avoir pour valeur(hasValue) un littéral.

Section 6.6. Conclusion et discussion 191

Nom Départ Destination Description

calledBy Behaviour Behaviour Pile des appelsbehaviourLocation Behaviour String et URIreference Emplacement d’un comportementhasParameterName ExecAction Individu Nom du paramètre

6.6 Conclusion et discussion

La mise en œuvre du prototype a permis de valider l’approche théorique par uneréalisation simple. Les limitations sur les capacités d’échanges des agents (restriction auRDF) mises en évidence dans la section 2.5.1 ont été dépassées. La spécification d’unnombre fini d’actions de bas niveaux a permis de résoudre le problème de la dualité deslangages que présentaient les autres approches vues dans l’état de l’art. L’unification dela base de connaissances autour des formats OWL et SWRL et la programmation d’agentsà l’aide de ces langages permet l’échange de tout élément de la base de connaissances del’agent : comportement, communication, sécurité, cognition. Le langage de bas niveau,ici le JAVA est limité à la réalisation de l’interpréteur, le contenu (connaissance etcomportement) d’un agent est en OWL-DL et SWRL exclusivement. L’unification dela base de connaissances a été réalisé par l’unification des langages représentant lesdifférents composants initiaux, en alignant ces langages sur ceux de plus haut niveau, enl’occurrence OWL-DL et SWRL. En ce sens les objectifs concernant l’architecture d’agentont été atteints. Les connaissances justifiables et empiriques coexistent au sein de labase de la connaissance des agents et sont échangeables, les spécifications des chapitresprécédents ont ainsi été mises en œuvre.

Cette réalisation présente certaines limitations techniques. Les premières limitationslors du développement du prototype sont venus du raisonneur dont le support desfonction SWRL étaient alors (fin 2008) très limité. A l’époque certaines fonctions decomparaison avaient été implémenté en bas niveau. Le choix d’utilisation de Pellet s’estavéré payant puisque au fil des mois les fonctions SWRL ont une à une été intégrées àPellet (excepté quelques fonctions sur les dates et heures).

La gestion dynamique des messages au travers d’un second processus (MessageBehaviour)s’est imposé au cours des tests et n’avait pas été prévu lors de la phase de spécification.En effet le seul support de la réception par attente active limitait considérablement lespossibilités du prototype. La synchronisation de la file des messages a été réalisé demanière simple par l’utilisation d’un mutex sur l’ensemble de la file. Il est possible deréaliser un mécanisme de synchronisation plus efficace mais nettement plus fastidieux àmettre en œuvre en implémentant un mutex par message et en gérant la conservation dela structure de liste (en cas de suppression d’un message par exemple). Les performancesà un mutex étant largement satisfaisante pour les besoins de nos travaux, ce systèmepourra faire l’objet d’une implémentation dans une nouvelle version du prototype.


Une seconde limitation concerne la gestion des variables associées à un prototype.Pour des raisons de simplicité, toutes les variables de l’interpréteur sont globales, seull’état courant lors de l’appel à un autre comportement est sauvegardé. Il faudrait alorsétendre le modèle de l’agent pour associer un contexte d’exécution plus complet pourchaque comportement.

Concernant la validation de code, les propriétés des OWLList en réduisent consi-dérablement les possibilités. En effet, les implémentations de OWL-DL sont ici unfacteur limitant qui ne permet pas d’exclure les cycles des OWLList [Drummond06].Une séquence d’action peut-être cyclique et donc ne jamais terminer.

Certaines fonctions n’ont pas été (ou partiellement) implémentées. En particuliercertaines fonctions de la gestion d’ontologies qui n’étaient pas nécessaires au dévelop-pement de scénarios et de tests ont été écarté du développement pour des questionsde temps. Ce prototype se veut avant tout une preuve de concept, permettant de va-lider une approche, mais ne se veut en aucun cas comme un système fonctionnel dedéveloppement d’agent sémantique.

6.6.1 Perspectives

Au dela des limitations technique d’implémentation, le prochain défi du prototypeest de simplifier la programmation de comportement. En effet la programmtion decomportement sous forme SWRL est fastidieuse pour le programmeur d’agent. Leprincipe de machines à états finis permet de transformer un graphique représentant leprogramme directement en règles SAM. La génération automatique de code à partir degraphiques est la prochaine grande étape du projet. Nous pensons nous orienter vers ledéveloppement d’un plugin pour Eclipse pour réaliser cette tâche.

L’implémentation a permis de réaliser le transfert de connaissance empirique et devalider l’approche. Nous avons aussi pu mettre en œuvre l’ontologie des communautésvirtuelles de connaissances. Dans la continuité de nos travaux concernant l’efficacitédes communautés [Calmet06], il est maintenant intéressant de lancer de nouvellessimulations avec des agents qui disposent de la capacité d’échanges de protocoles descommunautés. Il est alors possible de lancer des expérimentations sur un cadre pluslarge, de comparer les différents types de communautés et détecter des convergeancesdans les modes de transmission des connaissances.

Les processus d’intéraction entre agents sont basiques et il serait intéressant d’inté-grer des travaux théoriques concernant les processus d’argumentation. Les travaux deAmgoud sur la sélection d’arguments basée sur la justification [Amgoud10] font écho aucadre théorique que nous avons défini. La réalisation du prototype SAM peut permettrede mettre en œuvre ces travaux théoriques.

Une sortie, c’est une entrée que l’on prend dans l’autre sens

Boris Vian

7Conclusion

194 Chapitre 7. Conclusion

Plan du chapitre

7.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

7.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

195

Cette thèse conclut avec une révision des travaux présentés et une évaluation desobjectifs proposés à l’issue de la présentation des scénarios motivants. La portée desrésultats principaux est résumée, les limites sont discutées et les directions pour destravaux futurs sont suggérées.

La gestion de connaissances au sein des organisations est un problème récent quia été abordé selon des perspectives diverses telles que l’informatique, la gestion desconnaissances, la psychologie . . .. Les recherches menées par Maret et Calmet sur lamodélisation des connaissances d’entreprises ont mis l’accent sur une approche informa-tique basée sur le paradigme agent afin de prendre en compte l’aspect décentralisé desconnaissances. Ces travaux ont abouti aux approches d’abstraction orientée agent (AOA)et de communautés virtuelles de connaissances (VKC). Dans la définition des VKCdonnée dans le premier chapitre, la base de connaissances des agents ne contient passeulement des ontologies, mais aussi trois autres composants (cognition, communicationet sécurité). Cependant, l’implémentation montre une différence de traitement entreles différents composants. En effet les ontologies sont les seules parties de la base deconnaissances qui sont échangeables entre les agents. Les trois autres composants sontprogrammés sont internes à l’agent et ne peuvent être échangés lors d’intéractions. Nousavons étudié dans cette thèse comment ces composants peuvent être mis en œuvre demanière à être échangéables entre les agents. L’échange de connaissances de nature à êtreexécutées par l’agent introduit de nouveaux problèmes de justification ou de validationde ces connaissances.

L’analyse de l’état de l’art a montré que l’utilisation des langages du web sémantiquepermettait la mise en place des deux types de connaissances (justifiables et empiriques)au sein d’une architecture d’agents. Tout d’abord nous avons établi le rapprochemententre le caracètre exécutable des connaissances empiriques (qui produisent une action)et les comportements des agents. L’architecture BDI qui établit un lien direct entreprocessus de décision, comportement et connaissance semblait toute indiquée pourremplir cette tâche. Cependant les tentatives infructueuses d’implémentation d’une tellearchitecture ont orienté notre choix sur une architecture basée autour des machinesétendues à état finis (EFSM). Nous avons ensuite montré que les langages OWL et SWRLpermettaient la réalisation d’une base de connaissances homogène permettant de décrireà la fois les connaissances justifiables et empiriques. L’utilisation d’un raisonneur uniquepour l’inférence des connaissances, la justification des deux types de connaissance ainsique l’exécution des comportements est alors possible.

Un modèle d’agent sémantique respectant ces spécifications a été conçu. Les connais-sances des deux types ont été représentés à l’aide du formalisme fourni par les standardsOWL et SWRL. Le langage de règles SWRL ne permettant la programmation d’agents,nous avons proposé une architecture en couches pour compléter avec les fonctionsrequises en terme de communication et de gestion de la base de connaissances. Pourcompléter ces fonctions, nous avons spécifié un nombre fini d’actions qui est commun


à tous les agents. L’utilisation d’un nombre fini d’action permet une interopérabilitécomplète entre les agents sémantiques en évitant le problème de double définition desactions (au niveau sémantique et opérationnel).

Ce modèle permettant d’échanger des connaissances exécutables, nous sommesrevenus au concept de VKC. Nous avons transformé l’utilisation des VKC en uneconnaissance échangeable entre les agents. Pour ce faire, nous avons formalisé le conceptde VKC, tout d’abord par une formalisation à l’aide de l’outil mathématique communque représentent les ensembles et relations. Pour compléter le lien entre cette formali-sation et les agents, nous avons défini une ontologie des commaunutés virtuelles deconnaissances qui est intégrable dans la base de connaissances des agents sémantiques.Dans la description formelle des communautés virtuelles de connaissances, nous avonsintroduit le concept de protocoles qui permet d’établir le lien avec les connaissanceséchangeables par les agents sémantiques. Nous représentons ces protocoles sous formesde règles interprétables par les agents SAM, afin de rendre opérationnelle l’utilisationdes communautés sous forme d’ontologie. Cette formalisation a aussi permet de rendrecompte d’un type plus large de VKC en ne se restreignant pas à l’implémentation pré-sentée dans les motivations mais en permettant de représenter un spectre plus large decommunautés.

Nous avons implémenté le modèle d’agent sémantique pour valider notre approche.Le code source du prototype est disponible en open source. La liste des publicationsconcernant nos travaux est donnée en annexe C.

7.1 Discussion

L’approche que nous proposons se base sur une consistance des connaissances. Uneconnaissance non consistante avec celles d’un agent sera rejeté par ce dernier. D’autresapproches proposent des bases de connaissances dont la consistance est locale, cesapproche dites multi-contexte [Giunchiglia93] permettraient des raisonnements sur desinconsistances en utilisant des logiques non monotones et des règles-pont (bridge rulesen anglais). Ces logiques non-monotones sont sous le feu des critiques des théoriciensdepuis leur introduction 1 [Girard07], et leurs fondations apparaissent pour le moinsinstables. Il faut donc approcher avec précaution ces logiques, nous avons choisi de leséviter. Notre système permet aux agents de posséder des connaissances qui sont incon-sistantes avec celles des autres agents, pour autant la transmission de ces connaissancesentre deux agents est alors impossible, le récepteur ne pouvant accepter d’inconsistancedans sa propre base.

L’aspect de la sécurité a été volontairement mis de côté tout au long de cette thèse.Les problématiques de confidentialité, de confiance dans les échanges sont des problé-

1. http://plato.stanford.edu/entries/logic-nonmonotonic/ cf conclusion

http://plato.stanford.edu/entries/logic-nonmonotonic/

Section 7.2. Perspectives 197

matiques importantes dans le domaine de la gestion des connaissances, notammentdans le cadre d’organisation ou l’accés aux données doit être restreint selon la place dansl’organisation. En effet lors de la transmission de connaissances empiriques, la connais-sance transmise sous forme d’une séquence d’actions et d’une propriété est alors testéepar le récepteur. Un agent doté de mauvaises pourrait alors transmettre une séquenced’actions malicieuses, de la même manière que les chevaux de troie se transmettent.Notre approche de la gestion des connaissances se situe en amont de ces problématiques,mais elles constituent un potentiel de développement futur des recherches, notammenten ce qui concerne les connaissances empiriques.

L’implémentation du prototype présente certaines limitations techniques. Pour desraisons de simplicité, toutes les variables de l’interpréteur sont globales, seul l’état cou-rant lors de l’appel à un autre comportement est sauvegardé. Il faudrait alors étendre lemodèle de l’agent pour associer un contexte d’exécution plus complet pour chaque com-portement. Concernant la validation de code, les propriétés des OWLList en réduisentconsidérablement les possibilités. En effet, les implémentations de OWL-DL sont ici unfacteur limitant qui ne permet pas d’exclure les cycles des OWLList [Drummond06].Une séquence d’action peut-être cyclique et donc ne jamais terminer. Certaines fonctionsn’ont pas été (ou partiellement) implémentées. En particulier certaines fonctions de lagestion d’ontologies qui n’étaient pas nécessaires au développement de scénarios et detests ont été écarté du développement pour des questions de temps. Ce prototype se veutavant tout une preuve de concept, permettant de valider une approche, mais ne se veuten aucun cas comme un système fonctionnel de développement d’agent sémantique.

7.2 Perspectives

L’implémentation que nous avons présenté dans cette thèse est une preuve de conceptqui démontre la faisabilité de notre approche. La difficulté de la programmation desagents sémantiques est dûe à l’absence d’une interface de développement intégrée.La meilleure approche selon nous consisterait en une une extension d’Eclipse pourpermettre au développeur de programmer visuellement les agents. Les actions étant ennombre fini, il est très simple de proposer une interface visuelle pour le développementrapide d’application utilisant des agents sémantiques. Une telle interface permettraitde réduire le temps de développement et autoriserait le développement d’applicationsmettant en œuvre un nombre plus large d’agents.

L’implémentation a permis de réaliser le transfert de connaissance empirique et devalider l’approche. Nous avons aussi pu mettre en œuvre l’ontologie des communautésvirtuelles de connaissances. Dans la continuité de nos travaux concernant l’efficacitédes communautés [Calmet06], il est maintenant intéressant de lancer de nouvellessimulations avec des agents qui disposent de la capacité d’échanges de protocoles des


communautés. Il est alors possible de lancer des expérimentations sur un cadre pluslarge, de comparer les différents types de communautés et détecter des convergeancesdans les modes de transmission des connaissances.

Les processus d’intéraction entre agents sont basiques et il serait intéressant d’inté-grer des travaux théoriques concernant les processus d’argumentation. Les travaux deAmgoud sur la sélection d’arguments basée sur la justification [Amgoud10] font écho aucadre théorique que nous avons défini. La réalisation du prototype SAM peut permettrede mettre en œuvre ces travaux théoriques.

Les connaissances acquises et les concepts développés au cours de cette thèse nousamène à revoir notre position sur la faisabilité d’une architecture BDI basée sur unraisonneur sémantique. Si les travaux théoriques de Moreira [Moreira06] n’ont pasabouti à une implémentation, nous avons une idée plus précise des problèmes qui ontpu être rencontrés. Le problème de la révision des croyances requiert une interventionexterne au raisonneur pour la suppression de croyances (problème aussi identifié par[Halaschek-Wiener06]), le second problème qui nous apparait est celui de l’activationdes plans. Les raisonneurs sémantiques ne privilégient pas de règles en particulier ettoutes les règles sont potentiellement activables, la représentation des plans sous formede règles SWRL par exemple est alors impossible. Nous pensons qu’il est possible decontourner cette difficulté par l’introduction d’un concept similaire aux états utilisésdans les EFSM, permettant la sélection d’un plan. Le troisième point qui doit être déve-loppé est l’intéraction entre le raisonneur et l’exécution des actions. A la différence denotre approche, nous pensons qu’il est nécessaire de développer une interface au sein duraisonneur, qui permet l’exécution d’action lors de la classification de ressources corres-pondantes à des actions. Cette interface permet la révision des croyances (interventionexterne sur la base de connaissances) et l’exécution des actions.

AAnnexe : Ontologie

200 Chapitre A. Annexe : Ontologie

Plan du chapitre

A.1 Ontologie sous forme d’expression . . . . . . . . . . . . . . . . . . . . 201

A.2 Ontologie au format N3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Section A.1. Ontologie sous forme d’expression 201

A.1 Ontologie sous forme d’expression

Classes

AP

AP v ∀ hasProtocol Protocols

AP v ∀ hasActions CommunityActions

AP v Thing

AP v ¬ Agent

AP v ¬ Roles

AP v ¬ Topic

AP v ¬ Protocols

AP v ¬ CommunityActions

AP v ¬ Community

Agent

Agent v ∀membershasroles Roles

Agent v ≥ 1 membershasroles Thing

Agent v Thing

Agent v ¬ Protocols

Agent v ¬ Roles

Agent v ¬ CommunityActions

Agent v ¬ Topic

Agent v ¬ AP

Agent v ¬ Community

Community

Community v Thing

Community v ∀ hasMember Agent

Community v ≥ 1 hasMember Thing

Community v ¬ Topic


Community v ¬ Roles

Community v ¬ CommunityActions

Community v ¬ Agent

Community v ¬ AP

Community v ¬ Protocols

CommunityActions

CommunityActions v ¬ Protocols

CommunityActions v ¬ Agent

CommunityActions v ¬ Community

CommunityActions v ¬ Roles

CommunityActions v ¬ Topic

CommunityActions v ¬ AP

LeaderAgent

LeaderAgent ≡ ∃membershasroles LeaderRole

LeaderAgent v Agent

LeaderRole

LeaderRole v Roles

Protocols

Protocols v ¬ CommunityActions

Protocols v ¬ Agent

Protocols v ¬ Roles

Protocols v ¬ Topic

Protocols v ¬ AP

Protocols v ¬ Community

Section A.1. Ontologie sous forme d’expression 203

Roles

Roles v Thing

Roles v ∀ hasAP AP

Roles v ¬ Community

Roles v ¬ Agent

Roles v ¬ Protocols

Roles v ¬ Topic

Roles v ¬ CommunityActions

Roles v ¬ AP

Thing

Topic

Topic v ¬ Community

Topic v ¬ Agent

Topic v ¬ Roles

Topic v ¬ Protocols

Topic v ¬ CommunityActions

Topic v ¬ AP

Propriétés d’objets

hasAP

∃ hasAP Thing v Roles

> v ∀ hasAP AP

hasActions

∃ hasActions Thing v AP

> v ∀ hasActions CommunityActions


hasMember

∃ hasMember Thing v Community

> v ∀ hasMember Agent

hasProtocol

∃ hasProtocol Thing v AP

> v ∀ hasProtocol Protocols

membershasroles

∃membershasroles Thing v Agent

> v ∀membershasroles Roles

A.2 Ontologie au format N3

@prefix protege: <http://protege.stanford.edu/plugins/owl/protege#> .@prefix xsp: <http://www.owl-ontologies.com/2005/08/07/xsp.owl#> .@prefix sqwrl: <http://sqwrl.stanford.edu/ontologies/built-ins/3.4/sqwrl.owl#> .@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .@prefix swrl: <http://www.w3.org/2003/11/swrl#> .@prefix default: <http://liris.cnrs.fr/~jsuberca/vkcs.owl#> .@prefix swrlb: <http://www.w3.org/2003/11/swrlb#> .@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .@prefix owl: <http://www.w3.org/2002/07/owl#> .@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .@prefix swrla: <http://swrl.stanford.edu/ontologies/3.3/swrla.owl#> .

[] a owl:AllDifferent .

default:APa owl:Class ;rdfs:comment "ActionProtocol"^^xsd:string ;rdfs:subClassOf owl:Thing ;rdfs:subClassOf

[ a owl:Restriction ;owl:allValuesFrom default:Protocols ;owl:onProperty default:hasProtocol

] ;rdfs:subClassOf

Section A.2. Ontologie au format N3 205

[ a owl:Restriction ;owl:allValuesFrom default:CommunityActions ;owl:onProperty default:hasActions

] ;owl:disjointWith default:Protocols , default:Community ,default:Roles , default:Agent , default:CommunityActions , default:Topic .

default:Communitya owl:Class ;rdfs:comment "Virtual Knowledge Community"^^xsd:string ;rdfs:subClassOf owl:Thing ;rdfs:subClassOf

[ a owl:Restriction ;owl:allValuesFrom default:Agent ;owl:onProperty default:hasMember

] ;rdfs:subClassOf

[ a owl:Restriction ;owl:minCardinality "1"^^xsd:int ;owl:onProperty default:hasMember

] ;owl:disjointWith default:Protocols , default:AP ,default:Roles , default:Agent , default:Topic , default:CommunityActions .

<./vkcs.owl>a owl:Ontology ;owl:imports <http://sqwrl.stanford.edu/ontologies/built-ins/3.4/sqwrl.owl> ,<http://swrl.stanford.edu/ontologies/3.3/swrla.owl> .

default:LeaderAgenta owl:Class ;rdfs:subClassOf default:Agent ;owl:equivalentClass

[ a owl:Restriction ;owl:onProperty default:membershasroles ;owl:someValuesFrom default:LeaderRole

] .

default:Topica owl:Class ;rdfs:comment "Topic of a community"^^xsd:string ;owl:disjointWith default:Protocols , default:AP ,default:Roles , default:Community , default:Agent , default:CommunityActions .

default:Protocolsa owl:Class ;


rdfs:comment "Protocols used to communicate between agents.A protocol is SAM Behaviour."^^xsd:string ;owl:disjointWith default:AP , default:Roles ,default:Community , default:Agent , default:Topic , default:CommunityActions .

default:hasProtocola owl:ObjectProperty ;rdfs:domain default:AP ;rdfs:range default:Protocols .

default:hasAPa owl:ObjectProperty ;rdfs:domain default:Roles ;rdfs:range default:AP .

default:Rolesa owl:Class ;rdfs:comment "Roles of agent in a given community"^^xsd:string ;rdfs:subClassOf owl:Thing ;rdfs:subClassOf

[ a owl:Restriction ;owl:allValuesFrom default:AP ;owl:onProperty default:hasAP

] ;owl:disjointWith default:Protocols , default:AP ,default:Community , default:Agent , default:Topic , default:CommunityActions .

default:membershasrolesa owl:ObjectProperty ;rdfs:domain default:Agent ;rdfs:range default:Roles .

default:Agenta owl:Class ;rdfs:subClassOf owl:Thing ;rdfs:subClassOf

[ a owl:Restriction ;owl:allValuesFrom default:Roles ;owl:onProperty default:membershasroles

] ;rdfs:subClassOf

[ a owl:Restriction ;owl:minCardinality "1"^^xsd:int ;owl:onProperty default:membershasroles

] ;owl:disjointWith default:Protocols , default:AP ,

Section A.2. Ontologie au format N3 207

default:Roles , default:Community , default:Topic , default:CommunityActions .

default:hasMembera owl:ObjectProperty ;rdfs:domain default:Community ;rdfs:range default:Agent .

default:hasActionsa owl:ObjectProperty ;rdfs:domain default:AP ;rdfs:range default:CommunityActions .

default:LeaderRolea owl:Class ;rdfs:subClassOf default:Roles .

default:CommunityActionsa owl:Class ;rdfs:comment "Actions that can be executed in the community"^^xsd:string ;owl:disjointWith default:Protocols , default:AP ,default:Roles , default:Community , default:Agent , default:Topic .

BAnnexe : Langages de communication agents

210 Chapitre B. Annexe : Langages de communication agents

Plan du chapitre

B.1 Langages de programmation agents . . . . . . . . . . . . . . . . . . . . 211

Section B.1. Langages de programmation agents 211

B.1 Langages de programmation agents

Les langages de programmtion d’agents permettent de développer le comportementd’agents autonomes. Pour que ces agents soient capables d’intéragir entre eux, sans sesoucier du langage de programmation utilisé, il faut que ces agents soient dotés d’unlangage de communication commun. Deux langages de communication ACL pour AgentCommunication Language en anglais, ont été développé. Ces deux langages, KQML (pourKnowledge Query and Manipulation Language) et FIPA-ACL sont tous deux baséssur la théorie des actes de langages du philosophe américain John Searle. Dans ceslangages, les agents échangent des messages qui sont caractérisés par leurs performatifs.Un performatif est un acte de communication, comme par exemple demander, informer,répondre, . . ..

B.1.0.1 KQML

Le langage KQML 1 a été developpé par un comité mis en place par le DARPA(Defense Advanced Research Projects Agency) dans le cadre du projet d’échanges desconnaissances Knowledge Sharing Effort 2. Initialement le KQML devait être un langaged’échanges de connaissances, comme par exemple KIF (Knowledge Interchange Format)[Genesereth92]. KQML a ensuite été proposé comme langages de communicationsd’agents [Finin94].

Un message KQML doit contenir au moins les éléments suivants :– Une performative qui indique la nature de l’acte de communication– Une ontologie à laquelle se réfère le contenu– Un contenuUn exemple de message KQML avec la performative ask-all (demande à tous les

agents) :

(ask-all

:content ‘‘geoloc(lax,(Long,Lat))’’

:language standard_prolog

:ontology geo-model3)

Le langage KQML a été utilisé avec succés dans de nombreuses applications 3. Il estmaintenant délaissé au profit de son successeur, le FIPA-ACL.

1. http://www.cs.umbc.edu/KQML/kqmlspec.ps2. http://ebiquity.umbc.edu/_file_directory_/papers/280.pdf3. http://www-ksl.stanford.edu/knowledge-sharing/agents.html

http://www.cs.umbc.edu/KQML/kqmlspec.ps

http://ebiquity.umbc.edu/_file_directory_/papers/280.pdf

http://www-ksl.stanford.edu/knowledge-sharing/agents.html

212 Chapitre B. Annexe : Langages de communication agents

B.1.0.2 FIPA-ACL

La FIPA (Foundations for Intelligent Agents) 4, initialement une association à butnon lucratif fondée qui est maintenant devenue un comité de standards de l’IEEE aproposé de nombreux standards pour les agents et plus particulièrement un standard delangages de communication qui a été adopté par de nombreuses plates-formes.

Le tableau B.1 montre les différents champs qui composent un message.

Parameter Category of Parametersperformative Type of communicative actssender Participant in communicationreceiver Participant in communicationreply-to Participant in communicationcontent Content of messagelanguage Description of Contentencoding Description of Contentontology Description of Contentprotocol Control of conversationconversation-id Control of conversationreply-with Control of conversationin-reply-to Control of conversationreply-by Control of conversation

TABLE B.1 – Paramètres des messages FIPA ACL

Les messages FIPA-ACL comportent nettement plus de champ et permettent l’élabo-ration de protocoles complexes entre agents, comme par exemple le CONTRACT-NET[Smith80].

4. http://www.fipa.org

http://www.fipa.org

CAnnexe : Liste des publications

Liste de publications

[1] Julien Subercaze and Pierre Maret. Sam : Semantic agent model for swrlrule-based agents. In INSTICC Press 2010, editor, ICAART 2010, Proceed-ings of the International Conference on Agents and Artificial Intelligence,Volume 2 - Agents, pages 244–248, January 2010.

[2] Julien Subercaze and Pierre Maret. Semantic Agent Systems - Foundationsand Applications, , chapter Programming Semantic Agent for DistributedKnowledge Management. Springer Verlag, November 2010.

[3] Christo Elmorr and Julien Subercaze. Handbook of Research on Develop-ments in e-Health and Telemedicine: Technological and Social Perspectives,chapter Knowledge Management in Health care., December 2009.

[4] Christo El Morr, Julien Subercaze, Marcia Rioux, and Mihaela Dinca-Panaitescu. Virtual knowledge network for human rights monitoring. InWorkshop on Web Intelligence and Virtual Enterprises (WIVE09), 10thIFIP Working Conference on Virtual Entreprises (PRO-VE09), October2009.

[5] Julien Subercaze, Christo El Morr, Pierre Maret, Adrien Joly, MattiKoivisto, Panayotis Antoniadis, and Masayuki Ihara. Towards successfulvirtual communities. In International Conference on Enterprise Informa-tion Systems, Lecture Notes in Business Information Processing, pages 677–688, . Springer Berlin Heidelberg, May 2009.

[6] Christo Elmorr, Julien Subercaze, Pierre Maret, and Marcia Rioux. A vir-tual knowledge community for human rights monitoring for people with dis-abilities. In Piet Kommers, editor, IADIS International Conference WBC2008, pages 78–84, July 2008.

[7] Pierre Maret, Julien Subercaze, and Jacques Calmet. Peer to peer modelfor virtual knowledge communities. In AIKED’08, pages 365–370, March2008.

[8] Pravin Pawar, Julien Subercaze, Pierre Maret, Bert-Jan van Beijnum, andDimitri Konstantas. Towards business model and technical platform forthe service oriented context-aware mobile virtual communities. In IEEESymposium on Computers and Communications ISCC, pages 103–110, .IEEE Computer Society Press, July 2008.

[9] Julien Subercaze, Pravin Pawar, Pierre Maret, and Jacques Calmet. Aservice oriented framework for mobile business virtual communities. InWilly Picard Luis M. Camarinha-Matos, editor, Virtual Enterprises andCollaborative Networks, pages 493–500, . Springer, September 2008.

[10] Julien Subercaze, Pierre Maret, Ngoc Minh Dang, and Ken Sasaki.Context-aware applications using personal sensors. In Social-Informatics

ICST (Institute for Computer Sciences and Telecommunications Engineer-ing), editors, BodyNets ’07: Proceedings of the ICST 2nd internationalconference on Body area networks, pages 1–5, July 2007.

[11] Jacques Calmet, Julien Subercaze, and Pierre Maret. Simulation in virtualknowledge communities. In Angel Oropeza Freddy Mapica, editor, Socialand Organizational Informatics and Cybernetics, pages 238–242, July 2006.

Bibliographie

[ACL-FIPAml] ACL-FIPA. Fipa personal assistant specification (2000). FIPA,http ://www.fipa.org/specs/fipa00083/XC00083B.html. 29, 35

[Alavi99] Maryam Alavi & Dorothy Leidner. Knowledge Management Sys-tems : Emerging Views and Practices from the Field. Hawaii Inter-national Conference on System Sciences, vol. 7, page 7009, IEEEComputer Society, Los Alamitos, CA, USA, 1999. 68

[Amgoud10] Leila Amgoud & Srdjan Vesic. Handling Inconsistency withPreference-Based Argumentation. In Amol Deshpande & AnthonyHunter, editeurs, SUM, volume 6379 of Lecture Notes in ComputerScience, pages 56–69. Springer, 2010. 192, 198

[Ancona04a] D. Ancona & V. Mascardi. Coo-BDI : Extending the BDI modelwith cooperativity. Lecture Notes in Computer Science, vol. 2990,pages 109–134, Springer, 2004. 94, 98

[Ancona04b] D. Ancona, V. Mascardi, J.F. Hubner & R.H. Bordini. Coo-AgentSpeak : Cooperation in AgentSpeak through plan exchange. InProceedings of the Third International Joint Conference on Au-tonomous Agents and Multiagent Systems-Volume 2, page 705.IEEE Computer Society, 2004. 94, 132

[Anicic07] N. Anicic, N. Ivezic & A. Jones. An architecture for semanticenterprise application integration standards. Interoperability of En-terprise Software and Applications, pages 25–34, Springer, 2007.79

[Bachimont96] M.B. Bachimont. Hermeneutique ma erielle et Artefacture : des ma-chines qui pensent aux machines qui donnent a penser. Doctorat,Ecole polytechnique - Service d’Informatique Médicale de l’As-sistance Publique, 1996. 64

[Balmisse02] G. Balmisse. Gestion des connaissances(outils et applications duknowledge management). Entreprendre. Informatique, Vuibert,2002. 65

[Barclay97] R.O. Barclay & P.C. Murray. What is knowledge management. Know-ledge Praxis, vol. 19, 1997. 18

218 BIBLIOGRAPHIE

[Bellifemine99] F. Bellifemine, A. Poggi & G. Rimassa. JADE–A FIPA-compliantagent framework. In Proceedings of PAAM, volume 99, pages97–108. Citeseer, 1999. 29, 35, 108

[Berners-Lee00] T. Berners-Lee & D. Connolly. CWM-closed world machine. In-ternet : http ://www. w3. org/2000/10/swap/doc/cwm. html,2000. 103

[Biegel04] Gregory Biegel & Vinny Cahill. A Framework for Developing Mo-bile, Context-aware Applications. percom, vol. 00, page 361, IEEEComputer Society, Los Alamitos, CA, USA, 2004. 32

[Boissier01] O. Boissier. Modèles et architectures d’agents. Principes et architec-tures des systèmes multi-agents, pages 71–107, 2001. 85

[Boley01] Harold Boley, Said Tabet & Gerd Wagner. Design Rationale forRuleML : A Markup Language for Semantic Web Rules. In Isabel F.Cruz, Stefan Decker, Jérôme Euzenat & Deborah L. McGuinness,editeurs, SWWS, pages 381–401, 2001. 79

[Bonifacio02a] M. Bonifacio, P. Bouquet & P. Traverso. Enabling distributed know-ledge management : Managerial and technological implications. No-vatica and Informatik/Informatique, page 23, Citeseer, 2002. 11,69, 70

[Bonifacio02b] M. Bonifacio, R. Cuel, G. Mameli & M. Nori. A peer-to-peer ar-chitecture for distributed knowledge management. In Proceedingsof the 3rd International Symposium on Multi-Agent Systems,Large Complex Systems, and E-Businesses (MALCEB’02). Cite-seer, 2002. 69

[Bonifacio02c] Matteo Bonifacio, Paolo Bouquet & Roberta Cuel. KnowledgeNodes : the Building Blocks of a Distributed Approach to Knowledge.J. of Universal Computer Science, vol. 8, no. 6, pages 652–661,2002. 69

[Bonifacio03] Matteo Bonifacio, Paolo Bouquet, Gianluca Mameli & MicheleNori. Peer-Mediated Distributed Knowledge Management. In vanElst et al. [van Elst04a], pages 31–47. 12, 19, 114, 115

[Bordini05a] R. Bordini, J. H"ubner & R. Vieira. Jason and the Golden Fleece of agent-orientedprogramming. Multi-Agent Programming, pages 3–37, Springer,2005. 98

[Bordini05b] R.H. Bordini. Multi-agent programming : languages, platforms,and applications. Springer, 2005. 96

[Bordini07] R. Bordini, J. H"ubner & D. Tralamazza. Using Jason to implement a team of gold

BIBLIOGRAPHIE 219

miners. Computational Logic in Multi-Agent Systems, pages304–313, Springer, 2007. 98

[Boswell05] J. Boswell. The Life of Samuel Johnson. Kessinger Publishing,2005. 64

[Bryl06] Volha Bryl, Paolo Giorgini & Stefano Fante. ToothAgent : A Multi-agent System for Virtual Communities Support. In AOIS, pages212–230, 2006. 113

[Buhler03] P. Buhler & J.M. Vidal. Semantic web services as agent behaviors.Agentcities : Challenges in Open Agent Environments, pages25–31, Springer-Verlag, 2003. 107

[Calmet04] Jacques Calmet, Pierre Maret & Regine Endsuleit. Agent-orientedabstraction. Academia de Ciencias, Serie "A" de Matemeticas,vol. 98, December 2004. 23, 25, 26, 112

[Calmet06] Jacques Calmet, Julien Subercaze & Pierre Maret. Simulationin Virtual Communities. In Proceeding of the Social and Orga-nizational Informatics and Cybernetics (SOIC) conference 2006,Orlando, Florida, USA, pages 238–242, 2006. 162, 192, 197

[Capuano00] N. Capuano, M. Marsella & S. Salerno. ABITS : An agent basedIntelligent Tutoring System for distance learning. In Proceedings ofthe International Workshop in Adaptative and Intelligent Web-based Educational Systems. Available at http ://virtcampus.cl-ki. uni-osnabrueck. de/its-2000, pages 17–28, 2000. 12, 118,119

[Chen04] Wei Chen & Keith S. Decker. The Analysis of Coordination in anInformation System Application - Emergency Medical Services. InPaolo Bresciani, Paolo Giorgini, Brian Henderson-Sellers, Gra-ham Low & Michael Winikoff, editeurs, AOIS, volume 3508 ofLecture Notes in Computer Science, pages 36–51. Springer, 2004.113

[Cheng93] K.T. Cheng & AS Krishnakumar. Automatic functional test genera-tion using the extended finite state machine model. In Proceedings ofthe 30th international conference on Design automation, pages86–91. ACM New York, NY, USA, 1993. 125

[Clark01] K. Clark, P.J. Robinson & R. Hagen. Multi-threading and messagecommunication in Qu-Prolog. Theory and Practice of Logic Pro-gramming, vol. 1, no. 03, pages 283–301, Cambridge Univ Press,2001. 107

[Cobo07] P. Cobo, J.M. Fortuny, E. Puertas & P.R. Richard. AgentGeom : amultiagent system for pedagogical support in geometric proof problems.

220 BIBLIOGRAPHIE

International Journal of Computers for Mathematical Learning,vol. 12, no. 1, pages 57–79, Springer, 2007. 118, 119

[Corby00] O. Corby, R. Dieng & C. Hébert. A conceptual graph model for w3cresource description framework. Lecture notes in computer science,pages 468–482, Springer, 2000. 118

[Corby04] O. Corby, R. Dieng-Kuntz & C. Faron-Zucker. Querying the se-mantic web with corese search engine. In ECAI, volume 16, page705, 2004. 114

[Costantini92] S. Costantini, P. Dell’Acqua & G. Lanzarone. Reflective agents inmetalogic programming. Lecture notes in computer science, pages135–135, Springer, 1992. 93

[Damasio06] C.V. Damasio, A. Analyti, G. Antoniou & G. Wagner. Suppor-ting open and closed world reasoning on the web. Lecture notes incomputer science, vol. 4187, page 149, Springer, 2006. 19

[Davenport99] T.H. Davenport, D.W. De Long & M.C. Beers. Successful knowledgemanagement projects. The Knowledge Management Yearbook1999-2000, pages 89–107, Butterworth-Heinemann, 1999. 51

[Davenport00] T.H. Davenport & L. Prusak. Working knowledge : How organiza-tions manage what they know. Ubiquity, vol. 1, no. 24, ACM NewYork, NY, USA, 2000. 64, 65

[Decker98] Stefan Decker, Michael Erdmann, Dieter Fensel & Rudi Stu-der. Ontobroker : Ontology based Access to Distributed and Semi-Structured Information. pages 351–369, Kluwer Academic Publi-sher, 1998. 75

[Dickinson03] I. Dickinson & M. Wooldridge. Towards practical reasoning agentsfor the semantic web. In Proceedings of the second internationaljoint conference on Autonomous agents and multiagent systems,pages 827–834. ACM New York, NY, USA, 2003. 11, 104, 105, 106,178, 182

[Dikenelli05] O. Dikenelli, R.C. Erdur & O. Gumus. Seagent : a platform for de-veloping semantic web based multi agent systems. In Proceedings ofthe fourth international joint conference on Autonomous agentsand multiagent systems, page 1272. ACM, 2005. 110

[Drummond06] N. Drummond, A. Rector, R. Stevens, G. Moulton, M. Horridge,H. Wang & J. Seidenberg. Putting OWL in order : Patterns forsequences in OWL. In Proc. 2nd Workshop on OWL : Experiencesand Directions. Citeseer, 2006. 143, 178, 182, 192, 197

BIBLIOGRAPHIE 221

[Ehrig03] Marc Ehrig, Christoph Tempich, Jeen Broekstra, Frank van Har-melen, Marta Sabou, Ronny Siebes, Steffen Staab & Heiner Stu-ckenschmidt. SWAP : Ontology-based Knowledge Management withPeer-to-Peer Technology. In Wissensmanagement, pages 17–20,2003. 19, 68, 69, 120

[El Morr07] C. El Morr & J. Kawash. Mobile virtual communities research : asynthesis of current trends and a look at future perspectives. Interna-tional Journal of Web Based Communities, vol. 3, no. 4, pages386–403, Inderscience, 2007. 49

[El Morr09] Christo El Morr, Julien Subercaze, Marcia Rioux & MihaelaDinca-Panaitescu. Virtual Knowledge Network for Human RightsMonitoring. In Workshop on Web Intelligence and Virtual En-terprises (WIVE’09), 10th IFIP Working Conference on VirtualEntreprises (PRO-VE’09), October 2009. 23, 48

[ElMorr07] Christo ElMorr & Jalal Kawash. Mobile virtual communities re-search&#58 ; a synthesis of current trends and a look at future perspec-tives. Int. J. Web Based Communities, vol. 3, no. 4, pages 386–403,Inderscience Publishers, Inderscience Publishers, Geneva, SWIT-ZERLAND, 2007. 39

[Elmorr08] Christo Elmorr, Julien Subercaze, Pierre Maret & Marcia Rioux.A Virtual Knowledge Community for Human Rights Monitoring forPeople with Disabilities. In Piet Kommers, editeur, IADIS Interna-tional Conference WBC 2008, pages 78–84, July 2008. 23, 48

[Farooq02] U. Farooq, PL Isenhour, J.M. Carroll & M.B. Rosson. MOOs-burg++ : Moving towards a wireless virtual community. In Procee-dings of the 2002 International Conference on Wireless Networks,2002. 40

[Ferber89] J. Ferber. Objets et agents : une étude des structures de représentationet de communications en Intelligence Artificielle. Th ese d’infor-matique, Universit e Pierre et Marie Curie, Paris, vol. 6, 1989.18

[Finin94] T. Finin, R. Fritzson, D. McKay & R. McEntire. KQML as an agentcommunication language. In Proceedings of the third internationalconference on Information and knowledge management, page463. ACM, 1994. 83, 131, 211

[FIPA02] TC FIPA. Architecture Group, FIPA Abstract Architecture Specifica-tion. Rapport technique, Tech. Rep. XC00001K, Foundation forIntelligent Physical Agents, Geneva, Switzerland, 2002. 107

222 BIBLIOGRAPHIE

[Fox00] M.S. Fox, M. Barbuceanu & R. Teigen. Agent-oriented supply-chainmanagement. International Journal of Flexible ManufacturingSystems, vol. 12, no. 2, pages 165–188, Springer, 2000. 87

[Gaborit96] P. Gaborit. Planification distribuée pour la coopération multi-agents.1996. 87

[Gandon02] Fabien Gandon. Distributed Artificial Intelligence and KnowledgeManagement : ontologies and multi-agent systems for a corporatesemantic web. Doctorat, INRIA and University of Nice - SophiaAntipolis, 2002. 11, 113

[Ganek03] A.G. Ganek & T.A. Corbi. The dawning of the autonomic computingera. IBM Systems Journal, vol. 42, no. 1, pages 5–18, IBM Corp.,2003. 88

[Gellersen02] Hans W. Gellersen, Albercht Schmidt & Michael Beigl. Multi-sensor context-awareness in mobile devices and smart artifacts. Mob.Netw. Appl., vol. 7, no. 5, pages 341–351, Kluwer AcademicPublishers, Hingham, MA, USA, 2002. 32

[Genesereth92] M.R. Genesereth, R.E. Fikeset al. Knowledge interchange format,version 3.0 reference manual, 1992. 211

[Georgeff89] M.P. Georgeff & F.F. Ingrand. Decision-making in an embeddedreasoning system. In Proceedings of the Eleventh InternationalJoint Conference on Artificial Intelligence (IJCAI-89), pages 972–978, 1989. 11, 92

[Gettier63] E.L. Gettier. Is justified true belief knowledge ? Analysis, vol. 23,no. 6, page 121, 1963. 63

[Girard07] J.Y. Girard. Le point aveugle : Cours de logique : Tome 1, vers laperfection. Hermann, Paris, 280p, 2007. 72, 196

[Giunchiglia93] E. Giunchiglia, P. Traverso & F. Giunchiglia. Multi-context systemsas a specification framework for complex reasoning systems. J. Treur,Th. Wetter (eds.), Formal specification of complex reasoningsystems, Ellis Horwood, pages 45–72, 1993. 196

[Goldman86] A.I. Goldman. Epistemology and cognition. Harvard Univ Pr,1986. 63

[Gruber93] T.R. Gruberet al. A translation approach to portable ontology specifi-cations. Knowledge acquisition, vol. 5, pages 199–199, AcademicPress, 1993. 72

[Haarslev07] V. Haarslev, R. M"oller & M. Wessel. RacerPro User’s Guide and Reference ManualVersion 1.9. 1, 2007. 79

BIBLIOGRAPHIE 223

[Haase05] Peter Haase, Björn Schnizler, Jeen Broekstra, Marc Ehrig, Frankvan Harmelen, Maarten Menken, Peter Mika, Michal Plechawski,Pawel Pyszlakand Ronny Siebes, Steffen Staab & Christoph Tem-pich. Bibster — A Semantics-Based Bibliographic Peer-to-Peer System.Journal of Web Semantics, vol. 2, no. 1, 2005. 120

[Halaschek-Wiener06] C. Halaschek-Wiener, Y. Katz & B. Parsia. Belief base revision forexpressive description logics. OWL : Experiences and Directions,vol. 2006, Citeseer, 2006. 198

[Heflin00] J. Heflin & J. Hendler. Searching the Web with SHOE. In AAAI-2000 Workshop on AI for Web Search, pages 35–40, 2000. 73

[Henricksen04] Karen Henricksen & Jadwiga Indulska. A Software EngineeringFramework for Context-Aware Pervasive Computing. Percom, vol. 00,page 77, IEEE Computer Society, Los Alamitos, CA, USA, 2004.32

[Hesselman06] C. Hesselman, A. Tokmakoff, P. Pawar & S. Iacob. Discovery andcomposition of services for context-aware systems. Smart Sensingand Context, pages 67–81, Springer, 2006. 45

[Hey04] J. Hey. The data, information, knowledge, wisdom chain : The metapho-rical link. Relatório técnico, Intergovernmental OceanographicCommission (UNESCO), 2004. 65

[Hindriks99] K.V. Hindriks, F.S. De Boer, W. Van der Hoek & J.J.C. Meyer.Agent programming in 3APL. Autonomous Agents and Multi-Agent Systems, vol. 2, no. 4, pages 357–401, Springer, 1999. 11,102

[Horn01] P. Horn. Autonomic computing : IBM’s perspective on the state ofinformation technology. IBM TJ Watson Labs, NY, 15th October,2001. 88

[Horrocks03] I. Horrocks, P.F. Patel-Schneider & F. Van Harmelen. From SHIQand RDF to OWL : The making of a web ontology language. Websemantics : science, services and agents on the World Wide Web,vol. 1, no. 1, pages 7–26, Elsevier, 2003. 78

[Horrocks04] I. Horrocks, P.F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof &M. Dean. SWRL : A semantic web rule language combining OWLand RuleML. W3C Member Submission, vol. 21, 2004. 79, 141

[Hustadt94] U. Hustadt. Do we need the closed world assumption in knowledgerepresentation. In Proc. of the 1st Workshop KRDB, volume 94.Citeseer, 1994. 71

224 BIBLIOGRAPHIE

[Jansen02] W. Jansen, GCA Steenbakkers, HPM Jagers & M. Khosrowpour.Knowledge management and virtual communities. Knowledge map-ping and management, page 281, Irm Pr, 2002. 49

[Jennings98] N.R. Jennings, K. Sycara & M. Wooldridge. A roadmap of agentresearch and development. Autonomous agents and multi-agentsystems, vol. 1, no. 1, pages 7–38, Springer, 1998. 85

[Katasonov08] A. Katasonov & V. Terziyan. Semantic agent programming language(S-APL) : A middleware platform for the Semantic web. In Proc. 2ndIEEE International Conference on Semantic Computing, pages504–511, 2008. 11, 103, 104

[Kawash05] J. Kawash, C. El Morr, W. Charaf & H. Taha. Building MobileVirtual Communities for Public Transport Awarness. In 2005 2ndInternational Conference on Mobile Technology, Applicationsand Systems, pages 1–7, 2005. 40, 49

[Kephart03] J.O. Kephart & D.M. Chess. The vision of autonomic computing.Computer, pages 41–50, IEEE Computer Society, 2003. 88

[Klapiscak09] T. Klapiscak & R. Bordini. JASDL : A practical programming ap-proach combining agent and semantic web technologies. DeclarativeAgent Languages and Technologies VI, pages 91–110, Springer,2009. 11, 99, 100

[Klyne04] G. Klyne, J.J. Carroll & B. McBride. Resource description frame-work (RDF) : Concepts and abstract syntax. W3C recommendation,vol. 10, 2004. 77

[Laclavik06a] Michal Laclavik, Marian Babik, Zoltan Balogh, Emil Gatial &Ladislav Hluchý. Semantic Knowledge Model and Architecture forAgents in Discrete Environments. In ECAI, pages 727–728, 2006.109, 178

[Laclavik06b] Michal Laclavik, Zoltan Balogh, Marian Babik & Ladislav Hlu-chý. AgentOWL : Semantic Knowledge Model and Agent Architecture.Computers and Artificial Intelligence, vol. 25, no. 5, 2006. 19,103, 178

[Lacy04] L. Lacy & W. Gerber. Potential modeling and simulation applicationsof the web ontology language-OWL. In Proceedings of the 36thconference on Winter simulation, page 270. Winter SimulationConference, 2004. 79

[Lacy05] L. Lacy, G. Aviles, K. Fraser, W. Gerber, A. Mulvehill & R. Gaskill.Experiences using OWL in military applications. In Proc. of the FirstOWL Experiences and Directions Workshop, volume 188, 2005.79

BIBLIOGRAPHIE 225

[Leimeister04] J.M. Leimeister & H. Krcmar. Revisiting the virtual communitybusiness model. In Proceedings of the Tenth Americas Conferenceon Information Systems. Citeseer, 2004. 39, 43

[Loke98] S.W. Loke & A. Davison. LogicWeb : Enhancing the web with logicprogramming. The Journal of Logic Programming, vol. 36, no. 3,pages 195–240, Elsevier, 1998. 75

[Ma08] Zongmin Ma & Huaiqing Wang. The semantic web for know-ledge and data management : Technologies and practices. Infor-mation Science Reference - Imprint of : IGI Publishing, Hershey,PA, 2008. 80

[Machado99] I. Machado, A. Martins & A. Paiva. One for all and all in one : alearner modelling server in a multi-agent platform. In Proceedingsof the seventh international conference on User modeling tableof contents, pages 211–221. Springer-Verlag New York, Inc. Se-caucus, NJ, USA, 1999. 118

[Maret04a] Pierre Maret & Jacques Calmet. Modeling Corporate Knowledgewithin the Agent Oriented Abstraction. In CW, pages 224–231. IEEEComputer Society, 2004. 23, 25

[Maret04b] Pierre Maret, Mark Hammond & Jacques Calmet. Virtual Know-ledge Communities for Corporate Knowledge Issues. In Marie PierreGleizes, Andrea Omicini & Franco Zambonelli, editeurs, ESAW,volume 3451 of Lecture Notes in Computer Science, pages 33–44.Springer, 2004. 23, 25, 35, 87, 170

[Martinez01] M. T. Martinez, P. Fouletier, K. H. Park & J. Favrel. Virtual en-terprise - organisation, evolution and control. International Journalof Production Economics, vol. 74, no. 1-3, pages 225 – 238, 2001.117

[Mascardi05] Viviana Mascardi, Daniela Demergasso & Davide Ancona. Lan-guages for Programming BDI-style Agents : an Overview, 2005. 92

[Merali01] Y. Merali & J. Davies. Knowledge capture and utilization in virtualcommunities. In Proceedings of the 1st international conferenceon Knowledge capture, page 99. ACM, 2001. 49

[Modi04] Pragnesh Jay Modi, Manuela Veloso, Stephen F. Smith & Jean Oh.CMRadar : A Personal Assistant Agent for Calendar Management. InIn Agent Oriented Information Systems, (AOIS, pages 134–148,2004. 113

[Moreira06] Á. Moreira, R. Vieira, R. Bordini & J. H"ubner. Agent-oriented programming with underlying ontological

226 BIBLIOGRAPHIE

reasoning. Declarative Agent Languages and Technologies III,pages 155–170, Springer, 2006. 99, 125, 198

[Norman04] T.J. Norman, A. Preece, S. Chalmers, N.R. Jennings, M. Luck, V.D.Dang, T.D. Nguyen, V. Deora, J. Shao, W.A. Grayet al. Conoise :Agent-based formation of virtual organisations. Knowledge-BasedSystems, vol. 17, no. 2-4, pages 103–111, 2004. 12, 116

[Norvig03] P. Norvig & SJ Russell. Artificial intelligence : a modern approach.Prentice Hall, 2003. 86

[Novák08a] P. Novák. Jazzyk : A programming language for hybrid agents withheterogeneous knowledge representations. In Sixth InternationalWorkshop on Programming Multi-Agent Systems. Springer, 2008.106

[Novak08b] P. Novak, D. Mainzer, M. Koster & B. Fuhrmann. Jazzbot : A non-monotonically reasoning bot in a simulated 3D environment. 2008.106

[Pacherie04] É. Pacherie & J. Proust. Philosophie cognitive. Editions MSH,2004. 63

[Pankratius04] V. Pankratius, O. Sandel & W. Stucky. Retrieving content withagents in web service e-learning systems. In IFIP Symposium onProfessional Practice in AI, IFIP WG12, volume 5, 2004. 118

[Parsia05] B. Parsia, E. Sirin, B.C. Grau, E. Ruckhaus & D. Hewlett. Cau-tiously Approaching SWRL. Rapport technique, Technical report,University of Maryland, 2005. 79

[Patel05] J. Patel, W.T.L. Teacy, N.R. Jennings, M. Luck, S. Chalmers,N. Oren, T.J. Norman, A. Preece, P.M.D. Gray, G. Shercliffet al.Monitoring, policing and trust for grid-based virtual organisations.In Proc. of the UK e-Science All Hands Meeting, pages 891–898,2005. 117

[Patel06] Jigar Patel, W. T. Luke Teacy, Nicholas R. Jennings, Michael Luck,Stuart Chalmers, Nir Oren, Timothy J. Norman, Alun D. Preece,Peter M. D. Gray, Gareth Shercliff, Patrick J. Stockreisser, JianhuaShao, W. Alex Gray, N. J. Fiddian & Simon Thompson. CONOISE-G : agent-based virtual organisations. In Hideyuki Nakashima,Michael P. Wellman, Gerhard Weiss & Peter Stone, editeurs, AA-MAS, pages 1459–1460. ACM, 2006. 116, 117

[Pawar07] P. Pawar, S. Srirama, B.J. van Beijnum & A. van Halteren. A Com-parative Study of Nomadic Mobile Service Provisioning Approaches.

BIBLIOGRAPHIE 227

In The 2007 International Conference on Next Generation Mo-bile Applications, Services and Technologies, 2007. NGMAST’07,pages 277–286, 2007. 46

[Pawar08] Pravin Pawar, Julien Subercaze, Pierre Maret, Bert-Jan van Beij-num & Dimitri Konstantas. Towards Business Model and Techni-cal Platform for the Service Oriented Context-Aware Mobile VirtualCommunities. In IEEE Symposium on Computers and Communi-cations ISCC, pages 103–110. IEEE Computer Society Press, July2008. 23, 24, 39

[Perez00] P. Perez, K. Hervé, R. Dieng, O. Corby, A. Giboin, F. Gandon,J. Quinqueton, A. Poggi, G. Rimassa, C. FIETTAet al. Corpo-rate memory management through agents. E-business : Key Issues,Applications and Technologies, pages 360–366, 2000. 113

[Pinyapong04] Sineenard Pinyapong & Toshikazu Kato. Query Processing Algo-rithms for Time, Place, Purpose and Personal Profile Sensitive MobileRecommendation. In CW ’04 : Proceedings of the 2004 Interna-tional Conference on Cyberworlds (CW’04), pages 423–430, Wa-shington, DC, USA, 2004. IEEE Computer Society. 32

[Platon.94] Platon. Théétète. Traduction, introduction et notes par M. Narcy,Flammarion, Paris, 1994. 62

[Pokahr05] A. Pokahr, L. Braubach & W. Lamersdorf. Jadex : A BDI reasoningengine. Multiagent Systems Artificial Societies and SimulatedOrganizations, vol. 15, page 149, Springer, 2005. 109

[Preece00] Jenny Preece. Online communities - designing usability, suppor-ting sociability. John Wiley & Sons, Ltd, Chichester, New York,Weinheim, Brisbane, Toronto, Singapore, 2000. 48

[Rao95] A.S. Rao & M.P. Georgeff. BDI agents : From theory to practice. InProceedings of the first international conference on multi-agentsystems (ICMAS-95), pages 312–319. San Francisco, 1995. 92

[Rao96] A.S. Rao. AgentSpeak (L) : BDI agents speak out in a logical com-putable language. Lecture Notes in Computer Science, vol. 1038,pages 42–55, Springer, 1996. 97

[Ritter95] S. Ritter & KR Koedinger. Towards lightweight tutoring agents. InAI-ED, 1995. 118

[Ritter96] S. Ritter & K.R. Koedinger. An architecture for plug-in tutor agents.Journal of Artificial Intelligence in Education, vol. 7, no. 3-4,pages 315–347, Association for the Advancement of Computingin Education, USA, 1996. 118

228 BIBLIOGRAPHIE

[Ritter97] S. Ritter. Communication, cooperation and competition among mul-tiple tutor agents. In Artificial Intelligence in Education, Procee-dings of AI-ED, volume 97, pages 31–38, 1997. 118

[Rothaermel01] F.T. Rothaermel & S. Sugiyama. Virtual internet communities andcommercial success : Individual and community-level theory groundedin the atypical case of TimeZone. com. Journal of Management,vol. 27, no. 3, page 297, South Manage Assoc, 2001. 43

[Rowley07] J. Rowley. The wisdom hierarchy : representations of the DIKWhierarchy. Journal of Information Science, vol. 33, no. 2, pages163–180, Sage Publications, Inc., 2007. 65

[Salber98] D. Salber & G. Abowd. The Design and Use of a Ge-neric Context Server. Rapport technique, 1998. Alsoavailable as http://www-static.cc.gatech.edu/fce/

contexttoolkit/pubs/pui98.pdf. 32

[Schubert05] P. Schubert & J.F. Hampe. Business models for mobile communities.Published by the IEEE Computer Society, 2005. 39, 40

[Sharma98] R. Sharma, V. I. Pavlovic & T. S. Huang. Toward multimodal human-computer interface. Proceedings of the IEEE, vol. 86, no. 5, pages853–869, 1998. 33

[Shi02] H. Shi, S. Revithis & S.S. Chen. An agent enabling personalizedlearning in e-learning environments. In Proceedings of the firstinternational joint conference on Autonomous agents and mul-tiagent systems : part 2, pages 847–848. ACM New York, NY,USA, 2002. 118

[Shoham91] Y. Shoham. AGENT0 : A simple agent language and its interpreter.In Proceedings of the Ninth National Conference on ArtificialIntelligence, volume 2, pages 704–709, 1991. 11, 12, 97, 145

[Shoham95] Y. Shoham & M. Tennenholtz. On social laws for artificial agentsocieties : Off-line design. Artificial Intelligence, vol. 73, no. 1-2,pages 231–252, Elsevier, 1995. 87

[SILVENT03] A.S. SILVENT, C. GARBAY, P.Y. CARRY & M. DOJAT. Rôledes données, informations et connaissances dans la construction descénarios médicaux. Revue d’intelligence artificielle, vol. 17, no. 1-3, pages 207–212, Lavoisier, 2003. 11, 65, 66

[Sirin07] E. Sirin, B. Parsia, B.C. Grau, A. Kalyanpur & Y. Katz. Pellet :A practical owl-dl reasoner. Web Semantics : Science, Servicesand Agents on the World Wide Web, vol. 5, no. 2, pages 51–53,Elsevier, 2007. 78

http://www-static.cc.gatech.edu/fce/contexttoolkit/pubs/pui98.pdf

http://www-static.cc.gatech.edu/fce/contexttoolkit/pubs/pui98.pdf

BIBLIOGRAPHIE 229

[Smith80] RG Smith. The contract net protocol : High-level communicationand control in a distributed problem solver. IEEE Transactions oncomputers, vol. 100, no. 29, pages 1104–1113, 1980. 212

[Stankovsky05] M. Stankovsky. Creating the discipline of knowledge manage-ment. Butterworth-Heineman, 2005. 67

[Stein05] A. Stein, P. Hawking & P. Sharma. A classification of U-commercelocation based tourism applications. In AUSWeb05, The EleventhAustralasian World Wide Web Conference, pages 2–6, 2005. 49

[Strugeon08] Emmanuelle Grislin-Le Strugeon, Abdouroihamane Anli & Em-manuel Adam. Agent-oriented information systems iv, chapitreA Methodology to Bring MAS to Information Systems, pages90–104. 2008. 112

[Subercaze07] Julien Subercaze, Pierre Maret, Ngoc Minh Dang & Ken Sa-saki. Context-aware applications using personal sensors. In Social-Informatics ICST (Institute for Computer Sciences & Telecommu-nications Engineering), editeurs, BodyNets ’07 : Proceedings ofthe ICST 2nd international conference on Body area networks,pages 1–5, July 2007. 23, 39

[Subercaze08] Julien Subercaze, Pravin Pawar, Pierre Maret & Jacques Calmet.A Service Oriented Framework for Mobile Business Virtual Communi-ties . In Willy Picard Luis M. Camarinha-Matos, editeur, VirtualEnterprises and Collaborative Networks, pages 493–500. Sprin-ger, September 2008. 23, 24, 39

[Subercaze09] Julien Subercaze, Christo El Morr, Pierre Maret, Adrien Joly,Matti Koivisto, Panayotis Antoniadis & Masayuki Ihara. TowardsSuccessful Virtual Communities. In International Conference onEnterprise Information Systems, May 2009. 48

[Sugimoto06] C. Sugimoto, M. Tsuji, G. Lopez, H. Hosaka, K. Sasaki, T. Hirota& S. Tatsuta. Development of a behavior recognition system using wi-reless wearable information devices. Wireless Pervasive Computing,2006 1st International Symposium on, pages 1–5, 2006. 36

[Swaminathan98] J.M. Swaminathan, S.F. Smith & N.M. Sadeh. Modeling supplychain dynamics : A multiagent approach. Decision Sciences, vol. 29,no. 3, pages 607–632, Blackwell Publishing Ltd, 1998. 87

[Tsarkov06] D. Tsarkov & I. Horrocks. FaCT++ description logic reasoner :System description. Lecture Notes in Computer Science, vol. 4130,page 292, Springer, 2006. 78

230 BIBLIOGRAPHIE

[Tsoukas96] H. Tsoukas. The firm as a distributed knowledge system : a construc-tionist approach. Strategic management journal, pages 11–25, JohnWiley and Sons, 1996. 68

[van Diggelen05] Jurriaan van Diggelen, Virginia Dignum, Ludger van Elst &Andreas Abecker, editeurs. Proceedings of the aamas 2005 work-shop on agent-mediated knowledge management (amkm-2005),2005. 70

[van Elst04a] Ludger van Elst, Virginia Dignum & Andreas Abecker, editeurs.Agent mediated knowledge management, international sympo-sium amkm 2003, stanford, ca, usa, march 24-26, 2003, revisedand invited papers, volume 2926 of Lecture Notes in ComputerScience. Springer, 2004. 19, 218

[van Elst04b] Ludger van Elst, Virginia Dignum & Andreas Abecker, editeurs.Agent mediated knowledge management, international sympo-sium amkm 2003, stanford, ca, usa, march 24-26, 2003, revisedand invited papers, volume 2926 of Lecture Notes in ComputerScience. Springer, 2004. 70

[Vassileva99] J. Vassileva, J. Greer, G. McCalla, R. Deters, D. Zapata, C. Mud-gal & S. Grant. A multi-agent approach to the design of peer-helpenvironments. In Proceedings of AIED, volume 99, pages 38–45,1999. 118

[Vilmer05] J.B.J. Vilmer. Réalité, Vérité et Connaissance. Une alternative à latraditionnelle «Justified True Belief», inspirée de la «Wirklichkeit» duManuscrit de 1942 de W. Heisen. 2005. 63

[Virginia Dignum04] Andreas Abecker Virginia Dignum Ludger van Elst, editeur. Pro-ceedings of the ecai-2004 workshop on agent-mediated know-ledge management (amkm-2004, 2004. 70

[Wac06] K. Wac, A. van Halteren & D. Konstantas. QoS-Predictions Service :Infrastructural Support for Proactive QoS-and Context-Aware MobileServices (Position Paper). In On the Move to Meaningful InternetSystems 2006 : OTM 2006 Workshops, pages 1924–1933. Springer,2006. 41

[Wang05] Y.H. Wang, W.N. Wang & Y.H. Yen. An intelligent semantic agentfor e-learning message communication. In Advanced InformationNetworking and Applications, 2005. AINA 2005. 19th Internatio-nal Conference on, volume 2, 2005. 119

[Weber68] M. Weber, G. Roth & C. Wittich. Economy and society. New York,page 4, 1968. 26

[Weissman00] D. Weissman. A social ontology. Yale Univ Pr, 2000. 49

BIBLIOGRAPHIE 231

[Weithoener06] T. Weithoener, T. Liebig, M. Luther & S. Boehm. What’s Wrongwith OWL Benchmarks ? In Proceedings of the Second Interna-tional Workshop on Scalable Semantic Web Knowledge BaseSystems (SSWS 2006), pages 101–114, 2006. 83

[Widyantoro01] D.H. Widyantoro, T.R. Ioerger & J. Yen. Learning user interestdynamics with a three-descriptor representation. Journal of the Ame-rican Society for Information Science and Technology, vol. 52,no. 3, pages 212–225, John Wiley & Sons, 2001. 55

[Wiig00] K.M. Wiig. Knowledge management : an emerging discipline rootedin a long history. Knowledge Horizons, Butterworth-Heinemann,Boston, MA, pages 3–26, 2000. 67

[Wilson02] T.D. Wilson. The nonsense of knowledge management. InformationResearch, vol. 8, no. 1, pages 8–1, Tom Wilson/Lund UniversityLibraries, 2002. 66

[Wooldridge95] M. Wooldridge & N.R. Jennings. Intelligent agents : Theory andpractice. Knowledge engineering review, vol. 10, no. 2, pages115–152, Cambridge [England] ; New York, NY : CambridgeUniversity Press,[1984-, 1995. 85

[Wooldridge99] M. Wooldridge. Intelligent Agents in G. Weiss,Multiagent Systems :A Modern Approach to Distributed Artificial Intelligence, 1999. 11,86, 89, 91

[Wooldridge09] M. Wooldridge. An introduction to multiagent systems. Wiley,2009. 18

[Zambonelli01] F. Zambonelli, N.R. Jennings & M. Wooldridge. Organizationalabstractions for the analysis and design of multi-agent systems. Lec-ture notes in computer science, pages 235–252, Springer, 2001.87

[Zarri99] G.P. Zarri, E. Bertino, B. Black, A. Brasher, B. Catania, D. Deavin,L. Di Pace, F. Esposito, P. Leo, J. McNaughtet al. CONCERTO,an environment for the’intelligent’indexing, querying and retrievalof digital documents. Lecture notes in computer science, pages226–234, Springer, 1999. 75

U N MODÈLE D AGENT SÉMANTIQUE - Les Thèses de l'INSA de...

Documents

Transcript of U N MODÈLE D AGENT SÉMANTIQUE - Les Thèses de l'INSA de...