Méthodologie de construction de base de connaissances : NeOn

Télécharger le fichier pdf d’un mémoire de fin d’études

Le Web sémantique aujourd’hui

Comme nous avons pu l’observer, le Web sémantique repose sur un certain nombre de technologies. Ces diﬀérentes technologies sont dépendantes les unes des autres. C’est par exemple le cas de RDF qui repose sur l’utilisation d’URI. La figure 5 présente ces technologies et leurs dépendances.
Cette figure présente le « cake du Web sémantique ». Les technologies sont représentées sous la forme de couches du cake et la superposition des couches représente les dépendances. Pour reprendre notre précédent exemple, la couche RDF est bien au-dessus de la couche URI. La couche XML permet de préciser qu’il est possible de représenter du RDF en XML. Nous avons aussi abordé les vocabulaires RDFS et OWL présents dans cette figure. La couche SPARQL représente le langage d’interrogation de données au format RDF. Ce langage, proche de SQL, permet la récupération, l’ajout, la suppression et la modification de triplets RDF. Le langage RIF 22 permet quant à lui de définir des règles d’inférences spécifiques sous un format interopérable et partageable. La couche « Unifying Logic » permet de définir des méthodes de déduction de nouvelles connaissances en exploitant les vocabulaires utilisés et les règles d’inférences définies. La couche « Proof » permet de spécifier la preuve de la pertinence des données, à partir notamment de leur provenance. Toutes ces couches sont en parallèle avec la couche « Crypto ». En eﬀet, afin de garantir une communication sécurisée et donc un partage de données non altéré, il est intéressant de proposer une connexion cryptée.La couche « Trust » permet de définir la confiance que l’on peut apporter à une donnée. La couche présente au sommet du cake représente l’application et l’interface utilisant les données.
Certaines couches précisent des technologies spécifiques et sont fondées sur des recom-mandations du W3C (URI, RDF, RDFS, RIF, SPARQL et OWL) alors que d’autres couches ne sont que des préconisations (Unifying Logic, Proof, Trust, Crypto et User Interface). Il n’existe pas encore de recommandation du W3C pour ces couches.
Nous pouvons prendre l’exemple de la couche « Trust ». Nous l’avons vu, le nuage représentant le Web de données liées devient de plus en plus imposant car de plus en plus de données sont ouvertes et partagées de cette manière. Avec l’arrivée d’une telle masse de données apparaît aussi la problématique de la pertinence des données. Un eﬀet similaire est apparu losque le Web de documents a été de plus en plus utilisé. Il est aujourd’hui évident que les documents présents sur le Web peuvent contenir des erreurs. Il en est de même pour les données sur le Web de données liées. La couche « Trust » a donc un rôle particulièrement important à jouer dans le développement du Web de données liées pour permettre la réutilisation de données présentant un niveau de confiance suﬃsant. Néanmoins, aucune recommandation n’existe à l’heure actuelle concernant cette couche. Il n’existe donc pas de critères permettant de représenter la confiance de manière exhaustive, ni une représentation générique de cette confiance à travers les diﬀérents systèmes. C’est aussi le cas de la couche « Proof » sur laquelle se fonde la couche « Trust ». Cette couche « Proof » inclut notamment la notion de provenance des données représentées. Il apparaît que la confiance d’une donnée est partiellement liée à sa provenance.
Un verrou majeur existant pour le développement du Web de données liées est la transformation de sources non ontologiques pour exploiter ces technologies. Il existe sur le Web un grand nombre de sources qui n’exploitent pas directement ces technologies du Web sémantique et donc ne participent pas au Web de données liées. Certaines de ces sources sont le résultat de plusieurs années d’évolution et d’amélioration. Il est donc particulièrement intéressant de les réutiliser.
Nous concentrons l’étude présentée dans ce manuscrit sur ces deux verrous du Web sémantique. Nous cherchons à transformer des sources non-ontologiques pour obtenir des bases de connaissances en considérant plusieurs bases de connaissances simultanément. Cette considération simultanée nous permet de pouvoir découvrir des éléments communs à plusieurs sources. Comme nous l’avons vu, la confiance peut être définie en fonction de la provenance des ressources.
Comme nous allons le présenter dans le prochain paragraphe, l’agriculture est un domaine qui permet d’illustrer ce verrou car il existe un grand nombre de sources non-ontologiques présentes sur le Web, mais le Web de données liées agricole reste encore très peu fourni.

Domaine d’application : la protection des cultures agricoles

