Vous êtes sur la page 1sur 113

‫ﺍﳉﻤﻬﻮﺭﻳــــﺔ ﺍﳉﺰﺍﺋﺮﻳــﺔ ﺍﻟﺪﳝﻘﺮﺍﻃﻴـــﺔ ﺍﻟﺸﻌﺒﻴـــﺔ‬

‫ﻭﺯﺍﺭﺓ ﺍﻟﺘﻌﻠﻴﻢ ﺍﻟﻌﺎﱄ ﻭ ﺍﻟﺒﺤﺚ ﺍﻟﻌﻠﻤﻲ‬


*‫ * ﺳﻜﻴﻜﺪﺓ‬1955 ‫ ﺃﻭﺕ‬20 ‫ﺟﺎﻣﻌﺔ‬

FACULTE : SCIENCE DE L’INGENIEUR


DEPARTEMENT : INFORMATIQUE

CONSTRUCTION D’UNE ONTOLOGIE A PARTIR DE BASES DE


DONNEES POUR L’AIDE A LA MAINTENANCE INDUSTRIELLE
APPLICATION : TURBINE A VAPEUR

MEMOIRE
Pour l’obtention du Diplôme
Magister
(Ecole Doctorale STIC)

(Spécialité Informatique)

Présenté Par

Mme KLAI SIHEM


Epouse Soukehal

Encadrée Par

Dr. KHADIR Med TAREK

Année Universitaire 2008/2009


Résumé

Les données concernant le système industriel “Turbine à Vapeur” étudié sont stockées dans
des bases de données qui diffèrent dans leur contexte d’utilisation. L’un concerne les
caractéristiques des équipements et l’autre concerne les interventions de maintenance de ces
équipements définissant les défauts, symptômes, causes et remèdes pour chaque cas. Ces
bases de données représentent le seul moyen d’accès à l’information ce qui pose des
problèmes d’intégration et d’échange de données. En tant que modèle permettant
d’exprimer la sémantique des données, les ontologies constituent une solution pertinente à
ces problèmes. La maintenance industrielle est complexe et les raisonneurs spécifiques à
OWL ne répondent pas à des cas particuliers notamment pour une aide au diagnostic. Un
système Expert est intégré à l’ontologie pour raisonner sur les instances afin de générer de
nouvelles connaissances ou pour une recherche intelligemment guidée par l’ontologie.
Notre approche consiste d’une part à capitaliser toutes les connaissances relatives au
système industriel « Turbine à vapeur » en intégrant les bases de données en une seule
ontologie, créer des relations entre les classes, les instances issues des différentes sources de
données pour enrichir la sémantique des données et permettre l’échange entre elles. Et
d’autre part exploiter l’ontologie via une interface permettant un accès aux connaissances
d’une manière transparente à l’utilisateur, une autre interface a été développé pour doter la
base de données des informations importées à partir de l’ontologie. Une table dont la
structure est composée d’un ensemble d’attributs du premier système et un ensemble
d’attributs du deuxième système a été généré de l’ontologie pour qu’elle soit crée dans une
des bases de données source. La mise à jour de la base de données à partir du programme
JAVA a été effectuée en utilisant l’API JDBC.

Mot clés : Bases de Données, DataMaster, Modèle en oignon, Ontologie, OWL2JESS, JESS,
JDBC

1
CHAPITRE I : INTRODUCTION

2
I .1. Introduction

A notre époque, et sans électricité, la vie quotidienne serait difficilement envisageable. Il est
donc nécessaire de savoir la produire de manière efficace et continue pour répondre à la
consommation croissante d’électricité. Le système industriel étudié « Turbine à vapeur » est
capable de produire de l’électricité en grande quantité, maintenir ce matériel industriel et le
garder en bon état de fonctionnement est un enjeu majeur dans une entreprise de production
électrique. C’est un système très complexe en volume et en diversité des composants à
maintenir (plus de 2000 composants), ce qui nécessite un savoir faire en entretien non
négligeable.

De ce fait les entreprises ont perçus l’importance de prise en charge des pannes causant
l’inactivité du système et par conséquent entraînant la diminution de la production et
augmentation des coûts en cas d'arrêt prolongé. Vu la complexité du système industriel, son
entretien nécessite un personnel qualifié et compétant connaissant au moindre détail tous les
composants du système, leur structure hiérarchique, ainsi que les défauts, causes et remèdes
des pannes précédentes. Les experts ayant ces connaissances ne peuvent pas être tout le temps
disponibles pour aider les acteurs de maintenance. La mémorisation de ces connaissances
pour une ventilation et une redistribution opportune est nécessaire, permettant aux auteurs de
maintenance d'obtenir un diagnostic définitif ou du moins une aide au diagnostic.
Les connaissances de l’entreprise sont de ce fait considérées comme « une ressource
stratégique pour la productivité croissante ; un facteur de stabilité dans un environnement
instable et dynamique » [Ermine, 2000]. Cette ressource est essentielle pour tous les acteurs
de l’organisation. Il est donc important pour toute organisation de maitriser la gestion de son
capital intellectuel. En effet, la gestion des connaissances devrait permettre pour les
organisations de « localiser et rendre visible les connaissances de l’entreprise, être capable de
les conserver, y accéder et les actualiser, savoir comment les diffuser et mieux les utiliser, les
mettre en synergie et les valoriser » [Grundstein, 1995].
Dans ce contexte, l’objectif de notre travail est de construire pour l’acteur de maintenance une
mémoire d’entreprise, lui permettant une meilleure restitution et capitalisation des
connaissances. La mémoire d’entreprise est définie comme la « représentation explicite et
persistante des connaissances et informations cruciales d’une organisation, pour faciliter leurs

3
accès, partage et réutilisation par des membres de l’entreprise dans leurs tâches individuelles
et collectives » [Dieng et al., 2000]. Parmi les techniques adoptées pour la construction d’une
mémoire d’entreprise on trouve, les bases de données, les bases de connaissances, les bases de
cas, etc.

I.2. Problématique

Notre problématique entre dans le cadre de la gestion des connaissances afin d’identifier,
collecter, capitaliser et exploiter les connaissances du domaine spécifié au profit des acteurs
de maintenance et des applications existantes à travers les bases de données, avec pour
domaine d'application la maintenance des turbines à vapeur.

Pour la problématique posée, et lors de notre étude, nous avons constaté que toutes les
données concernant le système industriel « Turbine à Vapeur » sont déjà stockées dans des
bases de données relationnelles qui diffèrent dans leurs contextes d’utilisation. Et elles
représentent les seuls moyens d’accès aux données par les utilisateurs. Ainsi, la gestion des
données dans les bases de données présente des limites quand à l’interrogation, l’échange, la
partageabilité et l’intégration des données, avec le temps et avec les exigences des utilisateurs,
ces limites deviennent des problèmes de plus en plus cruciaux. D’où la nécessité d’intégrer de
nouvelle approche de représentation de connaissances tel que les ontologies qui permettent
d’expliciter la sémantique des données.
[Hondjack, 2007] a formulé les différences qui existent entre les bases de données et les
ontologies en cinq points :
L’objectif de la modélisation : Les modèles conceptuels modélisent les données pour un
système informatique particulier. Tandis que, les ontologies décrivent les concepts d’un
domaine indépendamment de toutes applications et systèmes informatiques particuliers dans
lesquels l’ontologie pourrait être utilisée.

L’identification des concepts : Les classes et les propriétés définies dans l’ontologie sont
associés à des identifiants tels que les URI, ce qui leur permet d’être référencés à partir de
n’importe quel format ou modèle indépendamment de leur structure. Au contraire, la
conceptualisation effectuée dans un modèle conceptuel des données ne peut être réutilisée à
l’extérieur et indépendamment de ce modèle conceptuel.

4
Le raisonnement : Le facteur formel des ontologies permet de raisonner sur les ontologies
soit pour vérifier la cohérence des informations, soit pour déduire l’information.

La consensualité : Le caractère consensuel des ontologies permet de représenter de la même


façon les mêmes concepts dans tous les systèmes d’une communauté.

La souplesse de description : Toutes les instances des classes d’une ontologie, peuvent ne pas
initialiser les mêmes propriétés. Elles n’ont pas forcément la même structure. Cette souplesse
est permise par le fait que les concepts des ontologies soient associés à des identifiants
universels. Cela a pour conséquence de rendre les ontologies beaucoup plus simples à utiliser
pour des échanges ou intégration de systèmes informatiques.

La solution est de capitaliser toutes ces connaissances et les rendre accessible via une
interface simple et facile à exploiter. L’approche adoptée est basée sur une ontologie pour la
représentation des connaissances et afin de gagner du temps nous avons décidé d’extraire les
concepts, les relations et les données stockées dans les bases de données pour une
construction semi-automatique de l’ontologie « turbine à vapeur ».
La construction semi-automatique de l’ontologie à partir de plusieurs bases de données, nous
a poussé à prendre en compte un aspect très important : l’hétérogénéité sémantique des
données (issues de plusieurs bases de données) à intégrer. Cette sémantique permet d’offrir le
meilleur moyen pour rendre les échanges possibles et plus intelligibles à travers l’utilisation
des technologies de web sémantique (RDF, RDFS, OWL).

I.3. Les objectifs du système proposé

A travers cette problématique, nous arrivons à tracer les grands axes à développer :
 Capitalisation des connaissances via la construction semi-automatique d’une ontologie
de domaine et ceci par une extraction des concepts, relations, propriétés ainsi que les
instances à partir des bases de données relationnelles.
 Elaboration d’une interface permettant aux acteurs de maintenance d’exploiter cette
ontologie
 Elaboration d’une interface permettant aux bases de données d’exploiter l’ontologie.

5
Et à travers tous le système, nous comptons atteindre les objectifs suivants :
- Assurer une partageabilité et échange d’informations entre les différents systèmes
informatiques existants ;
- Assurer une assistante des acteurs de maintenance en leurs fournissant les informations
utiles au moment où ils ont en besoin et surtout dans les meilleurs délais possibles ce qui
permet de réduire le temps des pannes, donc une aide au diagnostic pour la maintenance
- Expliciter la sémantique des données issues des bases de données relationnelles
- Assurer une recherche d’informations, intelligemment guidée par l’ontologie

I.4. Description du contenu

Ce mémoire est structuré en six chapitres :


Le chapitre 1 : présente une introduction sur le travail ainsi, il détaille la problématique et les
objectifs à atteindre.

Le chapitre 2 : concerne quelques définitions essentielles sur le système industriel étudié


« Turbine à Vapeur » et sa maintenance.

Le chapitre 3 : concerne l'état de l'art et donne une idée sur les travaux réalisés dans le
domaine de maintenance industrielle, bases de données, système expert et la gestion des
connaissances fondée sur l’ontologie, ainsi que le système à base de connaissance.

Le chapitre 4 : explicite la notion d’ontologie, ses composants et le cycle de son


développement ainsi que l’ontologie basée sur le modèle en oignon.

Le chapitre 5: présente la construction semi-automatique de l’ontologie « turbine à vapeur »


dans Protege; l’insertion des constructeurs OWL, et les relations entre les concepts pour
étendre et compléter l’ontologie. Le système expert JESS (Java Expert System Shell) a été
intégré à l’ontologie, vu la particularité technique du domaine de maintenance industrielle
nécessitant un raisonnement à base de règles externes spécifiques à ce domaine; ainsi nous

6
présentons dans ce chapitre la traduction de l’ontologie en faits de JESS pour qu’elle puisse
être exploitée par ce dernier.

Le chapitre 6 : est consacré à l’application de la démarche proposée et expose quelques cas


d’utilisation de l’ontologie en mode opérationnel, ainsi que l’interface ontologie-utilisateur et
l’interface ontologie-base de données.

7
CHAPITRE II : LA TURBINE A VAPEUR

8
II.1. Introduction

Une turbine est un dispositif rotatif destiné à utiliser la force d’un fluide (eau, vapeur, air, gaz
de combustion) dont le couple est transmis au moyen d’un arbre.
L’énergie du fluide, caractérisée par sa vitesse et son enthalpie est partiellement convertie en
énergie mécanique pour entrainer un alternateur, une pompe ou tout autre récepteur
mécanique rotatif.
Il existe plusieurs types de turbines, à savoir turbine à vapeur, turbine hydraulique, turbine à
gaz combustible, turbine à air.

II.1.1. Définition- Principes généraux de fonctionnement de la turbine à


vapeur
La turbine à vapeur est un moteur thermique à combustion externe, fonctionnant selon le
cycle thermodynamique dit Clausius-Ranhime. Ce cycle se distingue par le changement d’état
affectant le fluide moteur qui est en général de la vapeur d’eau.
Ce cycle comprend au moins les étapes suivantes :
 L’eau liquide est comprimée par une pompe et envoyée vers la chaudière
 La vapeur se détend dans la turbine en fournissant de l’énergie mécanique
 La vapeur détendue est condensée au contact de la source froide sous vide partiel.
La turbine en constitue une évolution exploitant les principaux avantages des turbomachines à
savoir :
 Puissance massique et puissance volumique élevée
 Rendement améliorée par la multiplication des étages de détente

Le rendement croit avec la pression de la vapeur et avec la température de surchauffe.


Cependant, l’augmentation de ces caractéristiques est limitée par la teneur en eau de la vapeur
en fin de détente. En effet, la courbe de détente peut atteindre la courbe de saturation avec
formation de gouttelettes qui nuisent à l’efficacité des derniers étages de détente. La teneur en
eau liquide du mélange doit être limitée à 15 ou 20 pourcent in fine, c’est la pression dans le
condenseur qui fixe de ce fait les pressions et température limites admissibles.

9
Afin d’augmenter la pression et la température malgré le problème de l’humidité en fin de
détente, il est possible de renvoyer la vapeur détendue jusqu'à la saturation vers la chaudière
pour procéder à une resurchauffe dans un échangeur supplémentaire.
Le cycle comprend fondamentalement deux changements d’état (évaporation et
condensation). Le diagramme de phases de l’eau permet d’envisager un cycle à un seul
changement d’état par l’utilisation d’une chaudière supercritique.
Réalisation pratique
Une turbine à vapeur est constituée d’un rotor comprenant un arbre sur lequel sont fixées des
aubes et d’un stator constitué d’un carter portant des déflecteurs fixes, généralement constitué
de deux parties assemblées selon un plan axial. Elle comprend en outre un tore d’admission
segmenté et un divergent d’échappement dirigé vers le condenseur.
La fonction des déflecteurs fixes est d’assurer tout ou partie de la détente en formant un
réseau des tuyères et de modifier la direction de l’écoulement sortant de l’étage précédent.
Une turbine à vapeur comprend un ou plusieurs étages assurant chacun deux fonctions :
 La détente de la vapeur qui correspond à la conversion de l’énergie potentielle en
énergie cinétique.
 La conversion de l’énergie cinétique en couple de rotation de la machine par le biais
des aubages mobiles [1].

Les turbines à vapeur se classent en deux grandes catégories souvent combinées dans une
même machine :
 Turbine à action
La forme la plus simple de turbine à vapeur est la turbine à action, dans laquelle les jets sont
fixés sur la partie intérieure de l’enveloppe de la turbine, et les ailettes placées sur le bord des
roues tournantes montées sur un arbre central. La vapeur se déplaçant dans une tuyère fixe
passe sur les ailettes incurvées, qui absorbent une partie de l’énergie cinétique de la vapeur
dilatée, faisant ainsi tourner la roue et l’arbre sur lesquels elles sont montées. Cette turbine est
conçue de manière à ce que la vapeur entrant par une extrémité de la turbine se dilate à
travers une succession de tuyères jusqu'à ce qu’elle ait perdu la majeure partie de son énergie
interne.

[1] : Encyclopédie msn.encarta, 2007,Machine à vapeur, http://fr.encarta.com.

10
 Turbine à réaction
Dans la turbine à réaction, une partie de l’énergie mécanique est obtenue par l’impact de la
vapeur sur les ailettes. La partie la plus importante est obtenue par l’accélération de la vapeur
lors de son passage dans la roue de la turbine, ou elle se dilate.
Une turbine de ce type se compose de deux jeux d’ailettes, l’un fixe, l’autre mobile. Ces
ailettes sont disposées de telle façon que chaque paire joue le rôle de tuyère, à travers laquelle
la vapeur se dilate lors de son passage. Dans chaque étage, une faible quantité d’énergie
thermique est convertie en énergie cinétique.
La vapeur se détend dans les aubes fixes, puis entraine les aubes mobiles disposées sur la
roue ou le tambour de la turbine. Les ailettes d’une turbine à réaction sont en général montées
sur un tambour, qui fait alors office d’arbre.
Les turbines à réaction nécessitent en général davantage d’étages que les turbines à action, Il a
pu être démontré que, pour le même diamètre et la même gamme énergétique, une turbine à
réaction a besoin de deux fois plus d’étages pour obtenir un rendement maximal. Les grosses
turbines, qui sont généralement à action, utilisent une certaine réaction à la base du trajet de
vapeur pour assurer en débit efficace à travers les auges. Nombre de turbines, qui sont
normalement à réaction, disposent d’un premier étage de commande d’impulsion, qui permet
d’envisager la réduction du nombre total d’étages nécessaires. Les arbres des turbines de
chaque étage sont reliés entre eux au moyen d’accouplements [2].

Génération électrique :
Du fait de leurs caractéristiques, Les turbines à vapeur sont très employées dans les centrales
thermiques de moyenne et forte puissance, y compris nucléaires. Dans la gamme de puissance
de 1 à 10 MW et elles sont utilisées pour d’autres applications [1].

[2] : http://www.univ-lille1.fr/mail/gene_vap/fr/
[3] : http://www.directindustry.com/prod/ansaldo-energia/steam-turbine-29641-232047.html

11
II.1.2. Les principaux composants des turbines à vapeur

 Alternateur
L'alternateur est une machine électrique du type génératrice à courant alternatif qui
transforme l'énergie mécanique en énergie électrique. Il est entraîné par la turbine [3].

 Transformateurs
Transformateur principal (TP) :
L’évacuation de l’énergie produite par l’alternateur est évacuée sur le réseau haute
tension à travers un transformateur principal élévateur : 13800V/63000V, un disjoncteur 63
KV (disjoncteur 52), trois câbles souterrains à pression d’huile et une ligne triphasée aérienne.
Transformateur de soutirage (TS) :
Les auxiliaires du groupe sont alimentés à travers un transformateur de soutirage
(TS) abaisseur : 13800V/6300V en service normal et un transformateur de démarrage (TD)
abaisseur : 63000V/ 6300V en secours. [3]
 Chaudière
Le rôle du générateur de vapeur est d'extraire l'énergie calorifique du combustible
pour la céder à l'eau et produire de la vapeur à des paramètres fixés. Il constitue la source
chaude du cycle thermodynamique. Cette vapeur sera utilisée par la turbine pour fournir de
l'énergie mécanique [3]
 Condenseur
Afin de maximiser le rendement de la turbine à vapeur, la pression et la température de la
sortie de vapeur doivent être aussi basses que possible. Pour cela, la vapeur qui sort de la
turbine est dirigée vers le condenseur où elle est refroidie et condensée. Le condenseur est un
échangeur de chaleur avec des milliers de tubes dans lesquels l'eau du circuit de
refroidissement circule. La vapeur circule sur les tubes et se condense au contact de ceux-ci.
L'eau du circuit de refroidissement extrait alors la chaleur de la vapeur. [3]

 Pompe alimentaire
La pompe KSB à très haute pression est une pompe a centrifuge multicellulaire.
Elle comprend un corps d’aspiration, un corps de refoulement et un certain nombre d’étages
ou de cellules assemblées par des tirants.

12
L’eau, provenant de la bâche alimentaire à la pompe, possède une énergie de pression et une
énergie cinétique qui seront augmentées dans les turbines en mouvement pour alimenter le
générateur de vapeur (chaudière) en quantité nécessaires d’eau pour maintenir le niveau
normal [3].

Figure II.1 : Schéma de la turbine à vapeur [4]

II.1.3. Fonctionnement

