Approche de couplage de BD et d ontologie pour l aide à la décision sémantique : contribution pour la satisfaction des requêtes SQL et SPARQL.

Transcription

1 Approche de couplage de BD et d ontologie pour l aide à la décision sémantique : contribution pour la satisfaction des requêtes SQL et SPARQL. Mariem Mahfoudh 1, Wassim Jaziri 2 1. Laboratoire MIPS, EA Université de Haute-Alsace (UHA), 12 rue des frères Lumière, Mulhouse Cedex, France. mariem.mahfoudh@uha.fr 2. College of Computer Science and Engineering, Taibah University, P.O Box 344, Postal Code: 41411, Madinah, KSA. jaziri.wassim@gmail.com RÉSUMÉ. La modélisation des systèmes d informations et l interrogation de leurs données présentent de plus en plus un défi primordial qui ne cesse de s imposer. Les solutions proposées dans la littérature étaient principalement organisées autour des bases de données (BD), des entrepôts de données et plus récemment, des ontologies. Cette multitude de formalismes a entraîné la nécessité d étudier le couplage entre les différents supports de stockage et d interrogation de l information. Cet article s intéresse à étudier le couplage entre BD et ontologie recouvrant le même domaine d étude, pour la satisfaction des requêtes utilisateurs. L'approche proposée se base sur un ensemble de règles définies et dédiées pour la recherche de l'information pertinente permettant de satisfaire les requêtes SQL et SPARQL. Un outil de couplage est également développé pour implémenter et valider nos propositions. ABSTRACT. The modeling of information systems and the extraction of their data present an important challenge. The proposed solutions in the literature were mainly organized around databases, data warehouse and more recently the ontologies. This multitude of formalisms requires studying the coupling between the different formalisms of information storage and query. This paper studies the coupling between DB and ontology covering the same domain, to satisfy users' queries. The developed approach is based on a set of defined rules for finding relevant information to satisfy SQL and SPARQL queries. A tool is also developed to implement and validate our proposals. MOTS-CLES : Couplage, Base de données, Ontologie, Reformulation de requêtes, SQL, SPARQL. KEYWORDS: Coupling, Database, Ontology, Query reformulation, SQL, SPARQL. DOI: /tsi Lavoisier Techniques et sciences informatiques

2 2 TSI Introduction Les ontologies, comme les Bases de Données (BDs), conceptualisent l univers du discours au moyen de classes (concepts) reliées par des relations et associées à des propriétés. Elles sont le résultat d une modélisation plus ou moins abstraite présentant et reflétant la structure et les contraintes d un domaine d étude. Malgré leurs points communs, les ontologies et les bases de données présentent diverses différences. Les ontologies sont considérées comme des modèles de haut niveau qui permettent de décrire les concepts d un problème donné d un point de vue assez général. Alors que les BDs sont construites pour représenter l information d un système pour faire face à un besoin applicatif donné. En effet, les BDs et les ontologies sont fondées sur des hypothèses différentes : les BDs sont construites sur la base de l'hypothèse du monde fermé à la différence des ontologies qui sont fondées sur l'hypothèse du monde ouvert (Guarino, 1998). D ailleurs, dans une BD, chaque concept est référencé par la notion d identifiant qui ne prend sens qu au sein du système informatique dans lequel l application est réalisée, tandis que dans une ontologie, chaque composant possède un identifiant universel (comme l URI : Uniform Resource Identifier) permettant de le référencer à partir de n importe quel environnement, indépendamment de l ontologie dans laquelle il a été défini. La BD et l ontologie possèdent toutes les deux leurs propres avantages et inconvénients. Les BDs se distinguent par leur : 1) évolutivité, leur évolution ne cause pas des inconsistances ; 2) efficacité de stockage grâce à la non-redondance des données représentées ; 3) structuration idéale permettant un temps optimal d exécution des requêtes utilisateurs ; 4) gestion des droits d accès, les BDs offrent des mécanismes de contrôle et de sécurité. L ontologie est : 1) consensuelle, décrit les concepts d un domaine d étude de manière à permettre de satisfaire les besoins techniques et métiers partagés par une communauté d'utilisateurs ; 2) référençable, les composantes de l ontologie possèdent des identifiants universels permettant de les référencer à partir de n importe quel environnement ; 3) expressive 1, formelle et fournit une contribution essentielle au défi de l'intégration des données hétérogènes. Nous pensons que l utilisation simultanée de ces deux supports d'information procure d une part une structuration forte des données et une capacité de stockage importante (la BD) et d'autre part une sémantique explicite et universelle (l ontologie). Dans ce travail, nous nous basons sur cette complémentarité pour proposer une démarche permettant de faire cohabiter les BDs et les ontologies avec leurs avantages et inconvénients propres. Notre travail se positionne dans un cadre d aide à la décision sémantique. Suite à une requête utilisateur, on voudrait que le système soit en mesure de fournir une réponse sémantiquement satisfaisante. Les requêtes peuvent êtres de différents types (simples, sémantiques ou bien mixtes) ce qui nécessite la présence de la BD et de l ontologie à la fois. 1. Bien entendu, le niveau d expressivité dépend du type d ontologie (cf. ontologie «légère» vs «lourde») et du langage de représentation sous-jacent.

