Analyse du langage OntoQL par rapport aux exigences définies

Exigence 1 (Expression de requêtes niveau ontologique)

Le langage OntoQL permet d’exprimer des requêtes sur les données à partir des ontologies, indé-pendamment du schéma des données, avec une puissance d’expression proche de SQL99 (cf. chapitre 3, section 3).

Une comparaison du pouvoir d’expression de plusieurs langages définis pour RDF a été proposée dans [Haase et al., 2004] sur un échantillon de requêtes. L’expression de ces requêtes en OntoQL est présentée dans l’annexe B. Cette étude montre que le langage OntoQL propose les opérateurs suivants, peu supportés par les autres langages considérés dans l’étude :

– les opérateurs d’agrégat (GROUP BY) et de tri (ORDER BY) ;

– les opérateurs sur les collections (par exemple, l’accès à un élément donné d’une collection) ; – les opérateurs permettant d’exploiter le multilinguisme (rechercher une valeur dans une langue

– les opérateurs sur les types de données (par exemple, les opérateurs arithmétiques sur les entiers).

Par contre, il ne permet pas d’exprimer des requêtes récursives ainsi que les requêtes qui nécessitent de prendre en compte certaines particularités de RDF telles que la réification où le fait que tout élément manipulé constitue une ressource en RDF. Nous avons également vu qu’il ne permet pas d’exprimer des requêtes non typées.

Exigence 2 (Définition de concepts non canoniques)

Des classes non canoniques peuvent être créées en utilisant le LDD. L’extension de cette classe est définie à partir d’une requête OntoQL à l’image des vues en SQL (cf. chapitre 3, section 4).

Par rapport au langage RVL, la principale différence est que le langage OntoQL permet d’organi-ser les classes canoniques et non canoniques dans la même hiérarchie. Dans RVL, ces deux types de concepts sont clairement distingués pour respecter le principe d’indépendance logique. Pour nous, les classes canoniques et les classes non canoniques ne forment qu’un seul et même niveau : le niveau onto-logique. Notons que ne pas distinguer ces deux types de concepts évite de devoir importer les concepts canoniques, nécessaires à la définition des concepts non canoniques, dans un nouvel espace de noms.

Une autre différence est que dans le langage OntoQL, lorsque les concepts non canoniques peuvent être mis à jour, ces mises à jour sont répercutées sur les concepts canoniques correspondants. Nous avons fait ce choix pour rester conforme à la sémantique des modèles d’ontologies qui offrent des constructeurs de concepts non canoniques comme par exemple OWL. En RVL, les concepts non canoniques peuvent toujours être mis à jour. Par contre, ces mises à jour ne sont pas répercutées sur les concepts à partir desquels ces concepts non canoniques ont été définis.

Enfin, par rapport à la problématique de définir la couche OCNC d’une ontologie, ces deux langages présentent les limitations évoquées à la fin de la section 4 du chapitre 3, c’est-à-dire essentiellement de ne pas permettre le placement automatique des classes non canoniques dans la hiérarchie de classes.

Exigence 3 (Exploitation linguistique)

Les modèles de données définis pour exploiter les ontologies et leurs instances prennent en compte le multilinguisme. En effet, les ontologies sont exploitées par rapport à un modèle d’ontologies noyau dont les noms d’entités et d’attributs ainsi que les valeurs d’attributs peuvent être définis dans plusieurs langues naturelles (cf. section 2.5). De même, les instances sont exploitées par rapport aux ontologies dont les noms des classes et des propriétés ainsi que les valeurs de propriétés peuvent également être définis dans plusieurs langues naturelles (cf. chapitre 3, section 5). Les instructions OntoQL peuvent ainsi être exprimées dans différentes langues naturelles et traiter des données caractérisées dans différentes langues naturelles. Cette capacité n’est cependant possible que si (1) les noms des classes sont uniques pour un espace de noms et une langue naturelle donnés et si (2) les noms des propriétés sont uniques pour une classe, un espace de noms et une langue naturelle donnés (cf. section 5 du chapitre 3).

SPARQL est un des rares langages qui permet également d’exploiter le multilinguisme. En effet, comme OntoQL, il permet de rechercher une valeur de propriétés ou d’attributs dans différentes langues naturelles. Il propose également les fonctions lang et lang-matches qui permettent de retrouver la langue naturelle dans laquelle une chaîne de caractères est définie. Ces fonctions sont particulièrement

utiles lorsque l’on utilise une propriété multilingue dans une projection et que l’on souhaite connaître la langue naturelle dans laquelle chaque valeur retournée est définie. Ces fonctions ne sont pas proposées par OntoQL car il ne permet de réaliser une projection impliquant une propriété multilingue que par rapport à une langue naturelle donnée. Par contre, contrairement à OntoQL, SPARQL ne permet pas d’exprimer des requêtes multilingues car il est basé sur le modèle RDF qui n’impose pas les contraintes permettant de proposer cette fonctionnalité.

Exigence 4 (Indépendance par rapport à un modèle d’ontologies donné)

Le langage OntoQL est construit sur un modèle noyau contenant les constructeurs communs à dif-férents modèles d’ontologies (cf. section 2.1). Ce modèle noyau peut être étendu en y ajoutant de nou-veaux constructeurs afin de prendre en compte les particularités d’un modèle d’ontologies donné. Cette extension est principalement structurelle. Ceci permet de représenter dans une BDBO l’ensemble des descriptions fournies par une ontologie quel que soit le modèle d’ontologies selon lequel elle est définie. Niveau sémantique, les constructeurs ajoutés ne peuvent qu’hériter de la sémantique des constructeurs définie dans le modèle noyau. Actuellement, cette sémantique, cablée dans le modèle noyau, ne peut pas être étendue automatiquement.

Par contre, le langage OntoQL permet de définir manuellement cette sémantique en utilisant les dif-férents langages qu’il propose. Par exemple, la sémantique du constructeur OWL HasValue est que les instances d’une telle restriction sont celles qui présentent une valeur donnée pour une propriété donnée. Nous avons vu que cette sémantique pouvait être représentée en créant une vue (cf. chapitre 3, sec-tion 4.3). De plus, comme le montre la figure 4.3, la définisec-tion de ces vues peut être automatisée. En effet, une requête OntoQL sur les ontologies peut être exprimée pour retrouver chaque restriction Has-Valueainsi que les informations permettant d’en créer l’extension, c’est-à-dire la propriété et la valeur sur laquelle elle porte. Pour chaque ligne du résultat, une instruction CREATE VIEW peut être générée pour créer l’extension de la restriction correspondante.

CREATE VIEW OF UserDurand AS SELECT * FROM User

WHERE last_name = 'Durand' CREATE VIEW OF ForumSioc AS

SELECT * FROM Forum WHERE has_host = 11 SELECT #name as of,

#onProperty.#scope.#name as from, #onProperty.#name as pred_g, #value as pred_d FROM #HasValue 11 has_host Forum ForumSioc Dupont last_name User UserDurand pred_d pred_d from of 11 has_host Forum ForumSioc Dupont last_name User UserDurand pred_d pred_d from of

F. 4.3 – Automatisation du calcul de l’extension des classes non canoniques HasValue Contrairement au langage SPARQL, qui est indépendant d’un modèle d’ontologies particulier mais qui les considère comme un ensemble de triplets, sans sémantique spécifique, le langage OntoQL se base sur un modèle noyau auquel une sémantique cablée est associée et qui peut être étendu via des instructions du langage.

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

OntoQL propose les principaux opérateurs de SQL92 pour permettre de manipuler les données au niveau logique d’une BDBO (cf. chapitre 3, section 2). A ce niveau, les données sont stockées dans un schéma résultant de l’implantation des extensions des classes. OntoQL permet de connaître les propriétés utilisées pour créer l’extension d’une classe (#usedProperties). Il permet également de forcer l’im-plantation de cette extension comme une représentation horizontale (cf. chapitre 3, section 3.3.2). Il ne permet pas, pour l’instant, de forcer une autre implantation.

Par rapport à CQL, la syntaxe du langage OntoQL permettant de manipuler les données au niveau logique respecte strictement celle de SQL. De plus, OntoQL distingue clairement l’accès au niveau on-tologique (à partir des classes) de l’accès au niveau logique (à partir des tables), alors que dans CQL, ces deux niveaux ne sont pas distingués.

Exigence 7 (Définition et manipulation des ontologies)

Deux langages permettent de créer les éléments d’une ontologie : le LDD (cf. chapitre 3, section 3.3) et le LMO (cf. section 2.4). L’avantage du LDD est de proposer la syntaxe habituelle de création d’un conteneur. Celui du LMO est d’offrir un pouvoir d’expression supérieur, étant lié au LIO. En particu-lier, l’instruction INSERT INTO SELECT permet de créer les éléments d’une ontologie dans une autre ontologie. Elle permet également de réaliser des transformations de modèles [Jean et al., 2007b].

Comparé au LDD proposé par RVL, OntoQL permet de définir la valeur de tous les attributs qui permettent de caractériser une classe et une propriété. RVL permet seulement de créer une classe en indi-quant son identifiant et ses super-classes. Pour les propriétés, il ne permet que de préciser son identifiant, ses éventuelles super-propriétés et son domaine et codomaine. De plus, OntoQL permet de créer d’autres éléments que des classes et des propriétés dans une ontologie (par exemple, les documents PLIB). Enfin, à notre connaissance, il est le seul à proposer un langage pour manipuler le modèle d’ontologies utilisé (cf. section 2.3). Ce langage permet d’ajouter de nouvelles entités (par exemple, les restrictions OWL) ou de nouveaux attributs (par exemple, les attributs note et remark de PLIB) à ce modèle d’ontologies.

Exigence 8 (Définition et manipulation des données)

OntoQL propose un langage de définition de données permettant de créer les classes et les propriétés selon une syntaxe similaire à celle de SQL (cf. chapitre 3, section 3.3). Il permet également d’associer des instances à ces classes. En OntoQL, une instance n’appartient qu’à une seule classe de base qui est canonique. Elle peut cependant appartenir à d’autres classes non canoniques via le mécanisme des vues. La manipulation de ces instances peut être faite avec un LMD similaire à celui de SQL (cf. chapitre 3, section 3.4). Ce LMD peut être utilisé pour mettre à jour une instance à partir de sa classe de base. Ces mises à jour sont alors automatiquement répercutées sur les classes non canoniques grâces au mécanisme de vue. Quand ces vues peuvent être mises à jour, le LMD peut aussi être utilisé pour mettre à jour une instance à partir des classes non canoniques (cf. chapitre 3, section 4.2). A nouveau, ces mises à jour sont répercutées sur les autres classes auxquelles elle appartient.

L’approche proposée par RUL est différente. Une instance peut appartenir à plusieurs classes de base sans que celles-ci n’aient un lien entre elles. RUL permet de manipuler une instance par rapport à une classe sans que cela n’ait de conséquence sur ses autres classes d’appartenance. Par exemple, une

instance peut être supprimée d’une classe sans qu’elle ne soit supprimée des autres classes auxquelles elle appartient. Pour cela, il propose de manipuler les instances à travers les liens d’instanciation. D’autre part, RUL sépare la manipulation d’une instance par rapport aux classes de la mise à jour de ses valeurs de propriétés en proposant deux instructions différentes.

Ces deux langages différent donc sur leur approche de la multi-instanciation qui permet de repré-senter différents points de vue possibles sur une instance. OntoQL permet la multi-instanciation via le mécanisme des vues. Par contre, il impose l’unicité de la classe de base afin que la structure possible d’une instance soit fixée et afin de permettre un stockage efficace de ces instances. Ce n’est pas le cas de RUL qui impose, en conséquence, que les instances soient manipulées et stockées indépendamment de leurs valeurs de propriétés.

Exigence 9 (Interrogation des ontologies)

Le langage OntoQL propose un langage d’interrogation pour les ontologies d’une BDBO, le LIO (cf. section 2.5). Ce langage propose les mêmes opérateurs que le LID permettant d’interroger les données à base ontologique. En conséquence, la comparaison entre le pouvoir d’expression de ce langage avec celui des autres langages proposés dans la littérature est la même que celle que nous avons faite pour le LID. Notons cependant, qu’en plus, il permet d’interroger les ontologies en utilisant des attributs dont le calcul nécessite un pouvoir d’expression supérieur à SQL. Ceci permet d’exprimer des requêtes typiques sur les ontologies comme par exemple rechercher les sous-classes (directes ou non) d’une classe ou rechercher les propriétés (définies ou applicables) sur une classe.

Exigence 10 (Interrogation à la fois des ontologies et des données)

OntoQL permet d’exprimer des requêtes portant à la fois sur les ontologies et sur les données. Pour naviguer dans une BDBO des ontologies vers les données, il permet d’utiliser des itérateurs à liaison dynamique (C AS i) afin de parcourir les instances d’une classe déterminée à l’exécution de la requête. De plus, il permet d’utiliser des propriétés déterminées à l’exécution d’une requête dans une projection (i.p). Pour naviguer des données vers les ontologies, OntoQL propose l’opérateur TYPEOF qui permet d’obtenir la classe de base d’une instance à partir de son identifiant. Cet opérateur peut ainsi être utilisé pour réaliser des jointures entre les éléments des ontologies et les instances des classes.

Le pouvoir d’expression proposé par OntoQL pour interroger à la fois les ontologies et leurs instances est inférieur à celui de RQL qui permet d’utiliser des expressions de chemins généralisées. Cette capacité permet notamment de construire une expression de chemin contenant plusieurs propriétés déterminées dynamiquement à l’exécution d’une requête. Par exemple, l’expression RQL @P.@P permet de rechercher les valeurs d’instances pour n’importe quelle expression de chemin de taille 2. L’expression de telles requêtes en OntoQL n’est pas possible. Néanmoins, le pouvoir d’expression qu’il propose s’est montré suffisant pour les projets dans lesquels nous l’avons utilisé.