Comme nous venons de le voir, nous orientons l’étude faite dans ce manuscrit sur la transformation de plusieurs sources non-ontologiques pour participer au Web de données liées. Nous avons cité l’exemple du domaine de l’agriculture qui est particulièrement représentatif grâce aux nombreuses sources non-ontologiques existantes.
Dans cette section nous étudierons les besoins du domaine de l’agriculture concernant le Web de données liées. Pour cela, nous étudierons dans un premier temps un besoin concret d’après l’élaboration d’un projet de recherche, besoin auquel le projet Vespa souhaite répondre. Nous étudierons ensuite un échantillon des types de sources de données disponibles dans ce domaine.

Présentation du domaine

Lors du plan Ecophyto 23 et du Grenelle de l’environnement, le gouvernement a engagé l’initiative d’une transition vers une agriculture durable. Cette agriculture préconise l’utilisation de produits phytosanitaires uniquement lorsque cela est nécessaire et non plus de manière systématique. Cette agriculture durable doit permettre la réduction de l’utilisation de produits phytosanitaires dans les cultures agricoles. En eﬀet, un usage trop intensif de produits phytosanitaires peut amener à retrouver des résidus de ces produits dans les récoltes, polluer les eaux ou encore avoir une influence négative sur l’écosystème.
Une des méthodes préconisées pour favoriser la transition vers une agriculture durable est le renforcement de l’épidémiosurveillance. En eﬀet, pour n’utiliser des produits phytosanitaires que lorsque cela est nécessaire, il est indispensable de déterminer les risques d’attaques sur les cultures. En France, des agents ont pour tâche d’observer l’état des cultures et les diﬀérentes attaques survenues. Le résultat de ces observations est retranscrit dans un document textuel qui paraît plusieurs fois par mois pour chaque région de France : les Bulletins de Santé du Végétal. Néanmoins, ces documents sont textuels et ne permettent donc pas une analyse globale de la situation des attaques de bio-agresseurs en France. Cette analyse pourrait être particulièrement pertinente pour déterminer le développement d’une maladie et donc en déduire son évolution future.
C’est dans ce cadre que se positionne le projet Vespa 24. Ce projet, dirigé par l’INRA, est consacré en partie à l’archivage et à l’exploitation des BSV dans un système de recherche d’informations. Ce système doit permettre de faciliter l’épidémiosurveillance, notamment à travers un outil : PestObserver.
Nous allons donc tout d’abord étudier ce qu’est un BSV puis nous présenterons l’outil PestObserver. Nous verrons ensuite en quoi l’étude présentée dans ce manuscrit permet l’amélioration de l’outil.

Les Bulletins de Santé du Végétal (BSV)

Une des méthodes de surveillance existant à l’heure actuelle est la rédaction de Bulletins de Santé du Végétal (BSV) 25 par un représentant régional du Ministère de l’agriculture. Ces BSV sont des documents d’information techniques et réglementaires qui doivent être mis à la disposition du public, notamment par l’intermédiaire d’un site Web. Néanmoins, ces BSV sont stockés sur des sites Web diﬀérents (un par région). Ils ont pour vocation, entre autres, d’alerter les personnes concernées lors d’apparitions d’agresseurs dans les cultures. Il est donc intéressant pour les agriculteurs ou les conseillers agricoles d’une région d’avoir connaissance des alertes agricoles (AA) des régions limitrophes ou encore de l’évolution des agressions. Il n’existe pas encore, à notre connaissance, de système permettant l’interrogation unifiée des BSV de France.
La figure 6 présente un exemple de BSV. Ce bulletin présente l’observation de plusieurs agresseurs (Sésamie et Pyrale) sur les cultures de maïs en Midi-Pyrénées au 8 juillet 2010. Nous pouvons observer qu’il y a une évaluation des risques de ces agressions mais aucune recommandation sur les techniques de lutte. Cette absence de recommandation est voulue pour ne pas influencer les agriculteurs sur l’utilisation d’un produit plutôt qu’un autre. Les auteurs de ces BSV varient suivant la région ou le type de culture. Cette variabilité des auteurs apporte une diversité sur la présentation des BSV. De plus le rythme des publications suit le développement des cultures et n’est pas régulier. Le rythme de publication d’un BSV pour un type de culture dans une région donnée peut aller d’une parution hebdomadaire à une parution mensuelle. Enfin, les BSV ne sont pas une agrégation automatique de données mesurées mais une synthèse analytique humaine sur des observations.
Ces contraintes apportent une grande diversité sur la forme, le rythme de parution et le vocabulaire employé. Ces diversités en font des documents diﬃcilement exploitables automatiquement.

Types de sources agricoles