3 Approche de couplage de BD et d ontologie 3 Cet article est organisé comme suit. La section 2 passe en revue le couplage entre BDs et ontologies. Les sections 3 et 4 présentent notre démarche de couplage basée sur un processus de satisfaction de requêtes utilisateur suivant leur contenu. Les sections 5 et 6 sont dédiées au mécanisme de traitement des requêtes SQL et SPARQL. La section 7 présente la partie implémentation au travers de l'outil CoDBOnto. Enfin, une conclusion synthétise la proposition de l article et trace les perspectives envisagées. 2. Etat de la question Dans le but d expliciter les connaissances relatives à un domaine donné, plusieurs travaux ont étudié le couplage entre des bases de données et des ontologies. Ces travaux ont suivi différentes orientations : 1. Suivre une approche BD classique puis dériver vers des spécifications sémantiques conduisant à la construction d une ontologie ; 2. Entamer une approche ontologique aboutissant à la construction d une ontologie qui servira par la suite à concevoir la BD ; 3. Disposer de la BD et de l ontologie puis définir un lien de correspondance (mapping) entre elles Construction d ontologies à partir des BDs Plusieurs travaux se sont intéressés à la construction d une ontologie à partir d une BD dans le but d exprimer la sémantique, insuffisamment (implicitement) traitée par les BDs. Le recours aux ontologies est justifié principalement par la capacité de ces dernières de faire face aux problèmes d hétérogénéité et d intégration de données. (Nyulas et al., 2007) ont proposé une méthode d importation d une Base de Données Relationnelle (BDR) dans une ontologie. L approche est validée par le développement du DataMaster : un plug-in de Protégé 2 qui peut supporter comme entrée n importe quel type de BD et peut générer en sortie une ontologie OWL ou une ontologie frame. Cependant, DataMaster n'est pas paramétrable. Il ne permet pas, par exemple, des traitements spécifiques à certaines tables ou bien le choix de conventions sur le nommage des concepts extraits. (Cerbah, 2008) propose l outil RDBToOnto dédié à la conversion des BDs en ontologies. Cet outil implémente une approche d'apprentissage automatique qui peut être progressivement affinée par l'utilisateur. Ce dernier peut choisir le convertisseur approprié (parmi ceux prédéfinis) pour l'implémentation de la transformation, ou le recours à une nouvelle méthode. RDBToOnto est un outil assez riche et assure une interaction importante avec l utilisateur. Cependant, comme la plupart des outils proposés dans la littérature, il ne permet pas de traiter les problèmes d héritage. 2. protege.stanford.edu

4 4 TSI 2013 (Lubyte et Tessaris, 2009) ont proposé un framework pour l extraction d une ontologie à partir d une BDR. Pour représenter le modèle conceptuel extrait, l approche utilise un langage d ontologie expressif DLR-Lite : une variante de la description logique capable de capturer la sémantique du schéma ER et des diagrammes de classes d UML. Cette approche a l avantage de traiter certains axiomes. Par ailleurs, elle exige que les relations du schéma relationnel soient en troisième forme normale (3NF) pour pouvoir prouver formellement que le modèle extrait est fidèle au modèle initial. L approche garantit la non perte des données et la préservation des contraintes. Cependant la transformation ne respecte pas les caractéristiques de l ontologie et le résultat est plus proche d'un schéma relationnel exprimé en langage d ontologie qu une vraie ontologie. (Kamel et Aussenac-Gilles, 2009) présentent une approche de construction automatique d ontologie à partir d un document de spécification de BD au format XML. Cette approche vise à exploiter la sémantique véhiculée par les balises. Ainsi, le processus de construction commence par l analyse des balises du document dans le but d identifier les concepts, les relations conceptuelles et les propriétés. Ces composants servent pour la création du noyau de l ontologie qui sera enfin enrichi à l aide de patrons lexico-syntaxiques. Cette approche apparaît différente par rapport aux précédentes puisque la BD est au format XML. L ontologie résultante s avère riche en concepts et relations, puisque basée sur des techniques de traitement automatique des langages naturels. Toutefois, elle souffre de certaines limites dans le sens où l'ontologie résultat peut contenir des incohérences qui ne peuvent être corrigées que manuellement. En plus, l'ontologie résultante est très dépendante de la structure du fichier XML d'entrée puisque les règles de transformation se basent essentiellement sur la hiérarchisation de ce fichier. (Farouk et Ishizuka, 2012) proposent de transformer une BD en un fichier RDF 3 (Resource Description Framework) pour l exploiter dans le domaine du Web Sémantique. En effet, plusieurs travaux ont été présentés dans ce cadre, comme par exemple ceux de (Bizer, 2003), (Laborda et Conrad, 2006), (An et al., 2006) et (Tirmizi et al., 2008). Leur objectif était principalement d obtenir un fichier RDF ou bien OWL qu ils pourront interroger par les langages d interrogation du web sémantique à l instar de SPARQL 4, RQL 5 et ontoql (Jean et al., 2006). Par contre, l utilisation de ces fichiers ne pourra être vraiment de grande utilité que s ils contiennent de la connaissance. Un tel avantage ne peut pas être obtenu par une transformation automatique de la BD. Afin de remédier à ce problème, (Farouk et Ishizuka, 2012) ont proposé de suivre une approche semi-automatique composée de deux étapes. La première consiste à transformer automatiquement la BD en document RDF alors que la deuxième permet d ajouter manuellement par l utilisateur des connaissances et des règles d inférence. (Gherabi et Bahaj, 2012) proposent une méthode de transformation d un diagramme de classes UML à une ontologie OWL. Cette méthode consiste en trois athena.ics.forth.gr:9090/rdf/rql

