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 luận văn ths công nghệ thông tin

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

Spécialité: Systèmes Intelligents et Multimédia
Code: Programme pilote

RESUME DU MEMOIRE DE FIN D’ETUDES DU MASTER
INFORMATIQUE

HANOI – 2015


Travail réalisé à l’Institut Francophone International, Université Nationale du
Vietnam, Hanoi

Sous la direction de: (Titre, Grade universitaire et Nom de l’encadrant)
Rapporteur 1:………………………………………
Rapporteur 2:………………………………………

Le mémoire est soutenu devant le jury à l’Institut Francophone International
le …………….…… 2015 à …… h…….

Le mémoire est accessible:
- au Centre d’Informations et de Bibliothèque, Université Nationale du
Vietnam, Hanoi

- à l’Institut Francophone International, Université Nationale du
Vietnam, Hanoi


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 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
1


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 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é
3


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
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 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 GCs 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
4


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.
Notions

Graphe conceptuel

OWL2

Classe

Oui

Oui

Sous classe

Oui

Oui

Relation

Oui

Oui

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
5


logique de description puisque le formalisme de représentation de connaissances choisi est aussi
lié à la logique de description.
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.
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

6


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 ∀ 𝐶𝑖 ∈ {𝐶1 , … , 𝐶𝑛 }, 𝑜𝑛 𝑎 𝐶𝑖 ⊆ 𝐶 (𝐶 𝑠𝑢𝑏𝑠𝑢𝑚𝑒 𝐶𝑖 ).
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.
Nous présentons dans cette sous 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/N-triple/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

7


5 Caractéristique de
l’espace de recherche

Top-down

Top-down

Top-down /
bottom-up

6 Système

Disponible/ Open-source

Non disponible Disponible

Tableau 2: Comparaison DL-learner, DL-foil et YINYANG
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.
2. Conclusion
En somme, nous avons présenté deux approches de représentation de connaissances, et trois
méthodes d’apprentissage basées 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 idéale et intéressant pour les utilisateurs. Nous allons décrire
dans le chapitre précédent pourquoi et comment doit-on améliorer DL learner pour obtenir un

bon modèle tout en exploitant certains principes développées dans DL learner.

8


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.

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.



1

É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.1

/>
9






É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 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.

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 2 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.

2

www.asrs.arc/nasa.gov

10


Figure 1: 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,
incident61..

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
11


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.
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 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)
 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
𝒏𝒃𝑪
𝒆𝒙𝒂𝒄𝒕(𝑪) =
∗ 𝟏𝟎𝟎 𝒐ù
|𝑬|
𝒏𝒃𝑪 = 𝑛𝑜𝑚𝑏𝑟𝑒 𝑑′ 𝑒𝑥𝑒𝑚𝑝𝑙𝑒𝑠 𝑐𝑜𝑢𝑣𝑒𝑟𝑡𝑠 𝑝𝑎𝑟 𝐶
|𝑬| = 𝑛𝑜𝑚𝑏𝑟𝑒 𝑡𝑜𝑡𝑎𝑙 𝑑 ′ 𝑒𝑥𝑒𝑚𝑝𝑙𝑒𝑠 𝑑′𝑎𝑝𝑝𝑟𝑒𝑛𝑡𝑖𝑠𝑠𝑎𝑔𝑒
 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.

12


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.
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 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
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 :

13


∅
{𝐶𝑖 | 𝐶𝑖 ∈ 𝑀}
𝜌↓ (𝐶) = { {𝐴′ |𝐴′
∈ 𝑛𝑏↓ (𝐴)}
{∃𝑟. 𝐸| 𝐸 ∈ 𝜌↓ (𝐷)}

𝑠𝑖 𝐶 =⊥
𝑠𝑖 𝐶 =⊺
}
𝑠𝑖 𝐶 = 𝐴 (𝐴 ∈ 𝑁𝑐)
𝑠𝑖 𝐶 = ∃𝑟. 𝐷

Figure 2: Définition de l'opérateur de raffinement

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

Incident =100%

𝑰𝒏𝒄𝒊𝒅𝒆𝒏𝒕 ⊓
𝒉𝒂𝒔𝑨𝒏𝒐𝒎𝒂𝒍𝒚. 𝑻

Т
Aircraft =60%

---

----

𝑰𝒏𝒄𝒊𝒅𝒆𝒏𝒕 ⊓
𝒉𝒂𝒔𝑨𝒏𝒐𝒎𝒂𝒍𝒚. {𝒄𝒓𝒊𝒕𝒊𝒄𝒂𝒍}

Figure 3: Illustration d'une recherche par raffinement d'opérateur
La figure 10 montre un exemple de raffinement de concept avec comme heuristique
l’exactitude et comme 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.

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 ne peut être
atteint par deux chaînes de raffinement différent (non de redondance de raffinement).
14


- 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 preuve est faite dans le rapport.

2.4.4.

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.