Bien que les turbines à vapeur soient construites selon deux principes différents (à action ou à
réaction, leurs éléments essentiels sont similaires. Elles se composent de tuyères ou de jets, et
d’ailettes. La vapeur s’écoule dans les tuyères, dans les quelles elle se dilate. Ainsi,
sa température diminue et son énergie cinétique augmente. La vapeur en mouvement exerce
une pression contre les ailettes, entraînant leur rotation.
La disposition des jets et des ailettes, fixes ou stationnaires, dépend du type de turbine. À la
sortie du dernier condenseur (échangeur thermique), l’eau peut être de nouveau vaporisée et
surchauffée. L’eau ou la vapeur en sortie est alors ramenée vers la chaudière et la pompe
alimentaire, qui compresse de l’eau à l’état liquide. Il s’agit d’une turbine auxiliaire intégrée
au cycle thermodynamique de la turbine principale utilisant de la vapeur soutirée dans celle-
ci.
Les turbines à vapeur possèdent toutefois un équipement annexe, nécessaire à leur
fonctionnement. Parmi celui-ci, un palier de tourillon supporte l’arbre et un palier de butée le

13
positionne de manière axiale. Un système d’huile assure le graissage des paliers ; des joints
réduisent les pertes de vapeur tout au long de son trajet. Enfin, un système d’étanchéité
empêche la vapeur de s’échapper à l’extérieur de la turbine et l’air d’y entrer. La vitesse de
rotation est commandée par des soupapes situées aux entrées d’admission de la machine et
pilotées par des systèmes de régulation électroniques ou mécaniques. Les turbines à réaction
développent une poussée axiale considérable, du fait de la chute de pression sur les ailettes
mobiles. Cette poussée est généralement compensée par l’utilisation d’un piston
d’équilibrage.

La turbine à vapeur utilise des principes thermodynamiques. Lorsque la vapeur se dilate, sa


température et donc son énergie interne diminuent. Cette réduction de l’énergie interne
s’accompagne d’une augmentation de l’énergie cinétique sous la forme d’une accélération des
particules de vapeur. Cette transformation rend une grande partie de l’énergie disponible.
Ainsi, une réduction de 100 kJ de l’énergie interne, du fait de la dilatation, peut provoquer un
accroissement de la vitesse des particules de vapeur de l’ordre de 2 800 km/h. À de telles
vitesses, l’énergie disponible est importante. Lorsque la pression de la vapeur d’eau en sortie
de la turbine est égale à la pression atmosphérique, la turbine est dite à condensation.

Aujourd’hui, les turbines à vapeur sont généralement limitées à une température maximale de
580 °C dans le premier étage, et à une pression maximale d’admission de 170 à 180 bars [5].

II.2. La Maintenance Industrielle

La maintenance est un ensemble d’actions tendant à prévenir ou à corriger les dégradations


d’un matériel afin de maintenir ou de rétablir sa conformité aux spécifications. Pour une unité
de production cette maintenance devrait permettre une contribution maximale à une meilleure
efficacité et une meilleure rentabilité.
Au cours des vingt dernières années, la maintenance a considérablement évoluée.
Actuellement, elle constitue l’un des vecteurs essentiels de compétitivité des entreprises
[Talbi et al, 2003].
Les concepts liés à la maintenance sont :
Diagnostic : Identification d’une panne par ses symptômes
Expertise : Intervention, opération d’un expert, évaluation de l’état d’un équipement

14
Pronostic : Prévision, supposition sur ce qui doit arriver sur l’équipement

II.2.1. Les types de maintenance

Il existe plusieurs types de maintenance parmi eux, on peut distinguer :


La maintenance préventive : Effectuée périodiquement de façon préventive, elle permet
d’améliorer la fiabilité des installations mais ne corrige pas les pannes.
La maintenance curative ou corrective : Elle intervient après le constat d’une panne et
consiste à en diagnostiquer les causes à réparer.
La maintenance conditionnelle ou prédictive : Prévenir les pannes sans démontage ou arrêt
de production. Cette maintenance est basée sur l’analyse des conditions de fonctionnement
des machines et elle est différente de la maintenance préventive traditionnelle qui se résume à
des opérations de maintenance programmées à l’avance et à des intervalles réguliers.
La maintenance prédictive comporte trois formes : traditionnelle (un expert ausculte de
temps en temps la machine et analyse ses mesures périodiques pour essayer de prévoir un
éventuel défaut) ; continue (l’utilisateur de la machine installe des capteurs sur une machine
critique et un expert réalise l’analyse des informations sur un PC, la collecte est donc
automatique, mais l’analyse ne l’est pas ; continue intelligente (la collecte et l’analyse sont
automatique).

II. 3. Maintenance de la turbine à vapeur

La maintenance a principalement pour but de réduire le temps d’arrêt des équipements qui
coûte cher, ce qui permet de limiter les pertes de production et de réduire les coûts de
maintenance.
Parmi les problèmes majeurs rencontrés dans les turbines à vapeur on trouve [6] :
- Les aubes de turbine à vapeur basse pression ont besoin d’être réparées fréquemment
en raison de dommages provoqués par les mauvaises conditions de vapeur, la perte de
plaque anti_érosion brasées ou de dommages provoqués par des corps étranges. Ces
aubes peuvent être en principe entièrement réparées en toute sécurité sur site ou en
atelier, avec jusqu'à 50% de remplacement du profil externe, comprenant souvent :
 Le remplacement des plaques de protection et du bord d’attaque (stellite)
 La réparation par soudure de section endommagée du bord de fuite

15
 Le remplacement complet des extrémités
 Le remplacement/ la remise en état de tenons
 Le repositionnement d’amortisseurs et réinstallation de fils de liaison

Figure II.2 : Maintenance de turbine à vapeur

- Réparation des diaphragmes et de tuyère : permet de réparer/ remettre en condition


pour remplacer entièrement les ailettes ou les segments de profils externe, y compris :
 La réparation par soudure d’ailettes/ de séparation
 Le remplacement de segment d’ailette
 Le remplacement et la réparation de bagues internes, externes
 La réparation et la modification de goupille de positionnement
 Le remplacement de joint

[4] : http://www.retscreen.net/fr/steam_turbine_schematic.php
[5] : http://fr.encarta.msn.com/encyclopedia_761563866_3/turbine.html
[6] : http:// www.power-technology.com/contractors/operations/wood_group/

16
CHAPITRE III : ETAT DE L’ART

17
Pour bien cerner l’état de l’art, il est nécessaire d’adopter une vision multidisciplinaire, les
différents domaines concernés par notre étude sont : la maintenance industrielle, les bases de
données et les systèmes à base de connaissances.

III.1. Travaux réalisés et état de l'art dans le domaine de la gestion


des connaissances pour la Maintenance Industrielle

Les ontologies ont montré leur efficacité dans le cadre de la gestion des connaissances dans
le domaine de maintenance industrielle, nous citons comme exemple la plateforme PROTEUS
[Rasovska, et al., 2005] ou une approche « raisonnement à partir de cas » (RàPc) a été adopté
comme modèle de résolution de problèmes.
Le RàPC met en œuvre une base de connaissances composée de cas contenant des
expériences de problèmes résolus ou l’on peut rechercher des expériences passées similaires
au problème à résoudre (remémoration).
Ces cas sont mémorisés et organisés en fonction de critères bien déterminés permettant de les
retrouver efficacement. La non existence d’un cas dans la base, fait l’objet de l’insertion de ce
dernier, ceci permet de faire évoluer les connaissances dans la base des cas.

Un autre exemple de développement de système d’aide à l’analyse des risques dans le


domaine industriel basé sur l’ontologie, l’indexation des ressources et le raisonnement à partir
de cas est présenté dans [Debray et al., 2008]. Le système de recherche d’information
utilisant l’ontologie proposé dans cet article est interrogeable par le langage de requêtes
SPARQL [Prud’hommeaux et seaborne, 2006].

Dans le cadre de la conception/ exploitation dans l’entreprise étendue et plus particulièrement


des systèmes d’échange de données techniques, il ya eu le développement de dictionnaire de
composants PLIB (ontologie en modèle PLIB) [7] dont le but est d’assurer:

[7] : http://www.plib.ensma.fr

18
 Interchangeabilité des données techniques ;
 Adaptation des formats de données ;
 Gestion des bases de données multipartenaires
 Plateau commun de développement
PLIB est un concept normalisé de modélisation de données descriptives, basé sur le corpus de
normes ISO 13584 et s’appuyant sur :
 Des dictionnaires (modèles de description)
 Des catalogues générés, sur la base de ces dictionnaires à partir des données fournies
par les fabricants de produits de fonctionnement industriels du commerce :
. Catalogues techniques et documentation associées pour sélection des produits
(adéquation au besoin fonctionnel).
. Référentiel de systèmes d’information internes aux entreprises.
. Un code unique et partagé par tous les intervenants (fabricants, fournisseurs,
clients) supprime des litiges et des aléas de production
. Une classification commune facilite les échanges
. Une description avec des dictionnaires standardisés voir normalisés : assure un
langage commun et facilite les échanges (multilinguisme) et permet de gérer le processus
complet (conception, maintenance, ect..) et chaque intervenant diminue ses coûts.

19
Figure III.1 : Catalogue des composants industriels sous PLIB [7]

[El Hadj Mimoune, 2004] et pour offrir une représentation qui répond aux exigences des
données techniques des composants (produits industriels) a opté pour le modèle PLIB, puis il
a proposé l’implémentation de cette représentation (PLIB) au sein d’un SGBD avec SQL
comme seul langage de requête et d’exploitation précisant qu’il (SQL) n’offre pas la
possibilité d’exploiter le niveau de l’ontologie alors il a proposé en perspective le
développement d’un nouveau langage exploitant les deux niveaux : le niveau ontologie et le
niveau logique des données.

D’autres travaux utilisent des approches basées sur le système expert, nous citons comme
exemple l’article [Ketata et al., 2005] où l’auteur a intégré la logique floue dans le système
expert d’aide à la décision dédié au diagnostic industriel. Précisant les avantages apportés par
l’intégration de cette technique et parmi ces avantages il cite :
 Permet de manipuler des informations incomplètes, imprécises et de modéliser des
connaissances subjectives en fournissant une interprétation linguistique des données
numériques ;

20
 Garantit l’unicité des résultats générés par le système expert pour une situation donnée
permettant de minimiser l’incertitude des interprétations humaines ;
 Garantit la rapidité.

Un autre exemple propose une méthode de construction d’un modèle d’aide à la décision à
base de Réseaux Bayésiens orientés objet dont le but est l’évaluation globale d’un processus
industriel concernant la maintenance d’un tour [Weberet al., 2004].

Le travail de [IZAA, 2006] s’inscrit dans le cadre de l’intégration sémantique de systèmes


d’informations de grandes entreprises industrielles, il propose une approche flexible basée sur
les services sémantiques, en combinant à la fois les ontologies et les services Web.

[Bahloul, 2006] a utilisé l’ontologie comme model central pour la gestion des connaissances
de l’entreprise, précisant que la gestion des connaissances basée sur les ontologies a déjà fait
l’objet de quelques applications dont o’comm [Comma, 2000] en fait un bon exemple.
L’auteur a aussi développé un outil prototype permettant l’utilisation de l’ontologie pour
l’exploitation et la réutilisation des connaissances à travers des interfaces utilisateurs.
L’implémentation de l’ontologie s’est faite avec Protege, Racer [[Haarslev et Moller, 2001] et
Sesame [Broekstra et al., 2002] et pour une interrogation de l’ontologie d’une façon
transparente pour l’utilisateur, l’auteur a développé une API client communiquant avec
Sesame permettant d’interroger l’ontologie grâce à des requêtes formulées en langage
RDQL[Seaborne, 2004].

[ Laallam, 2007] a modélisé et développé une ontologie de turbine à gaz puis a procédé à son
exploitation à l’aide de l’outil JESSTab [Erikson, 2003 ] plugin de Protege, utilisant le modèle
Frame pour obtenir un système d’aide au diagnostic offrant des services aux acteurs de
maintenance de la Turbine à Gaz. L’outil JESSTab permet de raisonner sur l’ontologie, mais
la version actuelle ne supporte pas la sémantique d’OWL, ceci est parmi les travaux futurs
pour l’extension de JessTab [ 8].

[8] : http://www.ida.liu.se/~her/JessTab/tutorial06/

21
Dans l’article [Khadir et al, 2008], les auteurs ont proposé un environnement collaboratif
permettant aux utilisateurs (experts et débutants) de partager leurs connaissances à travers une
ontologie partagée pour l’entretien de la turbine à vapeur par l’intermédiaire des outils
synchrones et asynchrones. L’ontologie a été construite d’une manière semi- automatique en
exportant les concepts et les instances à partir des bases de données relationnelles et ceci
grâce au plug-in DataGénie de Protege.

III.2. Ontologie et bases de données


III.2.1. Introduction

Jean [Jean, 2007] a définit l’ontologie comme suit: « une ontologie de domaine est un
dictionnaire formel et consensuel des catégories et des propriétés d’entités existant dans un
domaine d’étude et des relations qui les lient ». Précisant que cette définition met en avant
trois caractéristiques qui distinguent une ontologie de domaine du modèle conceptuel des
données.
Une ontologie est (1) formelle permettant des raisonnements (2) consensuelle dans une
communauté et (3) référençable indique que toute entité ou relation décrite dans l’ontologie
peut être directement référencée par un symbole, dans n’importe quel but et ce à partir de
n’importe quel contexte, indépendamment des autres entités et relations. Selon ces critères des
différences entre l’ontologie et le modèle conceptuel ont pu être soulevés.
Le modèle conceptuel d’une base de données, tout comme une ontologie, définit une
conceptualisation d’une partie du monde ainsi il semble similaire à une ontologie. Leurs
différences par rapport aux caractéristiques définies ci-dessus.
Formelle : Le caractère formel d’un modèle conceptuel dépend du formalisme de
modélisation utilisé exemple le modèle Entité-Association. Mais ils peuvent être considérés
comme formels
Consensuel : Un modèle conceptuel ne satisfait pas cette caractéristique car il est conçu en
fonction des besoins d’une application particulière.
Référençable : Un identifiant d’un élément défini dans un modèle conceptuel est un nom qui
ne peut être référencé sans ambiguïté que dans le contexte du système d’information basé sur

22
ce modèle conceptuel particulier. Ainsi, un modèle conceptuel ne satisfait pas cette
caractéristique.
Cette analyse montre qu’un modèle de conception d’une base de données n’est pas une
ontologie.

III.2.2. Travaux réalisés et état de l’art de l’utilisation des ontologies dans


le domaine des bases de données

L’utilisation des ontologies a permis de résoudre différents problèmes rencontrés dans le


contexte des bases de données à savoir :

L’ontologie est utilisée pour concevoir une base de données, [Hondjack et al.,2007] a proposé
une méthodologie de conception de base de données basée sur les ontologies, cette
méthodologie offre deux avantages :
1. Elle permet de redéfinir la structure des classes en fonction des besoins des
applications cibles ;
2. Elle permet d’importer un ensemble de propriétés de l’ontologie de domaine que le
concepteur considère essentiel ou utile pour son application.
Utilisant l’éditeur PLIB, la démarche proposée passe par les étapes suivantes :
 Construire ou importer une ontologie couvrant le domaine d’étude qui concerne
l’application pour laquelle la base de données est conçue ;
 Construire le modèle conceptuel à partir de l’ontologie locale, ceci est réalisé par la
sélection des classes et des propriétés que le concepteur souhaite ;
 A l’aide d’un ensemble de règles de correspondance choisi, le modèle conceptuel est
traduit en modèle logique qui définit la structure des données sous forme interprétable
par le SGBD cible ;
 Enfin le SGBD génèrera la représentation physique des données.

Une ontologie peut également être utilisée pour enrichir la sémantique du modèle logique
d’une base de données en ajoutant des annotations. Cette indexation sémantique des bases de
données peut être assurée en associant des éléments du modèle logique (table, colonne, etc.) à
une ontologie. Cette correspondance peut être assistée par des outils s’appuyant sur les noms
utilisés comme l’a présenté [Sugumaran et storey,2006].

23
L’ontologie a été aussi utilisée comme format d’échange de données, les échanges basés sur
des ontologies sont très flexibles comparé au format d’échange usuel qui spécifie la structure
complète des données échangées, un exemple d’échange de données basé sur un médiateur est
présenté dans [chawathe et al., 1994]. Cette flexibilité est due à la conceptualisation du
domaine dont chaque élément est référençable.

D’autres travaux ont été proposés dans l’intégration des systèmes. Un système d’intégration
fournit une interface d’accès unique à des données stockées dans plusieurs sources de
données. Ces sources de données sont généralement, conçues indépendamment l’une de
l’autre et par des concepteurs différents. Intégrer des systèmes dont la sémantique des
données est différente revient à régler le problème d’hétérogénéité des données. L’ontologie
a été utilisée pour définir la sémantique des données des différentes sources à l’aide de
concepts commun, formalisés et référençable. Donc l’utilisation des ontologies représente une
solution pour résoudre les problèmes d’hétérogénéité des données. Parmi les travaux
d’intégration basés sur des ontologies, on cite la proposition de [Noy,2004].

D’autres propositions ont été faites pour permettre la persistance d’ontologies et de leurs
instances dans des bases de données : les bases de données à base ontologique
Une base de données à base ontologique (BDBO) [Hondjack, 2007] : est une source de
données qui contient des ontologies, un ensemble de données et des liens entre ces données et
les éléments ontologiques qui en définissent le sens, et les données à base ontologique sont les
données contenues dans une BDBO.
Plusieurs BDBO ont été proposées, elles se différencient suivant :
 Le modèle d’ontologie supporté ;
 Le schéma de base de données utilisé pour stocker des ontologies représentées selon
ce modèle ;
 Le schéma de base de données utilisé pour représenter les données à base ontologique
(instance)
 Les mécanismes utilisés pour définir le lien entre les données (instances) et les
éléments des ontologies (concepts)

24
L’architecture de la base de données à base ontologique intègre les deux éléments suivants :
 Le niveau ontologique : il est composé d’ontologies qui définissent les concepts de
différents domaines d’étude sous la forme de classes et de propriétés.
 L’aspect conceptuel : Cet aspect est représenté par le lien entre le niveau ontologique
et le niveau logique. Ce lien indique l’ensemble des concepts des ontologies qui sont
exploité pour satisfaire les besoins des applications pour lesquelles la base de données
est conçue. Cet ensemble de concepts, une fois choisi, peut être utilisé pour générer
automatiquement le modèle logique des données.

Un des travaux les plus récents est le travail de [Jean, 2007] il fournit un nouveau langage de
définition, manipulation et interrogation de données pour sa base de données à base
ontologique. D’après son étude, il a montré que les langages d’interrogation d’ontologie
existants ne satisfont pas les exigences qu’il a tracé, parmi ces exigences on cite ( définition et
manipulation des ontologies, définition et manipulation des données, interrogation des
ontologies et des données, séparément et simultanément, ect…). Et pour répondre à toutes
les exigences qu’il a tracé afin de mieux exploiter les bases de données à base ontologique, il
a définit un nouveau langage qu’il a appelé « OntoQl ». Ce langage permet de définir des
ontologies selon un modèle en couches qui caractérise différentes catégories d’ontologies. Il
est compatible avec le langage SQL et propose une syntaxe qui lui est proche pour permettre
des traitements sur les données aussi bien au niveau ontologique qu’au niveau logique des
données. Il combine ainsi les capacités des langages traditionnels de bases de données qui
disposent d’opérateurs algébriques pour manipuler les données à partir de leur structure et les
capacités des langages proposés dans le contexte du web sémantique pour interroger des
données à partir de leur sémantique, c.à.d de l’ontologie qui en définit le sens. Il permet aussi
d’offrir des capacités nouvelles au sein des langages de type SQL.

25
III.3 LES SYSTEMES A BASE DE CONNAISSANCES

Les Systèmes à Base de Connaissances permettent le stockage et la consultation de


connaissances, le raisonnement automatique sur les connaissances stockées, ainsi que le
partage de connaissances entre systèmes informatiques [Furst, 2004]. De manière générale, il
s’agit de permettre un dialogue et une coopération entre le système et l’utilisateur humain
(systèmes d’aide à la décision, systèmes d’enseignement assisté par ordinateur, recherche
d’information sur le Web).

III. 3.1. Apport des SBC


La réalisation des SBC a conduit à dépasser la représentation des connaissances sous forme de
règles logiques utilisée dans les Systèmes Expert permettant de résoudre automatiquement des
problèmes seulement. Cette évolution s’est tout d’abord orientée vers le développement des
logiques non classiques permettant de représenter l’incertitude des énoncés. Et actuellement
se répand l’utilisation de modèles plus axés sur la représentation des connaissances que sur
leur utilisation à des fins de raisonnement tel que la Logique de Description ect… Et qui
permettent des représentations davantage descriptives et explicites de connaissances [Furst,
2004].
En plus l’architecture des SBC est une structure modulaire qui sépare les connaissances et les
mécanismes de manipulation de ces connaissances. Cette structure permet de développer de
façon séparée la représentation de connaissances d’un domaine et plusieurs mécanismes de
raisonnement. C’est pour atteindre le but de pouvoir utiliser la même représentation de
connaissances dans des SBC implémentant des mécanismes de raisonnement chacun a pour
fonction l’objectif applicatif recherché.

Les connaissances sont constituées par une base de connaissances qui regroupe l’ensemble de
ce qui est connu dans le domaine considéré (les faits). Les mécanismes de raisonnement sont
implémentés dans un moteur d’inférence qui réalise la résolution de problèmes en produisant
de nouveaux faits dans la base de connaissances.

26
Dans ce contexte, les ontologies apparaissent comme des composants des SBC permettant une
représentation conceptuelle et explicite des connaissances tout en assurant l’indépendance
entre cette représentation et les mécanismes de raisonnement mis en œuvre dans le SBC.

Ainsi, l’utilisation d’ontologie garantit une grande modularité puisque chaque moteur
d’inférence peut être utilisé indépendamment du domaine mais uniquement selon le scénario
d’usage envisagé (objectif opérationnel). L’usage d’ontologie au sein du SBC apparaît alors
comme une réponse au problème de la réutilisabilité des représentations des connaissances
[Corcho, et al., 2000]

L’indépendance entre l’ontologie et les systèmes qui les utilisent permet d’utiliser celle-ci
pour la communication entre systèmes au niveau conceptuel, elle sert de support à
l’interopérabilité et le dialogue [Gandon, 2002].

III.3.2 Les ontologies et les SBC

C’est à partir des années 90 que les ontologies sont apparues dans le domaine de l’ingénierie
des connaissances, et plus largement en Intelligence Artificielle, comme une approche de
modélisation et de représentation des connaissances. Elles se sont introduites dans le cadre
des démarches d’acquisition des connaissances pour les Systèmes à Base de Connaissances
(SBC) et ont évolué vers la représentation des connaissances et leur organisation [Furst,
2004].
Durant la dernière décennie, l’utilisation des ontologies pour la gestion des connaissances
s’est avérée avantageuse dans le domaine de la recherche en intelligence artificielle où la
gestion des connaissances est basée sur la représentation des connaissances de façon à simuler
le raisonnement humain afin de modéliser les connaissances d’une façon utilisable par la
machine [Barthès, 1997]. Ainsi, les ontologies sont utiles pour construire des systèmes de
gestion des connaissances. Elles permettent la représentation des connaissances et la
modélisation des raisonnements qui sont des caractéristiques fondamentales des SBC.

Elles ont pour rôle de fournir un système de concepts fondamentaux du domaine, afin de
construire une base de connaissances. La conceptualisation permise par les ontologies
représente en effet, une base solide sur laquelle sont construites des bases de connaissances

27
partageables et utilisables. Une ontologie modélise à l’aide d’un formalisme approprié les
connaissances spécifiques d’un domaine d’application. Elle permet ensuite, la recherche et la
restitution des connaissances dans des bases de connaissances et des systèmes d’information
hétérogènes et distribués. La recherche via une ontologie est souvent basée sur la sémantique
en exploitant les mécanismes de raisonnement et l’inférence.
L’ingénierie des ontologies est née de la volonté de diversifier les applications des SBC, et de
permettre une représentation des connaissances indépendante de ces diverses applications, de
manière à assurer sa portabilité d’une application à l’autre. Les ontologies permettent
d’intégrer à la fois les connaissances terminologiques d’un domaine et l’expression de la
sémantique de celui-ci, tout en conservant leur indépendance vis à vis des usages
opérationnels des SBC.

Décrire les connaissances entre concepts, de relations et de propriétés sur ces concepts et ces
relations ne suffit généralement pas à atteindre l’objectif opérationnel d’un SBC. D'ailleurs
comme spécifié dans [Teulier, Girard, 2001] : « De façon un peu caricaturale, on pourrait
dire que ce ne sont pas les connaissances en elle-même qui sont intéressantes. En fait, ce qui
doit être le centre d’intérêt pour le modélisateur, c’est davantage leur mise en œuvre, leur
concrétisation dans une action pour atteindre un but car c’est bien l’activité qu’on cherche à
assister et non les connaissances en elles mêmes ».

Les ontologies sont utilisées dans les systèmes à base de connaissances (SBC), où elles
peuvent servir de ressources de base pour le raisonnement de spécification permettant le
contrôle de la sémantique d’une base de connaissance.
Les ontologies de domaine sont conçues pour supporter ou rendre possible le traitement de
requêtes. Elles ont pour finalité d’être utilisées comme ressources pour tout type de
raisonnement dans des systèmes informatiques.
Utiliser une ontologie dans une machine à des fins de raisonnement nécessite que lui soit
attachée une sémantique opérationnelle qui précise les opérations que le système va appliquer
aux connaissances, et qui doivent être conformes à la sémantique formelle déjà spécifiée dans
l’ontologie.
La sémantique formelle dépend du domaine de connaissances et est complètement déterminée
à partir d’un corpus à l’issue des processus de conceptualisation.
La sémantique opérationnelle ne dépend pas seulement des connaissances du domaine, mais
également de l’usage opérationnel qui va être fait de l’ontologie considérée. Elle est donc

28
définie non par les experts du domaine mais par les concepteurs du système intégrant
l’ontologie.

Construire des représentations de connaissance au niveau conceptuel, tout en les destinant à


être utilisées pour le raisonnement dans un cadre opérationnel, oblige à se pencher
particulièrement sur le problème de l’opérationnalisation des ontologies, c.a.d comment une
spécification d’une conceptualisation va pouvoir être mise en œuvre de façon opérationnelle
dans un SBC pour mener différent types de raisonnement [ Furst, 2004].

III.3.3. L’opérationnalisation de l’ontologie

La possibilité d’utiliser l’ontologie dans différents SBC est alors assurée à travers un
processus d’opérationnalisation, consistant à plonger l’ontologie dans un langage opérationnel
de représentation de connaissances, conformément à l’objectif opérationnel du SBC.
L’utilisation opérationnelle d’une ontologie suppose sa représentation dans un langage non
seulement formel mais aussi opérationnel c.a.d offrant des mécanismes de raisonnement
adaptés aux manipulations de connaissances envisagées [Bouaud et al., 1995]. Il est donc
nécessaire de transcrire l’ontologie du langage formel dans lequel elle est exprimée dans un
langage opérationnel à travers lequel le système manipulera effectivement les connaissances.

On appelle ontologie opérationnelle, une ontologie exprimée dans un langage opérationnel et


dotée d’une sémantique opérationnelle. Un exemple est présenté dans [Furst, 2004] où il a
utilisé un outil d’édition et d’opérationnalisation d’ontologie « TooCoM » dans le cadre du
modèle des Graphes Conceptuels.

L’opérationnalisation de l’ontologie est l’un des objectifs tracés pour notre travail, nous y
reviendrons en détail dans la suite de ce mémoire.

29
CHAPITRE IV : LES ONTOLOGIES

30
IV.1. Définition et développement des ontologies

Le terme ontologie est un terme grec composé des mots « ontos » et « logos » qui veulent dire
respectivement l’essence de l’être. Ce terme, hérite d’une tradition philosophique qui
s’intéresse à la science de l’Etre, est apparu dans le domaine informatique grâce notamment
au projet ARPA Knowledge Sharing Effort [Gruber, 1991]. La première définition pour les
ontologies dans le domaine de l’intelligence artificielle est donc donnée par Gruber : « une
ontologie est une spécification explicite d’une conceptualisation » [Gruber, 1993]
 Le terme conceptualisation : fait référence à un modèle abstrait d’une partie de monde
réel permettant d’identifier les concepts pertinents de ce monde.
 Le terme explicite : signifie que l’identification de la structure des concepts ainsi que
les contraintes sur leur utilisation sont définie d’une manière claire et précise.

IV.1.1. Les composants d’une ontologie

Comme tout formalisme de représentation, avant d’utiliser les ontologies, il est nécessaire de
connaître les composants de base de l’ontologie.
Une ontologie peut être vue comme un ensemble structurée de concepts et de relations entre
ces concepts destinés à représenter les objets du monde sous une forme compréhensible aussi
bien par les hommes que par les machines. Les connaissances traduites par une ontologie sont
véhiculées à l’aide d’un certain nombre de constituants ou briques de base qui sont
principalement des 1) concepts 2) relations 3) fonctions 4) axiomes 5) instances [Gruber,
1993], [Gomez-Perez, 2000].