5 Approche de couplage de BD et d ontologie 5 étapes. La première se charge à présenter le diagramme de classes en une formulation mathématique. La seconde consiste à convertir le diagramme en un fichier texte représentant sa structure. Enfin, et en se basant sur le résultat de ces deux étapes, le diagramme de classes est converti en une ontologie OWL. Les règles de transformation sont assez simples, comme par exemple, tout attribut doit être transformé en DataProperty et toute relation est transformée en ObjectProperty. Ce travail, suppose que la transformation d une BD en fichier OWL garantit d avoir une ontologie, ce qui est loin d être vrai car cela dépend des connaissances véhiculées et conceptualisées dans le modèle conceptuel défini dans OWL. Différentes approches et outils traitant la construction (ou l extraction) de l ontologie à partir de la BD ont été proposés. Les approches sont variées et se placent, soit au niveau conceptuel avec un intérêt centré sur la couche conceptuelle/logique, essentiellement le modèle relationnel (Cerbah, 2008), (Trinkunas et al., 2007), soit à un niveau plus bas pour chercher des correspondances au niveau physique, par exemple, au niveau des langages de définition/représentation et de manipulation des BDs (SQL) et des ontologies OWL (Cullot et al., 2007), des ontologies DLR_Lite (Lubyte et al., 2007), frame (Nyulas et al., 2007) et RDF (Sahoo et al., 2009). Cependant, malgré cette variété, les règles utilisées se ressemblent et se basent souvent sur une extraction «plate» : la structure de l ontologie obtenue reste très proche du schéma de la BD. Par exemple, les structures hiérarchiques extraites sont peu profondes alors que l ontologie se distingue par sa structure hiérarchique (Krivine et al., 2009). On peut noter également que la plupart des outils développés peuvent être vus comme une aide à la construction d ontologies, d'autant plus que le résultat doit s intégrer dans une ontologie déjà existante avec des principes de modélisation et de structuration particuliers (ex : utilisation d une ontologie fondatrice comme BFO 6 : Basic Formal Ontology ou DOLCE 7 : Descriptive Ontology for Linguistic and Cognitive Engineering) Construction de BD à partir d'ontologie Grâce à la sémantique offerte par les ontologies et leur capacité de résolution des problèmes d intégration, plusieurs concepteurs s en servent, entre autres, dans la modélisation de leurs systèmes d informations. Cependant, à cause de l évolution continue de ces derniers, les données stockées atteignent rapidement des tailles qui deviennent incompatibles avec le traitement en mémoire centrale. (Sugumaran et Storey, 2006) ont proposé un outil nommé OMDDE (Ontology Management and Database Design Environment) d aide à la conception des Modèles Conceptuels de Données (MCD) à partir d ontologies de domaine. Il s agit d une approche linguistique dans laquelle le système analyse les termes du cahier des charges de l application et, par référence à l ontologie, suggère différents

6 6 TSI 2013 éléments à introduire dans le MCD. La méthode ne garde pas le lien entre les concepts et relations de l ontologie et le MCD défini, i.e., ne permet pas l accès à la BD résultante via l ontologie et ne facilite ni l échange ni l accès aux données. (Vysniauskas et Nemuraite, 2006) ont proposé une méthode de transformation d une ontologie OWL en un schéma relationnel, inspirée de la méthode «OWL2BD» de (Gali et al., 2004). Le processus de transformation est initialisé par le concepteur qui est chargé d introduire l ontologie. Après la vérification de la syntaxe OWL de l ontologie, la méthode proposée se base sur des algorithmes de transformation de chaque entité de l ontologie. (Astrova et al., 2007) ont proposé une approche pour la transformation automatique d'ontologie OWL en une BDR exprimée en SQL. Cette approche est implémentée dans un utilitaire QUALEG DB et se distingue des autres approches par sa capacité de traitement des axiomes et des restrictions, ainsi que la définition des règles de mapping pour les différentes catégories des objectproperty et des dataproperty (à valeurs uniques, à valeurs multiples). Toutefois, cette approche ne gère pas convenablement les namespace supportés par OWL et non supportés par SQL. (Fankam et al., 2009) ont proposé une approche nommée SISRO (Spécialisation des classes, Importation Sélective des propriétés et Représentation des Ontologies) permettant au concepteur de réutiliser la connaissance du domaine formalisée dans l ontologie. Cette approche comporte quatre étapes essentielles : 1) création d'une ontologie locale à partir d'ontologies de domaine ; 2) construction du modèle conceptuel à partir du sous ensemble canonique de l ontologie locale ; 3) définition des modèles logique et physique ; 4) fourniture d accès au niveau ontologique. La méthode SISRO est supportée par un ensemble d outils permettant de mettre en œuvre les différentes étapes. Ainsi, PLIBEditor permet de créer l ontologie locale. OntoDB (Dehainsala et al., 2007), système de gestion de base de données à base ontologique (BDBO), permet la génération de la BD et son exploitation par le langage de requêtes OntoQL. Une BDBO est définie dans (Dehainsala et al., 2007) comme «une source de données qui contient : une ontologie (locale), éventuellement, des références de l ontologie locale à des ontologies (partagées) externes, un ensemble de données et un lien entre chaque donnée et la notion ontologique qui en définit le sens». La méthode SISRO possède plusieurs avantages. Elle permet, d une part, au concepteur d importer d une façon sélective les concepts et les propriétés qu il juge pertinents et permet, d autre part, d éviter les conflits liés à l approche classique ANSI/SPARC 8 de conception de BD en se basant sur différentes ontologies partagées. Cependant, elle nécessite un travail exhaustif de la part du concepteur. Bien que la construction d une BD à partir d une ontologie présente un axe de recherche prometteur, les approches proposées présentent certaines limites : 8. ANSI/SPARC est l architecture fondamentale sur laquelle reposent les SGBD modernes.