Algorithme : Modèle de situation
𝑆𝑇 𝑑é𝑠𝑖𝑔𝑛𝑒 𝑙’𝑒𝑠𝑝𝑎𝑐𝑒 𝑑𝑒 𝑟𝑒𝑐ℎ𝑒𝑟𝑐ℎ𝑒 𝑖𝑛𝑖𝑡𝑖𝑎𝑙𝑖𝑠é à 𝑇ℎ𝑖𝑛𝑔 (𝑇)
𝑅𝑃 𝑑é𝑠𝑖𝑔𝑛𝑒 𝑙’𝑒𝑛𝑠𝑒𝑚𝑏𝑙𝑒 𝑑𝑒𝑠 𝑐𝑜𝑛𝑐𝑒𝑝𝑡𝑠 é𝑙é𝑚𝑒𝑛𝑡𝑎𝑖𝑟𝑒𝑠 𝑞𝑢𝑖 𝑝𝑒𝑢𝑣𝑒𝑛𝑡 𝑓𝑎𝑖𝑟𝑒
𝑝𝑎𝑟𝑡𝑖𝑟 𝑑𝑢 𝑚𝑜𝑑è𝑙𝑒
3 |E| désigne le nombre d’exemple d’apprentissage
4 𝐶=𝑇
5 𝒕𝒂𝒏𝒕𝒒𝒖𝒆 (𝑒𝑥𝑎𝑐𝑡(𝐶) >= 𝑏𝑟𝑢𝑖𝑡 ∗ |𝐸| )
6
𝑉é𝑟𝑖𝑓𝑖𝑒𝑟 𝑙𝑎 𝑛𝑜𝑛 − 𝑟𝑒𝑑𝑜𝑛𝑑𝑎𝑛𝑐𝑒 𝑑𝑎𝑛𝑠 𝑅𝑃 𝑒𝑡 𝐴𝑗𝑜𝑢𝑡𝑒𝑟 𝐶 à 𝑅𝑃
7
𝑅𝑎𝑓𝑓𝑖𝑛𝑒𝑟 𝐶 𝑒𝑡 𝐴𝑗𝑜𝑢𝑡𝑒𝑟 à 𝑙’𝑒𝑠𝑝𝑎𝑐𝑒 𝑑𝑒 𝑟𝑒𝑐ℎ𝑒𝑟𝑐ℎ𝑒
8

𝐶ℎ𝑜𝑖𝑠𝑖𝑟 𝐶 𝑡𝑒𝑙𝑞𝑢𝑒 𝐶 𝑎𝑖𝑡 𝑙𝑎 𝑝𝑙𝑢𝑠 𝑔𝑟𝑎𝑛𝑑𝑒 𝑝𝑟é𝑐𝑖𝑠𝑖𝑜𝑛 𝑑𝑎𝑛𝑠 𝑆𝑇
9 𝑭𝒊𝒏 𝒕𝒂𝒏𝒕𝒒𝒖𝒆
10 𝐸𝑙𝑖𝑚𝑖𝑛𝑒𝑟 𝑑𝑎𝑛𝑠 𝑅𝑃 𝑙𝑒𝑠 𝑐𝑜𝑛𝑐𝑒𝑝𝑡𝑠 𝑞𝑢𝑖 𝑠𝑜𝑛𝑡 𝑑𝑒𝑠 𝑠𝑢𝑝𝑒𝑟𝑐𝑙𝑎𝑠𝑠𝑒𝑠 𝑑’𝑎𝑢𝑡𝑟𝑒𝑠 𝑐𝑙𝑎𝑠𝑠𝑒𝑠
11 𝑚𝑜𝑑è𝑙𝑒 = 𝑐𝑜𝑚𝑏𝑖𝑛𝑒𝑟(𝑅𝑃)
12 𝑅𝑒𝑡𝑜𝑢𝑟𝑛𝑒𝑟 𝑚𝑜𝑑è𝑙𝑒
1
2

𝐶𝑜𝑚𝑏𝑖𝑛𝑒𝑟(𝑅𝑃)𝑟𝑒𝑡𝑜𝑢𝑟𝑛𝑒𝑟 𝑡𝑜𝑢𝑡𝑒𝑠 𝑙𝑒𝑠 𝑐𝑜𝑚𝑏𝑖𝑛𝑎𝑖𝑠𝑜𝑛𝑠 𝑝𝑜𝑠𝑠𝑖𝑏𝑙𝑒 é𝑙é𝑚𝑒𝑛𝑡𝑠 𝑑𝑒 𝑅𝑃 𝑡𝑟𝑖é𝑒𝑠
𝑝𝑎𝑟 𝑜𝑟𝑑𝑟𝑒 𝑑é𝑐𝑟𝑜𝑖𝑠𝑠𝑎𝑛𝑡 𝑑𝑒 𝑠𝑝é𝑐𝑖𝑓𝑖𝑐𝑖𝑡é, 𝑑𝑒 𝑙𝑜𝑛𝑔𝑢𝑒𝑢𝑟 𝑑𝑒𝑠 𝑐𝑜𝑛𝑐𝑒𝑝𝑡𝑠 𝑒𝑡
𝑑’𝑒𝑥𝑎𝑐𝑡𝑖𝑡𝑢𝑑𝑒 𝑑𝑒 𝑙𝑒𝑢𝑟 𝑖𝑛𝑡𝑒𝑟𝑠𝑒𝑐𝑡𝑖𝑜𝑛 "𝑠𝑢𝑝é𝑟𝑖𝑒𝑢𝑟 à (1 − 𝑝𝑜𝑢𝑟𝑐𝑒𝑛𝑡𝑎𝑔𝑒𝐵𝑟𝑢𝑖𝑡)"

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