Afin de générer la base de connaissances qui pourra permettre l’annotation sémantique des BSV, il est nécessaire d’analyser les diﬀérentes sources disponibles. C’est l’objectif de cette section qui nous permettra d’avoir une vue globale sur les sources existantes et leur format.
En s’appuyant sur les travaux présentés dans [Villazon-Terrazas et al., 2010], nous analysons les sources selon trois caractéristiques :
. Le type de source représente l’objectif de la modélisation de la source,
. Le modèle représente l’organisation utilisée pour représenter la source,
. L’implémentation est le format de représentation concret dans un fichier.
Ces niveaux permettent de faire la distinction entre l’objectif de la modélisation (le type de source), la façon dont la modélisation est eﬀectuée (le modèle) et la façon dont les données sont stockées (l’implémentation). Les données publiées sur le Web de données liées, et donc repréentées en RDF, sont plus facilement accessibles.
Dans ce cadre, nous définissons un ensemble de types de sources existant pour le domaine de l’agriculture. Ces sources sont présentées selon leur type.

Taxonomies

Le terme « taxonomie » provient du mot grecque « taxinomia » qui est composé du terme « taxis » (classement) et du terme « nomos » (loi). Le terme est apparu en 1863 dans l’ouvrage « Théorie élémentaire de la botanique ou exposition des principes de la classification naturelle et de l’art de décrire et d’étudier les végétaux » [de Candolle, 1813] écrit par Augustin Pyrame de Candolle. Initialement, une taxonomie était consacrée au recensement et à la catégorisation des organismes vivants. De nos jours, une taxonomie peut permettre la catégorisation d’autres domaines.
Dans ce manuscrit, nous considérerons qu’une taxonomie est le classement des êtres vivants. Elle permet de représenter chaque catégorie d’être vivant sous la forme de taxons avec des liens hiérarchiques entre taxons. Un taxon représente une catégorie d’être vivant plus ou moins spécifique. Ce taxon peut être désigné par plusieurs termes.

Bilan sur les sources agricoles

Comme nous venons de le voir, la transition vers une agriculture durable apporte un certain nombre
de problématiques et notamment des besoins d’ana- lyse des données. Afin de pouvoir réduire l’utilisation de produits phytosanitaires, il est nécessaire de pouvoir analyser les données concernant les observa- tions d’attaques de bio-agresseurs dans les cultures et de les croiser avec d’autres. Il est par exemple intéressant de pouvoir croiser une observation d’at- taque agricole avec diﬀérentes techniques de lutte possibles contre cette attaque. Pour cela, le projet VESPA s’intéresse au stockage et à l’indexation des BSV pour faciliter l’analyse des attaques sur- venant dans les cultures françaises. L’indexation des BSV se faisant par un dictionnaire maintenu manuellement, il est diﬃcile de pouvoir couvrir l’in- tégralité du vocabulaire présent dans les BSV. Il est intéressant de pouvoir créer un vocabulaire d’in- dexation avec les diﬀérentes sources présentes dans ce domaine. La création de ce vocabulaire sous la forme d’une base de connaissances pouvant intégrer le Web de données liées agricole est un atout maître pour permettre le décloisonnement de ces données. Après avoir étudié les diﬀérents types de sources Figure 13 – Info-box Blé Dur disponibles, nous avons pu noter deux points im- Wikipedia portants. Le premier est l’hétérogénéité des types de sources disponibles dans ce domaine. En eﬀet, nous avons pu observer qu’il existe des thésaurus, des taxonomies, des bases de données ou encore des bases de connaissances pouvant être considérés dans la création de ce vocabulaire. Le deuxième aspect est la complémentarité des sources, en particulier au niveau de leur qualité. Certaines sources peuvent être particulièrement fournies mais ne garantissent pas la qualité des éléments représentées, alors que d’autres sources garantissent une certaine qualité mais sont moins exhaustives. Nous pouvons prendre l’exemple d’Agrovoc qui propose un grand nombre de labels mais qui peut aussi contenir un certains nombres d’erreurs [Soergel et al., 2004], alors que TaxRef est une référence en matière de taxonomie des organismes vivants en France mais contient bien moins de labels.
Il est alors particulièrement pertinent, dans ce cas, de pouvoir considérer plusieurs sources dans un processus de construction d’une base de connaissances. De cette manière, il serait possible d’exploiter la quantité et la complémentarité des sources présentes dans le domaine de l’agriculture.

Méthodologie de construction de base de connaissances : NeOn