7 Approche de couplage de BD et d ontologie 7 elles sont implémentées sous forme de prototypes de recherche qui souffrent souvent du manque de documentation et des tests prouvant leurs fonctionnalités ; elles ne fournissent pas de moyen de vérification et d analyse des pertes de la structure résultant du mapping, essentiellement l héritage. En fait, les ontologies se distinguent par leur structure hiérarchique souvent assez profonde. Une transformation automatique d une ontologie en une BD pourra ne pas prendre en compte toutes les relations d héritage et produira ainsi une perte de structure ; elles supposent que toutes les constructions d'une ontologie peuvent être mappées vers une BDR. L expérience du projet NeuroLOG 9 a montré qu en voulant mettre toute la sémantique de l ontologie dans un modèle relationnel (notamment les liens de subsomption multiples), on obtenait un modèle relationnel incompréhensible Travaux traitant le mapping entre ontologie et BD Traiter le mapping entre une ontologie et une BD consiste à disposer de ces deux composantes et à définir un lien de correspondance entre elles. Le résultat de mapping est utilisé, généralement, pour remédier aux problèmes d intégration et d interrogation des données 10. Cette orientation présente une voie prometteuse puisqu elle exploite les BDs et les ontologies avec leurs propres avantages et inconvénients. Cependant, les travaux qui s inscrivent dans cette orientation restent assez rares. (Rodriguez et Gómez Pérez, 2006) ont présenté un langage déclaratif R2O permettant de spécifier des correspondances entre une ontologie, décrite en RDFS 11 (Resource Description Framework Schema) ou en OWL, et une BD SQL. L'approche proposée consiste à créer un document de description du mapping avec toutes les correspondances entre les éléments du schéma de la BD et ceux de l'ontologie. Afin d exploiter le contenu du document R2O à des fins utiles, comme par exemple, la réponse aux requêtes utilisateurs, l invention de R2O a été accompagnée avec celle du processeur ODEMapster. Cependant, R2O ne définit pas des degrés de similitude entre les composants de la BD et de l ontologie, ce qui rend le jugement sur l existence de liens entre elles est très rigide. (Hu et Qu, 2007) ont proposé un processus de mapping entre un schéma relationnel et une ontologie, se déroulant en 4 phases : 1) réaliser une classification heuristique des entités du schéma relationnel et de celles de l ontologie dans le but de faciliter la recherche de candidats de correspondance ; 2) construire pour chaque entité candidate son propre «document virtuel» : une collection de pondérations dérivées non seulement de la description de l'entité elle-même, mais aussi des descriptions de ses voisines (Salton et McGill, 1983) ; 3) vérifier et valider la consistance du mapping ; 4) alimenter les correspondances découvertes par des 9. neurolog.polytech.unice.fr 10. L ontologie peut constituer une documentation aidant à gérer un modèle relationnel

8 8 TSI 2013 instances afin d être utilisées par un mapping sémantique connu sous le nom de «contextual mapping» (Bohannon et al., 2006). L algorithme de mapping est implémenté à l'aide de l'outil MARSON (MApping between Relational Schema and ONtologie). Cette approche possède deux limites : 1) la qualité du mapping est étroitement liée au choix du seuil de confiance ; 2) l incapacité de détecter des relations autres que l équivalence et l héritage, ce qui restreint le champ d application du mapping résultant. 3. Approche de couplage BD-Ontologie L étude des travaux de la littérature permet de constater que les approches proposées souffrent de certaines limites. Par exemple, la transformation d une ontologie en une BD conduit à des problèmes de redondance et d incohérence qui sont contradictoires avec les principes de base d une BD. La construction d une ontologie à partir d une BD amène à une ontologie contenant peu de concepts, de relations sémantiques et de hiérarchisations (ceci dépend tout de même de la complexité du schéma de la BD). Ces problèmes sont le résultat de la négligence des spécificités des ontologies et des BDs : certaines approches supposent que toutes les constructions d'une ontologie peuvent être mappées à une BD et inversement, ce qui est loin d être vrai puisque chacune a ses propres caractéristiques. Une voie prometteuse consiste donc à exploiter les potentialités des BDs et des ontologies via un couplage permettant de garder leurs avantages propres. Dans notre travail, nous supposons que la BD et l ontologie sont déjà construites et sont cohérentes 12 l une vis-à-vis de l autre (conceptuellement et sémantiquement) et qu elles modélisent le même domaine d étude. Nous exigeons également que la BD contienne toutes les instances afin de profiter de sa capacité de stockage et de sa puissance de gestion des données alors que l ontologie représente la sémantique du domaine d étude grâce à la structuration de ses entités ontologiques et ne contient aucun individu. Toutefois, l'existence d'instances dans l'ontologie (i.e. le cas des ontologies OWL qui peuvent avoir des instances au niveau d ABox) ne remet pas en cause notre approche. En effet, ceci nous semble nécessaire pour mieux exploiter les avantages de ces deux composants (puisque le stockage des instances est mieux supporté par les BDs et n'est pas une caractéristique essentielle des ontologies) Types de requêtes Notre approche consiste à exploiter l ontologie et la BD afin de satisfaire les besoins des utilisateurs. Si on se positionne dans un cadre d aide à la décision sémantique, suite à une requête utilisateur, le système doit être en mesure de fournir une réponse sémantiquement satisfaisante (cohérente) soit en interrogeant la BD ou bien l ontologie, ou en liant les deux composants. A cet effet, nous distinguons trois 12. Cette hypothèse de cohérence permet de travailler dans un environnement consistant garantissant que les réponses aux requêtes utilisateur soient sémantiquement satisfaisantes.

9 Approche de couplage de BD et d ontologie 9 catégories de requêtes auxquelles on se propose d'apporter des réponses adéquates en consultant les sources d information (la BD et/ou l ontologie). Requête simple : comporte des informations directement explicitées dans la BD. Ce type de requête ne nécessite aucun traitement au niveau sémantique et une BD saura y répondre facilement du moment que la requête est conforme au langage de manipulation de données qu elle supporte. Requête sémantique : comporte des interrogations nécessitant de déduire des connaissances (en ayant recours éventuellement à un raisonneur). Ce type de requête peut être satisfait directement en interrogeant l ontologie. Ceci sous-entend que la requête comporte tous les éléments nécessaires (d entrée) pour déduire la réponse. Requête mixte : demande à la fois l accès à la BD et à l ontologie. Ceci nécessite, par exemple, de faire appel à la sémantique (raisonner au niveau de l'ontologie) pour enrichir ou reformuler des requêtes avant de les lancer sur la BD et extraire ainsi les instances souhaitées, ou bien d exploiter la BD puis d'aller chercher la réponse dans l ontologie. Par exemple, on peut tomber sur des requêtes qui nécessitent de déduire des connaissances mais qui ne comportent pas les éléments (attributs, concepts, ) nécessaires à cette déduction. Il convient, dans ce cas, d accéder à la BD, éventuellement après une reformulation 13 de la requête, pour en extraire les informations nécessaires. Ces dernières serviront comme paramètres de la requête qui sera envoyée à l ontologie pour pouvoir enfin répondre à la requête initiale. Ce type de requête nécessite donc un traitement supplémentaire (la reformulation) pour adapter le contenu au système mis en place Processus de satisfaction de requêtes Le processus de satisfaction est initialisé par l utilisateur qui se charge d introduire une ontologie et une BD et de saisir les requêtes relatives à ses besoins. Dans notre travail, nous exigeons que les requêtes soient exprimées par des langages formels et non en langage naturel. Le système se charge alors de déterminer le type de la requête saisie ainsi que sa réponse en exécutant un ensemble de règles définies 14 à cette fin. Dans le cas où les règles ne permettent pas de trouver une réponse à la requête, on peut faire recours à l assistance d un expert qui peut, soit reformuler la requête, soit charger un référentiel sémantique (nous pouvons citer comme référentiel sémantique les thésaurus, les ontologies linguistiques ou d autres ontologies de domaine) qui sera exploité pour la recherche de la réponse pertinente. Dans notre approche, nous pensons également à la journalisation des requêtes pour assurer un mécanisme d'apprentissage permettant un gain en temps et de 13. La technique de reformulation de la requête a été proposée afin de limiter l impact du mauvais choix des termes et elle consiste à modifier les éléments de la requête jusqu à la satisfaction du besoin d information de l utilisateur. 14. Ces règles ne seront pas toutes présentées dans cet article pour des raisons de simplification.

