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.

(1)

Techniques et sciences informatiques

pour l’aide à la décision sémantique : contribution pour la satisfaction des requêtes SQL et SPARQL.

Mariem Mahfoudh

¹

, Wassim Jaziri

²

1. Laboratoire MIPS, EA-2332 -Université de Haute-Alsace (UHA), 12 rue des frèresLumière, 68093 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.

(2)

1. 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¹, 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)

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.

2.1. 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é² 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)

(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³ (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⁴, RQL⁵ 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

3. www.w3.org/RDF

4. www.w3.org/TR/rdf-sparql-query 5. athena.ics.forth.gr:9090/RDF/RQL

(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⁶ : Basic Formal Ontology ou DOLCE⁷ : Descriptive Ontology for Linguistic and Cognitive Engineering).

2.2. 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. www.ifomis.org/bfo 7. www.loa.istc.cnr.it/DOLCE

(6)

é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⁸ 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)

– 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⁹ 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.

2.3. 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¹⁰. 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¹¹ (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.

11. www.w3.org/TR/rdf-schema

(8)

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¹² 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).

3.1. 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)

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¹³ 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.

3.2. 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¹⁴ à 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)

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.

4.1. 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¹⁵ 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)

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¹⁶ (entre termes), de méronymie¹⁷, et de subsomption¹⁸ (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)

4.2. 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.

4.3. 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)

-

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)

21: 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¹⁹

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.

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.

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.

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)

– Si la requête utilisateur est exprimée en SQL : alors sa destination ne peut être que la BD (pour des raisons techniques²⁰) 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²¹ 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)

6: 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²² 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 »

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²³ 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)

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²⁴ 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)

Figure 4. Extrait de l’ontologie.

La Figure 4 présente un extrait d’ontologie OWL avec la syntaxe RDF/XML²⁵. 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.

</CommonTerms>

</synonymy>

</term>

</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.).

professor person

researcher student

teacher student

rdfs:subClassOf rdfs:subClassOf

rdfs:subClassOf

level educator

owl:equivalentClass owl:equivalentClass rdf:domain

(19)

</term>

</DBOnto>

</synonymy>

</term>

</synonymy>

</term>

</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)

– « 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²⁶, SPASQL²⁷, Virtuos²⁸ 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

27. www.w3.org/2005/05/22-SPARQL-MySQL/XTech

28. virtuoso.openlinksw.com/dataspace/dav/wiki/Main/VOSSQLRDF

(21)

Enfin, la requête doit être transformée en SQL pour pouvoir interroger la BD et aura finalement la forme : Select * from teacher ;

7. Implémentation

Afin de mettre en œuvre la méthode définie, nous avons développé l'outil CoDBOnto (tool for Coupling DataBase and Ontology) dont l’architecture est représentée par la Figure 6. CoDBOnto, développé en langage java pour être portable et facile à évoluer, vise à mettre en place un système assurant le couplage entre BD et ontologie de domaine afin de répondre à des requêtes utilisateur, exprimées en SQL ou SPARQL.

L’interface de l'outil permet à l’utilisateur de formuler de manière simple et conviviale ses requêtes. Elle est composée d’une barre de menu et d'une barre d’outils permettant à l’utilisateur de charger son ontologie, sa BD ainsi que la visualisation de ces deux sources d’information et du résultat de leur couplage. Elle guide l’utilisateur tout au long du processus de satisfaction d'une requête, en affichant, entre autres, le type de la requête ainsi que le résultat. L'outil CoDBOnto supporte les ontologies au format OWL.

Suite au chargement de la BD et de l’ontologie, l’outil CoDBOnto commence le processus d'analyse qui se termine par l’affichage de ces deux composantes sous forme d’arborescences. Nous nous basons à cet effet sur la bibliothèque Jena²⁹ (version 2.6) qui est une API open source permettant de lire et de manipuler des ontologies décrites en RDF, RDFS et OWL. Elle supporte aussi le langage SPARQL et permet d’appliquer différents mécanismes d'inférence aidant à l’extraction des connaissances de l’ontologie.

29. jena.sourceforge.net

(22)

Figure 6. Architecture de l’outil CoDBOnto.

La phase d’analyse de la BD et de l’ontologie aboutit à la création du fichier de correspondances au format XML, construit à l’aide des API JDOM et RitaWN³⁰.