Les concepts : aussi appelés termes ou classes sont des notions (ou objets) permettant la
description d’un concept, d’une tâche, d’une fonction, d’une action, d’une stratégie ou d’un
processus de raisonnement, etc. Ils peuvent être abstraits ou concrets, élémentaires ou
composés, réels ou fictifs. Habituellement, les concepts sont organisés en taxonomie. Une
taxonomie est une hiérarchie de concepts (ou objets) reliés entre eux en fonction de critères
sémantiques particuliers.
Les relations : traduisent les liens existant entre les concepts de façon à représenter un type
d’interaction entre les concepts d’un domaine. Elles sont formellement définies comme tout

31
sous-ensemble d’un produit de n ensembles, c'est-à-dire R : C1xC2x…..Cn. Des exemples de
relations binaires sont : sous-concept-de, sorte-de, etc. Ces relations nous permettent de
capturer la structuration ainsi que l’interaction entre les concepts, ce qui permet de représenter
une grande partie de la sémantique de l’ontologie.

Les propriétés (ou attributs) : sont des restrictions des concepts ou des relations.

Les fonctions : sont des cas particuliers de relations dans lesquelles le nième élément de la
relation est défini de manière unique à partir des n-1 éléments précédents. Formellement, les
fonctions sont définies ainsi : F : c1 x c2 x c3 …….. x cn-1 -> cn

Les axiomes de l’ontologie permettent de définir la sémantique des termes (classes, relations),
leurs propriétés et toutes contraintes quant à leur interprétation. Ils sont définis à l’aide de
formules bien formées de la logique du premier ordre en utilisant les prédicats de l’ontologie.

Les instances : sont utilisées pour représenter les occurrences.

IV.1.2. Les types d’ontologies


Les types d’ontologie les plus utilisées sont :

1) Les ontologies supérieures (Upper Top-level ontology) [Guarino, 1999]


Ces ontologies portent sur des concepts généraux qui sont indépendants d’un domaine ou
d’un problème particulier, exemple : les concepts de temps, d’espace …ect
« Elles sont prévues pour être utilisées dans des situations diverses et variées et peuvent servir
une large communauté d’utilisateurs, ainsi elles peuvent être utilisées dans l’organisation des
parties substantielles des connaissances humaines, comme la compréhension du langage
naturel. » [Mihoubi, 2000]

32
2) Les ontologies du domaine (Domain ontology) [Mizoguchi, 1995]
Ce type d’ontologies exprime des conceptualisations spécifiques à des ontologies de domaines
particuliers de la connaissance. Elles fournissent le vocabulaire des concepts du domaine de
connaissance.

3) Les ontologies d’application [van Heijst et al., 1997]


Ces ontologies sont les plus spécifiques. Les concepts correspondent souvent aux rôles joués
par les entités du domaine tout en exécutant une certaine activité. Elles peuvent contenir des
extensions spécifiques telles les méthodes et tâches. Elles contiennent toutes les définitions
nécessaires pour décrire la connaissance requise pour une application particulière.

4) Les ontologies de tâches (Task ontologies) [Mizoguchi, 1995]


Ces ontologies sont utilisées pour gérer des tâches spécifiques liées à la résolution de
problèmes dans les systèmes tels que les tâches de diagnostic et de planification. Elles
fournissent un ensemble de termes au moyen des quels on peut décrire au niveau générique
comment résoudre un type de problème.

IV.1.3. La construction d’une ontologie

Il existe trois méthodes possibles de création d’une ontologie. Une ontologie peut être
construite d’une façon manuelle, automatique ou mixte (semi-automatique).
La construction manuelle : Il existe plusieurs méthodologies offrant des techniques classiques
de collecte et d’analyse des connaissances.
La création d’une ontologie d’une manière automatique se base sur des méthodes formelles et
des techniques d’extraction des connaissances en employant des outils linguistiques et
statiques des méthodes de classification automatique issues de la théorie de l’information ou
encore les méthodes de regroupement conceptuel qui segmentent automatiquement les textes
en unités thématiquement homogènes, et regroupant ces unités en fonction d’une mesure de
similarité fondée sur la fréquence des mots [Ferret et al., 2001]
La construction mixte ou semi-automatique, les ontologies sont construites par des techniques
automatiques tout en intégrant des méthodes permettant d’étendre des ontologies ayant été
construites automatiquement. Quel que soit le mode choisi, l’élaboration de toute l’ontologie

33
doit s’appuyer sur un certain nombre de règles qu’il est nécessaire de respecter et une
méthodologie de construction d’ontologies.

IV.1.3.1. Les principes de construction d’une ontologie

Le processus de construction d’une ontologie doit respecter certains principes de bases qui
permettent d’obtenir une ontologie susceptible de répondre aux objectifs de l’ontologie. Le
constructeur de l’ontologie, se doit donc de garder à l’esprit ces principaux critères tout au
long du cycle de développement de son ontologie [Gruber,1993] :
La clarté et objectivité : l’ontologie doit fournir le sens des termes définis en offrant des
définitions objectives ainsi que de la documentation associée en langage naturel.
L’exhaustivité : une définition exprimée par une condition nécessaire et suffisante est
préférable à une définition exprimée seulement par une condition nécessaire ou par une
condition suffisante.
La cohérence : afin de pouvoir formuler des inférences cohérentes avec les définitions.
L’extensibilité monotone maximale : les nouveaux termes, qu’ils relèvent de la langue
générale ou d’une langue de spécialité, devraient être inclus dans l’ontologie sans entraîner de
modifications dans les définitions existantes.
L’intervention ontologique minimale : intervenir le moins possible sur le monde en phase de
modélisation, L’ontologie devrait spécifier le moins possible le sens de ses termes, de façon à
ce que les parties impliquées dans l’ontologie aient les mains libres pour spécialiser et
instancier l’ontologie à leur guise.

IV.1.4. Les Ontologies et le raisonnement

La représentation des connaissances par les ontologies peut s’accompagner des mécanismes
de raisonnement. Le raisonnement concerne la manipulation des connaissances déjà acquises
pour produire de nouvelles connaissances. Il utilise des mécanismes d’inférence qui
permettent la résolution des problèmes pour lesquels il n’existe pas de procédures explicites
dans le programme. L’opération d’inférence consiste à admettre une proposition préalable qui
a la valeur Vrai. Le raisonnement, déduction, induction, etc., sont des cas spéciaux de
l’inférence. Différents mécanismes de raisonnement sont utilisés selon les objectifs du

34
système à mettre en place : raisonnement logique, raisonnement par classification, le filtrage,
l’héritage et le raisonnement à base de règles.

 Le raisonnement logique
Le raisonnement logique se base sur un mécanisme de déduction qui utilise un ensemble de
règles d’inférence pour déduire des nouveaux faits à partir des faits connus. Ces règles, le
modus ponens, le modus tollens et la spécialisation universelle sont combinées avec des
manipulations syntaxiques des formules (filtrage et unification) pour élaborer la déduction
[Masini et al., 1989]. La logique fournit un formalisme clair et non ambigu. Cette clarté vient
d’une part du fait que la signification d’une formule ne dépend que de sa structure et de la
signification donnée à ses composants atomiques et d’autres part du fait que le langage
d’expression logique est proche du langage naturel [Halton et al.,1991]. De plus les
connecteurs logiques et les quantificateurs permettent une riche description du monde. Les
inférences faites avec la logique du premier ordre sont correctes, complètes et fondées
[Stillings et al., 1989]. Plusieurs langages de formalisation d’ontologies dotés de mécanismes
de raisonnement logique sont proposés tel que OWL [OWL, 2004] .

 Le raisonnement par classification


Le raisonnement par classification consiste à confronter une nouvelle connaissance à un
ensemble de connaissances connues pour déduire des informations liées à cette nouvelle
connaissance. Dans des représentations à base de frames, la classification consiste à
positionner un nouveau schéma dans une hiérarchie de frames connue. En général les
systèmes à base de frames distinguent la classification de classes de la classification
d’instances. La classification des classes modifie les liens taxinomiques des classes et
constitue un mécanisme de gestion et de maintien de la base ; la classification d’instances est
un mécanisme de raisonnement qui permet de compléter la connaissance d’une nouvelle
instance en la plaçant correctement dans la base et en récupérant l’information déduite de ce
classement.

 Le filtrage
Utilisé par la plupart des réseaux sémantiques. Il consiste à parcourir le graphe et à chercher
tous les sous-graphes ayant des propriétés ou une structure commune avec un graphe cible.

35
 L’héritage
L’héritage est un mécanisme de raisonnement qui consiste à récupérer des informations des
classes représentant des concepts plus généraux, pour les utiliser dans des classes plus
spécialisés ; cette récupération se fait en suivant les liens de spécialisation « est-un ». La
relation de spécialisation représente l’inclusion ensembliste ; toutes les instances d’une classe
le sont aussi pour ses superclasses. Une classe doit donc pouvoir « récupérer » l’information
de ses superclasses. Le mécanisme d’héritage de propriétés permet la récupération de cette
information à travers les liens de spécialisation et évite ainsi d’avoir à recopier les attributs
des superclasses dans la sous-classe. L’héritage est dynamique, veut dire que l’information
héritée d’une classe n’est pas stockée dans la sous classe mais récupérée chaque fois que le
système accède à la sous-classe. Cela garantit que toute modification faite à une classe est
prise en compte par ses sous-classes. Le mécanisme d’héritage est plus un raccourci d’écriture
(car il évite à recopier l’information) qu’un réel mécanisme d’inférence de nouvelles
connaissances.

 Le raisonnement à base de règles


Le raisonnement à base de règles est également un mécanisme de raisonnement sur les
connaissances. L’élément de base des systèmes à base de règles est la règle d’inférence ; une
règle a la forme suivante :
Si <condition> Alors <Action>
La partie condition est exprimée par un prédicat logique correspondant à une affirmation sur
la base de connaissance qui doit être vraie au moment de valider la règle pour que l’action soit
déclenchée ; la partie action, qui est la partie exécutable de la règle indique des ajouts ou
modification à faire à la base. Un système à base de règles comporte trois parties : une base de
règles, une base de faits et un moteur d’inférence. Les systèmes à base de règles permettent en
général de bien résoudre les problèmes de diagnostic. Ils offrent un cadre déclaratif pour
exprimer des connaissances procédurales, de « savoir-faire », ce qui permet de voir clairement
les conditions dans lesquelles une règle est applicable.

36
IV.2. Taxonomie des ontologies de domaine

Il existe deux catégories d’ontologies de domaine [cullot et al., 2003, Pierra, 2003]:
Les ontologies linguistiques (OL) : les ontologies dont l’objectif est la représentation de la
signification des termes utilisés, dans un univers du discours particulier et dans une langue
naturelle donnée.
Les ontologies conceptuelles (OC) : les ontologies dont le but est la représentation des
catégories d’objets et des propriétés des objets présents dans une partie du monde.
Cependant au sein même de la catégorie des OC, les ontologies présentent des caractéristiques
très différentes selon le domaine d’application où elles sont utilisées et selon le modèle
d’ontologie avec lequel elles sont décrites qui sont :

IV.2.1. Canonicité des Ontologies Conceptuelles

Les concepts qui apparaissent dans une OC peuvent être organisé selon les deux catégories
suivantes [Gruber, 1995] :
Les concepts primitifs : sont les concepts qui ne peuvent pas avoir une définition axiomatique
complète. La définition de ces concepts s’appuie sur une documentation textuelle et un savoir
partagé avec les utilisateurs. Les concepts primitifs sont la fondation sur laquelle d’autres
concepts de l’ontologie pourront ensuite être définis.
Les concepts définis : sont les concepts pour lesquels une ontologie fournit une définition
axiomatique complète au moyen de conditions nécessaires et suffisantes exprimées en termes
d’autres concepts primitifs ou eux-mêmes définis. Cette caractéristique est la base des
mécanismes d’inférence. L’introduction de concepts définis amène donc une notion
d’équivalence conceptuelle qui permet d’exprimer de plusieurs manières différentes les
mêmes concepts. Différents constructeurs ont été proposés pour définir des équivalences
conceptuelles. Ces constructeurs peuvent s’appliquer sur les classes d’une ontologie et
peuvent également être définies sur les propriétés d’une ontologie.

37
IV.2.2. Les ontologies Conceptuelles Canoniques (OCC)

Les Ontologies Conceptuels Canoniques, est une ontologie dont les définitions ne contiennent
aucune redondance. Dans les OCC, chaque concept du domaine est décrit d’une seule façon,
en utilisant une description qui ne peut inclure que des conditions nécessaires. En
conséquence les OCC ne comportent que des concepts primitifs.

IV.2.3. Les Ontologies Conceptuelles non Canoniques (OCNC)

Les Ontologies Conceptuelles Non Canoniques sont les ontologies qui contiennent non
seulement des concepts primitifs, mais aussi des concepts définis. Les OCNC sont
particulièrement utiles lorsqu’elles sont utilisées comme schéma global de requête. En effet,
la redondance qu’elles introduisent permet d’augmenter le nombre de concepts en termes
desquels il est possible d’exprimer une requête donnée.
Les constructeurs OCNC sont également très utiles pour définir des mapping entre différentes
ontologies. Ces primitives ont une sémantique formelle qui permet d’implanter des
mécanismes dans des outils nommés raisonneur comme par exemple, RACER [Haarslev et
Moller, 2001].

IV.2.4. Ontologie Linguistiques (OL)

Les ontologies Linguistique sont les ontologies qui définissent l’ensemble des termes qui
apparaissent dans la description langagière d’un domaine. Dans cette catégorie d’ontologies,
outre les relations entre concepts représentées par des relations de subsomption, des relations
entre les termes (par exemple, la synonymie ou l’homonymie) doivent être également
définies. Les relations entre les termes étant souvent fortement contextuelles, les inférences
automatiques basées sur ces ontologies nécessitent, en général, la supervision d’un expert.
Les OL aident à reconnaître des similarités conceptuelles entre des phrases même si différents

38
termes sont utilisés. Ce processus doit néanmoins être entièrement validé par un expert
humain.

IV.2.5. Le Modèle en Oignon

L’approche proposée par Jean, [Jean, 2007] pour la conception d’une ontologie s’étale sur les
étapes suivantes :
La première étape : Elle consiste à une mise en accord au sein d’une communauté sur une
OCC et qui doit suivre les points suivants :
 Identifier clairement quel est le domaine couvert par cette ontologie en s’appuyant sur
le savoir-faire des experts du domaine ;
 Choisir un modèle permettant de définir précisément les concepts primitifs (classes et
propriétés) existant dans le domaine et permettant d’indiquer le contexte d’évaluation
des valeurs des propriétés ;
 Fournir des descriptions partagées de l’ensemble de ces concepts primitifs couvrant le
domaine considéré. Cette conceptualisation doit permettre de satisfaire des besoins
techniques et métiers larges et diversités partagés par les membres de cette
communauté. Elle doit atteindre une large acceptation et reconnaissance.
Au sein de la communauté d’utilisateurs et/ou développeurs, sur la base de l’OCC définie, une
OCNC peut être construite afin d’être utilisée par les membres de cette communauté, soit pour
construire leur propre point de vue du domaine, soit pour modéliser formellement sous forme
de classes certains concepts existants dans le domaine cible et qui s’expriment sous forme de
combinaisons de concepts canoniques.
Afin de permettre l’utilisation de l’OCNC définie pour les inférences linguistiques et/ou pour
fournir une interface utilisateur conviviale dans différents langages naturels, associer à chaque
concept de l’OCNC une liste de termes spécifiques pour une ou plusieurs langues naturelles
données.

L’analyse de cette approche à permis à Jean de définir un modèle en couche et qu’il a nommé
« modèle en oignon ». Les trois couches de modèle en oignon présentées par la (figure IV.1)
sont : OCC, OCNC, OL. Une OCC fournit une base formelle pour modéliser et échanger
efficacement la connaissance d’un domaine. Une OCNC fournit les mécanismes pour lier

39
différentes conceptualisations faites sur ce domaine. Finalement, les OL fournissent une
représentation en langage naturel des concepts de ce domaine, éventuellement dans les
différents langages où ces concepts sont significatifs.

: opérateurs d’expression de concepts OCNC à


partir de concepts OCC

: opérateurs d’expression de concepts OL à


partir de concepts OCNC ou OCC

OL OCNC
OCC

Figure IV.1 : Le modèle en oignon pour les ontologies de domaine

IV.3. Les modèles d’ontologie

La représentation d’une ontologie requiert un modèle d’ontologies qui offre les primitives
nécessaires pour exprimer les entités et relations qu’elle contient et les opérateurs pour les
traiter. De nombreux modèles ont été proposés, ils sont issus de différents champs
disciplinaires dont les principaux sont les logiques de description, la logique des frames et les
bases de données. Mais avant cela nous avons jugé nécessaire de présenter en premier lieu les
définitions des constructeurs.