10 10 TSI 2013 ressources. De ce fait, nous enregistrons les requêtes erronées ainsi que les requêtes équivalentes reformulées pour les utiliser en cas de besoin. 4. Description de l'approche L'approche que nous proposons (voir Figure 1) passe par trois étapes essentielles : (1) analyse de la BD et de l'ontologie pour créer un fichier enregistrant leurs correspondances ; (2) analyse des requêtes utilisateurs pour déterminer la source et le rôle de chaque terme constituant les requêtes; (3) traitement de la requête et communication du résultat adéquat à l'utilisateur. Figure 1. Approche de couplage entre base de données et ontologies Analyse de la BD et de l'ontologie L analyse de la BD et de l ontologie est une étape importante aidant à connaître la source de la réponse à la requête utilisateur. Elle consiste tout d abord, à extraire les différents éléments constituant le schéma de la BD (récupérer la liste des tables, la liste des colonnes, etc.) et de l'ontologie (extraire les concepts, les relations, etc.). Ces éléments seront sauvegardés séparément pour servir par la suite dans la recherche de la source des termes constituant les requêtes utilisateurs et connaître exactement leur rôle (un concept, une propriété, etc.). Ensuite, un fichier de correspondance est créé entre ces deux sources d informations pour mettre en évidence leurs éléments communs 15 que nous devons détecter et extraire. Le fichier de correspondance est exploité pour satisfaire les requêtes utilisateurs et pour 15. Du point de vue des termes et non de la structure, étant donné que ces deux composantes ont des structures différentes.

11 Approche de couplage de BD et d ontologie 11 l optimisation du temps de recherche de l information pertinente. Ce fichier, comme le présente la Figure 2 est un fichier XML qui renferme : les termes appartenant à la fois à la BD et à l ontologie (point de vue syntaxique) et leur rôle dans ces deux sources d informations ; les correspondances sémantiques entre les termes de la BD et de l ontologie : il s agit de détecter le lien sémantique entre les termes et concepts, en se basant sur les connaissances véhiculées par l ontologie et sur des référentiels sémantiques que nous exploitons pour chercher des relations de synonymie 16 (entre termes), de méronymie 17, et de subsomption 18 (entre concepts). Notant que pour cette dernière relation, nous étendons la recherche aux synonymes et aux descendants des termes fils. Figure 2. Structure générale du fichier de correspondance entre une BD et une ontologie. 16. La synonymie est une relation sémantique reliant deux termes différents qui peuvent exprimer le même sens. 17. La relation de méronymie est la relation partie/tout. 18. La subsomption désigne une relation hiérarchique entre des concepts.

12 12 TSI Analyse de la requête utilisateur Comme nous l avons déjà évoqué, l utilisateur est invité à formuler ses requêtes en utilisant des langages formels pouvant être des langages de requête de BD ou bien des langages sémantiques. Ces requêtes doivent être analysées afin de déterminer leur type (simple, sémantique ou bien mixte) et procéder à l interrogation de la BD et/ou l ontologie pour les satisfaire. Cette analyse se déroule en trois phases assurant chacune un objectif bien déterminé : Première phase permet de distinguer entre les mots réservés/clés (from, select, where, ) du langage formel utilisé et ceux introduits par l utilisateur reflétant ses besoins réels (les données ou connaissances qu il voulait extraire de la BD et/ou de l ontologie). Cette phase se base sur des analyseurs lexico-syntaxiques correspondant aux langages choisis ; Deuxième phase, après la séparation entre les mots réservés et ceux reflétant l objectif de la recherche, il convient de déterminer la source de chacun de ces termes (BD, ontologie) ; Troisième phase détermine le rôle que les termes de la requête occupent aussi bien dans la requête que dans les sources de données : tables (concepts), relations, tuples (instances), colonnes (propriétés), etc. Le résultat de ces différentes phases sert comme input pour la troisième étape de notre approche à propos du traitement des requêtes utilisateur Traitement des requêtes utilisateurs Cette étape s'intéresse au chargement des règles adéquates pour préciser le type de requêtes (simple, sémantique, mixte) et le traitement nécessaire pour leur satisfaction qui est fortement lié à la nature de la requête. En effet, dans notre travail, nous traitons les requêtes de nature suivantes : Requête vide : requête bien formulée mais ayant comme résultat un ensemble vide d enregistrements. Autrement dit, aucune donnée de la BD ou de l ontologie ne correspond aux conditions spécifiées dans la requête. Requête invalide : toute requête non conforme au langage d expression. Il s agit des requêtes incorrectes qui souffrent des problèmes syntaxiques ou structurels. Exemple, le cas d une requête SQL qui demande d afficher le contenu d une colonne sans préciser dans la partie ItemsFrom la table en question. Requête inadaptée : une requête mal formulée contenant des termes inadaptés ou erronés. Ces derniers doivent être remplacés par d autres termes équivalents permettant de constituer une requête exécutable dans la BD ou dans l ontologie. - Terme inadapté : terme appartenant à la BD et/ou à l ontologie mais sa présence empêche l exécution de la requête, i.e., un terme de l ontologie qui se présente dans une requête qui va être exécutée sur la BD. Ce terme doit donc être reformulé par un autre terme équivalent qui fait partie de la BD.

