Distribution de la base de connaissances de Leopar++

La base de connaissances nouvellement form´ee renferme les donn´ees f´ed´er´ees de diff´erentes sources de donn´ees. Le rˆole final de celle-ci est d’ˆetre exploit´ee par les agents du syst`eme Leo- par++. Toutefois, la base de connaissances de OWL n’est pas directement utilisable par les agents. Une analyse d´etaill´ee de OWL rel`eve les limites majeures suivantes empˆechant l’uti- lisation de la base par des agents :

– Les agents sont appel´es `a interagir avec la base de connaissances OWL. Le nombre d’agents pouvant ˆetre ´elev´e, l’acc`es multiple `a la base de connaissances pose probl`eme et aboutit in´evitablement `a la cr´eation de goulots d’´etranglement.

– Les agents pouvant s’ex´ecuter en parall`ele, il devient n´ecessaire de disposer d’un m´e- canisme d’acc`es concurrentiel aux donn´ees. Permettre `a des agents d’acc´eder `a des donn´ees ´evitant l’inter-blocage est vital.

– Les agents de notre syst`eme peuvent ˆetre distribu´es sur diff´erentes machines. Il devient important de disposer de base de connaissances distribu´ee tout en ´evitant la duplication inutile des donn´ees.

Pour ce faire, nous avons d´ecid´e de convertir automatiquement une ontologie en Objets Java d´eploy´es sous l’environnement JavaSpaces. La g´en´eration de code Java `a partir d’onto- logie n’est pas nouvelle et il existe des outils qui permettent de convertir automatiquement des ontologies. Le tableau suivant 4.3 reprend ces outils et en r´esume les caract´eristiques :

Tableau 4.3 Comparaison d’outils de conversion de bases de connaissances en objets Java

Outils Environnement Remarque

OntoJava Prot´eg´e G´en`ere des objets Java `a partir d’ontologie et de r`egle RuleML.

Bean Generator Prot´eg´e Permet de g´en´erer des objets compatibles sous le format de JavaBeans `a partir d’une ontologie.

Ontology Creator Prot´eg´e G´en`ere des classes Java `a partir d’une ontolo- gie.

Jastor Java G´en`ere des classes `a partir d’une ontologie. Les instances ne sont pas prises en compte.

La majorit´e de ces outils sont destin´es `a ˆetre utilis´es avec l’environnement Prot´eg´e et ne sont pas autonomes. L’outil Jastor est le seul `a pouvoir s’ex´ecuter de mani`ere autonome. Cependant il souffre de deux limitations :

– L’outil Jastor ne traduit pas des instances de la ABox,

– Le code objet g´en´er´e n’est pas personnalisable en ce qui concerne les types, les m´e- thodes, les variables globales et les contraintes.

Pour cette raison nous avons d´evelopp´e notre propre API pour traduire `a la fois les concepts et les instances de l’ontologie. Nous nous appuyons sur les m´ethodes propos´ees

Figure 4.7 Architecture du JavaSpace

en (voir Kalyanpur et al., 2004) pour la traduction d’une ontologie en objets Java. Notre traduction est plus simple que celle propos´ee dans Jastor car notre conversion ne tient pas compte des contraintes logiques des propri´et´es. Les objets Java g´en´er´es vont uniquement servir comme support pour stoker les donn´ees. `A titre d’information nous exposons dans la figure 4.8 la conversion de certains concepts.

Pour rendre accessible les objets Java nouvellement form´es `a partir de la base de connais- sances, nous utilisons une technologie particuli`ere qui se nomme JavaSpaces (voir Mamoud, 2005). C’est une impl´ementation de haut niveau pour le partage de donn´ees afin de les rendre accessibles `a des programmes distribu´es. L’approche JavaSpaces a pour but de faciliter le par- tage de donn´ees entre applications r´esidant dans des environnements h´et´erog`enes. En effet, JavaSpaces utilise un protocole d’acc`es aux donn´ees sp´ecifique afin d’´eviter les inter-blocages et pr´eserve la consistance des donn´ees. Cette technologie permet de sauvegarder des donn´ees dans un espace commun accessible par des applications `a distance. La figure 4.7 expose l’ar- chitecture d’une zone JavaSpaces repr´esentant des applications Java acc´edant `a des donn´ees sauvegard´ees dans JavaSpaces.

Le m´ecanisme JavaSpace tire ses origines d’un langage de coordination LINDA (voir Bjornson et al., 1997) et pr´esente l’avantage de :

– Offrir une plateforme qui simplifie la conception et l’impl´ementation de syst`emes dis- tribu´es.

– Permettre aux agents d’acc´eder `a une zone commune de donn´ees distribu´ees pour en- registrer des donn´ees ou pour communiquer.

– Pr´eserver la consistance des donn´ees lors de l’acc`es concurrent aux donn´ees grˆace `a un langage sp´ecifique nomm´e LINDA.

Le langage LINDA est destin´e `a la programmation parall`ele et introduit des op´erations de synchronisation dans un espace de donn´ees. Le mod`ele LINDA est bˆati sur les concepts de tuples qui sont une structure de donn´ees renfermant un identifiant unique et des donn´ees ty- p´ees. Les tuples repr´esentent des objets Java et forment un espace de tuples. La manipulation des tuples dans l’espace de tuples se fait par l’une des instructions suivantes en conformit´e avec le langage LINDA :

– Write() : permet d’introduire un nouvel objet Java dans l’espace de tuples. – Take() : permet d’extraire des objets de l’espace.

– Read() : permet de lire le contenu de l’objet.

– Notify() : permet de surveiller l’espace de tuples afin de d´etecter une donn´ee particuli`ere.

Grˆace `a ces instructions, il est possible de sauvegarder des donn´ees distribu´ees dans des espaces de tuples. Ces donn´ees sont passives et les agents ne sont pas en mesure de modifier l’objet directement dans la zone d’espace qu’apr`es avoir retir´e et ins´er´e de nouveau l’objet.

Les espaces de tuples permettent `a plusieurs agents Java d’acc´eder simultan´ement `a un ou plusieurs espaces de tuples et ce de mani`ere transparente `a l’agent. Cette caract´eristique permet de cr´eer une zone commune de partage de donn´ees distribu´ees qui permet de garantir le transfert, la persistance, la communication et la synchronisation entre agents.

Pour conclure, nous avons ´et´e en mesure de combiner et d’optimiser des technologies diff´erentes afin de d´evelopper une base de connaissances ´electrique. Nous apportons la preuve qu’il est possible d’extraire, de fusionner, de v´erifier et de rendre accessible des connaissances ´

electriques volumineuses `a des fin de traitement. Ce pr´esent chapitre d´ecrit une approche nouvelle pour cr´eer une base de connaissances ´electriques et la rendre disponible aux syst`emes de simulation.