D’après la fusion des scénarios présentée dans le paragraphe précédent, nous proposons un processus général. Nous avons réutilisé les différentes étapes de cette fusion afin de définir notre méthodologie. La fusion des deux scénarios peut être représentée sous la forme d’un processus général reprenant les activités importantes. Ce processus général, présenté sur la figure20, est composé de trois étapes :
— 1 Analyse de sources : Pendant ce processus, l’expert du domaine sélectionne les sources les plus appropriées pour la construction de la base de connaissances. Il inspecte chaque source potentielle afin d’évaluer sa couverture, mais également afin d’évaluer la faisabilité de la transformation automatique en base de connaissances. Cette étape correspond aux activités 1, 2 et 3 du scénario 2 de NeOn.
— 2 Transformation de sources : Ce processus permet de spécifier la transfor-mation à appliquer sur chaque source pour obtenir une base de connaissances au format OWL. Une fois ces spécifications définies, la transformation est appliquée et nous obtenons ce que nous appelons une base de connaissances source. Cette étape correspond aux activités 4 et 5 du scénario 2 de NeOn.
— 3 Fusion de bases de connaissances : Ce processus construit la base de connais-sances finale en se fondant sur toutes les bases de connaisconnais-sances extraites à partir des sources. À notre connaissance, ce processus n’est proposé dans aucune des méthodes d’ingénierie d’ontologies. Généralement, les méthodes d’ingénierie d’onto-logies utilisent plusieurs sources séparément afin d’enrichir la base de connaissances de manière séquentielle. Le processus de fusion utilise plusieurs bases de connais-sances simultanément, afin d’extraire des connaisconnais-sances communes aux différentes sources. Cette étape correspond à l’activité 6 du scénario 2 de NeOn.
Le scénario 7 intervient dans la création de la partie haute d’un module ontologique que nous présenterons dans la section3.1.
Nous allons, dans la suite de ce chapitre, présenter plus en détails chacune des étapes.
2. Analyse des sources
Cette phase préliminaire du processus permet de dresser la liste des sources qui seront considérées dans la suite. Cette étape reprend les activités 1, 2 et 3 du scénario 2 présenté
dans la figure19. Afin de pouvoir sélectionner les sources les plus adaptées, il est important de spécifier pourquoi une source est adaptée et quels sont les critères à observer sur une source pour la sélectionner.
Ce que nous appelons ici une source adaptée est une source qui correspond aux besoins de l’objectif de la transformation. En d’autres termes, une source sera considérée comme pouvant être une source du processus si elle correspond au niveau de qualité et aux objectifs souhaités dans la base de connaissances finale.
À cette fin, nous avons défini quatre critères principaux que nous utilisons pour interagir avec l’expert. Ces critères n’englobent pas tous les critères cités dans le tableau 12
mais représentent ceux que nous considérons les plus pertinents par rapport à notre méthodologie.
— La réputation de la source est généralement fondée sur la réputation de ses auteurs. Si l’auteur est une institution gouvernementale ou internationale, la source sera plus probablement acceptée par une large communauté d’utilisateurs et sera réutilisée. La réputation de la source peut également être fondée sur le nombre de ses utilisateurs.
— La fraîcheur de la source se fonde sur la dernière date de mise à jour de la source, ainsi que sur le fait que la source est souvent mise à jour ou pas.
— L’adéquation de la source à la cible représente la similarité entre la source et la base de connaissances souhaitée. Elle prend en compte la couverture de la source par rapport à la base de connaissances finale.
— La clarté du modèle de la source évalue le fait que le modèle conceptuel de la source peut être facilement trouvé. Par exemple, si différents patrons sont utilisés pour stocker le même type d’informations, alors le modèle est ambigu.
Nous nous limitons à ces seuls critères pour guider l’expert dans la sélection des sources car, comme observé dans la section 4 du chapitre II, il est très difficile d’obtenir une liste exhaustive de critères pouvant intervenir dans la caractérisation d’une source de qualité. Il n’est, de plus, pas envisageable de demander à un expert d’évaluer une longue liste de critères pour chaque source. Néanmoins, les quatre critères cités précédemment permettent d’observer de manière synthétique les éléments importants entrant en compte dans la description d’une source de qualité dans notre processus.
Notre objectif dans ce processus est de trouver des connaissances communes à plusieurs sources. Les différentes sources ne présentent pourtant pas nécessairement le même intérêt en fonction de leur qualité. De ce fait, une connaissance provenant d’une source de bonne qualité aura plus de poids qu’une autre provenant d’une source de moins bonne qualité. Nous considérerons ici la définition d’une source de bonne qualité donnée dans [Dong et al., 2013]. Cette définition précise qu’une source est d’autant meilleure qualité qu’elle contient des éléments qui sont vrais. Nous considérons un élément modélisé dans la source comme étant vrai s’il correspond à un élément du monde réel. Si par exemple dans une source est modélisé le fait qu’une plante a des bras, cet élément ne correspond pas à un élément du monde réel ; il est donc considéré comme faux. Nous pouvons alors
définir la qualité d’une source S notée Q(S) de la manière suivante [Dong et al., 2013] :
Q(S) = |e ∈ S, e est vrai|
|S| (1)
Cette fonction Q(S) permet de définir la qualité d’une source S. Cette qualité est le ratio du nombre d’éléments e de la source S qui sont vrais sur le nombre total d’éléments dans S. Ce ratio permet d’obtenir une valeur comprise en 0 et 1 définissant le niveau de qualité d’une source.
Cette définition permet d’avoir l’intuition de ce que nous considérons comme étant la qualité d’une source. Néanmoins, toute la difficulté de notre approche est de déterminer si e est vrai ou non. Nous ne pouvons pas utiliser cette fonction telle qu’elle est définie ici. Nous demandons donc à un expert de donner une valeur représentant cette qualité pour chaque source considérée. L’expert a à sa disposition les critères présentés précédemment pour l’aider à définir cette qualité.
Le critère "adéquation de la source à la cible" est particulièrement complexe à déterminer à cause de la notion de "base de connaissances souhaitée". Il est nécessaire de définir les spécifications de ce que nous souhaitons voir apparaître dans la base de connaissances finale afin de déterminer l’adéquation entre la source et cette base.
3. Transformation de sources
3.1. Module ontologique
Un des aspects à prendre en considération lors de la conception d’une base de connais-sances est la réutilisabilité de celle-ci [Gangemi and Presutti, 2009]. De façon analogue aux pratiques dans le domaine de l’ingénierie logicielle, la simplification de la réutilisation d’une base de connaissances passe par la création de sous-parties de l’ontologie répondant à un sous-ensemble des spécifications attendues de l’ontologie globale. Afin de couvrir toutes les spécifications, plusieurs sous-parties sont créées et sont liées entre-elles. De cette manière il est possible de se concentrer sur un aspect spécifique de la modélisation en ne s’intéressant qu’à une sous-partie particulière. Ce procédé permet aussi la réutilisation d’une sous partie de la base de connaissances globale (ontologie regroupant toutes les sous-parties) et non de toute la base de connaissances.
Il est possible de remarquer dans la pratique des différents acteurs du Web sémantique que la réutilisation d’ontologies de petite taille est privilégiée par rapport à l’utilisa-tion d’ontologies plus larges mais moins facilement manipulables. C’est particulière-ment le cas si nous comparons la réutilisation d’une ontologie de petite taille telle que FOAF73 [Brickley and Miller, 2005] et la réutilisation d’une ontologie plus large telle que DOLCE74[Masolo et al., 2002].
De cette manière, nous souhaitons construire une ontologie générale fondée sur des modules ontologiques. Nous appelons module ontologique une sous-partie de
l’ontolo-73. Friend Of A Friend
gie générale telle que définie précédemment. Nous nous fondons sur la définition de [Gangemi and Presutti, 2009]. Nous allons appliquer le processus global pour chaque mo-dule que nous souhaitons créer. Ces momo-dules, une fois regroupés, permettront d’obtenir l’ontologie globale.
Chaque module représente un objectif particulier couvrant certaines spécifications de l’ontologie globale. Les différents modules permettent aussi d’avoir un objectif clairement identifié lors du processus de transformation. Pour ce qui nous concerne, notre objectif est de découvrir les connaissances communes entre plusieurs sources, et ce pour un module donné. Il faut donc avoir une définition des spécifications que nous souhaitons pour le module étudié. Nous demandons à un expert de conceptualiser ce que nous considérons comme étant la partie haute du module étudié. La partie haute d’un module englobe les classes les plus générales hiérarchiquement du module. Nous considérons qu’il n’existe pas d’autres classes au dessus hiérarchiquement que les classes de cette partie haute pour représenter le domaine qui nous intéresse. Nous représentons aussi dans cette partie haute du module ontologique toutes les propriétés que nous souhaitons utiliser.
Notre objectif est de pouvoir enrichir cette partie haute du module grâce aux éléments extraits des différentes sources. Pour cela nous extrayons uniquement les éléments qui spécialisent cette partie haute du module. En d’autres termes nous récupérons uniquement les classes qui sont, directement ou indirectement, une spécialisation d’une des classes de la partie haute du module. Nous extrayons aussi les individus qui instancient ces classes. Les relations que nous extrayons peuvent être étiquetées de quatre façons différentes :
instanceOf : Pour l’instanciation des individus suivant une des classes de la partie haute du module ou une spécialisation
subClassOf : Pour la spécialisation des classes de la partie haute du module rdfs :label : Pour extraire les labels des éléments extraits
ΣpropO de la partie haute du module : Pour représenter une relation étiquetée par une propriété définie dans la partie haute du module
De cette manière nous garantissons l’uniformité des étiquettes des relations.
L’utilisation de la partie haute du module telle que nous l’avons définie a deux avantages. Le premier est l’harmonisation de la modélisation que nous souhaitons obtenir. Effectivement chaque source ayant sa propre modélisation il n’est pas chose aisée que de fusionner ces différences. Nous l’avons vu dans l’état de l’art (c.f. section3.1du chapitreII) la fusion de plusieurs modèles peut apporter des incohérences et de la redondance. Pour éviter ce problème nous définissons un modèle de référence que nous utilisons pour harmoniser les différentes modélisations : la partie haute du module ontologique. Le deuxième avantage de l’utilisation de la partie haute d’un module ontologique est qu’elle permet la définition des bornes du domaine. Les éléments extraits des différentes sources doivent être en adéquation avec le module que nous cherchons à modéliser. Nous extrayons uniquement les éléments qui sont une spécialisation ou une instanciation d’une classe de la partie haute du module ontologique. De cette manière, si un élément extrait n’est pas une spécialisation ou une instanciation alors cet élément ne fait pas partie du domaine étudié.
Par conséquent, nous considérerons dans la suite de ce manuscrit, qu’un module ontologique est la partie haute de la sous-partie telle que définie dans les travaux [Gangemi and Presutti, 2009]. Afin de construire ce module, nous nous fondons, comme vu dans la section1 du chapitreIII, sur le scénario 7 de NeOn. Un module ontologique est donc le regroupement de patrons de conception adaptés et spécialisés pour le domaine étudié.
La figure 21 présente un exemple d’un module ontologique : AgronomicTaxon. Ce module ontologique [Roussey et al., 2013] permet de représenter la taxonomie des plantes. Sa conception a suivi les étapes définies dans le scénario 7 de NeOn. Il est possible de trouver plus de détails sur ce module à l’adresse suivante :https://sites.google.com/
site/agriontology/home/irstea/agronomictaxon.