– RitaWN est une API java disponible gratuitement en téléchargement. Elle fournit un accès simple à l'ontologie WordNet³¹ et permet d’extraire ses différentes relations sémantiques. Bien que d’autres API existent pour la manipulation de WordNet telles que JAWS³² et JWNL³³, RitaWN reste la plus simple à gérer ;

– JDOM est une API Java permettant la manipulation au sens large de documents XML : création, lecture, représentation sous forme d'arborescence, etc.

L’analyse des requêtes utilisateur exprimées en SQL et SPARQL se base sur les analyseurs³⁴ ZQL³⁵ et ARQ³⁶ :

– ZQL : un parseur de requêtes SQL qui offre une documentation détaillée et une API simple à manipuler ;

30. rednoise.org/rita/wordnet/documentation/index.htm 31. wordnet.princeton.edu

32. lyle.smu.edu/~tspell/jaws/index.html 33. sourceforge.net/projects/jwordnet

34. D'autres parseurs existent : websemantique.org/AnalyseurSyntaxique.

35. www.gibello.com/code/zql 36. jena.sourceforge.net/ARQ

(23)

– ARQ : un analyseur de requêtes SPARQL qui constitue avec Jena un système complet pour le stockage et l’interrogation des ontologies.

L'utilisateur saisit sa requête exprimée en SQL ou en SPARQL et le système se charge de trouver la réponse adéquate ainsi que le type de la requête et les éventuelles reformulations adoptées. Le système se charge tout d’abord de détecter le langage utilisé pour la formulation de la requête (SQL ou SPARQL) puis, selon le cas, de satisfaire les besoins de l’utilisateur. Nous présentons ci-dessous des exemples de requêtes manipulées par l'outil CoDBOnto, basées sur les extraits de la BD et l’ontologie illustrées dans les Figures 3 et 4.

Exemple 1 : une requête SQL mixte.

La Figure 7 présente un exemple de requête mixte qui nécessite à la fois l’accès à l’ontologie et à la BD. Il s’agit d’une requête SQL (select * from person) constituée d’un seul terme (« person ») appartenant à l’ontologie. Le système cherche l’existence de correspondants de ce terme dans le fichier de correspondance (voir Figure 5) afin de reformuler la requête pour qu’elle ne soit constituée que de termes appartenant à la BD (la recherche se base sur l’existence du nom de la table et non sur sa sémantique). Le système vérifie les termes synonymes du terme « person » puis les termes qui le spécialisent et enfin les méronymes. Il trouve ainsi que

« person » possède un correspondant dans la BD qui est le terme « teacher », le synonyme de son concept fils « professor ». Dans la recherche de correspondances par spécialisation, on ne se limite pas aux descendants directs d’un concept mais on étend la recherche aux différents niveaux de hiérarchie ainsi qu'aux synonymes des termes des concepts fils.

Figure 7. Exemple de requête SQL Mixte.

Exemple 2 : requête SPRAQL mixte.

L’utilisateur peut formuler ses besoins par des termes erronés qui n’existent ni dans la BD ni dans l’ontologie. Le système détecte ces termes et les affiche en précisant leur rôle dans la requête et en offrant à l’utilisateur le choix entre la

(24)

reformulation de sa requête ou le chargement d’un référentiel sémantique qui se charge de trouver des éventuelles correspondances entre ces termes erronés et ceux qui existent dans l’ontologie et la BD.

La Figure 8 montre un exemple de requête SPARQL contenant un terme erroné

« article » : qui n’existe ni dans l’ontologie ni dans la BD. Cette requête a une spécificité : elle demande l’affichage de toutes les instances de type « article » (son prédicat est rdf:type). Comme nous l'avons é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. Pour résoudre un tel problème, nous demandons l’assistance du référentiel sémantique WordNet qui se charge de fournir les différentes synonymies, hyponymies et méronymies de ce terme. Il revient au système de comparer ces termes avec ceux existants dans la BD.

Après toute analyse faite, le système trouve que le terme « article » est le synonyme du terme « paper » se trouvant dans la BD. Il reformul la requête et la transforme en langage SQL pour qu’elle soit capable d’interroger la BD (Figure 9).

Figure 8. Exemple de requête SPARQL Mixte : exploitation de l’ontologie.

(25)

WordNet.

Figure 9. Réponse de la requête SPARQL Mixte présentée par la Figure 8.

8. Conclusion

Cet article s'intéresse au problème de couplage entre BD et ontologie dans un système de recherche d'information pour la satisfaction de requêtes utilisateur.

