Le langage SOQA-QL indépendant d’un modèle d’ontologies particulier

Le second langage que nous présentons est le langage SOQA-QL conçu dans le contexte de l’inté-gration de données.

4.2.1 Présentation du langage SOQA-QL

Le langage SOQA-QL [Ziegler et al., 2005] a été conçu dans le contexte du projet SIRUP visant à permettre l’intégration de sources de données hétérogènes en fonction des besoins utilisateurs. Il permet d’interroger les ontologies et les données qu’elles décrivent indépendamment du modèle d’ontologies utilisé. L’approche suivie est basée sur la définition d’un modèle nommé SOQA Ontology Meta Model contenant les constructeurs importants de différents modèles d’ontologies. Les différents constructeurs de ce modèle d’ontologies sont les suivants.

– Le constructeur d’ontologies (Ontology). Ce constructeur permet de définir une ontologie avec un nom, un auteur, une documentation et un numéro de version.

– Le constructeur de classes (Concept). Ce constructeur permet de définir une classe avec un nom, une documentation et une définition. Il permet d’organiser les classes dans une hiérarchie utili-sant la relation de subsomption. Une classe a donc des super-classes et sous-classes directes et indirectes. Une classe est également décrite par les nouvelles propriétés et méthodes dont elle constitue le domaine ainsi que les relations dont elle fait partie.

– Le constructeur de propriétés (Attribute). Ce constructeur permet de définir une propriété avec un nom, une documentation, une définition, son type de données et sa classe de définition. – Le constructeur de méthodes (Method). Une méthode retourne une valeur à partir de valeurs de

paramètres. Ce constructeur permet de définir une méthode avec une classe de définition, un nom, une documentation, une définition, ses paramètres, son type de retour et sa classe de définition. – Le constructeur de relation (Relationship). Une relation permet d’établir un lien entre

diffé-rentes classes. Ce constructeur permet de définir une relation avec un nom, une documentation, une définition, son arité et les classes liées par cette relation.

– Le constructeur d’instances (Instance). Ce constructeur permet de définir des instances avec un nom, la classe dont elle est membre14et ses valeurs de propriétés.

Ce modèle d’ontologies a été utilisé pour définir une interface fonctionnelle d’accès à liaison préa-lable (SIRUP Ontology Query API). Cette API est constituée d’un ensemble de primitives permettant de récupérer les éléments d’une ontologie conforme à ce modèle.

Voici trois méthodes de cette API :

(M1) public Collection<Concept> getConcepts()

(M2) public Collection<Concept> getDirectSuperConcepts(String conceptName) (M3) public Collection<Instance> getInstances(String conceptName)

La méthode M1 permet de récupérer l’ensemble des classes (nommées concepts dans cette API) définies dans l’ontologie manipulée. La méthode M2 permet de récupérer l’ensemble des super-classes directes d’une classe dont le nom est passé en paramètre de la méthode. Enfin, la méthode M3 permet de récupérer l’ensemble des instances d’une classe dont le nom est passé en paramètre de la méthode.

Cette API constitue la base du langage SOQA-QL. Ce langage a en effet été défini en partant de SQL et en l’étendant pour qu’il puisse offrir les mêmes capacités que la SIRUP Ontology Query API. La syntaxe d’une requête SOQA-QL pour interroger les ontologies est la suivante :

SELECT attribute₁, · · · , attributen

FROM metaModelElementSet₁, · · · , metaModelElementSetm WHERE att_exp₁ OP_log₁ att_exp₂ · · · OP_log_k att_exp_k+1 ORDER BY attribute₁, ·, attributep

Chaque élément de la clause FROM (metaModelElementSet) est une collection (qui peut être réduite à un élément) de classes, propriétés, méthodes ou relations. Les éléments de la clause SELECT (proj) sont des attributs du modèle d’ontologies (par exemple documentation ou name). Les clauses WHERE et ORDER BYpermettent comme en SQL de filtrer les éléments spécifiés dans la clause FROM et de trier le résultat. L’exemple suivant illustre l’utilisation de cette syntaxe.

Exemple. Rechercher la documentation associée à la classe Post de l’ontologie dont l’espace de noms a pour alias sioc.

SELECT DOCUMENTATION FROM sioc:Post

Explication. Dans cet exemple, une seule classe est spécifiée dans la clause FROM. SOQA-QL traite cette