Afin de pouvoir construire une base de connaissances à partir de sources non-ontologiques, il est nécessaire de suivre une méthodologie définissant les diﬀérentes étapes nécessaires de ce processus. Une telle méthodologie considère tout le processus de création, de la définition des besoins jusqu’à la validation du résultat et la mise à disposition.
Afin de déterminer la méthodologie à utiliser, nous avons défini trois critères importants que doit permettre la méthodologie. Le premier critère est la possibilité de réutiliser des sources non-ontologiques dans le processus de création. Nous souhaitons pouvoir exploiter la quantité de sources disponibles dans le domaine de l’agriculture, comme nous l’avons observé dans la section 2.4 du chapitre I.
Le deuxième critère est la réutilisation de patrons de conception dans le processus afin d’améliorer la qualité de la modélisation. Il est courant de considérer, dans le domaine du génie logiciel, la réutilisation de patrons de conception. Il en est de même pour l’ingénierie des connaissances. La réutilisation de patrons de conception dans la modélisation d’une ontologie permet de faciliter le travail de modélisation en s’assurant d’une certaine qualité. Ces patrons de conception permettent aussi de faciliter la mise en correspondance des ressources de diﬀérentes bases de connaissances. Il devient alors plus facile de lier deux ontologies modélisées suivant les même patrons de conceptions [Gangemi and Presutti, 2009]. Il existe un entrepôt de patrons de conceptions pouvant être réutilisés sur le site Ontology Design Pattern 56. Ce critère est d’autant plus intéressant que la FAO 57 a proposé des patrons de conception pour le domaine de l’agriculture.
Enfin, notre dernier critère est la possibilité de créer des ontologies modulaires. Pour faciliter la création d’une ontologie de grande taille [Rector, 2003, d’Aquin et al., 2006], elle est découpée en plusieurs modules, chacun étudiant un aspect spécifique de cette ontologie [Grau et al., 2007]. Tous les modules sont ensuite reliés pour créer l’ontologie finale. Cette modularisation des ontologies est assimilable à la décomposition en diﬀérents paquetages d’un système d’information en ingénierie logicielle.
Bien que plusieurs méthodologies aient été définies dans la littérature, à notre connais-sance une seule permet de répondre à nos trois critères : la méthodologie NeOn. Cette méthodologie se décline en neuf scénarios, chacun proposant une méthode diﬀérente de construction d’ontologies suivant les objectifs souhaités. Chaque scénario est constitué de diﬀérents processus pour la construction collaborative d’ontologies et de réseaux d’ontologies. La figure 14 présente ces scénarios. [Suárez-Figueroa, 2010]
1. «Des spécifications à l’implémentations» : Le premier scénario permet la construc-tion d’une ontologie ex nihilo, c’est à dire qu’aucune autre source n’est utilisée dans cette méthode.
2. «Réutilisation de sources non ontologiques» : Ce scénario permet le développe-ment d’une ontologie à partir de sources non-ontologiques telles que des thésaurus, des bases de données ou autres.
3. « Réutilisation de sources ontologiques » : Ce scénario propose une méthode pour la construction d’une ontologie en réutilisant d’autres ontologies existantes, ou par réutilisation de parties d’ontologies existantes.
4. « Réutilisation et reingénierie de sources ontologiques » : Ce scénario est simi-laire au précédent, si ce n’est que les ontologies considérées dans cette méthodologie peuvent être modifiées si nécessaire.
5. « Réutilisation et fusion de sources ontologiques » : Ce scénario permet la réuti-lisation de sources ontologiques et leur fusion pour créer l’ontologie finale.
6. « Réutilisation, réingénierie et fusion de sources non ontologiques » : Ce scéna-rio est similaire au précédent en incluant de possibles modifications aux ontologies sélectionnées avant la fusion.
7. « Réutilisation de patrons de conceptions ontologiques (ODP) » : Ce scénario pro-pose de sélectionner des patrons de conception ontologiques qui permettront la construction d’une ontologie.
8. « Restructuration de sources ontologiques » : Ce scénario modifie les ontologies pour les intégrer dans un réseau d’ontologies.
9. « Localiser des sources ontologiques » : Ce scénario traduit une ontologie dans une langue donnée.
Grâce à la diversité de ces scénarios, la méthodologie NeOn permet de couvrir un grand nombre de situations. Ces scénarios ne sont pas incompatibles et un certain nombre de processus sont communs à tous les scénarios. Nous pouvons le remarquer sur la figure 14, car tous les scénarios impliquent l’application du scénario 1. Ce scénario est donc central dans cette méthodologie et dresse les étapes principales de la création d’une base de connaissances, quel que soit le scénario choisi. Ce scénario définit 5 étapes :
1. Spécifications des besoins : Durant cette étape, l’équipe en charge du dévelop-pement d’une base de connaissances doit définir les besoins d’une telle base de connaissances comme le domaine, la langue ou encore les objectifs que la base de connaissances doit respecter. Ces objectifs sont représentés sous forme de questions auxquelles la base de connaissances doit pouvoir répondre.
2. Plannification : Cette étape de planification permet de définir un calendrier des objectifs à atteindre et les ressources humaines qui seront nécessaires pour ces objectifs.
3. Modélisation : L’étape de la modélisation de la base de connaissances permet la structuration et l’organisation des diﬀérentes connaissances à représenter.
4. Formalisation : Cette étape permet la formalisation des connaissances en suivant un vocabulaire prédéfini.
5. Implémentation : Cette dernière étape permet la représentation des connaissances sous un format d’implémentation manipulable par une machine (par exemple en OWL).
Le résultat de ce scénario est une base de connaissances implémentée. Les autres scénarios permettent d’obtenir des éléments pouvant aider à l’application du scénario 1. Le scénario 3 permet par exemple de trouver d’autres ontologies pouvant aider à la modélisation de notre base de connaissances.
Cette méthodologie prenant en compte tous les critères énumérés ci-dessus, nous avons décidé de l’utiliser comme structure pour la proposition que nous présentons dans ce manuscrit.

