Un modèle d`agent sémantique. Application aux communautés

Transcription

N O D ’ ORDRE 2010-ISAL-9999
A NNÉE 2010
T HÈSE
UN
MODÈLE D ’ AGENT SÉMANTIQUE .
A P P L I C AT I O N
AU X
C O M M U N AU T É S
VIRTUELLES DE CONNAISSANCES .
Présentée devant :
L’Institut National des Sciences Appliquées de Lyon
Pour obtenir :
Le grade de docteur
Spécialité :
Informatique
Formation doctorale :
Informatique
École doctorale :
Infomaths
Par :
Julien S UBERCAZE
S OUTENANCE
DEVANT LE JURY SUIVANT
:
Olivier B OISSIER, Professeur des universités, ENS Mines de Saint-Etienne . . . . . . . . . . . . . . . . . . . Rapporteur
Fabien G ANDON, Chargé de recherche HDR, INRIA Sophia-Antipolis . . . . . . . . . . . . . . . . . . . . . . . . . Rapporteur
Pierre M ARET, Professeur des Universités, Université de Lyon . . . . . . . . . . . . . . . . . . . . . . . . Directeur de thèse
Jacques C ALMET, Professeur des Universités, Université de Karlsruhe . . . . . . . . . . . . . . . . . . . . . . Examinateur
Christo E L M ORR, Professeur des Universités, York University . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examinateur
Bernard E SPINASSE, Professeur des Universités, Université d’Aix Marseille . . . . . . . . . . . . . . . . . Examinateur
Frédérique L AFOREST, 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 cette
thè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 de
soirées. Je tiens aussi à remercier Adrien et Johan pour ces séminaires en équipe, aussi
intéressant scientifiquement que personellement.
Je remercie Christo pour son accueil chaleureux et pour nos discussions passionnantes autour d’un capuccino second cup ou d’une andouillette lyonnaise. Je souhaite
remercier Jacques Calmet pour m’avoir fait découvrir le monde de la recherche. Je remercie aussi Pravin et toute l’équipe du Telemedecine group de l’université de Twente
pour cette collaboration enrichissante. Je n’oublie pas non plus tous les gens avec qui j’ai
eu l’occasion de travailler tout au long de cette thèse, notamment tous mes collègues du
départment informatique de l’UJM et du LaHC. Je remercie aussi les rapporteurs pour
les critiques constructives et les améliorations du manuscrit.
Je pense aussi bien évidemment à ma famille, que je n’ai pas eu l’occasion de voir
aussi 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ées
lyonnaises, parisiennes ou bretonnes.
Je remercie aussi Dunhill, les cafetières Krups, Yves Simon, Boris Vian, les Doors et
Magma. Leur soutien indéfectible m’a permis de mener à terme cette rédaction. Merci
aussi aux nombreux pots de thèses du LIRIS ainsi qu’au ministère de l’enseignement
supérieur et de la recherche pour son soutien financier.
Pour conclure, un très grand merci à Loane pour m’avoir subi et soutenu pendant
toute la rédaction de ce manuscrit.
6
Résumé
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 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 de
stockage qu’ils nécessitent, et enfin surtout par la possibilité de traitement automatique
des informations qu’ils contiennent. Suite à l’avènement de l’informatique dans les
organisations au cours des années 70, puis plus largement dans les années 80, s’est
posé le problème de comment gérer, organiser et transmettre toutes les informations
qui étaient désormais disponibles numériquement et sur lesquelles les machines étaient
capables d’effectuer des traitements. C’est le début de la gestion des connaissances au
sens moderne du terme.
L
A
La gestion des connaissances est une discipline à la frontières de multiples domaines
tels que les sciences sociales, les sciences cognitives, l’informatique et les sciences et
technologies de l’information. Dans le cadre de cette thèse, notre domaine d’étude
se restreint à l’approche mécaniste de la gestion des connaissances, qui considère la
connaissance comme étant un élément qui peut être traité automatiquement par une
unité 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 est
venu compléter les mainframes et autres puissants serveurs, sans toutefois les remplacer
totalement ; de la même manière, la gestion décentralisée des connaissances est venue
contrebalancer l’hégémonie des approches centralisées.
Les travaux récents dans le domaine la gestion décentralisée des connaissances basée
sur le paradigme agent ont posé les jalons d’une nouvelle branche de la gestion des
connaissances, dont les spécificités notables, par rapport à l’approche centralisée, sont la
prise en compte de la nature distribuée et de l’aspect social de la connaissance au sein
des 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 la
gestion des connaissances, en analysant les différentes définitions de la connaissance
qui y sont employées. Nous montrons que les définitions de la connaissance qui soustendent les systèmes de gestion de connaissances, centralisés comme décentralisés ne
sont 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 la
connaissance issue du domaine de l’épistémologie, qui au-delà d’un cadre formel plus
strict, 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’une
approche multi-agent en déterminant les composants requis par les agents pour supporter cette représentation. La difficulté réside dans la définition du modèle d’agent qui
devra 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 parti
des avancées dans le domaine du web sémantique. Les standards du web sémantique
OWL-DL et SWRL possèdent de solides fondements logiques et nous montrons qu’ils
sont parfaitement adaptés à nos besoins de représentation. OWL-DL supporte des raisonnements en monde ouvert qui sont plus en phase avec les connaissances humaines
et nous utilisons le langage de règles SWRL qui permet de manipuler des concepts OWL
et nous permettra d’exprimer les connaissances empiriques.
Nous définissons le modèle d’agent et présentons une implémentation que nous illustrons au travers d’exemples. Afin d’illustrer notre approche, nous utilisons ce modèle
pour y intégrer un mécanisme de transmission des connaissances. Nous nous plaçons
pour cela dans un contexte de partage des connaissances que sont les VKC ou communautés virtuelles de connnaissances. Notre proposition se situe donc à la frontière de
trois domaines que sont la gestion des connaissances, les systèmes multi-agents et le
web sémantique.
8
Notes
Table des matières
Avant-propos
5
Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
Table des matières . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1
Introduction
17
2
Scénarios motivants
21
3
4
5
2.1
Communautés virtuelles de connaissances . . . . . . . . . . . . . . . . .
25
2.2
Scénario 1 : Assistants personnels . . . . . . . . . . . . . . . . . . . . . . .
31
2.3
Scénario 2 : Communautés virtuelles mobiles . . . . . . . . . . . . . . . .
39
2.4
Scénario 3 : Projet DRPI . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
2.5
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
Etat de l’art
59
3.1
Connaissances et gestion des connaissances . . . . . . . . . . . . . . . . .
61
3.2
Représentation des connaissances et Web Sémantique . . . . . . . . . . .
71
3.3
Agents et Systèmes multi-agents . . . . . . . . . . . . . . . . . . . . . . .
84
3.4
Analyse et mise en perspective . . . . . . . . . . . . . . . . . . . . . . . . 122
3.5
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Un modèle d’agents sémantiques
135
4.1
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
4.2
Programmation des agents . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
4.3
Structure de contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
4.4
Représentation des connaissances empiriques . . . . . . . . . . . . . . . . 148
4.5
Exécution d’un scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
4.6
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Communautés Virtuelles de Connaissances à base d’agents
5.1
155
Conception de l’ontologie . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
10
6
7
A
TABLE DES MATIÈRES
5.2
Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
5.3
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Implémentation
175
6.1
Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
6.2
Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
6.3
Exécution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
6.4
Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
6.5
Base de connaissances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
6.6
Conclusion et discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Conclusion
193
7.1
Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
7.2
Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Annexe : Ontologie
199
A.1 Ontologie sous forme d’expression . . . . . . . . . . . . . . . . . . . . . . 201
A.2 Ontologie au format N3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
B
Annexe : Langages de communication agents
Langages de communication agents
209
B.1 Langages de programmation agents . . . . . . . . . . . . . . . . . . . . . 211
C
Annexe : Liste des publications
Bibliographie
213
231
Table des figures
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
Diagramme de classe simplifié des agents . . . . . . . . . . . . . . .
Description du framework . . . . . . . . . . . . . . . . . . . . . . . .
Foot pressure sensor . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interface utilisateur de l’agent personnel . . . . . . . . . . . . . . . .
Communication entre les agents . . . . . . . . . . . . . . . . . . . .
Modèle économique pour les communautés virtuelles mobiles . . .
Vue globale de la plate-forme technique . . . . . . . . . . . . . . . .
Vue d’ensemble des composants de la plate-forme collaborative . .
Création d’une nouvelle communauté . . . . . . . . . . . . . . . . .
Un membre choisissant la visibilité de ses documents, soit pour
membres ou pour des communautés . . . . . . . . . . . . . . . . . .
2.11 Edition des mots-clés après extraction . . . . . . . . . . . . . . . . .
2.12 Un membre choisissant la visibilité de ses documents, soit pour
membres ou pour des communautés . . . . . . . . . . . . . . . . . .
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
des
. . .
. . .
des
. . .
Processus d’extraction de connaissances mettant en exergue l’abstraction
[SILVENT03] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Approche distribuée de la gestion de connaissance [Bonifacio02a] . . . .
Les différentes couches du Web Sémantique . . . . . . . . . . . . . . . . .
Un agent dans son environnement [Wooldridge99] . . . . . . . . . . . .
Architecture BDI [Georgeff89] . . . . . . . . . . . . . . . . . . . . . . . . .
Critères d’analyse des structures internes des agents . . . . . . . . . . . .
Diagramme de flot des agents AGENT-0 [Shoham91] . . . . . . . . . . .
Architecture JASDL ([Klapiscak09]) . . . . . . . . . . . . . . . . . . . . . .
Cycle délibératif des agents 3APL [Hindriks99] . . . . . . . . . . . . . .
Squelette d’un agent 3APL . . . . . . . . . . . . . . . . . . . . . . . . . . .
Architecture des agents dans S-APL [Katasonov08] . . . . . . . . . . . .
Architecture du système Nuin [Dickinson03] . . . . . . . . . . . . . . . .
Plate-forme FIPA : Architecture abstraite . . . . . . . . . . . . . . . . . . .
Architecture de la plate-forme JADE . . . . . . . . . . . . . . . . . . . . .
Modèle Sémantique des agents dans AgentOWL . . . . . . . . . . . . . .
Architecture globale de SEAGENT . . . . . . . . . . . . . . . . . . . . . .
Sociétés pour la gestion de la mémoire [Gandon02] . . . . . . . . . . . .
30
33
37
38
38
41
44
50
51
52
53
54
66
70
76
86
92
95
97
100
102
103
104
106
108
108
110
111
113
12
TABLE DES FIGURES
3.18
3.19
3.20
3.21
Composants principaux de KEx [Bonifacio03] . . . . . . . . . . . . . . . .
Processus de décision des agents dans CONOISE [Norman04] . . . . . .
Architectures interne et externe de ABITS [Capuano00] . . . . . . . . . .
Composants nécessaires aux agents pour la mise en œuvre des connaissances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.22 Rôles du raisonneur selon les types de connaissances . . . . . . . . . . .
128
129
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
Architecture des agents . . . . . . . . . . . . . . . . . . . . . . . . . . . .
EBNF du langage interprété. Ce langage est un sous ensemble de SWRL
Actions selon les couches de l’architecture . . . . . . . . . . . . . . . . .
Interpréteur des agents, inspiré de [Shoham91] . . . . . . . . . . . . . . .
Ontologie résultante de l’architecture . . . . . . . . . . . . . . . . . . . . .
Ontologies des agents : hiérarchie des actions . . . . . . . . . . . . . . . .
Exemple illustratif (a), Scénario . . . . . . . . . . . . . . . . . . . . . . . .
Exemple illustratif (b), Structure de données de la séquence d’actions . .
Exemple illustratif (c), Flux de la transition de l’état sDebut vers l’état A
138
142
144
145
147
148
150
151
152
5.1
5.2
5.3
5.4
5.5
Execution de envoyerMessage dans la communauté c0 . . . . . . . . . . . .
Diagrame de séquence du protocole envoyerMessage de la communauté 0
Relation ternaire, impossible à représenter en OWL . . . . . . . . . . . .
Introduction de la classe AP, pour représenter la relation r p . . . . . . . .
Exemple : utilisation des communautés virtuelles de connaissances. Séquence d’actions transmise par Carmen à Julio . . . . . . . . . . . . . . . .
Exemple : diagramme des messages échangés par les agents lors de l’exécution du scénario sur la plate-forme JADE . . . . . . . . . . . . . . . . .
160
161
163
163
Diagramme de classe d’un agent . . . . . . . . . . . .
Diagramme de séquence de l’initialisation d’un agent
Diagramme d’activité UML des agents . . . . . . . . .
Diagramme de classes des actions . . . . . . . . . . .
179
182
184
188
5.6
6.1
6.2
6.3
6.4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
115
116
119
172
173
Liste des tableaux
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
3.19
3.20
3.21
3.22
3.23
3.24
3.25
3.26
3.27
3.28
3.29
3.30
Représentation des connaissances dans JASON . . . . . . . .
Comportement des agents dans JASON . . . . . . . . . . . .
Représentation des connaissances dans JASDL . . . . . . . .
Comportement des agents dans JASDL . . . . . . . . . . . .
Représentation des connaissances dans Argonaut . . . . . .
Comportement des agents dans Argonaut . . . . . . . . . . .
Représentation des connaissances dans 3APL . . . . . . . . .
Comportement des agents dans 3APL . . . . . . . . . . . . .
Représentation des connaissances dans S-APL . . . . . . . .
Comportement des agents dans S-APL . . . . . . . . . . . . .
Représentation des connaissances dans Nuin . . . . . . . . .
Comportement des agents dans Nuin . . . . . . . . . . . . .
Représentation des connaissances dans JADE . . . . . . . . .
Comportement des agents dans JADE . . . . . . . . . . . . .
Représentation des connaissances dans AgentOWL . . . . .
Comportement des agents dans AgentOWL . . . . . . . . . .
Représentation des connaissances dans SEAGENT . . . . . .
Comportement des agents dans SEAGENT . . . . . . . . . .
Représentation des connaissances dans CoMMA . . . . . . .
Comportement des agents dans CoMMA . . . . . . . . . . .
Représentation des connaissances dans KEx . . . . . . . . . .
Comportement des agents dans KEx . . . . . . . . . . . . . .
Représentation des connaissances dans CONOISE-G . . . .
Comportement des agents dans CONOISE-G . . . . . . . . .
Représentation des connaissances dans les systèmes d’EIAH
Comportement des agents dans les systèmes d’EIAH . . . .
Représentation des connaissances dans Bibster . . . . . . . .
Comportement des agents dans Bibster . . . . . . . . . . . .
Récapitulatif des représentations des connaissances . . . . .
Récapitulatif des comportments agents . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
98
99
101
101
101
102
103
103
105
105
105
106
109
109
110
110
111
112
114
114
116
116
117
117
120
120
121
121
123
124
B.1 Paramètres des messages FIPA ACL . . . . . . . . . . . . . . . . . . . . . 212
Liste des définitions
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
La connaissance, selon Platon . . . . . . . . . . . . . .
La connaissance, selon Johnson . . . . . . . . . . . . .
La connaissance, selon Davenport et Prusak . . . . . .
Raisonneur correct et complet . . . . . . . . . . . . . .
Agent, définition faible de Wooldrigde et Jennings . .
Agent, définition forte de Wooldrigde et Jennings . .
Agent , définition de Jennings, Wooldridge et Sycara .
Agent rationnel, définition de Russell et Norvig . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
62
64
64
83
85
85
85
86
1
Introduction
18
Chapitre 1. Introduction
modèles de réprésentation des connaissances des agents logiciels sont principalement 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 technique
en s’appuyant sur les outils du web sémantique.
L
ES
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 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 de stockage
qu’ils nécessitent, et enfin surtout par la possibilité de traitement automatique des informations qu’ils contiennent. Suite à l’avènement de l’informatique dans les organisations
au cours des années 70, puis plus largement dans les années 80, s’est posé le problème
de comment gérer, organiser et transmettre toutes les informations qui étaient désormais
disponibles numériquement et sur lesquelles les machines étaient capables d’effectuer
des traitements. C’est le début de la gestion des connaissances au sens moderne du
terme.
La gestion des connaissances est une discipline à la frontières de multiples domaines
tels que les sciences sociales, les sciences cognitives, l’informatique et les sciences et
technologies de l’information. Dans le cadre de cette thèse, notre domaine d’étude
se restreint à l’approche mécaniste de la gestion des connaissances, qui considère la
connaissance comme étant un élément qui peut être traité automatiquement par une
unité de calcul, donc de manière mécanique.
Les premiers systèmes de gestion des connaissances, plus connus sous le nom de
KMS (pour Knowledge Management System en anglais), sont apparus vers la fin des années
70. 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 est
venu compléter les mainframes et autres puissants serveurs, sans toutefois les remplacer
totalement ; de la même manière, la gestion décentralisée des connaissances est venue
contrebalancer l’hégémonie des approches centralisées.
L’approche décentralisée de la gestion des connaissances a émergé grâce aux recherches dans le domaine de l’informatique qui l’ont précédées. En effet l’approche
décentralisée de la gestion des connaissances se base notamment sur le paradigme des
systèmes multi-agents qui est apparu à la fin des années 80 [Ferber89] (bien que les
principes 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 connaissances 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 Knowledge
Management [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 nouvelle
branche 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 social
de la connaissance au sein des organisations. C’est sur ce paradigme multi-agent que se
baseront nos travaux. Le domaine des systèmes multi-agents englobe de nombreuses
disciplines (Intelligence artificielle distribuée, simulation, négociation, coordination)
Dans cette thèse, nous présentons tout d’abord le cadre des communautés virtuelles
de connaissances (VKC) qui sont un outil décentralisé d’échanges de connaissances entre
agents autonomes. Nous introduisons le cadre théorique des VKC puis trois scénarios
d’application de ces communautés. Nous analysons ensuite les limitations rencontrées
dans ces travaux pour définir le cadre de notre problématique concernant l’échange de
tous les types de connaissances des agents, en particulier celles éxécutables.
Nous étudions les fondements théoriques de la gestion des connaissances, en analysant les différentes définitions de la connaissance qui 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 ne sont 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 la connaissance issue du domaine de
l’épistémologie, qui au-delà d’un cadre formel plus strict, permet contrairement aux approches existantes [Bonifacio03, Ehrig03, Laclavik06b] d’introduire la notion de connaissance empirique au sein des agents et de faire le lien avec la notion de connaissances
exécutables. Parallèlement nous étudions les architectures d’agent afin de mettre en
lumière les limitations induites par la conception des agents concernant l’échange des
connaissances.
Ensuite nous mettons en application cette définition de la connaissance dans des
agents sémantiques en nous aidant de l’analyse précédente concernant les architectures
d’agent.. La difficulté réside dans la définition du modèle d’agent qui devra 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 parti des avancées dans
le domaine du web sémantique. Les standards du web sémantique OWL-DL et SWRL
possèdent de solides fondements logiques et nous montrons qu’ils sont parfaitement
adaptés à nos besoins de représentation. OWL-DL supporte des raisonnements en
monde ouvert qui sont plus en phase avec les connaissances humaines [Damasio06] et
nous utilisons le langage de règles SWRL qui permet de manipuler des concepts OWL
et nous permettra d’exprimer les connaissances empiriques.
Nous définissons le modèle d’agent et présentons une implémentation que nous
illustrons 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çons
pour cela dans un contexte de partage des connaissances entre que sont les VKC ou
communautés virtuelles de connnaissances. Notre proposition se situe donc à la frontière
de trois domaines que sont la gestion des connaissances, les systèmes multi-agents et le
web 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écrivons
les scénarios qui ont motivé nos recherches.
– Dans le chapitre 3, nous présentons un état de l’art des trois domaines qui nous
intéressent, à savoir la gestion des connaissances, les systèmes multi-agents et le
web sémantique. Nous étudions dans ce chapitre les différents liens existants entre
ces trois domaines.
– Au chapitre 4, nous détaillons notre proposition et nous présentons un modèle
d’agent supportant une définition épistémologique de la connaissance. Nous
détaillons les différentes étapes de la construction de ce modèle, de la définition
vers 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 connaissance inter-agents sur notre modèle en l’appliquant au paradigme des communautés virtuelles de connaissances. Nous présentons une formalisation ensembliste,
puis ontologique de ces communautés, puis nous détaillons leur modèle en tant
que connaissances des agents sémantiques.
– Le chapitre 6 décrit la mise en œuvre de notre modèle d’agent sémantique. Nous
décrivons les choix techniques et la conception logicielle du prototype d’agent
sémantique.
– Nous présentons les conclusions de cette thèse, ainsi que les différentes perspectives qu’offrent ces travaux au chapitre 7.
2
Scénarios motivants
22
Chapitre 2. Scénarios motivants
Plan du chapitre
2.1
Communautés virtuelles de connaissances . . . . .
2.1.1
Abstraction Orientée Agent . . . . . . . . .
2.1.2
La connaissance d’entreprise . . . . . . . .
2.1.3
Communautés virtuelles de connaissances
2.1.4
Implémentation . . . . . . . . . . . . . . . .
2.1.5
Conclusion . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
26
26
28
29
30
2.2
Scénario 1 : Assistants personnels
2.2.1
Framework . . . . . . . .
2.2.2
L’application réveil . . . .
2.2.3
Conclusion . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
32
36
38
2.3
Scénario 2 : Communautés virtuelles mobiles
2.3.1
Etat de l’art . . . . . . . . . . . . . . .
2.3.2
Modèle économique . . . . . . . . . .
2.3.3
Spécifications des services . . . . . . .
2.3.4
Plate-forme technique . . . . . . . . .
2.3.5
Application . . . . . . . . . . . . . . .
2.3.6
Conclusion . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
40
43
45
47
47
2.4
Scénario 3 : Projet DRPI . . . . . . . . . . . . . . . .
2.4.1
Communautés virtuelles . . . . . . . . . . .
2.4.2
Design de la plate-forme et implémentation
2.4.3
Gestion des connaissances . . . . . . . . . .
2.4.4
Conclusion . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
48
48
49
51
55
2.5
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.1
Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
56
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
La définition du contexte et l’introduction à la problématique, sont les deux objectifs
de ce chapitre. Dans une première partie nous introduirons le concept de communautés
virtuelles de connaissances auquel nous ferons appel tout au long de cette thèse. 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 trois sections
suivantes.
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 des
connaissances, la psychologie . . .. Les recherches menées par Maret et Calmet sur la
modélisation des connaissances d’entreprises ont mis l’accent sur une approche informatique basée sur le paradigme agent afin de prendre en compte l’aspect décentralisé des
connaissances. Pour comprendre l’approche qui sous-tend la réflexion engagée sur le
domaine de la gestion des connaissances d’entreprise, il est primordial d’introduire tout
d’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. Les
travaux de Maret et Calmet [Maret04a] ont conduit à un certain nombre de définitions
sur la connaissance d’entreprise qui sont présentées en section 2.1.2. Ces définitions
posent les fondations des communautés virtuelles de connaissances [Maret04b] que
nous 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èse
et qui mettent en œuvre ce concept de communautés virtuelles de connaissances. Ces
travaux ont été mené en collaboration avec des membres de l’université de Tokyo au
Japon [Subercaze07], l’université de Twente aux Pays-Bas [Pawar08, Subercaze08] et
York University au Canada [El Morr09, Elmorr08]. Ces scénarios illustrent l’utilisation
des communautés virtuelles de connaissance dans différents cas.
Le premier scénario se place dans le cadre des applications sensibles au contexte. Ces
applications sensibles au contexte sont basées sur la capture d’information provenant de
l’environnement ainsi que de l’utilisateur. Les informations de contexte sont fournies
par des capteurs qui peuvent être soit fixe ou mobile, que ce soit pour capturer des
informations concernant l’environnement ou bien l’utilisateur. Ces applications sensibles au contexte sont elles aussi fixes ou mobiles, elles peuvent être exécutés aussi
bien sur une machine fixe disposant d’une puissance de calcul élevé que sur une machine portable disposant de ressources plus limitées.De telles applications requiert le
développement de framework supportant les contraintes de mobilité. L’intégration des
données provenant des capteurs est un problème complexe, spécialement 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 do En utilisant l’aspect décentralisé et
autonome des agents, nous proposons un framework basé sur des agents qui permet la
24
fusion de données de capteurs (ainsi que l’é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 des capteurs portables, des transmetteurs ainsi
que des machines portables. Nous ferons appel au concept des communautés virtuelles
de connaissance pour les échanges entre les différents agents. Nous présentons tout
d’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 est
dé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 la
puissance de calcul des systèmes mobiles nous a conduit à changer notre vision des
communautés virtuelles mobiles l’année suivante. Jusqu’alors, les limitations imposées
par la puissance de calcul ne permettait que de réaliser des traitements simples et/ou
de consommer des services depuis un système mobile de type téléphone portable ou
PDA. Les évolutions technologiques récentes permettent de réaliser des calculs plus
importants. Il est alors naturel de considérer un système mobile non plus comme un
simple consommateur de services, mais aussi comme un potentiel fournisseur de services. Nos recherches se sont focalisés sur la réalisation d’applications commerciales
orientées services. Pour cela nous proposons un modèle économique pour les communautés virtuelles mobiles dans lesquelles les systèmes mobiles sont consommateurs
mais aussi producteurs de services [Pawar08, Subercaze08]. Nous détaillons dans ce
second scénario en section 2.3 les pré-requis au niveau des services, l’architecture requise
et l’implémentation open-source de la plate-forme technique. Puis nous donnons un
exemple 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 le
cadre du projet DRPI. Le projet DRPI est un projet international visant à surveiller les
violations des droits des handicapés dans le monde. Le projet est divisé par pays. Nos
travaux se sont focalisés sur la partie DRPI Canada, qui est un des membres fondateurs
du projet. Ce projet rassemble des acteurs académiques aussi bien que 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 et approches des quatre thèmes du projet. Ces quatre thèmes définis
ci-après, doivent permettre de couvrir et d’obtenir les informations sur les nombreux
types de discrimination dont peuvent souffrir les handicapés :
– Surveillance des expériences personnelles : des personnes souffrant d’un handicap
sont impliquées dans la surveillance et peuvent faire part de leurs expériences
personnnelles de discrimination.
– Surveillance des médias : les productions médiatiques concernant le handicap sont
analysé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 personnes
souffrant 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 concernant
les handicapés.
Il est aussi fondamental de construire un partage de la connaissance au sein de la communauté, pour promouvoir une prise de conscience des discriminations dont sont victimes
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’un spectre varié
de participants autour des quatre thèmes énoncés ci-dessus : chercheurs, représentants
de la communauté, législateur et grand public. Nous présentons ce scénario en section
2.4.
Nous présentons nos conclusions à la fin de ce chapitre et présentons une analyse
des 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 trois
sections suivantes.. Nous présentons ici le concept en détail ainsi que certains exemples
d’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 des
connaissances. Pour comprendre l’approche qui sous-tend la réflexion engagée sur le
domaine de la gestion des connaissances d’entreprise, il est primordial d’introduire tout
d’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. Nous
introduisons le concept d’AOA dans la sous-section suivante.
Les travaux de Maret et Calmet [Maret04a] ont conduit à un certain nombre de définitions sur la connaissance d’entreprise qui sont présentées en section 2.1.2. Ces définitions
posent les fondations des communautés virtuelles de connaissances [Maret04b] que
nous 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].
26
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 de
Weber en sociologie qui définit une société comme résultante de l’ensemble des actions de
ses membres [Weber68]. L’AOA définit un agent comme une entité dotée d’une base de
connaissances ainsi que d’un mécanisme de décision. La base de connaissances contient
l’ensemble des connaissances de l’agent qui sont relatives à l’organisation dans laquelle
il évolue. Cette base de connaissances est constituée de quatre composants appellées
annotations : ontologies,communication, cognition et sécurité. Le mécanisme de décision
de l’agent est relatif aux buts et tâches de l’agent. Il génère des fonctions d’utilité qui
mesurent l’efficacité des décisions de l’agent. Ces fonctions d’utilité sont structurés en
classes. 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 au
travers de la mémoire d’entreprise. Cette mémoire d’entreprise comprend tous les
"morceaux" d’information disponibles dans l’entreprise, des technologies requises pour
concevoir un produit jusqu’au politique de gestion des ressources humaines ou de
communication 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 agents
possèdent des connaissances
Définition 2 Les connaissances d’un agent sont annotées. Les annotations sont des
classes ou types structurant la connaissance.
Définition 3 Les clusters sont des sous-ensemble cohérents des connaissances des
agents. 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 de
décision selon ses connaissances. Ces actions et décisions sont évaluées par les
fonctions d’utilité.
Définition 5 La mémoire d’entreprise est constituée de l’ensemble des connaissances
détenu par l’ensemble des agent qui constituent l’entreprise. Cette mémoire est
composée des connaissances stockées et obtenues par des communications internes
ou externes.
Ces caractéristiques sont suffisantes pour aborder le problème de la gestion des
connaissances qui nous intéresse ici. Nous n’exposons pas plus en détail l’AOA et
invitons 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 connaissance
n’est pas extérieure aux agents mais elle leur est propre. Les agents sont détenteurs des
27
connaissances de l’entreprise. La première définition implique ques les individus (humains) et machines sont considérés selon le même niveau d’abstraction. La connaissance
n’est pas prise en compte au sens d’un système de base de données mais comme un
paradigme centré sur l’agent (individu ou automate). La communication est un élément
nécessaire pour chaque agent, les automates doivent être capables de communiquer
entre 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’aide
des trois composants additionnels : cognition, communication et sécurité ; d’aborder
de manière globale la définition d’un agent. Le composant de cognition regroupe les
capacité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’ensemble
des protocoles, messages, etc qui permettent à l’agent de communiquer. Cette énumération des composants n’entend pas être exhaustive et peut être étendue. C’est le rôle de la
notion d’annotation dans les définitions. Les annotations se réfèrent à la structure des
connaissances de l’agent. Un élément de connaissance i peut être annoté par différentes
annotations a1 ...an qui lui confèrent des propriétés. On peut ainsi imaginer un message
qui soit annoté du point de la communication (protocole, structure) mais aussi du point
de la sécurité (respect des lois, etc). Le mécanisme d’annotations permet d’étendre les
annotations 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 connaissance
consistué 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 les
relations présentes au sein du cluster ainsi qu’à l’extérieur.
La définition 4 signifie que les agents sur leurs connaissances pour prendre des
décisions. Les agents définissent des fonctions d’utilité qui permettent de mesurer
l’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 comprend
les 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 vision
objective 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érentes
avec celles d’autres agents.
28
2.1.3
Communautés virtuelles de connaissances
Les communautés virtuelles de connaissances ont été introduites en tant que moyen
d’échange de connaissances au sein d’une société composée d’agents définis selon les
termes de la section précédente, c’est-à-dire possédant une base de connaissances et un
mé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 le
but initial pour lequel l’agent a été introduit dans le système. Le but des communautés
virtuelles de connaissance est d’augmenter l’efficacité des échanges de connnaissance entre les
agents afin de permettre aux agents de réaliser plus rapidement leur but. L’objectif
secondaire est d’obtenir au travers de ces échanges, de nouvelles connaissances apprises
ou déduites, à l’aide des capacités de raisonnement (composant de cognition) de chaque
agent. De manière similaire aux processus d’entreprises, les communautés virtuelles
de 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’un
espace d’échanges de messages. Le thème d’une communauté est un cluster C ∈ CL. Les
agents participant à la communauté sont sensés échanger des messages autour du thème
de la communauté. Tout agent ne respectant pas ces clauses peut se voir exclu de la
communauté. Les messages sont échangés au travers d’un sytème permettant d’accéder
aux messages reçus et d’en envoyer de nouveaux (tampon de messages). Le contenu des
messages 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 ou
initiation de la communauté peut être effectuée par n’importe quel agent, cet agent
devient alors le leader de la communauté. La crétion d’une communauté se fait par
la création d’un cluster, d’un tampon de messages (buffer) et de la promotion de la
communauté. 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é envoie
un message contenant le cluster qui est le thème de la communauté. Ce cluster peut
contenir 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 des
communauté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. La
dissolution d’une communauté intervient par la volonté du leader. Celui-ci efface alors
le 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 tampon
de messages et par envoi de cluster et/ou d’instances dans ce tampon.
29
Les capacités des agents à interpréter les connaissances acquises, à échanger des
connaissances sont considérées comme des connaissances en tant que telles. Ces capacités
sont propres à chaque agent et peuvent par conséquent différer dans les fonctionnalités
et dans l’implémentation. Ce choix de conception est volontaire et permet de prendre en
compte la décentralisation des capacités des agents.
La régulation des communautés est un problème social que l’on retrouve dans
le cas des communautés virtuelles. Pour prendre en compte la notion de régulation
chaque agent fondant une communauté peut spécifier les politiques de sécurité et de
confidentialité qui s’y appliquent. Ces politiques spécifient entre autres la manière
dont les agent rejoignent, participent aux communautés. Le rôle de ces politiques est
d’adresser les problèmes de sécurité qui peuvent apparaitre lorsque des agents malicieux
sont 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 agents
possédant des connaissances hétérogènes peuvent créer, terminer, participer à des communautés virtuelles de connaissances. L’accent est mis sur le partage, en particulier sur
les correspondances entre les ontologies hétérogènes décrivant des concepts similaires
ainsi 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 participation à des communautés. Chaque agent possède ses concepts personnels, ainsi que
des ontologies normalisées et un ensemble de correspondances entre les deux. L’utilisation des agents est centrée utilisateur, les agents disposant d’une interface graphique
permettant à l’utilisateur d’entrer de nouveaux buts, de nouveaux concepts/instances
ou de nouvelles correspondances. L’agent agit ensuite pour l’utilisateur, selon les buts
assignés.
La plate-forme JADE [Bellifemine99] a été choisie pour réaliser l’implémentation
du prototype. Le choix de JADE se justifie par la capacité des agents à échanger des
messages selon le standard FIPA-ACL [ACL-FIPAml] et par la possibilité d’utiliser pour
chaque agent des ontologies définies par l’utilisateur. Les agents ont été créé en étendant
la classe jade.core.Agent.
La classe principale du système est la classe CommunityAgent qui est une classe
abstraite définissant les méthodes des agents participant aux communautés. Deux implémentations de cette classe abstraite ont été réalisées : la classe IndividualAgent
et SocialAgent. Ces deux implémentations sont opposées dans le comportement de
l’agent. l’agent individualiste cherchera à rejoindre une communauté et à y participer
30
F IGURE 2.1 – Diagramme de classe simplifié des agents
seulement si il a besoin de connaissances qui pourrait s’y trouver. Une fois les connaissances 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 connaissances. 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 qui
représente une ontologie décrivant les concepts, instances et clusters possibles. D’aucun peuvent considérer la classe KnowledgeClusterOntology comme une métaontologie. Les connaissances personnelles d’un agent sont constituées des ontologies
personnelles KnowledgeCluster ainsi que des instances personnelles de la classe
AbsContentElementList. La figure 2.1 représente les différentes classes énumérées.
Les communications entre agents se fait par passage de messages. Les messages sont de type jade.lang.acl.ACLMessage : inform ou request. Trois
types de messages request peuvent être envoyés par les CommunityAgent :
joinCommunity, readFromBuffer (qui demande de lire le tampon de messages) et KnowledgeCluster (l’agent souhaite envoyer un cluster à la communauté). Nous distinguons quatre types de messages inform : les messages contenant unKnowledgeCluster ou des instances qui sont partagés par un agent,
updateRole lors de la mise à jour d’un ou des roles des agents, leavingCommunity
et 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’approche
AOA de Calmet a permis de donner des définitions de la connaissance d’entreprise A
partir 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’autonomie, de décentralisation, de modélisation des connaissances ainsi que des mécanismes
d’échanges. Le concept de communautés virtuelles de connaissances permet de diffuser et d’étendre les connaissances d’une société d’agents. La connaissance n’est pas
limitée au domaine d’intérêt de chaque agent mais comprend aussi les connaissances
des 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 œuvre
les différents aspects.
La base de connaissances ne contient pas seulement des ontologies, mais aussi trois
autres composants (cognition, communication et sécurité). Cependant, l’implémentation montre une différence de traitement entre les différents composants. En effet les
ontologies sont les seules parties de la base de connaissances qui sont échangeables
entre 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 qui
ne permet pas réutiliser le code de chacun 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.reflect et offre la possibilité de transférer des portions
de code exécutables entre des programmes JAVA. Cette limitation dans le transfert
des connaissances provient de l’architecture des agents JADE. Les agents sont conçus
pour échanger des messages au format FIPA-ACL et pour gérer de manière interne
des ontologies. Les parties exécutables qui sont les comportements (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 est
l’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 ontologies
sont au format RDF, les composants responsables de la communication, cognition et
sécurité sont programmés en JAVA (une partie de la sécurité est en RDF, pour la description 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. La
distinction entre les parties échangeables et non échangeables de la base de connaissances
soulève plusieurs questions : une connaissance qui n’est pas échangeable est-elle une
connaissance ? si oui, dans quelle mesure est-elle utile pour le système ? Quand peut-on
parler de connaissance ?
2.2 Scénario 1 : Assistants personnels
32
Les applications sensibles au contexte sont basées sur la capture d’information provenant de l’environnement ainsi que de l’utilisateur. Les informations de contexte sont
fournies par des capteurs qui peuvent être soit fixe ou mobile, que ce soit pour capturer
des informations concernant l’environnement ou bien l’utilisateur. Ces applications
sensibles au contexte sont elles aussi fixes ou mobiles, elles peuvent être exécutés aussi
bien sur une machine fixe disposant d’une puissance de calcul élevé que sur une machine portable disposant de ressources plus limitées.De telles applications requiert le
développement de framework supportant les contraintes de mobilité.
L’intégration des données provenant des capteurs est un problème complexe, spécialement 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 sein
de 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’applications statiques sensibles au contexte . Les frameworks les plus avancés sont les
suivants : [Pinyapong04] qui est dédié au profil utilisateur, [Gellersen02] spécialisé dans
l’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éveloppement
rapide 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égrer
simplement 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 framework basé sur des agents qui permet la fusion de données de capteurs (ainsi que
l’é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 des
capteurs portables, des transmetteurs ainsi que des machines portables. Nous ferons
appel au concept des communautés virtuelles de connaissance pour les échanges entre
les différents agents. Nous présentons tout d’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.
2.2.1
Framework
Bien que l’utilisation des capteurs dans les applications sensibles au contexte soit une
chose nécessaire, on constate un manque d’approche globale dans les infrastructures
dédiées au développement de ces applications. De plus, pour intégrer pleinement les
données fournies par les capteurs, le point de vue de l’architecture de l’application
en terme de composants doit-être pris en compte, mais aussi le traitement de ces don-
33
nées ainsi que l’échange des données de contexte entre ces différents composants puis
finalement leur interprétation sémantique.
Pour permettre une intégration efficace de ces différents niveaux de traitement nous
proposons une infrastructure (voir figure 2.2) basée sur les trois concepts suivants :
– Les applications sensibles au contexte requiert une autonomie des composants
qui permet de décentraliser le traitement des données. En terme de paradigme, la
notion 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 responsables de la capture des données de contexte, de leur interprétation et de leur
dissémination au sein du système (section 2.2.1.1), et les agents personnels qui
possèdent des connaissances sur l’utilisateur (son profil) et qui sont chargés de
fournir 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 ontologies. Les échanges entre les agents seront effectués au travers des communautés
virtuelles de connaissances que nous avons décrites dans la section précédente.
F IGURE 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 complexe
d’aide à la décision. Les décisions sont basées sur les connaissances extraites des données
des capteurs ainsi que sur les préférences de l’utilisateur. Les données des capteurs
hétérogènes peuvent être intégrées de différentes manières. [Sharma98] propose trois
niveaux d’intégration :
1. Fusion des données : Les données brutes sont fusionnées avant tout autre type de
traitement. C’est l’intégration au plus bas niveau, elle n’est possible que dans le
cas de capteurs capturant le même type de données. Par exemple dans le cas des
34
rangées de microphones, la fusion à bas niveau permet de réduire le pourcentage
d’erreur.
2. Fusion des caractéristiques : Chaque signal ou donnée brute est interprété en tant
que caractéristique (température, pression, niveau d’activité, . . .). Ces interprétations 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 calculée (proposer X ou Y à l’utilisateur), ces décisions sont ensuite fusionnées, pour
déterminer la décision finale.
Les applications sensibles au contexte qui nous intéressent intègrent des données de
différentes natures, ce qui exclut de facto la fusion à bas niveau dans notre système. La
fusion au niveau décision requiert un temps de calcul plus élevé que celle au niveau
caracté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 de
capteur doit être effectué au niveau des caractéristiques. Ce niveau de fusion est satisfaisant en terme de possibilités d’évolution, puisqu’il intègre des données de différentes
natures et il est aussi adapté au application mobile qui dispose d’une puissance de calcul
limitée.
Nous distinguons quatre niveaux dans l’architecture des agents de contexte :
1. Capteur : Ils capturent les informations environnementales et délivrent soit un
signal é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 fournies
par le capteur. A ce niveau, le signal est transformé en données contextuelles. Par
exemple à partir du signal fourni par un accéléromètre, l’interpréteur peut fournir
le contexte du porteur de l’accéléromètre : marcher, courrir, être immobile . . .. Dans
ce cas précis, ce module est aussi nommé HBR pour Human Behavioral Recogntion
ou Reconnaissance du Comportement Humain en français.
4. Synthétiseur : La partie innovante dans notre approche. Le synthétiseur transforme les données fournies par l’interpréteur afin de les rendre échangeables avec
les autres agents du système.
Le bénéfice en terme de développement d’applications apparait avec l’introduction
du synthétiseur, qui permet l’échange entre les différents agents qui composent l’application. L’intégration de nouveaux capteurs et de nouvelles données dans le système
ne 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éfinies
dans 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 cette
souplesse dans l’application.
35
De plus, un agent de contexte étant capable de communiquer avec d’autres agents, en
particulier d’autres agents de contexte, il lui est possible d’agréger les informations
fournies 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é sur
une machine mobile de type téléphone portable ou PDA et il joue le rôle d’assistant
personnel. Cet agent rassemble les informations de contexte fournies par les agents de
contexte et fournit un service à l’utilisateur final. Cet utilisateur est décrit sous la forme
d’un profil qui contient des informations sur les préférences de l’utilisateur, des données
personnelles, ainsi qu’un historique des actions de l’utilisateur. Le processus de décision
de l’agent se base sur le profil de l’utilisateur ainsi que sur les données fournies par les
agents de contexte. Ce processus est défini par des prédicats qui peuvent être soit entrés
au moment de la conception de l’application, soit par l’utilisateur final. L’utilisation de
règles a été choisie pour son temps de calcul de réduit, ainsi que pour la faible taille en
mé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, agents
logiciels) requiert des mécanismes d’échanges d’information qui sont efficaces. Une
approche 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ède
sa propre base de connaissance basée sur des ontologie et il possède aussi ses mécanismes 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 telle
communauté n’existe pas, l’agent crée une communauté et la déclare dans un système
de pages jaunes. Les échanges ont lieu pendant la durée de vie de la communauté, qui
peut-être finie ou infinie. La sécurité des échanges est garantie par les politiques de
sécurité associées à chaque communauté.
Ces communautés virtuelles de connaissances ont été implémenté sur la plate-forme
JADE [Bellifemine99] et JADE-LEAP pour des applications mobiles. Les connaissances
des 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-
36
nauté, il spécifie la thématique de la communauté ainsi que les politiques d’échanges et
de sécurité. Les échanges sont faits au travers d’un système de tableau noir, en fonction
de leurs droits au sein de la communauté, les agents peuvent lire et/ou écrire sur le
tableau.
2.2.2
L’application réveil
Nous avons implémenté notre framework dans une application apepllée "Réveille
moi". Le scénario est le suivant. Un passager du métro s’endort pendant le trajet qui
l’amène à son domicile. L’application doit-lui permettre de ne pas rater son arrêt de
métro. La solution proposée est de détecter le niveau d’activité de l’utilisateur à l’aide
de capteurs portables et si nécessaire de le réveiller en faisant sonner son téléphone
portable lorsqu’il s’approche de la station désirée.
Cette application requiert différents composants : des transmetteurs dans les stations
de métro, des capteurs d’activité ainsi qu’un téléphone portable. Chacun implémente
soit 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 qui
est 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 au
niveau 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 est
la station de métro. Pour notre application, ce transmtteur fournit seulement le nom de
la station, mais ces fonctionnalités peuvent être étendues pour fournir d’autres éléments
aux voyageurs tels qu’un plan de la station, les horaires de métro . . .. Les connaissances
transmises sont les suivantes :
– Concept : Nom de station
– Instance : ’Ginza’
Capteur
Nous avons utilisé un capteur de pression au niveau du pied qui mesure le niveau
d’activité d’un voyageur [Sugimoto06] (voir figure 2.3). La sortie du capteur est un
signal électrique qui ne possède aucune signification brute. Ce signal est envoyé à un
37
composant embarqué sur lequel est déployé un agent de contexte implémenté sur JADELEAP qui détermine si l’utilisateur est endormi ou non. Un algorithme de type HBR est
utilisé pour déterminer l’état de l’utilisateur. Cet agent de contexte associé au capteur
est aussi en charge de la diffusion de cette information au travers des VKC. Une version
simplifiée des connaissances transmises est indiquée ci-dessous.
F IGURE 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éphone
portable. 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 rejoindre
des 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. Si
l’utilisateur se trouve à la station désirée, l’agent de contexte située dans le téléphone crée
une 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 de
décision
– exemples d’instances :
– nieau d’activité : inconnu
38
F IGURE 2.4 – Interface utilisateur de l’agent personnel
– Destination souhaitée : ’Ginza’
– Position actuelle : ’Shibuya’
– Règles de décision : IsSameLocation(Location1, Location2) ; IntentionDescription(Desired location, Actual location)
F IGURE 2.5 – Communication entre les agents
2.2.3
Conclusion
L’utilisation des capteurs personnels dans les applications mobiles sensibles au
contexte est un domaine de recherche prometteur. Le framework proposé, basé sur
des échanges de connaissances entre des agents de contexte et des agents personnels
au sein de communautés permet l’intégration dynamique de nouveaux capteurs sans
respé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 de
contexte lié à ce second capteur et de la modification des règles de décision de l’agent
personnel 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’aspect
autonomie que présente l’approche agents et le scénario du réveil permet d’illustrer son
fonctionnement. Le synthétiseur est le composant innovant de cette approche qui permet
de transformer les informations de l’agent en connaissances échangeables avec les autres
agent. Ces échanges basés sur les VKC permettent l’ajout dynamique de nouveaux
capteurs 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 un
facteur limitant quant aux possibilités de réalisation. L’augmentation de la puissance de
calcul des systèmes mobiles nous a conduit à changer notre vision des communautés
virtuelles mobiles l’année suivante. Jusqu’alors, les limitations imposées par la puissance
de calcul ne permettait que de réaliser des traitements simples et/ou de consommer des
services depuis un système mobile de type téléphone portable ou PDA. Les évolutions
technologiques récentes permettent de réaliser des calculs plus importants. Il est alors
naturel de considérer un système mobile non plus comme un simple consommateur de
services, mais aussi comme un potentiel fournisseur de services.
Nos recherches se sont focalisés sur la réalisation d’applications commerciales orientées services. Pour cela nous proposons un modèle économique pour les communautés virtuelles mobiles dans lesquelles les systèmes mobiles sont consommateurs mais
aussi producteurs de services [Pawar08, Subercaze08]. Nous détaillons les pré-requis
au niveau des services, l’architecture requise et l’implémentation open-source de la
plate-forme technique. Puis nous donnons un exemple d’application dans le domaine
de 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 des
communauté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 des
catégories est ensuite réalisée. Pour Leimister et. al. [Leimeister04], un modèle économique 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 utilisant
ce modèle économique est faite en [Leimeister04]. Comme indiqué en [Schubert05], un
40
modèle économique sert à comprendre les composants fondamentaux d’une activité
commerciale, existante ou future. Le modèle économique présenté en [Schubert05] prend
en compte les aspects sociaux et commerciaux des communautés virtuelles. La plateforme de communauté est mise en place par les fournisseurs de services ou les vendeurs
qui souhaitent faire la promotion ou la vente de services ou de produits. En se basant sur
des informations telles que les préférences des utilisateurs, leur réseau social, le vendeur
fournit 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 les
messages à leurs amis quand ils le souhaitent. L’application présentée est un système de
location 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 aspects
mobiles et sensibles au contexte.
Pour profiter de l’aspect mobile dans des scénarios tels que ceux des encombrements
de traffic, [Kawash05] propose un système innovant de collaboration basé sur le concept
de spot. Ce modèle collaboratif a été appliqué par [Kawash05] pour développer des communautés autour des problématique de transport public. Pour étendre les communautés
virtuelles en partant d’un point de vue fixe vers la mobilité, [Farooq02] propose un systè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 membres
pour le recommander des produits, services . . .
3. Une approche orientée service pour l’implémentation de l’architecture dans laquelle les membres utilisent leurs systèmes mobiles pour offrir des services commerciaux ou des échanges de contenu.
2.3.2
Modèle économique
Dans le modèle économique proposé nous définissons tous d’abord trois types
d’acteurs primaires : consommateurs, fournisseurs et la plate-forme de communauté. Les
fournisseurs et consommateurs peuvent être indifféremment fixes ou mobiles. Les
founisseurs sont divisés en sous-catégories : les fournisseurs de services commerciaux,
les vendeurs de produits, les fournisseurs de contenus sociaux, les fournisseurs de support
communautaire ainsi que les fournisseurs de service internet. Les consommateurs sont définis
de manière duale aux fournisseurs : consommateurs de service commerciaux, consommateurs
de produits, consommateur de contenu. La plate-forme communautaire fournit les éléments
et foncionnalités nécessaires aux intéractions entre consommateurs et fournisseurs.
41
F IGURE 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 tant
que 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 exemple
plus détaillé, voir le cas d’étude en section 2.3.5.
Utilisateur mobile comme consommateur d’un service commercial : L’utilisateur mobile
prend 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 une
comparaison des prix.
Utilisateur mobile comme fournisseur d’un service commercial : L’utilisateur mobile utilise
son téléphone pour controler la qualité de service (QoS) et fournir des données à un
service de cartographie de QoS [Wac06] qui analyse et compile les informations fournis
par de nombreux appareils mobiles, et fournit une carte du réseau.
Le fournisseur d’accés à internet (ISP) fournit la connectivité qui permet aux acteurs
d’intéragir entre eux. Son rôle étant limité dans notre étude, nous ne le détaillerons
pas 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 flots
d’échanges, de contenus, financiers et de produits sont aussi décrits. La section suivante
décrit en particulier le rôle central de la plate-forme communautaire.
42
2.3.2.1
Plate-forme communautaire :
La plate-forme communautaire fournit l’infrastructure ainsi que les fonctionnalités
pour créer des relations sociales et faciliter les transactions financières et de contenus
entre les fournisseurs et les consommateurs. La plate-forme permet aux fournisseurs
de services (produits) de lister et de promouvoir leurs services (produits). Le service
d’intéraction sociale au sein de la plate-forme fournit les outils pour créer les relations
sociales 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 service
de recommandation sensible au contexte qui utilise les informations de contexte (localisation,
. . .) des fournisseurs et consommateurs pour leur recommander des services ou des produits en s’appuyant sur leur contexte. Par exemple si différents fournisseurs proposent
un service d’ambulance, le patient utilisera le service le plus proche. L’utilisation des
informations 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 contenu
entre les acteurs :
Publier : Le mode d’intéraction Publier est utilisé par le fournisseur de services
commerciaux, de produits ou de contenu social et par le fournisseur du service de
plate-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 liste
des services, produits, contenu dans les sous communautés appropriées ou sur le profil
de l’utilisateur) pour publier ces informations.
Réponse à une requète : Le mode réponse à une requète est utilisé par les consommateurs
et par la plate-forme communautaire pour intéragir avec les fournisseurs. La plateforme communautaire sert donc essentiellement de médiateur entre les fournisseurs et
consommateurs. Le service de médiation pour les aspects commerciaux offert par la plateforme 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 traitement
effectué par le service de médiation est principalement la génération de revenus pour la
plate-forme communautaire (voir section 2.3.2.4). Le consommateur de services de type
sociaux ou de contenu utilise ce mode d’intéraction pour demander l’accés au contenu
publié par les membres de la communauté.
Abonnement-Notification : Ce mode d’intéraction est semblable au précédent. La
43
différence se situe dans la notion d’abonnement. Le consommateur s’abonne puis reçoit
de 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 quand
un 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 qui
le 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 acteurs
aussi bien producteur que consommateur a pour conséquence la mise en œuvre de
service 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-forme
communautaire établit la concordance ou non d’intérêts entre les membres de la communauté et/ou avec les fournisseurs de produits/services. La plate-forme communautaire
propose des sous communautés appropriées aux membres et suggèrent aux membres de
nouveaux contacts pour intéragir. La sensibilité au contexte dans la fonction de mise en
relation 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 les
aspects 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 plateforme communautaire et le fournisseur de services ainsi que par la publicité. Pour
plus 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 des
applications 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émentation. Nous avons choisi le paradigme SOA pour le design de communautés virtuelles
mobiles. Pour être viable, la plate-forme supportant les communautés virtuelles né-
44
F IGURE 2.7 – Vue globale de la plate-forme technique
cessitent un certain nombre de spécification en termes de services, afin de supporter
l’intégration des consommateurs et producteurs, fixes ou mobiles.
Nous présentons ici un nombre restreint de services basiques dédiés au support des
fournisseurs 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 SOA
et 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é, telle
qu’elle est représentée en figure 2.7.
Service de gestion des membres : Ce service fournit les fonctionnalités telles que l’enregistrement 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 offres
commerciales 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és
requises pour créer, rejoindre, accéder aux sous-communautés de la plate-forme, ainsi
que 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 de
la communautés. Ce qui inclut des fonctionnalités telles que le dialogue en direct, les
notifications, et la souscription aux flux d’un membre.
45
Service de mise en relation sensible au contexte : Ce service est utilisé pour trouver
des membres potentiels pour les nouvelles sous-communautés. Le service de mise en
relation est vital au bon fonctionnement du modèle économique décrit ci-dessus. Si
un membre de communauté est intéressé par un type particulier de service (qui peut
comprendre plusieurs instances de service), le service de mise en relation choisira selon
le contexte de l’utilisateur lequel de ces services lui sera proposé, selon l’approche défini
dans [Hesselman06].
Service de médiation pour les aspects commerciaux : Le rôle du service de médiation
est de fournir aux membres l’accés aux différents services et produits listés dans la
plate-forme et de gérer les transactions au nom des membres. A cette fin, le service
de médiation est constitué d’un module centralisé de facturation. La plate-forme de
communauté contient une base de données qui contient entre autres les profils des
utilisateurs, la liste des services et produits ainsi que les informations de facturation. Les
inté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 permetrre
l’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 afin
que ce contenu soit publié dans les communautés adéquates. De la même manière ce
service d’échange s’abonne et reçoit les informations des communautés auxquelles le
membre appartient. Ce service transforme le dispositif mobile en producteur de contenu
social et en consommateur de services commerciaux ou sociaux.
Service mobile commercial : le rôle de ce service est de permettre au dispositif mobile de
devenir un fournisseur de services commerciaux. Ce service peut réutiliser le composant
social décrit ci-dessus dans le cadre des échanges de contenus. En dehors de ce cas, les
fonctionnalités supplémentaires doivent être implémentées sur la machine, en fonction
de 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 en
temps-réel à la plate-forme communautaire. Ces informations sont ensuite utilisées par
le service de mise en relation.
2.3.4
Plate-forme technique
Notre choix technologique pour l’implémentation des services au niveau de la plateforme communautaire sont les Services Web. Ce choix d’architecture SOA se justifie
46
par l’interopérabilité et la facilité de déploiement des Services Web. A la différence des
services situés sur le réseau fixe dont les problématiques sont classiques, l’utilisation et la
maintenance de services moibles posent un certain nombre de problèmes en particulier
dues à la connectivité intermittente, à la limitation des ressources ainsi qu’à la mobilité
de l’utilisateur. Comme cela a été identifié dans [Pawar07], il existe trois approches
différentes pour la problématique des services mobiles : les micro-services, les microhost 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 connaissance
technologique que nous en avions. MSP est un middleware basé sur un proxy situé dans
le système de surrogate Jini 1 . Les spécifications initiales de MSP ne supportant pas une
architecture SOA, nous avons étendu cette dernière pour intégrer la gestion des services
web. 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 service
sur mobile.
2. Une représentation du service sur la partie fixe du réseau que l’on nomme surrogate
ou substitut.
Le substitut fonctionne comme un proxy pour le service sur mobile et intervient dans
la 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 le
substitut. 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 plateforme communautaire est une extension du logiciel open source Dolphin 2 , développé en
PHP. Dolphin a été installé sur un serveur Apache et une base de données MySQL. Du
côté de la plate-forme communautaire, les web services ont été implémenté en PHP. Les
services commerciaux mobiles, d’information de contexte sont développés en tant que
service nomadique. Pour l’interopérabilité entre les services mobiles et la plate-forme
communautaire, des interfaces spéciales ont dues être développées pour permettre au
client Jini de fonctionner en tant que service web et le substitut en tant que client de
service web. Pour réaliser ces interfaces nous avons utilisé Eclipse WTP.
1. http://www.jini.org
2. http://www.boonex.com/dolphin/
2.3.5
47
Application
Le cas présenté ici se situe dans le domaine de l’informatique de santé mobile (mhealth). 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 Care
Community en anglais). Le service de mise en relation recommande à Alice, Bob et
d’autres membres de rejoindre la communauté HCC. Bob et Alice rejoignent la communauté en mettant à jour leur profil avec les informations nécessaires à HCC (les
troubles dont souffre Bob, . . .). Le service de mise en relation recommeade à chacun de
rejoindre le réseau social de l’autre, en se basant sur les informations fournis au profil
HCC. Bob, Alice et d’autres peuvent ainsi établir des liens, se rencontrer, pour partager
leurs expériences. Pendant ce temps, le HCC annonce qu’il met à disposition un système
de 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 de
recommandation propose à Bob un BAN compatible avec son PDA. Bob (consommateur
de produit) achète le BAN et s’abonne au service de télé-surveillance via la plate-forme
communautaire. Alors que Bob est atteint d’une crise épilepsie, le BAN détecte la crise
et transmet les informations via son PDA à la plate-forme communautaire. Le service
de télé-surveillance recherche alors l’ambulance la plus proche de Bob. Le système de
mise 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 les
soins d’urgence à Bob.
2.3.6
Conclusion
Au cours de ces travaux, nous avons étudié le modèle économique des communautés virtuelles au sein desquelles les utilisateurs mobiles pouvaient être non seulement
consommateur, mais producteur de services. Nous avons sur une approche orientée
services 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écifications de la plate-forme communautaire. L’utilisation combinée des données de
contexte ainsi que service mobile permet la création de fonctionnalités avancées au sein
de la plate-forme communautaire.
Ces travaux permettent de mettre en lumière le potentiel économique des communautés virtuelles, notamment dans les applications mobiles. Les communauté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ésentent un fort potentiel
économique que le modèle économique présenté permet d’exploiter.
48
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 international
visant à surveiller les violations des droits des handicapés dans le monde. Le projet est
divisé par pays. Nos travaux se sont focalisés sur la partie DRPI Canada, qui est un des
membres fondateurs du projet. Ce projet rassemble des acteurs académiques aussi bien
que 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 et
approches des quatre thèmes du projet. Ces quatre thèmes définis ci-après, doivent permettre de couvrir et d’obtenir les informations sur les nombreux types de discrimination
dont peuvent souffrir les handicapés :
– Surveillance des expériences personnelles : des personnes souffrant d’un handicap
sont impliquées dans la surveillance et peuvent faire part de leurs expériences
personnnelles de discrimination.
– Surveillance des médias : les productions médiatiques concernant le handicap sont
analysées à travers le prisme des droits de l’homme.
– Surveillance des aspects juridiques : le statut actuel et l’évolution de la législation
sont suivis pour s’assurer du respect des droits fondamentaux des personnes
souffrant 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 concernant
les handicapés.
Il est aussi fondamental de construire un partage de la connaissance au sein de la
communauté, pour promouvoir une prise de conscience des discriminations dont sont
victimes 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’un
spectre 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 de
la part des communautés en informatique, sociologie, psychologie, ainsi que d’autres
disciplines [Preece00]. Une communauté virtuelle est une forme de système social, il
3. 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 communauté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 connaissance (Knowledge Network en anglais). Les réseaux de connaissance sont des communautés au sein desquelles les participants capturent, accèdent, utilisent, créent et définissent
des 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 le
contexte du projet DRPI. Notre plate-forme VC-KM (gestion de connaissance et communauté 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 membres
de la communauté gèrent des activités complexes extrêmement variables alors que la
dissémination d’une partie des connaissances au grand public doit se faire avec simplicité. Beaucoup de plate-formes de communautés virtuelles existent, notamment en
open-source. Malheureusement aucune n’est adaptée au besoin de notre projet en terme
de relation entre les membres, gestion de la confidentialité (complexe ici avec les différents types de membres), édition collaborative sde documents , partage à différents
niveaux de granularité. De plus, aucun des sites ne vérifie le niveau d’accessibilité aux
handicapé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ées
sont é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. Un
des besoins importants est de permettre un apprentissage continu et permettre de
dé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, la
communauté doit permettre aux chercheurs de collaborer efficacement, de vérifier et
valider les propositions. La communauté doit faciliter la création de connaissances ainsi
que la recherche au sein de la plate-forme. En effet les productions attendues sont très
nombreuses et la recherche d’information jouera un rôle primordial pour le succés de
la plate-forme. Notre plate-forme a été conçue autour des aspects suivants (voir figure
2.8) :
1. Création de connaissance
2. Découverte de connaissance
3. Dissémination des connaissances
4. Gestion des membres et des accés
50
Création de
connaissances
Découverte de
connaissances
Communauté
virtuelle de
connaissances
Dissémination
des
connaissances
Gestion de
communauté
F IGURE 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. Les
fonctionnalités classiques de gestion des membres ont été développées, ainsi qu’un
système de création de communautés.
Cinq communautés ont ensuite été créées, quatre autour des thèmes du projet et
restreintes aux participants, la cinquième étant ouverte au grand public. Deux niveaux
ont été créé, administrateur et membre. Chaque administrateur gère sa communauté, un
super administrateur gérant la plate-forme globale (voir fig 2.9). Chaque membre peut
ensuite devenir non seulement consommateur mais aussi producteur de contenu. La
communauté publique est la seule qui ne nécessite pas l’approbation de l’administrateur
pour pouvoir la rejoindre. Les membres des communautés autre que celle publique, sont
essentiellement des chercheurs, donc producteurs de contenu. Néanmoins ils sont aussi
consommateurs des informations échangées et produites par leurs collègues.
Les administrateurs et les membres des communautés peuvent envoyer des documents sur la plate-forme et assigner une visibilité à chacun de leur fichier (voir figure
2.10). Chaque membre peut décider si son document est visible par un membre ou par
51
F IGURE 2.9 – Création d’une nouvelle communauté
une communauté. Le droit individuel étant prioritaire sur le droit global. Il est donc
possible 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 bonnes
pratiques du département de la santé américaine 4 et nous avons utilisé un code XHTML
qui satisfait aux normes W3C ainsi qu’un nombre réduit d’images pour ne pas pénaliser
les 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 raccourci
clavier.
2.4.3
Gestion des connaissances
Deux tendances prédominent actuellement la conception de la gestion des connaissances, 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 certain nombre de bonnes pratiques pour la réalisation de notre plate-forme spécifique au
domaine 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 nombre
de documents qui seront répartis entre les différentes communautés. Deux problèmes
4.
52
F IGURE 2.10 – Un membre choisissant la visibilité de ses documents, soit pour des
membres ou pour des communautés
F IGURE 2.11 – Edition des mots-clés après extraction
53
54
F IGURE 2.12 – Un membre choisissant la visibilité de ses documents, soit pour des
membres ou pour des communautés
majeurs ont été identifiés et nous avons développé des solutions pour les résoudre. Tout
d’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 rapidement
et 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 passer
inaperçu, noyé dans la masse du contenu. Par conséquent il est important de faciliter la
recherche 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 documents 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 mis
en 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 est
indexé par la plate-forme. Les utilisateurs ayant un profil correspondant à la description
du 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éret
de l’utilisateur [Widyantoro01]. Nous avons utilisé le système KEA pour extraire les
mots-clés d’un document. Le modèle a tout d’abord été entrainé sur une cinquantaine
de 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 de
connaissances 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 faite
ici dans un cadre statique, le nombre de communauté étant fixe et n’évoluant pas au
cours du temps. Ce contexte particulier nous a conduit à développer une approche du
comportement 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 grandement la dissémination des connaissances en comparaison avec un système classique de
recherche.
2.5 Conclusion
La présentation du cadre théorique ainsi que de trois scénarios d’application a
permis de préciser le cadre de nos travaux. L’analyse de la structure d’un sytème de
gestion de connaissances selon l’approche AOA de Calmet a permis de donner des
définitions de la connaissance d’entreprise A partir 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 qui fournissent un cadre de travail prenant
en compte les différents aspects d’autonomie, de décentralisation, de modélisation
des connaissances ainsi que des mécanismes d’échanges. Le concept de communautés
virtuelles de connaissances permet de diffuser et d’étendre les connaissances d’une
société d’agents. La connaissance n’est pas limitée au domaine d’intérêt de chaque agent
mais comprend aussi les connaissances des 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 œuvre les différents aspects.
Les trois scénarios ont mis en valeur le potentiel d’applications qui découlent des
communautés virtuelles de connaissances.Le framework proposé dans le premier scénario, basé sur des échanges de connaissances entre des agents de contexte et des agents
personnels au sein de communautés permet l’intégration dynamique de nouveaux capteurs 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
56
agent de contexte lié à ce second capteur et de la modification des règles de décision
de l’agent personnel 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’aspect autonomie que présente l’approche agents et le scénario du réveil permet d’illustrer son fonctionnement. Le synthétiseur est le composant innovant de cette approche
qui permet de transformer les informations de l’agent en connaissances échangeables
avec les autres agent. Ces échanges basés sur les VKC permettent l’ajout dynamique de
nouveaux 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 communautés virtuelles au sein desquelles les utilisateurs mobiles pouvaient être non seulement
consommateur, mais producteur de services. Nous avons sur une approche orientée services 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écifications de la plate-forme communautaire. L’utilisation combinée des données de contexte
ainsi que service mobile permet la création de fonctionnalités avancées au sein de la
plate-forme communautaire. Ces travaux permettent de mettre en lumière le potentiel
économique des communautés virtuelles, notamment dans les applications mobiles. Les
communauté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ésentent
un 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-forme
Web 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 la
communautés. L’utilisation des communautés est faite ici dans un cadre statique, le
nombre de communauté étant fixe et n’évoluant pas au cours du temps. Ce contexte
particulier nous a conduit à développer une approche du comportement 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 grandement la dissémination des
connaissances 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 connaissances
ne contient pas seulement des ontologies, mais aussi trois autres composants (cognition,
communication et sécurité). Cependant, l’implémentation montre une différence de
traitement entre les différents composants. En effet les ontologies sont les seules parties
de la base de connaissances qui sont échangeables entre 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 qui ne permet pas réutiliser le code de
chacun des composants. Mais ces agents, basés sur JADE, sont programmés en JAVA, le
57
JAVA proposant des fonctionnalités de réflection dans le package java.lang.reflect
et offre la possibilité de transférer des portions de code exécutables entre des programmes
JAVA. Cette limitation dans le transfert des connaissances provient de l’architecture des
agents JADE. Les agents sont conçus pour échanger des messages au format FIPA-ACL
et pour gérer de manière interne des ontologies. Les parties exécutables qui sont les
comportements (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 est
l’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 ontologies
sont au format RDF, les composants responsables de la communication, cognition et
sécurité sont programmés en JAVA (une partie de la sécurité est en RDF, pour la description 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. La distinction
entre les parties échangeables et non échangeables de la base de connaissances soulève
plusieurs questions : une connaissance qui n’est pas échangeable est-elle une connaissance ? si oui, dans quelle mesure est-elle utile pour le système ? Quand peut-on parler
de connaissance ? Ces questions levées par un problème technique sont en fait d’ordre
théorique et touchent à la nature même de la connaissance. De la même manière que
l’AOA s’inscrit dans le cadre d’une théorie sociologique, il nous apparait important de
préciser le cadre épistémologique dans lequel nous nous plaçons. Notre état de l’art se
porte donc en premier lieu sur la notion de connaissance et de comment cette connaissance peut être mise en œuvre au sein d’un système informatique. Nous discutons dans
cette partie de la notion de connaissance au sens théorique, c’est-à-dire dans le domaine
de l’épistémologie ainsi que le domaine de la connaissance appliquée qu’est la gestion
des connaissances.
La distinction entre les composants échangeables et non échangeables (au sens
d’échange entre agents et non au sens d’interchangeable) de la base de connaissances
se 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 la
machine. Le but que nous nous fixons au cours de cette thèse, est de réussir à unifier
la base de connaissance, au sein d’un même formalisme afin de permettre l’échange
de n’importe quelle connaissances. Nous avons vu que la limitation était imposée par
l’architecture des agents JADE et par l’hétérogénéité des connaissances dans la base. Une
nouvelle architecture d’agent supportant une nouvelle base de connaissances doit être
mis en œuvre. Les deux domaines qui nous concernent, les agents (pour l’architecture) et
la représentation des connaissances (pour l’hétérogénéité) sont étudiés dans les sections
suivantes de l’état de l’art.
58
Les trois scénarios ont mis en évidence les domaines d’application variés des communautés virtuelles de connaissance. La mobilité, les applications sensibles au contexte,
le partage de documents et de connaissances sont autant de domaines ou nous avons
mis en œuvre ces communautés. Chacun de ces scénarios a montré un cas d’application
différent, nécessitant le développement de composants additionnels : sur JADE-LEAP
dans le premier scénario, d’interface pour les services Web dans le second et d’une plateforme 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 montre
un chemin qui intéresse plus nos recherches. En effet les VKC ne sont pas seulement
un espace d’échanges de messages comme nous l’avons vu dans la première partie de
ce chapitre. Une première constatation s’impose. Les VKC fonctionnant à l’aide d’un
tampon de messages ne sont qu’un instance de la classe des VKC. Ces VKC comprennent
tous les modes d’échanges entre agents. Se pose alors la question de la définition, de
la formalisation de ces communautés au sens plus large. Ces communautés une fois
formalisé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é ; souvent
mê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"
3
Etat de l’art
60
Chapitre 3. Etat de l’art
Plan du chapitre
3.1
Connaissances et gestion des connaissances . . . . . . . . . . . . . .
3.1.1
Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2
Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.3
Gestion des connaissances distribuées . . . . . . . . . . . . .
3.1.4
Conclusion de l’état de l’art sur la gestion des connaissances
.
.
.
.
.
61
61
67
68
70
3.2
Représentation des connaissances et Web Sémantique . . .
3.2.1
Web Sémantique . . . . . . . . . . . . . . . . . . . .
3.2.2
Ontologies . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3
Historique du Web Sémantique . . . . . . . . . . . .
3.2.4
Standards du Web Sémantique . . . . . . . . . . . .
3.2.5
Raisonneurs . . . . . . . . . . . . . . . . . . . . . . .
3.2.6
Conclusion de l’état de l’art sur le Web Sémantique
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
71
72
72
73
75
82
83
3.3
Agents et Systèmes multi-agents . . . . . . . . . . . . . .
3.3.1
L’agent . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2
Les systèmes multi-agents . . . . . . . . . . . . .
3.3.3
Domaines d’applications . . . . . . . . . . . . . .
3.3.4
Différents niveaux d’approche . . . . . . . . . .
3.3.5
Approche abstraite . . . . . . . . . . . . . . . . .
3.3.6
Architectures standards . . . . . . . . . . . . . .
3.3.7
Critères d’analyses . . . . . . . . . . . . . . . . .
3.3.8
Langages de programmation agents . . . . . . .
3.3.9
Plates-formes . . . . . . . . . . . . . . . . . . . .
3.3.10 Applications agents basés sur des connaissances
3.3.11 Conclusion de l’état de l’art sur les agents . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 84
. 84
. 86
. 87
. 87
. 88
. 89
. 94
. 96
. 107
. 111
. 121
3.4
Analyse et mise en perspective . . . . . . . . . . . . . . . . . . . . .
3.4.1
Agents et composants . . . . . . . . . . . . . . . . . . . . .
3.4.2
Echanges des différents types de connaissances . . . . . .
3.4.3
Un modèle unifié des connaissances et des comportements
.
.
.
.
.
.
.
.
3.5
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
3.5.1
Conclusion de l’analyse . . . . . . . . . . . . . . . . . . . . . . 133
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
122
123
126
127
Section 3.1. Connaissances et gestion des connaissances
61
gestion distribuée des connaissances est un domaine qui se situe à l’intersection
de plusieurs champs de recherche. Au nombre de trois, ces domaines existent indépendemment de notre domaine d’étude. Nous allons présenter dans ce chapitre ces
différents domaines. Nous commencerons tout d’abord par l’épistémologie qui est la
science de la connaissance, que nous mettrons en parallèle avec l’approche moderne de
la gestion des connaissances dans les organisations. Nous présenterons ensuite les techniques de représentation des connaissances. Le dernier domaine que nous présenterons
est le paradigme multi-agents ainsi que ses applications au domaine de la gestion des
connaissances.
L
A
3.1 Connaissances et gestion des connaissances
notion de connaissance en informatique peut être abordée de différentes maniè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. Avec
l’avènement de l’informatique, on peut distinguer plusieurs branches de recherches. la
gestion 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 informatiques. Le domaine de la représentation des connaissances, s’occupent des formalismes
permettant de représenter les connaissances. L’extraction des connaissances, qui traite
des manières automatisables de découvrir des connaissances à partir de données. Cette
liste n’entend pas être exhaustive, mais donne un aperçu du panel des recherches autour
de la connaissance et de l’informatique.
L
A
Nos recherches portent sur les différents types de connaissance et la manière de les
transférer entre agents (voir discussion, chapitre précédent).
La gestion des connaissances est un domaine de recherche très actif depuis les années
90, é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 ses
racines. La gestion des connaissances telle que nous la connaissons aujourd’hui est très
liée aux technologies numériques et aux réseaux. Pour mieux comprendre ce champ de
recherche nous donnons plusieurs définitions pour introduire le cadre dans lequel nous
nous 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’abord
introduire 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 long
de l’histoire un certain nombre de définitions et de discussions. Nous détaillerons les
62
différentes approches philosophiques et épistémologiques. L’apparition de la gestion
des connaissances au cours de années 80 a donné lieu à une autre approche, plus
pragmatique, de la connaissance. Nous présenterons et discuterons les définitions de
la connaissance au sens de la gestion de connaissance, puis nous établirons les points
communs 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 pourvue
de raison ».
Une opinion droite pour Platon est une opinion qui est vraie dans le sens ou elle
coincide avec la réalité. Pour autant cette coincidence avec la réalité pourrait être accidentelle, dans ce cas la connaissance n’aurait pas de valeur pour Platon. Il donne l’exemple
de la plaidoirie mensongère de l’avocat qui peut convaincre ses jurés à l’aide d’arguments faux. Pour autant cette plaidoirie ne constitue pas une connaissance puisque ses
fondements sont erronnés. Platon pose donc la restriction suivante : l’opinion droite
doit être « pourvue de raison ». Si par exemple je regarde la position de la lune pour
savoir si le Paris Saint-Germain gagnera la coupe de France cette année, il se peut que
l’interprétation que j’en fasse soit cohérente avec la défaite du club, pour autant je n’ai
pas de raison de croire que la position de la lune puisse m’indiquer la victoire ou défaite
du Paris Saint-Germain. Le terme "pourvue de raison" n’est donc pas ici par le fruit du
hasard. 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 convaincre
l’interlocuteur de la véracité de notre propos. Ce raisonnement, ne doit donc pas être
erronné 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émontrables
que l’on a énoncées ci-dessus. Les connaissances empiriques ou empiriques, comme
par exemple connaître le chemin d’un point A à un point B relèvent de l’opinion droite
et ne nécessitent pas de démonstration. Si quelqu’un me demande le chemin pour
aller au point B, je peux lui donner le chemin que je connais, pour autant je ne peux
pas lui démontrer que je connais ce chemin. Mon interlocuteur doit expérimenter le
chemin pour être convaincu de ma connaissance de ce chemin. Ces connaissances sont
donc distinctes des connaissances qui nécessitent une « opinion droite pourvue de
raison », puisqu’elles ne nécessitent pas de « raison valable », seule l’expérience peut
alors convaincre l’interlocuteur.
63
La théorie classique de la connaissance, ou épistémologie, se base sur la définition
de la connaissance comme une croyance vraie et justifiée (justified true belief ou JTB en
anglais). Une connaissance est donc une chose dont on peut donner une démonstration
qu’elle est connaissance (à l’exception des connaissances empiriques). De manière fomelle, 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 philosophe
Edmund Gettier, exhibe des contres-exemples à cette définition. Contre-examples dans
lesquels des croyances peuvent à la fois être vraies et justifiées sans pour autant constituer
une connaissance [Gettier63]. Voici un contre-exemple « à la Gettier » :
Alice a un ami Bob qui possède une guitare Stratocaster avec laquelle il
joue depuis des années. Alice pense donc que Bob joue sur une Fender. Mais
Alice ne sait pas que Bob avait brisé sa Stratocaster dans un accés de folie lors
d’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 joue
avec 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 hasard. Les travaux de Gettier ont une forte influence sur l’épistémologie et la philosophie
analytique moderne [Pacherie04], qui ont eu pour conséquences, non pas l’abandon
de la définition de la connaissance comme JTB mais au contraire, sa mise en place
comme définition minimale sur laquelle sont venus se greffer de nouvelles conditions
qui 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 de
la 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 ou
basé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 la
justification.
Ainsi, en épistémologie, on a observé l’importance de la notion de justification (et
donc de démonstration) pour établir une connaissance vraie. Les exemples de Gettier
ont 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 un
fait objectif » [Vilmer05]. La notion de perception de la réalité, qui reviendra notamment
64
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 de
connaissances doivent définir la nature de la connaissance pour déterminer la manière
de les opérationnaliser. Dans ses travaux, Bachimont se base sur les systèmes logiques
inférentiels. Il critique le formalisme de représentation des connaissances dans une
syntaxe formelle, en particulier sur la sémantique dont il permet de rendre compte, pour
proposer 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écessaire
dans le traitement automatique des connaissances. Des interfaces sont toujours requises
pour intéragir entre l’homme et la machine. Cette traduction s’opère dans deux sens pour
les 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 est
leur capacité inférentielle qui permettent d’expliciter des connaissances certes existantes
dans le système formalisé, mais qui ne sont pas encore apparus aux yeux de l’utilisateur
humain.
Les problèmes aux interfaces ne sont pas ici l’objet de cette thèse et nous nous
focalisons sur la représentation de connaissances qui ne sont pas inférentielles, mais
exécutables au sens des agents, c’est-à-dire produisant un effet sur l’environnement. Ce
type 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 les
dé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 souvent
de base à la définition des connaissances au sens de l’entreprise :
Définition (La connaissance, selon Johnson). « La connaissance est de deux types, soit nous
connaissons nous-mêmes le sujet, ou alors nous savons comment trouver de l’information sur
celui-ci. ».
Davenport et Prusak donnent quant à eux une définition de la connaissance par la
négative [Davenport00] :
Définition (La connaissance, selon Davenport et Prusak). « La connaissance, n’est ni des
données, ni de l’information. Elle est reliée aux deux. La différence entre données, information
65
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’information
sur un sujet, on a alors une connaissance de celui-ci. Dans cette définition la différence
entre connaissance et information reste floue. C’est la possession de l’information qui
en fait une connaissance. Cette définition indique donc qu’une connaissance ne serait
en fait qu’une information sur un sujet. La définition de Davenport, plus récente, a vu
entre temps la naissance de l’informatique et l’apparition du concept de données et de la
théorie de l’information. La connaissance est définie par opposition avec les données et
l’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 leur
domaines d’origine respectifs (base de données et théorie de l’information, que ce soit
celle de Shannon ou celle algorithmique de Kolmogorov). Les définitions suivantes sont
donné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 ne
connait pas le contexte (est-ce un capteur de température, de pression ?), cette donnée
ne 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 capteur
de 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 et
exploitation des données. Cette définition est certes peu claire, les auteurs ne prétendant
pas remplacer les définitions des épistémologistes mais veulent fournir une définition
applicable de la connaissance. La notion d’utilisation est parfois utilisée pour établir la
différence entre information et donnée [Balmisse02]. Dans l’exemple précédent, si l’on
sait que cette pièce est une chambre d’hôpital, on sera amené à prendre les décisions qui
s’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ès
courant 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 connaissance, 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ès
loins des discussions philosophiques qui précèdent. Leurs buts sont purement applica-
66
F IGURE 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 au
sein des organisations.
3.1.1.4
Discussion sur ces définitions
De nombreuses questions se posent aux vues des deux approches, épistémologiques
et gestion des connaissances, qui ne semblent liées que par le terme connaissance. Nous
nous intéressons alors au problème suivant : pourquoi n’y a t-il pas de rapport ou de
notions communes entre ces deux concepts et comment est-il possible de trouver un lien
entre les deux ?
Les deux approches diffèrent fondamentalement, l’approche philosophique aborde le
problème par un questionnement logique, avec une approche scientifique, qui supporte
la 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 mettre
en 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 approche
se 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 tardive
comparé à l’approche philosophique, mais deviendra un point crucial dans l’approche
récente, notamment par le biais des technologies du web sémantique qui seront utilisées
pour la représentation des connaissances. Mais si la notion de vérité est absente des
définitions du KM, c’est qu’elle est présupposée. On considère que les connaissances qui
seront intégrées au système de gestion sont vraies. C’est en fait un des fondements tacite
de cette approche.
Dans le domaine du KM, si les définitions de données, information et connaissance
sont largement acceptées, cependant, comme le montre T.D Wilson dans son célèbre
article « The Nonsense of Knowledge Management » [Wilson02]le domaine du KM
a constitué une bulle économique, en créant un effet de mode autour du KM, afin
67
d’en tirer des profits économiques. Cette dérive a conduit comme le montre Wilson
a 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 des
années 90, nous pensons que les problème posés par le KM sont bien réels, que ce soit
pour 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étaillerons
ensuite 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 supports
et celle des avancées techniques dans le domaine de ces supports. Les connaissances
humaines ont d’abord eu une transmission orale, puis l’écriture a permi la pérennisation du savoir. L’avènement de l’imprimerie a permi de diffuser plus largement les
connaissances. La transmission de connaissances tacites, regroupant souvent les connaissances empiriques, comme par exemple les savoir-faire artisanaux, a été rapidement
institutionnalisé. On trouve trace dès le dix-huitième siècle d’une institutionnalisation
de cette transmission de connaissances par le biais du compagnonnage (les premiers
écrits allemands traitent des « Wandergesellen », qui sont comparables au compagnonnage français). Certains historiens situent le début du compagnonnage à la construction
des églises médiévales en Angletterre. Ces immenses chantiers auraient été l’occasion
de mettre en place la transmission des connaissances artisanales. Cette méthode de
transmission perdure encore de nos jours notamment chez les charpentiers allemands.
En ce qui concerne les connaissances qui se transmettent par le biais du langage, le
dernier grand changement, après l’écriture et l’imprimerie est intervenu avec l’avènement de l’informatique qui a eu pour conséquence la dématérialisation du support et
une massification de l’accés à l’information. Les technologies de l’information ont permis
une 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 connaissances en tant que discipline académique en 1995 [Stankovsky05], sous l’influence des
sciences cognitives et de la psychologie [Wiig00].
Le but de la gestion de connaissances telle qu’on l’étudie actuellement est double. Il
est tout d’abord de pérenniser les connaissances d’une organisation et d’améliorer sa
gestion, et deuxièmement de pouvoir évaluer la valeur du capital des connaissances
68
détenues par l’organisation. Pour ce faire, de nombreux outils et méthodes de gestion
et d’évaluation ont été développés. Dans notre travail, le premier point, c’est à dire
la pérennisation, transmission et gestion des connaissances sera le seul objet de notre
attention. Le deuxième concerne des considérations économiques, qui sont ici hors de
notre propos.
3.1.2.1
Outils et Méthodes
Les outils électroniques de gestion de connaissance sont au départ des systèmes destinés à être utilisé par les managers pour disséminer l’information (Manager Information
System ou MIS). Ils ont ensuite évolué vers des outils d’aide à la décision (Decision Support Systems ou DSS), puis sont devenus des systèmes capables de délivrer l’information
en 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égration
de 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 approche
centralisée, autour d’un dépôt de connaissances, mis en place et maintenu par des
experts. Les outils de travail collaboratifs électroniques font leur première apparition
notable 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 en
plus nombreux au fil des années.
Ehrig montre que l’approche centralisée est coûteuse [Ehrig03] et que son coût de
maintenance est élevée. Vers le milieu des années 90, de nouvelles approches sont développé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’une
organisation il est impossible qu’une entité puisse détenir toutes les connaissances, et
que par conséquent les connaissances sont non seulement distribuées géographiquement et au niveau des entités qui les détiennent, mais aussi que cette distribution fait
partie d’un contexte sur lequel l’organisation n’a pas de contrôle (le marché, les autres
organisations, . . . ). Ces travaux signent le départ d’une nouvelle approche, antagoniste
de l’approche centralisée, dans laquelle les entités participant à une organisation jouent
un rôle premier.
3.1.3
Gestion des connaissances distribuées
Une fois le verrou de la centralisation identifié, les premières approches distribuées
ont été mises en oeuvre. En 1999 dans [Alavi99], les auteurs montrent que 36% des
KMS utilisent des filtres ou agents. Cependant le mélange dans une même catégorie des
69
notions de filtres et d’agents ne permet pas de conclure quant à l’utilisation des agents
dans les KMS. Les approches purement décentralisées apparaissent en 2002 avec les
travaux de Bonifacio, tout d’abord dans des travaux théoriques sur les « Knowledge
Nodes » [Bonifacio02c] puis par le système Kex [Bonifacio02b]. On peut aussi noter
l’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 objectiviste 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é de
disposer 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 un
modèle unique. Les systèmes centralisés maintenus par des experts en sont l’exemple
le plus pertinent, dans ces systèmes les ontologies de domaines créées par l’expert
constituent le modèle unique de représentation des connaissances.
En analysant la structure de ces KMS, Bonfacio montre que l’organisation interne
et la hiérarchie au sein des KMS est semblable à l’organisation et à la hiérarchie des
compagnies [Bonifacio02a]. Cette approche de contrôle hiérarchique est incompatible
avec la nature distribuée de la connaissance. En effet les échanges de connaissance dans
les organisations entre les membres ne transitent pas dans la pratique par les chemins
de sa structure hiérarchique, les échanges entre les employés étant très nombreux. L’approche distribuée permet donc de prendre en compte les aspects distribués du stockage
et des échanges au sein des organisations. L’approche de Bonifacio se base sur une
approche différente de la notion même de connaissance. La notion d’autonomie est centrale dans l’approche de Bonifacio, chaque communauté maintient une représentation
des connaissances, la notion de coordination entre les communautés permet l’échange
de connaissances entre différentes représentation. Chaque communauté possède un
contexte qui est une représentation explicite du schéma d’interprétation de la communauté. 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 (Enabling Distributed and Autonomous Management of Knowledge) qui est la première architecture de gestion de connaissances distribuées [Bonifacio02a]. La figure 3.2 présente
l’approche distribuée au sein d’EDAMOK.
L’architecture reproduit le processus social dit de négotiation du sens en utilisant des
protocoles 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 un
processus 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 des
matching avec le contexte (c’est à dire l’interprétation) d’autres communautés. Ce rôle
70
F IGURE 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 pour
l’utilisateur local.
Le système KEX que nous présentons en section 3.3.10.3 est la plate-forme implémentant l’approche distribuée de EDAMOK. Parallèlement les systèmes d’information multiagents se développent et on assiste à partir de 2003 à la réunion des deux domaines lors
des é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 de
la 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 des
connaissances.
La définition de la connaissance qui est utilisée dans l’approche appliquée de la
gestion 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ées
et 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’un
capteur et représentent une suite de bits, sans signification. Ces données sont ensuite
traitées pour en calculer la température mesurée par le capteur, ce qui constitue alors
l’information. Si l’on extrait d’un relevé de température fournie par le capteur un modèle
qui décrit l’évolution de la température dans cette pièce, on a alors extrait une connaissance à 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. Mais
le but d’un système de gestion de connaissances est, comme de nombreux systèmes
informatique, 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 doit
prévaloir, plutôt qu’une approche technique. Ce raisonnement ne s’applique pas seulement à la définition de la connaissance en tant que "tout ce qui n’est pas information ou
données", mais à toute définition de la connaissance qui est imposée par la structure de
la machine qui est amenée à traiter les connaissances. La définition épistémologique ("La
connaissance est une opinion droite pourvue de raison) nous semble être plus proche du
fonctionnement "humain", c’est donc cette définition qui selon nous, doit être au centre
des systèmes de gestion des connaissances.
Les travaux de Bonifacio ont mis en évidence la notion d’autonomie de la connaissance et ont ouvert la voie à la gestion décentralisée des connaissances. Cependant
l’autonomie de la représentation des connaissances se limite au domaine de la communauté. Cette autonomie de représentation doit être étendue complètement jusqu’aux
entités qui composent les communautés. Les techniques de représentation des connaissances 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 de
données décrivent et raisonnent sur des aspects du monde réel. Le but de ces systèmes est
de pouvoir stocker de manière électronique les connaissances. Certains de ces systèmes
sont basés sur des paradigmes logiques, comme le Prolog, les Frame-Logics et le Web
Sémantique, nous restreindrons notre domaine d’étude à ces systèmes. On caractérise
ces systèmes par les hypothèses qui sont faites, sur la nature des connaissances et sur la
logique qui y est utilisée. On distingue les caractéristiques suivantes [Hustadt94] :
Monde Fermé Toutes les informations qui ne sont pas connues comme vraies sont
fausses. C’est le principe du tiers exclu.
Monde Ouvert Il peut exister des faits qui soient vrais et qui ne sont pas contenus dans
le systèmes
Domaine fermé Il n’existe pas d’autres objets dans le monde que ceux désignés par les
variables du système.
72
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 être
en contradiction.
Paraconsistant Système logique qui tolère les inconsistances. Ces systèmes sont considérés comme inintéressant par les spécialistes de la logique [Girard07]. Nous les
laisserons donc volontairement en dehors de notre étude.
De nombreux formalismes et outils ont été développés pour répondre à cette question 1 et il serait long et fastidieux de les lister. Actuellement, les standards et technologies
issus du Web Sémantique, basés sur la notion d’ontologies tendent à supplanter les autres
techniques de représentation.
3.2.1
Web Sémantique
Le World Wide Web grossit à une vitesse très grande (26 millions de pages indexées
par Google en 1998, un milliard de milliard en 2008 2 ) et la recherche d’information
au sein du réseau est rendue difficile par la structure des pages internet. En effet les
liens dans le web classique sont des liens entre des pages et ces liens ne contiennent pas
plus 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 sur
des analyses statistiques des pages et sur les liens qui les relient entre elles. Le pagerank
de Google est l’exemple le plus célèbre à jour. Le but du web sémantique n’est pas de
remplacer le web classique, mais d’y apporter une structure, afin que les informations
puissent ê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 philosophique. En philosophie l’ontologie est l’étude de l’être en tant qu’être, c’est à dire les
propriétés générales de ce qui existe. De la même manière le terme informatique définit
une ontologie comme un ensemble de termes et de propriétés [Gruber93].
Les ontologies ont initialement été développées comme technique de représentation
des connaissances vers la fin des années 80. Le but d’une ontologie est de modéliser un
ensemble de connaissances dans un domaine donné.
Une ontologie est un ensemble structuré des termes et concepts représentant le sens
d’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_representation
accédé le 09/11/09
2. http://googleblog.blogspot.com/2008/07/we-knew-web-was-big.html
accédé le 09/11/09
73
les éléments d’un domaine de connaissances. L’ontologie constitue en soi un modèle
de données représentatif d’un ensemble de concepts dans un domaine, ainsi que les
relations entre ces concepts. Elle est employée pour raisonner à propos des objets du
domaine 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 en
HTML :
<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 ne
contient 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-tend
le web sémantique est de structurer le contenu du web, en particulier avec l’idée de
typer les liens qui relient les informations afin de permettre le traitement automatique.
Pour cela, le formalisme des ontologies se prètent parfaitement à cet exercice. Avant
l’avènement des technologies actuelles du web sémantique, de nombreux projets qui
font maintenant figure de pionniers présentaient déjà l’idée de fusionner les technologies
du web et les ontologies. Nous présentons ici quelques uns des projets dont les idées
préfiguraient les standards actuels du consortium W3C.
Le projet SHOE [Heflin00] pour Simple HTML Ontology extension est une extension
du langage HTML qui permet d’annoter une page HTML en se basant sur le vocabulaire
défini dans les ontologies importées. La page web suivante est un exemple de page non
annoté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.
74
<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">
75
<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 une
description sémantique manipulable par une machine. La représentation ci-dessus est
une reformulation du texte écrit en langage naturel dans le formalisme SHOE et il ne se
substitue 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 Horn
sans 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 les
autres outils, on citera Concerto [Zarri99], LogicWeb [Loke98], qui s’appuient sur une
dé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éé en
1994 par Tim Berners-Lee avec le soutien du CERN et du MIT 3 . Les standards dont nous
parlerons ici, ne sont pas des standards au sens normes de la commission européenne
ou ISO, mais des standards industriels qui sont en fait des recommandations de bonnes
pratiques.
Les différents standards du web sémantique sont résumés dans la figure 3.3 communément appellée Semantic Web Layer Cake ou Gâteau en couches du web sémantique. Cette
figure montre l’empilement des différentes couches, les couches supérieures se basant
sur 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, XML
pour la structuration des documents et les Namespace pour la réutilisation des balises
de sources différentes.
XML Query et XML Schema sont des outils permettant l’exécution de requètes sur
les documents XML (XML Query) et la définition de la structure de ces documents (XML
Schema). 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
76
F IGURE 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 (et
RDFS) 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écrites
en 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 assurer
la sécurité et la confiance à l’aide de signature digitale des ressources RDF/OWL. Les
couches "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. Il
a été développé par le World Wide Web consortium (W3C) pour faciliter l’écriture
et l’échanges de données structurées dans un format texte. Adopté en 1998 en tant
que recommandation par le W3C, le XML a connu depuis un essor considérable. Tous
les 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 grande
interopé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>
77
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 du
W3C [Klyne04]. Initialement prévu pour représenter un modèle de données pour les
mé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 être
des 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
78
Pour écrire des documents RDF, on dispose de nombreuses syntaxes. La plus courante
est 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 de
langages dédiés à l’écriture d’ontologies. On peut le considérer comme la suite logique
des travaux sur les langages SHOE et DAML+OIL [Horrocks03]. Une ontologie OWL
dé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 permettre d’obtenir une fondation plus solide que pour RDF. OWL permet l’égalité entre
des propriétés, les concepts de classes équivalentes, d’égalité de deux ressources, de
leurs 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 de
description 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éveloppement des outils pour OWL Lite s’est montré aussi coûteux que pour OWL-DL
qui est pourtant bien plus expressif. De fait OWL-Lite, qui était dédié à une utilisation simple, par exemple pour la rédaction de taxonomies, est maintenant très
minoritairement utilisé.
OWL-DL : ce langage a été conçu pour permettre le maximum d’expressivité tout en
gardant les propriétés de décidabilité, de complétude et l’existence d’algorithmes
efficaces pour l’implémentation de raisonneurs. Tous les constructeurs OWL sont
présents dans OWL-DL, mais ils sont soumis à certaines restrictions qui garantissent la décidabilité et la complétude.
OWL-Full : est basé sur une sémantique quelque peu différente de OWL-DL, puisqu’il assure une interopérabilité avec RDF Schema. OWL-Full ne garantit pas les
propriétés de décidabilité et de complétude.
Parmi ces trois langages, OWL-DL est indéniablement le plus utilisé puisqu’il garantit la décidabilité et la complétude. De plus, il existe de nombreux raisonneurs pour
l’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/
79
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 fait
maintenant une technologie de choix non seulement pour des projets académiques mais
aussi industriels 6 [Lacy04, Anicic07, Lacy05].
3.2.4.4
SWRL
Le langage de règles pour le web sémantique (Semantic Web Rule Language) est
une proposition de langage [Horrocks04] dont les spécifications ont été soumises au
W3C par un consortium composé du CNRC (Conseil national de recherches Canada), de
l’université de Stanford ainsi que de l’entreprise Network Inference.
SWRL combine les langages OWL-DL et Rule-ML [Boley01]. Etonnament, le consortium a proposé un langage qui n’est pas décidable, ce qui rend l’implémentation de
raisonneurs SWRL impossible. Pour l’implémentation de raisonneurs, un sous ensemble
de règles SWRL est utilisé, qui est appellé SWRL-DL. La construction de SWRL-DL en
partant 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 (aussi
communément appellées conditions et conclusion). La syntaxe abstraite des règles est la
suivante :
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 RDF
pour 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 OWL
http://www.webont.org/owled/
80
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>
</ruleml:_body>
<ruleml:_head>
<swrlx:individualPropertyAtom swrlx:property="oncleDe">
<ruleml:var>z</ruleml:var>
<ruleml:var>y</ruleml:var>
</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 conditions 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 axiome
OWL :
axiom ::= rule
Conclusion sur SWRL
Bien que toujours à l’état de proposition de standards, de nombreux raisonneurs
ont été développé pour SWRL (Pellet, Bossam, . . .), ainsi que des outils d’édition de
règles (SWRLTab pour Protégé). L’adoption rapide par la communauté du SWRL laisse
entendre 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:propertyPredicate rdf:resource="frereDe"/>
<swrl:argument1 rdf:resource="#z" />
<swrl:argument2 rdf:resource="#x" />
</ruleml:body>
<ruleml:head rdf:parseType="Collection">
<swrl:propertyPredicate rdf:resource="oncleDe"/>
<swrl:argument1 rdf:resource="#z" />
<swrl:argument2 rdf:resource="#y" />
</ruleml:head>
</ruleml:imp>
81
82
3.2.4.5
RIF
Le format d’échange de règles (Rule Interchange Format ou RIF) est un ensemble
de standards et d’outils pour permettre l’échange des règles sur le Web. Les standards
RIF 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 de
rè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 et
conclusions des règles sont monotones. Il n’est pas possible de changer la valeur
d’un prédicat. BLD supporte les fonctionnalités suivantes (en plus de celles du
noyau) :
– Egalité dans la conclusion
– Fonctions logiques
– Listes ouvertes
– Appartenance dans la conclusion
– PRD (Production Rule Dialect) : Dans ce dialecte des règles de production, les
conditions et conclusions des règles sont non-monotones. Les fonctionnalités sont
les 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 au
travers d’une syntaxe commune. La seule syntaxe du RIF (à la différence de RDF par
exemple) est basée sur XML. La philosophie de RIF est de ne pas restreindre les outils
du web sémantique à l’utilisation d’un seul type de logique. Pour favoriser la communication de règles entre des partenaires (commerciaux ou non), le groupe de travail s’est
fixé comme but l’adoption des standards présentés ainsi que leur mise en œuvre. De
nombreux 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 raisonnement logique sont nécessaires. Ces outils, appellés raisonneurs sont des logiciels
7. http://www.w3.org/2005/rules/wiki/RIF_Working_Group
8. http://www.w3.org/2005/rules/wiki/Implementations
83
capables d’inférer les conséquences logiques d’un ensemble d’axiomes et de règles. De
nombreuses propriétés caractérisent les raisonneurs et nous présentons ici celles qui
sont en lien avec nos travaux.
Définition (Raisonneur correct et complet). Un raisonneur est dit correct et complet si il
possè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ée
sur l’autel de l’efficacité. Il existe donc des raisonneurs efficaces mais non complets. De
nombreux raisonneurs affichent, pour des raisons commerciales, ces propriétés comme
établies, certaines recherches tendent à prouver le contraire [Weithoener06]. Le fait que le
raisonneur 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’accorder
de valeur aux inférences produites, puisqu’il serait impossible de savoir si elles sont
justes 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 moins
importante, 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, on
recherchera toujours un raisonneur possédant les deux propriétés de correction et de
complétude.
Une liste de raisonneurs OWL est donnée par le W3C 9 . Nous ne détaillons pas ici les
caractéristiques des différents raisonneurs, mais justifions dans le chapitre concernant
l’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 description. La non-monotonie de ces logiques ainsi que l’hypothèse de monde ouvert ont
considérablement freiné le développement de ces technologies qui jusqu’à l’OWL était
extrêmement simple. Le fait qu’aucun langage de règles n’ait encore été choisi comme
standard par le W3C (même si on peut parier sur le SWRL) montre que la technologie
n’est pas encore matûre pour une utilisation industrielle 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 permis l’accélération du développement de
formats et de technologies pour la représentation des 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 et standards du Web Sémantique trouveront (et
9. http://www.w3.org/2007/OWL/wiki/Implementations
84
trouvent déjà) un champ d’application dans toutes les applications touchant à la gestion
de 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ée
au chapitre précédent. En effet dans un tel système logique, il est possible de justifier
par l’utilisation de raisonneur de la validité d’une proposition au regard d’un système
d’axiomes et de règles de dérivation. Les raisonneurs permettent aussi de vérifier la
consistance 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èse
d’un monde ouvert nous parait parfaitement adapté à nos besoins de représentation et
d’inférence dans le cadre de nos recherches.
La partie suivante fait le point sur les systèmes multi-agents, domaine dans lequel
les 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 connaissances. 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’agents
et de systèmes multi-agents ont déjà été évoqués, notamment dans le contexte de la
gestion décentralisée des connaissances en section 3.1.3. Nous allons présenter ici, le
paradigme multi-agent et nous allons étudier plus en détails les architectures des agents
manipulant 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 indiquons
les domaines d’application des systèmes multi-agents. Nous définissons ensuite les
critères correspondant à nos besoins dans l’étude et nous analysons les approches
existantes dans trois sous-domaines : les langages de programmation agent, les platesformes 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 compré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 consensuelle
du concept d’agent, chaque auteur donnant sa propre définition, en fonction de son
domaine de recherche et de son point de vue. Nous présentons ici, deux définitions
d’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ème
définition plus forte [Wooldridge95]. Nous présentons ensuite la définition proposée
par 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 ces
décisions.
– Capacité sociale : un agent intéragit avec les autres agents par le biais de moyens de
communications.
– 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 de
maniè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’agents
comprend les propriétés énoncés dans la définition faible auxquelles s’ajoute le fait que l’agent est
conceptualisé 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 qui
peuvent reproduire des émotions humaines ainsi que tout les agents qui sont en contact
direct avec l’utilisateur humain. L’architecture d’agent basée sur la logique (décrite en
section 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 système informatique, situé dans un environnement, qui est capable d’actions flexibles et autonomes
pour accomplir les tâches qui lui sont assignées. ».
Boissier propose une définition minimale de l’agent : "Un agent est un programme
informatique autonome, plongé dans un environnement qu’il est capable de percevoir
et sur lequel il est capable d’agir". Puis il propose trois types d’architecture pour classer
les agents [Boissier01] :
– Architecture d’agent autonome : architecture possédant des capacités de perception
et d’action sur son environnement. Ne possède pas explicitement de capacité de
coopération.
86
– Architecture d’agent interagissant : possède des capacités d’intéraction avec
d’autres agent du système. Possède éventuellement des descriptions des agents et
peut les influencer par envoi de messages.
– Architecture d’agent social : l’agent social est le niveau supérieur de l’agent interagissant. Les entités organisationnelles sont formalisées et prises en compte par
l’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équence
possible de perceptions, un agent rationnel sélectionnera une action qui maximisera sa mesure de
performance, étant donnée l’information apportée par la séquence de perceptions et quelles que
soient les connaissances dont dispose l’agent. ».
Dans ces définitions on retrouve de nombreux points communs et on peut sans
hé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 agents
ne 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.4
montre la représentation d’un agent dans son environnement telle que proposée par
Wooldridge [Wooldridge99] et illustrant les trois attributs énoncés précédemment.
F IGURE 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 sein
de cette société, les agents peuvent être amenés à coopérer. Les agents peuvent aussi se
87
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çus
pour travailler coopérativement à la résolution d’un objectif commun.
– Systèmes ouverts : Système dans lesquels les agents ne partagent pas nécessairement un but commun et peuvent être en compétition. Les agents peuvent dynamiquement 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èmes
dans des domaines variés. On trouve notamment des applications dans le domaine de
la 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 » 10 sont très orientées vers
les applications pratiques et les démonstrations des systèmes multi-agents. Les actes de
ces conférences fournissent de nombreux exemples d’application des systèmes multiagents à 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 allons
décrire ces niveaux, du plus général vers le plus précis. Pour mieux comprendre, on
pourrait 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 niveau
d’entités individuelles telles que le consommateur et voit l’économie comme la somme
des actions de ces entités, c’est à-dire d’un point de vue émergent. La macroéconomie
se situe quant à elle au niveau de grands agrégats économiques telles que l’inflation, le
chômage, . . . Le problème de l’économie est donc abordé par le haut, au travers d’une
vision plus globale.
Dans l’approche la plus globale, on considère le système multi-agent dans son
ensemble, on parle alors de société d’agents [Shoham95]. Le comportement global est
déterminé par l’ensemble des agents. Cette approche est notamment considérée dans le
cadre d’applications collaborative où les agents travaillent ensemble à l’accomplissement
d’une tâche, ou pour l’observation de phénomènes émergents dûs aux intéractions des
différents agents.
A l’inverse de cette approche globale de société d’agents, il existe plusieurs approches
qui se concentrent sur l’agent en tant qu’entité individuelle. L’étude des architectures
10. http://www.paams.net
88
d’agents est une de ces approches. L’architecture des agents désigne les composants et
leur 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 "autonomic computing" introduite par IBM en 2001 [Horn01, Kephart03, Ganek03]. Ce domaine
se focalise sur l’architecture d’agents autonomes mais en lui ajoutant des propriétés supplé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 au
niveau de l’agent en lui-même. Nous présentons dans la section suivante les différentes
architectures standards d’agents. Nous nous intéresserons ensuite à la capacité de réflexivité, dont nous présenterons les fondements logiques ainsi que des architectures
d’agents supportant cette propriété.
3.3.5
Approche abstraite
On peut formaliser simplement les considérations précédentes sur les composants
d’un système multi-agent. On commence d’abord par définir l’environnement dans
lequel évolue les agents. L’environnement E est défini comme un ensemble d’états
d’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 des
actions : A = a1 , a2 , . . ..
Wooldridge propose de définir un agent comme une fonction qui a une séquence
d’états d’envrionnement associe des actions : agent : seq( E) → A ou seq( E) est l’ensemble des séquences d’éléments de E. Le caractère discret et séquentiel (évolution
suivant le temps) de l’environnement est une conséquence de cette définition. l’environnement 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 de
l’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 perception
pour les agents réactifs, ce qui implique leur omnipotence (une connaissance parfaite et
totale de l’environnement). Nous préfèrerons considérer pour la suite que tout agent
est 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 être
erronnée et d’une précision finie.
A partir de ces définitions on peut caractériser quelques architectures simples
d’agents :
89
– Réactive : L’agent purement réactif réagit à l’état actuel de l’environnement, il est
donc caractérisé par la fonction suivante : E → A.
– Agents à états : On considère maintenant que l’agent est doté d’une représentation
interne de données qui leur permet de sauvegarder des informations concernant
l’environnement ainsi qu’un historique interne. Soit I l’ensemble des états internes
de l’agent. On dénote P l’ensemble des perceptions possibles de l’agent sur l’environnement. Un agent à états est alors caractérisé au moins par les deux fonctions
suivantes :
– 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 leurs
propriétés et les concepts sous-jacents à la notion d’agent. Dans cette partie nous allons
présenter différentes architectures concrètes, au sens ou ces architectures sont implémentées et utilisées dans des applications ou des prototypes de recherche. Nous considérons
5 classes d’agents, qui sont organisés chronologiquement.
– Agents basés sur la logique : Les décisions sont effectuées par des déductions
logiques sur l’état interne de l’agent.
– Agents Réactifs : Les décisions de l’agent sont des conséquences directes de l’état
de l’environnement.
– Agents Pro-actifs : ont comportement orienté vers un but et ils sont capables de
prendre des initiatives afin de satisfaire le but assigné.
– Architectures en couches : dans lesquelles la décision est faite par différentes
couches, les différentes couches permettent des raisonnements à différents niveaux
d’abstraction.
– Architectures BDI : pour "Belief Desire Intention" ou Croyance Désir Intention
en français. Les décisions sont prises selon les désirs, croyances et intentions de
l’agent.
3.3.6.1
Architectures basées sur la logique
Cette approche s’est développé au sein de l’approche symbolique en intelligence
artificielle, et dans la continuité des recherches de la programmation logique qui ont
amené au développement de Prolog, qui sera très largement utilisée pour l’implémentation des agents basés sur la logique. L’agent est capable de manipuler des symboles
qui 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 formules
de la logique du premier ordre, qui appartient à l’ensemble de tout les ensembles des
90
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 pas
contradictoire avec son état interne et les règles de déduction ρ. Pour cela on définit
un 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 de
déduction ρ, alors l’action a est valide, et doit être exécutée. De la même manière toute
action 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 construction du comportement de l’agent, de nombreux problèmes importants la rende quasiment impossible à implémenter. En effet, dans le modèle, l’agent doit énumérer la
liste d’actions possibles est vérifier que leur exécution serait déductible. Cette opération
de déduction est à elle seule extrèmement couteuse en temps. Le second problème est
celui de l’ordonnancement des actions. En effet, plusieurs règles de déduction appartenant à ρ peuvent être valides sur E, ainsi plusieurs actions peuvent être éxecutables
en même temps. Au niveau de l’implémentation, puisque l’agent dispose d’un nombre
fini de processeurs, il faut établir une séquence d’exécutions des actions. Une solution
est de prioriser les règles de déduction, c’est-à-dire d’ordonner les élements de ρ, pour
obtenir une séquence d’actions. Cependant les différentes implémentations existantes
de Prolog ne permettent pas de donner de priorité aux règles. Une même exécution
donnera le même ensemble de résultats mais l’ordonnancement est variable selon le
chemin d’exploration.
Les architectures basées sur la logique telles que proposées sont certes très élégantes
et d’un formalisme agréable à la lecture, elles sont malheureusement trop coûteuses en
temps de calcul pour être efficace.
3.3.6.2
Réactives
A l’inverse du développement du calcul symbolique en intelligence artificielle, des
chercheurs ont voulu développer au cours de la fin des années 80 une approche qui
soit 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 avec
l’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 il
n’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
91
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 propose
d’introduire une relation d’ordre total ≺ sur l’ensemble des couples ( p, a), ou p est
la perception d’une situation et a une action. Dans le cas ou plusieurs règles sont
applicables, 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, ou
couples ( p, a)) en calculant l’ensemble des actions exécutables, puis de sélectionner le
couple ( p, a) de priorité maximale [Wooldridge99]. Les algorithmes choisis par Wooldridge ne sont pas explicités mais nous proposons une solution en O(n) en parcourant
une seule fois les couples ( p, a) :
6
début
Données: B ensemble des règles de comportements
Entrées: s perception de l’environnement actuel
Sorties: (c, a) couple de priorité maximale
temp ←− (0, 0)
pour chaque ( x, y) ∈ B faire
si x == s alors
si temp ≺ ( x, y) alors
temp ←− ( x, y)
7
fin
1
2
3
4
5
On remarque que pour la relation ≺ l’ordre total n’est pas requis, on peut réduire à un
ordre partiel entre tout couple (s, x ) (s, y) avec s la perception de l’environnement et
et ∀s ∈ P; x ∈ A, (0, 0) ≺ (s, x ). En effet les couples n’ont besoin d’être comparé que
lorsque s est identique, c’est-à-dire pour une même perception. Tout autre comparaison
entre deux perceptions ne sera pas effectuée par l’agent et devient par conséquent
superflue. Dans notre algorithme (0, 0) est la valeur d’initialisation qui est l’élément le
plus petit des couples (s, x ).
L’approche réactive gagne donc en simplicité, complexité et vitesse d’exécution par
rapport à l’approche logique, mais se limite à l’exécution de comportements basiques. Il
est impossible d’exécuter des comportements plus complexes avec cette architecture,
comme par exemple les comportements où l’agent prend des initiatives pour accomplir
un but, que nous présentons dans la section suivante. Les architectures réactives sont
adaptées aux agents dont les ressources sont limitées.
92
3.3.6.3
Proactives
A l’inverse des architectures réactives, les agents proactifs sont des agents qui ont
une capacité d’initiatives et qui ne répondent pas seulement à un stimulus de l’environnement.
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’axiomatisation de cette théorie et son implémentation est due à Rao et Georgeff [Rao95]. Un
agent 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].
F IGURE 3.5 – Architecture BDI [Georgeff89]
L’approche BDI a donné lieu à de nombreuses implémentations, dans son état de
l’art [Mascardi05], Mascardi présente en 2005 neufs langages et systèmes implémentant
l’architecture BDI.
93
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 une
représentation des connaissances des agents à l’aide de symboles explicites, contrairement à l’architecture connectionniste présentée à la section précédente. Ces agents basés
sur des connaissances sont une catégorie d’agents intelligents. La spécificité de cette
classe d’agents est de pouvoir manipuler des connaissances.
Les agents basés sur des connaissances disposent au moins des deux composants
suivants :
– Une base de connaissances
– Un mécanisme d’inférence
La 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 appartenant
au 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 de
l’agent pour décider des actions que l’agent va exécuter. Ce comportement peut être mis
en œ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 modifier ses structures au cours de son exécution. Cette propriété intéressante est présente
dans 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é se
définit de manière similaire. Nous décrivons dans une première partie les fondements
logique du concept de réflexivité (et sa proxémie avec le concept d’introspection dans
le domaine de la logique). Puis nous étudions en détail les architectures ou modèles
d’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 une
approche logique, qui suit les définitions présentés précédemment. Costantini et ses
coauteurs présentent une architecture d’agents réflexifs basés sur le langage Reflexive
Prolog [Costantini92].
L’application présentée est la résolution du problème des trois hommes sages. Ce
problème est un exemple classique d’utilisation de méta-raisonnement et dans le cadre
d’agents, de l’utilisation de la réflexivité. Le problème est le suivant :
94
Un roi veut savoir lequel de trois hommes est le plus sage, il pose un chapeau sur la tête de
chacun des sages. Chacun pouvant voir le chapeau des autres sans pouvoir voir le sien. Il leur dit
alors : "Vous avez chacun un chapeau, il est soit de couleur blanche ou noire, et il y a au moins
un chapeau blanc", en fait, tout les chapeaux sont blancs. Il leur demande ensuite successivement
la couleur de leur chapeau. Le premier et le second répondent qu’ils ne savent pas, le troisième
répond alors "le mien est blanc". Pour déterminer la couleur de son chapeau, le troisième sage fait
le raisonnement suivant : "si mon chapeau est noir, dans ce cas le second sage verrait un chapeau
blanc et un chapeau noir. Il conclurait alors, que si son chapeau est noir, le premier aurait conclu
que son chapeau est blanc, mais il a dit qu’il ne savait pas, son chapeau serait donc blanc. Puisque
le 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 commune
ou 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 est
adaptable à N sages.
Approche par composants
La seconde approche de la réflexivité est par échange de composants. Dans cette
approche on considère les comportements des agents comme des modules qui sont
échangeables entre les agents, chaque agent a donc connaissance de sa propre structure
et des modules qui la composent. Il est donc en mesure de raisonner sur son architecture, 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 de
comportements 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, qui
constituent la séquence des actions a éxécuter pour atteindre un but donné. Antona et ses
co-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 et
des systèmes multi-agents. L’étude qui va suivre s’oriente plus particulièrement sur les
critè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 pour
formuler notre proposition. Les langages de programmation d’agents, ainsi que certaines
plates-formes présentées en section 3.3.9, ont en commun deux choses. Tout d’abord
l’agent possède une représentation de son environnement et de ses connaissances (ou
croyances selon les architectures). D’autre part l’agent est doté de comportements qui se
95
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érentes
approches, nous spécifions ici les critères qui nous concernent pour la représentation
des connaissances et pour l’expression des comportements. Ces critères sont représentés
dans la figure 3.6.
Agent
Représentation des
connaissances
Comportement
• Technologie
• Décision
• Logique
• Logique
• Complétude (domaine
ouvert/fermé)
• Réflexivité
• Hypothèse de monde
ouvert/fermé
F IGURE 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’expressivité 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 choix
technologique. La réprésentation peut représenter un domaine fermé si tout les types de
connaissances sont connus au départ. Dans le cas contraire le domaine est dit ouvert, de
nouveaux 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 monde
fermé. La logique en monde fermé (type base de données, Prolog) stipule que c’est qui
n’est pas explicitement vrai est faux. A l’opposé, la logique en monde ouvert ce qui
n’est pas explicitement faux ni explicitement vrai est inconnu. Nous discuterons dans
l’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’un
agent peut intervenir à la fois dans l’inférence de la base de connaissance, mais aussi
96
dans le processus de décision d’un agent (i.e. dans son comportement). Il est aussi
possible que deux logiques différentes soient utilisées. Ce qui explique la présence de la
colonne logique dans chacun des tableaux qui vont suivre.
Concernant le comportement de l’agent, l’architecture utilisée est un aspect important de classification (BDI, réactive, . . .). Dans les cas ou la logique est utilisée dans le
processus de l’agent, nous nous intéressons au type de logique utilisée. Des logiques
plus ou moins expressives, décidables ou indécidables, influent particulièrement sur les
capacités d’un agent. La capacité de réflexivité d’un agent, c’est-à-dire d’acquérir des
connaissances sur son propre état d’exécution, sur ses connaissances permet d’augmenter
les capacités des agents. L’échange de comportement qui est une de nos problèmatiques
est 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 programmation
agents qui intègrent la notion de connaissance. Nous étudions ensuite les plates-formes
d’agents qui pour certaines spécifient un certain type de représentation des connaissances et/ou un certain de type de comportement. Puis nous étudions les applications
utilisant des agents intégrant des bases de connaissances. Nous concluons cette étude
par 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 approches
spé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 de
la recherche en agents autonomes s’intéresser à la problématique de la programmation
des agents. Nous présentons dans cette section les langages d’agents qui intègrent la
notion de connaissance au sein des agents, notre étude n’a pas pour vocation de lister
exhaustivement les langages de programmation agent 11 . L’Agent Oriented Programming
qui est le premier langage que nous présentons est présent ici pour des raisons historiques. Les deux langages suivants AgentSpeak et 3APL) sont des langages communs
du monde agent ; nous présentons deux extensions d’AgentSpeak/Jason (JASDL et
Argonaut) qui sont d’un intérêt particulier pour nos travaux puisqu’ils réalisent l’interface entre AgentSpeak et le langage OWL. Les langages S-APL et Nuin ne sont pas des
langages courants mais présentent de même l’intéret de mettre en œuvre des ontologies
au sein des agents. Le langage Jazzyk propose une approche intéressante de jonction
entre comportement et connaissance.
11. Pour plus d’information, le lecteur trouvera dans les travaux de Bordini [Bordini05b] un état de l’art
très complet sur la programmation d’agents.
3.3.8.1
97
Agent Oriented Programming
L’idée d’un langage de programmation dédié aux agents se concrétise en 1991 par
l’Agent Oriented Programming (AOP) de Shoham [Shoham91] dans lequel il présente le
premier langage d’agent appellée AGENT-0. L’approche de Shoham introduit 3 concepts
principaux 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é.
F IGURE 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 des
projets de recherche, mais il a ouvert la voie à de nombreux successeurs qui se sont très
largement 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
98
avaient été utilisé. La nouveauté d’AgentSpeak réside dans le fait que les trois attitudes principales de l’agent (Croyance, Désir et Intention) ne sont plus représentées
par des structures de données mais par des opérateurs modaux. AgentSpeak marque
l’entrée de la logique dans le monde de la programmtion agents. Non plus d’un point de
vue pratique par l’utilisation de Prolog, mais par la définition logique de l’architecture
BDI. Une version étendue d’AgentSpeak est utilisée pour la programmation des agents
dans Jason.
L’implémentation de Jason est réalisée en JAVA. Le langage interprété par Jason est
donnée en [Bordini05a]. Ce langage couvre les notions de plans, croyances, évènements
tels que définis dans AgentSpeak, mais ne couvre pas l’intégralité de l’éxécution du
code d’un agent. En effet lors de l’éxécution d’un agent Jason, les fonctions réalisant un
traitement 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 dans
les services Web ; c’est un langage qui permet d’orchestrer les différentes actions qui
elles, dans le cas de Jason sont implémentées en Java. L’orchestration se fait au sens de
l’architecture BDI que nous avons présentée précédemment.
Jason seul, présente pour notre problème les limitations communes aux nombreux
langages d’agents, en particulier la dichotomie entre le langage définissant les comportements (AgentSpeak) et les actions (ici en Java). Cette dichotomie pose des problèmes
d’interopérabilité entre agents, l’échange de comportements en AgentSpeak nécessite
l’échange des fonctions en Java, ce qui en soit n’est pas impossible (avec la réflexivité de
Java) mais n’est pas mis en œuvre dans Jason, une extension de Jason propose l’échange
de plans entre agents [Ancona04a], mais aucune implémentation n’est fournie. De plus
Jason utilise une représentation dans un format interne pour la base de connaissance
de l’agent (format AgentSpeak) qui est limitant dans son expressivité, comparé aux langages d’ontologies. Se basant sur une représentation de type Prolog, les connaissances
sont 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 nous
recherchons. JASDL et Argonaut proposent l’intégration d’OWL dans Jason, de deux
manières différentes. Nous détaillons ces deux extensions dans les sections suivantes.
JASON
Connaissance
Représentation
Logique Complétude
AgentSpeak(type Prolog)
Horn
Non
Monde
Fermé
TABLE 3.1 – Représentation des connaissances dans JASON
JASON
99
Comportement
Décision
Logique Réflexivité
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’OWLAPI pour fournir les fonctionnalités de programmation agent ainsi que les raisonnements
sur les ontologies [Klapiscak09]. L’approche de JASDL diffère des travaux préliminaires
de Moreira [Moreira06] qui suggèrent des changements dans la sémantique opérationnelle pour intégrer AgentSpeak dans OWL. Ces travaux préliminaires avaient établi un
cadre théorique mais aucune implémentation n’avait été fournie. Les avantages attendus
sont 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 propose
une approche plus simple en utilisant une correspondance entre la partie AgentSpeak
de Jason et la partie des axiomes OWL. L’utilisation d’un raisonneur OWL est aussi
inté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 de
la définition de nouvelles actions, de les définir à la fois dans le langage AgentSpeak et en
OWL. L’échange des connaissances au sens de l’AOA est alors limité par les définitions
locales des actions en AgentSpeak. Ces actions sont en effet propres à chaque agent et ne
sont pas échangeables.
L’utilisation d’OWL avec AgentSpeak permet la représentation de connaissances au
format OWL (ainsi que l’utilisation d’un raisonneur sur ces connaissances), ainsi que
la généralisation de plans au format OWL. Le moteur de décision de l’agent restant au
niveau AgentSpeak.
Tout comme l’approche proposée dans [Moreira06], JASDL, bien que plus simple
dans la proposition ne fournit pas d’implémentation. On pourra aussi noter qu’il est
reproché à Nuin de ne pas fournir d’implémentation ([Klapiscak09]), ce qui est pourtant
le cas depuis 2004 13 .
13. voir http://web.archive.org/web/*/http://www.nuin.org pour plus de détails.
100
F IGURE 3.8 – Architecture JASDL ([Klapiscak09])
JASDL
Représentation
OWL et AgentSpeak
Connaissance
Logique
Complétude
DL et Prolog
Non
101
Monde
Fermé
TABLE 3.3 – Représentation des connaissances dans JASDL
JASDL
Comportement
Décision
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 les
applications sensibles au contexte en utilisant les capacités de représentations et de
raisonnement des ontologies. A cette fin, l’intégration de Jena est faite de manière
externe à Jason. Les composants BDI de l’architecture Jason ne sont pas modifiés pour
l’occasion.
Les agents peuvent alors échanger des information de contexte représentés au format
OWL. L’intéraction entre Jason et les ontologies sont faites au travers de Jena, par
l’intégration de deux fonctions dans la base d’actions internes des agents. Les résultats
des requètes sur les ontologies sont transformées pour être intégrés dans la base de
croyances de l’agent.
Cette approche utilise certes OWL, mais d’une manière externe à l’architecture de
l’agent. L’objectif visé est ici les application sensibles au contexte. Seule une partie
des connaissances est représentée en OWL, les connaissances ne concernant pas les
problématiques de contexte sont au niveau AgentSpeak. L’utilité de cette approche par
rapproche à une définition en AgentSpeak n’est pas mise en avant et les bénéfices ne sont
pas montrés. Aucune implémentation d’Argonaut n’est fournie, il est donc impossible
de tester le fonctionnement du système.
Argonaut
Représentation
OWL
Connaissance
Logique
Complétude
DL et Prolog
Non
Monde
Fermé
TABLE 3.5 – Représentation des connaissances dans Argonaut
102
Argonaut
Comportement
Décision
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’université d’Utrecht aux Pays-Bas [Hindriks99]. 3APL reprend les concepts de de croyances et
de capacités de AGENT-0 et rajoute les concepts de buts et de plans. Les agents 3APL
suivent un processus délibératif pour élaborer les plans qui vont conduire à la réalisation
des buts assignés à l’agent. Le cycle de délibération de l’agent est présenté dans la figure
3.9.
F IGURE 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 de
planification 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 de
l’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 langage
3APL est un mélange de programmation impérative et de programmation logique. De
la programmation impérative, on retrouve par exemple les fonctions récursives alors
que la partie logique est utilisée pour les requètes sur la base de connaissance. Les
connaissances des agent 3APL sont représentées dans le langage 3APL qui est très
similaire au langage de programmation logique de type Prolog.
103
PROGRAM "agent"
BELIEFBASE {}
CAPABILITIES {}
GOALBASE {}
PLANBASE {}
PG-RULES {}
PR-RULES {}
F IGURE 3.10 – Squelette d’un agent 3APL
3APL
Représentation
type Prolog
Connaissance
Logique Complétude
Horn
Non
Monde
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 leurs
applications aux agents, notamment dans la réalisation de langages de programmtion agents. Le design Semantic Agent Programming Language [Katasonov08] est orienté
vers une description ontologique non seulement de l’environnement mais des agents
eux-mêmes. On retrouve une représentation sémantique des agents dans AgentOWL
[Laclavik06b]. La représentation des agents dans leur propre base de connaissances
entraine une capacité de réflexité pour les agents.
S-APL se situe à la jonction d’AgentSpeak, d’un raisonneur sémantique, en l’occurrence Closed World Machine (CWM [Berners-Lee00]) et de l’architecture BDI. S-APL
utilise le RDF (en notation N3) comme langage de représentation. Les inférences sont
faites par le raisonneur CWM, dans une logique du premier ordre en monde fermé (sans
la négation 14 ). L’architecture en couches de S-APL (figure 3.11 se base sur la description
sémantique de comportement (dans la couche belief data storage) qui utilise des comportements 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
Comportement
Décision
Logique
Règles(type Prolog)
Horn
Réflexivité
Non
TABLE 3.8 – Comportement des agents dans 3APL
104
F IGURE 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 la
pièce n°1. En cas de succés, l’agent ajoute dans ses croyances que John a été informé 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 comportement entre les agents, cependant on peut regretter que S-APL n’utilise pas OWL et se
restreigne à une représentation en RDF et à une logique du premier ordre en monde
fermé, 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’applications
orientées web sémantique et basées sur des agents [Dickinson03]. Les agents Nuin pos-
Représentation
RDF
S-APL
105
Connaissance
Logique
Complétude
Premier ordre
Non
Monde
Fermé
TABLE 3.9 – Représentation des connaissances dans S-APL
S-APL
Décision
CWM
Comportement
Logique
Réflexivité
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 NuinScript
basé sur Prolog et AgentSpeak(L). Le rôle de NuinScript est de combler certains problèmes d’AgentSpeak concernant l’échec de plans (l’échec d’un élément entraine l’échec
du plan en AgentSpeak, ce qui peut être problématique 15 . La logique utilisé dans le
processus de décision de Nuin est celle de l’interpréteur Prolog, qui est une logique
du premier ordre restreinte aux clauses de Horn. La communication entre les agents
est effectuée par la plate-forme JADE. Les connaissances des agents Nuin peuvent être
repré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é un
raisonneur. Plusieurs formats de représentation peuvent coexister, de même que plusieurs raisonneurs associés à ces formats. Les exemples données dans [Dickinson03] cite
l’utilisation de RDF, DAML-OIL et OWL.
Les agents Nuin permettent de manipuler des connaissances représentées dans les
formats du web sémantique, mais tout comme S-APL, Nuin se restreint à l’utilisation
d’une logique du premier ordre. Dans [Dickinson03], les auteurs indiquent que les agents
Nuin ne requiert qu’un fichier RDF pour être exécuté. Ce fichier de configuration contient
en fait le lien vers le fichier de script NuinScript qui contient le programme exécutable
par l’agent. Ce langage propriétaire qui n’est pas compatible avec les formats du web
sémantique restreint les capacités des agents à raisonner sur leur propre architecture.
Nuin
Représentation
Variable
Connaissance
Logique Complétude
Variable
Non
Monde
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.
106
F IGURE 3.12 – Architecture du système Nuin [Dickinson03]
Nuin
Comportement
Décision
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 programmation d’agents dont la fonctionnalité principale est d’exploiter différents systèmes
de représentations de connaissance (Knowledge Representation ou KR par la suite) en
utilisant différents modules d’interface entre ces KR. Jazzyk implémente le principe des
Behavioural State Machines (BSM). Le principe des BSM ressemble fortement à celui des
architectures 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 couche
de représentation de connaissance et de couche comportementale. En effet pour gérer
des modules de KR hétérogènes, l’auteur a choisi de ne pas représenter les comportements comme des connaissances reliées à un module KR. La couche responsable du
comportement 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és
dans les agents, nous ne présentons pas de comparaison ici. On notera l’existence d’un
module utilisant des logiques non monotones [Novak08b].
3.3.8.9
107
Conclusion sur les langages de programmation d’agents
Les langages dédiés aux agents ont évolué, notamment sous l’impulsion des travaux
de Rao vers une utilisation de la programmation logique comme outil principal des
interpréteurs. Les clauses de Horn sont donc majoritairement utilisées, du fait de leur
support par les langages de type Prolog qui sont utilisés pour les interpréteurs. Des
langages plus récents tel que S-APL, Picola [Buhler03] ou Qu-Prolog [Clark01] utilisent
une approche similaire.
Les composants principaux ont peu évolué, si la notion d’engagement définie par
Shoham a été abandonnée, les architectures délibératives de 3APL et de AgentSpeak
se basent sur les notions de croyance et de capacité. Les langages plus récents comme
Jazzyk ou S-APL se concentre sur la problématique émergente de la représentation
interne de connaissances et le rapport au comportment de l’agent. Les approches sont
diamétralement opposées, S-APL décrit de manière sémantique les comportements alors
que 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éveloppement de systèmes multi-agents. Une plate-forme est notamment responsable de la
gestion du cycle de vie des agents, du transport des messages entre les agents ainsi
que de la découverte des agents et des services. Certaines plates-formes spécifient les
langages de représentation des connaissances ou certaines éléments du comportement
des agents, c’est pourquoi nous les présentons ici.
La FIPA a proposé une architecture abstraite [FIPA02] pour la description des platesformes multi-agents. Le but de la FIPA est de favoriser l’interopérabilité entre des
plates-formes utilisant des mécanismes de communication différents. Pour permettre
cette intéropérabilité, les comités de normalisation FIPA ont focalisé leur travail sur les
points 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 jaunes
Les 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écifications
de la FIPA.
108
F IGURE 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 les
normes d’interopérabilité de la FIPA en implémentant le langage FIPA-ACL comme
langage de communication entre les agents. Une plate-forme JADE est formée d’un ou
plusieurs containeurs, qui peuvent intéragir entre eux. Une plate-forme comporte deux
agents initiaux, le DF pour directory facilitator, qui fournit un système de pages jaunes
et l’AMS pour Agent Management System, qui contrôle la plate-forme.
F IGURE 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érents
types :
– Simples
– Réception de messages
– Cycliques
– Ticker (réactif)
– Composés de plusieurs comportements
109
– parralèle
– séquentiel
JADE offre aussi de nombreuses librairies tierces-parties, parmi lesquelle se trouve
JADEx [Pokahr05], qui introduit une architecture BDI dans les agents JADE. JADEx
diffèrent des architectures BDI classique dans le sens ou la représentation des buts se
fait 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 section
précédente), en implémentant un ou plusieurs des types de comportements cités cidessus. Malgré l’utilisation de JAVA, JADE n’a pas été conçue pour permettre une
réflexivité, aucun échange de comportement n’est possible entre agent JADE.
Les connaissances des agents sont nativement géré en RDF par JADE sans utilisation
spécifique de raisonneur. JADE étant une plate-forme ouverte, l’utilisation d’outils plus
avancés est laissée au choix du concepteur d’applications.
JADE
Représentation
RDF
Connaissance
Logique Complétude
Non
N/A
Monde
N/A
TABLE 3.13 – Représentation des connaissances dans JADE
JADE
Comportement
Décision Logique Réflexivité
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 de
RDF par OWL pour la représentation des connaissances de l’agent. Cette extension
permet d’étendre les capacités de représentation de l’agent. Dans AgentOWL, OWL est
utilisé comme mode de représentation des connaissances et non de comportement. Le
comportement des agents reste programmé en JAVA exactement de la même manière
que pour JADE.
Les agents AgentOWL possèdent une représentation de leur propre architecture dans
un 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 propre
architecture. AgentOWL est basé sur Jena et propose l’utilisation d’inférences du moteur
110
F IGURE 3.15 – Modèle Sémantique des agents dans AgentOWL
Jena. Cette librairie ne modifie pas le fonctionnement des comportements des agents
JADE, qui reste basé sur une approche objet.
AgentOWL
Représentation
OWL
Connaissance
Logique Complétude
DL
Non
Monde
Ouvert
TABLE 3.15 – Représentation des connaissances dans AgentOWL
AgentOWL
Comportement
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 les
technologies du web sémantique [Dikenelli05]. Compatible avec le langage FIPA-ACL,
SEAGENT utilise un langage appellé SEAGENT Content Language comme langage
de communication agent. La représentation interne des connaissances se fait à l’aide
d’OWL, la description des services fournis par les agents. L’architecture globale de
la plate-forme est semblable à celle de JADE, à laquelle on ajoute un Semantic Service
Matcher pour la découverte de service, en plus du DF (service de pages jaunes).
111
F IGURE 3.16 – Architecture globale de SEAGENT
SEAGENT propose de définir de manière sémantique les comportements réutilisables 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 des
connaissances, un raisonneur simple OntoLog est utilisé pour le matching dans le composant Semantic Service Matcher. Cependant aucune information n’est fournie sur les
capacités du raisonneur ni sur le type de logique utilisée. L’utilisation des techniques de
raisonnement OWL se limite donc à la découverte des services au sein de la plate-forme
SEAGENT, les agents eux-mêmes ne possèdent pas de tels mécanismes. Pour résumer on
peut comparer SEAGENT à une plate-forme de type JADE dans laquelle une surcouche
de description sémantique des services a été ajoutée.
SEAGENT
Représentation
OWL 16
Connaissance
Logique Complétude
N/A
N/A
Monde
Ouvert
TABLE 3.17 – Représentation des connaissances dans SEAGENT
3.3.10
Applications agents basés sur des connaissances
112
SEAGENT
Comportement
Java
N/A
Oui
TABLE 3.18 – Comportement des agents dans SEAGENT
Dans les parties précédentes, nous avons successivement abordé la gestion de
connaissances, les systèmes multi-agents et le Web Sémantique. Nous allons maintenant
dé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 se
mettre 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èmes
multi-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, se
situent à l’intersection de ces domaines. Ces agents sont constitués de deux composants
principaux. Le premier étant la base de connaissance, qui contient la représentation du
monde de l’agent. Le second étant son mécanisme de décision, ou comportement qui
dirige les actions de l’agent en vue d’un but précis. Ces actions sont déterminées par
inférences sur la base de connaissances [Calmet04]. Ce type d’agent est particulièrement
adapté à la gestion des connaissances distribuées. L’accent sera mis dans cette partie sur
la 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 domaines
mettant en jeu leurs capacités spécifiques liées à leurs architectures. Nous traiterons
tout d’abord des systèmes d’information multi-agents puis des systèmes de gestion de
connaissance basés sur des agents. Les deux domaines étant intimement liées. Nous
présenterons ensuite les applications de ces agents dans le cadre des organisations
virtuelles 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 Information Systems (AOIS), est apparu en 1999 avec l’organisation du premier workshop
AOIS 17 lors de la conférence Agents’99.Dans [Strugeon08], les auteurs proposent une
méthodologie visant au développement de SIMA. Ils proposent de combiner les avantages des deux domaines (systèmes d’information et systèmes multi agents) en utilisant
une méthodologie séparant au départ l’analyse des services et des agents pour ensuite
les intégrer. Dans le cadre des SIMA, les auteurs ont identifié trois caractéristiques
principales que doivent posséder les agents :
1. Intéraction avec les utilisateurs
17. http://www.aois.org/
113
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 agents
selon 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 comportement
des agents suivant l’analyse faite à l’étape précédente et enfin l’implémentation et le test
de ces comportements.
Les agents d’information, qui représentent une version simplifiée des agents basées sur des connaissances, dans le sens ou ils manipulent des informations et non
des connaissances ont été utilisé avec succés dans le cadre des SIMA. De nombreuses
applications dans le domaine des assistants personnels [Modi04] ainsi que pour les services d’urgence [Chen04] ou encore pour les communautés virtuelles [Bryl06]. Dans ces
applications, l’architecture interne n’est pas explicitée, l’approche rôles/organisations
étant préférée.
3.3.10.2
Projet Comma
F IGURE 3.17 – Sociétés pour la gestion de la mémoire [Gandon02]
Le projet CoMMA (Corporate Memory Management through Agents [Perez00]) est
un 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’entreprise
basé sur les formats du web sémantique. Gandon [Gandon02] propose dans le cadre
du système CoMMA (Corporate Memory Management through Agents), d’utiliser une
114
approche multi-agents combinée avec les technologies du Web Sémantique dans le cadre
de la gestion de connaissances d’une mémoire organisationnelle distribuée. Dans ce
système, les agents sont basés sur des technologies du web sémantique, en particulier
le RDF. Dans son approche, l’auteur montre que la nature distribuée des SMA est en
parfaire adéquation avec les besoins d’une mémoire organisationnelle. L’organisation du
SMA est obtenu par raffinement successifs, en partant d’une société globale, puis en segmentant 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 est
constituée de documents annotés selon une ontologie définie en RDFS. Ce sont ces annotations qui sont gérées par CoMMA,. La recherche d’information se base sur le moteur
Corese [Corby04] qui permet de manipuler RDFS et les graphes conceptuels. Le système
multi-agent intègre des agents utilisateurs, et des agents intermédiaires. Ces agents sont
organisés dans quatre sociétés, dont les noms et rôles sont décrits dans la figure 3.17. Le
prototype du système a été implémenté en JAVA, en utilisant la plate-forme JADE.
CoMMA
Connaissance
Représentation
Logique
Documents et métadonnées
Non
Complétude
Oui
Monde
N/A
TABLE 3.19 – Représentation des connaissances dans CoMMA
CoMMA
Comportement
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 gestion
de connaissance distribuées dans un environnement pair-à-pair. L’architecture globale
du système est donnée par la modélisation en rôles et intéractions. Dans KEx les agents
peuvent ê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 ses
connaissances :
– Normalisation et enrichissement du contexte : le service effectue une normalisation linguistique du contexte utilisateur en utilisant des outils de traitement
automatique du langue naturel et la base Wordnet.
– K-federation : une fédération est un regroupement d’agents qui apparaissent alors
comme un agent unique dans le système. Les requètes sont alors distribuées dans
la fédération puis les réponses sont agrégées.
115
– Propagation de requètes : dans KEx, lorsqu’un agent reçoit une requète il peut la
reformuler sémantiquement à l’aide de son propre contexte utilisateur. La nouvelle
requè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égrer
les mappings sémantiques utilisés dans la requèete. De même, ces mappings
peuvent ê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) :
F IGURE 3.18 – Composants principaux de KEx [Bonifacio03]
Les agents possèdent des connaissances stockées sous formes de documents (document repository) ainsi que des connaissances strucuturées de manière sémantique
dans le context repository qui servent entre autre à décrire les documents. Cependant le
processus de décision des agents, n’est pas explicité. De nombreux choix d’implémentations ne sont pas explicités : dans quelles circonstances un agent choisit-il d’enrichir une
requète ? comment choisit-il de créer une fédération ? D’un point de vue technique, la
communication 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 pas
utilisés dans les différents systèmes que nous avons étudié dans cette section. Les comportements des agents peuvent pourtant être décrits selon des architectures standards
telle 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.
116
KEx
Connaissance
Représentation
Logique
Non
Complétude
Oui
Monde
N/A
TABLE 3.21 – Représentation des connaissances dans KEx
KEx
Comportement
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 alliances
temporaires d’entreprises partageant leurs ressources et compétences dans le but par
exemple d’exploiter une niche de marché ou de proposer un service mettant en jeu
leurs différents ressources ou compétences. Les agents basés sur des connaissances
ont été dans les prototypes CONOISE [Norman04] et CONOISE-G [Patel06]. Ces prototypes s’intéressent plus particulièrement au processus de formation des organisations
virtuelles.
Le mécanisme de décision interne à chaque agent est basé sur le principe de satisfaction de contraintes (CSP). Ce mécanisme est couplé à un système d’enchères pour
l’allocation des contrats au sein de l’organisation.
F IGURE 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
117
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 malicieux
dans une organisation virtuelle, l’architecture de CONOISE-G permet la reformation
dynamique d’une nouvelle organisation. Martinez et Al. [Martinez01] ont identifié les
différences services nécessaires à la gestion et au contrôle d’une organisation virtuelle
existante dans le cadre d’une approche multi-agents.
Dans ces applications au cadre des organisations virtuelles, les agents détiennent
des connaissances sur le prix, la qualité des services des autres agents, l’enchaînement
des services, leurs besoins.Ces connaissances détenues par les agents sont complètes et
structuré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 de
résolution de contraintes (CSP). L’implémentation du prototype [Patel05] est faite à l’aide
de JADE et les connaissances des agents sont représentées en RDF. L’implémentation de
l’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émantique
pour ces agents. Ces agents ne possèdent donc pas de réflexivité.
Conoise-G
Représentation
RDF
Connaissance
Logique Complétude
Non
Oui
Monde
Fermé
TABLE 3.23 – Représentation des connaissances dans CONOISE-G
Conoise-G
Comportement
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-learning
est défini comme (Union européenne 18 ) "l’utilisation des nouvelles technologies multimédias de l’Internet pour améliorer la qualité de l’apprentissage en facilitant d’une
part l’accès à des ressources et à des services, d’autre part les échanges et la collaboration à distance". Les systèmes informatiques utilisés pour l’apprentissage en ligne
sont nommmés du terme anglais LCMS (Learning Content Management System). Dans
la 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
118
ligne de contenu, évaluation par QCM, texte à trous, ... Les enseignants et étudiants
communiquent par l’intermédiaire des moyens de communications électroniques.
Au sein des LCMS, les systèmes multi-agents peuvent intervenir dans les différentes
parties d’un LCMS. Ils peuvent fournir un recherche personnalisée aux utilisateurs en
se basant sur leurs spécifications [Pankratius04]. Shi et al. [Shi02] proposent de remplacer l’enseignant par un agent intelligent qui s’adapte à l’étudiant. En se basant sur
une approche connectionniste (carte auto adaptative) qui modélise le comportment
de l’étudiant, l’agent est capable de proposer un environnement personnalisé d’apprentissage. Les agents tuteurs sont communément utilisés pour la modélisation du
comportement 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 communication et la coopération afin d’améliorer leurs performances. [Ritter97]. De nombreuses
approches 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ée
de leurs connaissances, ce qui garantit la consistance des connaissances du système. La
communication s’effectue en utilisant le langage KQML. L’évaluation des buts ainsi que
la prise de décision sont opérées par un raisonneur Prolog. La logique utilisée dans la
prise de décision est donc celle des clauses de Horn.
Dans ABITS [Capuano00] (Fig. 3.20), les connaissances sont représentées suivant
le schéma IEEE LTSC LOM à l’aide de graphes conceptuels. Ce choix des graphes
conceptuels peut paraître étrange puisque le schéma IEEE LTSC LOM est entre autre
basé sur Dublin Core dont une spécification RDF existe déjà. De plus les métadonnées
sont quant à elles représentées en RDF. Bien qu’il existe des méthodes de mapping de
RDF et des graphes conceptuels (tel que Corese [Corby00]), ces méthodes ne sont pas
mentionnées. La communication entre agents se fait selon le format d’échange standard
des graphes conceptuels (CGIF). Les agents ABITS peuvent modéliser l’état cognitif
et les préférences d’apprentissage de chacun des étudiants par un modèle basé sur la
logique floue. Les différentes préférences (pré-établies) de l’étudiant sont représentés
par une nombre flou. La logique floue utilisée n’est pas non plus spécifiée, alors qu’il
en existe de très nombreuses (monoïdale, basique, Lukasiewicz, . . .). La plate-forme
proposée est intéressante du point de vue agents (autonomes et multi-agents), mais est
desservie par le manque d’exemples et l’absence d’implémentation qui aurait permis de
lever 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 interne
les 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 un
langage de bas niveaux posent de sérieux problèmes d’interopérabilité puisque seuls
119
F IGURE 3.20 – Architectures interne et externe de ABITS [Capuano00]
des agents programmés en JAVA sont capables de les manipuler. La sérialisation est
aussi 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 mathématiques et notamment géométriques. L’idée principale qui sous-tend la conception
de la plate-forme est de pouvoir aider l’étudiant pas à pas dans la résolution de problè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) simplifie
nettement la tâche qui incombe à l’agent tuteur, si l’on compare avec les plates-formes
précédemment décrites. La sélection des messages à envoyer se fait par le parcours d’un
arbre de la résolution du problème. Cet arbre contient les actions à effectuer en fonction
de l’état d’avancement de l’étudiant.
Ces plates-formes utilisent différentes représentations des connaissances et ne sont
majoritairement pas basées sur des technique avancées de représentation de connaissance. Ceci s’explique en grande partie par le fait que ces contributions sont majoritairement antérieures à la popularisation des standards actules du web sémantique tels
que RDF ou OWL. Toutefois, les contributions plus récentes telles que [Wang05] se proposent 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 connaissances
pour vérifier la sémantique des communications entre l’étudiant et le professeur. Cepen-
120
dant l’application proposée n’a pas été implémentée, il est donc impossible d’analyser
les 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
I-Help
PACF
AgentGeom
Représentation
CG/RDF
Prolog
Java
Arbres
Connaissance
Logique Complétude
Non
Oui
Horn
Oui
Oui
Non
Non
Oui
Monde
N/A
N/A
N/A
N/A
TABLE 3.25 – Représentation des connaissances dans les systèmes d’EIAH
ABITS
I-Help
PACF
AgentGeom
Comportement
Ad hoc
N/A
Non
Ad hoc
N/A
Non
Ad hoc
N/A
Non
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 agents
basés sur des connaissances, dont le domaine d’application ne rentre dans aucun des
cadres énumérés ci-dessus.
Bibster
Bibster [Haase05] est une implémentation de l’architecture SWAP [Ehrig03]. Le but
de Bibster est de proposé aux chercheurs de partager leurs ressources bibliographiques
en utilisant un système pair à pair. Dans Bibster les références bibliographiques sont
les connaissances échangées à travers le systèmes. Leur description est fixée par deux
ontologies. La première ontologie (SWRC) décrit les différents aspects génériques des
mé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. Les
connaissances échangées sont en fait des entrées bibliographiques au format RDF. Les
ontologies de domaine sont fixées dans l’application, les agents échangent des instances
de ces ontologies. Les agents Bibster sont des pairs utilisant la plate-forme pair-à-pair
JXTA de SUN pour la communication. L’architecture des agents est identique à tous
121
les agents. Les connaissances échangées entre les agents concernent exclusivement des
ressources bibliographiques qui sont formalisés de manière statique. Les connaissances
sont donc consistantes au sein de l’application Bibster.
Bibster
Représentation
RDF
Connaissance
Logique Complétude
Non
Oui
Monde
N/A
TABLE 3.27 – Représentation des connaissances dans Bibster
Bibster
Comportement
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 des
connaissances et les comportements des agents. Le tableau 3.29 permet de mettre en
perspective les différentes approches de représentation des connaissances, le tableau
3.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 le
dé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 moteurs
d’inférence logique liées à ces technologies permettent aux agents la découverte de
nouvelles connaissances à partir de celles déjà existantes. Cependant ces capacités ne
sont pas pleinement utilisées, notamment OWL, comme on peut le voir dans SEAGENT
ou AgentOWL, puisque la capacité de représentation n’est pas utilisée avec la logique de
description qui est à la base de ce langage. On a donc une sous-utilisation des capacités
de représentation et d’inférence. Toujours d’un point de vue logique, l’hypothèse de
monde fermé est très largement utilisée et comme nous l’avons vu en section 3.2 elle
n’est pas cohérente avec la représentation que nous nous faisons du monde. L’approche
logique au niveau des connaissances, en tant que système inférentiel est présente dans
les trois domaines que nous avons étudiés. Ce n’est pas une surprise car les outils
disponibles (Prolog ou logique de description) s’intègre sans difficulté technique dans
tout 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 lieu
intégrées dans les approches génériques (langages de programmation et plates-formes),
les applications dédiées utilisant des technologies plus anciennes.
122
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 toute
sémantique dans les comportements d’agents. Pour pallier ce manque, les approches
de 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écanismes
inspirés des Web Services. Dans les trois domaines étudiés, les langages de programmation du comportement et ceux de la représentation de connaissance sont différents
dans la très grande majorité des cas, sauf pour les architectures BDI. Dans le cas précis
des architectures, le lien entre base de connaissance et comportement est réalisé au
niveau des croyances (B de BDI). L’implémentation de cette architecture se base sur
l’utilisation de raisonneur de type Prolog, ce qui restreint par conséquent la logique
utilisée pour la base de connaissances à la logique du premier ordre. Les logiques de
description utilisée dans OWL sont dotées d’une expressivité plus grande mais elles
n’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 de
la base de connaissance autour d’OWL reste donc un problème ouvert. La question de la
reflexivité dans les architectures est souvent ignorée dans le cadre des langages agents
alors que c’est à ce niveau qu’on pourrait s’attendre à la voir apparaître. Seuls S-APL et
une extension de Jason (non implémentée) proposent cette fonctionnalité, mais aucun de
manière satisfaisante. La dualité langage de raisonnement et langage d’implémentation
des fonctions est le facteur limitant à l’échange des comportements entre agents dans les
deux cas.
En conclusion, l’utilisation des technologies du web sémantique est un standard
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 la réalisation
des comportements des agents. Nous discutons dans l’analyse en section suivante des
moyens 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’architecture des agents, en vue de permettre l’échange des différents composants d’une base
de connaissance. L’échange de ces composants introduit des problèmes d’intégrations
dans la base de connaissances des agents. Lors d’intéraction avec d’autres agents, il
est souhaitable de disposer d’un processus permettant de choisir ou non d’intégrer ces
nouvelles connaissances. En nous basant sur les notions définies en épistémologie nous
discutons des approches pouvant apporter des pistes pour ce problème.
Section 3.4. Analyse et mise en perspective
JASON
JASDL
Argonaut
3APL
S-APL
Nuin
JADE
AgentOWL
SEAGENT
CoMMA
KEx
Conoise-G
Bibster
ABITS
I-Help
PACF
AgentGeom
Connaissance
Représentation
Logique
AgentSpeak(type Prolog)
Horn
OWL et AgentSpeak
DL et Prolog
OWL
DL et Prolog
type Prolog
Horn
RDF
Premier ordre
Variable
Variable
Agents au sein des plates-formes
RDF
Non
OWL
DL
OWL 19
N/A
Applications
Non
Non
RDF
Non
RDF
Oui
CG/RDF
Non
Prolog
Horn
Java
Oui
Arbres
Non
123
Complétude
Monde
Non
Non
Non
Non
Non
Non
Fermé
Fermé
Fermé
Fermé
Fermé
Fermé
N/A
Non
N/A
N/A
Ouvert
Ouvert
Oui
Oui
Oui
Fermé
Oui
Oui
Non
Oui
N/A
N/A
Fermé
N/A
N/A
N/A
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, plateforme agents et des applications basées sur des agents) une architecture supportant nos
besoins d’échange de connaissances. A la question d’une architecture agent pouvant
supporter l’échange des différents composants de l’AOA, nous avons vu qu’aucune des
architectures 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 comportement
et 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 retrouve
une approche similaire dans la dualité des langages au sein des agents. Chaque agent
possède au moins deux langages, un qui permet d’exprimer le comportement au sens de
l’approche BDI (i.e. AgentSpeak) et un langage de plus bas niveau (Java). Les applications
que 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 le
travaux de Moreira, Argonauts et S-APL. Cependant aucune ne permet d’unifier comportement et connaissance. S-APL, le seul de ces langages dont une implémentation est
124
JASON
JASDL
Argonaut
3APL
S-APL
Nuin
JADE
AgentOWL
SEAGENT
CoMMA
KEx
Conoise-G
Bibster
ABITS
I-Help
PACF
AgentGeom
Comportement
Décision
Logique
BDI/AgentSpeak
Horn
BDI/AgentSpeak
Horn
BDI/AgentSpeak
Horn
Règles(type Prolog)
Horn
CWM
Premier ordre
BDI (NuinScript)
Horn
Agents au sein des plates-formes
Java
N/A
Java
N/A
Java
N/A
Applications
Ad hoc
N/A
Ad hoc
N/A
Ad hoc
N/A
Ad hoc
N/A
Ad hoc
N/A
Ad hoc
N/A
Ad hoc
N/A
Ad hoc
N/A
Réflexivité
Non 20
Non
Non
Non
Oui
Non
Non
Oui
Oui
Non
Non
Non
Non
Non
Non
Non
Non
TABLE 3.30 – Récapitulatif des comportments agents
fournie, propose de réutiliser des composants Java partagé entre les agents. L’appel à un
langage de bas niveau est toujours présent.
Dans la conclusion de l’article présentant JASDL, il est mis en avant que JASDL
permet de définir des nouvelles intéractions au niveau de l’ontologie, mais qu’à la différence d’Argonauts ou les implémentations de ces intéractions doivent être faites en
JAVA, 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 et
Argonauts) 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èmes
d’architecture ne permettent pas la réalisation de l’échange des composants d’une base
de connaissance. Tout d’abord, l’utilisation de deux langages pour les agents, un pour
les comportements et un pour les connaissances ou pour les actions est limitant. Mais on
pourrait contourner cette difficulté en réalisant deux modules réflexifs, l’un pour chaque
langage. De nombreuses architectures sont réalisées en Java, il suffirait par exemple dans
le cas de JASDL de permettre l’échange lié de plans, croyances et d’implémentations
d’action. Cette approche ne nous parait satisfaisante. D’un point de vue de conception
125
logicielle, il est plus simple d’utiliser seulement un seul langage. En terme de représentation de connaissances, OWL s’est imposé dans de nombreuses architectures récentes et il
nous semble être un choix judicieux. Nous sommes alors tentés de résoudre le problème
de la même manière que Moreira [Moreira06]. Le second problème intervient alors, par
la 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 un
raisonneur OWL. En effet l’architecture BDI est séduisante par ses possibilités, mais elle
est complexe à mettre en œuvre avec des logiques de description. Il est plus judicieux
dans 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 SWRL
dans le même fichier), il est possible de définir un comportement sous forme de règles
exécutables par un interpréteur. L’architecture BDI étant complexe à implémenter et
n’étant pas requise pour notre approche, le premier prototype des VKC fonctionnant avec
divers 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 plus
bas niveau est alors nécessaire. Le problème de la définition de nouvelles actions et
leurs implémentations dans des langages de plus bas niveau que OWL (par exemple
AgentSpeak ou Java) peut être résolu de manière simple. JASDL ou S-APL proposent
de définir parallèlement de nouvelles actions en des déclarant dans les ontologies et en
donnant une implémentation liée à cette déclaration (en JAVA pour S-APL, AgentSpeak
pour JASDL). Nous proposons de définir un nombre fini d’actions dont on établit
la correspondance entre l’ontologie et l’implémentation. Pour définir de nouvelles
actions, on les compose à partir des actions prédéfinies dans l’ontologie. Le but de cette
approche est d’avoir un interpréteur universel à tous les agents, capables d’éxécuter un
comportement reçu lors d’une intéraction, sans avoir à transmettre d’implémentation
dans 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 BDI
semblait difficile à mettre en œuvre en OWL, de plus elle n’est pas requise pour notre
implémentation. C’est pourquoi nous proposons d’utiliser le concept des machines
étendues à état finis (EFSM), pour représenter les comportements des agents. Pour le
confort du lecteur, nous donnons ci-après un bref rappel de cette notion.Les EFSM
sont des versions étendues des automates finis classiques, ce qui signifie concrètement
qu’à chaque transition est associée un ensemble d’actions qui seront exécutées lors de la
transition [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,
126
– 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 f i : 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 × O
une 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, fonction
d’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 la
machine d’un état vers le suivant (les états sont notés S), un ensemble d’opérations U
est effectué.
Les EFSM nous fournissent un cadre permettant de réaliser simplement des comportements 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 basant
sur 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 des
différents composants qui constituent la base de connaissances d’un agent. Dans le cas
des connaissances représentées de manière logique, le fonctionnement des raisonneurs
fait écho à la théorie de la justification. Cependant le cas des connaissances qui ne
relèvent pas du domaine logique est encore ouvert. La question de la justification de
ces connaissances lors d’un échange entre agent est cruciale. Quelles sont les raisons
ou justifications qui doivent inciter un agent à accepter certaines connaissances (non
logiques) et à en refuser d’autres ?
La spéficité des agents gérant des connaissances par rapport aux systèmes basés sur
des connaissances est la capacité d’action. Si l’on considère ce qui relève de l’action des
agents (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 les
connaissances empiriques nous donne une solution par l’expérimentation. L’exemple
de la connaissance du chemin, dont l’interlocuteur ne peut être convaincu qu’en expérimentant ce chemin 21 (cf page 62) est tout à fait adaptable à un système d’agent
communiquant.
21. Il est possible d’argumenter le fait que le chemin est justifiable de manière logique par la connaissance
d’une carte, auquel cas c’est la carte qui devra être soumise à l’expérience pour être justifiée.
127
A cette fin, nous proposons une différentiation des connaissances au niveau de l’agent
selon le niveau auquel elles interviennent dans l’architecture. Nous avons précédemment
exclu les architectures BDI de notre approche, les considérations qui suivent s’appliquent
aux autres architectures 22 . Les connaissances empiriques entrainent (par définition de
l’expérience) une exécution d’actions de la part de l’agent expérimentant, actions qui ont
des 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. Les
connaissances justifiables logiquement sont placées dans la partie classique de la base
de connaissances de l’agent et ne sont pas exécutées. Cependant cette différentiation
des connaissances sur le plan de l’exécution ne doit pas entrainer une différence dans
la représentation et le stockage. En effet les connaissances empiriques peuvent faire
intervenir des concepts définis dans les connaissances empiriques.
En nous basant sur la définition épistémologique de la connaissance et les réflexions
précédentes, nous abordons la question de la mise en œuvre de ces connaissances sous
l’angle de l’architecture des agents en partant du niveau de la définition de la connaissance ou nous avons établi la distinction entre connaissance justifiables logiquement
et connaissance empiriques. Au niveau de l’agent, nous devons disposer de capacités
de représentation pour chacun des types de connaissance. Dans le premier cas, un formalisme logique doit être supporté, dans le second cas, aucun formalisme précis n’est
prescrit.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 connaissances
justifiables au sens de la logiqe et les connaissances empiriques qui nécessitent une
expérience pour leur validation. Pour être utilisable par des agents, nous spécifions ainsi
les 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 empiriques
La section suivante présente les étapes de simplification et d’unification des composants.
3.4.3
Un modèle unifié des connaissances et des comportements
Notre approche nous permet de considerér un agent comme étant composé de
connaissances justifiables et empiriques. Il est souhaitable de disposer d’un modèle
unique pour ces connaissances, ou à défaut, d’un modèle de représentation cohérent
et compatible entre des deux types de connaissances. Par ailleurs, les connaissances
empiriques é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
128
Connaissance: Opinion droite et
justifiée
Connaissance
Connaissances
démontrables
Représentation
niveau agent
Composants
de l’agent
Formalisme logique
pour la représentation
des connaissances
Base de connaissance
supportant un
formalisme logique
Moteur logique
Connaissances
empiriques
Connaissance exécutable par l’agent
Méthode d’évaluation
Base de connaissance
pour les connaissance
empiriques
Moteur d’exécution
et de vérification des
actions
F IGURE 3.21 – Composants nécessaires aux agents pour la mise en œuvre des connaissances
l’agent peut exécuter. Il s’agit donc d’un comportement de l’agent. Ceci nous conduit
donc à 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ême
formalisme, que ces connaissances soient justifiables de manière logique ou alors empiriques. La représentation des connaissances empiriques n’impose pas à priori de
formalisme très restrictif, comparé aux connaissances justifiables qui nécessitent une
représentation basée sur la logique et l’utilisation d’un raisonneur sémantique. Il se pose
alors 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 connaissance 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 architectures existantes, nous avons identifié une analogie entre les besoins de représentation
des connaissances vérifiables par l’expérience et les comportements des agents. L’innovation de notre proposition de modèle d’agents sémantique se situe au niveau de la
représentation sémantique des comportements d’agents en tant que connaissance. Nous
souhaitons que toutes les connaissances des agents soient représentées dans le même
129
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 les
langages OWL et SWRL, le langage OWL étant utilisé pour la base de connaissances
classique (connaissances justifiables).
Nous pouvons donc utiliser un seul raisonneur pour les deux types de connaissance. 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 nouvelles
connaissances. Lorsqu’un agent souhaite intégrer des connaissances reçues, il vérifiera
la consistance avec celles qui possède déjà et les intégrera le cas échéant. Dans le cas
de non consistance, l’agent utilise les fonctions d’explication du raisonneur pour déterminer la cause de non consistance. L’agent peut ensuite engager un dialogue avec son
interlocuteur pour argumenter de la validité ou non des connaissances. L’argumentation
dans les systèmes multi-agents est un vaste domaine de recherche qui est en dehors du
propos de nos travaux qui sont focalisés sur l’agent seul 23 . Concernant les connaissances
empiriques, le processus de justification nécessite l’exécution du comportement (enchainement des règles de l’EFSM) correspondant à la connaissance, puis de la vérification
d’une propriété à l’issue de cette éxécution. La figure 3.22 résume le rôle du raisonneur
logique en fonction de chacun des types de connaissances. La réalisation concrète de
l’architecture puis de l’impleméntation va suivre cette volonté de représentation des
comportements et des connaissances dans le même formalisme.
Base de
connaissances
Raisonneur
Découverte de
connaissances
Connaissances justifiables
Expliquer par
Justification déductive
Déduction
Explication
Maintenir la
consistance
Vérification de consistance
Connaissances
expérimentables
Vérification
des propriétés
Moteur logique
Comportements
Exécution de
comportements
Enchaînement de règles
F IGURE 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/
130
3.5 Conclusion
Nous avons présenté les trois domaines à l’intersection desquels se trouve domaine
de recherche : la gestion des connaissances, le web sémantique et les systèmes multiagents. 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 et
la formalisation des communautés virtuelles de connaissance.
Nous avons abordé différents points dans le domaine des connaissances et et de la
gestion des connaissances, tout d’abord les définitions de la 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 des connaissances. La définition de la
connaissance qui est utilisée dans l’approche appliqué de la gestion 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ées et aux informations, se base sur une
succession de traitement informatique. Prenons l’exemple d’un capteur de température
dans une pièce : les données sont acquises d’un capteur et représentent une suite de
bits, sans signification. Ces données sont ensuite traitées pour en calculer la température
mesurée par le capteur, ce qui constitue alors l’information. Si l’on extrait d’un relevé de
température fournie par le capteur un modèle qui décrit l’évolution de la température
dans cette pièce, on a alors extrait une connaissance à 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. Mais le but d’un système de gestion connaissances est, comme de nombreux systèmes informatique, de délester l’utilisateur humain
de tâches automatisable par la machine. C’est donc une définition de la connaissance
qui est aussi pour l’utilisateur qui doit prévaloir, plutôt qu’une approche technique. Ce
raisonnement ne s’applique pas seulement pas à la définition de la connaissance en
tant que "tout ce qui n’est pas information ou données", mais à toute définition de la
connaissance qui est imposée par la structure de la machine qui est amenée à traiter les
connaissances. La définition épistémologique ("La connaissance est une opinion droite
pourvue de raison) de la théorie de la justification nous semble être plus proche du fonctionnement "humain", c’est donc cette définition qui selon nous, doit être au centre des
systèmes de gestion des connaissances. Les travaux de Bonifacio ont mis en évidence la
notion d’autonomie de la connaissance et ont ouvert la voie à la gestion décentralisée des
connaissances. Cependant l’autonomie de la représentation des connaissances se limite
au domaine de la communauté. Cette autonomie de représentation doit être étendue
complètement jusqu’aux entités qui composent les communautés.
A l’étude des technologies du Web Sémantique, nous avons constaté que l’ensemble
des technologies n’est pas encore arrivé à maturité, notamment à cause des problèmes
induits par l’utilisation de ces logiques de description. La non-monotonie de ces logiques
131
ainsi que l’hypothèse de monde ouvert ont considérablement freiné le développement de
ces technologies qui jusqu’à l’OWL était extrêmement simple. Le fait qu’aucun langage
de règles n’ait encore été choisi comme standard par le W3C (même si on peut parier
sur le SWRL) montre que la technologie n’est pas encore matûre pour une utilisation
industrielle 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 permis
l’accélération du développement de formats et de technologies pour la représentation
des 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 et
standards du Web Sémantique trouveront (et trouvent déjà) un champ d’application
dans toutes les applications touchant à la gestion de 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ée au chapitre précédent. En
effet dans un tel système logique, il est possible de justifier par l’utilisation de raisonneur
de la validité d’une proposition au regard d’un système d’axiomes et de règles de
dérivation. Les raisonneurs permettent aussi de vérifier la consistance 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èse d’un monde ouvert nous
parait parfaitement adapté à nos besoins de représentation et d’inférence dans le cadre
de nos recherches.
Dans l’étude des agents et des systèmes multi-agents, nous avons focalisé notre étude
sur deux classes de critères, la représentation des connaissances et les comportements
des agents. La problématique de représentation des connaissances au sein des agents
suit le dé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
moteurs d’inférence logique liées à ces technologies permettent aux agents la découverte
de nouvelles connaissances à partir de celles déjà existantes. Cependant ces capacités ne
sont pas pleinement utilisées, notamment OWL, comme on peut le voir dans SEAGENT
ou AgentOWL, puisque la capacité de représentation n’est pas utilisée avec la logique de
description qui est à la base de ce langage. On a donc une sous-utilisation des capacités
de représentation et d’inférence. Toujours d’un point de vue logique, l’hypothèse de
monde fermé est très largement utilisée et comme nous l’avons vu en section 3.2 elle
n’est pas cohérente avec la représentation que nous nous faisons du monde. L’approche
logique au niveau des connaissances, en tant que système inférentiel est présente dans
les trois domaines que nous avons étudiés. Ce n’est pas une surprise car les outils
disponibles (Prolog ou logique de description) s’intègre sans difficulté technique dans
tout 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 lieu
intégrées dans les approches génériques (langages de programmation et plates-formes),
les applications dédiées utilisant des technologies plus anciennes.
132
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 toute
sémantique dans les comportements d’agents. Pour pallier ce manque, les approches
de 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écanismes
inspirés des Web Services. Dans les trois domaines étudiés, les langages de programmation du comportement et ceux de la représentation de connaissance sont différents
dans la très grande majorité des cas, sauf pour les architectures BDI. Dans le cas précis
des architectures, le lien entre base de connaissances et comportement est réalisé au
niveau des croyances (B de BDI). L’implémentation de cette architecture se base sur
l’utilisation de raisonneur de type Prolog, ce qui restreint par conséquent la logique
utilisée pour la base de connaissances à la logique du premier ordre. Les logiques de
description utilisée dans OWL sont dotées d’une expressivité plus grande mais elles
n’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 de
la base de connaissances autour d’OWL reste donc un problème ouvert. La question de
la reflexivité dans les architectures est souvent ignorée dans le cadre des langages agents
alors que c’est à ce niveau qu’on pourrait s’attendre à la voir apparaître. Seuls S-APL et
une extension de Jason ([Ancona04b], non implémentée) proposent cette fonctionnalité,
mais aucun de manière satisfaisante. La dualité langage de raisonnement et langage
d’implémentation des fonctions est le facteur limitant à l’échange des comportements
entre agents dans les deux cas. l’utilisation des technologies du web sémantique est un
standard 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 la
réalisation des comportements des agents.
L’analyse qui a suivi a montré que l’utilisation des langages du web sémantique
permettait 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 rapprochement
entre 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 entre
processus de décision, comportement et connaissance semblait toute indiquée pour
remplir cette tâche. Cependant les tentatives infructueuses d’implémentation d’une telle
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éalisation d’une base de connaissances homogène permettant de décrire à la fois les
connaissances justifiables et empiriques. L’utilisation d’un raisonneur unique pour l’inférence des connaissances, la justification des deux types de connaissance ainsi que
133
l’exécution des comportements est alors possible. Nous présentons dans le chapitre
suivant, 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 web
sémantique permettait 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 rapprochement entre 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
entre processus de décision, comportement et connaissance semblait toute indiquée
pour remplir cette tâche. Cependant les tentatives infructueuses d’implémentation d’une
telle 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éalisation d’une base de connaissances homogène permettant de décrire à la fois les
connaissances justifiables et empiriques. L’utilisation d’un raisonneur unique pour l’inférence des connaissances, la justification des deux types de connaissance ainsi que
l’exécution des comportements est alors possible.
L’homme est infiniment grand par rapport à l’infiniment petit et infiniment petit
par rapport à l’infiniment grand ; ce qui le réduit presque à zéro.
Vladimir Jankélévitch
4
Un modèle d’agents sémantiques
136
Chapitre 4. Un modèle d’agents sémantiques
Plan du chapitre
4.1
Architecture . . . . . . . . . . . . . . . . . . . . . .
4.1.1
Base de connaissances et Comportements
4.1.2
Interpréteur . . . . . . . . . . . . . . . . .
4.1.3
Actions de bas niveau et plate-forme . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
137
138
139
139
4.2
Programmation des agents . . . . . . .
4.2.1
Syntaxe du langage . . . . . . .
4.2.2
actions SWRL standards . . . .
4.2.3
Actions spécifiques aux agents
4.2.4
Définition de nouvelles actions
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
140
141
141
143
145
4.3
Structure de contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
4.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
’ ANALYSE de l’état de l’art précédent a abouti sur une architecture d’agent sémantique utilisant les machines étendues à états finis pour représenter les comportements sous formes de règles SWRL. Cependant SWRL ne contient pas toutes les
fonctionnalités nécessaires à la programmation d’un agent. SWRL est un langage de
rè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 architecture
en couhes qui permet l’utilisation d’un langage de plus bas niveau pour compléter les
fonctions manquantes à la réalisation de l’agent. Nous présentons cette architecture dans
la section suivante.
L
La programmation des EFSM requiert la définition de règles spécifiques SWRL et de
la mise en place d’un interpréteur qui exécutera les règles et les actions présentes dans le
conséquent. La grammaire du langage ainsi que la structure de contôle de l’interpréteur
font l’objet des sections 4.2 et 4.3. Les spécifications issues de l’interpréteur permettent
de définir le modèle sémantique des agents (section 4.3.1) qui permet la réflexivité, les
agents ayant connaissance de leur propre structure. Puis nous présentons l’extension du
modè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 langage
de règles ne contienne pas toutes les fonctionnalités nécessaires à la programmation d’un
agent. SWRL est un langage de rè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 architecture en ccouhes qui permet l’utilisation d’un langage de
plus 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 justifie
par la difficulté d’extension d’un interpréteur SWRL. De plus, pour la communication
inter-agents, il est souhaitable par souci d’intéropérabilité de respecter les standard
FIPA-ACL. De nombreuses implémentations de ces standards existent, notamment en
JAVA.
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
138
OWL - SWRL
Base de connaissances et de comportements
Teste les transitions
Séquences d’actions
Messages reçus
(sémantisés)
JAVA
Pellet
Jena
Interpréteur
Démarre les actions
Messages reçus
Actions de bas niveau
Intéraction avec la plate-forme
JAVA
JADE
F IGURE 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 contient
l’ensemble des connaissances de l’agent, justifiables et empiriques. Ces connaissances
sont composées de concepts OWL (classes, instances, propriétés et opérations) et de
règles SWRL pour les connaissances justifiables. Les connaissances empiriques sont
dé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 expliciterons
ensuite l’écriture des comportements. Notons dès à présent qu’un avantage significatif
de notre approche est l’usage de SWRL, dont la syntaxe étend celle de OWL. En effet
les termes de la base de connaissances de l’agent sont directement manipulés dans
les règles décrivant les comportements (cf Section 3.2.4.4), aucune transformation des
connaissances pour les manipuler à l’aide de règles n’est requise.
Section 4.1. Architecture
4.1.2
139
Interpréteur
L’intérpréteur constitue la structure de contrôle ainsi que l’interface entre les couches
de haut et bas niveaux. L’interpréteur comprend un le raisonneur tel que décrit dans la
figure 3.22 qui intéragit avec la couche sémantique pour les différentes actions( déclenchement 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ère
les appels à la couche inférieure. Nous détaillons le fonctionnement de l’interpréteur
dans 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 distingue
d’une part les actions du langage de règles SWRL qui sont exécutées par le raisonneur
et d’autre part celles les actions de bas niveau. Ces actions de bas-niveau, comme nous
l’avons indiqué précédemment sont les actions requises au fonctionnement d’un agent
et qui ne sont pas disponibles parmi les prédicats de SWRL. Au sein de ces actions de
bas niveau, on distingue deux catégories d’actions selon leur portée : les actions internes
et les actions externes. Les actions internes concernent les actions dont l’effet porte sur
l’agent lui-même alors que les actions externes concernent les intéractions de l’agent
avec son environnement. Une action interne modifie l’état de l’agent alors qu’une action
interne 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 utilisant
les concepts suivants : classes, propriétés et individus. A chacun de ces concepts, sont
associées trois opérations : création,modification et suppression. Seulement la première
de ces opération est supportée SWRL. Comme seule la création est possible en SWRL, la
liste suivante montre les opérations qui doivent être effectuées par la couche basse de
l’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 qui
restreint donc les actions possibles à l’échange de messages entre agents. Il y a donc
deux actions basiques, l’envoi et la réception de messages. Les actions relatives à la
communication se basent sur une plate-forme d’agents. Les messages sont structurés
selon la spécification FIPA-ACL (nous proposons une implémentation basée sur JADE
140
dans le chapitre 6). Lors de la réception d’un message, celui-ci est stocké dans la file
des messages reçus dans la base de connaissance. Les agents sont compatibles avec la
spécification FIPA ACL 1 . En plus des éléments standards, tels que émetteur, destinataire
et contenu, la spécification FIPA-ACL impose de nombreux paramètres tels que l’URI
de l’ontologie utilisée et la performative. A l’aide de ces deux actions, il est possible
de construire des intéractions complexes (cf spécification FIPA). Les actions externes
permettent 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 autre
moyen 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 ou
automates à états finis étendues déterministes (deterministic EFSM). Les séquences
d’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 ceux
envoyés par l’agent. Les fonctions d’activation sont les conditions portant sur l’état
interne de l’agent, c’est-à-dire sa base de connaissances. Les actions de mise à jour, sont
un ensemble d’actions qui sera exécuté par l’agent à l’issue de la transition. L’espace D
est ici l’espace des propositions représentables dans la base de connaissances, c’est à dire
l’union des ontologies OWL et des règles SWRL.
On peut représenter une machine à états finis étendues sous forme d’un ensemble
de 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 base
de 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 comme
un état mental de l’agent.
1. http://www.fipa.org/repository/aclspecs.html
Section 4.2. Programmation des agents
4.2.1
141
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 (SAMantecedent) et le conséquent (SAMconsequent). L’antécédent contient les conditions de
déclenchement de la règle. Ces conditions portent sur l’état courant de l’agent ainsi
que sur des concepts de sa base de connaissance. Ces dernières conditions sont facultatives (atom*). Une transition peut s’exécuter sans poser de conditions explicites sur les
connaissances 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’assertion) ainsi que l’état d’arrivée de la transition. Cette liste spécifiée par a-list est liée au
conséquent par aActions. Les éléments non-terminaux de la grammaire sont définis dans
l’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édent
de 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équent
de 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 aValeurParametre.
4.2.2
actions SWRL standards
Les actions existantes en SWRL (SWRL built-ins en anglais) se répartissent en sept
caté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
142
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
action
::= aContenu(action) aSuivant(a-list)
| finListe
::= URIreference
aNomParametre(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 ’)’
F IGURE 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 est
non 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 approche
requiert l’utilisation de liste, pour représenter les connaissances empiriques ainsi que les
comportements, nous utilisons donc une ontologie tierce OWLList [Drummond06] qui
permet 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 qui
n’existent pas en SWRL. Nous avons déjà énoncé deux catégories, les actions internes
dont le résultat est une modification de l’état interne de l’agent et les actions externes
dont le résultat influe sur l’environnement extérieur des agents. Dans le cadre d’échanges
de 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’une
règle SWRL, seule la création (par assertion) est possible. L’hypothèse de monde ouvert
entraîne le non support des négations comme but ou négation par l’échec. En pratique
il est donc possible de faire l’assertion de propriétés sur des individus ou des classes
dans le conséquent d’une règle. L’exemple suivant issue du document SWRL montre
l’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égation
l’échec et la suivante un cas d’inférence non-monotonie. Il est par conséquent impossible
de supprimer une information dans le conséquent de la règle. Cependant cette opération
peut-ê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 domaines
de oncle et tante sont disjoints.
144
Les actions internes déléguées à la couche inférieure de l’architecture sont les suivantes :
– 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és
dans la norme FIPA-ACL (voir annexe B), les agents se basent sur la norme ACL pour la
structure des messages.
Les messages reçus sont stockés dans une liste de type OWLList. Les actions externes sont les suivantes : envoiMessage et messagerecu. La première action prend en
paramè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 aux
messages reçus qui sont stockés dans la liste.
A partir de ces simples intéractions, toujours en suivant les spécifications de la
FIPA il est possible de construire des échanges de nature complexe tels que propostion,abonnement,contrat. Les différents champs du message sont représentés dans la
base de données OWL en utilisant les propriétés hasPerformative, hasContent, hasSender .
Actions Internes
Fonctions
SWRL
Assertions
Comparaisons
Mathématiques
Chaînes de caractères
Booléens
Date, temps et durée
URI
Fonctions
de bas
niveaux
Création
Classes
Individus
Relations
Modification : idem
Suppression : idem
Actions Externes
X
Envoi de messages
Réception de messages
Interactions avec la plate-forme
F IGURE 4.3 – Actions selon les couches de l’architecture
Section 4.3. Structure de contrôle
4.2.4
145
Définition de nouvelles actions
Le modèle présenté dans la section précédente spécifie une liste d’actions de base
pour la gestion de connaissance et l’échange de messages. La définition de nouvelles
actions 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érabilité entre les agents qui ne partageraient pas tous les mêmes actions. L’approche par
composition est donc celle qui est retenue.
Ces nouvelles actions sont une composition d’actions de bas niveaux et de primitives
SWRL. Ces actions, sont de type composées (voir Fig 4.6). Pour définir ces nouvelles
actions, nous utilisons le même principe que pour réprésenter le comportement d’un
agent. Les actions composées sont un ensemble de règles constituant une machine à
états finis étendue.
4.3 Structure de contrôle
Base de connaissances
et
Comportement
Moteur de
règles
Clock
Messages reçus
Noms et paramètres
des actions
Règles et états
Interpréteur
Paramètres
Des actions
Paramètres
Des messages
Messages sortants
Actions interne
Actions
externes
Messages reçus
F IGURE 4.4 – Interpréteur des agents, inspiré de [Shoham91]
146
L’interpréteur que nous proposons repose sur le principe des EFSM que nous avons
pré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 les
couches basses de l’architecture. Le cycle de l’interpréteur est décrit dans l’algorithme 1.
Algorithm 1: Cycle de l’interpréteur
1
2
3
4
5
6
7
8
9
10
début
etatCourant ←− sDebut;
tant que etatCourant 6= sFin faire
temp ←− valeurEtatSuivant();
si temp 6= etatCourant alors
enlevePropriete(etatCourant, aValeur );
listeActions ←− getlisteActions();
si executeAction(listeActions) alors
ajoutePropriete(etatCourant, temp) ;
sinon ajoutePropriete(etatCourant, erreur )
fin
Les états entre les transitions sont explicites. L’interpréteur est initialisé à l’état
sDebut qui est l’état de départ pour chaque comportement. sFin étant l’état final. Le
cycle se termine quand etatCourant = sFin (ligne 3). Si une transition est active, alors la
valeur de l’état suivant sera différente de celle de l’état actuel. L’interpréteur fait appel
au moteur de règles (cf figure 4.4) à la ligne 5, pour obtenir la valeur de la variable
etatSuivant. L’état courant est alors réinitialisé, et l’interpréteur récupère ensuite la liste
des actions de bas niveau à exécuter. Si ces dernières sont exécutées avec succès, alors
l’état suivant est activée et le cycle continue. En cas d’erreur lors de l’exécution de ces
actions, 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 partie
4.1 et dont la syntaxe a été donné dans la partie précédente. Les concepts OWL ainsi
définis, représentent le modèle sémantique des agents. Ces agents possèdent donc une
repré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 est
présenté dans la figure 4.5.
Les différents états possibles de l’agent sont des instances de la classe State. Il existe
deux é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 relation
entre comportement et état du schéma 4.6, montre la nécessité de ces deux états particuliers pour chaque comportement. La liste des actions à exécuter lors d’une transition
ainsi que les messages reçus sont des instances de listes de type OWLList 2 . Les actions
de bas niveaux sont des instances la classe Action
1
0..*
1
Connaissance Empirique
1
1
possède
Agents
Agent Courant
Propriété
valeur : String
possède
0,1
1
Pile d'exécution
1
0,1
1..*
Comportement
nom : String
Adresse : String
1
1
2..*
1..*
1
1
1
1
<<interface>>
I/O
Etat Courant
Etat
Règle SAM
nom : String
<<realize>>
Entrée
ListeActions
1
0..*
<<realize>>
Sortie
Actions
nom : String
run() : void
Action interne
Action externe
F IGURE 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ée
précédemment.
2. http://www.co-ode.org/ontologies/lists/
148
Action
subClassOf
subClassOf
disjointWih
Atomic Action
Composed Action
isa
subClassOf
subClassOf
disjointWih
Internal Action
External Action
ActionList
F IGURE 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’actions
associé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 la
base 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 suivante : tout d’abord il initialise les paramètres de l’éxécution. Puis il exécute la série
d’actions de la même manière qu’un comportement, en exécutant les actions lors de
transition 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’échanges
avec des agents. La requète sur la base de connaissances permet d’obtenir le résultat de
cette exécution, puis soit d’afficher le résultat à l’utilisateur qui confirmera ou invalidera
le 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 dispose
des opérations mathématiques standards fournies par SWRL 3 : addition, multiplication,
puissance, . . .. Un deuxième agent, Bob, sait quant à lui, en plus des connaissances
dont dispose Alice, calculer la factorielle d’un entier. Il utilise l’algorithme standard de
multiplication successive.
La fonction mathématique swrlb :add est vraie si la somme du premier et du
deuxième argument est égale au troisième. Pour obtenir la somme de 3 et 5 dans la
variable 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 volontairement
la 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 Alice
veut envoyer une question à l’agent Bob. Alice s’enregistre auprès des pages jaunes de
la plate-forme (nous proposons dans la section suivante une implémentation basée sur
JADE). Bob répond ensuite à Alice. Si le message que reçoit Alice est de Bob. S’il s’agit de
la réponse à son message précédent, alors Alice ajoute la réponse de Bob dans sa base de
connaissances. L’EFSM correspondant au comportement d’Alice est illustré par la figure
4.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 pages
jaunes. 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
150
aRecu(?x)
^ aPerformative(x,Answer)
^ aEmetteur(x, Bob)
^ hasContent(x,?y)
sDebut
A
1.
2.
RegisterDF
EnvoiMessage
sFin
AddIndividual
Paramètre
Valeur
Performative
Query
Contenu
Select ?x
Destinataire
«Bob»
Paramètre
Valeur
Individu
?y
F IGURE 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 couche
intermédiaire) interroge la base de connaissances de l’agent pour connaître la valeur
de EtatSuivant. Si cette dernière est différente de la valeur de EtatCourant cela signifie
qu’une transition doit être exécutée. L’interpréteur lit ensuite les valeurs des actions
contenues dans SequenceActions ainsi que leur paramètres respectifs. La séquence d’action 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 la
propriété aValeurParametre.
La règle spécifiant la deuxième transition contient des conditions sur le message
reçu. Il faut en effet vérifier que le message a été envoyé par Bob et qu’il a été envoyé en
réponse au message d’Alice. On vérifie donc les propriétés Emetteur et Performatives sur
le 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 pour
l’exécution de la première transition.
Bob
aValeurParametre
Question
Select ?x from..
aValeurParametre
Destinataire
aNomParametre
aValeurParametre
Performative
aNomParametre
Contenu
aNomParametre
EnvoiMessage
RegisterDF
aContenu
{RegisterDF,
EnvoiMessage}
aContenu
{EnvoiMessage}
aSuivant
{}
aSuivant
F IGURE 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 figure
4.9. Tout d’abord l’interpréteur interroge la couche sémantique pour connaitre la valeur de EtatSuivant. On a alors EtatSuivant = A. Comme A 6= sDebut, l’interpréteur
ré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 niveau
RegisterDF. Si celle-ci est exécutée avec succés, les paramètres de EnvoiMessage sont
152
A
EtatCourant = A
Execute
EnvoiMessage
Execute
Regiser DF
Actions
atomiques
{RegisterDF
EnvoiMessage}
Couche
intermédiaire
Valeur de
EtatSuivant?
Base de
connaissance
Valeur de
SequenceActions?
ensuite récupérés et l’action est appellée avec ses paramètres. Si elle est exécutée avec
succès, l’interpréteur modifie l’état de l’agent dans la couche sémantique pour que
EtatCourant = A. La transition est alors terminée et le cycle d’exécution reprend par la
comparaison des valeurs de EtatSuivant et EtatCourant.
F IGURE 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’application
d’une définition épistémologique de la connaissance. Les connaissances des deux types
ont été représentés à l’aide du formalisme fourni par les standards OWL 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 fonctions requises en terme de
communication et de gestion de la base de connaissances. Pour compléter les fonctions
requises, 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 des actions (au niveau
sémantique et opérationnel).
Notre approche a été de représenter les connaissances empiriques en nous basant sur
la représentation des comportements de l’agent, c’est-à-dire sous forme de connaissances
exécutables. L’architecture que nous avons spécifiée permet de représenter toutes les
connaissances de l’agent au même niveau d’abstraction et de disposer de méthodes
adaptées à la justification des connaissances au sein d’un système multi-agents dédié à
la gestion des connaissances.
153
La problématique posée en début de chapitre, la mise en œuvre d’une définition épistémologique de la connaissance basée sur la distinction entre connaissances empiriques
et 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 de
les rendre échangeables entre les agents.
Si l’objectif fixé a été atteint, des bénéfices non attendus ont été obtenus lors de
la réalisation. Tout d’abord, le fait de ne pas dépendre d’un langage de bas-niveau
en particulier, tout agent implémentant le modèle et les actions de bas niveaux (en
C++, JAVA ou autre langage), sera capable d’échanger ses connaissances et surtout ses
connaissances empiriques et comportements. Le deuxième avantage est l’unicité de
la base de connaissances, qui en plus des connaissances classiques, contient aussi les
comportements de l’agent.
Un homme qui cherche la vérité se fait savant ; un homme qui veut laisser sa
subjectivité s’épanouir devient peut-être écrivain. Mais que doit faire un homme
qui cherche quelque chose situé entre les deux ?
Robert Musil - "L’homme sans qualité"
5
Communauté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 . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1
Formalisation Ensembliste . . . . . . . . . . . . . . . . . . . . .
5.1.2
Ontologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.3
Agents Sémantiques et ontologie des communautés virtuelles
de connaissances . . . . . . . . . . . . . . . . . . . . . . . . . .
157
157
163
167
5.2
Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
5.2.1
Description du scénario . . . . . . . . . . . . . . . . . . . . . . 169
5.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 formalisation à l’aide de l’outil mathématique commun que représentent les ensembles et
relations. L’expressivité et la simplicité de ce cadre formel ont été déterminant dans notre
choix. De plus, il ne se restreint pas à l’utilisation d’une technologie, mais permet au
contraire 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 nous
avons décrites dans le premier chapitre.
Pour compléter le lien entre cette formalisation et les agents, nous définissons une
ontologie des commaunutés virtuelles de connaissances qui est intégrable dans la base
de connaissances de ces agents. Pour ce faire, nous traduisons les ensembles par des
classes et les fonctions par des relations. Nous présentons ensuite différents exemple
d’utilisation de cette ontologie.
Dans la description formelle des communautés virtuelles de connaissances, nous
introduisons le concept de protocoles qui va permettre d’établir le lien avec les connaissances échangeables par les agents sémantique. Nous représentons ces protocoles sous
formes de règles interprétables par les agents SAM, afin de rendre opérationnelle l’utilisation des communautés sous forme d’ontologie.
Nous présentons ensuite une application qui illustre les atouts de notre approche et
permet 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’utilisation de communautés de connaissances, décrite par l’ontologie) puis son utilisation
pour 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 communauté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émantique
dé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 formalisation à l’aide de l’outil mathématique commun que représentent les ensembles et
relations. L’expressivité et la simplicité de ce cadre formel ont été déterminant dans notre
choix. De plus, il ne se restreint pas à l’utilisation d’une technologie, mais permet au
contraire 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
158
théoriques de Calmet et Maret ainsi que sur les différentes implémentations que nous
avons décrites dans le premier chapitre.
Le premier ensemble que nous définissons est celui des agents qui composent les
communautés (dénoté ensemble M). Ces agents peuvent être autonomes ou dirigés
par un utilisateur humain. Les communautés regroupent des agents autour d’un (ou
plusieurs) élément(s) commun(s), que l’on nomme le thème. L’ensemble de ces éléments
est appellé S pour ensemble des sujets. Nous avons vu dans le premier chapitre que les
agents n’ont pas tous les mêmes fonctions au sein d’une communauté, par exemple le
leader peut dissoudre une communauté alors qu’un membre ne peut que la quitter. Ces
fonctions (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 comme
appartenant à l’ensemble R, l’ensemble A contient l’ensemble des actions possibles. Pour
lier les agents aux rôles et les rôles aux actions, nous définisson les relations rr et r p .
L’ensemble le plus intéressant au sens de nos travaux est celui des protocoles (ensemble P). Nous entendons par protocoles les règles de communication qui régissent les
inté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érationnelles" pour les agents. Ces protocoles appartenant à l’ensemble P décrivent l’implémentation des actions auxquelles nous les associons par la relation r p .
Nous proposons la formalisation suivante pour les VKC : unee communauté c appartenant à l’ensemble des communautés C est un tuple : c ∈ C = { M, R, A, P, S, rr , r a , r p }
où M, R, A, P, S sont des ensembles et rr , r a , r p 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 communauté. | 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 de
toute 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 entre
deux agents au sein de la communauté. A chaque action on associe un protocole
qui 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’ordonnancement des actions. Par exemple, on commence d’abord par rejoindre la
communauté, ensuite on échange des messages, puis on quitte la communauté. La
cardinalité de P est supérieure ou égale à un (conséquence de A non vide).
159
– 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ôles
R. 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 être
inoccupés au sein d’une communauté. De ce fait la relation rr est totale à gauche 1 .
– r a ⊆ R × A est une relation entre l’ensemble R des rôles et l’ensemble A des
actions. 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.
– r p ⊆ R × A × P est la relation qui à chaque couple (rôle,action) associe un protocole. Prenons par exemple l’action de rejoindre la communauté, le protocole sera
différent si l’agent est membre ou créateur, dans le premier cas il sera émetteur de
la 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 communauté que l’on puisse construire, dans laquelle il y a un transfert possible d’informations
entre les membres. D’aucun pourrait penser intuitivement que la communauté minimale
contient 3 actions, rejoindre,envoyermessage,quitter, on peut en fait définir une communauté avec seulement deux actions envoyermessage,quitter. Cette communauté fonctionne
comme une mailing-list ou l’envoi d’un message sur la liste entraine l’ajout comme
membre de la liste. Pour quitter la liste, on envoie un message au créateur de la liste
qui retire l’agent de la liste. La figure 5.1 illustre cet exemple. Bob est le créateur de la
communauté, 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 protocole
associé au créateur et transfère le message aux membres de la liste. Finalement Alice est
ajoutée comme membre de la liste par Bob.
Pour les protocoles, ils seront notés avec un + à la fin si l’agent qui va executer
l’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.
160
Chuck
Alice
message
membre
Bob
Nouveau membre
Créateur
Dave
membre
F IGURE 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−) ∈ r p
– (createur, createur, quitter −) ∈ r p
– (membre, quitter, quitter +) ∈ r p
– (membre, envoyerMessage, envoyerMessage+) ∈ r p
5.1.1.2
Protocoles
Les protocoles spécifient les règles de communication entre les différents agents. A
chaque action dans la communauté est associée un protocole. Ce protocole décrit les
règles de communication d’agents en spécifiant le contenu des messages échangés lors
de 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 le
cadre de la communauté-0 présentée ci-dessus. La spécification du protocole d’envoi
sous forme de diagramme séquence est présentée en figure 5.2.
161
Communauté 0 : Broadcast
membre
créateur
Membre 1
Membre N
Envoi message
Broadcast du message
F IGURE 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 fonction
de son rôle et de son historique dans la communauté, un agent ne possèdera pas les
mêmes informations que ses homologues. Prenons toujours pour exemple la communauté zéro, Alice qui vient de rejoindre la communauté, ne sait pas que Bob et Chuck sont
membres 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 de
communauté, connaît la liste de tous les membres et possède un historique de tous les
messages.
Concernant les protocoles qui régissent la communauté, il n’est pas nécessaire que
chaque agent ait connaissance de tous les protocoles. Il est même souhaitable pour des
raisons 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, selon
les protocoles d’échanges utilisés les VKC peuvent être plus ou moins efficaces. Pour
162
mesurer l’efficacité de ces communautés nous définissons l’efficacité de l’échange des
connaissances 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 f i K → [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 un
inté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 de
la communauté au temps t.
On définit alors l’efficacité de la distribution des connaissances par la formule suivante (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 maximale
quand tout les agents trouvent un intérêt dans toutes les connaissances échangées dans
le système et minimale quand aucune connaissance n’est intéressante. L’EKD donne une
mesure de l’évolution au cours du temps de cette efficacité. Son intégrale normalisée
R t2
sur le temps
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
5.1.1.6
dEDKT (t)
dt
indique la variation instantanée de l’efficacité.
Conclusion
Dans cette partie nous avons présenté une formalisation ensembliste des VKC basées
sur les travaux précédents et sur des éléments identifiés lors de différentes implémentations. A la lumière des travaux réalisés sur l’échange de connaissances qui peuvent être
exécutées par un agent, nous avons défini une formalisation des VKC qui permet de
prendre en compte cette notion afin d’opérationnaliser cette connaissance des VKC. La
notion de protocole a été définie pour intégrer des connaissances exécutables au sein de
la 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’illustrer
notre approche et l’utilisation de protocoles. La prochaine étape est d’adapter cette
formalisation au format OWL qui est celui manipulé par nos agents. C’est l’objet de la
prochaine sous-partie.
5.1.2
163
Ontologie
Nous avons présenté une formalisation ensembliste des communautés virtuelles de
connaissances, ainsi qu’une spécification plus précise des protocoles, s’appuyant sur
les règles qui régissent le comportement des agents. Pour compléter le lien entre cette
formalisation et les agents, nous définissons une ontologie des commaunutés virtuelles
de connaissances qui est intégrable dans la base de connaissances de ces agents. Pour ce
faire, nous traduisons les ensembles par des classes et les fonctions par des relations.
Le changement par rapport à la formalisation ensembliste concerne la relation ternaire r p qui ne peut exprimer directement en OWL. En OWL les relations sont par
définition binaires. Pour contourner cette limitation, nous introduisons une classe intermédiaire qui possède les deux propriétés requises. Pour la relation r p , ceci se traduit
par l’ajout de la classe intermédiaire AP (pour Action Protocole). Cette méthode fait
partie, avec deux autres des méthodes de conception préconisée par le W3C dans la
note 2 concernant les relations n-aires . les figures 5.3 et 5.4 montrent le fonctionnement
de cette classe intermédiaire.
Actions
Rôles
Protocoles
F IGURE 5.3 – Relation ternaire, impossible à représenter en OWL
Actions
hasAction
hasAP
Rôles
AP
hasProtocol
Protocoles
F IGURE 5.4 – Introduction de la classe AP, pour représenter la relation r p
2. http://www.w3.org/TR/swbp-n-aryRelations/
164
Classes
Les différentes classes de l’ontologie sont en partie celles définies lors de la formalisation 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 la
communauté. La classe Role décrit les différents rôles possibles qui sont liés à des
actions (classe CommunityAction) et des protocoles (classe Role. La classe AP permet
de représenter la relation ternaire entre un rôle, une action et un protocole. Finalement
la classe Topic décrit le sujet ou thème d’une communauté. Le tableau suivant liste ces
classes.
Nom
Description
AP
Agent
Community
CommunityAction
LeaderAgent
LeaderRole
Protocol
Role
Topic
Thing
Thing
Thing
Thing
Agent
Roles
Thing
Thing
Thing
Action/Protocole pour relation ternaire
Agent
Communauté virtuelle de connaissances
Action, associée à une communauté
Agent de type leader
Rôle de leader
Protocole de communication
Roles dans la communauté
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ôles
sont à la fois liées aux agents et aux communautés. La relation entre rôles et agents
est donnée par memberHasRole. Celle avec les communautés est décrite par hasRole
et son inverse roleOf. Les rôles sont aussi liés aux actions et aux protocoles qui leur
sont associés par l’intermédiaire des relations hasAP, hasAction et hasProtocol qui
représentent la relation ternaire.
Nom
Source
But Description
hasTopic
hasAP
hasAction
hasProtocol
hasMember
memberOf
hasRole
roleOf
memberHasRole
Community
Roles
AP
AP
Community
Agent
Community
Community
Agent
Topic
AP
CommunityAction
Protocols
Agent
Community
Role
Role
Roles
associe une communauté à un sujet
relation associant des actions et protocoles à u
associe un AP à une action
associe un AP à un protocole
défini les membres d’une communauté
inverse de hasMember
associe un rôle à une communauté
inverse de hasRole
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
165
Vue des agents
La vue d’une communauté dans la base de connaissances d’un agent se traduit
par les différentes instances des classes qu’il possède. Dans l’exemple précédent de la
communauté 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 → membre
Chuck → membre
Dave → membre
– Actions : envoyerMessage+,envoyerMessage-,quitter
– Topic : le sujet de la communauté
Roles : membre, créateur
Membres : Alice,Bob,Chuck,Dave
MemberHasRole : Alice → membre
Bob → createur
– Actions : envoyerMessage+,quitter
Chuck
–
–
–
Dans le cas d’une communauté centralisée telle que la communauté-0, il apparaît que
seul le créateur de la communauté possède une vue complète de la communauté. Dans
le cas de communautés décentralisées, le créateur possède l’ensemble des protocoles de
communication, cependant il ne connaît pas l’intégralité des agents appartenant à la
communauté et possède de ce fait une vue partielle.
La notion de vue de la communauté est capitale puisqu’elle permet de maintenir la
connaissance 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 fonctionnement 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 !. Les
groupes Yahoo offrent les fonctionnalités suivantes aux utilisateurs :
3. http://fr.groups.yahoo.com
166
– 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 site
Les 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érents
rôles au sein des communautés. Les rôles de membres, manager et créateur sont ceux
spécifiés par Yahoo ! Groups. A ces 3 rôles s’ajoutent celui de Yahoo ! en tant qu’hébergeur
des communautés et fournisseur d’un service de recherche de ces communautés. La
cardinalité du créateur est de 1, puisqu’il ne peut y avoir qu’un seul créateur, il en est
de même pour l’hébergeur. Les rôles de manager et utilisateur ne sont pas limités en
nombre.
Les fonctionnalités décrites précédemment permettent de définir les actions, tout
d’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, SupprimerFichier}
– Annuaire de liens : {CréerRépertoireAnnuaire, SupprimerRépertoireAnnuaire, AjouterLien, 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}
167
– 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 donc
29+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 un
protocole pour l’émetteur et un pour le récepteur. A noter que l’hébergeur est ici le seul
récepteur des actions.
Cet exemple permet d’illustrer l’utilisation de l’ontologie que nous de définir dans
un 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 un
processus qui a nécessité peu de modifications par rapport à la version de départ. Les
formalismes étant relativement proches dans le concept, seule la relation ternaire a
du être transformée. Les spécificités de OWL, telles que les relations inverses et les
restrictions sur les relations permettent d’exprimer pleinement notre approche des
communautés dans une ontologie qui est manipulable par les agents.
Chaque agent possède une vue différente de la communauté puisque chaque agent
selon rôle ou le moment ou il a rejoint la communauté, ne possède pas les mêmes
informations. Nous avons illustré ce concept à l’aide de la communauté zéro. L’exemple
des Yahoo ! Groups a quant à lui illustré le fonctionnement de l’ontologie ainsi que son
expressivité pour décrire un cas réel.
5.1.3
Agents Sémantiques et ontologie des communautés virtuelles de connaissances
Dans la description formelle des communautés virtuelles de connaissances, un point
reste à éclaircir. En effet, nous n’avons donné aucune précision quant à la nature des
protocoles. Ces protocoles décrivent les mécanismes de communication entre les agents
ainsi que les actions à effectuer à la récéption d’un message. Ces protocoles sont donc
représentables comme des comportements pour les agents SAM, puisqu’ils contiennent
des actions à effectuer. Nous allons donc représenter ces protocoles sous formes de règles
interprétables par les agents SAM.
En utilisant les spécifications sur les agents SAM, nous pouvons définir plus précisément la notion de protocoles pour ces agents. Les messages échangés par les agents
utilisent la norme FIPA-ACL et les différents champs qui les composent sont définis
dans l’annexe C.
168
L’expression des protocoles sous forme de règles éxécutables, permet de décrire
totalement l’implémentation d’une communauté, et de transformer cette formalisation
en une formalisation « utilisable » en opposition avec une formalisation « descriptive ».
En reprenant l’exemple du protocole de la communauté-0 à la figure 5.2 nous pouvons maintenant décrire ce protocole sous forme de règles SWRL telles que définies au
chapitre 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 de
requète, le contenu du message est celui du message à transférer et le protocole du
message 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 message
est transmis à tout les membres de la communauté et l’émetteur du message
devient 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écifications
que nous avons donné au chapitre précédent. Ils permettent une description sémantique complète de la communauté, qui ne se restreint pas à une simple spécification
de concepts, mais le fait qu’ils contiennent un code exécutable par l’agent rend cette
représentation sémantique des communautés opérationnelle et directement utilisable
par les agents. C’est un des apports principaux de notre approche. La représentation
sémantique des comportements des agents que nous avons défini au chapitre précédent
permet d’embarquer du code sémantique au sein d’une ontologie et par conséquent de
donner une implémentation de la communauté.
5.2 Application
Dans ce chapitre nous avons défini une formalisation, puis une ontologie des communauté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 connaissances et des comportement dans les formats du web sémantique et deuxièmement, la
repré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 notre
approche et de mettre en œuvre les différents concepts que nous avons défini. Nous
avons vu dans la section 5.1.1.2, un premier lien entre l’architecture des agents et l’ontologie des communautés de connaissance. Les protocoles qui définissent les intéractions
entre les agents au sein d’une communauté sont en fait des actions exécutables directement par les agents. Nous allons poursuivre dans cet exemple l’illustration des différents
concepts 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 par
l’intermédiaire de messages respectant la norme FIPA-ACL. Cet exemple permet de
mettre en œuvre les concepts d’échanges de connaissances empiriques et de représentation ontologique des communautés de connaissance, tels que nous les avons énoncés
dans les chapitres précédents.
Dans ce scénario l’agent Julio, cherche à répondre à « La grande question sur la
vie, l’univers et le reste » 4 . Au début de ce scénario, l’agent Julio connaît seulement
l’agent Carmen. Il lui demande si elle connaît la réponse à la fameuse question. Carmen
ne 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 de
ces communautés de connaissances. Jusqu’ici Julio n’avait pas connaissance du concept
même de communautés de connaissances. Il apprend grâce à Carmen l’existence et le
fonctionnement 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 de
communautés virtuelles de connaissances. L’agent Julio, qui connaît désormais le fonctionnement 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
170
Agents
Le scénario présente deux agents sémantiques, Julio et Carmen ainsi que trois agent
non sémantiques PagesJaunes, PenséesProfondes et Loonquawl. Les agents dits sémantiques
possède l’architecture que nous avons défini au chapitre précédent. Les agents non
sémantiques ne possède pas cette architecture.
Communautés
Les communautés de connaissances au sein du système possèdent les propriétés
suivantes :
– Les agents intéragissent au sein d’une communauté par le biais d’un tableau
noir qui est hébergé par l’agent créateur de la communauté. Les agents peuvent
lire 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 cette
implémentation comme une instance de notre modèle de commaunuté défini
précédemment.
– Le créateur de la communauté maintient la liste des agents membres de la communauté.
– Les communautés sont listées au sein d’un annuaire de communautés, aussi
appellé la « Communauté des communautés ». L’annuaire propose un service
d’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 classe
OWL.
La communauté des commaunutés peut-être vue comme le point d’entrée d’un forum
distribué. Chaque discussion autour d’un thème est hébergée par un agent différent et le
mode 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 communautés de connaissances et comment y participer. Ce que sont ces communautés est
décrit par une instance des concepts de l’ontologie des VKC. Le comment est décrit par
une 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éer
une 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 à une
communauté (si il n’existe pas de communauté, elle est alors créée par l’agent). Le
code 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 communauté
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’agent
qui utilise cette connaissance doit être en mesure de rejoindre une communauté. La
requè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é la
connaissance qui lui a été transmise. Nous verrons par la suite qu’à l’issue de l’exécution
de 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 lui
transmettra sa connaissance des communautés virtuelles de connaissances. Parallèlement Penséesprofondes crée une communauté autour du thème de la Grande question de
la vie, il déclare l’existence communauté aux PagesJaunes. Longhorn souhaite partager la
réponse qu’il possède avec d’autres agents connaît le fonctionnement des communautés
virtuelles de connaissances. Il recherche la communauté adéquate pour partager son
savoir. Il contacte alors les PagesJaunes puis rejoint la communauté initiée par Penséesprofondes et partage son message qui est inscrit sur le tableau de la communauté. Julio
a appris par Carmen, l’existence et le fonctionnement des communautés, il contacte
alors les Pagesjaunes, rejoint la communauté initiée par Penséesprofondes puis récupère la
réponse déposée par Longhorn. Les messages échangés entre les agents dans ce scénario
sont illustrés par la figure 5.6.
172
Evaluation interne
de l’agent
L’agent doit-il
rester dans la
communauté ?
Appartient à
une communauté
N’appartient pas
à une commaunuté
Obtenir la liste des
communautés sur
le thème
Changer
|Communautés|=0
|Communautés|>0
Choix de la
communauté
Rester
Création de la
communauté
Communauté
Communauté
Echange de
connaissances
F IGURE 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’agent
Julio a acquis un savoir-faire qui lui a permis d’obtenir la réponse à la grande question
fondamentale de la vie. Cet exemple a permi de montrer les possibilités ouvertes par
l’échange de connaissance empirique et de montrer une utilisation pratique de l’ontologie 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 la
description de communautés virtuelles de connaissance à l’aide du formalisme défini
dans ce chapitre.
5.3 Conclusion
Nous avons présenté une formalisation ensembliste des VKC basées sur les travaux
précédents et sur des éléments identifiés lors de différentes implémentations. A la
173
F IGURE 5.6 – Exemple : diagramme des messages échangés par les agents lors de
l’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ées
par un agent, nous avons défini une formalisation des VKC qui permet de prendre
en compte cette notion afin d’opérationnaliser la connaissance des VKC. La notion
de protocole a été définie pour intégrer des connaissances exécutables au sein de la
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’illustrer
notre approche et l’utilisation de protocoles.
La transformation de la formalisation ensembliste en une ontologie OWL est un
processus qui a nécessité peu de modifications par rapport à la version de départ. Les
formalismes étant relativement proches dans le concept, seule la relation ternaire a
du être transformée. Les spécificités de OWL, telles que les relations inverses et les
restrictions sur les relations permettent d’exprimer pleinement notre approche des
communautés dans une ontologie qui est manipulable par les agents.
Chaque agent possède une vue différente de la communauté puisque chaque agent
selon rôle ou le moment ou il a rejoint la communauté, ne possède pas les mêmes
informations. Nous avons illustré ce concept à l’aide de la communauté zéro. L’exemple
des Yahoo ! Groups a quant à lui illustré le fonctionnement de l’ontologie ainsi que son
expressivité pour décrire un cas réel.
Nous avons ensuite présenté l’intégration des protocoles avec le concept d’agent
sémantique. Les protocoles sont des séquences exécutables par l’agent, suivant les spéci-
174
fications que nous avons données au chapitre précédent. Ils permettent une description
sémantique complète de la communauté, qui ne se restreint pas à une simple spécification de concepts, mais le fait qu’ils contiennent un code exécutable par l’agent rend cette
représentation sémantique des communautés opérationnelle et directement utilisable
par les agents. C’est un des apports principaux de notre approche. La représentation
sémantique des comportements des agents que nous avons défini au chapitre précédent
permet d’embarquer du code sémantique au sein d’une ontologie et par conséquent de
donner une implémentation de la communauté.
Finalement nous avons présenté un exemple illustratif, détaillant les protocoles et les
intéractions entre les agents. Cet exemple a permis de montrer les possibilités ouvertes
par l’échange de connaissance empirique et de montrer une utilisation pratique de l’ontologie 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
la description de communautés virtuelles de connaissance à l’aide du formalisme défini
dans ce chapitre.
The brain is a computing machine connected with a spirit.
Kurt Gödel, in A logical journey : from Gödel to philosophy
6
Implémentation
176
Chapitre 6. Implémentation
Plan du chapitre
6.1
Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
6.2
Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
6.3
Exécution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
6.3.1
Initialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
6.3.2
Comportements . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
6.4
Actions . . . . . . . . . . . . . .
6.4.1
Gestion des ontologies .
6.4.2
Entrées/Sorties . . . . .
6.4.3
Connaissance empirique
6.4.4
Communications . . . .
6.4.5
Appel des actions . . . .
6.5
Base de connaissances . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
6.5.1
Base minimale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
6.6
Conclusion et discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 191
6.6.1
Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
183
183
185
186
186
187
Section 6.1. Choix techniques
177
réalisation d’un prototype est une étape importante dans la validation de notre
approche. Nous présentons dans ce chapitre les différents éléments de l’implémentation de notre protoype. Dans une première partie nous détaillons et motivons les choix
techniques. Ensuite nous entrons dans le cœur même de l’application en décrivant la
structure de classes, nous énumérons et décrivons de manière systèmatique les classes
et méthodes. Nous présentons ensuite les différentes étapes d’exécution d’un agent, son
initialisation et le fonctionnement de l’interpréteur SAM. Cet interpréteur fait appel
aux actions de bas niveau qui complètent les actions SWRL. Nous détaillons en section
6.4 les actions de bas niveaux ainsi que le mécanisme d’appel de ces actions. Ensuite
nous présentons la structure de la base de connaissances qui permet d’exécuter des
comportements sémantiques. Nous listons les différents éléments spécifiés au cours des
sections précédentes.
L
A
Les difficultés rencontrées lors du développement du prototype font l’objet de la
section 6.6. Nous discutons au sein de cette même section des limitations techniques
du prototype et des moyens, le cas échéant de les dépasser. Nous terminons par les
perspectives offertes par le développement de ce prototype et présentons les futurs axes
de développement.
6.1 Choix techniques
Les contraintes de réalisation du prototype étaient extrêmement faibles. Seul le
support du langage FIPA-ACL pour l’interopérabilité avec l’ancien prototype était
requis. 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 de
connaissance 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 agents
au sein de la plate-forme JADE mais non à la plate-forme elle-même. L’expérience de la
plate-forme ainsi que la perspective de faire cohabiter simplement les agents des VKC
avec les agents sémantiques ont motivé ce choix.
Le choix du raisonneur s’est fait entre les différents raisonneurs proposant un support SWRL : RacerPro, Bossam, Pellet, KAON2 et Fact++. Bossam et RacerPro n’étant
plus maintenu depuis 2007, ils ont été rapidement écarté. L’utilisation de JADE nous
imposant une API Java, Fact++ (développé en C++) a été écarté. KAON2 et Pellet (tous
deux en JAVA et offrant un support DL-Safe) possèdent deux approches différentes. le
premier utilise un système déductif de type "Forward Chaining" alors que le second
utilise une approche par tableau calcul. Le but de notre prototype étant de fournir une
preuve de concept et non de manipuler de grandes ontologies, la méthode de raisonnement importait peu. Le support de SWRL (des fonctions built-ins) était au départ du
178
développement très partiel pour les deux raisonneurs. Le critère de sélection s’est donc
fait sur la qualité du développement du projet, les exemples fournis, l’activité du forum
de 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 agents
JADE. Afin d’intégrer un support pour OWL et SWRL dans la base de connaissances des
agents, nous avons étendu la librairie AgentOWL pour permettre d’intégrer le support
du raisonneur Pellet au modèle Jena. L’échange de règles SWRL au travers d’une API
Java a nécessité l’utilisation de l’API Protege, Jena ne supportant pas l’ajout de règles
au modèle. En utilisant les compatibilités entre les deux modèles, nous maintenons une
représentation homogène. Une ontologie du projet Nuin [Dickinson03] a été intégrée
afin de représenter les messages FIPA-ACL au format OWL. L’ontologie OWLList de
Drummond [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 plugins
MaintainJ 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 de
JADE. Cette classe SemanticAgent possède un attribut mem de type KnowledgeBase
qui représente la base de connaissances.
La seule implémentation de KnowledgeBase est la classe SWRLMemory qui permet de gérer la base de connaissances OWL et SWRL de l’agent. Cette classe est
adapté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 type
com.hp.hpl.jena.ontology.OntModel représente la vue JAVA de la base de
connaissances de l’agent. Le choix de Jena est du au choix du raisonneur Pellet. En
effet 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 factory
ModelFactory :
model = ModelFactory.createOntologyModel(PelletReasonerFactory.THE_SPEC);
Le modèle Jena est stocké en mémoire, il est cependant parfois nécessaire d’utiliser
un modèle de la librairie Protégé API pour certaines actions non disponibles dans
l’API Jena. Les deux modèles étant interchangeables, la librairie ProtegeOWL permet
1. http://www.maintainj.com
2. http://www.objectaid.com
+mem
SWRLMemory(String,String)
getBase(): String
initModel(): OntModel
performInference(String,boolean): void
memory2swrl(): void
setModel(OntModel): void
getModel(): OntModel
config: Config
model: OntModel
agent.core.memory
SWRLMemory
<<Java Class>>
setModel(OntModel): void
getModel(): OntModel
config: Config
model: OntModel
agent.core.memory
KnowledgeBase
<<Java Interface>>
#myAgent
jade.core.behaviours
ThreadedBehaviourFactory
<<Java Class>>
-tbf SWRLAgent()
chainRules(): void
extractParameter(String,HashMap<String,String>): String
setup(): void
executeActions(Individual): void
executeAction(String,HashMap<String,String>): void
retrieveParameters(Individual): HashMap<String,String>
noChildBehaviour(): boolean
stackSize(): int
popBehaviour(): void
num: int
agent.core.swrlagent
SWRLAgent
<<Java Class>>
agent.core.onto
SemanticAgent
<<Java Class>>
jade.core
Agent
<<Java Class>>
Behaviour
<<Java Class>>
MessageBehaviour(Agent,long)
onTick(): void
MessageBehaviour
<<Java Class>>
action(): void
done(): boolean
done: boolean
SemanticBehaviour
<<Java Class>>
SimpleBehaviour
<<Java Class>>
TickerBehaviour
<<Java Class>>
Section 6.2. Classes
179
F IGURE 6.1 – Diagramme de classe d’un agent
180
d’importer un modèle Jena et d’exporter un modèle Protégé au format Jena. L’appel
au raisonneur Pellet étant requis par l’interpréteur qui est le composant principal de
l’agent, le modèle Jena est la représentation permanente de la base de connaissances. Les
diffé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 la
règle est passé en paramètre, ainsi qu’un booléen indiquant si l’on souhaite garder
la trace des propositions inférées.
memory2swrl : sauvegarde la base de connaissances sous la forme d’un fichier. Le nom
et chemin du fichier sont définis dans config.
setModel : accesseur permettant de remplacer le modèle courant par celui passé en
paramè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 connaissances, un processus dédié y est affecté en plus de celui dédié au comportement classique
de l’agent. Au niveau de l’architecture JADE il est possible d’affecter plusieurs comportements à un agent à l’aide de la classe ThreadedBehaviourFactory. Un agent
SWRLagent possède un objet tbt de type ThreadedBehaviourFactory pour gérer
ces comportements. Les comportements sont ensuite executés de manière parallèle. Les
deux comportements utilisés sont SemanticBehaviour en charge du comportement
principal de l’agent et MessageBehaviour en charge de la gestion des messages.
MessageBehaviour est un comportement de type TickerBehaviour. Ce type
de comportement est exécuté de manière périodique par l’invocation de la méthode
onTick(). Dans l’architecture JADE, un agent possède une queue de messages accessible par différentes méthodes. Le rôle de ce comportement est de transférer les messages
reçus de la couche JADE à la couche sémantique, en convertissant les messages ACL
reçus en instance OWL de la classe message.
Le comportement SemanticBehaviour est un comportement de type
jade.core.behaviours.SimpleBehaviour, c’est-à-dire un comportement simple
qui 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 langage
SAM. En tant qu’agent de type jade.core.agent.Agent, la méthode setup est invoquée lors de l’initialisation de l’agent. Cette méthode initialise la base de connaissances
en créant l’objet mem de type SWRLMemory. La méthode principale est chainRules qui
enchaî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 renvoie
vraie si le comportement courant est le seul comportement executé, c’est-à-dire qu’il
n’est pas le fils d’un comportement qui l’a invoqué. La méthode stackSize renvoie la
taille de la pile d’appel, et zéro quand noChildBehaviour renvoie vraie. Le rôle de
la 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 il
n’y a pas de comportement père, l’agent termine.
La méthode chainRules fait appel au raisonneur Pellet qui exécute les fonctions SWRL de haut niveau, puis cette méthode extrait du conséquent des règles la
séquence des actions à exécuter ainsi que leurs paramètres respectifs. La méthode
executeActions exécute la séquence d’actions associée à une règle. Pour cela elle
fait appel à la méthode retrieveParameters pour extraire les paramètres de l’action
courante à 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érentes
classes décrites.
6.3 Exécution
L’exécution d’un agent sémantique se fait en deux temps, tout d’abord l’initialisation
de l’agent qui comprend le chargement de la base de connaissances et le lancement
de l’interpréteur. La deuxième phase, le régime permanent est celui de l’exécution du
comportement 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 de
jade.core.agent.Agent, la méthode setup est invoquée. Cette méthode initialise la base de connaissances SWRLMemory qui fait appel à la configuration
chargée par la classe Config. Les deux comportements SemanticBehaviour et
MessageBehaviour 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 figure
6.2 décrit l’initialisation d’un agent.
6.3.2
Comportements
Les deux processus (comportement au sens de JADE) SemanticBehaviour et
MesssageBehaviour nécessitent la synchronisation des ressources partagées. Le processus de l’interpréteur SAM peut accéder potentiellement à toute la base de connais-
182
F IGURE 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 de
messages. Il était donc nécessaire de synchroniser l’accés à cette file, ce qui est réalisé de
manière classique par un mutex (primitive d’exclusion mutuelle).
L’exécution du comportement de gestion des messages MessageBehaviour se
fait de manière régulière (temps paramétrable, fixé par défaut à 250ms). La méthode
onTick qui est invoqué par la factory des comportements regarde si la file des messsages de l’agent est non vide en appellant la méthode getCurQueueSize de la classe
jade.core.agent.Agent. Dans le cas ou un ou plusieurs messages sont présents
dans cette liste, les messages sont convertis dans au format OWL puis intégré à la liste
des messages en attente de la base de connaissances. Nous avons réutilisé l’ontologie
FIPA-ACL définie par Ian Dickinson pour le framework Nuin 3 [Dickinson03]. La structure de séquence des messages au sein de la base de connaissances n’étant pas définie
en OWL (à la différence des listes RDF), nous avons fait appel à l’ontologie OWLList de
Drummond [Drummond06]. Cette même ontologie est aussi utilisée pour représenter
les 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. Une
fois acquis, l’agent ajoute un message en fin de liste.
Le comportement SemanticBehaviour exécute l’interpréteur SAM par l’invocation 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
Section 6.4. Actions
183
de l’état BEGIN. Un comportement SAM termine si l’état courant est END 4 . Un comportment pouvant invoquer un autre comportement, une pile des appels est maintenue
au niveau de la base des connaissances. Une variable currentBehaviour pointe vers
le comportement courant. La propriété calledBy permet de lier les comportements
au 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 comportement
terminé (à 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 valeur
currentState qui indique la valeur de l’état courant au moment ou un comportement
fils a été invoqué. Toutes les autres variables sont considérées comme globale à la base
de connaissances. L’exécution d’une règle de transition est effectuée dans un premier
temps 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 NextState
dans la base de connaissances, il charge alors la liste des actions qui se situe au niveau
de la variable AL (pour Action List). Cette liste est une OWLsList, tout comme la liste
des messages reçus. L’exécution de la séquence d’actions se fait en exécutant une à une
les actions par l’invocation de la méthode executeAction. Nous décrivons dans la
section suivante le mécanisme d’appel de ces actions et nous en donnons la liste. La
figure 6.3 présente le diagramme d’activité des agents SAM (sans le comportement de
gestion des messages).
6.4 Actions
Les actions de bas niveau sont invoquées par l’interpréteur dans l’ordre spécifié par
la liste. Les actions qui doivent être exécutées sont liées par la propriété hasNext, les
paramètres sont liées à l’action (qui est une instance de l’action qu’elle représente) par la
propriété hasParameterName qui définit le nom du paramètre. Ce nom prend ensuite
une 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 suppression
pour 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 sont
définis en section 6.5
184
Diagramme d’activité des agents
Rouge : 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 comportement
Démarrage
Etatcourant= début
Exécution première règle:
1 Lecture de l’état suivant
2 Exécution des fonctions sémantiques
Etatsuivant = END
Mise à jour
Étatcourant=etatsuivant
Etatsuivant <> END
Pas d’action
Lecture de la taille de la pile
des comportements
Taille<>0
Lecture de la
liste des actions
Taille = 0
Lecture de
l’action à exécuter
Action présente
Dépiler
Passage à l’action suivante
Récupération des paramètres
Exécution de l’action
F IGURE 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é. Le
raisonneur étant appellé en premier, les actions de haut niveau seront effectuées avant
celles de bas niveau. Il se peut que l’on souhaite effectuer certaines actions (comme par
exemple affecter une propriété ou une valeur à un individu) après l’exécution des actions
de haut niveau. Ces fonctions existent donc dans les actions de haut et bas niveaux. Les
185
autres fonctions de gestion des ontologies sont définies exclusivement à bas niveau. Le
tableau suivant liste toutes les actions de gestion des ontologies.
Nom
CreateIndivudal
ModifyIndividual
DeleteIndividual
CreateClass
ModifyClass
DeleteIndividual
CreateProperty
ModifyProperty
DeleteProperty
Paramètres
Description
class : URI de la classe
name : nom de l’individu
oldName : ancien nom
newName : nouveau nom
Création d’un individu
name : nom de la classe
oldName : ancien nom
newName : nouveau nom
nom de la classe : nom de la classe
Création d’une classe
Modification d’une classe
name : nom de la propriété
param1 : paramètre 1
param2 : paramètre 2
type : type de la modification
Création d’une propriété
Modification de la propriété
Modification d’un individu
Suppression d’un invididu
Suppression d’une classe
Suppression d’un invididu
La méthode modifyProperty doit permettre d’effectuer les opération de modification 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/individu
Ces 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 être
totalement 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 est
une classe, son nom est affiché. Si la ressource est un individu, on afficher son nom et
dans 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.
Nom
Paramètres
Description
DisplayValue
SaveMemory
uri : URI de la ressource
Aucun
Affiche une valeur à l’écran
Sauvegarde la base de connaissances dans un fichier
186
6.4.3
Connaissance empirique
Pour valider les connaissances empiriques ou justifiables, nous avons défini deux
actions qui sont CheckConsistency et RunQuery. La première permet de vérifier la
consistance de la base de connaissances. La méthode de vérification de la consistance
fait appel à validate de com.hp.hpl.jena.rdf.model.InfMOdel. Le résultat du
rapport de validation (méthode isValid()) est placée dans OUTPUT. Cette action est
utilisé pour choisir d’intégrer ou non de nouvelles connaissances dans la base, si elles
sont consistantes avec la base. La seconde action permet d’exécuter une requète SPARQL
sur la base de connaissances, le résultat étant aussi stocké dans OUTPUT. Elle est utilisée
pour 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 la
fonction 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 est
constitué de son état courant est sauvegardé. Le comportement appellé est alors exécuté.
Nom
RunQuery
LoadBehaviour
CheckConsistency
6.4.4
Paramètres
Description
query : requète
Exécute une requète SPARQL.
Le résultat est stocké dans OUTPUT
Chargement d’un comportement
Vérifie la consistance
de la base de connaissances
avec les ressources (optionnel)
uri : uri
ressources : URI
(Optionnel)
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ètre
un individu de la classe OWL représentant les messages FIPA-ACL ainsi que son destinataire (ce paramètre s’est révélé être superflu puisque contenu dans l’ontologie du
message, mais a été conservé par souci de rétrocompatibilité). Les messages sont ajoutés
par le comportement messageBehaviour dans une file de message. Le système de
pages jaunes de JADE (Directory Finder) sera noté ici DF. Deux actions permettent
d’intéragir avec le DF, RegisterDF et AskDF. La première action permet d’enregistrer
l’agent courant auprès du système de pages jaunes. La seconde permet quant à elle de
rechercher des services dans le DF.
187
Nom
Paramètres
Description
RegisterDF
AsKDF
Aucun
ServiceName : nom du service
dest : agent récepteur
content : URI/nom du fichier
dest : agent récepteur
content : URI du message
sender : expéditeur
Enregistre l’agent au DF
Requète d’existence de service
Envoi d’un comportement
à un agent
Envoi d’un message
SendBehaviour
SendBMessage
ReceiveMessage
Réception avec attente active
La méthode ReceiveMessage est utilisée dans le cas ou l’on souhaite attendre
explicitement l’arrivée d’un message d’un expéditeur précis avant de continuer le
traitement.
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 celles
de 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 connaissances, 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 actions par l’interpréteur se fait par les mécanismes de réflection de JAVA. Les actions
prennent deux paramètres ; l’agent qui les exécute ainsi que l’ensemble des paramètres
de 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 est
passé à la méthode ainsi que les paramètres (actionName et parameters). Une classe
JAVA de type Class typée sur l’interface Action est instanciée à l’aide de la méthode
Class.forName du package java.lang.reflect. Une instance de l’action est ensuite 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 courant et les paramètres de la fonction. Le code JAVA de cette méthode executeAction
est donné dans le listing 6.1.
Listing 6.1– executeAction de la classe SWRLAgent
1
2
p r o t e c t e d synchronized void e x e c u t e A c t i o n ( S t r i n g actionName ,
HashMap< S t r i n g , S t r i n g > parameters ) {
3
4
5
6
7
Class <Action > c l a s s e ;
try {
c l a s s e = ( Class <Action >) C l a s s . forName ( " agent . c o r e . a c t i o n s . " +
actionName + " Action " ) ;
Action a c t = ( Action ) c l a s s e . newInstance ( ) ;
188
<<Java Class>>
<<Java Class>>
DisplayValueAction
SaveMemoryAction
agent.core.actions
agent.core.actions
run(SWRLAgent,HashMap<String,String>): void
<<Java Class>>
AskDFAction
agent.core.actions
<<Java Class>>
CreateIndividualAction
agent.core.actions
<<Java Class>>
RegisterDFAction
agent.core.actions
<<Java Class>>
ModifyIndividualAction
<<Java Class>>
SendBehaviourAction
agent.core.actions
agent.core.actions
<<Java Interface>>
Action
agent.core.actions
<<Java Class>>
DeleteIndividualAction
<<Java Class>>
agent.core.actions
SendMessageAction
agent.core.actions
<<Java Class>>
ReceiveMessageAction
agent.core.actions
<<Java Class>>
RunQueryAction
agent.core.actions
<<Java Class>>
LoadBehaviourAction
<<Java Class>>
CheckConsistencyAction
agent.core.actions
agent.core.actions
F IGURE 6.4 – Diagramme de classes des actions
Section 6.5. Base de connaissances
a c t . run ( t h i s , parameters ) ;
} catch ( Exception e ) {
e . printStackTrace ( ) ;
}
8
9
10
11
12
189
}
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 et
instances dans deux fichiers séparés. Dans notre approche le comportement initial et
le reste de la base de connaissances sont dans deux fichiers distincts. Les fichiers sont
accessibles 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 de
la base de connaissances. Nous listons ici les différentes classes, valeurs et propriétés
requises pour le fonctionnement de l’agent. Ces éléments constituent l’ontologie du
modèle de l’agent. Cette ontologie doit être importée dans la base de connaissances. Ce
sont les valeurs de ces ressources qui seront accédées et modifiées par l’interpréteur
pour exécuter le comportement des agents.
Classes
Le modèle des agents SAM définit six classes (au sens OWL), qui sont les classes
repré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é. Dans
l’implémentation l’agent possède une valeur (owl :hasValue) qui est son adresse dans
la plate-forme JADE. Les états sont décrits par la classe State, la valeur de l’état est
une chaîne de caractère. Deux valeurs sont spéciales, BEGIN et END qui spécifient le
commencement 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 individus
de ExecAction sont des individus de Action. Cette "copie" s’avère nécessaire pour
pouvoir exécuter dans la même séquence d’action deux fois la même action avec des
paramè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équence
d’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 ExecAtion
ont toutes deux la même valeur : SendMessage mais possèdent des paramètres différents.
190
Nom
Agent
State
Action
Behaviour
ExecAction
restriction
Description
Prend une valeur de type String
Prend une valeur de type String
Même valeur que Action
Représente un agent
Etat au sens des EFSM
Action de bas niveau
Comportement
Action de bas niveau
A ces classes que nous avons définies, s’ajoutent les classes importées des ontologies
OWLList et FIPA-ACL (ontologie représentant les messages FIPA ACL).
Individus
Deux individus de la classe State sont nécessaires pour le fonctionnement. Ce
sont les états CurrentState et NextState. Le rôle de ces états est de donner la
valeur 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) pour
déterminer l’exécution d’une transition. Les 19 actions décrites dans la partie précédentes
sont des individus de la classe Action. Il existe un comportement particulier qui est le
comportement courant de l’agent, représenté par CurrentBehaviour et qui prend ses
valeurs dans les individus de classe comportement. De la même manière il existe une
liste 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ésenter
la file de réception des messages, on utilise ML (pour MessageList) lui aussi individu de
la classe OWLList.
Nom
Classe
Description
CurrentState
NextState
{SendMessage,. . . }
CurrentBehaviour
AL
ML
OUTPUT
State
State
Actions
Behaviour
OWLList
OWLList
Object
L’ensemble des 19 actions
Comportement courant
Liste des actions à exécuter
Liste des message
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’un
comportement, 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, qui
doit 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
behaviourLocation
hasParameterName
Behaviour
Behaviour
ExecAction
Behaviour
String et URIreference
Individu
Pile des appels
Emplacement d’un comportement
Nom du paramètre
6.6 Conclusion et discussion
La mise en œuvre du prototype a permis de valider l’approche théorique par une
réalisation simple. Les limitations sur les capacités d’échanges des agents (restriction au
RDF) mises en évidence dans la section 2.5.1 ont été dépassées. La spécification d’un
nombre fini d’actions de bas niveaux a permis de résoudre le problème de la dualité des
langages que présentaient les autres approches vues dans l’état de l’art. L’unification de
la 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 de
l’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 et
comportement) d’un agent est en OWL-DL et SWRL exclusivement. L’unification de
la base de connaissances a été réalisé par l’unification des langages représentant les
différents composants initiaux, en alignant ces langages sur ceux de plus haut niveau, en
l’occurrence OWL-DL et SWRL. En ce sens les objectifs concernant l’architecture d’agent
ont été atteints. Les connaissances justifiables et empiriques coexistent au sein de la
base de la connaissance des agents et sont échangeables, les spécifications des chapitres
précédents ont ainsi été mises en œuvre.
Cette réalisation présente certaines limitations techniques. Les premières limitations
lors du développement du prototype sont venus du raisonneur dont le support des
fonction SWRL étaient alors (fin 2008) très limité. A l’époque certaines fonctions de
comparaison avaient été implémenté en bas niveau. Le choix d’utilisation de Pellet s’est
avé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 les
possibilités du prototype. La synchronisation de la file des messages a été réalisé de
manière simple par l’utilisation d’un mutex sur l’ensemble de la file. Il est possible de
ré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 de
la 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ème
pourra faire l’objet d’une implémentation dans une nouvelle version du prototype.
192
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, seul
l’é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 pour
chaque comportement.
Concernant la validation de code, les propriétés des OWLList en réduisent considérablement les possibilités. En effet, les implémentations de OWL-DL sont ici un
facteur 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 particulier
certaines fonctions de la gestion d’ontologies qui n’étaient pas nécessaires au développement de scénarios et de tests ont été écarté du développement pour des questions
de temps. Ce prototype se veut avant tout une preuve de concept, permettant de valider une approche, mais ne se veut en aucun cas comme un système fonctionnel de
développement d’agent sémantique.
6.6.1
Perspectives
Au dela des limitations technique d’implémentation, le prochain défi du prototype
est de simplifier la programmation de comportement. En effet la programmtion de
comportement sous forme SWRL est fastidieuse pour le programmeur d’agent. Le
principe de machines à états finis permet de transformer un graphique représentant le
programme directement en règles SAM. La génération automatique de code à partir de
graphiques est la prochaine grande étape du projet. Nous pensons nous orienter vers le
dé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 de
valider l’approche. Nous avons aussi pu mettre en œuvre l’ontologie des communautés
virtuelles de connaissances. Dans la continuité de nos travaux concernant l’efficacité
des communautés [Calmet06], il est maintenant intéressant de lancer de nouvelles
simulations 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 plus
large, de comparer les différents types de communautés et détecter des convergeances
dans 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 de
Amgoud sur la sélection d’arguments basée sur la justification [Amgoud10] font écho au
cadre théorique que nous avons défini. La réalisation du prototype SAM peut permettre
de mettre en œuvre ces travaux théoriques.
Une sortie, c’est une entrée que l’on prend dans l’autre sens
Boris Vian
7
Conclusion
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 des
objectifs proposés à l’issue de la présentation des scénarios motivants. La portée des
résultats principaux est résumée, les limites sont discutées et les directions pour des
travaux futurs sont suggérées.
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 des
connaissances. 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 VKC
donnée dans le premier chapitre, la base de connaissances des agents ne contient pas
seulement des ontologies, mais aussi trois autres composants (cognition, communication
et sécurité). Cependant, l’implémentation montre une différence de traitement entre
les différents composants. En effet les ontologies sont les seules parties de la base de
connaissances qui sont échangeables entre les agents. Les trois autres composants sont
programmés sont internes à l’agent et ne peuvent être échangés lors d’intéractions. Nous
avons étudié dans cette thèse comment ces composants peuvent être mis en œuvre de
manière à être échangéables entre les agents. L’échange de connaissances de nature à être
exécutées par l’agent introduit de nouveaux problèmes de justification ou de validation
de ces connaissances.
L’analyse de l’état de l’art a montré que l’utilisation des langages du web sémantique
permettait 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 rapprochement
entre 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 entre
processus de décision, comportement et connaissance semblait toute indiquée pour
remplir cette tâche. Cependant les tentatives infructueuses d’implémentation d’une telle
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éalisation d’une base de connaissances homogène permettant de décrire
à la fois les connaissances justifiables et empiriques. L’utilisation d’un raisonneur unique
pour l’inférence des connaissances, la justification des deux types de connaissance ainsi
que l’exécution des comportements est alors possible.
Un modèle d’agent sémantique respectant ces spécifications a été conçu. Les connaissances des deux types ont été représentés à l’aide du formalisme fourni par les standards
OWL 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 fonctions
requises en terme de communication et de gestion de la base de connaissances. Pour
compléter ces fonctions, nous avons spécifié un nombre fini d’actions qui est commun
196
à 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 des
actions (au niveau sémantique et opérationnel).
Ce modèle permettant d’échanger des connaissances exécutables, nous sommes
revenus au concept de VKC. Nous avons transformé l’utilisation des VKC en une
connaissance échangeable entre les agents. Pour ce faire, nous avons formalisé le concept
de VKC, tout d’abord par une formalisation à l’aide de l’outil mathématique commun
que représentent les ensembles et relations. Pour compléter le lien entre cette formalisation et les agents, nous avons défini une ontologie des commaunutés virtuelles de
connaissances qui est intégrable dans la base de connaissances des agents sémantiques.
Dans la description formelle des communautés virtuelles de connaissances, nous avons
introduit 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 formes
de règles interprétables par les agents SAM, afin de rendre opérationnelle l’utilisation
des communautés sous forme d’ontologie. Cette formalisation a aussi permet de rendre
compte 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 de
communauté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 publications
concernant nos travaux est donnée en annexe C.
7.1 Discussion
L’approche que nous proposons se base sur une consistance des connaissances. Une
connaissance non consistante avec celles d’un agent sera rejeté par ce dernier. D’autres
approches proposent des bases de connaissances dont la consistance est locale, ces
approche dites multi-contexte [Giunchiglia93] permettraient des raisonnements sur des
inconsistances en utilisant des logiques non monotones et des règles-pont (bridge rules
en anglais). Ces logiques non-monotones sont sous le feu des critiques des théoriciens
depuis leur introduction 1 [Girard07], et leurs fondations apparaissent pour le moins
instables. 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 inconsistantes avec celles des autres agents, pour autant la transmission de ces connaissances
entre deux agents est alors impossible, le récepteur ne pouvant accepter d’inconsistance
dans 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
Section 7.2. Perspectives
197
matiques importantes dans le domaine de la gestion des connaissances, notamment
dans le cadre d’organisation ou l’accés aux données doit être restreint selon la place dans
l’organisation. En effet lors de la transmission de connaissances empiriques, la connaissance transmise sous forme d’une séquence d’actions et d’une propriété est alors testée
par le récepteur. Un agent doté de mauvaises pourrait alors transmettre une séquence
d’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, notamment
en ce qui concerne les connaissances empiriques.
L’implémentation du prototype présente certaines limitations techniques. Pour des
raisons de simplicité, toutes les variables de l’interpréteur sont globales, seul l’é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 pour chaque comportement. Concernant la validation de code, les propriétés des OWLList en réduisent
considérablement les possibilités. En effet, les implémentations de OWL-DL sont ici un
facteur 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 particulier certaines fonctions de la
gestion d’ontologies qui n’étaient pas nécessaires au développement de scénarios et de
tests ont été écarté du développement pour des questions de temps. Ce prototype se veut
avant tout une preuve de concept, permettant de valider une approche, mais ne se veut
en 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 concept
qui démontre la faisabilité de notre approche. La difficulté de la programmation des
agents 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 pour
permettre au développeur de programmer visuellement les agents. Les actions étant en
nombre fini, il est très simple de proposer une interface visuelle pour le développement
rapide d’application utilisant des agents sémantiques. Une telle interface permettrait
de réduire le temps de développement et autoriserait le développement d’applications
mettant en œuvre un nombre plus large d’agents.
L’implémentation a permis de réaliser le transfert de connaissance empirique et de
valider l’approche. Nous avons aussi pu mettre en œuvre l’ontologie des communautés
virtuelles de connaissances. Dans la continuité de nos travaux concernant l’efficacité
des communautés [Calmet06], il est maintenant intéressant de lancer de nouvelles
simulations avec des agents qui disposent de la capacité d’échanges de protocoles des
198
communautés. Il est alors possible de lancer des expérimentations sur un cadre plus
large, de comparer les différents types de communautés et détecter des convergeances
dans 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 de
Amgoud sur la sélection d’arguments basée sur la justification [Amgoud10] font écho au
cadre théorique que nous avons défini. La réalisation du prototype SAM peut permettre
de mettre en œuvre ces travaux théoriques.
Les connaissances acquises et les concepts développés au cours de cette thèse nous
amène à revoir notre position sur la faisabilité d’une architecture BDI basée sur un
raisonneur sémantique. Si les travaux théoriques de Moreira [Moreira06] n’ont pas
abouti à une implémentation, nous avons une idée plus précise des problèmes qui ont
pu être rencontrés. Le problème de la révision des croyances requiert une intervention
externe 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’activation
des plans. Les raisonneurs sémantiques ne privilégient pas de règles en particulier et
toutes les règles sont potentiellement activables, la représentation des plans sous forme
de règles SWRL par exemple est alors impossible. Nous pensons qu’il est possible de
contourner cette difficulté par l’introduction d’un concept similaire aux états utilisés
dans les EFSM, permettant la sélection d’un plan. Le troisième point qui doit être développé est l’intéraction entre le raisonneur et l’exécution des actions. A la différence de
notre approche, nous pensons qu’il est nécessaire de développer une interface au sein du
raisonneur, qui permet l’exécution d’action lors de la classification de ressources correspondantes à des actions. Cette interface permet la révision des croyances (intervention
externe sur la base de connaissances) et l’exécution des actions.
A
Annexe : 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
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
201
202
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
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
203
204
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
@prefix
@prefix
@prefix
@prefix
@prefix
@prefix
@prefix
@prefix
@prefix
@prefix
[]
a
protege:
xsp:
sqwrl:
rdfs:
swrl:
default:
swrlb:
xsd:
owl:
rdf:
swrla:
<http://protege.stanford.edu/plugins/owl/protege#> .
<http://www.owl-ontologies.com/2005/08/07/xsp.owl#> .
<http://sqwrl.stanford.edu/ontologies/built-ins/3.4/sqwrl.owl#> .
<http://www.w3.org/2000/01/rdf-schema#> .
<http://www.w3.org/2003/11/swrl#> .
<http://liris.cnrs.fr/~jsuberca/vkcs.owl#> .
<http://www.w3.org/2003/11/swrlb#> .
<http://www.w3.org/2001/XMLSchema#> .
<http://www.w3.org/2002/07/owl#> .
<http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
<http://swrl.stanford.edu/ontologies/3.3/swrla.owl#> .
owl:AllDifferent .
default:AP
a
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:Community
a
owl:Class ;
rdfs:comment "Virtual Knowledge Community"^^xsd:string ;
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:LeaderAgent
a
owl:Class ;
rdfs:subClassOf default:Agent ;
owl:equivalentClass
[ a
owl:Restriction ;
owl:onProperty default:membershasroles ;
owl:someValuesFrom default:LeaderRole
] .
default:Topic
a
owl:Class ;
rdfs:comment "Topic of a community"^^xsd:string ;
default:Roles , default:Community , default:Agent , default:CommunityActions .
default:Protocols
a
owl:Class ;
206
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:hasProtocol
a
owl:ObjectProperty ;
rdfs:domain default:AP ;
rdfs:range default:Protocols .
default:hasAP
a
rdfs:domain default:Roles ;
rdfs:range default:AP .
default:Roles
a
owl:Class ;
rdfs:comment "Roles of agent in a given community"^^xsd:string ;
rdfs:subClassOf
[ a
owl:Restriction ;
owl:allValuesFrom default:AP ;
owl:onProperty default:hasAP
] ;
default:Community , default:Agent , default:Topic , default:CommunityActions .
default:membershasroles
a
rdfs:domain default:Agent ;
rdfs:range default:Roles .
default:Agent
a
owl:Class ;
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
] ;
Section A.2. Ontologie au format N3
207
default:Roles , default:Community , default:Topic , default:CommunityActions .
default:hasMember
a
rdfs:domain default:Community ;
rdfs:range default:Agent .
default:hasActions
a
rdfs:domain default:AP ;
rdfs:range default:CommunityActions .
default:LeaderRole
a
owl:Class ;
rdfs:subClassOf default:Roles .
default:CommunityActions
a
owl:Class ;
rdfs:comment "Actions that can be executed in the community"^^xsd:string ;
default:Roles , default:Community , default:Agent , default:Topic .
B
Annexe : 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 comportement
d’agents autonomes. Pour que ces agents soient capables d’intéragir entre eux, sans se
soucier du langage de programmation utilisé, il faut que ces agents soient dotés d’un
langage de communication commun. Deux langages de communication ACL pour Agent
Communication Language en anglais, ont été développé. Ces deux langages, KQML (pour
Knowledge Query and Manipulation Language) et FIPA-ACL sont tous deux basés
sur la théorie des actes de langages du philosophe américain John Searle. Dans ces
langages, 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 des
connaissances Knowledge Sharing Effort 2 . Initialement le KQML devait être un langage
d’échanges de connaissances, comme par exemple KIF (Knowledge Interchange Format)
[Genesereth92]. KQML a ensuite été proposé comme langages de communications
d’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 contenu
Un 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 est
maintenant délaissé au profit de son successeur, le FIPA-ACL.
1. http://www.cs.umbc.edu/KQML/kqmlspec.ps
2. http://ebiquity.umbc.edu/_file_directory_/papers/280.pdf
3. http://www-ksl.stanford.edu/knowledge-sharing/agents.html
212
B.1.0.2
Chapitre B. Annexe : Langages de communication agents
FIPA-ACL
La FIPA (Foundations for Intelligent Agents) 4 , initialement une association à but
non lucratif fondée qui est maintenant devenue un comité de standards de l’IEEE a
proposé de nombreux standards pour les agents et plus particulièrement un standard de
langages 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
performative
sender
receiver
reply-to
content
language
encoding
ontology
protocol
conversation-id
reply-with
in-reply-to
reply-by
Category of Parameters
Type of communicative acts
Participant in communication
Content of message
Description of Content
Control of conversation
TABLE B.1 – Paramètres des messages FIPA ACL
Les messages FIPA-ACL comportent nettement plus de champ et permettent l’élaboration de protocoles complexes entre agents, comme par exemple le CONTRACT-NET
[Smith80].
4. http://www.fipa.org
C
Annexe : Liste des publications
Liste de publications
[1] Julien Subercaze and Pierre Maret. Sam : Semantic agent model for swrl
rule-based agents. In INSTICC Press 2010, editor, ICAART 2010, Proceedings 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 - Foundations
and Applications, , chapter Programming Semantic Agent for Distributed
Knowledge Management. Springer Verlag, November 2010.
[3] Christo Elmorr and Julien Subercaze. Handbook of Research on Developments 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 DincaPanaitescu. Virtual knowledge network for human rights monitoring. In
Workshop on Web Intelligence and Virtual Enterprises (WIVE09), 10th
IFIP Working Conference on Virtual Entreprises (PRO-VE09), October
2009.
[5] Julien Subercaze, Christo El Morr, Pierre Maret, Adrien Joly, Matti
Koivisto, Panayotis Antoniadis, and Masayuki Ihara. Towards successful
virtual communities. In International Conference on Enterprise Information 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 virtual knowledge community for human rights monitoring for people with disabilities. In Piet Kommers, editor, IADIS International Conference WBC
2008, pages 78–84, July 2008.
[7] Pierre Maret, Julien Subercaze, and Jacques Calmet. Peer to peer model
for virtual knowledge communities. In AIKED’08, pages 365–370, March
2008.
[8] Pravin Pawar, Julien Subercaze, Pierre Maret, Bert-Jan van Beijnum, and
Dimitri Konstantas. Towards business model and technical platform for
the service oriented context-aware mobile virtual communities. In IEEE
Symposium on Computers and Communications ISCC, pages 103–110, .
IEEE Computer Society Press, July 2008.
[9] Julien Subercaze, Pravin Pawar, Pierre Maret, and Jacques Calmet. A
service oriented framework for mobile business virtual communities. In
Willy Picard Luis M. Camarinha-Matos, editor, Virtual Enterprises and
Collaborative 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 Engineering), editors, BodyNets ’07: Proceedings of the ICST 2nd international
conference on Body area networks, pages 1–5, July 2007.
[11] Jacques Calmet, Julien Subercaze, and Pierre Maret. Simulation in virtual
knowledge communities. In Angel Oropeza Freddy Mapica, editor, Social
and 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 Systems : Emerging Views and Practices from the Field. Hawaii International Conference on System Sciences, vol. 7, page 7009, IEEE
Computer Society, Los Alamitos, CA, USA, 1999. 68
[Amgoud10]
Leila Amgoud & Srdjan Vesic. Handling Inconsistency with
Preference-Based Argumentation. In Amol Deshpande & Anthony
Hunter, editeurs, SUM, volume 6379 of Lecture Notes in Computer
Science, pages 56–69. Springer, 2010. 192, 198
[Ancona04a]
D. Ancona & V. Mascardi. Coo-BDI : Extending the BDI model
with 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. CooAgentSpeak : Cooperation in AgentSpeak through plan exchange. In
Proceedings of the Third International Joint Conference on Autonomous Agents and Multiagent Systems-Volume 2, page 705.
IEEE Computer Society, 2004. 94, 132
[Anicic07]
N. Anicic, N. Ivezic & A. Jones. An architecture for semantic
enterprise application integration standards. Interoperability of Enterprise Software and Applications, pages 25–34, Springer, 2007.
79
[Bachimont96]
M.B. Bachimont. Hermeneutique ma erielle et Artefacture : des machines qui pensent aux machines qui donnent a penser. Doctorat,
Ecole polytechnique - Service d’Informatique Médicale de l’Assistance Publique, 1996. 64
[Balmisse02]
G. Balmisse. Gestion des connaissances(outils et applications du
knowledge management). Entreprendre. Informatique, Vuibert,
2002. 65
[Barclay97]
R.O. Barclay & P.C. Murray. What is knowledge management. Knowledge Praxis, vol. 19, 1997. 18
218
BIBLIOGRAPHIE
[Bellifemine99]
F. Bellifemine, A. Poggi & G. Rimassa. JADE–A FIPA-compliant
agent framework. In Proceedings of PAAM, volume 99, pages
97–108. Citeseer, 1999. 29, 35, 108
[Berners-Lee00]
T. Berners-Lee & D. Connolly. CWM-closed world machine. Internet : http ://www. w3. org/2000/10/swap/doc/cwm. html,
2000. 103
[Biegel04]
Gregory Biegel & Vinny Cahill. A Framework for Developing Mobile, Context-aware Applications. percom, vol. 00, page 361, IEEE
Computer Society, Los Alamitos, CA, USA, 2004. 32
[Boissier01]
O. Boissier. Modèles et architectures d’agents. Principes et architectures des systèmes multi-agents, pages 71–107, 2001. 85
[Boley01]
Harold Boley, Said Tabet & Gerd Wagner. Design Rationale for
RuleML : 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 knowledge management : Managerial and technological implications. Novatica and Informatik/Informatique, page 23, Citeseer, 2002. 11,
69, 70
[Bonifacio02b]
M. Bonifacio, R. Cuel, G. Mameli & M. Nori. A peer-to-peer architecture for distributed knowledge management. In Proceedings
of the 3rd International Symposium on Multi-Agent Systems,
Large Complex Systems, and E-Businesses (MALCEB’02). Citeseer, 2002. 69
[Bonifacio02c]
Matteo Bonifacio, Paolo Bouquet & Roberta Cuel. Knowledge
Nodes : 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 & Michele
Nori. Peer-Mediated Distributed Knowledge Management. In van
Elst 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-oriented
programming. 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, pages
304–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 Multiagent System for Virtual Communities Support. In AOIS, pages
212–230, 2006. 113
[Buhler03]
P. Buhler & J.M. Vidal. Semantic web services as agent behaviors.
Agentcities : Challenges in Open Agent Environments, pages
25–31, Springer-Verlag, 2003. 107
[Calmet04]
Jacques Calmet, Pierre Maret & Regine Endsuleit. Agent-oriented
abstraction. Academia de Ciencias, Serie "A" de Matemeticas,
vol. 98, December 2004. 23, 25, 26, 112
[Calmet06]
Jacques Calmet, Julien Subercaze & Pierre Maret. Simulation
in Virtual Communities. In Proceeding of the Social and Organizational 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 based
Intelligent Tutoring System for distance learning. In Proceedings of
the International Workshop in Adaptative and Intelligent Webbased 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 an
Information System Application - Emergency Medical Services. In
Paolo Bresciani, Paolo Giorgini, Brian Henderson-Sellers, Graham Low & Michael Winikoff, editeurs, AOIS, volume 3508 of
Lecture Notes in Computer Science, pages 36–51. Springer, 2004.
113
[Cheng93]
K.T. Cheng & AS Krishnakumar. Automatic functional test generation using the extended finite state machine model. In Proceedings of
the 30th international conference on Design automation, pages
86–91. ACM New York, NY, USA, 1993. 125
[Clark01]
K. Clark, P.J. Robinson & R. Hagen. Multi-threading and message
communication in Qu-Prolog. Theory and Practice of Logic Programming, vol. 1, no. 03, pages 283–301, Cambridge Univ Press,
2001. 107
[Cobo07]
P. Cobo, J.M. Fortuny, E. Puertas & P.R. Richard. AgentGeom : a
multiagent 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 w3c
resource description framework. Lecture notes in computer science,
pages 468–482, Springer, 2000. 118
[Corby04]
O. Corby, R. Dieng-Kuntz & C. Faron-Zucker. Querying the semantic web with corese search engine. In ECAI, volume 16, page
705, 2004. 114
[Costantini92]
S. Costantini, P. Dell’Acqua & G. Lanzarone. Reflective agents in
metalogic programming. Lecture notes in computer science, pages
135–135, Springer, 1992. 93
[Damasio06]
C.V. Damasio, A. Analyti, G. Antoniou & G. Wagner. Supporting open and closed world reasoning on the web. Lecture notes in
computer science, vol. 4187, page 149, Springer, 2006. 19
[Davenport99]
T.H. Davenport, D.W. De Long & M.C. Beers. Successful knowledge
management projects. The Knowledge Management Yearbook
1999-2000, pages 89–107, Butterworth-Heinemann, 1999. 51
[Davenport00]
T.H. Davenport & L. Prusak. Working knowledge : How organizations manage what they know. Ubiquity, vol. 1, no. 24, ACM New
York, NY, USA, 2000. 64, 65
[Decker98]
Stefan Decker, Michael Erdmann, Dieter Fensel & Rudi Studer. Ontobroker : Ontology based Access to Distributed and SemiStructured Information. pages 351–369, Kluwer Academic Publisher, 1998. 75
[Dickinson03]
I. Dickinson & M. Wooldridge. Towards practical reasoning agents
for the semantic web. In Proceedings of the second international
joint 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 developing semantic web based multi agent systems. In Proceedings of
the fourth international joint conference on Autonomous agents
and 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 for
sequences in OWL. In Proc. 2nd Workshop on OWL : Experiences
and Directions. Citeseer, 2006. 143, 178, 182, 192, 197
BIBLIOGRAPHIE
221
[Ehrig03]
Marc Ehrig, Christoph Tempich, Jeen Broekstra, Frank van Harmelen, Marta Sabou, Ronny Siebes, Steffen Staab & Heiner Stuckenschmidt. SWAP : Ontology-based Knowledge Management with
Peer-to-Peer Technology. In Wissensmanagement, pages 17–20,
2003. 19, 68, 69, 120
[El Morr07]
C. El Morr & J. Kawash. Mobile virtual communities research : a
synthesis of current trends and a look at future perspectives. International Journal of Web Based Communities, vol. 3, no. 4, pages
386–403, Inderscience, 2007. 49
[El Morr09]
Christo El Morr, Julien Subercaze, Marcia Rioux & Mihaela
Dinca-Panaitescu. Virtual Knowledge Network for Human Rights
Monitoring. In Workshop on Web Intelligence and Virtual Enterprises (WIVE’09), 10th IFIP Working Conference on Virtual
Entreprises (PRO-VE’09), October 2009. 23, 48
[ElMorr07]
Christo ElMorr & Jalal Kawash. Mobile virtual communities research&#58 ; a synthesis of current trends and a look at future perspectives. Int. J. Web Based Communities, vol. 3, no. 4, pages 386–403,
Inderscience Publishers, Inderscience Publishers, Geneva, SWITZERLAND, 2007. 39
[Elmorr08]
Christo Elmorr, Julien Subercaze, Pierre Maret & Marcia Rioux.
A Virtual Knowledge Community for Human Rights Monitoring for
People with Disabilities. In Piet Kommers, editeur, IADIS International Conference WBC 2008, pages 78–84, July 2008. 23, 48
[Farooq02]
U. Farooq, PL Isenhour, J.M. Carroll & M.B. Rosson. MOOsburg++ : Moving towards a wireless virtual community. In Proceedings of the 2002 International Conference on Wireless Networks,
2002. 40
[Ferber89]
J. Ferber. Objets et agents : une étude des structures de représentation
et de communications en Intelligence Artificielle. Th ese d’informatique, Universit e Pierre et Marie Curie, Paris, vol. 6, 1989.
18
[Finin94]
T. Finin, R. Fritzson, D. McKay & R. McEntire. KQML as an agent
communication language. In Proceedings of the third international
conference on Information and knowledge management, page
463. ACM, 1994. 83, 131, 211
[FIPA02]
TC FIPA. Architecture Group, FIPA Abstract Architecture Specification. Rapport technique, Tech. Rep. XC00001K, Foundation for
Intelligent Physical Agents, Geneva, Switzerland, 2002. 107
222
BIBLIOGRAPHIE
[Fox00]
M.S. Fox, M. Barbuceanu & R. Teigen. Agent-oriented supply-chain
management. International Journal of Flexible Manufacturing
Systems, 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 Knowledge
Management : ontologies and multi-agent systems for a corporate
semantic web. Doctorat, INRIA and University of Nice - Sophia
Antipolis, 2002. 11, 113
[Ganek03]
A.G. Ganek & T.A. Corbi. The dawning of the autonomic computing
era. IBM Systems Journal, vol. 42, no. 1, pages 5–18, IBM Corp.,
2003. 88
[Gellersen02]
Hans W. Gellersen, Albercht Schmidt & Michael Beigl. Multisensor context-awareness in mobile devices and smart artifacts. Mob.
Netw. Appl., vol. 7, no. 5, pages 341–351, Kluwer Academic
Publishers, 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 embedded
reasoning system. In Proceedings of the Eleventh International
Joint 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 la
perfection. Hermann, Paris, 280p, 2007. 72, 196
[Giunchiglia93]
E. Giunchiglia, P. Traverso & F. Giunchiglia. Multi-context systems
as a specification framework for complex reasoning systems. J. Treur,
Th. Wetter (eds.), Formal specification of complex reasoning
systems, 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 specifications. Knowledge acquisition, vol. 5, pages 199–199, Academic
Press, 1993. 72
[Haarslev07]
V. Haarslev, R. M
"oller & M. Wessel. RacerPro User’s Guide and Reference Manual
Version 1.9. 1, 2007. 79
BIBLIOGRAPHIE
[Haase05]
223
Peter Haase, Björn Schnizler, Jeen Broekstra, Marc Ehrig, Frank
van Harmelen, Maarten Menken, Peter Mika, Michal Plechawski,
Pawel Pyszlakand Ronny Siebes, Steffen Staab & Christoph Tempich. 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 for
expressive description logics. OWL : Experiences and Directions,
vol. 2006, Citeseer, 2006. 198
[Heflin00]
J. Heflin & J. Hendler. Searching the Web with SHOE. In AAAI2000 Workshop on AI for Web Search, pages 35–40, 2000. 73
[Henricksen04]
Karen Henricksen & Jadwiga Indulska. A Software Engineering
Framework 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 and
composition of services for context-aware systems. Smart Sensing
and Context, pages 67–81, Springer, 2006. 45
[Hey04]
J. Hey. The data, information, knowledge, wisdom chain : The metaphorical link. Relatório técnico, Intergovernmental Oceanographic
Commission (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 MultiAgent Systems, vol. 2, no. 4, pages 357–401, Springer, 1999. 11,
102
[Horn01]
P. Horn. Autonomic computing : IBM’s perspective on the state of
information technology. IBM TJ Watson Labs, NY, 15th October,
2001. 88
[Horrocks03]
I. Horrocks, P.F. Patel-Schneider & F. Van Harmelen. From SHIQ
and RDF to OWL : The making of a web ontology language. Web
semantics : 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 OWL
and RuleML. W3C Member Submission, vol. 21, 2004. 79, 141
[Hustadt94]
U. Hustadt. Do we need the closed world assumption in knowledge
representation. 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 mapping and management, page 281, Irm Pr, 2002. 49
[Jennings98]
N.R. Jennings, K. Sycara & M. Wooldridge. A roadmap of agent
research and development. Autonomous agents and multi-agent
systems, 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. 2nd
IEEE International Conference on Semantic Computing, pages
504–511, 2008. 11, 103, 104
[Kawash05]
J. Kawash, C. El Morr, W. Charaf & H. Taha. Building Mobile
Virtual Communities for Public Transport Awarness. In 2005 2nd
International Conference on Mobile Technology, Applications
and 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 approach combining agent and semantic web technologies. Declarative
Agent Languages and Technologies VI, pages 91–110, Springer,
2009. 11, 99, 100
[Klyne04]
G. Klyne, J.J. Carroll & B. McBride. Resource description framework (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 for
Agents in Discrete Environments. In ECAI, pages 727–728, 2006.
109, 178
[Laclavik06b]
Michal Laclavik, Zoltan Balogh, Marian Babik & Ladislav Hluchý. 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 applications
of the web ontology language-OWL. In Proceedings of the 36th
conference on Winter simulation, page 270. Winter Simulation
Conference, 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 First
OWL Experiences and Directions Workshop, volume 188, 2005.
79
BIBLIOGRAPHIE
225
[Leimeister04]
J.M. Leimeister & H. Krcmar. Revisiting the virtual community
business model. In Proceedings of the Tenth Americas Conference
on Information Systems. Citeseer, 2004. 39, 43
[Loke98]
S.W. Loke & A. Davison. LogicWeb : Enhancing the web with logic
programming. The Journal of Logic Programming, vol. 36, no. 3,
pages 195–240, Elsevier, 1998. 75
[Ma08]
Zongmin Ma & Huaiqing Wang. The semantic web for knowledge and data management : Technologies and practices. Information Science Reference - Imprint of : IGI Publishing, Hershey,
PA, 2008. 80
[Machado99]
I. Machado, A. Martins & A. Paiva. One for all and all in one : a
learner modelling server in a multi-agent platform. In Proceedings
of the seventh international conference on User modeling table
of contents, pages 211–221. Springer-Verlag New York, Inc. Secaucus, NJ, USA, 1999. 118
[Maret04a]
Pierre Maret & Jacques Calmet. Modeling Corporate Knowledge
within the Agent Oriented Abstraction. In CW, pages 224–231. IEEE
Computer Society, 2004. 23, 25
[Maret04b]
Pierre Maret, Mark Hammond & Jacques Calmet. Virtual Knowledge Communities for Corporate Knowledge Issues. In Marie Pierre
Gleizes, 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 enterprise - organisation, evolution and control. International Journal
of Production Economics, vol. 74, no. 1-3, pages 225 – 238, 2001.
117
[Mascardi05]
Viviana Mascardi, Daniela Demergasso & Davide Ancona. Languages for Programming BDI-style Agents : an Overview, 2005. 92
[Merali01]
Y. Merali & J. Davies. Knowledge capture and utilization in virtual
communities. In Proceedings of the 1st international conference
on 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. In
In 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-Based
Systems, 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 with
heterogeneous knowledge representations. In Sixth International
Workshop on Programming Multi-Agent Systems. Springer, 2008.
106
[Novak08b]
P. Novak, D. Mainzer, M. Koster & B. Fuhrmann. Jazzbot : A nonmonotonically 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 with
agents in web service e-learning systems. In IFIP Symposium on
Professional Practice in AI, IFIP WG12, volume 5, 2004. 118
[Parsia05]
B. Parsia, E. Sirin, B.C. Grau, E. Ruckhaus & D. Hewlett. Cautiously 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, Jianhua
Shao, W. Alex Gray, N. J. Fiddian & Simon Thompson. CONOISEG : agent-based virtual organisations. In Hideyuki Nakashima,
Michael P. Wellman, Gerhard Weiss & Peter Stone, editeurs, AAMAS, pages 1459–1460. ACM, 2006. 116, 117
[Pawar07]
P. Pawar, S. Srirama, B.J. van Beijnum & A. van Halteren. A Comparative Study of Nomadic Mobile Service Provisioning Approaches.
BIBLIOGRAPHIE
227
In The 2007 International Conference on Next Generation Mobile Applications, Services and Technologies, 2007. NGMAST’07,
pages 277–286, 2007. 46
[Pawar08]
Pravin Pawar, Julien Subercaze, Pierre Maret, Bert-Jan van Beijnum & Dimitri Konstantas. Towards Business Model and Technical Platform for the Service Oriented Context-Aware Mobile Virtual
Communities. In IEEE Symposium on Computers and Communications ISCC, pages 103–110. IEEE Computer Society Press, July
2008. 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. Corporate memory management through agents. E-business : Key Issues,
Applications and Technologies, pages 360–366, 2000. 113
[Pinyapong04]
Sineenard Pinyapong & Toshikazu Kato. Query Processing Algorithms for Time, Place, Purpose and Personal Profile Sensitive Mobile
Recommendation. In CW ’04 : Proceedings of the 2004 International Conference on Cyberworlds (CW’04), pages 423–430, Washington, 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 reasoning
engine. Multiagent Systems Artificial Societies and Simulated
Organizations, vol. 15, page 149, Springer, 2005. 109
[Preece00]
Jenny Preece. Online communities - designing usability, supporting 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. In
Proceedings of the first international conference on multi-agent
systems (ICMAS-95), pages 312–319. San Francisco, 1995. 92
[Rao96]
A.S. Rao. AgentSpeak (L) : BDI agents speak out in a logical computable language. Lecture Notes in Computer Science, vol. 1038,
pages 42–55, Springer, 1996. 97
[Ritter95]
S. Ritter & KR Koedinger. Towards lightweight tutoring agents. In
AI-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 Computing
in Education, USA, 1996. 118
228
BIBLIOGRAPHIE
[Ritter97]
S. Ritter. Communication, cooperation and competition among multiple tutor agents. In Artificial Intelligence in Education, Proceedings of AI-ED, volume 97, pages 31–38, 1997. 118
[Rothaermel01]
F.T. Rothaermel & S. Sugiyama. Virtual internet communities and
commercial success : Individual and community-level theory grounded
in 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 DIKW
hierarchy. Journal of Information Science, vol. 33, no. 2, pages
163–180, Sage Publications, Inc., 2007. 65
[Salber98]
D. Salber & G. Abowd.
The Design and Use of a Generic Context Server.
Rapport technique, 1998.
Also
available 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 humancomputer interface. Proceedings of the IEEE, vol. 86, no. 5, pages
853–869, 1998. 33
[Shi02]
H. Shi, S. Revithis & S.S. Chen. An agent enabling personalized
learning in e-learning environments. In Proceedings of the first
international joint conference on Autonomous agents and multiagent 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 Artificial
Intelligence, volume 2, pages 704–709, 1991. 11, 12, 97, 145
[Shoham95]
Y. Shoham & M. Tennenholtz. On social laws for artificial agent
societies : 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ôle
des données, informations et connaissances dans la construction de
scénarios médicaux. Revue d’intelligence artificielle, vol. 17, no. 13, 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, Services
and Agents on the World Wide Web, vol. 5, no. 2, pages 51–53,
Elsevier, 2007. 78
BIBLIOGRAPHIE
229
[Smith80]
RG Smith. The contract net protocol : High-level communication
and control in a distributed problem solver. IEEE Transactions on
computers, vol. 100, no. 29, pages 1104–1113, 1980. 212
[Stankovsky05]
M. Stankovsky. Creating the discipline of knowledge management. Butterworth-Heineman, 2005. 67
[Stein05]
A. Stein, P. Hawking & P. Sharma. A classification of U-commerce
location based tourism applications. In AUSWeb05, The Eleventh
Australasian World Wide Web Conference, pages 2–6, 2005. 49
[Strugeon08]
Emmanuelle Grislin-Le Strugeon, Abdouroihamane Anli & Emmanuel Adam. Agent-oriented information systems iv, chapitre
A Methodology to Bring MAS to Information Systems, pages
90–104. 2008. 112
[Subercaze07]
Julien Subercaze, Pierre Maret, Ngoc Minh Dang & Ken Sasaki. Context-aware applications using personal sensors. In SocialInformatics ICST (Institute for Computer Sciences & Telecommunications Engineering), editeurs, BodyNets ’07 : Proceedings of
the 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 Communities . In Willy Picard Luis M. Camarinha-Matos, editeur, Virtual
Enterprises and Collaborative Networks, pages 493–500. Springer, September 2008. 23, 24, 39
[Subercaze09]
Julien Subercaze, Christo El Morr, Pierre Maret, Adrien Joly,
Matti Koivisto, Panayotis Antoniadis & Masayuki Ihara. Towards
Successful Virtual Communities. In International Conference on
Enterprise 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 wireless 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 supply
chain 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 constructionist approach. Strategic management journal, pages 11–25, John
Wiley and Sons, 1996. 68
[van Diggelen05]
Jurriaan van Diggelen, Virginia Dignum, Ludger van Elst &
Andreas Abecker, editeurs. Proceedings of the aamas 2005 workshop on agent-mediated knowledge management (amkm-2005),
2005. 70
[van Elst04a]
Ludger van Elst, Virginia Dignum & Andreas Abecker, editeurs.
Agent mediated knowledge management, international symposium amkm 2003, stanford, ca, usa, march 24-26, 2003, revised
and invited papers, volume 2926 of Lecture Notes in Computer
Science. Springer, 2004. 19, 218
[van Elst04b]
Ludger van Elst, Virginia Dignum & Andreas Abecker, editeurs.
Agent mediated knowledge management, international symposium amkm 2003, stanford, ca, usa, march 24-26, 2003, revised
and invited papers, volume 2926 of Lecture Notes in Computer
Science. Springer, 2004. 70
[Vassileva99]
J. Vassileva, J. Greer, G. McCalla, R. Deters, D. Zapata, C. Mudgal & S. Grant. A multi-agent approach to the design of peer-help
environments. In Proceedings of AIED, volume 99, pages 38–45,
1999. 118
[Vilmer05]
J.B.J. Vilmer. Réalité, Vérité et Connaissance. Une alternative à la
traditionnelle «Justified True Belief», inspirée de la «Wirklichkeit» du
Manuscrit de 1942 de W. Heisen. 2005. 63
[Virginia Dignum04]
Andreas Abecker Virginia Dignum Ludger van Elst, editeur. Proceedings of the ecai-2004 workshop on agent-mediated knowledge management (amkm-2004, 2004. 70
[Wac06]
K. Wac, A. van Halteren & D. Konstantas. QoS-Predictions Service :
Infrastructural Support for Proactive QoS-and Context-Aware Mobile
Services (Position Paper). In On the Move to Meaningful Internet
Systems 2006 : OTM 2006 Workshops, pages 1924–1933. Springer,
2006. 41
[Wang05]
Y.H. Wang, W.N. Wang & Y.H. Yen. An intelligent semantic agent
for e-learning message communication. In Advanced Information
Networking and Applications, 2005. AINA 2005. 19th International 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 Wrong
with OWL Benchmarks ? In Proceedings of the Second International Workshop on Scalable Semantic Web Knowledge Base
Systems (SSWS 2006), pages 101–114, 2006. 83
[Widyantoro01]
D.H. Widyantoro, T.R. Ioerger & J. Yen. Learning user interest
dynamics with a three-descriptor representation. Journal of the American 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 rooted
in a long history. Knowledge Horizons, Butterworth-Heinemann,
Boston, MA, pages 3–26, 2000. 67
[Wilson02]
T.D. Wilson. The nonsense of knowledge management. Information
Research, vol. 8, no. 1, pages 8–1, Tom Wilson/Lund University
Libraries, 2002. 66
[Wooldridge95]
M. Wooldridge & N.R. Jennings. Intelligent agents : Theory and
practice. Knowledge engineering review, vol. 10, no. 2, pages
115–152, Cambridge [England] ; New York, NY : Cambridge
University 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. Organizational
abstractions for the analysis and design of multi-agent systems. Lecture 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 retrieval
of digital documents. Lecture notes in computer science, pages
226–234, Springer, 1999. 75

Un modèle d`agent sémantique. Application aux communautés

Transcription

Documents pareils

Saluons le solstice d`hiver au mont Owl`s Head Lundi 21 décembre

Envoyer gratuitement des cartes virtuelles

Barn Owl

Moon Flower

Les oiseaux de chez nous

savero ht2 456 - GT Radial USA

"Jade et les sacrés mystères de la Vie"

Annotation et recherche multi-facettes guidées par une