classe (Post) comme une collection réduite à un élément. La clause SELECT permet de projeter cette classe sur l’attribut DOCUMENTATION afin de retrouver la documentation la décrivant.

Afin d’intégrer les capacités de la SIRUP Ontology Query API, SOQA-QL est équipé d’une fonction pour chaque primitive de cette API. L’exemple suivant montre comment SOQA-QL permet d’intégrer les capacités de recherche des super-classes directes d’une classe (méthode M2 présentée précédemment).

Exemple. Rechercher la valeur des attributs (nom, documentation, etc.) décrivant les super-classes di-rectes de la classe Post.

SELECT * FROM DIRECTSUPERCONCEPTS(sioc:Post)

Explication. Conformément à sa signature dans la SIRUP Ontology Query API, la fonction DIRECT-SUPERCONCEPTS appliquée sur la classe Post retourne la collection des super-classes directes de cette classe. La clause SELECT permet de projeter cet ensemble de classes sur l’ensemble des attributs du modèle d’ontologies SOQA définis pour décrire les classes (syntaxe *).

Dans la clause SELECT, SOQA-QL ne permet d’utiliser que des attributs du modèle d’ontologies et pas de propriétés d’une classe donnée. Ainsi, le langage SOQA-QL a été essentiellement défini pour interroger les ontologies. Afin de permettre de retrouver tout de même les valeurs de propriétés des instances, SOQA-QL fournit les fonctions INSTANCES et VALUE. INSTANCES retourne l’ensemble des instances d’une ou plusieurs classes prises en paramètre. VALUE retourne la valeur d’une propriété prise en paramètre pour une instance donnée. L’utilisation de ces fonctions est illustrée dans l’exemple suivant.

Exemple. Rechercher la valeur de la propriété email pour les instances des sous-classes de la classe User.

SELECT VALUE(sioc:email)

FROM INSTANCES(SUBCONCEPTS(sioc:User))

Explication. Dans la clause FROM l’appel de la fonction SUBCONCEPTS permet de retrouver les sous-classes de la classe User. La fonction INSTANCES appliquée à cette collection de sous-classes retourne l’ensemble des instances de ces classes. La fonction VALUE utilisée dans la clause SELECT permet de projeter ces instances sur la propriété EMAIL. Comme le montre cette requête, SOQA-QL permet d’interroger à la fois l’ontologie (SUBCONCEPTS) et les données (VALUE).

4.2.2 Analyse du langage SOQA-QL par rapport aux exigences définies

Exigences 1, 2, 3 et 4 (Exigences liées au modèle en oignon)

Le langage SOQA-QL permet d’exprimer des requêtes au niveau ontologique indépendamment de la structure des données dans la BDBO (exigence 1). Par contre, il ne permet pas la définition de concepts non canoniques (exigence 2). L’aspect linguistique d’une ontologie est pris en compte dans le modèle d’ontologies SOQA (nom, documentation, définition, etc.) et donc dans le langage SOQA-QL. Cepen-dant, le multilinguisme n’est pas supporté. SOQA-QL supporte donc partiellement l’exigence 3. Enfin, le langage SOQA-QL est le premier langage ayant été conçu indépendamment d’un modèle d’ontologies particulier (exigence 4). Notons cependant que cette capacité est limitée aux constructeurs fournis dans le modèle d’ontologies noyau défini pour ce langage.

Exigences 5 et 6 (Compatibilité avec l’architecture traditionnelle des bases de données)

SOQA-QL est un des rares langages d’ontologies dont la syntaxe étend celle de SQL (exigence 5). Il permet ainsi d’effectuer la projection des entités définies dans le modèle d’ontologies sur des attributs. Les requêtes sur les ontologies se présentent donc comme une requête SQL classique. Notons par contre que la syntaxe proposée pour l’interrogation des données diffère de celle de SQL. Pour retourner la valeur d’une propriété pour les instances d’une classe, il est nécessaire d’utiliser les fonctions INSTANCES et VALUE. Le langage SOQA-QL satisfait donc partiellement l’exigence 5.

En SOQA-QL, les instances sont associées directement aux classes sans la notion de schéma (niveau logique). Il ne permet ainsi pas de manipuler explicitement la structure de ces données (exigence 6).

Exigences 7 , 8, 9 et 10 (Exigences en termes de pouvoir d’expression)