IV.3.1.Les constructeurs

 Les constructeurs d’ontologie

Le constructeur d’ontologie permet de regrouper la définition d’un ensemble de concepts qui


sont des classes ou des propriétés. Une ontologie définit un domaine d’unicité des noms aussi
appelé espace de nom permettant d’identifier les concepts qu’elle définit de manière unique.

40
Elle est souvent décrite par des informations sur le fournisseur de cette ontologie. Certains
modèles d’ontologies tels que OWL fournie également des descripteurs permettant de gérer
les versions des ontologies conçues et de les décomposer en modules.

 Les constructeurs de classes

Le constructeur de classes est un mécanisme d’abstraction permettant de regrouper un


ensemble d’instances présentant des caractéristiques communes. Dans un univers particulier,
une classe est associée à un ensemble d’instances appelé son extension. Une classe a une
définition intention qui décrit le concept sous-jacent. Cette définition est généralement
composée des éléments suivants :
 Un identifiant : il permet de référencer cette classe. Cet identifiant est universel et
unique. Il est parfois complété par un numéro de version afin de gérer l’évolution des
concepts d’une ontologie.
 Une description textuelle : elle permet de rattacher une classe à une connaissance
préexistante de l’utilisateur. Une ontologie étant une conceptualisation acceptée par
une vaste communauté d’utilisateurs, elles sont souvent utilisées dans un contexte
international comme par exemple le Web. En conséquence, les définitions textuelles
associées aux concepts qu’elle définit sont souvent définies dans plusieurs langues
naturelles.
 Les classes qu’elle généralise et spécialise : Les classes sont organisées dans une
hiérarchie où elles sont liées par une relation de subsomption. La plupart des modèles
supportent l’héritage multiple ou permettent de le représenter.
Les éléments précédents permettent de rattacher une classe à un savoir préexistant partagé par
le lecteur. Ils définissent également des conditions nécessaires d’appartenance d’une instance
à une classe. Ils permettent ainsi de définir une classe primitive (concepts primitifs).

 Les constructeurs de propriété

Le constructeur de propriété permet de décrire les instances d’une classe. Les propriétés
comme les classes, possèdent toujours un identifiant et une partie textuelle éventuellement
définie dans plusieurs langues naturelles. Chacune des propriétés doit être définie sur une
classe des instances qu’elle décrit. Cette classe est le domaine de définition de la propriété.

41
Dans certains formalismes, comme par exemple RDF-Schéma, ce domaine peut être
l’intersection de plusieurs classes. Il peut également être facultatif.
Dans ce cas, le domaine de la propriété est constitué de l’ensemble des objets appartenant au
domaine visé par l’ontologie. Notons que ceci peut être représenté en définissant cette classe
implicite. Une propriété a également un codomaine qui permet de restreindre son domaine de
valeurs. Enfin, les modèles d’ontologie permettent de faire la distinction entre les propriétés
monovaluées, c'est-à-dire qui ne présentent au maximum qu’une valeur pour une instance
donnée, des propriétés multivaluées qui peuvent présenter plusieurs valeurs pour une même
instance.

 Les constructeurs de types de données

Le constructeur de type de données permet de définir le codomaine des propriétés d’une


ontologie. Les modèles d’ontologie permettent la définition de types simples, principalement
les types entiers, réel, chaine de caractères, booléen et date. Une classe peut également être
utilisée comme type de données. Dans ce cas, la valeur d’une telle propriété est l’identifiant
d’une instance de la classe formant son codomaine. Enfin, les modèles d’ontologies
permettent la définition de type collection dont les éléments sont soit d’un type simple, soit
des identifiants d’instances de classes.

 Les constructeurs d’instances

Le constructeur d’instance permet de définir l’extension d’une classe dans un certain univers.
A l’inverse de ce qui se passe pour les classes, aucun modèle d’ontologie ne fait l’hypothèse
d’existence d’un identifiant unique et universel pour les instances. En RDF-Schéma et OWL,
l’identifiant est un URI, qui peut être utilisée pour référencer cette instance en dehors de ce
système. Cependant, une instance n’a pas forcément un seul identifiant. Ainsi, un même objet
du monde réel pourra être identifié différemment dans différents systèmes.
Une instance est définie en indiquant ses classes d’appartenance, elle est également
caractérisée par un ensemble de valeurs de propriétés.
Voici les différents modèles d’ontologies orientés vers la définition des couches (OCC,
OCNC, OL).

42
IV.3.2. Modèles d’ontologies orientés vers la définition de OCC
Les modèles d’ontologies RDF-Schema et PLIB permettent de définir des OCC

IV.3.2.1. RDF/RDF-Schéma

RDF[ Manola et Miller, 2OO4] est le premier langage apparu pour définir la sémantique de
sources WEB. Sa structure est issue des réseaux sémantiques introduits dans le domaine de la
représentation des connaissances. RDF permet d’exprimer des assertions dont la structure est
un triplet (sujet, prédicat, objet).
Chaque élément de ce triplet est défini comme suit :
Le sujet : la ressource que l’on définit
Le prédicat : la propriété de la ressource qui est une liaison étiquetée et orientée du sujet vers
l’objet
L’objet : la valeur prise par la propriété pouvant être une autre ressource ou bien un litéral.
Puisque l’objet d’un triplet peut être le sujet d’un autre, les triplets peuvent être reliés entre
eux. En représentant les sujets et objets par des nœuds et les prédicats par des arrêtes, des
données RDF se représentent sous la forme d’un graphe. Au niveau sémantique, chaque triplet
exprime une assertion. En conséquence, la signification d’un tel graphe est l’ensemble de ces
assertions.
RDF n’introduit que très peu de prédicats prédéfinis, c’est pourquoi il a été rapidement étendu
par un ensemble de constructeurs permettant la définition d’ontologies. Cette extension de
RDF porte le nom de RDF-Schéma [Brickley et Guha, 2004].

La (figure IV.2) permet d’illustrer les principaux constructeurs utilisés pour modéliser la
sémantique de RDF/RDFS d’un domaine.

43
Rdfs :Literal Rdfs :Resource Rdfs :Label
s
t
t t
t
s Rdfs :Comment
Rdfs :Class t t

Rdf :Property t
t
t Rdfs :isDefinedBy
Rdfs :ConstraintRessource s t t
t
s Rdfs :Type Rdfs :SeeAlso
s

Rdfs :ConstraintProperty
t t Rdfs :SubClassOF
t

Rdfs :range Rdfs :domain Rdfs :subPropertyOf


t s

s = rdfs :subClassOf
Rdfs :ContainerMembershipProperty t= rdf:type

Figure IV.2 : Extrait du méta-modèle RDF [ 9]

Les constructeurs (relations ou prédicats) introduits par RDF-Schéma sont les suivants :
Constructeurs de classes :
rdfs :Class permet de définir des classes
rdfs :subClassof permet d’organiser les classes dans une hiérarchie dont les liens sont des
relations de subsomption.
Rdfs :label et rdfs :comment permettent respectivement de donner des noms aux classes et de
les décrire de façon textuelle.

Constructeur de propriétés :
rdfs :domain et rdfs :range permettent respectivement de définir le domaine et le codomaine
d’une propriété RDF(rdf :Property). Le domaine d’une propriété RDF-schéma est optionnel.
Un domaine peut être défini par une ou plusieurs classes.

[9] : http://www.w3.org/TRrdf-schema/, 2002

44
Si plusieurs classes sont utilisées, le domaine est composé des instances qui appartiennent à
l’intersection de ces classes. La définition du codomaine d’une propriété est similaire à celle
de son domaine à part qu’en plus des classes, des types de données sont disponibles pour le
définir. Comme les classes, les propriétés peuvent être d’une part décrites de façon textuelle
en utilisant rdfs :label et rdfs :comment et sont, d’autre part, organisées dans une hiérarchie
par des liens de subsomption en utilisant rdfs :subPropertyof.

Constructeur de types de données : Les valeurs d’une propriété peuvent être des instances de
classes ou des littéraux. Ces littéraux peuvent être typés en utilisant les types prédéfinis de
XML-Schéma. Ceci permet par exemple de représenter des valeurs de types chaine de
caractères, numériques ou date. Par ailleurs, RDF-Schéma fournit également des types
collections (rdfs :container) et il propose des constructeurs pour construire différentes sortes
de collections et en particulier les liste(rdfs :List) et les sac(rdf :Bag).

Constructeur d’instances : Les instances sont définies, en RDF par deux types de triplets. Les
triplets de la forme (i,rdf :type,c) indique que i est une instance de la classe c. Les autres
triplets de la forme (i, p, v) caractérisent l’instance i par la valeur v pour la propriété p.

IV.3.2.2. Le modèle PLIB

PLIB (Pats Libraty) [ISO1358425, 2004], son objectif était de permettre une modélisation
informatique des catalogues de composants industriels afin de les rendre échangeables entre
fournisseurs et utilisateurs. Un tel catalogue propose une classification des classes de
composants industriels représentés, ainsi qu’une description de toutes les propriétés
s’appliquant à celles-ci. En conséquence, un catalogue contient à la fois une ontologie
permettant de représenter une partie des concepts présents dans un domaine inclus dans celui
des composants industriels et des instances de cette ontologie.
Le modèle PLIB permet de créer des OCC avec les constructeurs suivants :
Constructeur de classe : « item_class » pour définir des classes.
Constructeur de propriétés : « non_de_pendent_pdet »
Constructeur de types de données : « class_instance_type » permet d’utiliser une classe
comme un type de données.

45
Constructeur d’instances : Les classes de définition (item_class) contiennent les propriétés
essentielles d’une classe

IV.3.3. Modèles d’ontologies orientés vers la définition de OCNC

Les modèles d’ontologies permettant la définition de OCNC fournissent des constructeurs


pour construire des concepts définis dans une ontologie à partir d’autres concepts primitifs
et/ou définis. Les modèles OWL et F-Logic offrent cette construction de différentes manières.

IV.3.3.1. OWL

OWL est un langage d’ontologie web appartient à la famille W3C liées au Web Sémantique.
Une ontologie OWL est composée d’un en-tête, d’axiomes et de faits. L’entête représente des
méta-données, les axiomes permettent de définir des concepts ou des relations et les faits sont
des instances dont les propriétés sont renseignées.
Un objectif important de OWL est d’assurer que les raisonnements qui peuvent être réalisés
sur des ontologies conçues avec un sous-ensemble de ce langage soit décidables.
L’impossibilité d’obtenir un langage à la fois compatible avec RDF-Schéma et dont les
raisonnements associés soit décidables a poussé les concepteurs de OWL à en spécifier trois
versions : OWL Lite, OWL DL et OWL Full. Ces trois versions offrent une expressivité
croissante (OWL Lite puis OWL DL puis OWL Full). Les raisonnements associés à OWL
Lite et OWL DL sont décidables mais ne sont pas compatibles avec RDF-Schéma. OWL Full
est compatible avec RDF-Schéma mais les raisonnements associés ne sont pas forcément
décidables.
La figure suivante illustre les principaux constructeurs utilisés par OWL Lite, il réutilise les
constructeurs de RDFS tel que class, Property, Subclassof, subpropertyof, domain , range.

46
Figure IV.3 : Extrait du méta-modèle OWL Lite [ Izza, 2006]

Constructeurs d’ontologies : OWL permet de construire une ontologie comme étant un


ensemble de définitions de classes et de propriétés regroupées dans un ou plusieurs espaces de
noms. OWL fournit de nombreux attributs permettant de caractériser une ontologie
owl :versionInfo qui indique son numéro de version.

Constructeurs de classes :
owl :class permet de définir des classes, chaque classe est identifiée par un URI, elle est
décrite de façon textuelle comme une classe RDF-Schéma (rdfs :label et rdfs :comment). Ces
classes peuvent être organisés dans une hiérarchie en utilisant le constructeur
rdfs :SubClassOf.
La classe owl :Thing est une classe prédéfinie, elle est la super-classe de toutes les autres
classes. Ainsi toutes les instances appartiennent à cette classe.
OWL permet aussi de définir des classes définies en fournissant des opérateurs booléens sur
les classes, les constructeurs permettant d’avoir des classes définies sont les suivants :
owl :unionof : permet de définir une classe comme étant l’union de plusieurs classes.

47
owl : intersectionof : permet de définir une classe comme étant l’intersection de plusieurs
classes
owl :complementof : permet de définir une classe comme étant le complémentaire d’une
autre classe
owl :allvaluesFrom : permet de définir une classe comme étant l’ensemble des instances qui
ne prennent comme valeur d’une propriété que des instances d’une classe donnée
owl :someValuesFrom : permet de définir une classe comme étant l’ensemble des instances
qui prennent comme valeurs d’une propriété au moins une instance d’une classe donnée.
owl :hasValue : permet de définir une classe comme étant l’ensemble des instances qui
prennent une certaine valeur pour une propriété donnée.
owl :oneOf : permet de définir une classe en extension, c'est-à-dire en indiquant la liste de ses
instances.

Constructeur de propriétés :
owl :ObjectProperty permet de définir des propriétés (relations), le codomaine des propriétés
est une classe
owl :DatatypeProperty permet de définir une propriété dont le codomaine est un type de
données. Quelque soit son type, une propriété est définie comme une propriété RDF-Schéma,
c'est-à-dire par un domaine (rdfs :domain) qui peut être l’intersection de plusieurs classes, par
un codomaine (rdfs :range).
(rdfs :subPropertyof) permet d’organiser les propriétés en hiérarchie

Les constructeurs permettant de qualifier une propriété sont :


(owl : inverseof) deux propriétés peuvent être définies comme étant l’inverse l’une de l’autre
(owl :symmetricProperty) une propriété est définie comme étant symétrique
(owl :TransitiveProperty) une propriété est transitive
(owl :InversefunctionalProperty) une propriété est injective
(owl :Functional-Property) une propriété est définie comme étant une fonction

Constructeur de types de données : Le type de donnée d’une propriété owl :DatatypeProperty


peut être le type RDF-Schéma rdfs :Literal ou un des types simples définis pour les XML
Schéma dont la liste est donnée dans [Smith et al., 2004].

48
Constructeur d’instances : Comme pour RDF-Schéma, une instance OWL est définie en
utilisant le constructeur rdf :type, elle est identifiée par un URI et peut appartenir à plusieurs
classes non liées par la relation de subsomption. Une instance est caractérisée par un ensemble
de valeurs de propriétés.

Constructeur d’axiomes : OWL permet de préciser le nombre de valeurs qu’une instance peut
prendre pour une propriété donnée grâce aux axiomes owl :mincardinality, owl :cardinality,
owl :maxcardinality.
L’axiome owl :equivalentclass indique que deux classes sont équivalentes,
l’axiome owl :disjointwith indique que les extensions de deux classes données sont disjointes,
pas d’instances en communs. OWL permet d’indiquer que deux propriétés sont équivalentes,
c'est-à-dire qu’elles présentent des valeurs pour les mêmes instances et que ces valeurs sont
identiques pour les mêmes instances, par l’axiome owl :equivalentproperty.
Les axiomes owl :sameas, owl :differentFrom et owl :Alldifferent permettent d’indiquer
l’égalité ou l’inégalité des instances car OWL ne fait pas l’hypothèse d’unicité des noms qui
consiste à considérer que les identifiants permettent d’identifier de manière unique un élément
dans une ontologie.

IV.3.3.2. F-Logic

F-Logic (Frame Logic) [Kifer et al.,1995] est un langage de modélisation des connaissances
qui combine aussi bien les frames que la logique de premier ordre. Il permet de représenter
des connaissances avec les éléments suivants : concepts, taxonomies, relations, axiomes et
règles de déduction. Il possède un moteur d’inférence Ontobroker, qui peut être utilisé pour
dériver de nouvelles connaissances. Les constructeurs fournis par ce langage sont les
suivants :

- Constructeur de classes : F-logic permet de définir des classes. Ces classes peuvent être
organisées dans une hiérarchie en utilisant l’héritage multiple en utilisant l’opérateur ( ::) . Les
classes ne sont pas identifiées de manière universelle comme les espaces de nom en OWL.

49
- Constructeur de propriétés : F-Logic permet de définir des propriétés monovaluées et
multivaluées. Ces propriétés doivent être définies en même temps que leurs classes de
définition, il permet également de définir des méthodes.

- Constructeur de type de données : Les types de données sont utilisés en f-Logic pour définir
le codomaine des propriétés ainsi que les arguments d’une méthode. F-Logic permet d’utiliser
des types primitifs (integer, real, string et date) et les classes comme type de données. Il
supporte les collections de type ensemble.

- Constructeur d’instances : Une instance F-Logic est caractérisée par les classes auxquelles
elle appartient ainsi que ses valeurs de propriété. Permet qu’une instance soit traitée comme
une classe et ainsi elle peut avoir des instances. Cette capacité est qualifiée de méta-
modélisation.

- Constructeur de règles : Pour offrir des capacités déductives, F-Logic est équipé d’un
langage de règles. La règle se présente sous la forme coclusion →precondition , la
precondition est le corps de la règle, la conclusion est la tête de la règle : permet de trouver
l’appartenance d’une instance à une classe, etc… L’exécution d’une règle consiste à
rechercher les valeurs des variables qui permettent de satisfaire la precondition. Les faits
déduits sont ceux obtenus en remplaçant les variables de la conclusion par les valeurs qui
satisfont la précondition.

IV.3.4. Les constructeurs pour les OL

Une OL permet de définir des relations linguistiques entre termes telles que la synonymie,
l’homonymie, l’hyperonymie ou l’hyponymie. Ce type d’ontologie est surtout utile pour les
applications d’analyse de corpus de document ou d’indexation des documents par les
éléments de l’ontologie conceptuelle

Dans les différents modèles d’ontologie présentés, les classes comme les propriétés peuvent
être associées à une ou plusieurs descriptions textuelles. En RDF-Schema et OWL, cette
description est optionnelle et définie par rdfs :label et rdfs :comment.

50
RDF-Schema et OWL supportent aussi le multilinguisme en permettant que les valeurs
d’attributs et de propriétés de type texte puissent être définies dans plusieurs langues
naturelles. Dans ces modèles d’ontologie, le multilinguisme est aussi disponible pour décrire
les ontologies et les données.
Exemple xml : lang= ‘fr’ , xml :lang=’en’

Et les relations entre les mots utilisées dans une ontologie linguistique sont :

la synonymie : deux termes ont une signification identique


l’homonymie : deux termes ont la même forme orale ou écrite mais des sens différents
l’antonymie : deux termes ont un sens opposé
la similarité : deux termes ont un sens proche
l’hyperoymie (respectivement l’hyponymie) : un terme à son extension qui englobe
(respectivement est inclus dans) l’extension d’un autre terme.

Conclusion

En conclusion, les modèles sélectionnés pour notre système sont RDF, RDF-Schéma et OWL
et parmi les constructeurs présentés ci-dessus, il y en a qui vont permettre d’enrichir la
sémantique des données ou de résoudre le problème d’hétérogénéité sémantique des données
issues de différents systèmes que nous allons présenter dans le chapitre suivant.

51
CHAPITRE V : DEVELOPPEMENT DE L’ONTOLOGIE
TURBINE A VAPEUR

52
Dans le chapitre précédant nous avons présenté les éléments constitutifs d’une ontologie de
domaine avant d’expliciter dans ce chapitre la notion d’ontologie à travers la description du
processus conduisant à son développement.

Le processus de construction peut être découpé en trois phases dans le cas d’une ontologie
opérationnalisée. Ce processus n’est pas séquentiel, des allers-retours entre les différentes
phases du processus sont à prévoir.

V.1. PROCESSUS GENERAL DE DEVELOPPEMENT DE


L’ONTOLOGIE

Le processus général de construction d’ontologies [ Furst, 2004] illustré par la (figure V.1),
peut être défini par les étapes suivantes :

 La Conceptualisation : C’est l’identification des connaissances contenues dans un


corpus représentatif du domaine considéré. Ce travail doit être mené par des experts
du domaine assisté par un ingénieur de connaissance, apportant son expertise de
paradigmes de représentation des connaissances en machine pour aider à la
structuration des connaissances ;

 L’Ontologisation : C’est la formalisation, autant que possible, du modèle conceptuel


obtenu à l’étape précédente. Une part des connaissances du domaine peut, à ce niveau,
être abandonnée, du fait de l’impossibilité de lever certaines ambigüités, ou du fait des
limitations de l’expressivité du langage de représentation d’ontologie utilisé. Ce travail
doit être mené par l’ingénieur de la connaissance, expert du modèle formel de
représentation de l’ontologie, assisté de l’expert du domaine ;

 L’Opérationnalisation : C’est la transcription de l’ontologie dans un langage formel


et opérationnel de représentation des connaissances. Ce travail doit être mené par
l’ingénieur de connaissances.

53
Formel ou
Informel ou semi-formel Formel Opérationnel

Modèle
Données Conceptuel Ontologie
Brutes conceptualisation Ontologie Opérationnelle
corpus

Conceptualisation Ontologisation Opérationnalisation

Figure V.1 : Construction d’une ontologie opérationnelle

De nombreux outils de construction d’ontologies utilisant des formalismes variés et offrant


différents fonctionnalités ont été développés :

 Les outils orientés conceptualisation


 Les outils orienté ontologisation
 Les outils orienté opérationnalisation

V.1.1. Les outils orientés conceptualisation

Ces outils sont essentiellement dédiés à l’extraction, à partir de documents, des concepts du
domaine et des relations existantes entre eux, mais offrant également des fonctionnalités de
structuration permettant de bâtir de véritables ontologies. Voici quelques exemples :

 TERMINAE[10] : développé au LIPN de l’université Paris-Nord, permet à


travers de l’outil d’ingénierie linguistique LEXTER, d’extraire d’un corpus
textuel les candidats termes d’un domaine.

 TEXT-TO-ONTO[11] : développé à l’Institut AIFB de l’université de


