RÉALISATION D`UN MODÈLE DE FILTRAGE DE DONNÉES THIẾT
publicité
UNIVERSITE NATIONALE DU VIETNAM, HANOI
INSTITUT FRANCOPHONE INTERNATIONAL
POLLA DE NDJAMPA Félix-Bazin
RÉALISATION D’UN MODÈLE DE FILTRAGE DE DONNÉES
THIẾT LẬP MỘT MÔ HÌNH LỌC DỮ LIỆU
MEMOIRE DE FIN D’ETUDES DU MASTER INFORMATIQUE
HANOI – 2015
ATTESTATION SUR L’HONNEUR
J’atteste sur l’honneur que ce mémoire a été réalisé par moi-même et que les
données et les résultats qui y sont présentés sont exacts et n’ont jamais été publiés
ailleurs. La source des informations citées dans ce mémoire a été bien précisée.
LỜI CAM ĐOAN
Tôi cam đoan đây là công trình nghiên cứu của riêng tôi.
Các số liệu, kết quả nêu trong Luận văn là trung thực và chưa từng được ai
công bố trong bất kỳ công trình nào khác. Các thông tin trích dẫn trong Luận văn
đã được chỉ rõ nguồn gốc.
Signature de l’étudiant
POLLA DE NDJAMPA Félix-Bazin
Table des matières.......................................................................................................... iii
Remerciements ................................................................................................................ v
Résumé ........................................................................................................................... vi
Abstract ......................................................................................................................... vii
Liste des figures ........................................................................................................... viii
Liste des tableaux ........................................................................................................... ix
Introduction ..................................................................................................................... 1
Chapitre 1 ........................................................................................................................ 3
Synthèse bibliographique ................................................................................................ 3
Contexte : .................................................................................................................... 3
1.1. Langages de représentation des connaissances ............................................ 3
1.1.1
Graphe conceptuel ...................................................................................... 4
1.1.2
Langage du Web Sémantique ..................................................................... 4
1.1.3
Tableau comparatif des GC et OWL2 ........................................................ 5
1.2. L’apprentissage automatique ......................................................................... 6
1.2.1
Généralités sur la programmation logique inductive (PLI) ....................... 7
1.2.2
Apprentissage sur des ontologies (OWL) ................................................... 8
1.2.2.1. DL-Foil ................................................................................................ 9
1.2.2.2. DL-Learner ........................................................................................ 10
1.2.2.3. YINYANG (Yet another INduction Yields to ANother
Generalization) .................................................................................................. 12
1.2.2.4. Tableau comparatif ............................................................................ 13
Conclusion ................................................................................................................ 14
Chapitre 2 - Apports...................................................................................................... 15
Approche méthodologique ............................................................................................ 15
2.1. Etape de génération du modèle de situation .................................................... 16
2.2. Étape1 : Modélisation de la base de connaissance .......................................... 17
2.3. Étape 2 : Extraction d’exemples positifs ......................................................... 18
2.4. Étape 3 : Apprentissage ................................................................................... 19
2.4.1
Définition de quelques notions ................................................................. 21
2.4.2
Définition de l’opérateur de raffinement .................................................. 22
2.4.3
Propriétés de l’opérateur de raffinement ................................................. 24
2.4.4
Preuve des propriétés de l’opérateur de raffinement ............................... 25
2.4.5
Algorithme d’obtention de modèles .......................................................... 26
Conclusion ................................................................................................................ 28
Chapitre 3 ...................................................................................................................... 29
Expérimentation et analyses des résultats .................................................................... 29
3.1.
Présentation des cas d’étude ..................................................................... 29
3.1.1.
Scénario d'apprentissage .................................................................... 29
3.1.2.
Les paramètres d’expérimentations ................................................... 30
3.1.3.
Critères d’évaluation .......................................................................... 31
3.2.
Résultats d'expérimentations et interprétations ........................................ 31
3.2.1.
Résultat du scénario 1 ........................................................................ 32
3.2.2.
Interprétations des résultats du scénario1 ......................................... 33
3.2.3.
Résultat du scénario 2 ........................................................................ 34
3.2.4.
Interprétations des résultats du scénario 2 ........................................ 36
Conclusion .................................................................................................................... 38
Perspectives................................................................................................................... 39
Références ..................................................................................................................... 41
ANNEXES A : Présentation de tous les modèles de situation du scénario 1 .............. 44
ANNEXES B : Opérateur de DL learner ...................................................................... 47
iv
Nous tenons à saisir cette occasion pour adresser nos profonds remerciements
et notre profonde reconnaissance à :
§ Mme Claire LAUDY, Mme Gaëlle LORTAL et Mme Yue MA, pour leurs
précieux conseils et leurs orientations tout au long de notre recherche.
§ Tout le personnel du laboratoire LRASC de Thales Research & Technology et
celui du laboratoire LRI - Equipe LaHDAK pour leur assistance sur le lieu de
stage
§ Tous les professeurs de l’IFI, qui ont assuré notre formation durant ces deux
dernières années
§ Enfin, j’adresse mes plus sincères remerciements à ma famille, qui m’a toujours
soutenue et encouragée au cours de la réalisation de ce mémoire
Je remercie les personnes qui ont, à des degrés divers, contribué à l’aboutissement
de ce travail
v
L'étude qui est proposée dans ce mémoire s'intéresse aux problèmes
d’acquisition et d'exploitation de bases de connaissances structurées de grande taille,
en vue d'appuyer le processus décisionnel dans des domaines aéronautique et aussi
d'améliorer celui de la fusion d'information qui est proposée dans (Claire et al .,
2007). Dans le cadre précis de nos travaux, nous sommes attachés à l'exploitation des
bases de connaissance afin de déterminer des comportements communs que présente
un ensemble de données. Notre approche est divisée en 4 étapes : concevoir la base de
connaissance, extraire des observations, apprendre ou inférer des connaissances à
partir de ces observations et enfin générer des modèles de situation. Le modèle de
situation est un ensemble d’informations qui décrit au mieux une situation précise ou
un ensemble d’observations en d’autre terme le modèle de situation est une extraction
des informations pertinentes correspondant à des observations dans une base de
connaissance. La conception de système à bases de connaissances capable de réaliser
les fonctions de raisonnements constitue à l’heure actuelle un champ de recherche en
intelligence artificielle.
L'approche que nous avons proposée au cours de notre stage consiste à créer et
enrichir une base de connaissances structurée reposant sur le paradigme des données
liées aux formalismes du Web Sémantique (OWL2) et aux graphes conceptuels.
Ensuite, un algorithme d'apprentissage fondé sur la Programmation Logique Inductive
(PLI) est proposé pour déterminer les informations communes et pertinentes pour un
groupe de données. La sortie de l’algorithme est donc qualifiée de modèles de situation
Les résultats obtenus par notre approche sont satisfaisant au dire d'expert et en
plus, l’algorithme proposé réussit à déterminer des modèles de situation dont la
précision sur d’autres données est très proche de la précision du modèle obtenu
(différence de 4%). Ces résultats constituent une avancée pour une proposition des
modèles de situation aux utilisateurs. Mais d’autres améliorations sont à prendre en
compte afin de raffiner les modèles de situation obtenus. Comme améliorations, on
peut prendre en compte l’évolution de l’ontologie ou d’autres ontologies. On peut
aussi proposer un nombre réduit de modèles de situation afin de permettre une
meilleure couverture de tous les exemples d’apprentissage.
Mots clés : Ontologie, programmation logique inductive, fusion d'information
vi
In this work, we focus on the acquisition and exploitation of large structured
knowledge bases problems for supporting the decision making process in the
aeronautics fields. We also focus our study on the improvement of information fusion
method proposed by (Claire et al., 2007). Particularly, we worked on the exploitation
of the knowledge databases in order to determine the common behavior of a set of
data. Our proposed approach is divided into four steps: design the knowledge
databases, retrieve observations, learn or infer knowledge from these comments, and
finally generate situation models. The situation model is a set of information that best
describes a particular situation or set of observations. In other words, the situation
model is the extraction of relevant information that corresponds to some observations
in the knowledge database.
The design of knowledge system that be able to perform reasoning function is a
challenging field of research in artificial intelligence. The aim of our proposed
approach is to create and enhance a structured knowledge database that belong to the
data paradigm related to the Semantic Web formalisms (OWL2) and conceptual
graphs. Then, we proposed a learning algorithm based on the Inductive Logic
Programming (ILP) in order to determine the common information for a data group
(situation model).
The results of our approach are satisfying according to the expert and in
addition, the proposed algorithm is able to identify situation models whose accuracy
on other data is very close to the accuracy of the resulting model (difference of 4
percents). These results represent a breakthrough for a proposal of situation models to
users. But other improvements are considered in order to refine the situation models
obtained. As improvements, we can take into account the evolution of ontology or
other ontologies. One can also provide a reduced number of situation models to enable
better coverage.
Keywords: Ontology, inductive logic programming, information fusion
vii
Figure 1: Exemple de graphe conceptuel ........................................................................ 4
Figure 2 : Résultats expérimentaux de DL-Foil en termes de mesures IR standards:
moyennes ± écart type [min ;max]................................................................................ 10
Figure 3: Architecture de DL learner ............................................................................ 11
Figure 4: Étape de génération de modèle de situation .................................................. 16
Figure 5: Visualisation graphique de l’ontologie ASRS .............................................. 18
Figure 6: Exemple de requête SPARQL ....................................................................... 19
Figure 7: Résultat de DL learner avec comme exemple <<Les incidents ambigus>> . 20
Figure 8: Opérateur utilisé pour le langage de l'opérateur de raffinement ................... 23
Figure 9: Définition de l'opérateur de raffinement ....................................................... 23
Figure 10: Illustration d'une recherche par raffinement d'opérateur ............................. 24
Figure 11: Illustration de la redondance de ࣋ ՝ ............................................................ 26
Figure 12: Exemple de requête SPARQL correspondant au scénario 1 ....................... 30
Figure 13: Exemple de requête SPARQL correspondant au scénario 2 ....................... 30
Figure 14: Différence d’exactitude entre les données d'apprentissage et celle de tests
(Scénario1) .................................................................................................................... 34
Figure 15: Différence d’exactitude entre les données d'apprentissage et celle de tests
(Scénario2) .................................................................................................................... 37
viii
Tableau 1: Comparaison GC et OWL2 ........................................................................... 6
Tableau 2: Comparaison DL-learner, DL-foil et YINYANG ...................................... 13
Tableau 3: Description concernant l'ontologie utilisée pour les expérimentations ...... 29
Tableau 4: Paramètres d'entrée pour la génération de modèles de situation ................ 31
Tableau 5: Résultats d'apprentissage du scénario 1 ...................................................... 32
Tableau 6: Modèles de situation du scénario1 .............................................................. 33
Tableau 7: Résultats d'apprentissage du scénario 2 ...................................................... 35
Tableau 8: Modèles de situation du scénario 2 ............................................................. 36
ix
Introduction
Le monde d’aujourd’hui est marqué par la présence de masses de
données dont l’exploitation peut affecter de façon profonde grand nombre de
secteurs (de l’e-commerce à la recherche scientifique en passant par la finance
et la santé). Les organismes, les entreprises, les particuliers ont généralement en
leur possession un grand nombre de données et arrivent rarement à bien les
exploiter. Afin d’être capable d’extraire des informations dans ces bases de
connaissances, on fait généralement appel aux experts et ingénieurs pour
structurer et exploiter les données.
L'exploitation de ces immenses masses de données nécessite des
techniques sophistiquées visant à extraire l'information pertinente. Le
mécanisme d’extraction d’informations pertinentes est porteur de nombreux
défis qui requièrent une approche interdisciplinaire (statistiques numériques,
apprentissage statistique ou machine learning). Ces approches vont de l’analyse
de données exploratoires aux techniques les plus sophistiquées comme
l’inférence et la classification. En général une vaste palette de méthodes
statistiques mathématiques et d’apprentissage est mobilisée pour parvenir à
mieux exploiter les données.
Ainsi, l’objectif de notre étude est de proposer une approche permettant
de générer un modèle d’extraction des informations pertinentes dans une base
de connaissance. Dans ce document, ce modèle sera appelé modèle de situation
car les informations extraites doivent décrire une situation correspondant à une
réelle expertise.
C’est dans cette optique que s’inscrit mon stage intitulé : « Réalisation
d’un modèle de filtrage de données ».
Les différentes tâches à accomplir sont les suivantes :
-
Modélisation ontologique d’une base de données existante ;
Création d’un algorithme pour générer un modèle de situation ;
Evaluation du modèle de situation créé sur des données des cas
d’utilisation.
Notre travail s’inscrit en effet dans le cadre de la fusion d’information
qui est l’un des thèmes de l’équipe du LRASC et dont l’objectif est d'améliorer
la connaissance du monde observé pour le décrire du mieux possible pour
l’utilisateur. Le modèle de situation sera ajouté comme entrée dans le processus
1
de fusion (Fossier, et al., 2013). Le travail effectué au cours de cette étude s’est
déroulé au sein du LRASC (Laboratoire Raisonnements et Analyses dans les
Systèmes Complexes) à Thales Research &Technology et du laboratoire LRI
(Laboratoire de Recherche en Informatique) de l’université Paris-Sud, équipe
LAHDAK dont les travaux portent sur des propositions d’infrastructures
adaptées à la gestion de données et de connaissances massives et hétérogènes
plus ou moins complexe.
Pour rendre compte du travail effectué tout au long de cette étude, nous
avons rédigé ce rapport qui s’organise en trois sections. Dans la section 1, nous
ferons une synthèse bibliographique du domaine d’étude. Dans la section 2,
nous présentons l’approche proposée pour la réalisation du modèle de filtrage
ou encore pour l’obtention de modèles de situation. Dans la section 3, nous
présentons les résultats d’expérimentations et les analysons. Enfin, nous
concluons ce rapport par le bilan des apports de notre contribution ainsi que par
la présentation rapide de quelques perspectives ouvertes par notre travail.
2
Contexte :
Nos travaux s’inscrivent dans le domaine plus large de la fusion
d’information. Le terme « fusion d’information » est apparu dans les années 90
dans le but de gérer et de mettre en correspondance un ensemble d’informations
provenant des données multi-sources et à les exploiter. Depuis quelques années
de nombreux algorithmes de fusion ont été développés pour les applications
dans des domaines tels qu’intelligence artificiel, imagerie satellitaire et aérienne
...
Cependant, pour pouvoir appliquer ou utiliser des algorithmes de fusion,
les experts de domaines doivent filtrer de leur base de connaissance, les données
qui sont les plus significatives avant d’effectuer le processus de fusion. Ces
données significatives sont celles qu’on qualifie de modèle de situation. Le
modèle de situation est ensemble de données structurées qui décrit des
observations d’un utilisateur afin de lui donner une meilleure compréhension.
En d’autres termes, le modèle de situation est une structure qui permet de
décrire au mieux possible ce qu’ont en commun un ensemble de données.
Avant de pouvoir obtenir le modèle de situation, il est important de
trouver un formalisme de représentation des données et une méthode pour
extraire les informations communes.
Dans cette section, nous présentons quelques notions importantes en
relation avec notre domaine d’étude à savoir : les langages de représentation de
connaissance et l’apprentissage.
1.1. Langages de représentation des connaissances
La représentation des connaissances est une discipline de l’IA destinée à
représenter et à organiser un ensemble de connaissance dans le but de la
partager, d’interroger et même de raisonner (combiner un ensemble
d’informations préalablement connues afin obtenir une information qui en
découle). La problématique de la recherche en représentation des connaissances
est de fournir des modèles formels de représentation qui permettent d’une part,
de modéliser facilement la connaissance et d’autre part, d’exploiter cette
connaissance lors de la résolution d’un problème donné. Plusieurs formalismes
de représentation existent mais dans cette partie nous nous intéressons qu’aux
3
formalismes qui nous permettrons à faire des raisonnements logiques sur les
connaissances à savoir graphe conceptuel et le langage OWL.
1.1.1
Graphe conceptuel
Le modèle des graphes conceptuels (GCs) est un modèle formel de
représentation des connaissances fondé sur la description de concepts qui est
introduit dans (Sowa, 1984). Les connaissances exprimées dans ce modèle se
structurent en deux niveaux : un niveau terminologique encore appelé support
ou vocabulaire est principalement composé d’un treillis de concepts et d’un
ensemble ordonnée de relations conceptuelles. Le second niveau est dit
assertionnel ou factuel et permet décrire les faits ou observations par des
graphes cela en se basant des éléments du niveau terminologique. Plusieurs
extensions de ce modèle ont été proposées chacun dans le but d’enrichir la
méthode de représentation de connaissance (les types conjonctifs, les règles, et
des contraintes). Le modèle des graphes conceptuels, s’appuie sur une
représentation graphique des connaissances et permet le raisonnement. Le
raisonnement étant réalisé par des algorithmes de graphes (principalement la
recherche d’isomorphisme de graphe). Il dispose en plus d’une fonction
d’interprétation logique qui permet de doter le modèle d’une sémantique
formelle. Ainsi tout graphe conceptuel peut être représenté en logique de
description du premier ordre.
Un graphe conceptuel est un graphe biparti orienté dans lequel les nœuds
(concept et relation) sont liés par des arcs orientés
Type Concept: Marqueur
relation
Type Concept: Marqueur
Figure 1: Exemple de graphe conceptuel
1.1.2
Langage du Web Sémantique
Les ontologies sont apparues au début des années 90 en ingénierie des
connaissances, dans le cadre des démarches d’acquisition des connaissances
pour les systèmes à base de connaissances. Dans ce contexte, les chercheurs ont
proposé de fonder ces connaissances sur la spécification d’une ontologie,
ensemble structuré par différentes relations entre des objets du domaine dont
l’élaboration relève du choix du modélisateur. Les ontologies fournissent une
capacité de stocker les connaissances générales, d’une manière qui est
compréhensible à la fois par les humains et les ordinateurs. Nous ne considérons
qu’un sous-ensemble des ontologies : les ontologies OWL, permettant la
4
production d’inférences de nouvelles données à partir des données déjà
présentes dans la base. Ces ontologies contiennent entre autre des axiomes
permettant de spécifier des contraintes d’appartenances des individus à une
classe.
OWL2 est une recommandation du consortium du W3C. Il vise
également à rendre les ressources sur le Web aisément accessibles aux
processus automatisés en les structurant d’une façon compréhensible et aussi en
leur ajoutant des méta-informations (McGuinness & Harmelen, 2004). Pour
cela, OWL offre des moyens puissants pour exprimer la signification et la
sémantique que XML, RDF, et RDF-S n’offrent pas. OWL ajoute des
vocabulaires pour la description des propriétés et des classes, des relations entre
classes, des cardinalités, des caractéristiques de propriétés (symetry), et des
classes énumérées. Tandis que RDF-S permet de définir seulement la hiérarchie
entre les classes et propriétés. OWL a été donc développé comme une
extension du vocabulaire de RDF. De plus, à l’aide nombreux plugin (OWL
Api, Jena API) OWL permet l’intégration des ontologies c’est à dire permet la
construction de nouvelle ontologie à partir de zéro ou à partir d’autre déjà
existante, elle permet l’utilisation des ontologies dans les applications et enfin
elle permet la fusion de plusieurs ontologie en une seule.
1.1.3
Tableau comparatif des GC et OWL2
Dans (Raimbault, 2008) ces deux formalisent bien qu’ils soient
similaires à la logique de description, ils ont des différences. La plus notoire est
au niveau d’expressivité des connaissances. Par exemple la notion de
complémentarité est partiellement définie en graphe conceptuel tandis que celle
d’énumération ne l’est pas. D’après le tableau ci-dessous, on peut remarquer
que pour la représentation des connaissances en OWL offre un vocabulaire le
plus riche. Ainsi, la majorité des notions d’un système sont donc généralement
(totalement) instanciables dans les modélisations basées sur OWL2.
Graphe conceptuel
OWL2
Classe
Oui
Oui
Sous classe
Oui
Oui
Relation
Oui
Oui
Notions
5
Individus
Oui
Oui
Equivalence
Oui
Oui
Intersection
Oui
Oui
Union
Oui
Partiellement
Complément
Oui
Partiellement
Enumération
Oui
Non
Restriction de cardinalité
Oui
Partiellement
Tableau 1: Comparaison GC et OWL2
Après avoir fait une brève présentation des formalismes de
représentation de connaissances reposant sur le paradigme des données liées tel
que la technologie du Web Sémantique « OWL » et les graphes conceptuels,
nous présentons des méthodes qui permettent d’inférer des connaissances à
partir des bases de connaissances.
1.2. L’apprentissage automatique
L'apprentissage automatique (machine learning en anglais), champ
d'étude de l'intelligence artificielle qui concerne la conception, l'analyse, et
l'implémentation de méthodes permettant à une machine d'évoluer par un
processus systématique. Grace à l’apprentissage, la machine devient capable de
remplir des tâches difficiles ou impossibles à remplir par des moyens
algorithmiques plus classiques. L’objectif de l’apprentissage automatique est de
produire automatiquement des règles. Plusieurs méthodes sont utilisées pour y
parvenir: les arbres de décision, la programmation génétique, les réseaux de
neurones, la programmation logique inductive. Dans cette partie nous nous
intéressons seulement à l’apprentissage en logique de description puisque le
formalisme de représentation de connaissances est aussi lié à la logique de
description.
6
1.2.1
Généralités sur la programmation logique inductive (PLI)
La Programmation Logique Inductive ou PLI (en anglais Inductive Logic
Programming, ILP) peut se définir comme étant à l'intersection de
l'apprentissage automatique et de la programmation logique. L'apprentissage
automatique, et plus précisément de l'apprentissage inductif, permet de
développer des outils et des techniques permettant d'induire des hypothèses et
de synthétiser de nouvelles connaissances à partir de l'expérience.
La PLI hérite d'un langage de représentation des connaissances palliant
les limitations des approches non logiques de l'induction (en particulier
l'absence de prise en compte d'une théorie du domaine) et les techniques et
théories bien établies de ce domaine. La Programmation Logique Inductive
avait à l'origine pour objectif l'inférence de programmes logiques à partir
d'observations et relativement à une théorie du domaine. Son application s'étend
aujourd'hui à l'apprentissage de concepts en logique de description.
Formellement, la programmation logique inductive est une combinaison
de l’apprentissage automatique et de la programmation en logique. Elle est
décrite de la façon suivante (Lavrac & Dzeeoski, 1994) :
Entrées : Trois ensembles, ࡱା et ࡱି avec
· Une base de connaissance
· Un ensemble d’exemples
· Un ensemble de contre -exemples
ࡱା
ࡱି
Sortie : Trouver une hypothèse H vérifiant les propriétés suivantes
· La complétude
· La consistance
۶ ٪ ࢋࡱ א ܍ା
۶ ିࡱ א ܍ࢋ ٮ
On cherche donc à trouver une hypothèse H qui permet d’expliquer au
mieux les exemples positifs, tout en rejetant au maximum les exemples négatifs.
Elle se base souvent sur l’utilisation d’autres techniques liées à la
programmation logique comme la substitution, la spécialisation, la
généralisation, l’unification et la résolution.
La complexité d’apprentissage d’une nouvelle hypothèse dépend du
langage de la logique qui est choisi (Franz Baader, 2003). Plus le langage est
complet, plus la complexité est grande.
7
En programmation logique inductive, on distingue trois grandes
approches pour l’apprentissage d’hypothèses. La première approche, dite
descendante ou top-down, consiste à partir d’une hypothèse générale et aller
vers une hypothèse plus spécifique en respectant les règles définies dans la base
de connaissances. Cette approche a pour principale but d’induire une nouvelle
hypothèse. Dans la littérature, on a plusieurs systèmes qui sont développés avec
cette approche : CIGOL (Muggleton & Buntine, 1992), CLINT (De Raedt,
1992), GOLEM (Muggleton & Feng, 1990), ALEPH (Srinivasan, version4)
La seconde approche (bottom-up) qui est "l’inverse" de la première,
consiste à partir d’une hypothèse plus spécifique et se diriger vers une
hypothèse générale. Elles sont généralement implémentées à l’aide des
méthodes comme Least Subsumer Common et Most Specific Concept (Cohen
et al., 1992). ࡸࡿሺǡ Ǥ Ǥ Ǥ ሻ ൌ où ܥest le concept le plus spécifique qui
subsume tous les Ci (c’est à direܥ אሼܥଵ ǡ ǥ ǡ ܥ ሽǡ ܥܽ݊ ك
ܥሺܥ݁݉ݑݏܾݑݏܥ ሻ.
Cette approche est utilisée par des systèmes tels que : FOIL (Quinlan,
1995), PROGOL (Muggleton, 1995), CLAUDIEN (De Raedt & Dehaspe,
1996).
Et la troisième approche est juste une combinaison des deux précédentes
et on la retrouver dans le système PROGOLEM (Muggletton et al., 2010)
Le véritable problème en programmation logique inductive est la
définition de l’espace de recherche des hypothèses. L’espace de recherche
d’hypothèses représente toutes les hypothèses existantes dans une base de
connaissance. Ainsi il est important de choisir et d’utiliser une méthode ayant
une complexité raisonnable afin toutes ces hypothèses. Le parcours de l’espace
de recherche est généralement effectué par le biais de l’opérateur de
subsomption. Chaque méthode de PLI diffère les unes des autres par deux
grands facteurs, la taille de l’espace de recherche et la qualité de l’hypothèse
trouvée (hypothèse couvrant au mieux les exemples positifs et aucun exemple
négatif).
1.2.2
Apprentissage sur des ontologies (OWL)
Trois principaux algorithmes de la PLI permettent l’apprentissage sur des
ontologies OWL à savoir DL-FOIL (Fanizzi, 2008), DL-Learner (Lehmann et
al., 2011) et YINYANG (Luigi et al., 2005). Dans cette sous-section, nous
présentons ces trois algorithmes et nous faisons une étude comparative afin de
trouver lequel est mieux adapté pour résoudre notre problème.
8
1.2.2.1.
DL-Foil
DL-Foil est une approche d’apprentissage des concepts en logique de
description ALC et elle est proposée dans (Fanizzi, 2008), Le principe de cette
approche est de commencer avec une règle très générale Ensuite la spécialise en
ajoutant des hypothèses jusqu’à ce que la règle ne couvre plus aucun exemple
négatif. Les grandes étapes de cette idée sont :
· La première étape consiste à définir l’opérateur de raffinement qui est un
opérateur non complet pour la grande expressivité de la logique de
description d’après les propriétés de raffinement d’opérateur (Hitzler &
Lehmann, 2008). Ensuite par le biais de cet opérateur, la méthode
effectue des spécialisations dans le but d’obtenir des hypothèses qui ne
couvrent aucun exemple négatif ou du moins qui en couvrent très peu
(inférieur à un seuil). Ceci marque la condition d’arrêt de l’algorithme.
· La deuxième étape consiste à choisir l’hypothèse où le concept ayant la
plus grande fonction de gain. Cette fonction est définie par :
ͳǤ ቂ݈݃
ଵା௨ଵ௪ଵ
ଵାଵା௨ଵ
െ ݈݃
ା௨௪
ቃ Où
ାା௪
§ ͳǡ ݊ͳ݁ ͳݑݐreprésentent respectivement le nombre d’exemples positif,
négatif et non marqué couverts par la spécialisation.
§ Ͳǡ ݊Ͳ݁ Ͳݑݐreprésentent respectivement le nombre d’exemples positif,
négatif et non marqué couverts par l’ancienne définition.
§ w0, w1 sont déterminés par la probabilité a priori des exemples positifs,
respectivement dans la définition actuelle et l'ancienne définition.
L’idée est de conserver une seule hypothèse et de la modifier pour
conserver la compatibilité avec les exemples.
· La troisième et dernière étape est celle de spécialisation. Cette étape
consiste à effectuer des appels des services du raisonneur dans le but de
rechercher les subsomption et des vérifications des instances. Ces
opérations se font en une complexité de P-space1.
Les résultats d’expérimentation montre que, en évaluant les résultats en
utilisant la notion de précision/rappel, on a des résultats (autour de 65%) mais
pas assez élevé (fig.2). La principale raison est due à l’hypothèse de monde
ouvert qui ne peut pas dire qu'une chose n'existe pas tant qu'il n'a pas été
explicitement statué qu'elle n'existait pas. Un autre résultat d’expérimentation
est que les concepts appris se chevauchent totalement avec les requêtes et par
conséquent, les concepts retournés ont une certaine familiarité avec les
1
P-SPACE est la classe des problèmes qui peuvent être résolus en espace polynomial sur une machine
déterministe. (encyclopédie Wikipédia)
9
ontologies choisies. Notons toutefois que la définition incomplète de l’opérateur
de raffinement ne permet pas de couvrir ou d’avoir tous les concepts possibles
de l’espace de recherche.
Figure 2 : Résultats expérimentaux de DL-Foil en termes de mesures IR
standards: moyennes ± écart type [min ;max]
1.2.2.2.
DL-Learner
DL Learner est un framework développé en Java pour l’apprentissage en
logique de description des données provenant des fichiers OWL, fichier NTriple, SPARQL end points). C’est un framework qui utilise l’approche ILP
donc pour un ensemble d’exemples (positifs et négatifs), il trouve une
expression de classe OWL couvrant au mieux les exemples. Les résultats
fournis par DL learner sont les plus réduits possibles et faciles à comprendre par
les experts du domaine. DL Learner prend en compte beaucoup d’autres aspects
pour l’apprentissage par exemple les données provenant de sparql endpoints2,
ou des N-triples. Il contient aussi des raisonneurs (aussi des raisonneurs flous
(Lehmann & Iglesias, 2011)) propres à lui qui facilitent la réduction de l’espace
de recherche des hypothèses. Notons que les résultats d’apprentissage sont
retournés en logique ALCN.
DL learner est constitué de 4 principaux composants (fig.3)
-
2
Le composant de source de connaissance qui définit tous les formats de
type de données pris en compte par le système.
Le composant « problème d’apprentissage » : composant dans lequel on
spécifie le type d’apprentissage souhaité. Il peut s’agir un apprentissage
avec exemples positifs seulement, un apprentissage avec exemples
positifs et négatifs ou d’un apprentissage de définition de concepts.
www.w3.org/wiki/SparqlEndPoints
10
-
-
Le composant « algorithme d’apprentissage » est celui dans lequel est
développé tous les algorithmes d’apprentissage et dont CELOE (Class
Expression Learning for Ontology Engineering) est celui qui nous
intéresse.
Le composant « service de raisonneur » : c’est dans ce composant que
tous les algorithmes de raisonneurs sont disponibles. Il offre la
possibilité d’inclure les raisonneurs tels que : Pellet, FaCT++, KAON2,
et Racer Pro.
Figure 3: Architecture de DL learner
L’idée est la même que dans les approches top-down. Pour chaque nœud
de l’espace de recherche, on calcule le score qui est donné par
11
Le nœud ayant la plus grande valeur d’exactitude (‘accuracy’) est choisi et
l’algorithme continue jusqu'à trouver une hypothèse la meilleure hypothèse
possible. Au cas où il n’y a pas d’hypothèse ayant une exactitude de 100%, le
critère de temps est utilisé pour stopper l’exécution de l’algorithme.
Ø Algorithme
L’apprentissage d’un concept va consister à mettre à jour l’espace de
recherche (Lehmann & Hitzler, 2010) et de calculer le score de ces nœuds
ajoutés après raffinement. Le nœud ayant le plus grand score est exploré. Ce
processus s’arrête lorsqu’on obtient une exactitude ( ݍ ȁ ܧȁ ൈ
א ݐ݅ݑݎܤܿ݁ݒܽݐ݅ݑݎܤሾͲǢ ͳሿ )
Sachant que les nœuds dans l’espace de recherche sont ordonnés grâce à
l’opération de subsomption, l’algorithme ne s’intéresse qu’au n premiers nœuds
à chaque étape jusqu'à trouver une hypothèse ayant une bonne exactitude. Ce
choix des n premiers nœuds certes diminue la taille de l’espace de recherche
mais empêche d’autres hypothèses de faire partir de la solution.
1.2.2.3. YINYANG (Yet another INduction Yields to ANother
Generalization)
Cette approche a été mise au point dans le but principal d’aider à la
création manuelle des ontologies. En fait le système se base sur des définitions
déjà faites dans l’ontologie pour compléter celle souhaitée. Donc, il prend en
entrée les exemples et aussi une définition de concept qui peut être trop général
ou pas correct et ensuite déterminer une nouvelle définition. Par contre, les deux
12
autres approches précédentes ont la possibilité d’apprendre juste avec des
exemples qui leur sont fournis. Il utilise aussi comme logique de description
ALC. La méthode est la suivante : pour chaque exemple il cherche d’abord le
concept le plus spécifique (MSC=Most Specific Concept) correspondant. Et la
conjonction de ces concepts est utilisée pour désigner des exemples positifs et
négatifs. Ensuite une généralisation est faite sur les exemples tout en la
spécialisant au mieux pour éliminer les exemples négatifs. C’est pourquoi cette
approche est qualifiée d’hybride car une spécialisation et une généralisation
sont faites pour la recherche de meilleure hypothèse.
1.2.2.4.
Tableau comparatif
Nous présentons dans cette partie une petite comparaison des trois
systèmes. D’après le tableau DL learner est le système qui présente le plus
d’avantage comparé aux deux autres.
Algorithme
DL-Learner
DL-FOIL
YINYANG
1 Format de
l’ontologie
OWL/Ntriple/Sparql
endPoints
OWL
OWL
2 Logique de
description
EL/ALCN
ALC
ALC
3 Type
d’apprentissage
Exemple positif et
négatif / Exemple
positif seulement
Exemple
positif et
négatif
Exemple
positif et
négatif
4 Hypothèse retournée Une / plusieurs
Une
Une
5 Caractéristique de
l’espace de
recherche
Top-down
Top-down
Top-down /
bottom-up
6 Système
Disponible/ Opensource
Non
disponible
Disponible
Tableau 2: Comparaison DL-learner, DL-foil et YINYANG
13
En effet, DL Learner permet d’apprendre des nouvelles définitions de
concepts seulement avec des exemples positifs, il retourne des concepts
compréhensibles par les humains, il présente avec plus de détail la définition de
son heuristique qui facilite et réduit le parcours de l’espace de recherche et
pour terminer il est un système open source. Tous ces critères nous ont permis
de le comprendre et de pouvoir définir par exemple l’heuristique nécessaire
pour apprendre seulement les exemples positifs.
Conclusion
En somme, nous avons présenté deux approches de représentation de
connaissances, et trois approches d’apprentissage logique basé sur les
ontologies OWL.
Pour notre problème nous optons donc pour le formalisme OWL pour la
représentation de la base de connaissance et de l’algorithme DL Learner sera
utiliser (modifié) pour obtenir le modèle de situation parce qu’il présente les
avantages telles que décrit dans le tableau2. Comme par exemple, il peut nous
retourner des modèles de situation. Ces modèles de situation ou résultats de DL
learner ne sont pas toujours pas idéale et intéressant pour les utilisateurs. Nous
allons décrire dans le chapitre précédent pourquoi doit-on modifier DL learner
et comment on peut obtenir un bon modèle tout en exploitant certains principes
développées dans DL learner.
14
Dans ce chapitre, nous souhaitons, pour une base de connaissance et un
ensemble d’observation, déterminer ce qu’ont en commun et de pertinent les
différentes observations généralement appelées exemples positifs. Le but final
est de déterminer des modèles de situation. Un modèle de situation est décrit
comme étant un ensemble d'informations pertinent correspondant à une
situation. Notons toutefois qu’une situation est mieux présentée si elle décrit au
maximum tout ce qui est relaté dans les observations de l’opérateur.
Pour résoudre ce problème, nous utilisons l’approche ILP, qui, à partir
d’une base de connaissance K et d’un ensemble d’exemples ܧൌ ܧା détermine
une hypothèse qui satisfait au mieux tous les exemples positifs.
ܪ٪ ݁ ܧ א ݁ା Comme mentionné dans l’état de l’art l’algorithme d’apprentissage de
DL Learner est choisi pour apprendre ou rechercher les concepts qui couvrent le
maximum d’exemples, nous nous focalisons donc sur ce dernier pour proposer
une approche de génération de modèles de situations.
Dans la première partie, nous présentons le processus général choisit
pour l’obtention du modèle de situation, ensuite, nous présentons la
modélisation OWL de la base ASRS, et enfin nous présentons les étapes et
algorithmes de génération de modèles.
Intérêt du modèle proposé
Notre travail vise à concevoir des modèles permettant de donner de
manière automatique une description d’un ensemble de donnée provenant d’une
base de connaissance.
Ces modèles permettront de comprendre et voir les points de similarité
entre les différents exemples choisis. Ils seront donc utilisés par les experts pour
des prises de décision par rapport au phénomène observé. Ils seront aussi
utilisés comme paramètre d’entrée dans le processus de fusion d’information.
15
2.1. Etape de génération du modèle de situation
Nous allons présenter une approche pour l’obtention d’un modèle de
situation. L’approche proposée est constituée de 4 étapes et elle utilise les
formalismes discutés précédemment.
· Étape 1 : Modéliser la base de connaissance sous une ontologie OWL
(due à son grand pouvoir d’expressivité)
· Étape 2 : Extraction de la base de connaissance d’un sous-ensemble
d’entités représentant les besoins de l’utilisateur. Ces données sont
appelées exemples ou observations et correspondent donc à une
situation précise. Cette extraction est faite par une requête SPARQL.3
· Étape 3 : Algorithme d’apprentissage qui pourra extraire les concepts qui
correspondent au modèle de situation en logique de description. C’est à
dire que nos modèles de situation sont décrits en logique de description.
· Étape 4 : Spécialisation des résultats d’apprentissage pour la recherche
de modèle
Le schéma (fig.3) ci-dessous présente un résumé des différentes étapes du
processus d’obtention d’un modèle de situation. Le processus d’obtention du
modèle de situation étant très long nous nous sommes focalisé dans ce mémoire
dans la proposition d’un algorithme d’apprentissage générant le modèle de
situation en logique de description, c’est à dire à l’étape 3.
1. Requête
2. Extraction d’entité
Base OWL
(Exemple positif)
3. Apprentissage
4. Modèle Situation
Figure 4: Étape de génération de modèle de situation
3
http://www.w3.org/TR/rdf-sparql-query/
16
2.2. Étape1 : Modélisation de la base de connaissance
Dans cette partie, on s’intéresse à des bases de connaissances « dirigées
par une ontologie », c’est-à-dire comportant deux grands types de
connaissances. Les connaissances structurelles ou axiomes ontologiques qui
permettent de fixer la sémantique du vocabulaire à utiliser. Et les connaissances
factuelles qui décrivent des situations spécifiques relatives à une entité
individuelle du domaine. La diversité de formats de représentation de la
connaissance pose parfois le problème de choix pour déterminer la structure la
mieux adapter pour le problème. Pour notre problème, il était question d’utiliser
l’un des deux formalismes présenté au chapitre 1. Et le choix s’est donc porté
sur le formalisme OWL qui présente un plus grand niveau d’expressivité des
données car il contient plusieurs familles de langage comme EL, ALC, SHOIN
(Baader et al., 2003)
La base ASRS est une base de données en ligne 4 qui contient une
description de différents événements (incident) dans le domaine aéronautique.
Elle décrit pour chaque événement, les conditions (climat, lieu, le type d’avion
…), les causes (anomalies), et les conclusions. La base est exportable sous
plusieurs formats : word, excel, csv. Nous avons développé une méthode qui
transforme un fichier excel en un fichier OWL.
La base a été modélisée comme présentée sur la figure 5. En fait nous
nous sommes basés sur la taxonomie déjà disponible (Annexe) pour représenter
les connaissances structurelles et en parsant chaque ligne du fichier Excel, on
extrait des données qui nous permettent de représenter des faits ou des
observations. La construction de la base est faite à l’aide de l’API OWL. L’API
OWL (OWLAPI1, 2015) est une interface Java mise en œuvre par le W3C qui
est utilisée pour représenter les ontologies du Web Sémantique.
4
www.asrs.arc/nasa.gov
17
Figure 5: Visualisation graphique de l’ontologie ASRS
2.3. Étape 2 : Extraction d’exemples positifs
Pour cette deuxième étape, on voudrait choisir les exemples dont on
souhaite trouver une description commune. La méthode d’extraction
d’exemples utilisée est la requête SPARQL. SPARQL est utilisé pour diriger
l’étape d’apprentissage et considérer un ensemble bien défini de types
d’incident. Notons toutes fois qu’étant donné que l’utilisateur peut ne pas
maitriser comment définir sa requête, il peut entrer ses exemples sous la forme
« incident1, incident3, incident21.. » La figure 6 présente un exemple de
requête dans la base ASRS. La requête permet de sélectionner les incidents qui
dont le problème primaire est ambigu.
PREFIX inc :
SELECT ?incident
WHERE {?incident inc: hasAssessment ?assessment
.
? assessment inc:hasPrimaryProblem inc:ambiguous
}
18
Figure 6: Exemple de requête SPARQL
2.4. Étape 3 : Apprentissage
L’étape d’apprentissage se fait en utilisant l’approche top down des
algorithmes d’apprentissage. Dans cette partie, nous allons décrire comment on
réussit à extraire des concepts qui sont nécessaires pour le modèle de situation.
L’approche proposée se base sur DL learner (Jens Lehmann, 2010). Mais avant
d’y arriver nous présentons d’abord pourquoi l’algorithme d’apprentissage
CELOE (Class Expression Learning for Ontology Engineering) proposé dans
DL-learner ne nous satisfait pas complétement. Lorsqu’on paramètre DL learner
à la recherche de plusieurs concepts qui couvrent un ensemble d’exemple, il
retourne des concepts qui couvrent certes l’ensemble des exemples, mais ces
concepts comportent des expressions qui ne sont pas intéressantes pour le
modèle de situation. En effet généralement le premier résultat est court et ne
donne pas tous les détails sur la situation que l’on souhaite apprendre. Et bien
quand on a des résultats d’apprentissage long, ils contiennent des concepts qui
ne nous apprend rien de nouveau et qui est connu de tous.
Exemple : Problème de DL learner
Les résultats d’apprentissage avec DL learner correspond exactement de
l’apprentissage des incidents dont le problème primaire est mentionné comme
ambigu. Notons que le langage de la logique utilisé est ALCN. Donc d’après les
3 premières lignes de résultat ci-dessous, on note que lorsqu’un bon concept est
trouvé et ayant une exactitude de 100%, l’algorithme de DL learner ajoute à ce
concept d’autres en utilisant les constructeurs union ou intersection.
1- Incident
2- Incident Aircraft
3- Incident Aircraft ( hasPrimaryProblem)
accuracy :100%
accuracy :100%
accuracy :100%
En fait l’algorithme DL learner fait des disjonctions avec d’autres
concepts car il est évident qu’une disjonction d’un concept d’exactitude faible
avec un concept d’exactitude élevée, le résultat final la valeur de l’exactitude
(accuracy). De plus DL learner fait aussi des conjonctions mais avec des
concepts plus généraux que celui trouvé en premier.
19
Le but de travailler avec la logique EL était de voir si DL learner ne
pouvait pas directement rendre comme résultat d’apprentissage des concepts
directement assimilables aux modèles de situation.
Nous présentons une sortir de DL learner à la figure 7 et par la suite nous
présentons les insuffisances.
1: hasAssessment.( hasPrimaryProblem.({Ambiguous})) (pred. acc.:
100,00%)
2: hasAssessment.( hasPrimaryProblem.primaryProblem) (pred. acc.:
100,0%)
3: hasAssessment.( hasContributingFactor.contributingFactor) (pred.
acc.: 100,00%)
4: ( hasAssessment.( hasPrimaryProblem.({Ambiguous}))) ِ (
isDue.component) (pred. acc.: 100,00%)
5: ( hasAssessment.( hasPrimaryProblem.({Ambiguous}))) ِ (
hasPlace.place) (pred. acc.: 100,00%)
6: ( hasAssessment.( hasPrimaryProblem.primaryProblem)) ِ (
isDue.component) (pred. acc.: 100,00%)
- ……………………………………………………………
- ……………………………………………………………
41: hasDetector_Person.({FlightCrew}) (pred. acc.: 81,25%)
Figure 7: Résultat de DL learner avec comme exemple <<Les incidents
ambigus>>
D’après ces résultats, on constate que certains premiers résultats (résultat
2, 4, 5…) ne peuvent pas être considérés comme un modèle de situation car ne
donnent pas des détails sur la situation souhaitée (problème ambigu). Mais
l’exactitude est toujours de 100%. Quand nous observons bien les résultats, on a
au 3eme et au 41ème résultat d’autres informations qui sont intéressantes à savoir
il existe un facteur de contribution et l’incident est détecté par un membre de
l’équipage. Donc, il est difficile de savoir a priori quel numéro correspond à un
résultat intéressant pour le modèle de situation. Pour pallier ces insuffisances,
nous avons modifié le comportement de DL learner afin d’éviter les
redondances, les intersections et les unions avec tout autre concept non
intéressant (définition ci-dessous). L’optimisation du comportement a été gérée
20
par la modification de l’opérateur de raffinement qui est présentée dans la partie
suivante (fig.9).
2.4.1
Définition de quelques notions
· Un concept correspond à une « classe d'éléments » et est interprété
comme un ensemble dans un univers donné. Les rôles correspondent aux
« liens entre les éléments » et sont interprétés comme des relations
binaires sur un univers donné. Les individus correspondent aux éléments
d'un univers donné.
· Un concept est dit intéressant lorsqu’il ne va pas couvrir tous les
exemples de la base de connaissance. En d’autres termes lorsqu’il ne
cause pas un sur-apprentissage.
Exemple : Incident ِ isOn.Aircraft ِ (
hasDetector_Person.({FlightCrew}))
Ce concept comporte 3 expressions et c’est la dernière expression qui est
intéressante pour désigner un modèle car les 2 premiers (Incident et
isOn.Aircraft) ne nous apprennent rien de nouveau (car connu par toutes
personnes familières avec la base).
· Concept élémentaire : est tout concept obtenu sans l’utilisation
d’opérateur tel que l’union, l’intersection. En d’autre terme, il s’agit de
tout concept appartenant à
ሼܥǡ ݎǤ ܦሽîܥǡ ݈ݑ݁ݏݏ݈ܽܿ݁݊ݑݐݏ݁ܦᇱ ݅݊ ݀݁ܿ݊ܽݐݏᇱ ݁ݏݏ݈ܽܿ݁݊ݑሺ݅݊݀݅ ݑ݀݅ݒሻ
ou encore un concept élémentaire
Exemple : incident; ( hasDetector_Person.({FlightCrew})) ;
hasAssessment.( hasContributingFactor.contributingFactor)
Notons que la profondeur maximale d’un concept élémentaire est
au plus n (nє IN). Le concept « hasAssessment.(
hasContributingFactor.contributingFactor) » a pour profondeur 2 .
· Concept spécifique : c’est un concept qui contient des individus
instanciés dans sa description.
· exactitude d’un concept C ("accuracy") est donnée par la formule
࢈
כî
ࢋ࢞ࢇࢉ࢚ሺሻ ൌ ȁࡱȁ
࢈ ൌ ݊ ݀݁ݎܾ݉ᇱ ݁ܥݎܽݏݐݎ݁ݒݑܿݏ݈݁݉݁ݔ
ȁࡱȁ ൌ ݊ ݈݀ܽݐݐ݁ݎܾ݉ᇱ ݁݀ݏ݈݁݉݁ݔԢܽ݁݃ܽݏݏ݅ݐ݊݁ݎ
21
· Bruit : pourcentage d'erreurs. Il permet de détecter si un concept est
intéressant ou non. Le bruit est utilisé pour matérialiser le degré
d’impureté de notre base (valeur manquante, information erronée …)
Exemple : Si ݎ±ܿ݅݊݅ݏሺܥሻ ܰ ݐ݅ݑݎܤ כ ݈݁݉݁ݔܧ݁ݎܾ݉et C n’overfitte pas,
alors ܥest concept intéressant.
L’idée de notre approche est donc de se fonde sur l’existant des fonctions
de DL learner afin de redéfinir l’opérateur de raffinement et de proposer un
algorithme pour obtenir les modèles de situation. Il s’agit de partir de
l’expression la plus générale et évaluer le taux de couverture de l’expression
sur des exemples. Lorsqu’on trouve un concept élémentaire, si le nombre
d’exemples couverts est supérieur aux nombres d’exemples total*bruit, alors ce
concept est ajouté dans l’ensemble solution (RP) et il est ensuite raffiné. A la fin
de l’algorithme, on a dans l’ensemble solution "RP" tous concepts élémentaires
ayant une couverture maximale des exemples.
Pour obtenir des concepts plus spécifiques, on élimine de l’ensemble des
solutions, les concepts qui ne sont pas intéressants et on effectue les
combinaisons (l’intersection) entre les concepts restant et enfin nous retenons
ceux qui ont aussi une meilleure exactitude et sont plus spécifiques. Chaque
nouveau concept obtenu correspond à un modèle de situation.
Ainsi nous effectuons l’apprentissage pour déterminer des concepts
élémentaires et intéressants. Par la suite ces concepts sont combinés pour
trouver un ou des concepts plus longs et plus spécifiques. La longueur et la
spécificité d’un concept nous permet de mieux caractériser un modèle de
situation car nous partons de l’idée selon laquelle une information est bien
décrite si elle contient le plus de détail.
2.4.2
Définition de l’opérateur de raffinement
Le raffinement d’opérateur permet de décrire comment les éléments de
l’espace de recherche seront obtenus. Cela se fait généralement par la relation
de spécialisation. Exemple : L’opérateur de raffinement de ܥnoté ߩሺ ܥሻ ൌ
ሼ ܥᇱ ሽ où ܥǯest une spécialisation de ܥou encore ܥǯ est un sous concept de
ܥnoté (ܥԢ )ܥ ع.
Une telle définition entraîne un très grand nombre de spécialisations.
Mais la définition d’une heuristique va nous permettre de choisir des meilleurs
concepts afin de réduire l’espace de recherche. Cette heuristique est définie par
22
l’exactitude d’un concept. Si un concept a la plus grande valeur d’exactitude,
alors il est qualifié de meilleur concept.
Soit ࡺࢉ l’ensemble de tous les concepts atomiques et ࡺ࢘ l’ensemble de tous les
rôles
Soit ख כle langage de la logique de description qui contient les expressions du
tableau suivant. ࣦ כest le langage utilisé pour définir l’opérateur de raffinement.
Notons que l’opérateur de raffinement telle que défini à la figure 6 ne contient
que les concepts dit élémentaires
Constructeur
Syntaxe
Nom du concept
C
Top
ٹ
٣
Down
ݎǤ ܧ
Quantificateur existentiel
Figure 8: Constructeur utilisé dans le modèle de situation
Pour tout C ܿܰ א, on défini ܾ݊՝ ሺ ܥሻ ൌ ሼ ܥᇱ ȁ ܥᇱ ܿܰ אǡ ݁ ܥݐᇱᇱ א
ܰܿܥ݁ݑݍ݈݁ݐԢ ٌ ܥԢԢ ٌ ܥሽ . ܾ݊՝ ሺ ܥሻ représente l’ensemble de tous les concepts
qui sont directement inférieur au concept C
L’ensemble ܯreprésente l’ensemble de tous les concepts plus généraux et
l’ensemble des rôles.
ܾ݊՝ ሺ ܥሻ ൌ ሼ ܥᇱ ȁ ܥᇱ ܿܰ אǡ ݁ ܥݐᇱᇱ ܥ݁ݑݍ݈݁ݐܿܰ אԢ ٌ ܥԢԢ ٌ ܥሽ
ܯൌ ሼሼܾ݊՝ ሺٹሻሽڂሼݎǤ ٹȁݎܰ א ݎሽ
Définition : L’opérateur de raffinement est défini comme suit : ܥ݅ݏൌ٣
ሼܥ ȁܥ ܯ אሽ ܥ݅ݏൌٹ
ൢ
ߩ՝ ሺ ܥሻ ൌ ൞ ሼ ᇱ ᇱ
ܣȁܾ݊ א ܣ՝ ሺܣሻሽ ܥ݅ݏൌ ܣሺܿܰ א ܣሻ
ሼݎǤ ܧȁߩ א ܧ՝ ሺ ܦሻሽ ܥ݅ݏൌ ݎǤ ܦ
Figure 9: Définition de l'opérateur de raffinement
23
Avec l’opérateur de raffinement et aussi à l’aide d’une heuristique (plus
précisément l’exactitude défini précédemment), on définit pour chaque concept
par l’heuristique doit être spécifié.
Exemple de raffinement
La figure 10 montre un exemple de raffinement de concept avec comme
heuristique l’exactitude et dont le but la recherche de concept élémentaire et
spécifique.
L’exactitude de « incident » est 100% par contre celui de « aircraft » est de 60%
donc la descente dans l’arbre est faite à partir du nœud « incident » et ainsi de
suite.
Т
Incident =100%
Aircraft =60%
ࡵࢉࢊࢋ࢚ ِ
ࢎࢇ࢙ࢇ࢟Ǥ ࢀ
---
----
ࡵࢉࢊࢋ࢚ ِ
ࢎࢇ࢙ࢇ࢟Ǥ ሼࢉ࢚࢘ࢉࢇሽ
Figure 10: Illustration d'une recherche par raffinement d'opérateur
2.4.3
Propriétés de l’opérateur de raffinement
Un opérateur de raffinement à quatre principales propriétés (Hitzler, 2008)
- Fini c’est à dire que l'ensemble des concepts possibles obtenus à travers le
raffinement est en nombre fini.
- Propre qui garantit que chaque étape de raffinement retourne un concept
qui est strictement plus spécifique que le premier. C’est à dire que pour tout
concept C et D, ߩ א ܦሺ ܥሻ implique ܦ ء ܥ
- Complet qui garantit que chaque concept subsumé est accessible à travers une
chaîne de raffinement successive.
- Minimum qui garantit que chaque raffinement possible à partir d'un concept
24
ne peut être atteint par deux chaînes de raffinement différent (non de
redondance de raffinement).
- L’opérateur est dit idéal s’il est fini, propre et complet.
L’opérateur définit à la figure 9 est idéal. La section suivante permet de
démontrer ces propriétés.
La subsomption désigne une relation hiérarchique entre des concepts en
logique de description. Elle coïncide avec la notion d’inclusion.
2.4.4
Preuve des propriétés de l’opérateur de raffinement
Montrons que ߩ՝ est fini
Toute ontologie comporte un ensemble fini de concepts et de rôles donc
ܰܿ et ܰݎsont finis et par conséquent M est fini, ܾ݊՝ est fini. D’après la
définition de ߩ՝ , on a:
-
ሼܥ ȁܥ ܯ אሽ qui est fini puisque M est fini
ሼܣᇱ ȁܣᇱ ܾ݊ א՝ ሺܣሻሽ est aussi fini
ሼݎǤ ܧȁ ߩ א ܧ՝ ሺ ܦሻሽ Pour cet ensemble, nous ajoutons que la
profondeur est ݊ܽ߳݊ܿ݁ݒԳ . C’est-à-dire que tout concept de la
forme ݎǤ ሺݎǤ െ െ ሺݎǤ ܧሻሻሻ doit contenir au plus n rôles. Donc
ሼݎǤ ܧȁ ߩ א ܧ՝ ሺ ܦሻሽest aussi fini.
Montrons que chaque étape de raffinement retourne des concepts plus
spécifiques
L’ensemble ܯcontient tous les concepts qui sont en dessous de Thing et
tous les rôles. Par définition de ߩ՝ il n’est jamais moins général que le concept
initial. Puisque ܾ݊՝ ݁ݐM contiennent des concepts toujours spécifiques (notons
bien l’inclusion stricte dans la définition de ܾ݊՝ )
Montrons que ߩ՝ est complet
Si ܥǯ est un concept subsumé par ( ܥc’est à dire que ܥԢ ٌ )ܥalors il peut
exister un concept C’’ qui est subsumé aussi par C tel que ܾ݊՝ ሺሻ ൌ ሼǯǯሽ .
Ainsi ߩ՝ ሺ ܥሻܿ ܥݐ݊݁݅ݐ݊ᇱᇱ et non ܥԢ. Mais en faisant d’autres raffinements, ܥԢ fera
partir de ߩ՝ ሺ ܥሻ Donc il est garanti que chaque concept subsumé est accessible à
travers une chaine de raffinement.
25
Conclusion : ߩ՝ est un opérateur fini, propre et complet. Mais il n’est pas
minimal. Car, d’après la figure 8, il existe deux chaines de raffinement qui nous
permet d’aller du concept 1 au concept 2 donc il y a redondance et par
conséquent ߩ՝ n’est pas minimal.
Exemple : ߩ՝ ሺܿͳሻ ൌ ሼܿ͵ǡ ܿͶሽǢߩ՝ ሺܿ͵)={c2} et ߩ՝ ሺܿͶሻ={c2}
Concept1
Concept3
Concept4
Concept2
2.4.5
Figure 11: Illustration de la redondance de ࣋՝
Algorithme d’obtention de modèles
L’algorithme d’obtention de modèle est divisé en deux sous algorithme.
Le premier qui correspond à l’apprentissage et le deuxième à une sorte de
fusion.
26
Algorithme : Modèle de situation
1 ܵܶ݀±݈݁݊݃݅ݏǯ݁ݏ݈݅ܽ݅ݐ݄݅݊݅݁ܿݎ݄݁ܿ݁ݎ݁݀݁ܿܽݏ±݄ܶ݅݊݃ሺܶሻ
ʹ ܴܲ݀±݈݁݊݃݅ݏǯ݁݊ݏݐ݁ܿ݊ܿݏ݈ܾ݁݀݁݉݁ݏ±݈±݉݁݊݁ݎ݂݅ܽݐ݊݁ݒݑ݁݅ݑݍݏ݁ݎ݅ܽݐ
݀݉ݑ݀ݎ݅ݐݎܽ°݈݁
3 |E| désigne le nombre d’exemple d’apprentissage
Ͷ ܥൌ ܶ
ͷ ࢚ࢇ࢚࢛ࢋሺ݁ݐܿܽݔሺܥሻ ൌ ܾ כ ݐ݅ݑݎȁܧȁሻ
ܸ± ݈݊݊ܽݎ݂݁݅݅ݎെ ܴܲܥݎ݁ݐݑ݆ܣݐܴ݁ܲݏ݊ܽ݀݁ܿ݊ܽ݀݊݀݁ݎ
ܴ݂݂݈ܽ݅݊݁ݎ݁ݐݑ݆ܣݐ݁ܥݎǯ݄݁݁ܿݎ݄݁ܿ݁ݎ݁݀݁ܿܽݏ
ͺ ݎ݁݀݊ܽݎ݃ݏݑ݈݈ܽݐ݅ܽܥ݁ݑݍ݈݁ݐܥݎ݅ݏ݄݅ܥ±ܿ݅ܶܵݏ݊ܽ݀݊݅ݏ
ͻ ࡲ࢚ࢇ࢚࢛ࢋ
ͳͲ ݀ݏ݁ݏݏ݈ܽܿݎ݁ݑݏݏ݁݀ݐ݊ݏ݅ݑݍݏݐ݁ܿ݊ܿݏ݈ܴ݁ܲݏ݊ܽ݀ݎ݈݁݊݅݉݅ܧǯܽݏ݁ݏݏ݈ܽܿݏ݁ݎݐݑ
ͳͳ ݉݀°݈݁ ൌ ܿݎܾ݁݊݅݉ሺܴܲሻ
ͳʹ ܴ݁݀݉ݎ݁݊ݎݑݐ°݈݁
ݎܾ݁݊݅݉ܥሺܴܲሻ݈ܾ݁݅ݏݏݏ݊ݏܾ݅ܽ݊݅݉ܿݏ݈݁ݏ݁ݐݑݐݎ݁݊ݎݑݐ݁ݎ±݈±݉݁݊݅ݎݐܴܲ݁݀ݏݐ±݁ݏ
݀݁ݎ݀ݎݎܽ±ܿݏ݁݀ݐ݊ܽݏݏ݅ݎ±݂ܿ݅݅ܿ݅ݐ±ǡ ݈݀݁ݐ݁ݏݐ݁ܿ݊ܿݏ݁݀ݎݑ݁ݑ݃݊
݀ǯ݁ݑݏ̶݊݅ݐܿ݁ݏݎ݁ݐ݊݅ݎݑ݈݁݁݀݁݀ݑݐ݅ݐܿܽݔ±ݎݑ݁݅ݎሺͳ െ ݐ݅ݑݎܤ݁݃ܽݐ݊݁ܿݎݑሻ̶
Explication de l’algorithme
Les lignes de 1 à 9 correspondent à l’étape d’apprentissage. Les lignes 1à
4 correspondent à l’initialisation de nos principales variables. La ligne 5 qui
marque la condition d’arrêt de l’apprentissage, permet de considérer tous les
concepts dont l’exactitude est satisfaisante. La ligne 6, vérifie que le concept est
n’existe pas déjà dans RP et l’ajoute. La ligne 7 permet de spécifier le concept
choisit. La spécification est faite en appliquant la méthode de raffinement
définit à la figure 9. La ligne 8 permet de choisir un nouveau concept et
recommencer la boucle.
Les lignes 10 à 12 permettent de générer des modèles de situation. Tout
d’abord à la ligne 10, on éliminer les concepts moins spécifiques qui sont
superclasses d’autres dans la variable RP. Cette ligne permet d’éviter d’autre
redondance et minimiser les modèles de situation proposés. La ligne 11 permet
de fusionner(en utilisant l’intersection)
les concepts obtenus après
apprentissage tout en vérifiant que l’exactitude des modèles retournés soit
±ሺͳ െ
ሻ.
27
L’opérateur de raffinement est défini de tel sorte que les résultats
d’apprentissage soit seulement des concepts dit élémentaires. Par la suite, nous
effectuons des combinaisons des résultats d’apprentissage. La combinaison des
résultats est assimilable à une fusion d’information (concepts élémentaires).
Afin de ne considérer que les modèles ayant une exactitude adéquate (valeur
>1-bruit), on retient comme meilleurs modèles ceux qui contiennent le plus
grand nombre de concept spécifique, ensuite le plus grand nombre de concept
élémentaire et enfin ceux donc l’exactitude est adéquate. Notons que le choix de
nos meilleures modèles vient du fait qu’une information est mieux décrite si elle
contient le plus de détail possible.
Conclusion
En conclusion, nous avons présenté l’approche proposée pour la
génération de modèle de situation. Cette approche que nous avons nommée
ModelSituation est une approche dans laquelle la troisième étape se fonde sur
l’approche de DL learner. Vu que l’approche permet de générer des modèles de
situation, il ne nous reste qu’à attaquer le dernier objectif de notre étude qui est
l’évaluation. Le chapitre suivant se charge de présenter, analyser et évaluer les
résultats des expérimentations effectuées.
28
Dans ce chapitre nous présentons les données utilisées, les scénarios, les
paramètres et les critères d’évaluations. Pour évaluer nos résultats, nous allons
considérer principalement deux critères de comparaisons et deux scénarios
différents. Le premier critère est obtenu à dire d’expert, le deuxième est étape
de test pour vérifier le taux d’exactitude du modèle sur d’autre jeu de données.
Pour l’implémentation des étapes et algorithmes, nous avons choisi
d’utiliser l’éditeur Eclipse avec le langage de programmation Java, car ce
langage comporte plusieurs plugins nécessaires à la manipulation et à la
sérialisation des ontologies (OWL API, API Jena …)
3.1. Présentation des cas d’étude
Nos expérimentations sont faites sur la base ASRS, et plus précisément
sur les incidents qui ont eu lieu entre 2009 et 2010. Ces données correspondent
à 7000 description d’incidents. Le tableau nous donne un aperçu concernant
l’ontologie utilisée pour l’expérimentation.
Ontologie
Base ASRS
(20092010)
Classes
28
Propriétés
objet
Propriétés de
données
23
5
Individus
43346
Tableau 3: Description concernant l'ontologie utilisée pour les
expérimentations
3.1.1. Scénario d'apprentissage
Pour nos expérimentations, nous considérons tous les événements qui se
sont déroulés entre 2009 et 2010. Ces données correspondent à 4998 incidents
décrits. Nous allons donner un/plusieurs modèles de situation correspondant
aux situations suivantes :
29
-
Scénario 1 : Des incidents portés sur les avions de modèle boeing.
La requête de ce scénario correspond à :
PREFIX inc :http://example.com/owl/IncidentASRS
SELECT ?incident
WHERE {?incident inc: isOn ?aircraft
.
?aircraft inc:hasMakeModel ?model
FILTER
regex(?model,”Boeing”) }
ORDER
incident
Figure
12:BY
Exemple
de requête SPARQL correspondant au scénario 1
-
Scénario 2 : Des incidents dont le problème primaire est marqué
comme ambiguë
La requête de ce scénario correspond à :
PREFIX inc :
SELECT ?incident
WHERE {?incident inc: hasAssessment ?assessment
.
? assessment inc:hasPrimaryProblem inc:ambiguous
}
ORDER BY incident
Figure 13: Exemple de requête SPARQL correspondant au scénario 2
3.1.2. Les paramètres d’expérimentations
Dans cette section, nous présentons les paramètres d’entrées utilisés dans
notre algorithme de génération de modèles.
Paramètres
Commentaires
Valeur par défaut
Fichier OWL
Fichier contenant l’ontologie
et qui permet de spécifier la
base de connaissance utilisée.
Requête SPARQL
Requête qui permet de
À préciser
sélectionner les exemples dans
la base. Ce paramètre est à
30
baseASRS.owl
définir selon le scénario
Nombre de modèles
souhaité
Ce paramètre est utilisé pour
pouvoir retourner les n
meilleurs modèles obtenus
N=3
Bruit
Ce paramètre permet de
définir le pourcentage de bruit
qu’on choisit pour nos
données
Bruit=30%
Profondeur maximale du Ce paramètre est utilisé pour
concept élémentaire
éviter d’avoir un espace de
recherche infini et définit la
profondeur du concept
élémentaire
4
Tableau 4: Paramètres d'entrée pour la génération de modèles de situation
3.1.3. Critères d’évaluation
Le premier critère d’évaluation est à dire d’expert. L’idée de cette
évaluation qui est la meilleure pour ce type de problème est de présenter aux
experts l’approche abordée et les résultats obtenus pour qu’ils nous donnent leur
point de vue. (Fait par téléphone)
Le deuxième critère est celui de séparer les exemples de la requête en
deux, une partie pour rechercher les modèles et une autre partie appelée
exemples-tests pour vérifier si les taux de couverture des exemples tests par
rapport à un modèle sont proches de la valeur de l’exactitude du modèle. Pour
ce cas nous prenons des données de la base ASRS qui correspondent aux
incidents de 2014 à 2015.
3.2. Résultats d'expérimentations et interprétations
Dans cette section, nous présentons les résultats obtenus lors des
expérimentations faites sur les données présentées dans la section précédente.
Les expérimentations ont été faites avec un ordinateur ayant les caractéristiques
suivantes : 2.2 GHz CPU et 2 Go de RAM. Nous tenons à souligner que pour
les expérimentations, nous donnons aux paramètres les valeurs par défaut
résumées dans les tableaux 3.1 et 3.2.
31
3.2.1. Résultat du scénario 1
Nous présentons d’abord les résultats d’apprentissage. En d’autre terme
il s’agit des concepts élémentaires pouvant faire partir du modèle de situation.
Et ensuite nous présentons les (n=3) meilleurs modèles de situation obtenus.
N°
1
2
3
5
6
7
8
9
10
11
Concept élémentaire d’apprentissage
Description
Exactitude
hasAssessment.(
hasContributingFactor.contributingFact
or)
Incidents dont l’évaluation
mentionne un facteur de
contribution de l’incident
98,30%
hasAssessment.(
hasPrimaryProblem.primaryProblem)
Incidents dont l’évaluation
mentionne un problème
primaire
Incidents ayant eu lieu sur
des avions dont la phase de
vol est connue
Incidents ayant eu lieu sur
des avions dont l’opérateur
est « air carrier »
Incidents dont les anomalies
sont mentionnées
Incidents qui sont détectés
par un membre de
l’équipage
Incidents portés sur des
avions ayant une mission
définie
Incidents portés sur des
avions ayant pour plan de
vol « IFR » (Instrument
Flight Rules)
Incidents ayant lieu sur des
environnements dont les
conditions de vol sont
connus
Incidents détectes au
moment « en vol »
95,92%
isOn.( hasFlightPhase.flightPhase)
isOn.(
hasAircraftOperator.({AirCarrier}))
hasAnomaly.anomaly
hasDetector.({FlightCrew})
isOn.( hasMission.mission)
isOn.( hasFlightPlan.({IFR}))
hasEnvironment.(
hasFlightCondition.fligthCondition)
hasDetectionMoment.({In-flight})
Tableau 5: Résultats d'apprentissage du scénario 1
32
95,24%
90,14%
80,95%
80,27%
76,53%
74,83%
71,09%
70,41%
Comme présenté dans l’algorithme de modèle de situation, ces résultats
sont obtenus par combinaison des concepts élémentaires. Toutefois en retenant
des concepts les plus longs, les plus spécifiques et dont l’exactitude est
supérieure à (1- pourcentage de bruit). La colonne "description" nous permet
d’avoir en langage naturel la définition du modèle de situation retourné.
Modèles Intersection des concepts
1
2
3
Descriptions
exactitude
hasAssessment.(
hasContributingFactor.contributing
Factor)∩ isOn.(
hasAircraftOperator.({AirCarrier}))
∩
hasDetector.({FlightCrew})
Incidents dont l’évaluation 70,41%
mentionne un facteur de
contribution de l’incident et
ayant eu lieu sur des avions
dont l’opérateur est « air
carrier » et qui sont
détectés par un membre de
l’équipage
Incidents ayant eu lieu sur
71,43%
isOn.(
hasAircraftOperator.({AirCarrier})) des avions dont l’opérateur
est « air carrier » et qui
∩
sont détectés par un
hasDetector.({FlightCrew})
membre de l’équipage
ayant eu lieu sur des avions 72,43%
isOn.(
hasAircraftOperator.({AirCarrier})) dont l’opérateur est « air
carrier » et dont le plan de
∩ isOn.( hasFlightPlan.({IFR}))
vol est « IFR »
Tableau 6: Modèles de situation du scénario1
3.2.2. Interprétations des résultats du scénario1
D’après les résultats du tableau 6, nous observons que malgré le taux de
bruit qui est fixé à 30%, on obtient comme meilleur résultat une combinaison de
seulement 3 concepts. Cela est dû aux informations non mentionnées (valeurs
manquantes) dans l’ontologie. Vu la base de connaissance utilisée, il est très
peu probable de retrouver des modèles de situation intéressant, dont le taux de
couverture des exemples se rapproche de 100%. C’est la raison pour laquelle
nous laissons à l’opérateur la possibilité de faire varier le pourcentage de bruit.
Pour un bruit de 10%, il est difficile de décrire la situation avec des concepts
spécifiques. Ainsi l’opérateur peut augmenter le pourcentage (30% par
exemple) afin d’obtenir des modèles dont l’interprétation est plus aisée et plus
significative.
33
Nos résultats et notre approche de génération de modèle de situation ont
été présentés aux experts du domaine aéronautique afin d’avoir des retours et
des bases expertes pour évaluer le modèle. D’après leurs dires, ils sont
satisfaisants mais ils restent beaucoup d’autres critères à prendre en compte
pour améliorer le modèle. Nous présentons les améliorations possibles en
conclusion (perspective d’amélioration).
Pour une vérification d’exactitude des modèles, nous calculons le taux de
couverture du modèle par rapport aux exemples de test. Ceci dans le but de
détecter si la situation décrite est la même pour d’autre cas de données. La
figure ci-dessous nous permet de voir que delta (différence entre le taux de
couverture des exemples d’apprentissage et le taux de couverture des exemples
tests) est au plus de 3% entre les exemples d’apprentissage et les exemples-tests
pour tous les trois modèles. Ainsi nous pouvons dire que les modèles de
situation proposés décrivent quasiment le même nombre d’exemples pour
différentes données.
Exactitude (%)
78
76
74
72
70
68
66
64
62
60
exemple d'apprentissage
exemple test(%)
Modèle
1
Modèle
2
Modèle
3
exemple d'apprentissage
70,41
71,43
72,43
exemple test(%)
73,14
70,2
71,63
Figure 14: Différence d’exactitude entre les données d'apprentissage et
celle de tests (Scénario1)
3.2.3. Résultat du scénario 2
Nous présentons d’abord les résultats d’apprentissage. En d’autre terme
il s’agit des concepts élémentaires pouvant faire partir du modèle de situation.
Et ensuite nous présentons les (n=3) meilleurs modèles de situation obtenus.
34
N°
hypothèse élémentaire en logique
Description
Précision
1
hasAssessment.(
hasPrimaryProblem.({Ambiguous}))
Incidents dont
l’évaluation mentionne
le problème primaire
comme « ambiguë »
Incidents ayant eu lieu
sur des avions dont la
phase de vol est connue
Incidents ayant eu lieu
sur des avions dont le
plan de vol est connu
Incidents ayant eu lieu
sur des avions dont
l’opérateur est « air
carrier »
100,00%
Incidents dont
l’évaluation mentionne
un facteur de
contribution qui
« facteur humain »
Incidents qui sont
détectés par un membre
de l’équipage
Incidents portés sur des
avions ayant une
mission définie
Incidents ayant lieu sur
des environnements
dont les conditions de
vol sont connus
Incidents détectes au
moment « en vol »
70,89%
2
3
4
5
6
7
8
9
isOn.( hasFlightPlan.flightPhase)
isOn.( hasFlightPlan.flightPlan)
isOn.(
hasAircraftOperator.({AirCarrier}))
hasAssessment.(
hasContributingFactor.({HumanFactors}))
hasDetector.({FlightCrew})
isOn.( hasMission.mission)
hasEnvironment.(
hasFlightCondition.fligthCondition)
hasDetectionMoment.({In-flight})
94,24%
74,68%
90,14%
81,01%
72,15%
71,09%
73,42%
Tableau 7: Résultats d'apprentissage du scénario 2
Comme présenté dans l’algorithme de modèle de situation, ces résultats
sont obtenus par combinaison des concepts élémentaires toute fois en retenant
35
des concepts les plus longs, les plus spécifiques et donc l’exactitude est
supérieure à 1- pourcentage de bruit.
Modèles Intersection des hypothèses
1
2
3
Description
Incidents dont
hasAssessment.(
hasPrimaryProblem.({Ambiguou l’évaluation mentionne le
problème primaire
s}))∩
comme « ambiguë » et
isOn.(
dont la phase de vol est
hasFlightPlan.flightPhase) ∩
connue et dont la
hasDetector.({FlightCrew})
détection est faite par un
membre de l’équipage
Incidents dont
hasAssessment.(
hasPrimaryProblem.({Ambiguou l’évaluation mentionne le
problème primaire
s}))∩
comme « ambiguë » et
isOn.(
dont la phase de vol est
hasFlightPlan.flightPhase) ∩
connue
isOn.(
hasAircraftOperator.({AirCarrier
}))
Incidents dont
hasAssessment.(
hasPrimaryProblem.({Ambiguou l’évaluation mentionne le
problème primaire
s}))∩
comme « ambiguë » et
hasDetector.({FlightCrew})
dont la détection est faite
par un membre de
l’équipage
Précision
75,95%
74,68%
81,01%
Tableau 8: Modèles de situation du scénario 2
3.2.4. Interprétations des résultats du scénario 2
Pour ce deuxième scénario correspondant aux incidents dont le problème
primaire est ambigu, nous pouvons constater que les meilleurs modèles de
situation
retournés
contiennent
tous
le
concept
élémentaire
« (hasAssessment.(hasPrimaryProblem.({Ambiguous})» qui mentionne
effectivement que l’ensemble d’exemples d’apprentissage a ce concept en
commun. Cela est normal puisque la requête de départ mentionne que le
problème primaire est ambigu. Donc l’algorithme de génération de modèles de
36
situation réussit à retourner en plus des éléments provenant de la requête
d’autres informations pour mieux décrire les exemples.
De même qu’au scénario1 les modèles de situation obtenus sont passés
sur d’autres exemples dits exemples tests. On constate que les modèles couvrent
d’autres données avec des exactitudes très proches de celle des exemples
d’apprentissage. La différence maximale de cette exactitude est de 4%. (fig.15)
Cela montre que nos modèles de situation décrivent de la même façon des jeux
de données différents.
Exactitude (%)
90
80
70
60
50
40
30
20
10
0
exemple d'apprentissage
exemple test(%)
Modèle
1
Modèle
2
Modèle
3
exemple d'apprentissage
75,95
74,68
81,01
exemple test(%)
72,24
70,2
75,75
Figure 15: Différence d’exactitude entre les données d'apprentissage et
celle de tests (Scénario2)
37
Les opérateurs se trouvent très souvent confrontés au problème d’avoir
des données dont ils ne savent pas trop quoi faire. Pour un ensemble
d’observation provenant de leur base, trouver une ou des définitions de concepts
qui décrivent au mieux ces observations est le principal problème de ces
opérateurs. Nous appelons ces concepts recherchées des modèles de situation.
L’étude effectuée au cours ce stage s’inscrit dans cet ordre d’idée et
consiste à proposer une méthode permettant de présenter ce qu’un ensemble
d’observations peut avoir en commun. Ce modèle sera utilisé comme paramètre
d’entrée pour le processus de fusion d’information et aussi utilisé par des
experts pour des prises de décision. L’approche proposée pour l’obtention de ce
dit modèle est dans un premier temps de récupérer le besoin de l’opérateur la
transcrire en requête Sparql. Ensuite, les résultats de la requête sont utilisés
comme exemples positifs pour faire de l’apprentissage. L’apprentissage
retourne juste des concepts dit "élémentaires". Pour obtenir les modèles de
situation, on recherche des concepts de longueur maximale contenant le plus
d’informations ou des concepts spécifiques. Pour atteindre notre objectif, nous
nous somme fondé sur un système d’apprentissage existant (DL learner ) que
nous avons optimisé en redéfinissant la méthode de raffinement d’opérateur afin
de trouver seulement des concepts élémentaires. Nous faisons enfin une fusion
de ces concepts (intersections) pour trouver des concepts plus complexes.
Les questions qui nous viennent en esprit sont celles de savoir si les
modèles obtenus représentent une interprétation logique pour les experts du
domaine ? Quelles autres critères doit-on considérer afin d’améliorer et évaluer
efficacement l’approche ?
Nos premiers résultats ont été validés par les experts du domaine et
d’autres jeux de test dont les résultats sont déjà connus et traités à la main nous
ont été proposés. Mais ces jeux de données concernent uniquement les données
en langue naturelles. Or pour ce stage, on ne traite pas du langage naturel et
donc nous n’avons pas eu à faire plus d’expérimentations.
38
D’après les résultats obtenus, les modèles comportent peu de concepts
élémentaires (2 à 4). Cela est dû à la base qui est peu peuplée. Etant donné que
nous avons deux bases (base ASRS et base de maintenance d’avion) qui
proviennent toutes les deux d’un même domaine, on pourra d’abord proposer
une approche pour fusionner ces deux bases.
Plus la base est peuplée plus les concepts y figurant peuvent devenir
moins intéressants pour appartenir à un modèle de situation. Par exemple, pour
le scénario des avions ayant pour problème primaire ambigu, si le résultat du
modèle de situation comprend «la couleur est rouge », la couleur n’a rien à voir
avec le problème d’un avion. Donc pour raffiner nos résultats, nous devons
définir une méthode de sélection des caractéristiques pertinentes. Cette méthode
devra permettre d’éliminer les facteurs sans influences ou peu influents, les
facteurs redondants et aussi, elle devra permettre de faire des apprentissages
moins couteux et fiables (Meilleure compréhensibilité de l’hypothèse et
Meilleure performance en classification).
Étant donné qu’il est presque impossible d’avoir un modèle couvrant
tous les exemples d’apprentissage et aussi que dans notre approche, on peut
avoir un exemple ne faisant partie d’aucun modèles de situation générés, alors
une autre approche serait de trouver un nombre réduit de groupes de données
disjoints (cluster) . Ces clusters sont trouvés de telle sorte que chaque exemple
appartient à un groupe. Aussi, les modèles générer par notre approche sont
parfois. On obtient des modèles dont l’intersection n’est pas nulle. L’idéal
serait d’avoir un minimum de modèles dont l’intersection est nulle. Cette
amélioration permettra de bien classifier les exemples et permettrons aux
experts de mieux interpréter et catégoriser les modèles. Pour les exemples
données ont doit produire un nombre minimal de cluster. Sachant qu’un cluster
représente un modèle, on devrait parcourir les données et s’assurer que chaque
exemple positif appartient à un cluster.
L’étape 2 (extraction des exemples positifs) du processus d’obtention de
modèle nécessite toujours une intervention d’un expert informatique pour
définir la requête SPARQL. Nous devons proposer une approche pour pallier
cela. Tout d’abord on peut aborder le problème en permettant aux opérateurs de
formuler rapidement des requêtes intuitives en utilisant des vocabulaires
contrôlés et expressions courantes. De même on peut aborder le problème en
définissant des requêtes avec OBDA (Ontology-Based Data Access) qui
permettra d’inférer de nouveaux faits non explicitement stockés dans la base de
39
connaissance ainsi que permettre le mapping des ontologies en fournissant une
vue unifiée de plusieurs sources de données.
40
Baader, F., Horrocks, I., & Sattler, U. (2005). Description logics as ontology
languages for the semantic web. In Mechanizing Mathematical Reasoning (pp.
228-248). Springer Berlin Heidelberg.
Cohen, W. W., Borgida, A., & Hirsh, H. (1992, July). Computing least common
subsumers in description logics. In AAAI (Vol. 1992, pp. 754-760).
De Raedt, & L., Dehaspe, L. (1996) Clausal Discovery, Report CW 238,
Department of Computing Science, K.U. Leuven. Pp.
De Raedt, L. (1992). Interactive Theory Revision: An Inductive Logic
Programming Approach. Academic Press.
Fossier, S., Laudy, C., & Pichon, F. (2013, July). Managing uncertainty in
conceptual graph-based soft information fusion. In Information Fusion
(FUSION), 2013 16th International Conference (pp. 930-937). IEEE.
Iannone, L., & Palmisano, I. (2005). An algorithm based on counterfactuals for
concept learning in the semantic web. In Innovations in Applied Artificial
Intelligence (pp. 370-379). Springer Berlin Heidelberg.
Iannone, L., Palmisano, I., & Fanizzi, N., An algorithm based on
counterfactuals for concept learning in the semantic web, in Applied
Intelligence 26 (2), pp. 139-159
Iglesias, J., & Lehmann, J. (2011, November). Towards integrating fuzzy logic
capabilities into an ontology-based inductive logic programming framework. In
Intelligent Systems Design and Applications (ISDA), 2011 11th International
Conference on (pp. 1323-1328). IEEE.
Lehmann, J., & Hitzler, P. (2008). A Refinement Operator Based Learning
Algorithm for the\ mathcal {ALC} Description Logic. In Inductive Logic
Programming (pp. 147-160). Springer Berlin Heidelberg.
Lehmann, J., & Hitzler, P. (2010). Concept learning in description logics using
refinement operators. In Machine Learning, 78(1-2), 203-250.
Lehmann, J., & Hitzler, P., (2008) A Refinement Operator Based Learning
Algorithm for the ALC Description Logic, in Inductive Logic Programming, pp.
147-160.
41
Lehmann, J., Auer, S., Bühmann, L., & Tramp, S. (2011). Class expression
learning for ontology engineering. In Web Semantics: Science, Services and
Agents on the World Wide Web, 9(1), 71-81.
McGuinness, D. L., & Van Harmelen, F. (2004). OWL web ontology language
overview. W3C recommendation, 10(10), 2004.
Muggleton, S. (1995). Inverse entailment and Progol.in New generation
computing, 13(3-4), 245-286.
Muggleton, S., & Buntine, W. (1992). Machine invention of first-order
predicates by inverting resolution. In Proceedings of the fifth international
conference on machine learning (pp. 339-352).
Muggleton, S., & Feng, C. (1990). Efficient induction of logic programs. Turing
Institute, .
Muggleton, S., Santos, J., & Tamaddoni-Nezhad, A. (2010). ProGolem: a
system based on relative minimal generalisation. In Inductive Logic
Programming (pp. 131-148). Springer Berlin Heidelberg.
Mugnier, C. M. (1992). Conceptual graphs: Fundamental notions. In Revue
d'intelligence artificielle. vol6, p. 365–406.
Mugnier, M. L. (1996). Représenter des connaissances et raisonner avec des
graphes. In Revue d’intelligence artificielle, 10(1), 7-56.
N. Fanizzi, C. d. (2008). DL-FOIL:Concept Learning in Description Logics.
LACAM Dipartimento di Informatica Università degli studi di Bari.
OWLAPI1, 2015, Clark & Parsia LLC (Explanation code, Modularity code),
(s.d.). http://owlapi.sourceforge.net/ consulté le 18/09/2015.
OWLAPI2, 2015, University of Ulm (KRSS2 syntax parser and renderer).
(s.d.). http://owlapi.sourceforge.net/ consulté le 18/09/2015.
Quinlan, J. R.-J. (1995). Induction of logic programs: FOIL and related systems.
In New Generation Computing 13.3-4, 287-312.
Raimbault, T. (2008). Transition de modèles de connaissances. Un système de
connaissance fondé sur OWL, Graphes Conceptuels et UML. Thèse de
l’université de Nantes.
42
Srinivasan, A. (version4).
http://www.cs.ox.ac.uk/activities/machlearn/Aleph/aleph.html. The ALEPH
Manual. consulté le 18/09/2015.
Laudy, C., Ganascia, J. G., & Sedogbo, C. (2007, July). High-level fusion based
on conceptual graphs. In Information Fusion, 2007 10th International
Conference on (pp. 1-8). IEEE.
BAADER, Franz et NUTT, Werner. Basic description logics. In : Description logic
handbook. 2003. cap. 2, p. 43-95.
43
27 modèles trouvés
1- (( hasAssessment.( hasContributingFactor.contributingFactor)) ِ ( isOn.(
hasAircraftOperator.({AirCarrier})))) ِ ( hasDetector.({FlightCrew})) acc:70,41%
( hasDetector.({FlightCrew})) ِ ( isOn.( hasAircraftOperator.({AirCarrier}))) acc:71,43%
2- ( isOn.( hasAircraftOperator.({AirCarrier}))) ِ ( isOn.( hasFlightPlan.({IFR})))
acc:71,43%
3- (((( hasAssessment.( hasContributingFactor.contributingFactor)) ِ (
hasAssessment.( hasPrimaryProblem.primaryProblem))) ِ ( isOn.(
hasFlightPhase.flightPhase))) ِ ( isOn.( hasAircraftOperator.({AirCarrier})))) ِ (
hasAnomaly.anomaly) acc:70,07%
4- ((( hasAssessment.( hasContributingFactor.contributingFactor)) ِ (
hasAssessment.( hasPrimaryProblem.primaryProblem))) ِ ( isOn.(
hasFlightPhase.flightPhase))) ِ ( isOn.( hasAircraftOperator.({AirCarrier}))) acc:83,33%
5- ((( hasAssessment.( hasContributingFactor.contributingFactor)) ِ (
hasAssessment.( hasPrimaryProblem.primaryProblem))) ِ ( isOn.(
hasFlightPhase.flightPhase))) ِ ( hasDetector.({FlightCrew})) acc:73,13%
6- ((( hasAssessment.( hasContributingFactor.contributingFactor)) ِ (
hasAssessment.( hasPrimaryProblem.primaryProblem))) ِ ( isOn.(
hasAircraftOperator.({AirCarrier})))) ِ ( hasAnomaly.anomaly) acc:72,45%
7- ((( hasAssessment.( hasContributingFactor.contributingFactor)) ِ ( isOn.(
hasFlightPhase.flightPhase))) ِ ( isOn.( hasAircraftOperator.({AirCarrier})))) ِ (
hasAnomaly.anomaly) acc:70,75%
8- ((( hasAssessment.( hasPrimaryProblem.primaryProblem)) ِ ( isOn.(
hasFlightPhase.flightPhase))) ِ ( isOn.( hasAircraftOperator.({AirCarrier})))) ِ (
hasAnomaly.anomaly) acc:70,07%
9- (( hasAssessment.( hasContributingFactor.contributingFactor)) ِ ( hasAssessment.(
hasPrimaryProblem.primaryProblem))) ِ ( isOn.( hasAircraftOperator.({AirCarrier})))
acc:86,73%
10- (( hasAssessment.( hasContributingFactor.contributingFactor)) ِ ( hasAssessment.(
hasPrimaryProblem.primaryProblem))) ِ ( hasDetector.({FlightCrew})) acc:76,87%
(( hasAssessment.( hasContributingFactor.contributingFactor)) ِ ( hasAssessment.(
hasPrimaryProblem.primaryProblem))) ِ ( isOn.( hasFlightPlan.({IFR}))) acc:71,09%
(( hasAssessment.( hasContributingFactor.contributingFactor)) ِ ( isOn.(
hasFlightPhase.flightPhase))) ِ ( isOn.( hasAircraftOperator.({AirCarrier}))) acc:85,03%
(( hasAssessment.( hasContributingFactor.contributingFactor)) ِ ( isOn.(
hasFlightPhase.flightPhase))) ِ ( hasDetector.({FlightCrew})) acc:75,17%
(( hasAssessment.( hasContributingFactor.contributingFactor)) ِ ( isOn.(
hasAircraftOperator.({AirCarrier})))) ِ ( hasAnomaly.anomaly) acc:73,13%
(( hasAssessment.( hasPrimaryProblem.primaryProblem)) ِ ( isOn.(
hasFlightPhase.flightPhase))) ِ ( isOn.( hasAircraftOperator.({AirCarrier}))) acc:83,33%
(( hasAssessment.( hasPrimaryProblem.primaryProblem)) ِ ( isOn.(
hasFlightPhase.flightPhase))) ِ ( hasDetector.({FlightCrew})) acc:73,13%
44
(( hasAssessment.( hasPrimaryProblem.primaryProblem)) ِ ( isOn.(
hasAircraftOperator.({AirCarrier})))) ِ ( hasAnomaly.anomaly) acc:72,45%
(( isOn.( hasAircraftOperator.({AirCarrier}))) ِ ( isOn.( hasFlightPhase.flightPhase)))
ِ ( hasAnomaly.anomaly) acc:71,43%
( hasAssessment.( hasContributingFactor.contributingFactor)) ِ ( isOn.(
hasAircraftOperator.({AirCarrier}))) acc:88,44%
( hasAssessment.( hasContributingFactor.contributingFactor)) ِ (
hasDetector.({FlightCrew})) acc:79,25%
( hasAssessment.( hasContributingFactor.contributingFactor)) ِ ( isOn.(
hasFlightPlan.({IFR}))) acc:73,13%
( hasAssessment.( hasPrimaryProblem.primaryProblem)) ِ ( isOn.(
hasAircraftOperator.({AirCarrier}))) acc:86,73%
( hasAssessment.( hasPrimaryProblem.primaryProblem)) ِ ( hasDetector.({FlightCrew}))
acc:76,87%
( hasAssessment.( hasPrimaryProblem.primaryProblem)) ِ ( isOn.(
hasFlightPlan.({IFR}))) acc:71,09%
( isOn.( hasAircraftOperator.({AirCarrier}))) ِ ( isOn.( hasFlightPhase.flightPhase))
acc:86,39%
( hasDetector.({FlightCrew})) ِ ( isOn.( hasFlightPhase.flightPhase)) acc:75,85%
( isOn.( hasFlightPhase.flightPhase)) ِ ( isOn.( hasFlightPlan.({IFR}))) acc:71,09%
( hasAnomaly.anomaly) ِ ( isOn.( hasAircraftOperator.({AirCarrier}))) acc:73,81%
isOn.( hasAircraftOperator.({AirCarrier})) acc:90,14%
hasDetector.({FlightCrew}) acc:80,27%
isOn.( hasFlightPlan.({IFR})) acc:74,83%
hasDetectionMoment.({In-flight}) acc:70,41%
((( hasAssessment.( hasContributingFactor.contributingFactor)) ِ ( hasAssessment.(
hasPrimaryProblem.primaryProblem))) ِ ( isOn.( hasFlightPhase.flightPhase))) ِ (
hasAnomaly.anomaly) acc:75,85%
((( hasAssessment.( hasContributingFactor.contributingFactor)) ِ ( hasAssessment.(
hasPrimaryProblem.primaryProblem))) ِ ( isOn.( hasFlightPhase.flightPhase))) ِ (
isOn.( hasMission.mission)) acc:70,07%
(( hasAssessment.( hasContributingFactor.contributingFactor)) ِ ( hasAssessment.(
hasPrimaryProblem.primaryProblem))) ِ ( isOn.( hasFlightPhase.flightPhase)) acc:91,84%
(( hasAssessment.( hasContributingFactor.contributingFactor)) ِ ( hasAssessment.(
hasPrimaryProblem.primaryProblem))) ِ ( hasAnomaly.anomaly) acc:78,91%
(( hasAssessment.( hasContributingFactor.contributingFactor)) ِ ( hasAssessment.(
hasPrimaryProblem.primaryProblem))) ِ ( isOn.( hasMission.mission)) acc:74,15%
(( hasAssessment.( hasContributingFactor.contributingFactor)) ِ ( isOn.(
hasFlightPhase.flightPhase))) ِ ( hasAnomaly.anomaly) acc:76,87%
(( hasAssessment.( hasContributingFactor.contributingFactor)) ِ ( isOn.(
hasFlightPhase.flightPhase))) ِ ( isOn.( hasMission.mission)) acc:71,77%
(( hasAssessment.( hasPrimaryProblem.primaryProblem)) ِ ( isOn.(
hasFlightPhase.flightPhase))) ِ ( hasAnomaly.anomaly) acc:75,85%
(( hasAssessment.( hasPrimaryProblem.primaryProblem)) ِ ( isOn.(
hasFlightPhase.flightPhase))) ِ ( isOn.( hasMission.mission)) acc:70,07%
( hasAssessment.( hasContributingFactor.contributingFactor)) ِ ( hasAssessment.(
hasPrimaryProblem.primaryProblem)) acc:95,92%
45
( hasAssessment.( hasContributingFactor.contributingFactor)) ِ ( isOn.(
hasFlightPhase.flightPhase)) acc:93,88%
( hasAnomaly.anomaly) ِ ( hasAssessment.( hasContributingFactor.contributingFactor))
acc:80,27%
( hasAssessment.( hasContributingFactor.contributingFactor)) ِ ( isOn.(
hasMission.mission)) acc:75,85%
( hasAssessment.( hasPrimaryProblem.primaryProblem)) ِ ( isOn.(
hasFlightPhase.flightPhase)) acc:91,84%
( hasAnomaly.anomaly) ِ ( hasAssessment.( hasPrimaryProblem.primaryProblem))
acc:78,91%
( hasAssessment.( hasPrimaryProblem.primaryProblem)) ِ ( isOn.( hasMission.mission))
acc:74,15%
( hasAnomaly.anomaly) ِ ( isOn.( hasFlightPhase.flightPhase)) acc:77,55%
( isOn.( hasFlightPhase.flightPhase)) ِ ( isOn.( hasMission.mission)) acc:72,11%
hasAssessment.( hasContributingFactor.contributingFactor) acc:98,30%
hasAssessment.( hasPrimaryProblem.primaryProblem) acc:95,92%
isOn.( hasFlightPhase.flightPhase) acc:95,24%
hasAnomaly.anomaly acc:80,95%
isOn.( hasMission.mission) acc:76,53%
hasEnvironment.( hasFlightCondition.fligthCondition) acc:71,09%
46
C( ܿܰ אensemble des concepts atomiques), et ( ݎܰ א ݎensemble des rôles)
On défini ܾ݊՝ ሺ ܥሻ ൌ ሼ ܥᇱ ȁ ܥᇱ ܿܰ אǡ ݁ ܥݐᇱᇱ ܥ݁ݑݍ݈݁ݐܿܰ אԢ ٌ ܥԢԢ ٌ ܥሽ .
ܾ݊՝ ሺ ܥሻ représente l’ensemble de tous les concepts qui sont directement
inférieur au concept atomique C et ܾ݊՛ ሺ ܥሻ le contraire.
L’ensemble ܯreprésente l’ensemble de tous les concepts atomiques plus
généraux et l’ensemble des rôles.
ܯൌ ሼ ܥȁ ܿܰ אǡ ܾ݊՛ ሺ ܥሻ ൌ ሽڂሼ ܥȁ ܿܰ אǡ ܾ݊՝ ሺ ܥሻ ൌ ሽڂሼݎǤ ٹȁא ݎ
ܰݎሽ
47