Le langage SOQA-QL ne propose pas de langage de définition et de manipulation de données (exi-gence 8) . Il ne propose également pas de langage pour définir et manipuler les ontologies d’une BDBO (exigence 7). Ainsi, il ne permet pas de manipuler le modèle d’ontologies utilisé. En conséquence les particularités d’un modèle d’ontologies donné ne peuvent pas être prises en compte par ce langage. Par exemple, le modèle d’ontologies PLIB permet de décrire les classes et les propriétés d’une ontologie par une remarque, une note, une illustration ainsi que de nombreux autres attributs. La valeur de ces attributs ne peut pas être récupérée en utilisant SOQA-QL. De même, OWL permet de définir des restrictions sur des propriétés. SOQA-QL ne permet pas de récupérer les restrictions portant sur une propriété donnée.

Par contre, SOQA-QL propose un langage d’interrogation qui permet d’interroger les ontologies et à la fois les ontologies et les données (exigences 9 et 10) en utilisant les fonctions INSTANCES et VALUE.

Exigences 11 et 12 (Implantation du langage)

Au niveau implantation, la sémantique du langage SOQA-QL est définie en termes de la SIRUP Ontology Query API qui constitue l’algèbre de ce langage (exigence 11). Cette API a été implantée pour différents modèles d’ontologies. A notre connaissance ces implantations n’ont pas été réalisées sur des BDBO mais sur des fichiers. Enfin, ce langage est équipé d’un outil permettant de l’utiliser en ligne de commande (exigence 12). Le langage SOQA-QL satisfait donc nos exigences sur l’implantation de ce langage.

Synthèse et conclusion

Le tableau 2.4 synthétise l’analyse du langage SOQA-QL par rapport aux exigences définies. L’innovation du langage SOQA-QL est d’être fondé sur un modèle d’ontologies noyau contenant les constructeurs fondamentaux de nombreux modèles d’ontologies. Les limitations principales de ce langage par rapport à nos exigences sont les suivantes :

– le modèle d’ontologies noyau est figé. En conséquence, les spécificités de certains modèles d’on-tologies ne peuvent pas être prises en compte par le langage SOQA-QL ;

– les couches OCNC et OL d’une ontologie ne sont pas supportées par le langage SOQA-QL ; – SOQA-QL ne propose pas de langage de définition et de manipulation de données.

Exigences SOQA-QL

Expression de requête niveau ontologique •

Définition de concepts non canoniques

-Exploitation linguistique ◦

Indépendance par rapport à un modèle d’ontologies donné •

Compatibilité avec SQL ◦

Définition, manipulation et interrogation du schéma des données

-Définition et manipulation des ontologies

-Définition et manipulation des données

-Interrogation des ontologies •

Interrogation à la fois des ontologies et des données •

Définition d’une sémantique formelle •

Outils permettant l’exploitation du langage •

T. 2.4 – Analyse du langage SOQA-QL par rapport aux exigences définies

5 Conclusion

Dans ce chapitre, nous avons tout d’abord analysé l’architecture de BDBO proposée en termes d’exi-gences. Les principales exigences établies résultent d’une part de l’ajout du niveau ontologique dans l’architecture ANSI/SPARC décomposée selon les trois couches du modèle en oignon. Elles résultent, d’autre part, du fait que notre architecture est compatible avec celle des SGBD existants et donc, conserve le traitement des données au niveau logique.

Nous avons ensuite analysé différentes catégories de langages proposées dans la littérature par rapport à ces exigences. Nous avons vu dans un premier temps que les langages de BDBO conçus pour le Web Sémantique (SPARQL et RQL) ne présentent pas de compatibilité avec l’architecture usuelle des bases de données. Ils ne permettent ainsi pas de manipuler les données d’une BDBO au niveau logique et propose une syntaxe et une sémantique différentes de SQL. De plus, les langages construits pour RDF tels que SPARQL sont dépendants de l’interprétation des triplets représentés dans une BDBO. Quant au langage RQL, défini pour RDF-Schema, il présente des capacités limitées pour prendre en compte les spécificités introduites par certains modèles d’ontologies et n’exploite pas les définitions linguistiques d’une ontologie.