Karlsruhe, offre les mêmes fonctionnalités d’extraction d’ontologie à partir de
corpus ou de document Web, mais en utilisant des ontologies existantes.

 ONTOBUILDER[12] : développé au Technion d’Haifa, permet de bâtir une


ontologie à partir de ressources Web, autorise même la fusion d’ontologies
extraites de différents sites Web.

L’outil adopté pour construire l’ontologie turbine à vapeur permet l’extraction des concepts
et les instances à partir de sources structurées telle que les bases de données relationnelles,

54
c’est le plug-in DataMaster du Protege. Il permet d’intégrer le contenu d’une base de données
ou plusieurs bases de données dans Protégé via une connexion ODBC ou JDBC.

V.1.1.1. Data-Master

Data-Master est développé pour répondre à certains exigences tels que enrichissement
sémantique des données, intégration ou l’interopérabilité des bases de données que ce soit
syntaxique ou sémantique [Nyulas, 2007]

Il a été développé après le plug-in DataGéni [13] qui permettait l’extraction de base de
données relationnelle dans Protege Frame uniquement, ce dernier est limité et ne peut pas
répondre à notre approche pour intégrer plusieurs bases de données en une seule ontologie
avec des espaces de noms différents aussi l’absence des constructeurs OWL ne nous permet
pas de résoudre le problème d’hétérogénéité sémantique entre les données.

Data-Master permet l’extraction de schéma et le contenu d’une ou plusieurs bases de données


relationnelles dans une ontologie ou plusieurs ontologies séparées en les éditant dans Protege
Frame ou Protege OWL selon le choix de l’utilisateur.

V.1.2. Les outils orientés ontologisation

Plusieurs outils ont été développé, on cite comme exemple OntoEdit (ontology Editor) [Sure
et al., 2002] et ontolingua [Farquhar et al., 1997]. Nous avons opté pour Protégé 2000 et notre
choix s’est imposé du fait que DataMaster permettant l’extraction des concepts et des
instances à partir des bases de données est un plug-in de l’éditeur Protege.

V.1.2.1. Protege

Protege [14], est une interface modulaire, développé au « standford Medical Informatics de
l’université de standford », permettant l’édition, la visualisation, le contrôle (vérification des
contraintes) d’ontologies.
Protégé est un outil supportant la création, la visualisation et la manipulation d’ontologie, en
les exportant sous plusieurs formats de représentation tel que RDFS, OWL. C’est un éditeur
d’ontologie fournissant un environnement de « plug-in » (tels que ceux permettant
l’utilisation de RACER, JessTab, DataMaster,..) qui facilitent le raisonnement sur
l’ontologie, l’extraction des données, etc.

[ 10]: http://www.lipn.univ-paris13.fr/ szulman/Terminae.html


[11]: http ://km.aifb.uni-karlsruhe.de/kaon2/frontpage
[12] :http://iew3.technion.ac.il/Ontobuilder
[13] : DataGenieTab http://protege.stanford.edu/plugins/datagenie
[14]: Protege, Protege 2000 Ontology Editor Home page, http://protege.stanford.edu/, 2002

55
L’éditeur « Protégé-OWL » permet aux utilisateurs de créer des ontologies en utilisant le Web
Sémantique en particulier OWL. Pour OWL, une ontologie peut inclure des descriptions de
classes, propriétés, leurs instances et la sémantique associée entre concepts tel que (union des
classes, symétrie d’une classe etc.).
Dans sa dernière version, il propose également un moteur SPARQL, dont l’objectif est de
fournir un protocole et un langage de requête similaire à SQL, mais adapté à RDF.

V.1.3. Les outils orientés opérationnalisation

Il existe plusieurs outils permettant l’exploitation de l’ontologie, on cite quelques exemples


parmi d’autres :

V.1.3.1. Les moteurs d’inférence

Racer: Le système Racer ( Renamed Abox and Concept Expression Reasoner ou raisonneur
d’expression de concepts et de Abox) est un système de représentation de connaissance pour
le calcul sur la logique de description. Ce moteur d’inférence très connu, il possède son
propre langage de requête nRQL( new Racer proQuery Language) pour interroger l’ontologie
sur la logique de description. Racer peut être utilisé dans Protégé pour raisonnement et
contrôle de consistance de l’ontologie afin d’obtenir une ontologie cohérente.

Jena [15] : est un Framework (de HPsociété), c’est un cadre de travail java open source
permettant de construire des applications de Web Sémantique, elle fournit un environnement
de programmation pour RDF, RDFS et OWL ainsi qu’un moteur d’inférence basé sur les
règles. Utilise RDQL(RDF Data Query Language) qui est un langage d’interrogation du RDF.

Sesame[16] : est un outil permettant de stocker des ontologies au format RDFS ainsi que des
fichiers d’instances des ontologies au format RDF. Il permet aussi d’interroger une ontologie
en utilisant le langage RDQL.

JESS[17]: est un moteur d’inférence en Java. Il utilise le langage Clips pour raisonner. Il ya
deux types de licence de JESS, un gratuit pour la recherche et l’autre commercial. JESS peut
être utilisé dans Protege grâce au plug-in JESSTab pour raisonner sur les instances de
l’ontologie. Les requêtes sont représentées par des règles spéciaux de JESS, le langage de
requête est puissant parce qu’il respecte la clause de Horne. Il permet d’écrire les requêtes sur
les instances et les concepts en utilisant des API java.

Ontobroker[18]: moeur d’inférence d’ontologie composé de trois éléments :


 Une interface de requête
 Un moteur d’inférence
 Et un webcrawler (ontocrawler)
Le langage de requête est orienté vers la présentation basé sur Frame-logique (F-logic).

[15] : http:// Jena.sourceforge.net


[16]: http://sesame.administration.nr
[17]: http://herzberg.ca.sandia.gov/jess/
[18]: http://www.ontoprise.de

56
V.1.3.2. Les langages d’interrogation d’ontologie

Plusieurs langages ont été proposés dans le contexte du web sémantique. Il existent des
langages qui sont conçus pour le formalisme RDF exemple SPARQL [Prud’hommeaux et
seaborne, 2006], d’autres sont conçus pour le modèle RDF-Shéma exemple RQL
[Karvounarakis et al., 2002] et peu de langages conçus pour OWL exemple OWL-Ql [Fikes et
al., 2004].

1) SPARQL (SPARQL Protocol And RDF Query Langage ) est une amélioration du
langage RDQL [searbone, 2004] :
 Utilise la représentation générique des informations ( ensemble de triplets)
 Ne prend pas en compte la sémantique des constructeurs d’ontologie
 Langage puissant pour l’interrogation des triplets RDF, sa syntaxe est simple,
nous présentons ci-dessous quelques requêtes de ce langage.
Les requêtes CONSTRUCT permettent de créer de nouveaux triplets à partir du résultat
d’une requête ;
Les requêtes DESCRIBE permettent d’obtenir la description d’une ressource donnée. Les
spécifications de SPARQL ne précisent pas la nature de la description d’une ressource. Elles
imposent seulement que cette description soit un sous-ensemble du graphe interrogé.
Les requêtes ASK retournent un booléen indiquant si la requête a une solution ou pas.
La requête SELECT se présente sous la forme :
PREFIX namespace List
SELECT variables List
[From Source RDF List]
Where graph Patern
[ORDER BY explist]

La clause PREFIX permet d’indiquer des alias sur les espaces de noms utilisés dans la
requête.
La clause FROM permet d’indiquer la ou les ressources RDF interrogées.

La clause WHERE est constituée d’un ensemble de triplets pouvant contenir des variables
(préfixées par ?) un interpréteur de requêtes SPARQL recherche les valeurs de ces variables
pour lesquelles les triplets de la clause WHERE sont inclus dans le graphe RDF interrogé. Il

57
retourne le sous ensemble de ces valeurs correspondant aux variables spécifiées dans la clause
SELECT. Ce résultat peut être trié en spécifiant des expressions dans la clause ORDER BY.
SPARQL permet d’indiquer des conditions sur les variables utilisées dans la requête. Ces
conditions sont définies dans la clause WHERE grâce à l’opérateur FILTER.
SPRQL dispose également de l’opérateur UNION pour joindre deux ensembles de triplets
dans la clause WHERE.

2) NRQL (new Racerpro query language) [Haaslev, et al., 2001] est un langage
d’interrogation de Racer. Comme SPARQL, c’est un langage basé sur la recherche
de graphes RDF et sa syntaxe lui est proche.

3) RQL [Karvounarakis et al., 2002] est un langage conçu pour RDF-schéma


permettant ainsi d’interroger la sémantique de RDF-schéma tels que « subclass »,
il utilise la représentation qui fait la distinction entre l’ontologie et les instances.

4) OWL-QL [Fikes et al., 2004] : est un langage qui ne propose pas les
constructeurs spécifiques à OWL et son pouvoir d’expression est inférieur à celui
de SPARQL et RQL.

V.1.3.3. La représentation des connaissances

Il existe deux approches de représentation des connaissances adoptées par les outils
d’interrogation à savoir :

 La représentation par triplet ou représentation générique : Cette représentation consiste


en un ensemble de triplets (sujet, prédicat, objet). Chaque élément d’une ontologie est
ainsi défini par les triplets suivants :
 Le triplet (élement, rdf-Schéma :type, entité) qui permet d’indiquer le
type de l’élément. Ce type est un des entités définies en RDF-Schéma ou
OWL comme par exemple owl :class ou rdfs :property ;
 Les triplets (élément, attribut, valeur) qui permettent de caractériser
l’élément défini en lui assignant des valeurs d’attributs RDF-Schéma
comme par exemple rdfs :label ou rdfs :comment rdfs :Description-
symptôme.
Cette représentation est utilisée par Jena. Elle a l’avantage de faire évoluer le
modèle d’ontologie mais ne permet pas une prise en compte de la sémantique des
constructeurs d’ontologie.

 La représentation par séparation ontologie/contenu ou ontologie/instances: elle


consiste en une représentation du modèle d’ontologie dans le modèle relationnel ou
relationnel-objet supporté par un SGBD. Cette représentation est utilisée par Sesame,
elle a pour avantage la prise en compte de la sémantique des constructeurs
d’ontologie, mais le modèle d’ontologie reste figé.
Elle comporte les tables suivantes :

58
 Class : permet de stocker les classes des ontologies
 SubClassOf : permet de stocker la hiérarchie des classes en indiquant pour
chaque classe ses super-classes
 Property : permet de stocker les propriétés

V.2 APPROCHE GENERALE PROPOSEE

Etant donné que les données concernées par la Turbine à vapeur sont déjà stockées dans des
bases de données relationnelles qui diffèrent dans leur contexte d’utilisation, et pour ne pas
perdre du temps dans une construction manuelle de l’ontologie sachant que le nombre de
composant est très important ( plus de 2000 composants). Nous avons opté pour une
construction semi-automatique et ceci par l’extraction des concepts et des instances à partir
des bases de données relationnelles existantes.

Comme on a cité ci-dessus, un outil permettant l’extraction des données à partir de plusieurs
bases de données relationnelles en une seule ontologie avec des espaces de nom différents est
le plug-in Data-Master de Protege.

Une fois le contenu des bases de données est dans Protégé faisant partie d’une même
ontologie, d’autres opérations peuvent être effectuées pour étendre et compléter l’ontologie
afin de :
 Enrichir la sémantique des données issues des bases de données
 Résoudre le problème d’hétérogénéité structurelle et sémantique entre les données, et
ceci pour permettre un échange de données efficace et cohérent entre les deux
systèmes.

Rappelons que notre but ne se limite pas à construire une ontologie, mais aussi à permettre
une exploitation efficace et opérationnelle que ça soit par les utilisateurs ou par les systèmes
informatiques existants à travers les bases de données.

Protégé permet de générer le code OWL de l’ontologie finalisée, ce code va à son tour être
traduit en faits de JESS en utilisant l’outil OWL2JESS, et qui va permettre d’obtenir une base
de faits supportant toute la sémantique de OWL. Par ailleurs des règles seront formulées en
JESS, appliquées au moteur d’inférence JESS pourra inférer de nouveaux faits afin d’enrichir
la base des faits ou répondre à toute requête pour exploiter l’ontologie. Ce système pourra
être utilisé par les acteurs de maintenance via une interface qui l’assistera ainsi La réponse
fournie par le moteur d’inférence pourra être exploitable par l’utilisateur ou sera stockée dans
une base de données.

L’exploitation des connaissances via cette interface consiste à retrouver dans la base des faits,
les connaissances préalablement capitalisées ou en déduire d’autres grâce à l’intégration du
moteur d’inférence JESS. Il s’agit donc d’une approche plus intelligente qu’une recherche
simple et classique.

En employant cette ontologie, le processus de recherche d’information intègre une dimension


sémantique, mais aussi un mécanisme de raisonnement. L’exploitation de cette ontologie
contribue à améliorer le processus de recherche d’informations, notamment pour l’échange de
données entre les systèmes intégrés. L’approche proposée est illustrée par la figure suivante :

59
SYSTEME PROPOSE
BD1 BD2

DATA
MASTER

PROTEGE 2OOO
ONTOLOGIE
BASE DES
REGLES
CODE
OWL

OWL2JESS RErrrRESULTATS

BASE DES RESULTATS BD


FAITS
JESS

Figure V.2 : Approche générale proposée

Dans ce contexte, nous avons conçu une mémoire d’entreprise pouvant s’interfacer avec les
utilisateurs et les bases de données existantes. L’utilisateur pourra interroger simultanément
des connaissances issues des différentes sources de données concernées (intégrées dans
l’ontologie) via une interface commune. L’objectif de cette interface est d’offrir à l’utilisateur
un accès assisté aux connaissances tout en assurant une transparence de la façon dont les
connaissances sont représentées. Et puisque les requêtes sont formulées en JESS, cette
interface permet donc à l’utilisateur d’exploiter les connaissances sans pour autant connaître
le langage JESS.

V.3. CONSTRUCTION DE L’ONTOLOGIE « TURBINE A VAPEUR »

La construction de l’ontologie « Turbine à Vapeur » s’est déroulée selon le processus général


de construction d’une ontologie ainsi défini par [Furst, 2004].

V.3.1. Conceptualisation de l’ontologie Turbine à Vapeur

La conceptualisation de l’ontologie Turbine à vapeur est inspirée de la conceptualisation


d’ontologie basée sur le modèle en oignon proposé par [Jean,2007], et donné par la (Figure
IV.1), Les auteurs ont fait une étude sur les liens entre le modèle en oignon et les bases de
données. Nous présentons un résumé de cette étude dans ce qui suit.

60
V.3.1.1. Conceptualisation d’ontologie basée sur le modèle oignon

Chaque couche du modèle en oignon peut être utilisée pour résoudre différents problèmes des
bases de données :
 La couche de l’ontologie conceptuelle canonique (OCC) : représente des
modèles conceptuels formels et partageables. Ils peuvent être utilisés comme
base pour la conception d’un modèle logique de base de données ou comme
schéma global dans un scénario d’intégration de bases de données.

 La couche de l’ontologie conceptuelle non canonique (OCNC) : propose des


mécanismes similaires aux vues des bases de données, avec une théorie
formelle offrant des capacités d’inférence. Ces mécanismes peuvent être
utilisés pour réaliser le mapping entre différents schémas de bases de données.

 La couche de l’ontologie linguistique (OL) : peut être utilisée pour localiser les
similitudes existantes entre plusieurs schémas de bases de données, pour
documenter les bases de données ou pour enrichir le langage de dialogue
(plusieurs langues).

Et pour montrer l’intérêt du modèle en oignon, ils ont présenté un exemple d’un scénario
d’échange basé sur une ontologie conçue selon ce modèle.

Scénario d’échange basé sur une ontologie en couche

Dans l’univers des bases de données, chaque base de données utilise un vocabulaire
canonique qui peut être différent l’un de l’autre. Ainsi le scénario d’échange basé sur une
ontologie en couches consiste à échanger des données entre différentes sources de données
utilisant un vocabulaire canonique différent.
Le modèle en oignon suggère que tous les échanges soient effectués en utilisant une OCC
consensuelle (concevoir une ontologie pour le consensuel). Chaque source de donnée contient
simplement les descriptions de ses propres concepts en terme de concepts primitifs de la
OCC.
Cela revient à dire qu’il faut concevoir une ontologie par source de données ne contenant que
les concepts primitifs de cette dernière. Donc si on a quatre sources, il faut établir quatre
ontologies. Puis concevoir une ontologie consensuelle contenant le consensus de concepts
primitifs de toutes les sources de données. Cette solution requiert des mappings entre les
différentes ontologies, ces mappings représentent les opérateurs d’expression des concepts
OCNC à partir des OCC.
Ceci est illustré par la figure suivante.

61
OCC OCC
S1 S2

OCC consensuel

OCC OCC
S3 S4

Figure V.3 : Utilisation de plusieurs ontologies pour l’échange canonique de données