L'approche proposée se base sur trois étapes essentielles : (1) analyse de la BD et de l'ontologie permettant de créer un fichier XML enregistrant les différentes correspondances entre elles ; (2) analyse des requêtes utilisateurs ; (3) traitement des requêtes selon des règles définies à cet effet. Différentes techniques de reformulation ont été explorées, essentiellement basées sur la relation de synonymie et les relations de subsomption et de méronymie.

Nous avons également implémenté l'outil CoDBOnto qui supporte les langages SQL et SPARQL et permet de créer automatiquement le fichier de correspondance entre la BD et l’ontologie utilisateur, en se référant à l’ontologie linguistique Wordnet. Ce fichier assure la scalabilité du système et pourra être utilisé pour étendre les bases de données. Différentes expérimentations ont été élaborées sur des requêtes variées selon la syntaxe de SQL et de SPARQL et ont montré l’apport de notre approche et l’outil développé dans l’assistance des utilisateurs et la satisfaction de leurs requêtes.

De nombreuses perspectives peuvent être dégagées à la suite de nos travaux. En premier abord, il s'agit d’étendre les expérimentations afin d'analyser en détails l’impact de nos différentes propositions et tester plus profondément les performances de l’outil proposé. Il serait également intéressant de travailler sur l’amélioration des règles et l’enrichissement des services offerts par notre outil.

Nous envisageons également étudier la transformation des requêtes SPARQL en SQL et inversement afin d'intégrer des fonctionnalités de couplage plus avancées.

Enfin, dans notre travail, nous exigeons que les requêtes soient exprimées par des langages formels et non en langage naturel. En fait, ce serait intéressant

(26)

d’implémenter un système supportant le langage naturel, pour éviter l'apprentissage d'un langage formel complexe et la connaissance rigoureuse de la structure de la source d’information ce qui permet d’assurer un dialogue aisé favorisant le confort de l’utilisateur. Ceci nous semble envisageable par TALN ou en ayant recours à des mécanismes relevant de l’interface homme machine via des interfaces conviviales et des menus de sélection.

Bibliographie

An Y., Borgida A., Mylopoulos J. (2006). Discovering the semantics of relational tables through mappings. Journal of Data Semantics, Vol. 7, p. 1-32, Springer.

Astrova R., Korda N., Kalja A. (2007). Storing OWL ontologies in SQL relational databases.

International Journal of Electrical Computer and Systems Engineering, p. 242-247.

Bizer C. (2003). D2R map - a database to RDF mapping language. In Proceedings of the 12th International World Wide Web Conference, p. 20-24.

Bohannon P., Elnahrawy E., Fan W., Flaster M. (2006). Putting context into schema matching. In Proceedings of the 32nd International conference on very large databases, p. 307-318. VLDB Endowment.

Cerbah F. (2008). Learning highly structured semantic repositories from relational databases.

In The semantic web: Research and applications, p. 777-781, Springer.

Cullot N., Ghawi R., Yétongnon K. (2007). Db2owl: A tool for automatic database-to- ontology mapping. In Proceedings of the 15th italian symposium on advanced database systems, p. 491-494.

Dehainsala H., Pierra G., Bellatreche L. (2007). Ontodb: an ontology-based database for data intensive applications. In Proceedings of the 12th international conference on database systems for advanced applications, p. 497-508, Springer.

Fankam C., Bellatreche L., Dehainsala H., Ameur Y. A., Pierra G. (2009). Sisro, conception de bases de données à partir d’ontologies de domaine. Technique et Science Informatiques, Vol. 28, No. 10, p. 1233-1261.

Farouk M., Ishizuka M. (2012). Mapping db to rdf with additional discovered relations. In Proceedings of the 11th wseas International conference on artificial intelligence, knowledge engineering and data bases, p. 195-200. World Scientific and Engineering Academy and Society (WSEAS).

Gali A., Chen C. X., Claypool K. T., Uceda-Sosa R. (2004). From ontology to relational databases. In Conceptual modeling for advanced application domains, p. 278-289.

Springer.

Gherabi N., Bahaj M. (2012). A new method for mapping uml class into owl ontology. IJCA Special Issue on Software Engineering, Databases and Expert Systems, p. 5-9.

Guarino N. (1998). Formal ontology and information systems. In Proceedings of the 1^st international conference on formal ontologies in information systems (fois’98), p. 3-15.