Utilisation des associations

Considérons maintenant le traitement des relations d’associations (related term) pré-sentes dans un thésaurus. Ces relations permettent de définir une relation entre deux concepts du thésaurus sans en définir la nature exacte. Pour étudier leur traitement, nous allons, là-encore, définir plusieurs critères qui seront ensuite utilisés dans le tableau 3 :
— Utilisation (Util.) précise si la méthode prend en compte les relations d’associations (relations « related » dans les thésaurus) ;
— Traitement (Trait.) détermine le niveau d’automatisation du traitement des relations d’association (aucun traitement, manuel, semi-automatique, automatique) ;
— Désambiguïsation (Désamb.) détermine si ces relations sont désambiguïsées lors de la transformation, et précise la technique utilisée ;
— Validation (Val.) précise si la méthode applique un processus de validation (manuel ou automatique) concernant ces relations.
Les relations d’associations sont les plus diﬃciles à transformer car leur sens n’est pas précisé. Elles peuvent en eﬀet représenter tout type de relations ontologiques.
C’est pour cela que, comme nous l’observons dans le tableau 10, certains travaux [Hepp and De Bruijn, 2007, Van Assem et al., 2004, Wielinga et al., 2001] ne prennent pas en compte ces relations du thésaurus. Les travaux présentés dans [Charlet et al., 2012, Kless et al., 2012, Li and Li, 2012] traitent ces relations de manière entièrement manuelle, ce qui permet par la même occasion de les désambiguïser. La méthode proposée par [Hahn, 2003] extrait automatiquement les relations ambiguës et un expert les désa-mbiguïse manuellement. Nous retrouvons [Chrisment et al., 2008, Soergel et al., 2004, Villazon-Terrazas et al., 2010] qui traitent ces relations de manière automatique. Les travaux présentés dans [Soergel et al., 2004] utilisent le même procédé que pour les rela-tions hiérarchiques, c’est-à-dire une utilisation de règles de désambiguïsation permettant d’identifier des relations entre les éléments. [Villazon-Terrazas et al., 2010] utilise, lui aussi, le même procédé que pour les relations hiérarchiques, autrement dit l’utilisation d’un patron de transformation et potentiellement une source externe pour désambiguïser cette relation (sans préciser la méthode exacte). La méthode qui eﬀectue un traitement intéressant de ces relations est celle présentée par [Chrisment et al., 2008]. Elle extrait toutes les relations d’association du thésaurus pour poser des hypothèses de relations candidates entre les classes de l’ontologie. Ces relations sont ensuite désambiguïsées par un traitement automatique qui exploite un corpus de textes du domaine. Si plusieurs relations existent, le choix est laissé à l’utilisateur.
Ignorer les relations d’associations lors d’un processus de transformation d’un thésaurus en ontologie ne permettrait d’avoir qu’une hiérarchie de classe. Or il est particulièrement intéressant de pouvoir exporter les liens entre ces classes autre que hiérarchiques. Malheu-reusement, leur extraction reste complexe. Le traitement d’un corpus de textes, comme le préconise [Chrisment et al., 2008], est une méthode très intéressante pour permettre la désambiguïsation de relations en fonction des occurrences de ces relations dans le texte. Néanmoins, il nous faudrait disposer d’un corpus suﬃsamment important pour qu’il nous permette d’identifier tous les noms de relations entre classes de l’ontologie. Nous avons souhaité, dans ces travaux, nous concentrer sur le traitement de sources structurées. Nous souhaitons pouvoir transformer des thésaurus de grandes tailles en minimisant l’intervention humaine. En cela, l’utilisation de patrons de transformation spécifiques suivie d’une désambiguïsation par la comparaison des sources est la solution la plus envisageable. Elle permet de n’avoir à spécifier qu’un patron de transformation pour eﬀectuer la transformation. Ce patron spécifique contient les règles de désambiguïsation des relations dans le thésaurus. Nous retrouvons aussi le problème de la validation des éléments extraits, car la désambiguïsation à l’aide de sources externes n’est pas totalement fiable, ces sources pouvant contenir des erreurs.