Dans un second temps, nous avons étudié les langages CQL et SOQA-QL qui ont été conçus dans un autre contexte que le Web Sémantique. Nous avons montré que CQL ne satisfait pas nos exigences parce qu’il est lié à un modèle d’ontologies et qu’il ne permet pas de manipuler ce dernier. Concernant le langage SOQA-QL nous avons vu qu’il est indépendant d’un modèle d’ontologies particulier mais qu’il ne permet pas, par contre, de prendre en compte les spécificités d’un modèle d’ontologies particulier. De plus, aucun de ces deux langages ne permet de manipuler des classes non canoniques.

Même si ces langages ne satisfont pas les exigences définies, ils proposent des approches permettant d’en satisfaire une partie. Nous retenons notamment les approches suivantes proposées par ces langages :

– construire le langage sur la base d’un modèle d’ontologies noyau contenant les constructeurs partagés par différents modèles d’ontologies proposés dans la littérature pour que le langage soit indépendant d’un modèle d’ontologies particulier (approche proposée par SOQA-QL) ;

– construire le langage à partir de SQL pour permettre la manipulation des données au niveau lo-gique (approche proposée par CQL) ;

– ajouter des opérateurs permettant de rechercher la valeur d’attributs et/ou de propriétés dans plu-sieurs langues naturelles (approche proposée par SPARQL) ;

– utiliser le mécanisme de vue des bases de données pour permettre de définir des concepts non canoniques (approche proposée par RQL).

Ayant établi qu’il n’existe pas de langage satisfaisant l’ensemble des exigences que nous avons éta-blies, nous proposons un nouveau langage nommé OntoQL. La conception de ce langage est inspirée des approches que nous venons d’énoncer. Nous présentons ce langage dans la partie suivante.

Chapitre

3

Traitements des données à base ontologique d’une BDBO

Sommaire

1 Introduction . . . . 93 2 Exploitation des données à base ontologique au niveau logique . . . . 94 2.1 Modèle de données du niveau logique . . . . 94 2.2 Langage de définition, de manipulation et d’interrogation de données . . . 96 2.3 Utilisation . . . . 99 3 Exploitation des données à base ontologique au niveau ontologique.

Application à la couche OCC . . . 100 3.1 Modèle de données du niveau ontologique, couche OCC . . . 100 3.2 Aspects syntaxiques . . . 104 3.3 Langage de Définition de Données (LDD) . . . 106 3.4 Langage de Manipulation de Données (LMD) . . . 111 3.5 Langage d’Interrogation de Données (LID) . . . 112 4 Exploitation des données à base ontologique au niveau ontologique.

Application à la couche OCNC . . . 119 4.1 Problématique . . . 119 4.2 Langage de Définition de Vues (LDV) . . . 120 4.3 Utilisation . . . 123 5 Exploitation des données à base ontologique au niveau ontologique.

Application à la couche OL . . . 127 5.1 Modèle de données du niveau ontologique, couche OL . . . 127 5.2 Aspects syntaxiques . . . 128 5.3 Langage de définition, de manipulation et d’interrogation de données . . . 129 6 Conclusion . . . 131

Résumé. Dans le chapitre précédent, nous avons défini les exigences de conception d’un langage d’exploitation de l’architecture ANSI/SPARC étendue proposée et nous avons vu que nous ne connaissions pas de langage qui y réponde de manière satisfaisante. Nous pré-sentons à présent notre proposition de langage, nommé OntoQL, conçu pour répondre à ces

différentes exigences [Jean et al., 2006a, Jean et al., 2006b]. Dans ce chapitre, nous mettons l’accent sur les traitements des données à base ontologique que permet de réaliser le langage OntoQL lorsqu’un utilisateur connaît le modèle logique des données et/ou les ontologies qui les décrivent. Les données à base ontologique devant pouvoir être manipulées tant au niveau logique de l’architecture ANSI/SPARC étendue qu’au niveau ontologique suivant les trois catégories du modèle en oignon (OCC, OCNC, OL), nous avons choisi de concevoir le langage OntoQL en couches, chacune correspondant à un des niveaux d’accès nécessaires. Chaque couche est définie par un modèle de données ainsi que par les opérateurs du langage permettant de manipuler des données conformes à ce modèle. Pour définir ces modèles de données et ces opérateurs, nous avons cherché à rester le plus proche possible du langage SQL afin que langage OntoQL permette un accès homogène aux différents niveaux d’accès proposés. Le résultat est un langage qui (1) est compatible avec un sous-ensemble de SQL pour permettre de manipuler les données à base ontologique au niveau logique, comme dans une base de données traditionnelle et (2) adapte et étend ce sous-ensemble de SQL pour per-mettre de traiter les données à base ontologique à partir du niveau ontologique selon les trois catégories du modèle en oignon.