IOS Press.

(27)

Hu W., Qu Y. (2007). Discovering simple mappings between relational database schemas and ontologies. In Proceedings of the 6th International the semantic web and 2nd Asian conference on asian semantic web conference, p. 225-238. Springer.

Jean S., Aït-Ameur Y., Pierra G. (2006). Querying ontology based databases-the ontoql proposal. In Proceedings of the 18th international conference on software engineering &

knowledge engineering (SEKE2006), p. 166–171.

Kamel M., Aussenac-Gilles N. (2009). Construction automatique d’ontologies à partir de spécifications de bases de données. Journées francophones d’Ingénierie des Connaissances (IC2009), p. 85-96.

Krivine S., Nobécourt J., Soualmia L. F., Cerbah F., Duclos C. (2009). Construction automatique d’ontologies à partir d’une base de données relationnelles : application au médicament dans le domaine de la pharmacovigilance. Journées francophones d’Ingénierie des Connaissances (IC2009), p. 73-84.

Laborda C. P. de, Conrad S. (2006). Database to semantic web mapping using rdf query languages. In Proceedings of the 25th International conference on conceptual modeling, p. 241-254. Springer.

Lubyte L., Tessaris S. (2009). Automatic extraction of ontologies wrapping relational data sources. In Database and expert systems applications, p. 128-142, Springer.

Nyulas C., OConnor M., Tu S. (2007). Datamaster–a plug-in for importing schemas and data from relational databases into protege. In Proceedings of the 10th International protégé conference.

Rodriguez J. B., Gómez-Pérez A. (2006). Upgrading relational legacy data to the semantic web. In Proceedings of the 15th International conference on world wide web, p. 1069- 1070.

Sahoo S. S., Halb W., Hellmann S., Idehen K., Thibodeau Jr T., Auer S. et al. (2009). A survey of current approaches for mapping of relational databases to rdf. W3C RDB2RDF Incubator Group Report.

Salton G., McGill M. J. (1986). Introduction to modern information retrieval. McGraw-Hill, Inc.

Sirin E., Parsia B. (2007). Sparql-dl: Sparql query for owl-dl. In Proceedings of the third International workshop on owl: Experiences and directions (owled’07).

Sugumaran V., Storey V. C. (2006). The role of domain ontologies in database design: An ontology management and conceptual modeling environment. ACM Trans. Database Syst., Vol. 31, No. 3, p. 1064-1094.

Tirmizi S. H., Sequeda J., Miranker D. (2008). Translating sql applications to the semantic web. In Proceedings of the 19th international conference on database and expert systems applications, p. 450-464. Springer.

Trinkunas J., Gediminas V., Vasilecas O., Gediminas V. (2007). Building ontologies from relational databases using reverse engineering methods. In Compsystech ’07: Proceedings of the 2007 international conference on computer systems and technologies, p. 1-6. ACM.

Vysniauskas E., Nemuraite L. (2006). Transforming ontology representing from owl to relational database. Information Technology and Control, Vol. 35, No. 3A, p. 333-343.

(28)

Zhang H., Lin L., Qiang B. (2012). A semantic wrapper of deep web data source based on rdf view. Journal of Computational Information Systems, Vol. 8, No. 9, p. 3527–3539.

Article reçu le 8 décembre 2011 Article accepté après révisions le 15 avril 2013

Biographie

Mariem Mahfoudh est actuellement doctorante en informatique au sein du laboratoire MIPS/EA-2332 (Modélisation, Intelligence, Processus et Systèmes) de l’université de Haute Alsace, Mulhouse, France. Elle a eu son diplôme de master en 2011 de l’ISIMS, Sfax, Tunisie.

Ses travaux de recherche portent principalement sur les ontologies, la représentation et la gestion des connaissances (essentiellement les graphes et les logiques de description) et les spécifications algébriques.

Wassim Jaziri est professeur en informatique au College of Computer Science and Engineering, Taibah University, Arabie Saoudite. Après l’obtention de son doctorat à l’INSA- Rouen, France, en 2004, il a commencé sa carrière en tant que chercheur post-doctorat au CIRAD, Montpellier, France. Il a ensuite été Maitre Assistant puis Maitre de Conférences à l’ISIM-Sfax, Tunisie. Ses travaux de recherche sont à cheval entre les Systèmes d’Information Géographique, les ontologies et l’optimisation sous contraintes.