: opérateurs d’expression de concepts OCNC à partir de concepts OCC ( mapping entre les
ontologies.

Ce scénario et la démarche de conception proposés dans la section précédente montrent


l’intérêt d’articuler les trois catégories d’ontologies selon le modèle en oignon tout au long du
cycle de vie des ontologies de domaine. En effet chaque catégorie d’ontologies offre des
capacités particulières :
 Les OCC : fournissent une description canonique et précise de chaque concept
d’un domaine donné. Elles fournissent une base solide pour l’échange entre
différents sources d’informations ;
 Les opérateurs de OCNC : sont utilisés pour interagir avec ou intégrer d’autres
applications ou source ayant déjà leur propre ontologie ;
 Les OL offrent des capacités linguistiques sur l’ensemble des concepts
(primitifs et définis) du domaine.

V.3.1.2 conceptualisation de l’ontologie « turbine à vapeur » basée sur le


modèle en oignon

Pour le développement de l’ontologie turbine à vapeur, chaque couche d’ontologie va être


représentée comme suit :

 Les OCC : représente les concepts importés de la base de données ; ainsi l’extraction
des concepts de plusieurs bases de données permettra d’obtenir des sous ensemble de
OCC, un sous ensemble par source de données. Chaque sous ensemble offrira les
mêmes capacités formulées par Jean telles que :
 la description canonique de chaque concept de la source de données
 la base solide pour l’échange entre les différentes sources
 Les OCNC : Dans ce cas les OCNC vont être utilisées pour l’échange entre les
différents sous ensemble du OCC.

Chaque base de données source va représenter un sous ensemble de l’OCC exemple OCCS1
pour la première source et OCCS2 pour la deuxième source. Autrement dit en intégrant les
bases de données sources en une seule ontologie, le vocabulaire canonique de chaque base de

62
données devient un sous-ensemble de l’OCC consensuel. L’idée proposée est d’implémenter
les bases de données en une seule ontologie, avec des espaces de nom différents permettant de
référencer chaque source de données séparément.

Les opérateurs OCNC vont se limiter dans notre cas à l’insertion des constructeurs OWL ou
des relations spécifiques au domaine (à créer) entre les concepts appartenant aux différentes
sources de données (différentes bases de données), ces relations entre concepts de sources
différentes vont permettre donc d’enrichir la sémantique des données pour faciliter l’échange
de données entre elles sans pour autant remédier aux mapping entre ontologies car tous les
systèmes sont intégrés en une seule ontologie. Ainsi le OCCS1 et le OCCS2 sont des sous-
ensemble du OCC « Turbine à Vapeur », le modèle en oignon pour cette ontologie est
illustré par la figure suivante :

: Est représenté par un


constructeur OWL
Ou
OCC OCC Relations spécifiques
S1 S2 A créer entre concepts
OCNC appartenant aux systèmes
différents

OL

Figure V.4 : Représentation de l’ontologie Turbine à Vapeur en modèle en oignon

L’implémentation de cette solution a été réalisée à travers le Plug-in DataMaster. L’utilisateur


doit en premier lieu créer une connexion ODBC par base de données à intégrer dans
l’ontologie donnant à chaque connexion un nom de source de données différent de l’autre.

Dans notre cas les bases de données sources sont de type Access, nous avons créer deux
connexions la première portant le nom « topo » et la seconde « diagnostic » ayant
respectivement les bases de données « centraletopo.mdb » et « diagnostic.mdb » comme
source de données.
La première base de données concerne les caractéristiques (code, description, zone,
fonction,….) des composants et la deuxième concerne les cas d’interventions où chaque cas
est défini par la cause de panne, défaut, symptôme et remède.

Les figures suivantes représentent un aperçu sur les bases de données sources.

63
Figure V.5 : Extrait de la base de données centraletopo.mdb

Figure V.6 : Extrait de la base de données diagnostic.mdb

64
DataMaster a permis d’extraire les concepts, et le contenu des tables (instances) des
différentes bases de données, après avoir mentionné le type de driver (ODBC ou JDBC,
ODBC pour notre cas) et le nom de chaque source de données (connexion).
Les tables de la base de données importée sont représentées en ontologie par des classes ou
sous-classes selon le choix de l’utilisateur.

Seulement cet outil ne permet pas d’extraire les contraintes et les règles de validation des
données, ces dernières peuvent être compléter au niveau de Protege, soit l’étape
d’ontologisation.

La figure suivante représente une capture d’écran de l’opération d’importation des bases de
données dans Protege à l’aide du plug-in DataMaster. Les bulles expliquent le déroulement
séquentiel des opérations élémentaires à effectuer avant toute importation, les flèches reflètent
les zones de DataMaster concernées par chaque opération.

65
1. Choix de driver de connexion 6. Zone permettant de visualiser la 2. Choix si l’importation se fait en
ODBC ou JDBC hiérarchie des classes telle qu’a été plusieurs ontologies séparées ou en
Mentionner la source de données choisie par l’utilisateur. Toute table une seule ontologie avec des espaces
importée apparue dans cette zone en de nom différents.
tant que classe ou sous classe

Figure V.7 : Extraction des concepts à partir des bases de données dans Data-Master

4. 5. La sélection de chaque table 3. Permet d’importer


- Les tables de la base de données activée sont permet de visualiser son contenu le contenu des tables si
visualisées dans cette zone une fois l’utilisateur tape (les instances) dans cette zone le bouton est
sur le bouton connect qui se transforme en Disconnect sélectionné par
Jusqu'à la fin d’importation de cette base de données l’utilisateur
- On peut choisir d’importer toutes les tables en une
seule opération ainsi chaque table sera transférée en
une classe
- On pourra aussi importer par partie de la base en
sélectionnant les tables à importer, ceci permettra
aussi d’assister la hiérarchie des classes au niveau de
l’ontologie à construire.

66
Une fois l’opération d’importation des deux bases de données est achevée, et après une
consultation des classes OWL, nous remarquons que les classes issues de la première base de
données sont préfixées de « db1 : » et les classes issues de la deuxième base de données sont
préfixées de « db2 : » voir la figure ci-dessous.

Figure V.8 : Extrait de l’ontologie dans Protégé 2000

Db2 :30C est un exemple de classe de la deuxième source de données, ainsi toutes les classes,
sous-classes, instances et attributs ayant le préfixe « db2 : » sont issus de la deuxième source
« diagnostic ».
Db2 :_30C_Instance1 représente la première instance de la classe 3OC et c’est aussi une
instance de la Table 3OC de la base de données diagnostic.
Db2 :_3OC.CODE_SYMPTÖME représente un attribut de la classe 30C,
CODE_SYMPTÖME représentait un champ de la Table 30C d’origine.

Db1 :30B est un exemple de classe de la première source de données ainsi toutes les classes,
sous-classes, instances et attributs ayant le préfixe « db1 : » sont issus de la première source
« topo ».

67
V.3.2. Ontologisation de l’Ontologie Turbine à Vapeur

Utilisation de l’éditeur Protege pour étendre et compléter l’ontologie soit par la création :

1. des relations spécifiques au domaine ou des constructeurs OWL entre les concepts
appartenant à la même source, insérer de nouveaux attributs ou annotations aux
classes et ceci pour enrichir la sémantique des données issues des bases de données.
2. des relations spécifiques au domaine ou des constructeurs OWL entre les concepts
appartenant aux différentes sources. Ceci permettra d’enrichir la sémantique des
données afin de résoudre le problème d’hétérogénéité sémantique entre les données
et par conséquent permettre l’échange des données entre les différentes sources.

V.3.2.1. Problèmes résolus par la création de relations entre concepts

Goh [Goh,1997] a identifié trois principales causes liées à l’hétérogénéité sémantique des
données :

 Les conflits de nom ont lieu lorsque des noms différents sont utilisés pour décrire le
même concept (synonyme) ou lorsque le même nom est utilisé pour des concepts
différents (homonyme).

 Les conflits de mesure de valeur ont lieu lorsque différents systèmes de référence sont
utilisés pour évaluer une valeur.

 Les conflits de contexte ont lieu lorsque des concepts semblent avoir la même
signification mais différent en réalité dû à différents contextes de définition ou
d’évaluation.

 Différence de modélisation des sources de données intégrées

Un extrait des modèles conceptuels des deux sources de données est présenté dans la (figure
V.9)
Dans le système topo chaque équipement et sous équipement représente un individu, la
relation lie chaque équipement à son composant élémentaire. Et chaque équipement est décrit
par son code, description, zone, famille et fonction .
Dans le système diagnostic, seul l’équipement principal représente un individu, les
équipements composants les plus élémentaires représentent des instances ( exemple : 30BA22
« Disjoncteur PPE Circulation A » est une instance de la table 30B dans le système diagnostic
alors que 30BA22 est une instance de la table 3OBA dans le système topo). Et la relation
réflexive lie l’équipement principal à son sous équipement. Chaque équipement décrit par son
code, description, peut subir une ou plusieurs interventions alors le code-défaut, description-
défaut, code-cause, description-cause, code-symptôme, description-symptôme, code-remède,
description-remède lui seront associé. Et l’équipement qui n’a subit aucune intervention ne
figure pas dans le système diagnostic autrement dit le système diagnostic ne contient que les
équipements ayants subi des interventions de maintenance.

68
Equipement-topo Equipement composant
1..*

Code Code
description Description, zone
Zone Famille, fonction Défaut
Famille
fonction Code-defaut
Description-
defaut
Equipement-diagnostic
1..* Symptôme
Code
description Code-symptôme
Description-symptôme
1..* 1..*
1..*
1..*
Tranche Cause

1..* Code-cause
Description-cause

Remède

Code-remede
Description-remede

Figure V.9 : Modèles des systèmes intégrés dans l’ontologie

 Hétérogénéité structurelle des sources de données

Les différences structurelles peuvent être regroupées dans différentes catégories :


 Conflit des types de données : attribut en entier dans l’un, il est en chaine dans l’autre ;
 Conflit des constructeurs : le concept est modélisé d’un coté comme une entité, dans
l’autre comme un attribut ;
 Conflit du nombre de constructeurs : dans un système, un attribut sert à stocker
plusieurs informations, dans l’autre système il est éclaté en plusieurs champs
 Conflit des informations représentées : pour un même concept il a des structures
différentes dans les deux systèmes ( exemple le concept Equipement qui a des
structures différentes dans les deux systèmes.

 Hétérogénéité sémantique des sources de données

 Conflit de contexte : deux concepts ont le même nom mais en réalité ils sont différents
(exemple : le concept 30B dans le système topo et diagnostic diffèrent dans le contexte
d’utilisation)
 Conflit de nom : deux concepts ont des noms différents mais en réalité, il s’agit d’un
même concept (exemple l’instance db1 :_30BA_Instance13 qui a pour
code (30BA30), desciption (Disjoncteur PPE Alimentation A), voir (Figure V.14) est

69
le même équipement dans le système diagnostic représenté par
db2 :_3OB_Instance_5, les instances diffèrent dans le nom mais en réalité on parle du
même équipement ( voir Figures V.15)
 Conflit de mesure de valeur
 Conflit de contrainte portant sur les concepts

V.3.2.2. Résolution des problèmes en utilisant les constructeurs OWL et


les relations crées

Le problème de même nom de concept mais qui diffèrent en syntaxe et en sémantique est
résolu par la différence des espaces de noms ainsi l’URI de chaque concept (intégrant l’espace
de nom) est unique pour chaque concept.

Figure V.10 : Représentation des classes issues des sources différentes préfixées différemment

Le concept 30B dans le système topo sera db1 :_30B et le concept 30B du système diagnostic
sera db2 :_30B. Les préfixe db1 et db2 ont les espaces de nom suivants (voir Figure V.11)

Les espaces de nom ont été donné par défaut où on remarque qu’il contient l’identification du
fournisseur, mais notons que ces espaces de nom peuvent être modifiés au niveau de Protege.
Voir la figure cidessous.

70
Figure V.11 : Représentation des espaces de nom

Ainsi toute classe, sous-classe ou attribut (ressource) du système topo sera doté d’une URI
contenant l’espace de nom de db1
xmlns:db1(http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#) et toute
classe, sous classe ou attribut du système diagnostic sera doté d’une URI contenant l’espace
de nom de db2
(xmlns:db2=http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:diagnostic#)

Pour permettre l’échange de données entre les deux systèmes, il va falloir résoudre aussi le
conflit de nom, ainsi le même concept peut figurer dans le premier système (portant sur les
caractéristiques) et s’il a subit une ou plusieurs interventions il va figurer dans le système
diagnostic (ayant les informations représentant le cas tel que cause de panne, symptôme,
défaut ainsi que le remède utilisé). Alors on parle du même équipement mais dans les deux
systèmes, il est représenté différemment dans l’ontologie, le problème a été réglé en créant
une relation d’équivalence entre les concepts appartenant aux deux systèmes.
La figure suivante illustre la création de la relation d’équivalence entre la classe db1 :30B et
db2 :30B. La relation est transitive ainsi s’il y aura un autre concept équivalent, il suffit de
rajouter une seule relation d’équivalence soit avec db1 :30B ou db2 :30B et non pas les deux.

71
Figure V.12 : création de la propriété objet « equivalence1 » entre db1 :30B et db2 :30B

Une fois cette relation (propriété d’objet) crée, elle apparaît pour chaque instance de la classe
concernée, il ne suffit plus qu’a rajouter l’instance équivalente de la classe appartenant à
l’autre système (voir figure ci-dessous).

Figure V.13 : Liaison des instances par « equivalence1 »

72
Figure V.14 : Représentation de l’équipement « 30BA20 » du système topo

Figure V.15 : Représentation de l’équipement « 3OBA3O » du système diagnostic

73
V.3.2.3. Les langages de formalisation de l’ontologie turbine à vapeur

Protege permet de générer le code OWL de l’ontologie, le formalisme OWL est intéressant du
fait que son mécanisme de raisonnement est basé sur la logique de description et sa syntaxe
supporté par XML/XML schéma et qui est une extension du vocabulaire de RDF/RDF
schéma (Resource Description Framework).

OWL Logique

RDF + RDF schema


Méta-données

XML + XML schema


Syntaxe

 RDF/RDF schéma
Un document RDF est composé d’un ensemble de triplets (Sujet, Prédicat, Objet). L’Objet
d’un triplet peut être le sujet d’un autre. Cette caractéristique permet de relier les triples entre
eux. Côté sémantique, chaque triplet exprime une assertion.
Syntaxe
RDF utilise le mécanisme d’URI (Uniform Resource Identifier) pour identifier Sujet, Prédicat
et Objet et plus précisément de référence par URI
exemple:
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30BT"

URI Référence

RDF schéma permet de donner le sens aux informations stockées sous la forme de triplets. Il
introduit la connaissance en définissant la notion de classe, sous-classe et instance de classe.
Ces classes sont hiérarchisées par liaison de subsomption.
Il introduit également la connaissance descriptive en définissant les Prédicats comme des
propriétés dont le domaine et le codomaine sont des classes.

74
Parmi les limites de RDF Schéma qui ont poussé à la mise au point de OWL on trouve :
Rdfs : ne permet pas d’exprimer que les classes soient disjointes ect…
Rdfs : ne permet pas de créer des classes par combinaison ensembliste d’autres classes (
insertion, union,…)

 OWL
OWL est décomposé en trois sous-langages qui proposent une expressivité croissante: Lite,
DL et Full, chacun est une extension à son prédécesseur plus simple.
OWL Lite : répond à des besoins de hiérarchie de classification et de fonctionnalités de
contraintes simples de cardinalité 0 ou 1.
OWL DL : concerne les utilisateurs qui souhaitent une expressivité maximum couplée à la
complétude du calcul (cela signifie que toutes les inférences seront assurées d’être prise en
compte) et la décidabilité du système de raisonnement (c.a.d que tous les calculs seront
terminés dans un intervalle de temps fini). Il est nommé DL car il correspond à la logique de
description.
OWL Full : Il se caractérise par une compatibilité totale avec RDF et RDF Schema. Cette
version ne permet pas la distinction entre instances et classes. Elle autorise également
l’utilisation des constructeurs OWL comme paramètres de ses constructeurs. OWL Full est
indécidable.
Voici un extrait du fichier OWL qui définit la syntaxe RDF/XML pour représenter les espaces
de nom des deux sources.

<rdf:RDF
xmlns:dbs="http://www.dbs.cs.uni-duesseldorf.de/RDF/relational.owl#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:db1="http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:db2="http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:diagnostic#"
xmlns="http://www.owl-ontologies.com/Ontology1214680546.owl#"
xml:base="http://www.owl-ontologies.com/Ontology1214680546.owl">
.
.
.

75
Elémént classe :
OWL :Thing et OWL :Nothing sont deux classes prédéfinies, toute classe OWL est une sous-
classe d’OWL :Thing et une super-classe d’OWL :Nothing. Les classes sont définie avec un
élément OWL :class (OWL :class est une sous classe de rdfs :class).

Elément propriété :
Les propriétés OWL donnent la capacité d’exprimer des faits au sujet de ces classes et de
leurs instances. OWL fait la distinction entre deux types de propriétés
_ Les propriétés d’objet qui permettent de relier des instances à d’autres instances
_ Les propriétés de type de données qui permettent de relier des individus à des valeurs
de données.
Une propriété d’objet est une instance de la classe OWL :objectProperty, une propriété de
type de données est une instance de la classe OWL :DatatypeProperty. Ces deux classes sont
elles mêmes sous-classe de la classe RDF rdf :Property.
L’extrait ci- dessous, présente la propriété d’objet crée entre la classe 30B du système topo et
la classe 30B du système diagnostic. range et domain représentent les classes concernées par
la liaison. Les propriétés mathématiques sur les éléments propriétés tel que la Transitivité
définie par (si pour tout x,y,z p(x,y) et p(y,z) implique p(x,z)) equivalent1 étant transitive.

.
</owl:TransitiveProperty>
<owl:TransitiveProperty rdf:ID="equivalent1">
<rdfs:domain rdf:resource="http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30B"/>
<rdfs:range rdf:resource="http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:diagnostic#_30B"/>
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>
</owl:TransitiveProperty>
.

76
L’extrait ci-dessous présente un exemple de propriété typée où « zone » qui est un attribut de
30BA , le type est string et le type du champ d’origine est « zone » et de type « string » aussi

</owl:FunctionalProperty>
<owl:FunctionalProperty
rdf:about="http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30BA.zone">
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
<rdfs:domain rdf:resource="http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30BA"/>
<db1:hasOrigColumnName rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>zone</db1:hasOrigColumnName>
</owl:FunctionalProperty>

L’extrait ci-dessous présente une instance de la classe 30PA et sa structure dont les
attributs (fonction, zone,..) tous de type « string ».

</db1:_30BB>
<db1:_30PA
rdf:about="http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30PA_Instance_32">
<db1:_30PA.fonction rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>TRFLUD</db1:_30PA.fonction>
<db1:_30PA.famille rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>TUYAU</db1:_30PA.famille>
<db1:_30PA.zone rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>TR30</db1:_30PA.zone>
<db1:_30PA.description rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>CDTE ALIM GAZ TORCHE N°9</db1:_30PA.description>
<db1:_30PA.code_parent rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>30PA10</db1:_30PA.code_parent>
<db1:_30PA.code rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>30PA10Z129</db1:_30PA.code>

77
V.3.3. Opérationnalisation de l’ontologie Turbine à vapeur

La représentation formelle de l’ontologie ne suffit pas pour l’utiliser dans un système


opérationnel, il faut la traduire en un langage opérationnel doté de mécanisme de
raisonnement à travers lequel le système manipulera effectivement les connaissances.
Parmi les outils d’opérationnalisation existants, le choix doit dépendre fortement des
contraintes de l’environnement technologique de l’entreprise notamment dans le contexte
d’une application industrielle telle que la maintenance industrielle.

Le moteur d’inférence adopté est JESS, son raisonnement à base de règles offre un cadre
déclaratif pour exprimer des connaissances procédurales en permettant de voir clairement les
conditions dans lesquelles une règle est applicable.

V.3.3.1. Le système Expert JESS


JESS (The Java Expert System Shell) est un environnement crée par Dr. Ernest J.Friedman-
Hill dans Sandia National Laboratoires in livermore, canada à la fin de 1990 ( dans le cadre de
Mainning Publication), écrit en java et basé sur l’algorithme Rete pour raisonner. JESS est un
langage à base de règles qui fonctionne selon le modèle des moteurs d’inférences : un
ensemble de règles s’appliquent sur une base de faits permettant d’inférer de nouveaux faits
[Friedman, 2003].
C’est un moteur d’inférence fonctionnant essentiellement en chainage avant et chainage
arrière, il implémente l’algorithme RETE pour faire le patern matching. C’est un descendant
de Clips, il est très pratique pour décrire des comportements d’agents évolués, il est possible
d’ajouter des fonctions et ainsi d’étendre les capacités du langage. Il peut être utilisé pour
écrire l’API de java et pour accéder à JavaBeans.
Parmi ses avantages on cite :
 Expressivité du langage de représentation.
 Facile à apprendre et à utiliser.
 Haute et flexibilité, stabilité et puissance
 Le mécanisme d’inférence (par défaut le chaînage avant/ chaînage arrière) est au
choix de l’utilisateur.
 Il existe plusieurs outils supplémentaires pour faciliter la programmation avec JESS :
Plug in avec Eclipce, éditeur de règle pour JESS, et des plug in de protégé pour OWL
et Jess (Jess_Tab).
 Adapté à la programmation à base de règles et objet.
 Portabilité et rapidité

78
JESS accepte le langage OWL en entrée mais ceci nécessite un outil supplémentaire
« OWL2JESS » qui a pour rôle de convertir le code OWL en faits JESS avec différents
niveaux d’expressivité pouvant être réduit à RDF2JESS ou prolongé à SWRL2JESS.

V.3.3.2. CONVERSION DU CODE OWL EN FAITS DE JESS

L’exploitation de l’ontologie et de sa formalisation en OWL présente une limitation


importante quand à l’expressivité et l’efficacité des outils de raisonnement spécifiques à OWL
tels que Racer, etc ., [Mei J., 2004] [Mei, J., 2005]], ceci se traduit par:

 Un raisonnement efficace sur une ontologie contenant un grand nombre de concepts


est une tâche lourde avec la technologie courante basée sur la logique de description.

 OWL est suffisamment riche pour être utilisé dans plusieurs situations mais il ne peut
pas être employé efficacement pour modéliser certain domaines d’application
spécifiques (tâches particulières) telle que la maintenance industrielle.

Ces limitations peuvent être surmontées en intégrant au langage OWL des règles externes
pour d’éventuelles inférences. La communauté du web sémantique et pour surmonter les
limitations des raisonneurs spécifiques à OWL a proposé l’outil OWL2JESS [Mei, I. 2005]
pour convertir le code OWL en faits de JESS.

OWL2JESS a le rôle de convertir le code OWL en faits de JESS avec différents niveaux
d’expressivité qui peut être réduit à RDF2JESS ou prolongé à SWRL2JESS.

RDF2JESS : est utilisé pour convertir le code OWL réduit en sémantique au schéma
RDF(Resource Description Framework) en faits de JESS.

SWRL2JESS: SWRL [Harrocks,et al., 2004] est un langage de règles de web sémantique qui
enrichi la sémantique de l’ontologie définie en OWL. Cet outil permet la conversion du
langage de SWRL en règles de JESS et avec SWRL.

V.3.3.2.1. OWL2JESS

Cette transformation nécessite quatre étapes pour être réalisée voir (figure V.16) :

1- Construire l’ontologie avec Protege qui nous fournit le code de cette ontologie en
OWL
2- Transformer la syntaxe XML (eXtensible Markup Language) de OWL en faits de
JESS [Klai & Khadir, 2008a] en utilisant une feuille XSLT « OWL2JESS.XSL »
[19].
3- Combiner le fichier résultat (faits de JESS) avec les règles sémantiques RDF et les
règles sémantiques OWL [19].
4- Exécuter le moteur d’inférence JESS, s’il ya des erreurs en sortie ceci est dû à une
invalidité de l’ontologie originale, ceci permettra de corriger et de raffiner l’ontologie
originale.

79
XSLT (Extended Style Sheet Langage Transformation) est un langage permettant de spécifier
des règles de transformation sur un document XML dans le but de générer un document ciblé
dérivé du
document XML.

Assertions de JESS
Protege 2000
JESS

Ontologie XSLT Règles


OWL et Faits de JESS prédéfinies
instances

Figure V.16 : Modele de OWL2JESS

 Les règles sémantiques prédéfinies

Les règles sémantiques prédéfinies sont employés pour vérifier l’uniformité pour traiter la
classification taxonomique et sémantique des caractéristiques du vocabulaire de RDF, RDFS
et OWL, ce qui permettra aux concepteurs d’ontologie d’évaluer et de raffiner l’ontologie
originale.

Un extrait des règles sémantiques qui permettent au moteur d’inférence JESS de comprendre
le sens des relations entre les concepts sont donnés dans ce qui suit. Ceci est la traduction de
la sémantique des relations en règles définies en JESS, on trouve la sémantique spécifique à
RDFS et qui est restreinte et la sémantique spécifiques au langage OWL qui est très riche et
complexe.

[19] : Mei, J., Transformation Implementation of OWL Semantic,


http://www.ag_nbi.de/research/owltrans/, 2005.

80
1- Exemple1 : La relation « subPropertyOf_transitive » dans le langage RDFS

;;; IEXT(I(rdfs:subPropertyOf)) is transitive and reflexive on IP


(defrule RDFS_semantic_conditions_subPropertyOf_transitive
(triple (predicate "http://www.w3.org/2000/01/rdf-schema#subPropertyOf") (subject ?x) (object ?y))
(triple (predicate "http://www.w3.org/2000/01/rdf-schema#subPropertyOf") (subject ?y) (object ?z))
=>
(assert (triple (predicate "http://www.w3.org/2000/01/rdf-schema#subPropertyOf") (subject ?x)
(object ?z)))
)

(defrule RDFS_semantic_conditions_subPropertyOf_reflexive
(triple
(predicate "http://www.w3.org/1999/02/22-rdf-syntax-ns#type")
(subject ?p)
(object "http://www.w3.org/1999/02/22-rdf-syntax-ns#Property")
)
=>
(assert (triple (predicate "http://www.w3.org/2000/01/rdf-schema#subPropertyOf") (subject ?p)
(object ?p)))
)

Explication :
 La première règle indique pour une relation transitive entre un sujet x et un objet y et
qu’il existe une relation entre « y » et « z » alors il faut créer une relation entre le
sujet « x » et l’objet « z ».
 La deuxième règle indique que pour une relation réflexive du sujet p qui est de type
property alors il faut créer une relation subProperty entre le sujet « p » et l’objet
« p ».

2- Exemple2 : La relation « intersectionOf » dans le langage OWL


;;; --- owl:intersectionOf ---

(defrule OWL_intersectionOf_domainrange
(triple (predicate "http://www.w3.org/2002/07/owl#intersectionOf") (subject ?x) (object ?y))
=>
(assert (triple (predicate "http://www.w3.org/1999/02/22-rdf-syntax-ns#type")
(subject ?x)
(object "http://www.w3.org/2002/07/owl#Class")
)
)
(assert (triple (predicate "http://www.w3.org/1999/02/22-rdf-syntax-ns#type")
(subject ?y)
(object "http://www.w3.org/2002/07/owl#Class")
)
)
)

81
Explication : Cette règle indique que pour une relation d’intersection entre un sujet « x » et
l’objet « y » alors il faut créer une relation de type class du sujet « x » et une autre relation de
type class au sujet « y »

V.3.3.3. Représentation des connaissances dans la base des faits

La base des faits obtenue après la traduction de OWL est représentée comme suit :

Les faits JESS sont de type triplet [Klai & Khadir, 2008b], et chaque élément d’une ontologie
est défini par les triplets suivants parmi d’autres :
- Le triplet ( type, élément, entité) qui permet d’indiquer le type de l’élément. exemple
owl :class ou rdf-schema :subclassof
- Le triplet ( attribut, élément, valeur) qui permet de caractériser l’élément défini en lui
assignant des valeurs d’attribut

Toute suite on remarque que l’ensemble des triplets sont représentés selon trois niveaux à
savoir le niveau modèle de l’ontologie, le niveau ontologie et le niveau instances. Nous
présentons ci-dessous un extrait de la base pour chaque niveau.

1) Niveau modèle de l’ontologie :

(MAIN::triple (predicate "http://www.w3.org/1999/02/22-rdf-syntax-ns#type")


(subject "http://www.w3.org/2002/07/owl#DatatypeProperty") (object
"http://www.w3.org/2000/01/rdf-schema#Class"))
(MAIN::triple (predicate "http://www.w3.org/2000/01/rdf-schema#subClassOf")
(subject "http://www.w3.org/2002/07/owl#DatatypeProperty") (object
"http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"))
(MAIN::triple (predicate "http://www.w3.org/2000/01/rdf-schema#subClassOf")
(subject "http://www.w3.org/2000/01/rdf-schema#Datatype") (object
"http://www.w3.org/2000/01/rdf-schema#Class"))
(MAIN::triple (predicate "http://www.w3.org/1999/02/22-rdf-syntax-ns#type")
(subject "http://www.w3.org/2000/01/rdf-schema#Resource") (object
"http://www.w3.org/2000/01/rdf-schema#Class"))
(MAIN::triple (predicate "http://www.w3.org/1999/02/22-rdf-syntax-ns#type")
(subject "http://www.w3.org/2000/01/rdf-schema#Datatype") (object
"http://www.w3.org/2000/01/rdf-schema#Class"))

Explication de quelques faits:

 Le premier fait indique que le type du sujet “DatatypeProperty” est “class”


 Le deuxième fait indique que « DatatypeProperty » est sous-classe de « Property »

82
2) Niveau ontologie

(MAIN::triple (predicate "http://www.w3.org/1999/02/22-rdf-syntax-ns#type")


(subject
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30P")
3)
(object "http://www.w3.org/2002/07/owl#Class"))
(MAIN::triple (predicate "http://www.w3.org/1999/02/22-rdf-syntax-ns#type")
(subject
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30PB")
(object "http://www.w3.org/2002/07/owl#Class"))
(MAIN::triple (predicate "http://www.w3.org/2000/01/rdf-schema#subClassOf")
(subject
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30PB")
(object
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30P"))
(MAIN::triple (predicate "http://www.w3.org/2000/01/rdf-schema#domain")
(subject
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30PB.descri
ption") (object
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30PB"))
(MAIN::triple (predicate "http://www.w3.org/2000/01/rdf-schema#domain")
(subject
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:diagnostic#_30B.C
ODE_SYMPTÔME") (object
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:diagnostic#_30B")
)

Explication :
 Les deux premiers faits indiquent que « 30P » et « 30PB » sont des
classes (système topo)
 Le troisième fait indique que « 30PB » est sous-classe de « 3OP »
 Le quatrième fait indique que « description » est un attribut de la classe
« 30PB » (système topo)
 Le dernier fait indique que « CODE_SYMPTÖME » est un attribut de
la classe « 30B » (système diagnostic).

83
3) Niveau instances

(MAIN::triple (predicate
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30BT.fonction")
(subject
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30BT_Instance_4")
(object "TRANSF"))

(MAIN::triple (predicate
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:diagnostic#_30B.DESCRIPTION
_REMÈDE") (subject
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:diagnostic#_30B_Instance_2"
) (object "Remplacement du disjoncteur"))

Explication:

 Le premier fait indique que la valeur de l’attribut « fonction » de l’instance 4 de la


classe « 30BT » est « TRANSF » (système topo)
 Le deuxième fait indique que la valeur de l’attribut « DESRIPTION_REMEDE » de
l’instance 2 de la classe 30B est « Remplacement du disjoncteur » (système
diagnostic).

84
CHAPITRE VI : EXPLOITATION DE L’ONTOLOGIE
« TURBINE A VAPEUR »

85
Dans le chapitre précédant, nous avons traduit le code OWL de l’ontologie « Turbine à
Vapeur » en faits de JESS et nous avons obtenu un ensemble de faits stockés dans un fichier
texte. C’est la base des faits à exploiter pour répondre à des requêtes formulées en JESS.
Ainsi, et comme nous l’avons déjà vu, chaque fait est un triplet (Predicate, Subject, Object)
définissant les ressources et les liens entre les ressources. Ayant étudié de prés cet ensemble,
nous avons remarqué qu’il est composé de trois nivaux à savoir (le niveau modèle, le niveau
ontologie et le niveau instances) le contexte d’exploitation peut différer d’un niveau à l’autre.
Dans ce chapitre, nous allons présenter graphiquement un extrait de la façon dont les
connaissances sont liées, ces modèles graphiques nous ont facilité la formulation des requêtes
pour l’exploitation de chaque niveau.

VI.1. INTRODUCTION

Rappelons que l’objectif de notre travail ne se limite pas à construire une ontologie afin de
capitaliser les connaissances concernant le système industriel « Turbine à Vapeur » mais aussi
à exploiter ces connaissances via un système à base de connaissances offrant à l’utilisateur
(acteur de maintenance) les informations nécessaires pour les aider à faire un diagnostic face à
une panne.

Ceci peut se matérialiser par :

 Pour chaque système, fournir les tranches, les équipements principaux de chaque
tranche ainsi que les composants de chaque équipement principal;
 Fournir les informations portant sur les caractéristiques d’un équipement composant
sélectionné par l’utilisateur ;
 Afficher les cas d’interventions existants (cause, défaut, symptôme et remède) pour
chaque équipement composant sélectionné par l’utilisateur lui laissant la possibilité de
voir si ce cas est similaire à son cas courant;
 Permettre l’interfaçage avec les bases de données déjà existantes en les dotant des
informations importées de l’ontologie.

Rappelons aussi que l’objectif visé par l’approche ontologique est la manipulation et la
réutilisation des connaissances préalablement modélisées.

L’exploitation des connaissances dans un système basé sur les ontologies peut s’effectuer
selon trois approches qu’il est possible de combiner ou d’employer séparément.

Ces approches sont :

1- L’approche raisonnement: Consiste en la manipulation des connaissances déjà acquises


pour produire de nouvelles connaissances. Une mémoire d’entreprise basée sur une ontologie
permet une certaine flexibilité dans sa définition et son évolution. Dotée de mécanisme
d’inférence, le système d’interrogation permet à partir des connaissances déjà stockées, de
déduire de nouvelles connaissances permettant ainsi l’évolution de la base de connaissances.

2- L’approche exploitation des liens: Elle permet de retrouver des connaissances à travers les
liens, une ontologie peut en effet exprimer une sémantique plus riche au travers de la

86
modélisation des liens entre les connaissances. Notons que les liens entre les connaissances
offrent une richesse en sémantique dans la représentation du domaine.

3- L’approche base de données : Dans cette approche, la mémoire d’entreprise peut être
manipulée comme une base de données grâce à l’exploitation des instances de l’ontologie en
utilisant un langage de requête.

L’exploitation des connaissances devient complète si on combine l’approche bases de


données, l’approche raisonnement et les liens entre les connaissances.

VI.2. Modèle des liens entre les connaissances

Notre base de connaissances est représentée par un ensemble de faits de type triplets
(Prédicat, Sujet, Objet), pour pouvoir interroger cet ensemble, nous avons modélisé
graphiquement les liens entre les faits. Et comme les faits appartenaient à trois niveaux
différents, nous avons étudié les niveaux séparément. Les faits appartenant au niveau
« modèle d’ontologie » concernent le modèle de l’ontologie utilisé soit RDF/RDFS et OWL.
Pour ce niveau on s’est contenté de voir les possibilités d’exploitation offertes.

Les faits appartenant au niveau « ontologie » concernent les modèles des deux systèmes
intégrées avec les liens entre eux (ajoutés dans l’ontologie). Ce niveau a été exploité pour une
consultation et une interrogation, mais des cas d’utilisation possibles de mise à jour ont été
cités.

Les faits appartenant au niveau « instance » concernent les instances de l’ontologie qui
étaient en premier lieu des instances des deux bases de données intégrées dans l’ontologie. Ce
niveau aussi a été exploité pour une consultation et interrogation.

Pour les prochaines représentations graphiques, voici une description des notations utilisées.
- Les rectangles représentent les ressources, il peut s’agir de sujets ou objets ;
- Les annotations des arêtes représentent les prédicats (relations entre le sujet et
l’objet) ;
- La forme ovale représente un littéral ( la valeur du sujet).

Sujet S Prédicat O Objet

S
Prédicat

Litéral

87
VI.2.1. Niveau modèle ontologie

Les connaissances appartenant à ce niveau sont propres au modèle de l’ontologie (RDF/RDFS


et OWL) utilisé et elles sont complètement indépendantes du domaine concerné. Nous
présentons ci-dessous un extrait des liens de la ressource « class » dans (RDF/OWL) c’est
aussi un extrait du méta-modèle RDFS et du méta-modèle OWL pour la ressource « class »
voir figure (III.2 et III.3)

Object Subject
Nothing Thing subclass domain range Property Property

type domain range range range type type


type
Les arêtes : Predicate

class type
subclass

Figure VI.1 : Extrait de modèle pour « class » niveau modèle

Avec:

- Nothig, Thing, Property, ObjectProperty sont de type “class”


- Subclass a pour domaine une ressource de type « class » et une autre ressource pour
codomaine de type « class »
- Une classe est sous-classe « subclass » d’une autre classe
- Domain a pour codomaine une classe
- Range a pour codomaine une classe.

 Contexte d’utilisation :

L’exploitation des connaissances appartenant à ce niveau offre les possibilités


suivantes :
- Afficher la description, les liens entre les ressources ;
- Possibilité d’étendre dynamiquement de nouveaux constructeurs qui n’existaient pas dans
RDF, RDFS et OWL permettant une adaptabilité à des évolutions/ changements/
enrichissement du modèle d’ontologie ;
- Intégrer un autre modèle après avoir traduit ce dernier en faits JESS ;

Cette partie n’a pas été prise en compte, néanmoins, on a élaboré quelques exemples de
consultation. D’autres exemples permettant de générer une représentation des connaissances
en un autre modèle tel que le modèle F-Logic ont été testés et présenté à la suite de ce
chapitre.

88
VI.2.2. Niveau ontologie

Ces connaissances représentent les concepts appartenant au domaine d’application (concept


représente une tranche, équipement principal ou équipement composant), leurs attributs, les
types des attributs ainsi que les relations hiérarchiques, les relations spécifiques existantes
entre eux.

Nous présentons dans la figure suivante, un extrait de la représentation graphique des


connaissances ainsi que les liens existant entre elles appartenant à ce niveau.

S type O
concept class
O
S subclass type
O Property

O O range S S
Equivalent1
type
domain S ObjectProperty

type
TransitiveProperty

type
O DatatypeProperty
domain S S
attribut
type O
S S FunctionalProperty

range O
Valeur (type )

hasorigincolumn O Valeur champs


origine

Figure VI.2 : Extrait des liens entre les connaissances, niveau ontologie

Avec :

- Un concept est de type class ;

89
- Un concept est subclassof (sous-classe) d’un autre concept ;
- La relation « equivalent1 » qui lie deux concepts de nom différents ( le premier concept
représente le « domain » et le deuxième concept représente le « range » ;
- La relation « equivalent1 » est de type « Property », « ObjectProperty » et puisqu’elle
est transitive donc elle est aussi de type « TransitiveProperty) ;
- Un attribut d’un concept donné est représenté par « domain » par contre son codomaine
« range » est son type (c’est un litéral exemple : string) ;
- Un attribut est de type « FunctionnalProperty » et « DataProperty » ;
- Chaque attribut lui est affecté son nom d’origine dans la base de données source, ceci est
représenté par le prédicat « hasorigincolumn).

 Contexte d’utilisation

Les cas d’utilisation possibles pour l’exploitation des connaissances et les liens entre les
connaissances dans ce niveau sont :

- Créer d’autres classes (concepts) et par conséquent mettre à jour l’ontologie


- Créer de nouvelles relations spécifiques ou constructeur RDF/OWL entre les concepts
- Etendre une classe par ajout d’attribut
- Changer le type des attributs
- Consulter le champ d’origine d’un attribut (le nom de champ de la base de données
source)
- Afficher les relations hiérarchiques ou autres relations existant entre les ressources ou
exploitation de ces liens pour répondre à des requêtes utilisateur

VI.2.3 Niveau Instances

Dans ce niveau, sont représentées les instances de l’ontologie et les liens existants entre elles,
ainsi que les liens d’appartenance avec les classes concernées
La figure suivante illustre un extrait de la représentation graphique des instances

90
concept

Equivalent1

O
type S O
S
Instances O
literal

attribut
type
S
Valeur de type
O l’attribut String

Figure VI.3 : extrait de structure des instances

Avec
- Le prédicat « type » lie l’instance à son concept ;
- Deux instances équivalentes appartenant à deux systèmes différents sont liées par le
prédicat « equivalent1 » ;
- L’attribut est le prédicat entre l’instance et la valeur de cette instance dans cet
attribut ;

 Contexte d’utilisation
Tous les cas possible pour gérer des instances sont offerts :

- Ajout des instances tout en créant ses liens avec les autres ressources
- Afficher toutes les instances d’une classe d’un système donné ;
- Afficher toutes les instances équivalentes d’une classe donnée ;
- Afficher les informations caractéristiques de chaque concept (zone, fonction,
famille,..ect) ;
- Afficher les informations concernant un cas (symptôme, défaut, remède,..ect) .

VI.3. LES REGLES FORMULEES EN JESS POUR EXPLOITER


L’ONTOLOGIE

L’exploitation de l’ontologie turbine à vapeur revient donc à exploiter la base des faits ainsi
obtenue après la traduction de l’ontologie en fait de JESS. Ceci est assuré par des règles et des
requêtes permettant la recherche entre les faits de la base, à travers les commandes JESS tel
que « defrule » et « defquery ».

91
VI.3.1. Notation de JESS

Afin de définir un fait en JESS, il est nécessaire de définir un « template ». Un template est
définit par son nom et la liste de « slot » de son « template ». JESS fournit la fonction
« deftemplate » pour la définition d’un template.
La déclaration d’un template inclut un nom, une documentation (optionnelle), une clause
« extends » (optionnelle) et une liste de zéro à plusieurs description de slots,etc. Chaque slot
peut inclure un type de qualificateur (type de données, par exemple integer, float, string, etc.)
ou une valeur par défaut.
« triple » est le nom donné au template qui définit le triplet et qui est composé de Predicate,
subject, object. Cet template est exprimé en JESS de la façon suivante :

;;; Declaring the triple template ---------------------------------


(deftemplate triple "Template representing a triple"
(slot predicate )
(slot subject )
(slot object )
)

Afin de créer une instance d’un template, JESS utilise la fonction assert qui assigne à chaque
slot une valeur, la création d’une instance du template triple formulée en JESS est décrite ci-
dessous :

(assert
(triple
(predicate
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#hasOrigCo
lumnName")
(subject
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30BA.des
cription")
(object "description")
)
)

La définition d’une règle en JESS est donnée par « defrule » dont la syntaxe est la suivante :
(defrule nom-règle : définition du nom de la règle est obligatoire
[« documentation »] [ ] : c’est optionnel
(condition)* * : zéro à plusieurs conditions composées par des
opérateurs logiques (et, ou, not)
=> : ce symbole sépare la partie condition de la partie action, il joue le
même rôle que « then » dans une instruction « IF »
(action)*) : plusieurs actions peuvent être définies

La définition d’une requête en JESS est donnée par « defquery » dont la syntaxe est la
suivante :
(defquery nom-requête
[« documentation »]
(condition*))

92
VI.3.2. Quelques cas d’exploitation de l’ontologie

Dans ce qui suit, nous allons détailler quelques cas d’utilisation de la base (ontologie) en
présentant un extrait du programme JESS et les résultats données après exécution du
programme dans l’environnement JAVA.

Cas d’utilisation N°1 : Afficher la description de la ressource « class »

(defrule defclasse
(triple
(predicate ?p)
(subject "http://www.w3.org/2000/01/rdf-schema#Class")
(object ?o))
=>
(printout t "Subject:http://www.w3.org/2000/01/rdf-schema#Class" crlf
)
(printout t "Predicate
Object" crlf)
(printout t ?p " "?o crlf crlf))

Cette règle permet d’afficher tout les triplets ayant http://www.w3.org/2000/01/rdf-


schema#Class pour Subject, ?p et ?o sont respectivement des variables
contenant tous les prédicats, les objets respectant la condition. Ce cas
d’utilisation concerne le niveau « modèle d’ontologie ».

La figure suivante illustre une capture d’écran des résultats obtenus.

Figure VI.4 : Affichage des liens de la ressource « class »

Cas d’utilisation N°2 : Afficher les attributs de la classe


"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30BB"

93
(defrule attribut30BB
(triple
(predicate "http://www.w3.org/2000/01/rdf-schema#domain")
(subject ?s)
(object
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_
30BB"))
=>
(printout t ?s crlf ))

concept
O S attribut
domain

Cet extrait de la (figure VI.2) représente un triplet où le prédicat est « domain », le sujet
représente un attribut et l’objet représente le concept. Donc pour afficher les attributs d’un
concept, il suffit de définir le prédicat par « domain », de définir l’objet par le concept
concerné exemple : « 30BB », puis utiliser la variable « ?s » qui va contenir tous les sujets
vérifiant la condition définie dans Predicate et d’Object, ainsi « ?s » va contenir tous les
attributs du concept « 30BB », et afin de l’afficher, on emploi la commande JESS « Printout
t ?s ».
« crlf » permet de faire des sauts de lignes. Le résultat obtenu est présenté dans la figure
suivante :

Figure VI.5 : Affichage des attributs d’un concept donné

Cas d’utilisation N°3 : Afficher es instances de la classe


http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30BB

94
Voir dans la (figure VI.3) le triplet « type, instance, concept) et la définition de la règle ci-
dessus permet d’afficher toutes les instances du concept « 30BB ».

(defrule instances30BB
(triple
(predicate "http://www.w3.org/1999/02/22-rdf-syntax-ns#type")
(subject ?s)
(object
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_
30BB"))
=>
(printout t ?s crlf ))

La capture d’écran du résultat obtenu est présentée ci-dessous

Figure VI.6 : Affichage des instances d’un concept donné

Cas d’utilisation N°4 : Afficher les instances qui sont liées par la relation « equivalent1 »

Comme on a vu dans le chapitre précédent, avec l’éditeur Protge 2000, nous avons crée une
relation entre deux classes équivalentes appartenant aux deux systèmes différents et par
conséquent leurs instances. Rappelons que cette relation a été crée pour permettre l’échange
de données entre les deux systèmes et cette relation est visualisée dans la (figure VI.3) qui
nous aide à formuler la règle suivante.

95
(defrule instequivalent
(triple
(predicate "http://www.w3.org/1999/02/22-rdf-syntax-ns#type")
(subject ?s)
(object
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30B
B"))
(triple
(predicate "http://www.owl-
ontologies.com/Ontology1214680546.owl#equivalent1")
(subject ?ss&:(eq ?ss ?s))
(object ?o))
=>
(printout t ?s " " ?o crlf ))

La figure suivante présente les résultats obtenus, ainsi dans la même ligne il ya une instance
du système « topo » et l’instance équivalente du système « diagnostic »

Figure VI.7 : Affichage des instances équivalentes

Cas d’utilisation N°5 : Afficher la description des instances

On peut aussi récupérer la valeur des attributs, toujours en se référant au diagramme présenté
par la (figure VI.3), on formule cette règle afin d’afficher toute les instances du concept
« 30BB » puis récupérer la valeur de l’attribut « description » des instances trouvées.

96
(defrule inst
(triple
(predicate "http://www.w3.org/1999/02/22-rdf-syntax-ns#type")
(subject ?s)
(object
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30BB")
)
(triple
(predicate
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30BB.d
escription")
(subject ?ss&:(eq ?ss ?s))
(object ?o))
=>
(printout t ?ss " "?o crlf ))

Figure VI.8 : Affichage des valeurs de l’attribut « description »

V.3.3 Possibilité de représentation des connaissances dans un autre


modèle

Nous avons essayé par donner un exemple simple pour voir s’il ya une possibilité de générer
une représentation de l’ontologie dans un autre modèle, ce test donne des résultats, mais il
loin de dire que c’est faisable tant qu’une étude approfondie sur la syntaxe et la sémantique du
modèle cible n’a pas été établie. Le modèle choisi est « F-logic ».

F-logic est un langage avec de bonnes propriétés (décidabilité, calculabilité, héritage,..), c’est
un langage de représentation de connaissances dont voici quelques notations de base.

97
 C 1::C C est sou-classe de C1
 O :C O est un objet membre de la classe C
 O[p -> v] la propriété p de l’objet O a la valeur v
 O[A1-> v1 ;A2->v2 ;..] O est l’objet dont A1,A2,… sont ses attributs et
V1 ,V2,… leurs valeurs respectives.

1) Cette règle présente la hiérarchie des classes en F-logic


(deftemplate a
(slot sujet)
(slot operateur)
(slot objet))
(bind ?op "::")
(bind ?c
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_")
(bind ?l (str-length ?c))
(bind ?d 1)
(bind ?diag
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:diagnosti
c#_")
(bind ?ld (str-length ?diag))
(bind ?dd 1)
(defrule a
(triple
(predicate "http://www.w3.org/2000/01/rdf-schema#subClassOf")
(subject ?s)
(object ?o))
=>(if (>= (str-length ?s) ?l) then
(if (= ?c (sub-string ?d ?l ?s)) then
(if (>= (str-length ?o) ?l) then
(if (= ?c (sub-string ?d ?l ?o)) then
(assert (a (sujet ?s)(operateur ?op)(objet ?o ))))))) )
(defrule aa
(triple
(predicate "http://www.w3.org/2000/01/rdf-schema#subClassOf")
(subject ?ss)
(object ?oo))
=>(if (>= (str-length ?ss) ?ld) then
(if (= ?diag (sub-string ?dd ?ld ?ss)) then
(if (>= (str-length ?oo) ?ld) then
(if (= ?diag (sub-string ?dd ?ld ?oo)) then
(assert (a (sujet ?ss)(operateur ?op)(objet ?oo ))))))) )
(defrule b
(a(sujet ?s)(operateur ?p)(objet ?o))
=>(printout t (sub-string 61 (str-length ?s) ?s)?p(sub-string 61 (str-
length ?o) ?o) crlf))

La figure ci-dessous présente les classes avec leurs sous-classes en F-logic.

98
Figure VI.9 : Représentation des classes et leurs sous-classe en F-logic

2) La règle suivante permet d’afficher les instances (objets membres) de la classe


« 30BB » en F-logic

(defrule instf
(triple
(predicate "http://www.w3.org/1999/02/22-rdf-syntax-ns#type")
(subject ?s)
(object
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30BB"))
=>
(printout t (str-cat (sub-string 61 (str-length ?s) ?s)":topo#_30BB") crlf
))

99
Figure VI.10 : Représentation des objets d’une classe en F-logic

100
3) Le prochain extrait de programme JESS, permet d’afficher les attributs et la
valeur de chaque attribut de l’instance 30BB_Instance_6 en F-logic.

(deftemplate struc
(slot champs1))
(bind
?c"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_")
(bind ?l (str-length ?c))
(bind ?d 1)
(defquery aval
(triple
(subject
"http://biostorm.stanford.edu/db_table_classes?DSN=jdbc:odbc:topo#_30BB_Ins
tance_6")))
(bind ?champ " ")
(bind ?result (run-query aval))
(while (?result hasNext)
(bind ?token (call ?result next))
(bind ?fact (call ?token fact 1))
(bind ?p (fact-slot-value ?fact predicate))
(bind ?o (fact-slot-value ?fact object))
(if (>= (str-length ?p) ?l) then
(if (= ?c (sub-string ?d ?l ?p)) then
(if (= ?champ " ") then
(bind ?champ1 (str-cat ?champ (sub-string 72 (str-length ?p)
?p)"->'" ?o"'" )))
(if (neq ?champ " ") then
(bind ?champ1 (str-cat ?champ "," (sub-string 72 (str-length ?p)
?p)"->'" ?o"'" )))
(bind ?champ ?champ1)
)))
(assert (struc(champs1 (str-cat "topo#_30BB_Instance_6[" ?champ1"]"))))
(defrule afval
(struc(champs1 ?cp))
=>
(printout t ?cp crlf)
)

Figure VI.11 : Représentation d’un concept en F_logic

101
En conclusion, remarquons que l’utilisateur doit connaître le langage JESS pour interroger la
base des faits. Toutefois, il est indispensable de pouvoir réaliser des interrogations d’une
façon transparente pour l’utilisateur. Un des avantages de JESS est qu’il peut être intégré dans
un environnement pour la construction d’application JAVA. Nous profitons de cet avantage
pour développer des interfaces écrites en JAVA, qui télécharge et exécute des programmes de
recherche en JESS, puis récupère les résultats afin de les afficher dans l’interface ou les
stocker dans une base de données en utilisant l’API JDBC.

VI.4. IMPLEMENTATION

La réutilisation de l’ontologie s’attache à définir les différents modes selon lesquels les
utilisateurs du système souhaitent restituer les connaissances. Cela signifie qu’il faut prendre
en compte :
 Les modes de recherche et d’accès à savoir navigation dans une arborescence,
recherche par mots clé ou en texte libre, etc.
 Les interfaces de recherche et leurs caractéristiques
 Le support ou la façon dont ces connaissances doivent être restituées, base de données,
etc.

Deux interfaces ont été développés « Interface-Utilisateur » et « Interface-base de données ».


Sur le plan conceptuel, le développement de ces interfaces repose sur le modèle de liens des
connaissances dans la base des faits présenté dans les (Figures VI.2, VI.3.) Sur un plan
purement technique, le choix de JAVA c'est imposé étant donné qu’il offre les possibilités
d’exécuter des programmes JESS et d'en restituer les résultats.

VI .4.1. INTERFACE UTILISATEUR

Cette interface permet de consulter les connaissances définies par les concepts, leurs attributs
et les liens existant entre eux, ceci permet de fournir des réponses pertinentes aux requêtes.
Elle permet en premier lieu de fournir la structure hiérarchique d’un concept dans un système
donné, et une vue sémantique en deuxième lieu, ceci en fournissant les informations
concernant l’équipement dans l’autre système grâce aux liens existant entre les instances des
deux systèmes, les interactions se déroulent comme suit :

 l’utilisateur choisi le système, l’ensemble des classes qui représente les tranches lui est
fourni ;
 après avoir sélectionné une tranche, l’ensemble des sous-classes qui représente les
équipements principaux est affiché ;
 une fois l’équipement principal est choisi, l’ensemble des instances qui représente les
équipements composants est affiché ;
 Une fois l’équipement élémentaire est sélectionné, ses informations portant sur les
caractéristiques sont affichées et si cet équipement a subi des interventions alors les
symptômes (issus de l’autre système) sont affichés ;
 Il sélectionne le symptôme concerné pour avoir les défauts, les causes et les remèdes.

102
Figure VI.12 : Interface ontologie- utilisateur

Coté technique, nous avons utilisé l’environnement JAVA dans une plateforme Eclipse, et cet
extrait de programme JAVA présente la façon dont un programme JESS est chargé pour
exécution et la récupération des résultats.

try { Batch.run(mot,"d://maigsihem//trans//topo.txt");
mot.eval("(defquery printEquss (eqfam (famille ?m))
(eqzone(zone ?z)) (eqfon (fonction ?f)) (parent (coparent ?cp)))");
Query querySYM = null;
querySYM = new Query (mot,"printEquss");
querySYM.affichage("printEquss",this.texte_topo);

Explication :
La première ligne indique le chargement et l’exécution du programme JESS « topo.txt » ;
La deuxième ligne indique l’exécution de la requête « printEquss » et qui permet de récupérer
les résultats dans une classe JAVA « Query » présenté dans l’extrait suivant du programme ;
La dernière ligne permet d’afficher le résultat dans un box défini dans la fenêtre de l’interface.

if ( quer == "printEquss")
while(this.result.next())
{String topoq = " Famille :" + this.result.getString("m")+ "
zone :"+ this.result.getString("z")+ " Fonction :"+
this.result.getString("f")+ " code-parent :"+
this.result.getString("cp");
((JTextArea) compo).append(topoq);
}

103
VI.4.2. INTERFACE BASE DE DONNEES

L’interface « ontologie-base de données » permet de restituer les connaissances concernées


par la classe et sous-classe sélectionné par l’utilisateur et les stocker dans la base de données
topo. Ainsi, chaque sous-classe choisie fera l’objet de la création d’une table portant le libellé
de la sous-classe et qui a pour attributs : code, designation, fonction issus du système « topo »
et description-symptôme, description-défaut, description-cause et description-remède issus du
système « diagnostic ». Si l’équipement sélectionné n’a pas subit d’interventions, la table ne
sera pas crée.

Figure VI.13 : Interface ontologie- base de données

De la même façon que pour l’interface utilisateur, un programme JESS est chargé et exécuté ,
le premier « dequery printsym » permet d’importer les attributs et leurs types (structure de la
table à créer) à partir de l’ontologie et le deuxième « defquery printval » permet de récupérer
les valeurs (contenue de la table à créer).

104
try { Batch.run(mot,"d://maigsihem//trans//afeqbd.txt");
mot.eval("(defquery printSym (structureo (code
?c)(description ?de)(fonction ?f)(sym ?s)(def ?d)(cause ?ca)(remede
?r))(type (codet ?ct)(descriptiont ?det)(fonctiont ?ft)(symt ?st)(deft
?dt)(causet ?cat)(remedet ?rt)) (sc(dsc ?vdsc))) ");
Query querySYM = null;
querySYM = new Query (mot,"printSym");
querySYM.affichage("printSym",this.combo_equs,nombd);
} catch (NullPointerException e1)
{e1.printStackTrace();}
catch (JessException e1) {e1.printStackTrace();}
try {
Batch.run(mot,"d://maigsihem//trans//afeqbd.txt");
mot.eval("(defquery printval (sc(dsc ?vdsc))(valeur
(vcode ?vc)(vdescription ?vde)(vfonction ?vf)(vsym ?vs)(vdef ?vd)(vcause
?vca)(vremede ?vr)))");
Query querySYM = null;
querySYM = new Query (mot,"printval");
querySYM.affichage("printval",this.combo_equs,nombd);

L’accès à la base de données initiale« topo » à partir d’un programme JAVA est assuré par
l’API JDBC (Java DataBase Connectivity) et qui joue un rôle très important dans le cadre de
l’intégration des applications dans le domaine industriel.
La norme JDBC [20] est développée par JavaSoft, l’API standard JDBC définit un package
(ensemble de classes java) qui permettent à un composant java quelconque (applet, servlet,
java Bean ou toute application java) de se connecter à une base de données cible.

Cet extrait de programme permet d’établir une connexion avec la base de données cible
« topo » et en cas d’échec, un message d’erreur est affiché.

try {
String DBurl = "jdbc:odbc:topo";
con = DriverManager.getConnection(DBurl);
} catch (SQLException e) {
arret("Connection à la base de données impossible");
}

[20]: Sun, Java Database Connectivity (JDBC), http://java.sun.com/products/jdbc/,2005

105
Une fois la connexion est établie avec la base de données, la requête SQL de création de la
table et de sa structure importé de l’ontologie est définie comme suit :

requete = "CREATE TABLE `"+nombd+"` (`"+champ1+"` "+type1+"


,`"+champn+"` "+typen+" ,`"+champ2+"` "+type2+",`"+champf+"`
"+typef+",`"+champ3+"` "+type3+" ,`"+champ4+"` "+type4+",`"+champ5+"`
"+type5+" ,`"+champ6+"` "+type6+" )";

try {
Statement stmtc = con.createStatement();

int nbcre = stmtc.executeUpdate(requete);


affiche("Table crée");

La commande java « executeUpdate » permet d’exécuter la requête SQL définie ci-dessus et


dont le nom, les champs et les types ont été récupéré de l’ontologie (base des connaissances).

Cette capture d’écran montre l’apparition de la table crée à partir de l’ontologie dans Access.

Figure VI.14 : Apparition de la table importée de l’ontologie dans Access

106
Nous présentons dans la figure ci-dessous le contenue de la table crée à partir de l’ontologie et
dont les instances sont issues des deux systèmes sources « topo » et « diagnostic ».
Les champs code, description, fonction sont issus du système « topo » et qui représentent la
typologie des équipements, les champs description_symptôme, description_défaut,
description_cause et description_remède sont issus du système « diagnostic » et qui
représentent les cas d’interventions des mêmes équipements.

Figure VI.15 : Contenu de la table importée de l’ontologie dans Access

La structure de la table crée a été fixée à l’avance, mais il ya une possibilité d’afficher tous
les attributs d’un équipement laissant la possibilité à l’utilisateur de choisir ceux qui vont faire
l’objet de la structure de la table à créer et rendre ainsi la création dynamique des tables.

107
CONCLUSION ET PERSPECTIVE

Le travail effectué et répertorié dans ce mémoire consiste à une extraction de plusieurs bases
de données en une seule ontologie avec des espaces de nom différents. L’insertion des
relations entre les concepts appartenant à des sources de données différentes a enrichi la
sémantique des données et a permis l’échange des données entre elles.

Pour répondre aux spécificités du domaine industriel, un système expert JESS a été intégré. Et
la traduction du code OWL de l’ontologie en faits de JESS a permis d’avoir une base de
connaissances à trois niveaux donnant la possibilité d’exploiter le modèle d’ontologie,
l’ontologie et ses instances. Cette exploitation a été réalisée indépendamment de l’outil
Protege qui a servi à développer l’ontologie turbine à vapeur. Un système a été développé
pour naviguer la base de connaissances obtenue afin de répondre aux requêtes, fournissant à
l’utilisateur les informations nécessaires ( les cas d’intervention précédents) tout en lui
laissant la responsabilité de voir si ce cas est similaire à son cas courant.

La base de connaissances obtenue par la traduction du code OWL de l’ontologie en faits de


JESS et l’application des règles sémantiques RDFS et OWL par le moteur d’inférence JESS
a généré les faits JESS relatives à la sémantique de l’ontologie. Cette base de connaissances
est un ensemble de triplets (Predicate, Subject, Object) représentant les niveaux modèle,
ontologie et instance, cette représentation en niveaux a permis d’élargir le champ
d’exploitation de l’ontologie. L’exploitation du premier niveau permet d’étendre
dynamiquement de nouveaux constructeurs qui n’existaient pas dans RDF, RDFS et OWL
tout en permettant une adaptabilité à des évolutions, changements et enrichissement du
modèle d’ontologie.

L’exploitation du deuxième niveau permet de gérer les concepts et les relations, ceci se traduit
par: l'ajout de classes ou relations, modification en étendant les classes par insertion de
nouveaux attributs, etc. L’exploitation du dernier niveau permet de gérer les instances tout en
créant de nouvelles ainsi que des nouveaux cas d’intervention pour chaque équipement ou
même de nouveaux équipements. Sur le plan purement technique, le choix de JAVA c’est
imposé étant donné qu’il offre les possibilités d’exécuter des programmes JESS et d’en
restituer les résultats. Ces résultats peuvent être affichés à l’utilisateur ou stockés dans une des
bases de données source à l’aide de l’API JDBC. Ayant la possibilité d’exploiter le niveau
modèle de l’ontologie, nous pensons que la génération des connaissances de l’ontologie en un
autre modèle tel que le modèle F-logic est possible, quelques exemples simples ont été testés.

En perspective, nous pensons que ce sujet est très ouvert et plusieurs travaux peuvent être
proposés, nous allons citer quelques uns:
L’approche que nous avons adopté est d’intégrer les bases de données en une seule ontologie
avec des espaces de nom différents, toutefois, DataMaster permet aussi d’importer les bases
de données en plusieurs ontologies séparées (soit une ontologie par base de données), ça serait
intéressant de l’essayer pour établir par la suite une fusion des ontologies obtenues ou un
mapping entre elles.

108
Puis faire une étude comparative des approches utilisées afin d’identifier laquelle répond le
mieux aux critères suivants : Simplicité d’implémentation, efficacité dans l’exploitation des
ontologies, etc.

Nous proposons aussi de développer un outil ou un plug-in dans Protege permettant


d’extraire une base de données à partir d’une ontologie, soit l’opération inverse de
DataMaster utilisé pour importer les bases de données dans Protege. Cet outil permettra ainsi
une conception de base de données fondée sur une ontologie.

109
SOMMAIRE

CHAPITRE I : INTRODUCTION ..........................................................................................2


I .1. Introduction ................................................................................................................3
I.2. Problématique ..............................................................................................................4
I.3. Les objectifs du système proposé ..................................................................................5
I.4. Description du contenu .................................................................................................6
CHAPITRE II : LA TURBINE A VAPEUR ...........................................................................8
II.1. Introduction.................................................................................................................9
II.1.1. Définition- Principes généraux de fonctionnement de la turbine à vapeur.............9
II.1.2. Les principaux composants des turbines à vapeur .............................................. 12
II.1.3. Fonctionnement ................................................................................................. 13
II.2. La Maintenance Industrielle ..................................................................................... 14
II.2.1. Les types de maintenance ................................................................................... 15
II. 3. Maintenance de la turbine à vapeur.......................................................................... 15
CHAPITRE III : ETAT DE L’ART ...................................................................................... 17
III.1. Travaux réalisés et état de l'art dans le domaine de la gestion des connaissances pour
la Maintenance Industrielle ............................................................................................... 18
III.2. Ontologie et bases de données .................................................................................. 22
III.2.1. Introduction....................................................................................................... 22
III.2.2. Travaux réalisés et état de l’art de l’utilisation des ontologies dans le domaine des
bases de données ........................................................................................................... 23
III.3 LES SYSTEMES A BASE DE CONNAISSANCES ................................................ 26
III. 3.1. Apport des SBC ............................................................................................... 26
III.3.2 Les ontologies et les SBC ................................................................................... 27
III.3.3. L’opérationnalisation de l’ontologie .................................................................. 29
CHAPITRE IV : LES ONTOLOGIES .................................................................................. 30
IV.1. Définition et développement des ontologies ............................................................. 31
IV.1.1. Les composants d’une ontologie........................................................................ 31
IV.1.2. Les types d’ontologies...................................................................................... 32
IV.1.3. La construction d’une ontologie ........................................................................ 33
IV.1.3.1. Les principes de construction d’une ontologie ............................................... 34
IV.1.4. Les Ontologies et le raisonnement ..................................................................... 34
IV.2. Taxonomie des ontologies de domaine ..................................................................... 37
IV.2.1. Canonicité des Ontologies Conceptuelles .......................................................... 37
IV.2.2. Les ontologies Conceptuelles Canoniques (OCC).............................................. 38
IV.2.3. Les Ontologies Conceptuelles non Canoniques (OCNC) ................................... 38
IV.2.4. Ontologie Linguistiques (OL) ........................................................................... 38
IV.2.5. Le Modèle en Oignon........................................................................................ 39
IV.3. Les modèles d’ontologie .......................................................................................... 40
IV.3.1.Les constructeurs ............................................................................................... 40
IV.3.2. Modèles d’ontologies orientés vers la définition de OCC .................................. 43
IV.3.2.1. RDF/RDF-Schéma ......................................................................................... 43
IV.3.2.2. Le modèle PLIB ............................................................................................. 45
IV.3.3. Modèles d’ontologies orientés vers la définition de OCNC................................ 46

110
IV.3.3.1. OWL .............................................................................................................. 46
IV.3.3.2. F-Logic .......................................................................................................... 49
IV.3.4. Les constructeurs pour les OL .......................................................................... 50
CHAPITRE V : DEVELOPPEMENT DE L’ONTOLOGIE.................................................. 52
TURBINE A VAPEUR ........................................................................................................ 52
V.1. PROCESSUS GENERAL DE DEVELOPPEMENT DE L’ONTOLOGIE ................ 53
V.1.1. Les outils orientés conceptualisation................................................................... 54
V.1.1.1. Data-Master................................................................................................... 55
V.1.2. Les outils orientés ontologisation........................................................................ 55
V.1.2.1. Protege ............................................................................................................ 55
V.1.3. Les outils orientés opérationnalisation ................................................................ 56
V.1.3.1. Les moteurs d’inférence .................................................................................. 56
V.1.3.2. Les langages d’interrogation d’ontologie ........................................................ 57
V.1.3.3. La représentation des connaissances ................................................................ 58
V.2 APPROCHE GENERALE PROPOSEE ..................................................................... 59
V.3. CONSTRUCTION DE L’ONTOLOGIE « TURBINE A VAPEUR » ....................... 60
V.3.1. Conceptualisation de l’ontologie Turbine à Vapeur ............................................ 60
V.3.1.1. Conceptualisation d’ontologie basée sur le modèle oignon............................... 61
V.3.1.2 conceptualisation de l’ontologie « turbine à vapeur » basée sur le modèle en
oignon .......................................................................................................................... 62
V.3.2. Ontologisation de l’Ontologie Turbine à Vapeur ................................................ 68
V.3.2.1. Problèmes résolus par la création de relations entre concepts ........................... 68
V.3.2.2. Résolution des problèmes en utilisant les constructeurs OWL et les relations
crées ............................................................................................................................. 70
V.3.2.3. Les langages de formalisation de l’ontologie turbine à vapeur ......................... 74
V.3.3. Opérationnalisation de l’ontologie Turbine à vapeur ........................................... 78
V.3.3.1. Le système Expert JESS .................................................................................. 78
V.3.3.2. CONVERSION DU CODE OWL EN FAITS DE JESS .................................. 79
V.3.3.2.1. OWL2JESS .................................................................................................. 79
V.3.3.3. Représentation des connaissances dans la base des faits................................... 82
CHAPITRE VI : EXPLOITATION DE L’ONTOLOGIE ..................................................... 85
« TURBINE A VAPEUR » .................................................................................................. 85
VI.1. INTRODUCTION ................................................................................................... 86
VI.2. Modèle des liens entre les connaissances ................................................................. 87
VI.2.1. Niveau modèle ontologie................................................................................... 88
VI.2.2. Niveau ontologie ............................................................................................... 89
VI.2.3 Niveau Instances ................................................................................................ 90
VI.3. LES REGLES FORMULEES EN JESS POUR EXPLOITER L’ONTOLOGIE ....... 91
VI.3.1. Notation de JESS .............................................................................................. 92
VI.3.2. Quelques cas d’exploitation de l’ontologie ........................................................ 93
V.3.3 Possibilité de représentation des connaissances dans un autre modèle .................. 97
VI.4. IMPLEMENTATION ............................................................................................ 102
VI .4.1. INTERFACE UTILISATEUR ....................................................................... 102
VI.4.2. INTERFACE BASE DE DONNEES .............................................................. 104
CONCLUSION ET PERSPECTIVE .................................................................................. 108

111
112

Vous aimerez peut-être aussi