13 Approche de couplage de BD et d ontologie 13 - Terme erroné : tout terme ne faisant partie ni de la BD ni de l ontologie. Requête erronée : une requête qui ne peut être corrigée par aucune règle de l approche proposée. Après l'analyse faite sur la BD, l ontologie et la requête utilisateur, nous distinguons, en fonction des termes de la requête saisie, quatre cas : 1. les termes constituant la requête utilisateur appartiennent tous à la BD ; 2. les termes constituant la requête appartiennent tous à l ontologie ; 3. les termes constituant la requête appartiennent simultanément à l ontologie et à la BD ; 4. il existe au moins un terme dans la requête qui n appartient ni à la BD ni à l ontologie. Nous adoptons pour chacun de ces cas, des stratégies différentes de satisfaction de requêtes utilisateur selon l'algorithme suivant : Algorithme 1. Stratégies adoptées pour le traitement des requêtes utilisateur. 1: Entrées : BD, ontologie, fichier de correspondance entre BD et ontologie, requête utilisateur, résultat de l analyse de la requête utilisateur 2: Début : 3: si la requête est constituée de termes appartenant tous à la BD alors 4: si elle n est pas exprimée à l'aide d un langage capable d interroger la BD alors 5: elle doit être reformulée en langage d'interrogation approprié 6: sinon 7: si la requête est valide alors 8: elle est de type simple (quel que soit qu elle admet une réponse ou qu elle est une requête vide) 9: sinon le système doit reformuler la requête en se basant seulement sur le contenu de la BD 10: si la requête est devenue valide alors 11: la requête est de type simple 12: sinon la requête est considérée comme erronée 13: fin condition 14: fin condition 15: fin condition 16: fin condition 17: si la requête est constituée des termes appartenant tous à l ontologie alors 18: si la requête est exprimée à l'aide d un langage d interrogation de BD et que tous ses termes aient des correspondances dans la BD alors 19: la requête doit être reformulée en se basant sur le fichier de correspondance et elle est considérée comme mixte 20: sinon

14 14 TSI : si elle n est pas exprimée à l'aide d un langage sémantique permettant l interrogation de l ontologie alors 22: elle doit être transformée en un langage capable d interroger l ontologie 23: sinon la requête doit être exécutée dans l ontologie 24: si elle est valide alors 25: il s agit d une requête sémantique 26: sinon le système doit extraire les connaissances nécessaires à sa satisfaction tout en se basant sur les différentes relations sémantiques exprimées par l ontologie 19 27: si le système arrive à constituer une requête valide c est qu elle est sémantique. 28: sinon la requête est erronée. 29: fin condition 30: fin condition 31: fin condition 32: fin condition 33: fin condition 34: si la requête est constituée des termes appartenant à la fois à la BD et à l ontologie alors 35: le système doit reformuler la requête jusqu à ce qu elle devienne formée soit des termes appartenant tous à la BD soit des termes appartenant tous à l ontologie et ceci en se basant sur le fichier de correspondance. 36: fin condition 37: si la requête contient au moins un terme qui ne fait partie ni de la BD ni de l ontologie alors 38: la requête, dans sa forme actuelle, n admet pas de réponse et le système demande l assistance de l expert. 39: fin condition 40: Sortie : Résultat de la requête utilisateur, type de la requête (simple, sémantique ou bien mixte), les éventuelles reformulations de la requête. Dans notre travail, nous considérons les requêtes exprimées selon deux langages standards : le langage SQL (Structured Query Language), le standard utilisé par les principaux SGBDs et le langage SPARQL (Protocol And RDF Query Language) qui se distingue par sa capacité d exploiter et d interroger les différents formalismes du Web sémantique du W3C en particulier RDF et OWL (Sirin et Parsia, 2007). Il est important, ici, de signaler que le choix du langage formel influe sur la destination de la requête (BD et/ou ontologie) ainsi que sur son type (simple, sémantique ou bien mixte) : 19. Une requête utilisateur peut être inadaptée. En extrant les connaissances nécessaires par exemple les synonymies des termes inadaptés, le système peut constituer une requête valide exécutable dans l ontologie.