15


obtenus après apprentissage tout en vérifiant que l’exactitude des modèles retournés soit
supérieur à (1 − pourcentageBruit).

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.

16


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

Classes

Base ASRS
(2009-2010)

Propriétés objet

28

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 :
-

Scénario 1 : Des incidents portés sur les avions de modèle boeing.
La requête de ce scénario correspond à :

PREFIX inc : />SELECT ?incident

WHERE {?incident inc: isOn ?aircraft
.

?aircraft inc:hasMakeModel ?model

FILTER

regex(?model,”Boeing”) }

ORDER BY incident
Figure 4: Exemple de requête SPARQL correspondant au scénario 1
-

Scénario 2 : Des incidents dont le problème primaire est marqué comme ambiguë
17


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 5: 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.

baseASRS.owl

Requête SPARQL

Requête qui permet de sélectionner les
exemples dans la base. Ce paramètre
est à définir selon le scénario

À préciser

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
concept élémentaire

Ce paramètre est utilisé pour é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

18


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.

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.
Concept élémentaire d’apprentissage

Description

∃ hasAssessment.(∃
hasContributingFactor.contribut
ingFactor)

Incidents dont l’évaluation
mentionne un facteur de contribution
de l’incident
Incidents dont l’évaluation
mentionne un problème primaire

95,92%

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 »

95,24%

6

∃ hasAssessment.(∃
hasPrimaryProblem.primaryProble
m)
∃ isOn.(∃
hasFlightPhase.flightPhase)
∃ isOn.(∃
hasAircraftOperator.({AirCarrie
r}))
∃ hasAnomaly.anomaly

80,95%

7

∃ hasDetector.({FlightCrew})

8

∃ isOn.(∃ hasMission.mission)

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

N°
1

2

3
5

19

Exactitude
98,30%

90,14%

80,27%

76,53%


9

10

11

isOn.(∃ hasFlightPlan.({IFR}))

∃ hasEnvironment.(∃
hasFlightCondition.fligthCondit
ion)
hasDetectionMoment.({Inflight})

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 »

74,83%

71,09%

70,41%

Tableau 5: Résultats d'apprentissage du scénario 1
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
1

2

3

Intersection des concepts

Descriptions

exactitude

∃ hasAssessment.(∃
hasContributingFactor.contributin
gFactor)∩ ∃ isOn.(∃
hasAircraftOperator.({AirCarrier}
))∩
∃ hasDetector.({FlightCrew})

Incidents dont l’évaluation
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 des
avions dont l’opérateur est « air
carrier » et qui sont détectés par
un membre de l’équipage
ayant eu lieu sur des avions
dont l’opérateur est « air
carrier » et dont le plan de vol
est « IFR »

70,41%

∃ isOn.(∃
hasAircraftOperator.({AirCarrier}
))∩
∃ hasDetector.({FlightCrew})
∃ isOn.(∃
hasAircraftOperator.({AirCarrier}
))∩ isOn.(∃
hasFlightPlan.({IFR}))

71,43%

72,43%

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
20


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.
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 4% 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 6: 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.

21


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 des concepts les plus longs, les
plus spécifiques et donc l’exactitude est supérieure à 1- pourcentage de bruit.
Modèles
1

Intersection des hypothèses

Description

∃ hasAssessment.(∃
hasPrimaryProblem.({Ambiguo

us}))∩
∃ isOn.(∃
hasFlightPlan.flightPhase)
∩ ∃
hasDetector.({FlightCrew})

2

∃ hasAssessment.(∃
hasPrimaryProblem.({Ambiguo
us}))∩
∃ isOn.(∃
hasFlightPlan.flightPhase)
∩ ∃ isOn.(∃
hasAircraftOperator.({AirCa
rrier}))

3

∃ hasAssessment.(∃
hasPrimaryProblem.({Ambiguo
us}))∩ ∃
hasDetector.({FlightCrew})

Précision

Incidents dont l’évaluation
75,95%
mentionne le problème
primaire comme

« ambiguë » et dont la phase
de vol est connue et dont la
détection est faite par un
membre de l’équipage
Incidents dont l’évaluation
74,68%
mentionne le problème
primaire comme
« ambiguë » et dont la phase
de vol est connue

Incidents dont l’évaluation
mentionne le problème
primaire comme
« ambiguë » et dont la
détection est faite par un
membre de l’équipage

81,01%

Tableau 7: 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 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
22


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 7: Différence d’exactitude entre les données d'apprentissage et celle de tests
(Scénario2)

23