Réalisation d’un modèle de filtrage de données

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 cơng trình nghiên cứu riêng tơi Các số liệu, kết nêu Luận văn trung thực chưa công bố công trình khác Các thơng tin trích dẫn Luận văn 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 Chapitre Synthèse bibliographique Contexte : 1.1 Langages de représentation des connaissances 1.1.1 Graphe conceptuel 1.1.2 Langage du Web Sémantique 1.1.3 Tableau comparatif des GC et OWL2 1.2 L’apprentissage automatique 1.2.1 Généralités sur la programmation logique inductive (PLI) 1.2.2 Apprentissage sur des ontologies (OWL) 1.2.2.1 DL-Foil 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 - 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 : Extraction d’exemples positifs 18 2.4 Étape : 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 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 32 3.2.2 Interprétations des résultats du scénario1 33 3.2.3 Résultat du scénario 34 3.2.4 Interprétations des résultats du scénario 36 Conclusion 38 Perspectives 39 Références 41 ANNEXES A : Présentation de tous les modèles de situation du scénario 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 Gặ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 é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 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 Figure : 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 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 30 Figure 13: Exemple de requête SPARQL correspondant au scénario 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 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 32 Tableau 6: Modèles de situation du scénario1 33 Tableau 7: Résultats d'apprentissage du scénario 35 Tableau 8: Modèles de situation du scénario 36 ix 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 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 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 Modèle Modèle 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 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 ‫ ׌‬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% ‫ ׌‬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 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 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 3.2.4 Interprétations des résultats du scénario 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 exemple d'apprentissage exemple test(%) Modèle Modèle Modèle 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 (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 ... 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... 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... 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 : Spécialisation des résultats d’apprentissage