15 Approche de couplage de BD et d ontologie 15 Si la requête utilisateur est exprimée en SQL : alors sa destination ne peut être que la BD (pour des raisons techniques 20 ) et par voie de conséquence, la requête SQL ne peut être que simple ou mixte. Si la requête utilisateur est formulée avec SPARQL : dans ce cas, elle peut avoir n importe quelle destination (BD ou ontologie) puisqu on peut transformer une requête SPARQL en SQL et la diriger ainsi à la BD ce qui signifie que la requête peut être simple, sémantique ou bien mixte. Dans la section suivante, nous présenterons certaines règles définies pour le traitement des requêtes mixtes qui représentent un bon exemple de l'exploitation simultanée de la BD et l ontologie dans le cadre de leur couplage. 5. Traitement des requêtes SQL Les requêtes SQL mixtes sont le résultat de la reformulation des requêtes inadaptées. Pour qu une requête SQL inadaptée soit exécutable dans la BD, il faut que tous ses termes (après reformulation) fassent partie de la BD. Ceci nécessite : 1) la reformulation des termes inadaptés en s appuyant sur le fichier de correspondance de la BD et de l ontologie ; 2) la reformulation des termes erronés en s appuyant sur un référentiel sémantique. A cet effet, nous avons défini deux procédures : 1. La procédure ReformulationTermesInadaptés 21 qui prend en paramètres une requête inadaptée, un vecteur des termes inadaptés et le fichier de correspondance entre BD et ontologie. Elle cherche les éventuelles correspondances des termes inadaptés en se basant sur le fichier de correspondance ; 2. La procédure ReformulationTermesErronés qui prend en paramètres une requête inadaptée, un vecteur des termes erronés, la BD interrogée et un référentiel sémantique. Elle a pour rôle d extraire les connaissances du référentiel sémantique afin de trouver des correspondances (de synonymie, de méronymie, etc.) entre les termes erronés dans la BD. Algorithme 2. Résolution des termes inadaptés d une requête utilisateur. 1: Procédure ReformulationTermesInadaptés (ReqInadaptée, TermesInadaptés, FichCorrespondance) 2: Début : 3: pour tout TermeInadapté de la liste TermesInadaptés faire 4: Appliquer une expansion par synonymie à TermeInadapté pour générer «terme» 5: si «terme» n existe pas dans la BD alors 20. Puisqu on ne dispose pas actuellement d un moyen pour transformer une requête en SQL en un langage sémantique capable d interroger l ontologie. 21. Nous nous basons sur le travail de (Fayech et Ounalli, 2010) que nous enrichissons et adoptons à nos besoins.

16 16 TSI : Appliquer une expansion par spécialisation à TermeInadapté pour générer «terme» 7: si «terme» n est pas valide alors 8: Etendre la reformulation par spécialisation aux synonymes des concepts fils. 9: si toujours pas de résultat correct alors 10: Parcourir des niveaux plus profonds 22 dans la hiérarchie pour générer «terme» 11: si «terme» est inadapté alors 12: Demander avis utilisateur pour appliquer une expansion par méronymie à TermeInadapté et générer «terme» 13: fin condition 14: fin condition 15: fin condition 16: fin condition 17: si on trouve un «terme» valide alors 18: Retirer TermeInadapté de TermesInadaptés. 19: Reformuler la requête ReqInadaptée par le nouveau «terme» et générer ReqReformuleee. 20: sinon 21: La requête est erronée et le traitement 23 s'arrête. 22: fin condition 23: fin pour 24: fin procédure Notons que la reformulation par synonymie est une technique d expansion de requête qui consiste à remplacer un ensemble de termes par leurs synonymes extraits de dictionnaires, de thésaurus, d une ontologie linguistique ou d autres référentiels sémantiques. La reformulation par spécialisation consiste à remplacer certains termes de la requête par des termes qui les spécialisent. La reformulation par méronymie consiste à remplacer certains termes de la requête par leurs méronymes. Dans notre approche, afin de ne pas nuire à la pertinence du résultat, l intervention de l utilisateur nous semble indispensable pour décider de l'application de la reformulation en fonction des termes méronymes disponibles. Il est intéressant également de mentionner que nous n admettons pas la technique de reformulation par généralisation puisqu elle donne souvent des solutions plus générales et moins précises par rapport à ce qui est souhaité par l utilisateur. Nous présentons ci-dessous l'algorithme adopté pour la résolution des termes inadaptés dans une requête SQL et qui consiste à exécuter tout d abord la procédure ReformulationTermesInadaptés sur les tables inadaptées puis sur les colonnes inadaptées. 22. Chercher dans les descendants des concepts fils et ne pas se limiter aux descendants directs. 23. Il est inutile de poursuivre le traitement avec l existence de termes ne pouvant pas être adaptés.

17 Approche de couplage de BD et d ontologie 17 Algorithme 3. Résolution des termes inadaptés d une requête SQL. 1: Procédure ReformulationTermesInadaptés (ReqInadaptée, TablesInadaptées, ColonnesInadaptées, FichCorrespondance) 2: Début : 3: ReqReformulée ReformulationTermesInadaptés (ReqInadaptée, TablesInadaptées, FichCorrespondance) 4: si TablesInadaptées 24 est vide et ColonnesInadaptées est non vide alors 5: pour chaque table de ReqReformulée 6: Traiter les colonnes inadaptées 7: ReqReformulée ReformulationTermesInadaptés (ReqInadaptée, ColonnesInadaptées, FichCorrespondance) 8: fin boucle 9: fin condition 10: Sortie : Résultat de la requête utilisateur, son type et les éventuelles reformulations utilisées. La procédure ReformulationTermesErronés suit pratiquement la même stratégie que la procédure ReformulationTermesInadaptés à la différence qu elle cherche les éventuelles correspondances des termes inadaptés en s appuyant sur le référentiel sémantique et non pas sur le fichier de correspondance. Nous présentons ci-dessous un exemple de requêtes basées sur les extraits de la BD et l ontologie illustrées dans les Figures 3 et 4. La Figure 3 présente un extrait d une BD constituée de trois tables : 1) la table «teacher» contient trois colonnes : «cin» pour identifier le numéro de la carte d identité nationale d un enseignant, «name» précise son nom et «category» présente son grade ; 2) la table «paper» renferme la colonne «cod_pap» pour identifier les papiers, «title» pour enregistrer le titre et «date» pour préciser la date d édition ; 3) la table «writes» est une relation entre les deux tables «teacher» et «paper» ses colonnes sont ainsi les clés primaires de ces dernières. Figure 3. Extrait du modèle logique de la BD. 24. Il est inutile de corriger les colonnes si les tables sont encore inadaptées. Dans notre travail, nous abordons le traitement des colonnes uniquement si toutes les tables sont adaptées.