Transformation de bases de données

Après avoir étudié les méthodes de transformation de thésaurus, nous allons maintenant nous intéresser aux méthodes de transformation des bases de données. Notre volonté étant de réutiliser des sources non-ontologiques existant sur le Web, il nous est apparu important de considérer les bases de données au vu de leur place centrale dans les systèmes d’informations actuels. Cette section décrit et analyse les méthodes permettant la transformation d’une base de données (structure et contenu) en une base de connaissances. L’étude de la littérature sur ce domaine a fait apparaître deux familles de techniques :
— Transformation par règles
— Transformation par un langage intermédiaire

Transformation par règles

Cette famille de méthodes propose de définir des règles permettant d’identifier les actions pour la transformation. Nous pouvons par exemple définir que toutes les tables deviennent des classes dans l’ontologie finale. Les travaux [Sequeda et al., 2011b, Astrova, 2004, Tirmizi et al., 2008, Cerbah, 2008, Arenas et al., 2012] appliquent ce principe de règles de transformation. D’après l’étude [Sequeda et al., 2012], les travaux les plus aboutis sont ceux présentés dans [Tirmizi et al., 2008] grâce à la complétude des règles définies. Cette complétude est étudiée en fonction des caractéristiques des bases de données prises en compte par les règles. Il a été montré dans [Sequeda et al., 2011b] que les travaux présentés dans [Tirmizi et al., 2008] respectent cette complétude, contrairement aux autres travaux de l’état de l’art.
Nous pouvons remarquer que cette famille de méthodes est similaire à la définition de patrons de transformation présentés dans [Villazon-Terrazas et al., 2010].
Règles de transformations [Tirmizi et al., 2008] Les travaux de [Tirmizi et al., 2008] définissent six règles pour transformer une base de données relationnelle. Ces six règles sont définies de la façon suivante :
Régle 1 : détecte une table binaire qui servira à la mise en place des règles suivantes. Ce type de table spécifie une relation entre deux autres tables. Elle ne contient donc que deux attributs (ou ensembles d’attributs) qui sont des clefs étrangères vers deux autres tables. Elle ne contient aucune autre clef étrangère ou autre attribut. Elle permet donc de spécifier les relations [0..n] entre deux tables.
Règle 2 : pose la condition selon laquelle si une table n’est pas une table binaire, alors une classe OWL est créée.
Règle 3 : définit la génération d’une propriété d’objet entre deux classes s’il existe une table binaire définissant une relation entre les deux tables qui ont servi à la création des deux classes.
Règle 4 : est composée de plusieurs sous-règles pour définir les propriétés (Object- Property) provenant de clefs étrangères mais sans tables binaires :
Règle 4.a : conduit à la définition d’une propriété fonctionnelle s’il existe une clef étrangère vers une table non binaire sans la contrainte NOT NULL, ni UNIQUE.
Règle 4.b : est la même que la a, seulement avec la contrainte NOT NULL sur la clef étrangère. Cette contrainte ajoute le fait que la cardinalité de la propriété est forcément égale à 1. Chaque instance de cette classe aura nécessairement cette relation.
Règle 4.c : est la même que la a, avec la contrainte UNIQUE. Cette contrainte ajoute le fait que la propriété inverse est aussi fonctionnelle.
Règle 4.d : est la même que la a, avec les contraintes NOT NULL et UNIQUE.
Les cardinalités de la propriété générée et de son inverse sont égales à 1.
Règle 5 : définit les conditions pour la génération de propriétés de type de données avec plusieurs sous-règles :
Règle 5.a : indique que tout attribut qui n’est pas une clef étrangère sera traduit par une propriété de données. Cette propriété de données est fonctionnelle en raison de la structure des attributs dans les bases de données.
Règle 5.b : est la même que la a avec la condition NOT NULL. Celle-ci ajoute la cardinalité 1 à la propriété de données.
Règle 5.c : est la même que la a avec la condition CHECK. Cette condition ajoute le fait que la valeur de la propriété de données doit être dans la liste définie en base de données.
Règle 6 : définit les conditions nécessaires pour la génération d’une relation de type « subClassOf » (spécialisation) entre deux classes de l’ontologie. Il faut pour cela que deux tables soient reliées par une clef étrangère qui est aussi considérée comme clef primaire de la table source.
Les travaux présentés dans [Tirmizi et al., 2008] présentent quatre propriétés qui doivent être respectées pour que les règles définies permettent une transformation consi-dérée comme valide : Conservation des informations : Possibilité de transformer la base de connaissances générées pour retrouver la base de données initiale.
Conservation des requêtes : Toutes les requêtes possibles sur la base de données le sont aussi sur la base de connaissances.
Monotonie : Une modification sur la base de données peut être incluse dans la base de connaissances finale sans refaire tout le processus de transformation.
Conservation sémantique : Si la base de données est inconsistante, alors la base de connaissances le sera aussi.
Ces règles ont été étendues [Sequeda et al., 2011a] et proposées dans une recommandation du W3C 59 [Arenas et al., 2012].