1 Introduction

Dans le chapitre précédent, nous avons justifié la nécessité d’un nouveau langage de BDBO en défi-nissant les exigences pour l’architecture ANSI/SPARC étendue proposée. Pour répondre à ce besoin d’un nouveau langage, nous avons conçu le langage OntoQL [Jean et al., 2006a, Jean et al., 2006b]. Plutôt que de présenter ce langage globalement, en identifiant ses sous-langages de définition, manipulation et in-terrogation de données, nous avons choisi de le décrire selon deux familles de traitements et de fonctions qu’il offre : les traitements des données à base ontologique (présentés dans ce chapitre) et les traitements des ontologies et à la fois des ontologies et des données (présentés dans le chapitre suivant).

La composante du langage OntoQL décrite dans ce chapitre est sa capacité d’exploiter les données à base ontologique selon les différents niveaux de l’architecture ANSI/SPARC étendue. Ces traitements supposent que l’utilisateur connaisse le modèle logique des données à base ontologique (hypothèse éga-lement faite dans les bases de données traditionnelles) et/ou les ontologies qui en décrivent le sens. Les traitements présentés dans ce chapitre sont ainsi similaires à ceux proposés dans les bases de données traditionnelles sauf qu’ils permettent, en plus, d’accéder aux données d’une base de données indépen-damment de son modèle logique ; et cela, à partir du niveau ontologique correspondant à chacune des couches du modèle en oignon.

Compte tenu des différents niveaux d’accès nécessaires aux données à base ontologique, nous avons conçu le langage OntoQL en couches. Chaque couche permet d’exploiter les données à base ontologique suivant un des niveaux de l’architecture ANSI/SPARC étendue. Ces couches sont les suivantes :

– la couche d’accès aux données à base ontologique au niveau logique ;

– la couche d’accès aux données à base ontologique au niveau OCC dans le modèle en oignon ; – la couche d’accès aux données à base ontologique au niveau OCNC dans le modèle en oignon ; – la couche d’accès aux données à base ontologique au niveau OL dans le modèle en oignon. Le travail de définition d’un langage nécessitant à la fois de définir le modèle de données considéré, composé de structures de données et des constructeurs associés, ainsi que les opérateurs permettant de manipuler des données conformes à ce modèle, il a été mené pour chacune de ces couches.

Pour que le langage OntoQL conserve une compatibilité ascendante avec le langage SQL (exigence 5) et propose une syntaxe uniforme pour exploiter les données à base ontologique aux différents niveaux de l’architecture ANSI/SPARC étendue, nous nous sommes basés sur le modèle de données et les opérateurs de SQL pour définir les différentes couches d’accès offertes par le langage. Le résultat est un langage qui (1) est compatible avec un sous-ensemble de SQL pour permettre de manipuler les données à base ontologique au niveau logique, comme dans une base de données traditionnelle et (2) adapte et étend ce sous-ensemble de SQL pour permettre de traiter les données à base ontologique au niveau ontologique selon les trois catégories du modèle en oignon.

Ce chapitre est organisé comme suit. La section 2 présente la couche d’accès aux données à base ontologique au niveau logique en présentant le sous-ensemble de SQL avec lequel le langage OntoQL est compatible. Les trois sections suivantes sont consacrées aux couches d’accès aux données à base ontologique au niveau ontologique. Nous présentons d’abord, dans la section 3, la couche d’accès aux données à partir des concepts canoniques d’une ontologie. Puis, nous montrons dans la section 4 com-ment les concepts non canoniques peuvent être représentés et utilisés pour accéder aux données à base

ontologique en utilisant le mécanisme de vue des bases de données. Enfin, la section 5 présente l’accès aux données à base ontologique en utilisant la couche linguistique d’une ontologie qui permet d’expri-mer des requêtes en utilisant les noms associés aux concepts d’une ontologie. Ce chapitre est conclu à la section 6 en synthétisant les possibilités offertes par le langage OntoQL pour manipuler les données à