18 18 TSI 2013 person rdfs:subclassof rdfs:subclassof rdfs:subclassof student professor researcher student owl:equivalentclass owl:equivalentclass rdf:domain educator teacher level Figure 4. Extrait de l ontologie. La Figure 4 présente un extrait d ontologie OWL avec la syntaxe RDF/XML 25. Elle est composée de six concepts («person», «student», «professor», «reasercher student», «educator» et «teacher») et une propriété «level» (de type dataproperty) présentant le grade d un professeur. Certains concepts sont reliés par une relation d héritage (exprimée par rdfs:subclassof) comme (person, student), (person, professor) et (person, teacherstudent). D autres, sont considérés plutôt équivalents (owl:equivalentclass) et on trouve (professor équivalent à la fois à teacher et educator). Le fichier de correspondance entre les deux exemples d ontologie et de la BD est représenté par la Figure 5. <CorrespondanceDBOnto> <CommonTerms> <term value="teacher" roledb="table" roleonto="concept"/> </CommonTerms> <DBOnto> <term value="teacher" roledb="table"> <synonymy> <syn id="0" value="professor" roleonto="concept"/> <syn id="0" value="educator" roleonto="concept"/> </synonymy> </term> <term value="category" roledb="colonne"> <synonymy> <syn id="0" value="level" roleonto="datatypproperty"/> </synonymy> 25. OWL utilise différentes syntaxes (syntaxe RDF/XML basée sur RDF, syntaxe XML, syntaxe abstraite plus compacte que les précédentes, syntaxe graphique basée sur les conventions d UML, etc.).

19 Approche de couplage de BD et d ontologie 19 </term> </DBOnto> <OntoDB> <term value="professor" roleonto="concept"> <synonymy> <syn id="0" value="teacher" roledb="table"/> </synonymy> </term> <term value="level" roleonto="datatypproperty"> <synonymy> <syn id="0" value="category" roledb="colonne"/> </synonymy> </term> <term value="person" roleonto="concept"> <specialisation> <synsub id="0" value="teacher" roledb="table"/> </specialisation> </term> </OntoDB> </CorrespondanceDBOnto> Figure 5. Fichier de correspondance entre la BD et l ontologie de l exemple. Exemple : Soit la requête SQL suivante: SELECT level FROM teacher Comme déjà évoqué, l étape qui suit la création du fichier de correspondance consiste à analyser la requête utilisateur pour déterminer le rôle et la source de chaque terme en identifiant les éventuelles erreurs. Tables (ItemsFrom) Colonnes (ItemsSelect) Condition (ItemsWhere) Teacher (adapté) Level (inadapté) Dans cet exemple, la requête possède un terme inadapté «level» jouant le rôle d une colonne. Il faut donc chercher dans le fichier de correspondance un terme qui lui est correspondant jouant aussi le même rôle pour construire une requête correcte. En examinant le fichier de correspondance, on trouve que ce terme possède un synonyme («category») qui est une colonne de la table «teacher» de la BD. La requête doit être donc reformulée ainsi : SELECT category FROM teacher. 6. Traitement des requêtes SPARQL A l instar de la requête SQL, la requête SPARQL doit être analysée afin de déterminer sa nature. La requête SPARQL peut être de type : «select», la requête sélectionne des éléments selon un patron de requête particulier ; «ask», permet de répondre à une requête, en spécifiant si le patron recherché est présent dans le graphe interrogé ;

20 20 TSI 2013 «describe», la requête renvoie sous forme d un graphe RDF une description de la ressource passée en argument. Cette phase d'analyse permet dans certains cas de préciser directement le type de la requête (simple, sémantique, mixte). Par exemple, les requêtes «ask» et «describe» ne peuvent être que des requêtes sémantiques puisqu elles nécessitent de déduire des connaissances ne pouvant être fournies que par l ontologie. Ensuite, il faut distinguer les mots réservés (select, ask, where, ) de ceux introduits par l utilisateur reflétant son besoin réel. Outre les mots réservés, une requête SPARQL est composée par des termes issus directement de la source d information (dans notre cas la BD et l ontologie) et des variables utilisateur, précédées par un point d interrogation. Ces variables doivent être détectées pour ne pas être le sujet d une reformulation puisqu elles n ont pas de sémantique et elles peuvent aussi être identifiées par une suite alphanumérique quelconque. Une requête SPARQL peut être simple, sémantique ou bien mixte. Nous définissons une requête SPARQL mixte comme une requête qui demande à la fois l accès à la BD et à l ontologie. En effet, plusieurs cas peuvent se présenter, en l'occurrence, le cas des requêtes qui nécessitent de faire appel à la sémantique (raisonner au niveau de l'ontologie) avant qu elles ne soient lancées sur la BD pour en extraire les instances souhaitées. Règle : Si une requête SPARQL a le prédicat «rdf:type» et demande l affichage d un sujet, alors, elle a pour but d afficher des instances ce qui nécessite de la traduire en SQL et de l orienter vers la BD où sont stockées toutes les instances. La transformation d une requête SPARQL en une requête SQL peut être réalisée en se basant sur l'un des travaux suivants : Moteur sparql2sql de la plateforme Jena 26, SPASQL 27, Virtuos 28 ou encore en admettant le travail de (Zhang et al., 2012). Exemple. Soit la requête SPARQL suivante : SELECT?individu WHERE {?individu rdf:type onto:person} Cette requête demande l affichage de toutes les instances de type «person». Comme déjà évoqué, l ontologie ne contient aucune instance d où la nécessité d orienter la requête vers la BD. Mais avant cela, il faut l adapter pour qu elle ne soit constituée que de termes appartenant à la BD, ce qui nécessite le recours aux techniques de reformulation pour remplacer le terme «person» par ses correspondants dans la BD. En consultant le fichier de correspondance et en appliquant la reformulation par synonymie, la requête aura la forme suivante : SELECT?individu WHERE {?individu rdf:type onto:teacher} 26. jena.sourceforge.net/sparql2sql virtuoso.openlinksw.com/dataspace/dav/wiki/main/vossqlrdf