Transformation par un langage intermédiaire

La deuxième famille de méthodes de transformation est la transformation par l’utilisa-tion d’un langage intermédiaire. Pour cela, nous pouvons citer deux travaux représentatifs [Auer et al., 2009, Das et al., 2012].
Les méthodes de cette famille ne sont pas directement des méthodes de transformation mais plutôt une proposition d’implémentation des transformations. Néanmoins, certains travaux cherchent à transformer des bases de données en exploitant directement un langage intermédiaire défini. C’est notamment le cas de [Auer et al., 2009] qui a proposé des transformations de bases de données d’applications très utilisées sur le Web 60.
Le projet Triplify [Auer et al., 2009] propose d’étendre le langage SQL en ajoutant des informations concernant la transformation à eﬀectuer. Nous pouvons prendre l’exemple suivant :
. SELECT id.
. price AS ’price^^xsd:decimal’.
. desc AS ’rdfs:label@en’.
. cat AS ’belongsToCategory->category’.
. FROM products.
Cette requête permet de spécifier que l’attribut « price » de la table « products » est une propriété de données de type décimal, l’attribut « desc » est un label en anglais et l’attribut « cat » est une propriété nommée « belongsToCategory » vers une instance de « category ».
Le projet R2RML [Das et al., 2012] est également une recommandation du W3C 61 sur l’utilisation de JSON comme langage intermédiaire pour définir la transformation à eﬀectuer sur la base de données. Nous pouvons prendre l’exemple suivant :
Cet exemple prend en compte une table « EMP » qui permet la création de la classe « Employee ». Cette table a l’attribut « EMPNO » qui est utilisé pour la génération de l’URI d’une instance. Elle contient aussi l’attribut « ENAME » qui est transformé en une propriété de données de « Employee » nommée « ex :name ». Un exemple de résultat est :
En plus de ces deux familles, il existe d’autres travaux qui présentent des approches dédiées à une base de données spécifique [Dhombres et al., 2012, Krivine et al., 2009]. Ces travaux montrent que les méthodes génériques ne sont pas forcément pertinentes dans un cas réel. Les méthodes présentées précédemment montrent toutes des limites dans le cas des bases de données complexes. C’est particulièrement le cas pour la gestion des relations de spécialisation entre classes (subClassOf) qui n’est pas suﬃsamment explicite dans les bases de données. Les approches à base de règles peuvent découvrir certaines de ces relations mais peuvent aussi apporter du bruit, alors que les méthodes utilisant un langage intermédiaire permettent de mettre en place la transformation directement au niveau des éléments de la base de données.

Analyse des méthodes de transformation

Cette étude des méthodes de transformation de thésaurus et de bases de données nous permet de déduire qu’il n’existe, ni pour les thésaurus, ni pour les bases de données, de méthodes génériques permettant une transformation automatique de bonne qualité. Les méthodes proposant une qualité suﬃsante nécessitent une intervention humaine, soit au départ pour définir la transformation, soit pour valider et enrichir le résultat obtenu. Il apparaît que lorsque nous souhaitons transformer une source non-ontologique, même autre qu’un thésaurus ou une base de données, il est nécessaire de définir les règles à utiliser pour transformer la source. Les travaux qui sont les plus adaptés et génériques pour prendre en compte tous les types de sources sont ceux présentés dans NOR2O [Villazon-Terrazas et al., 2010]. Ceux-ci permettent la définition d’un patron de transformation spécifique à la source en utilisant des patrons génériques déjà définis. De cette manière, il est possible d’utiliser des transformations génériques déjà définies (mais qui peuvent apporter du bruit) ou de spécialiser un patron de manière spécifique à la source étudiée. La faiblesse de cette méthode étant la désambiguïsation des relations, nous pouvons utiliser les travaux de [Soergel et al., 2004]. Ces travaux proposent des règles pour désambiguïser les relations. Nous devons alors trouver un moyen de définir les relations du domaine à utiliser.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

