Un processus dirigé par les modèles pour la création de bases de connaissance ontologiques

Transcription

1 Un processus dirigé par les modèles pour la création de bases de connaissance ontologiques Guillaume Hillairet, Frédéric Bertrand, Jean Yves Lafaye Laboratoire Informatique Image Interaction Université de La Rochelle, La Rochelle, France {guillaume.hillairet01, Tfrederic.bertrand, RÉSUMÉ. Les modèles de domaine sont aujourd'hui des entités de premier plan dans le cycle de production du logiciel. Au sens de l'ingénierie, les modèles de domaine sont une représentation précise et concise des éléments et des relations d un domaine. Ils permettent de définir un point de vue stable et consensuel sur le contexte applicatif dans lequel se développent les différentes phases de conception. Dans le domaine de la représentation des connaissances, et plus récemment dans celui du Web sémantique, ce sont les ontologies qui, dans une autre perspective, permettent de répertorier et représenter le vocabulaire et l ensemble structuré des concepts d un sujet ou d une discipline que l'on veut partager entre différents acteurs. Nous pensons que les modèles de domaine développés dans le cadre de la conception de logiciels, constituent de fait une source d'information importante et utile pour faciliter le processus de conception d ontologies. En conséquence, nous proposons dans cet article un processus dirigé par les modèles pour la création d'une base de connaissance à partir d'un modèle du domaine annoté et des données persistantes associées. Ce processus comporte deux étapes fondées sur la transformation de modèles. La première concerne la production d une ontologie à partir d un modèle de domaine annoté sémantiquement. La seconde concerne le peuplement automatique de la base de connaissance par extraction de données persistantes définies conformément au modèle du domaine considéré. MOTS-CLÉS : Transformation de modèles, Modèle du Domaine, Ontologie. 1. Introduction Le travail dont nous rendons compte ici, porte sur la spécification et l exploitation de correspondances explicites entre modèles de domaine et ontologies. Plusieurs contextes applicatifs peuvent être évoqués pour préciser nos objectifs. Un premier cas d utilisation sera, par exemple, celui d un utilisateur exerçant ses activités dans un domaine donné, disposant de masses d informations et souhaitant développer un portail d accès fondé sur une ontologie locale. Un second cas est celui

2 IDM' juin Mulhouse où un utilisateur désirerait adopter une ontologie standard pour implémenter l indexation de ses informations propres, grâce à la structure de concepts partagée. D autres cas sont également envisageables dans le contexte d architectures pair à pair ou dans celui de l alignement d ontologies. Quel que soit le contexte, nous supposons que l utilisateur dispose d un modèle du domaine où il exerce. Ce modèle peut être exprimé avec divers langages de modélisation (UML, MOF, DSL). La gestion de la persistance des informations est assurée, soit par des SGBD relationnels, soit par des documents XML, des fichiers ou une combinaison de ces différents éléments. Le point de vue que nous adoptons est que les modèles métiers ou modèles du domaine sont des descriptions centrales particulièrement adaptées à servir de cadre pour exprimer et rendre opérationnelles les correspondances entre les différents espaces technologiques (objet, ontologique, relationnel, XML ) [Fowler 03] Le corollaire de cette affirmation est que nous pouvons, par une approche dirigée par les modèles faisant un usage extensif et contrôlé de transformations de modèles, offrir des environnements d aide à la gestion de mégamodèles [Bézivin 04] qui incluent à la fois les paradigmes objet, relationnel et ontologique. Ces environnements formalisent et contrôlent les processus en automatisant une part importante des activités. Ils garantissent ainsi une forme de qualité et de fiabilité des produits. En ce qui concerne la correspondance objet-ontologie, nous nous référons aux concepts exprimés dans ODM (Ontology Defintion Metamodel) [OMG ODM] que nous enrichissons pour les rendre effectivement opératoires. Pour le passage objetrelationnel, nous spécifions un modèle général de tissage pouvant rendre compte de toute correspondance pratique, qu elle soit fournie par un expert sous forme d annotations, par des fichiers de paramètres (e.g. Hibernate 1 ), ou par un algorithme de normalisation particulier. La correspondance entre la base de connaissance associée à l ontologie et la structure persistante des objets est obtenue par exploitation des correspondances entre modèle objet et ontologie. En conséquence, il devient formellement et pratiquement équivalent d interroger la base de connaissance par un langage de requête de type SPARQL, pour retourner des individus, ou d exécuter une requête SQL sur la base de données relationnelle assurant la persistance des objets du système pour obtenir un ensemble de n-uplets Pour mettre en œuvre cet ensemble complexe, nous spécifions précisément des métamodèles d annotation du modèle objet du domaine (orientés modèle d ontologie ou modèles de persistance). Nous spécifions également des métamodèles de transformation de modèles s appliquant aux modèles d objets, aux modèles de données et aux modèles de transformations (transformations d ordre supérieur). L ensemble de ces propositions rend explicite les correspondances entre espaces technologiques, assure la complétude et la cohérence des informations mises en jeu. 1

3 IDM pour la création de bases de connaissance ontologiques Dans la section suivante nous présentons notre approche en précisant les différents espaces technologiques impliqués. Puis nous détaillons le modèle d annotation et son application aux modèles de domaine. La dernière partie porte sur l utilisation des annotations pour générer une transformation permettant de peupler une base de connaissance liée à l ontologie. Nous concluons en présentant les perspectives de notre travail en ce qui concerne l interrogation de la base de connaissance. 2. Présentation de notre approche Nous présentons dans cet article une approche fondée sur l ingénierie dirigée par les modèles permettant la construction d une base de connaissance OWL-DL [McGuinness 03] à partir de données provenant de sources de données hétérogènes. Le choix de OWL comme langage commun pour la représentation des connaissances a été motivé par le fait qu il fournit d importantes capacités d inférences tant au niveau de l ontologie qu au niveau des individus. Ces capacités sont liées au fait que ce langage repose sur la logique de description [Baader 03]. De plus, OWL est également considéré comme le standard pour le partage d ontologies dans le cadre du Web Sémantique [Bernes Lee 01]. Les travaux précédents portant sur l intégration de données, principalement relationnelles - vers des bases de connaissance ontologiques ont soulevé de nombreuses questions. Néanmoins, leur principale limitation porte sur le fait qu ils ne proposent une solution que pour un seul type de données [Bizer 06] [Chen 06] [De Laborda 06]. À partir de ce constat, nous proposons d étendre le champ d action en concevant une approche générique acceptant différents types de données. Nous avons adopté une approche dirigée par les modèles pour assurer la traduction du couple schéma/n-uplets vers le couple ontologie/individus. Cette approche nous permet également de préciser en la modélisant la notion d espace technologique, paradigme répondant à ses propres règles, possédant un formalisme et utilisant des langages spécifiques [Djuric 06]. Les espaces technologiques les plus connus sont l espace des bases de données relationnelles, celui des grammaires, celui des ontologies ou enfin celui de l ingénierie des modèles. La figure 1 détaille la vue d ensemble de notre approche. L espace technologique de l IDM agit comme un espace pivot dans lequel s exécutent l ensemble des transformations de données. Ces dernières sont structurées conformément à un modèle du domaine unique représentant les principaux concepts du système. Les données sont importées dans l espace pivot sous forme de modèles à l aide de techniques de rétro-ingénierie dirigée par les modèles. Un espace technologique central agissant comme espace pivot nous semble être une architecture intéressante, en cela nous réduisons la complexité de mise en œuvre des ponts entre technologies. Ainsi l IDM est bien adaptée pour répondre à ce

4 IDM' juin Mulhouse problème d intégration de données, en raison de ses capacités pour représenter et traiter des artefacts hétérogènes sous un même formalisme. Figure 1. Vue d ensemble des projections entre espaces technologiques. L espace technologique des ontologies est utilisé comme espace de travail pour gérer l ontologie et les individus correspondants. Cet espace offre naturellement un point de vue idéal pour la navigation et le partage des connaissances du système [Wache 01]. 3. Annotation de modèles pour la création d ontologies Dans cette section, nous présentons une approche permettant la création semiautomatique d une ontologie à partir d un modèle de domaine annoté. Nous supposons que les modèles de domaine sont disponibles dans tout système d information. Ils sont généralement spécifiés dans la première phase de conception du système, ou bien générés par la suite à l aide de techniques de rétro-ingénierie. Notre proposition exploite ces modèles du domaine afin d en extraire l information nécessaire pour en dériver une ontologie à l aide d un processus d annotation. Dans la suite, nous considérerons les modèles de modèles comme étant des langages spécifiques de domaines (DSL), ou métamodèles. Nous illustrerons notre approche tout au long de cet article en utilisant comme exemple un métamodèle relativement simple représentant les entités existant dans un musée, donné dans la figure 2.

5 IDM pour la création de bases de connaissance ontologiques Figure 2. Modèle du domaine utilisé comme exemple Le processus d annotation De nombreux travaux ont proposé l utilisation des outils de l IDM pour la définition d ontologies, notamment à l aide d une notation s appliquant à des diagrammes de classes UML et par l utilisation de profils UML [Djuric 05]. La spécification ODM de l OMG fournit la définition d un ensemble de métamodèles relatifs aux ontologies tels RDF(S), OWL ou bien encore Topic Maps, ainsi que la définition de règles de transformations QVT. Néanmoins, la spécification ODM s inscrit par nature, dans un cadre très général, et les propositions de conversion qu elle préconise, doivent à la fois être spécialisées et étendues si l on vise des applications concrètes. Les modèles, tels que ceux utilisés dans l IDM, sont bien adaptés pour décrire la structure de systèmes mais ils manquent d expressivité pour représenter la connaissance. De plus, ces modèles, fortement orientés objet, sont généralement conçus par des développeurs plus familiers des technologies objet que des termes de logique de description sous jacents à la conception d ontologies OWL. L intervention d un expert du domaine semble nécessaire durant la création de l ontologie afin d assurer la consistance de l ontologie et le respect des attentes des utilisateurs. Il est important de pouvoir assister l expert du domaine pendant son interaction avec le système. Nous assurons cette assistance en proposant l usage d annotations afin de permettre à l expert d enrichir le modèle du domaine en sélectionnant, généralisant ou en spécialisant les concepts qui lui semblent nécessaires de figurer dans l ontologie résultante. L annotation de modèles est le fait de marquer un ensemble de classes et propriétés à l aide de termes spécifiques, ici des termes ontologiques. L annotation du modèle de domaine est réalisée à l aide d un langage d annotation que nous avons développé et nommé OAM (Ontology Annotation Metamodel). Les annotations sont alors représentées sous la forme d un modèle conforme au métamodèle OAM. Nous présentons ici le cas où l ontologie est construite à partir du modèle de domaine, mais notre approche peut être étendue au

6 IDM' juin Mulhouse cas où l on souhaite étiqueter les éléments du modèle par des concepts d une ontologie donnée. Figure 3. Chaîne de transformations de modèles pour la création de l ontologie. Le processus d annotation tel que décrit par la figure 3 est le suivant : a) Définition du modèle de domaine. Pour des raisons d implémentations, nous considérons que le modèle de domaine est défini au niveau M2 sous la forme d un métamodèle. De plus cela nous permet de gérer les données au niveau M2 sous forme de modèles comme nous le verrons dans les sections suivantes. b) Définition des annotations en utilisant le langage OAM par un expert du domaine. Le modèle contentant les annotations peut être construit de deux manières : - Soit directement par un expert du domaine à l aide d un outil spécifique. - Soit généré par une transformation de modèles appliquant les règles de mapping définis dans ODM sur le modèle de domaine. Le modèle d annotations résultant peut alors être ensuite raffiné par un expert du domaine. c) Enfin la dernière étape est la génération de l ontologie par une transformation de modèles prenant en entrée le modèle de domaine et les annotations. Cette transformation produit également un modèle de trace entre l ontologie et le modèle de domaine Métamodèle d annotation d ontologie (Ontology Annotation Metamodel) OAM permet l annotation de métamodèles par des concepts ontologiques. OAM a été développé en tant qu extension à l outil de tissage de modèles AMW (Atlas Model Weaver) [Didonet Del Faro 05]. Un modèle de tissage est conforme à un métamodèle définissant des relations sémantiques entre modèles. Une solution

7 IDM pour la création de bases de connaissance ontologiques alternative aurait pu être apportée par l utilisation de profils UML pour stéréotyper les annotations. Nous comparons la notion de tissage de modèles avec la définition de «mapping» donnée dans [Shvaiko 05]. Un tissage peut être défini par un quadruplet : <m, MM, M1, M2> où : - m est un ensemble d éléments de tissage ou liens. - MM est le métamodèle de tissage. - M1 et M2 sont les modèles participants au tissage. Selon [Shvaiko 05], un élément de «mapping» est un quintuplet : <id, e, e, n, R>. Ici nous considérerons la variable n représentant une mesure de confiance comme étant égale à 1. Nous pouvons dès lors considérer un élément de tissage comme étant un quadruplet : <id, e, e, R> où - id est un identifiant unique. - e et e sont des éléments respectivement de M1 et M2. - R est une instance du méta-élément défini dans MM et représente une relation sémantique entre une paire <e, e >. Un modèle d annotations est un cas particulier de modèle de tissage dans le sens où il n est lié qu à un seul modèle et non deux. Un modèle d annotation peut alors être défini par un triplet : <m, MM, M> où M est le modèle annoté. Un élément de tissage dans une annotation peut être représenté par un triplet : <id, e, R> où R est associé à un unique élément e du modèle M. Dans le cas présenté ici, MM correspond au métamodèle OAM et M au modèle du domaine que l on souhaite annoter. AnnotationModel annotations * OntologyAnnotation namespace : string localname : string 1 annotatedelement AnnotatedModelElement ClassAnnotation annotatedelement 1 PropertyAnnotation RestrictionAnnotation Ontology nsprefix : string subclassof OWLDataType * 1..* range 1 OWLClass 1..* condition OclExpression domain 1..* range hasinverse 1 ObjectProperty issymmetric : bool isinversefunctional : bool istransitive : bool * Property isfunctional : bool subpropertyof DatatypeProperty Restriction subpropertyof * Figure 4. Extrait du métamodèle OAM.

8 IDM' juin Mulhouse AMW permet à l utilisateur de définir son propre métamodèle de tissage de manière à satisfaire des besoins spécifiques. Un métamodèle de tissage est réalisé par extension du métamodèle de base d AMW. De cette manière, nous avons défini le métamodèle d OAM dont nous donnons un extrait dans la figure 4. Les principaux éléments d annotations sont : - OWLClass est une annotation utilisée pour marquer un concept de type EClass dans le modèle du domaine. Une annotation OWLClass peut posséder une condition prenant la forme d une expression OCL [OMG OCL]. Dans ce cas cette annotation induit le fait que la condition permet de créer une nouvelle classe par dérivation de la classe annotée. Les autres types d annotation de classes correspondent aux résultats d opérateurs ensemblistes (union, intersection, complément). - PropertyAnnotation regroupe les deux types de propriétés pouvant être définis par annotation, à savoir les DatatypeProperty s appliquant sur des EAttribute, et les ObjectProperty s appliquant sur les EReference Utilisation du modèle d annotations La création du modèle d annotations peut être réalisée soit directement par l utilisateur avec un outil de tissage de modèles [Didonet Del Faro 05], soit déduit du modèle de domaine par une transformation reprenant les règles de la spécification ODM. Ce dernier cas suppose que le modèle d annotations soit raffiné par un expert. Nous montrons ici un exemple d utilisation d annotations sur le métamodèle Museum. Les annotations correspondent à un ensemble d éléments référençant des éléments du métamodèle à annoter. Elles peuvent également comporter des contraintes OCL précisant leurs conditions d application. Figure 5. Modèle du domaine et Modèle d'annotation.

9 IDM pour la création de bases de connaissance ontologiques Dans l exemple présenté de la figure 5, le métamodèle Museum est présenté avec seulement une partie de ses classes. La classe Artist porte une annotation de type OWLClass indiquant que Artist devra être convertie en classe OWL. La condition liée à cette annotation indique également que seul un sous-ensemble des instances de la classe Artist devra être converti. Ce sous-ensemble devra satisfaire la contrainte OCL. La validation de cette contrainte sera vérifiée par la suite lors de la conversion des instances en individus, comme nous le verrons dans les sections suivantes Création de l ontologie La création de l ontologie est réalisée par une transformation de modèles prenant en entrée le métamodèle MMa (modèle du domaine ici Museum) ainsi que le modèle d annotations et produisant en sortie un modèle Mo conforme au métamodèle OWL [OMG ODM] [Brockmans 06]. La transformation produit également un modèle de tissage Mwmo entre MMa et Mo et qui sert de modèle de traçabilité et permet de connaître l origine des éléments de Mo (cf. fig. n 9). Un projecteur est ensuite utilisé pour sérialiser le modèle Mo dans le format XML associé à OWL, permettant ainsi l utilisation de l ontologie par des outils dédiés. 4. Intégration de données Dans cette section, nous présentons la manière dont nous gérons l extraction de données depuis une source de données de type quelconque, de manière à peupler la base de connaissance. Nous décrirons notre méthode en deux étapes : nous nous intéressons d abord au passage de la source de données vers les modèles, puis des modèles vers la base de connaissance Depuis la source de données vers les modèles La première phase d intégration de données met en jeu l espace technologique contenant la source de données et l espace technologique de l IDM. Le principe de notre approche est de représenter la source de données (schéma et données) sous forme de modèles. Cette étape met en jeu un projecteur [Jouault 06] qui injecte la source de données dans l espace des modèles. Notre approche se veut générique dans le sens où elle doit permettre l intégration de données hétérogènes, i.e. : provenant de différents systèmes de stockage (données relationnelles, semistructurées, objet, etc.). La seconde phase d intégration consiste à représenter les données suivant un modèle conforme à celui du domaine. Cette étape est naturellement réalisée par une suite de transformations de modèles Source de données utilisée Nous illustrons notre approche en prenant comme exemple le cas d une base de données relationnelle. Dans le cas d un autre type de données persistantes, le processus détaillé ici reste inchangé, seuls sont modifiés les métamodèles jouant un

10 IDM' juin Mulhouse rôle dans la projection. La base de données représente la couche de persistance de notre application dont le modèle du domaine est le métamodèle Museum présenté précédemment (cf. fig. n 3). Le schéma de la base de données est dérivé du modèle du domaine. Les différentes tables relationnelles sont décrites ci-après. Museum( IDMuseum, name, city ) Exhibits( IDMuseum, IDArtifact ) Artifact( IDArtifact, name, date ) Painting( IDPainting, IDArtifact, technique ) Sculpture( IDSculpture, IDArtifact, material ) Creates( IDArtifact, IDArtist ) Artist( IDArtist, firstname, lastname ) Représentation de la source de données sous forme de modèles La représentation de la base de données sous la forme de modèles est réalisée par une opération de rétro-ingénierie dirigée par les modèles à l aide de l outil Modisco 2. Ce dernier permet de spécifier un projecteur dédié à l exploitation des informations disponibles sur une source choisie, et opère ainsi la création du modèle cible. Dans le cas présent, nous appliquons l utilisation de cet outil à une base de données relationnelle. L objectif est de capturer le schéma de la base, puis d importer les données elles-mêmes. Pour cela, il est nécessaire de créer deux projecteurs, l un pour le schéma, et l autre pour les données, ce qui suppose l utilisation de deux métamodèles différents. Figure 6. Projection de la base de données relationnelle vers l espace technologique de l ingénierie des modèles. La illustre l utilisation de projecteurs pour le passage de la base de données vers les modèles. La base de données est représentée par un ensemble de données conforme à un schéma particulier. Nous considérons que la base de données est située au niveau M0. La définition des projecteurs Proj s et Proj d est réalisée selon 2 Modisco :

11 IDM pour la création de bases de connaissance ontologiques les métamodèles SQLDDL et DBContent respectifs. Le métamodèle SQLDDL est un sous ensemble du métamodèle CWM [OMG CWM] permettant la représentation de schémas relationnel. Le métamodèle DBContent a été d abord développé comme exemple d utilisation de l outil MoDisco et nous l avons ensuite étendu pour représenter le contenu de la base de données comme un ensemble de n-uplets. L exécution des projecteurs Proj s et Proj d fournit comme résultats les modèles Ms et Md, respectivement conformes aux métamodèles SQLDDL et DBContent. Un extrait du modèle Md est donné ci-après selon le format XMI [OMG XMI]. Il correspond à un n-uplet de la table Artist, contenant 3 éléments représentant les valeurs des différentes colonnes. <tables name="artist"> <tuples> <elements value="3" columnname="idartist"/> <elements value="pablo" columnname="firstname"/> <elements value="picasso" columnname="lastname"/> </tuples> </tables> Rendre les données conformes au modèle de domaine La seconde phase d intégration consiste à représenter le modèle Md obtenu précédemment sous la forme d un modèle Ma conforme à un métamodèle donné MMa, soit, dans le cas présent, le métamodèle Museum. Cette opération est réalisée par une transformation opérant entre un métamodèle constant, DBContent, et un métamodèle variable noté MMa. Notons Mt cette transformation définie par la fonction suivante : Mt : MMt(Md : DBContent) Ma : MMa. Le résultat de la transformation Mt est un modèle conforme à un métamodèle variable. Cela impose l utilisation d une transformation d ordre supérieur pour générer Mt. Figure 7. Tissage entre le modèle du domaine (MMa) et le schéma de la base de données (Ms). Nous utilisons un modèle de tissage entre le métamodèle MMa et le modèle du schéma relationnel représenté par le modèle Ms. Ce modèle de tissage est conforme à un métamodèle noté MRM (Metamodel Relational Mapping) qui étend le

12 IDM' juin Mulhouse métamodèle abstrait d AMW. Nous avons défini le métamodèle MRM de manière à rendre explicites les correspondances possibles entre concepts relationnels et concepts objets sous-jacents à l utilisation du MOF. Le métamodèle MRM a été défini à partir des travaux effectués sur les concepts d ORM [Ambler 06] (Object Relational Mapping). La illustre l utilisation de ce modèle de tissage. Figure 8. Transformation d ordre supérieur : exploitation du modèle de tissage pour générer la transformation Mt. Le modèle de tissage noté Mwsm est utilisé par une transformation d ordre supérieur notée Mht et définie par la fonction : Mht : MMt(Ms : SQLDDL, Mwsm : MRM, MMa : MOF) Mt : MMt La transformation Mt ainsi obtenue permet la conversion du modèle de la base de données Md en un modèle Ma représentant les données décritent par MMa. Les règles de transformation définies dans Mt permettent de créer, pour chaque n-uplet présent dans le modèle Md, son équivalent sous forme d élément conforme au métamodèle MMa. Pour cela le type correspondant à chaque n-uplet de Md doit être retrouvé dans MMa. Un extrait du modèle Ma résultat est donné au format XMI ciaprès. <Sculpture name="tete de femme" date="1931" hasartist="/12" exhibited="/20" material="plaster"/> <Painting name="guernica" date="1937" hasartist="/12" exhibited="/19" technique="oil"/> <Artist firstname="pablo" lastname="picasso" creates="/5 /4"/> 4.2. Des modèles vers la base de connaissance Dans cette sous-section, nous abordons le passage d une représentation d un modèle dans l espace technologique IDM à sa représentation sous forme de base de connaissance OWL. Cette phase reprend la même architecture que la phase précédente. Nous utilisons le modèle de tissage noté Mwmo obtenu lors de la phase de construction de l ontologie, comme modèle de traçabilité entre les éléments de

13 IDM pour la création de bases de connaissance ontologiques MMa et les éléments de Mo. Ce modèle est conforme au métamodèle noté MOM (Metamodel Ontology Mapping) qui garde la trace de l origine des éléments du modèle Mo dans MMa. Figure 9. Tissage entre le modèle du domaine (MMa) et le modèle d'ontologie (Mo). Figure 10. Passage du modèle Ma vers sa représentation en OWL. Les transformations utilisées ici sont respectivement notées Mht et Mt, elles sont définies par les fonctions : Mht : MMt( MMa : MOF, Mwmo : MOM, Mo : OWL ) Mt : MMt Mt : MMt( Ma : MMa ) Mi : OWL. La transformation Mt permet le passage du modèle Ma conforme au métamodèle MMa vers le modèle Mi conforme à OWL. Le modèle Mi contient les individus devant peupler la base de connaissance. Un individu correspond en OWL aux instances de classes dans le formalisme objet. Chaque individu est typé par une (ou plusieurs) classe(s) de l ontologie représentée par le modèle Mo. L ontologie et les instances sont représentées dans deux modèles distincts, tous deux conformes au métamodèle OWL. Il est à noter que le modèle Mi référence le modèle Mo notamment pour lier les individus à leurs types respectifs. La base de connaissance est construite en utilisant un projecteur prenant en entrée les modèles Mo et Mi et produisant en sortie les documents XML en accord

14 IDM' juin Mulhouse avec la syntaxe du langage OWL. Un extrait est donné ci-après montrant la représentation RDF/XML de deux individus de l ontologie. <Painter rdf:id = 'Individual_4'> <firstname rdf:datatype = '&string'>pablo</firstname> <lastname rdf:datatype = '&string'>picasso</lastname> <paints rdf:resource = '#Individual_20'/> </Painter> <Painting rdf:id = 'Individual_20'> <artname rdf:datatype = '&string'>guernica</artname> <date rdf:datatype = '&string'>1937</date> <haspainter rdf:resource = '#Individual_4'/> </Painting> Nous venons de montrer comment - à partir d un métamodèle annoté et d un modèle conforme à ce métamodèle - nous produisions une base de connaissances constituée à la fois d une ontologie et d un ensemble de données représenté par des individus. Cette approche peut être appliquée dès lors que l on souhaite partager un ensemble de données notamment avec des applications reposant sur les principes du Web sémantique. L utilisation de transformations d ordre supérieur et de modèles de tissage, nous permet d assurer la validité des modèles produits et de réduire la complexité inhérente à la migration de données. 6. Conclusion Nous présentons une approche fondée sur l ingénierie des modèles qui permet de créer une vue ontologique sur des données relationnelles. À partir d un modèle de tissage entre un modèle métier et une ontologie, nous définissons un ensemble de transformations établissant une traçabilité complète entre une base de données et une base de connaissance. Nous montrons que l ingénierie des modèles permet de faire le lien entre les différents espaces technologiques avec lesquels nous devons opérer : modèle relationnel, modèle du domaine et ontologie. L utilisation d une transformation d ordre supérieur permet de générer directement des transformations correctes. On offre ainsi un cadre applicatif général pouvant s adapter à tout schéma de données à condition que les correspondances entre schéma et modèle de domaine aient été formalisées préalablement dans un modèle de tissage. Cette approche garantit une certaine forme de qualité à l ensemble. Les métamodèles spécifiés en entrée et en sortie assurent, dans les différents cas concrets traités, la cohérence du modèle du domaine et de ses annotations et les transformations ad hoc sont ensuite générées automatiquement par des transformations d ordre supérieur exploitant les modèles de tissage. Bien que l exemple présenté ici concerne des données provenant d un SGBD relationnel, notre approche peut aisément être adaptée à d autres sources de données : données semi-structurées, objets ou fichiers. Cette adaptation consiste à

15 IDM pour la création de bases de connaissance ontologiques développer des projecteurs spécifiques permettant de passer de l espace technologique des données à celui des modèles. Notre travail offre plusieurs perspectives que nous souhaitons développer. La première consiste à tester notre approche en changeant d échelle pour traiter des bases de données réelles de taille importante. La seconde concerne le traitement des requêtes sur la base de connaissance. Le peuplement de la base de connaissance à partir d objets du domaine peut néanmoins poser des problèmes de gestion de cohérence entre les deux bases (données et connaissance). Pour la mise à jour des données, nous préconisons de n opérer qu au travers du SGBD, ce qui garantit l intégrité du système contrairement à l accès direct sur la base de connaissance qui offre peu de contrôle. De plus pour éviter ces problèmes de cohérences, nous envisageons de ne pas construire explicitement la base de connaissances, mais de réaliser une traduction à la volée des requêtes SPARQL [Prud hommeaux 04] vers SQL (ou XQuery [Chamberlin 03]). Ce dernier objectif est facilité par l utilisation du modèle de domaine comme modèle pivot pour la traduction envisagée. Pour conclure, nous souhaitons souligner que la qualité du processus de construction de la vue ontologique repose principalement sur la génération automatique de transformations. Ceci permet au concepteur de se concentrer sur la définition des liens entre les différents modèles (modèles de tissage), tâche difficilement automatisable, plutôt que sur l écriture de transformations dont nous montrons qu elles peuvent être générées automatiquement à partir des différents modèles de tissage. 7. Bibliographie Ambler S., «Mapping objects to relational databases: O/R mapping in detail», URL Baader F., The Description Logic Handbook: theory, implementation, and applications: Cambridge University Press, Berners-Lee, T., Hendler, J., Lassila, O., «The semantic Web», Scientific American 284 (2001) Bézivin, J. and Jouault, F. and Valduriez, P., «On the Need for Megamodels», In OOPSLA Workshop on Best Practices for Model-Driven Software Development, Vancouver, Canada, Bizer C., Cyganiak R., «D2R Server-Publishing Relational Databases on the Semantic Web», Poster at the 5th International Semantic Web Conference, Athens, USA, November, Brockmans S., Colomb R. M., Kendall E. F., Wallace E. K., Welty C., Xie G. T., «A Model Driven Approach for Building OWL DL and OWL Full Ontologies», 5th International Semantic Web Conference (ISWC2006), pp , 2006.

16 IDM' juin Mulhouse Chamberlin D., «XQuery: a query language for XML», Proceedings of the 2003 ACM SIGMOD international conference on Management of data, pp , Chen H., Wang Y., Wang H., Mao Y., Tang J., Zhou C., Yin A., Wu Z., «Towards a Semantic Web of Relational Databases: a Practical Semantic Toolkit and an In-Use Case from Traditional Chinese Medicine», Proceedings of the 5th International Semantic Web Conference, pp. 5-9, De Laborda C. P., Conrad S., «Bringing Relational Data into the SemanticWeb using SPARQL and Relational. OWL» Didonet Del Fabro M., Bézivin J., Jouault F., Breton E., Gueltas G., «AMW: A generic model weaver», Proc. of the 1ères Journées sur l'ingénierie Dirigée par les Modèles, Djuric D., Gasevic D., Devedzic V., «Ontology Modeling and MDA», Journal of Object Technology, vol. 4, pp , Djuric, D. and Gasevic, D. and Devedzic, V., «The Tao of Modeling Spaces», Journal of Object Technology, vol 5 (8), 2006, pp Fowler M., Patterns of Enterprise Application Architecture, Addison Wesley 512p ISBN Jouault F., Kurtev I., «Transforming Models with ATL», in Model Transformations in Practice Workshop at MoDELS Montego Bay, Jamaica, 2005, pp Jouault, F., Bézivin, J., Kurtev, I.: «TCS: a DSL for the specification of textual concrete syntaxes in model engineering». Proceedings of the 5th international conference on Generative programming and component engineering, Portland, Oregon, USA, 2006, pp McGuinness, D.L., van Harmelen, F., et al., «OWL Web Ontology Language Overview», W3C Recommendation 10 (2004) OMG, The Common Warehouse Model 1.1., OMG Document: formal/ OMG. XML Metadata Interchange (XMI) specification v 2.1.1, December 2007, OMG. Object Constraint Language (OCL) v 2.0, May OMG. Meta Object Facility (MOF) Core Specification, January OMG. Ontology Definition Metamodel OMG Adopted Specification, November Prud hommeaux E. and Seaborne A., «SPARQL Query Language for RDF. W3C Working Draft», World Wide Web Consortium (W3C), Shvaiko P., Euzenat J., «A Survey of Schema-Based Matching Approaches», Journal on Data Semantics IV, Wache H., Vögele T., Visser U., Stuckenschmidt H., Schuster G., Neumann H., and Hübner S., «Ontology-based integration of information-a survey of existing approaches», IJCAI- 01 Workshop: Ontologies and Information Sharing, vol. 2001, pp , 2001.