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
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
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
Figure 1: Exemple de graphe conceptuel
Type Concept: Marqueur relation Type Concept: Marqueur
5 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
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.
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
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 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) ࡸࡿሺǡ Ǥ Ǥ Ǥ ሻ ൌ ó ܥ 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,
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
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 ú 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-space 1
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) 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]
DL Learner est un framework développé en Java pour l’apprentissage en logique de description des données provenant des fichiers OWL, fichier N- Triple, 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 endpoints 2 , 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)
- 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
- 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
Apports
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
Figure 4: Étape de génération de modèle de situation
3 http://www.w3.org/TR/rdf-sparql-query/
É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
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
Figure 5: Visualisation graphique de l’ontologie ASRS
É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
Figure 6: Exemple de requête SPARQL
É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
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
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
Figure 7: Résultat de DL learner avec comme exemple
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
1: hasAssessment.( hasPrimaryProblem.({Ambiguous})) (pred acc.:
2: hasAssessment.( hasPrimaryProblem.primaryProblem) (pred acc.:
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%)
21 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 ࢋ࢞ࢇࢉ࢚ሺሻ ൌ ࢈ ȁࡱȁ כ ợ ࢈ ൌ ܾ݊݉ݎ݁݀ᇱ݁ݔ݈݁݉݁ݏܿݑݒ݁ݎݐݏܽݎܥ ȁࡱȁ ൌ ܾ݊݉ݎ݁ݐݐ݈ܽ݀ᇱ݁ݔ݈݁݉݁ݏ݀Ԣܽݎ݁݊ݐ݅ݏݏܽ݃݁ ã 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é ߩሺܥሻ ൌ ሼܥᇱሽ ó ܥǯ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
23 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
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
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é
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
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 Т
Incident 0% Aircraft `% - - - ࡵࢉࢊࢋ࢚ ِ ࢎࢇ࢙ࢇ࢟Ǥ ࢀ - - - - ࡵࢉࢊࢋ࢚ ِ ࢎࢇ࢙ࢇ࢟Ǥ ሼࢉ࢚࢘ࢉࢇሽ
Figure 10: Illustration d'une recherche par raffinement d'opérateur
25 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 cọ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 ܾ݊՝)
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
Tableau 3: Description concernant l'ontologie utilisée pour les expérimentations
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 à :
Figure 12: 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 à :
Figure 13: Exemple de requête SPARQL correspondant au scénario 2
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 à À préciser
PREFIX inc :http://example.com/owl/IncidentASRS SELECT ?incident
WHERE {?incident inc: isOn ?aircraft ?aircraft inc:hasMakeModel ?model FILTER regex(?model,”Boeing”) }
PREFIX inc : SELECT ?incident WHERE {?incident inc: hasAssessment ?assessment ? assessment inc:hasPrimaryProblem inc:ambiguous
Ce paramètre est utilisé pour pouvoir retourner les n meilleurs modèles obtenus
Bruit Ce paramètre permet de définir le pourcentage de bruit qu’on choisit pour nos données
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
Tableau 4: Paramètres d'entrée pour la génération de modèles de situation
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.
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
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° Concept élémentaire d’apprentissage Description Exactitude
Incidents dont l’évaluation mentionne un facteur de contribution de l’incident
Incidents dont l’évaluation mentionne un problème primaire
3 isOn.( hasFlightPhase.flightPhase) 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 ằ
6 hasAnomaly.anomaly Incidents dont les anomalies sont mentionnées
7 hasDetector.({FlightCrew}) Incidents qui sont détectés par un membre de l’équipage
8 isOn.( hasMission.mission) Incidents portés sur des avions ayant une mission définie
9 isOn.( hasFlightPlan.({IFR})) 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
11 hasDetectionMoment.({In-flight}) Incidents détectes au moment ô en vol ằ
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 Intersection des concepts Descriptions exactitude
1 hasAssessment.( hasContributingFactor.contributing Factor)∩ isOn.( hasAircraftOperator.({AirCarrier}))
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
∩ isOn.( hasFlightPlan.({IFR})) ayant eu lieu sur des avions dont l’opộrateur est ô air carrier ằ et dont le plan de 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
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
Figure 14: Différence d’exactitude entre les données d'apprentissage et celle de tests (Scénario1)
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
Modèle 3 exemple d'apprentissage 70,41 71,43 72,43 exemple test(%) 73,14 70,2 71,63
Exactitude (%) exemple d'apprentissage exemple test(%)
N° hypothèse élémentaire en logique Description Précision
Incidents dont l’évaluation mentionne le problème primaire comme ô ambiguở ằ
2 isOn.( hasFlightPlan.flightPhase) Incidents ayant eu lieu sur des avions dont la phase de vol est connue
3 isOn.( hasFlightPlan.flightPlan) 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 ằ
Incidents dont l’évaluation mentionne un facteur de contribution qui ô facteur humain ằ
6 hasDetector.({FlightCrew}) Incidents qui sont détectés par un membre de l’équipage
7 isOn.( hasMission.mission) Incidents portés sur des avions ayant une mission définie
Incidents ayant lieu sur des environnements dont les conditions de vol sont connus
9 hasDetectionMoment.({In-flight}) Incidents détectes au moment ô en vol ằ
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 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 Précision
1 hasAssessment.( hasPrimaryProblem.({Ambiguou s}))∩ isOn.( hasFlightPlan.flightPhase) ∩ hasDetector.({FlightCrew})
Incidents dont l’évaluation 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
2 hasAssessment.( hasPrimaryProblem.({Ambiguou s}))∩ isOn.( hasFlightPlan.flightPhase) ∩ isOn.( hasAircraftOperator.({AirCarrier }))
Incidents dont l’évaluation mentionne le problème primaire comme ô ambiguở ằ et dont la phase de vol est connue
3 hasAssessment.( hasPrimaryProblem.({Ambiguou s}))∩ hasDetector.({FlightCrew})
Incidents dont l’évaluation mentionne le problème primaire comme ô ambiguở ằ et dont la détection est faite par un membre de l’équipage
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
37 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
Figure 15: Différence d’exactitude entre les données d'apprentissage et celle de tests (Scénario2)
Modèle 3 exemple d'apprentissage 75,95 74,68 81,01 exemple test(%) 72,24 70,2 75,75
Exactitude (%) exemple d'apprentissage exemple test(%)
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
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