I Contexte
1 Le Web sémantique
1.1 Historique
1.2 Représentation des connaissances
1.2.1 Données/Informations/Connaissances
1.2.2 Le modèle de graphe RDF
1.2.3 Ontologie
1.2.4 Base de connaissances
1.3 Le Web de données liées
1.4 Le Web sémantique aujourd’hui
2 Domaine d’application : la protection des cultures agricoles
2.1 Présentation du domaine
2.2 Les Bulletins de Santé du Végétal (BSV)
2.3 PestObserver
2.4 Types de sources agricoles
2.4.1 Taxonomies
2.4.2 Thésaurus
2.4.3 Bases de données relationnelles
2.4.4 Base de connaissances
2.5 Bilan sur les sources agricoles
3 Méthodologie de construction de base de connaissances : NeOn
4 Conclusion
II Etat de l’art
1 Transformation de sources non-ontologiques
1.1 Transformation de Thésaurus
1.1.1 Présentation des travaux
1.1.2 Utilisation de la terminologie
1.1.3 Utilisation de la hiérarchie
1.1.4 Utilisation des associations
1.1.5 Analyse
1.2 Transformation de bases de données
1.2.1 Transformation par règles
1.2.2 Transformation par un langage intermédiaire
1.2.3 Analyse
1.3 Analyse des méthodes de transformation
2 Alignement d’ontologies
2.1 Définitions
2.2 Stratégies
2.3 OAEI
2.4 LogMap
3 Fusion de bases de connaissances
3.1 Fusion d’ontologies
3.2 Conflits lors de l’alignement
4 Qualité d’une source
5 Conclusion
III Contributions scientifiques
1 Processus général
1.1 Fusion de scénario NeOn
1.1.1 Scénario 7 : Réutilisation de patrons de conception ontologiques (ODP)
1.1.2 Scénario 2 : Réutilisation d’une source non-ontologique
1.1.3 Fusion des scénarios 2 et 7
1.2 Description du processus
2 Analyse des sources
3 Transformation de sources
3.1 Module ontologique
3.2 Transformation automatique d’une source
3.2.1 Base de connaissances source
3.2.2 Processus de transformation
3.2.3 Patron de transformation
4 Fusion de bases de connaissances
4.1 Processus de fusion de bases de connaissances
4.2 Alignements des bases de connaissances sources
4.2.1 Correspondance
4.2.2 Alignement
4.2.3 Bases de connaissances sources alignées
4.3 Génération de candidats
4.3.1 Candidat sommet
4.3.2 Candidat arc
4.3.3 Algorithme de génération des candidats
4.4 Calcul de la confiance d’un candidat
4.4.1 Trust likelihood
4.4.2 Trust Degree
4.4.3 Intégrale de Choquet
4.5 Découverte de l’extension optimale
4.5.1 Hypothèse d’incompatibilité
4.5.2 Définition d’une extension
4.5.3 Algorithme de recherche de clique maximale
4.5.4 Algorithme supervisé (branch and bound)
5 Mise à disposition des extensions sur le LOD
5.1 Ontologie de provenance : PROV-O
5.2 Export OWL
6 Conclusion
IV Implémentation
1 Serveur de données RDF (SPARQL endpoint)
1.1 L’utilisation de Fuseki
1.2 SparqlLib
1.2.1 Modélisation du projet SparqlLib
1.2.2 Exemple d’utilisation
2 Interface Seals
3 Solveur Choco
4 Modélisation de Muskca
4.1 muskca
4.2 Source
4.3 MultiSources
4.4 Candidate
4.5 Alignment
V Expérimentations
1 Expérimentation sur un cas réel : la taxonomie des blés
1.1 Mise en place du cadre expérimental
1.1.1 Module ontologique : AgronomicTaxon
1.1.2 Sources
1.1.3 Données de référence
1.2 Évaluation de la qualité des candidats générés
1.2.1 Stratégie de validation
1.2.2 Résultats
1.2.3 Analyse
1.3 Évaluation du score de confiance pour la génération d’une extension
2 Expérimentations sur un jeu de données issu du Web de données liées
2.1 Présentation de la tâche QA4OA de l’OAEI
2.2 Mise en place du cadre expérimental
2.2.1 Module ontologique pour la tâche QA4OA – OAEI
2.2.2 Sources
2.2.3 Paramétrage de Muskca
2.3 Stratégie de validation
2.3.1 Adaptation des requêtes
2.3.2 Adaptation du jeu de données de référence
2.3.3 Adaptation des fonctions de calculs
2.4 Résultats
2.5 Analyses
3 Conclusion
Conclusion
VI Annexes
VII Bibliographie