Le langage CQL associé au modèle d’ontologies PLIB

Le langage CQL a été conçu comme une extension de SQL pour les bases de données permettant de stocker des ontologies PLIB. Il présente ainsi la particularité d’avoir été conçu dans le soucis de conserver une compatibilité avec l’architecture des bases de données traditionnelles.

4.1.1 Présentation du langage CQL

CQL [Mizoguchi-Shimogori et al., 2002] est un langage développé au sein des laboratoires de re-cherche de TOSHIBA pour définir, manipuler et interroger des bases de données stockant une hiérarchie de classes. Les systèmes de gestion de données PLIB (PLIB-LMS) constituent une importante applica-tion de ce langage. En conséquence, sa concepapplica-tion a été influencée par le modèle d’ontologies PLIB. Notre présentation et évaluation de ce langage sont basées sur la version 2.0 des spécifications de ce langage diffusées à l’adresse http://www.toplib.com/En/aboutCQL.php.

CQL propose un langage de définition, manipulation et interrogation de données. Le langage de définition de données permet de créer des classes conformes au modèle PLIB. Une classe est créée en indiquant un des types de classe définis en PLIB comme par exemple Item_class. Elle possède un iden-tifiant unique qui s’obtient en concaténant l’ideniden-tifiant du dictionnaire dans lequel elle est définie avec l’identifiant de l’organisation qui l’a créée ainsi que son code. Par exemple, sioc_dic.sioc_org.Post est l’identifiant de la classe dont le code est Post, définie par l’organisation sioc_org dans le diction-naire sioc_dic. Pour simplifier l’écriture des exemples, nous utilisons l’expression sioc_org:Post comme identifiant de cette classe. La création d’une classe nécessite également d’indiquer la valeur de ses attributs. Les attributs disponibles sont similaires à ceux définis dans la norme PLIB (par exemple, definitionou applicable_properties).

Exemple. Créer une classe de type Item_class dont l’identifiant complet est sioc_dic.sioc_org.Po-st, dont le nom en anglais et en français est Posioc_dic.sioc_org.Po-st, dont la super-classe est Item et qui a comme propriétés applicables les propriétés title et content qui ont déjà été créées.

CREATE CLASS sioc_org:Post OF ITEM_CLASS ( SUPER_CLASS sioc_org:Item,

PREFERRED_NAME.FR ’Post’, APPLICABLE_PROPERTIES (

sioc_org:Post.title, sioc_org:Post.content ) )

Explication. La classe sioc_dic.sioc_org.Post (identifiant raccourci sioc_org:Post) est créée comme sous-classe de la classe Item en indiquant la valeur de l’attribut SUPER_CLASS. La définition de la valeur de l’attribut PREFERRED_NAME montre que CQL supporte les définitions multi-langues. Suivant la terminologie PLIB, l’attribut APPLICABLE_PROPERTIES permet d’indiquer les propriétés applicablespour les instances de cette classe, c’est-à-dire celles qui peuvent être utilisées pour décrire ces instances. Cet exemple suppose que ces propriétés ont déjà été créées. Ces propriétés sont iden-tifiées par rapport à leur classe de définition. Ainsi, la propriété title est identifiée par l’expression sioc_org:Post.title. Cette propriété étant définie dans le contexte de la classe sioc_org:Post, l’utilisation de l’identifiant complet des propriétés n’est pas nécessaire. Cependant, les auteurs de CQL ne précisent pas si le langage permet de n’utiliser que le code d’une propriété. Nous utilisons donc les identifiants complets.

Le langage de manipulation de données de CQL permet de créer des instances de classes. Pour cela, il requiert qu’une extension soit explicitement créée pour cette classe. Par exemple, l’expression suivante permet de créer une extension pour la classe User.

CREATE EXTENSION ON sioc_org:User;

Quand une extension a été créée, CQL permet ensuite de créer une table relationnelle pour stocker les instances de cette classe comme le montre l’exemple suivant.

Exemple. Créer une table de nom table_post pour stocker les instances de la classe Post. Cette table présente un attribut pour les propriétés title et content et la clé de cette table est l’attribut corres-pondant à la propriété title.

CREATE TABLE table_post ON sioc_org:Post ( sioc_org:Post.title,

sioc_org:Post.content,

CONSTRAINT KEY(sioc_org:Post.content ) )

Explication. La création de cette table se fait en indiquant son nom (table_post) ainsi que la classe correspondante (Post). Les colonnes de cette table sont définies par les propriétés à partir desquelles elles doivent être construites. Dans cet exemple, ce sont les propriétés title et content. La clé primaire de cette table peut être identifiée avec une syntaxe différente de celle de SQL (CONSTRAINT KEY).

Des instances peuvent ensuite être insérées dans cette table par une syntaxe similaire à SQL.

INSERT INTO table_post ON sioc_org:Post

(sioc_org:Post.title, sioc_org:Post.content )

VALUES (’Description de l’ontologie sioc’, ’L’ontologie SIOC ...’)

Explication. L’insertion d’une instance se fait en précisant la table dans laquelle les données sont in-sérées table_post. CQL nécessite également que la classe à laquelle cette table est associée soit indiquée (Post). Le nom des tables étant unique, préciser cette classe semble inutile. Les auteurs ne donnent pas d’explication à cette redondance syntaxique. Le reste de l’instruction est similaire à une instruction INSERT de SQL. Les propriétés valuées sont précisées avant le mot clé VALUES qui est suivi des valeurs de ces propriétés.

Le langage d’interrogation de CQL est décomposé en deux sous-langages : le langage d’interrogation des ontologies et le langage d’interrogation des données.

Une requête sur l’ontologie à la forme suivante : SELECT attribute₁, · · · , attributen

FROM entity₁, · · · , entity_m

WHERE exp_att₁ OP_log₁ exp_att₂ · · · OP_log_k exp_att_k+1 ORDER BY attribute₁, · · · , attributen

où :

– les attributei sont des attributs, tels que definition ou preferred_name, définis sur les classes et propriétés ;

– les entityi représentent une entité du modèle d’ontologies telle que Class, Property ou Sup-plier;

– les exp_attisont des expressions booléennes sur les attributs ;

– les OP_log_isont des opérateurs booléens (éventuellement parenthèsés). L’exemple suivant illustre l’utilisation de cette syntaxe.

Exemple. Retourner le domaine, le nom préféré en français ainsi que l’identifiant des propriétés dont le nom court en anglais se termine par name.

SELECT NAME_SCOPE, PREFERRED_NAME.FR, BSU_CODE FROM PROPERTY

WHERE SHORT_NAME.EN LIKE ’%name’;

Explication. Cet exemple montre que la syntaxe proposée par CQL est similaire à celle de SQL. La clause FROM permet d’introduire un itérateur sur les propriétés (mot clé PROPERTY). La clause WHERE permet de restreindre les propriétés parcourues à celles dont le nom court en anglais (mot clé SHO-RT_NAME) se termine par name. Pour chaque propriété restante, la clause SELECT permet de retrouver son domaine (NAME_SCOPE), son nom préféré en français (PREFERRED_NAME.FR) et son identifiant (BSU_CODE).

SELECT property₁, · · · , propertyn

FROM class_table₁, · · · , class_tablem

WHERE exp_prop₁ OP_log₁ exp_prop₂ , · · · , OP_log_k exp_prop_k+1 ORDER BY property₁, · · · , property_p

où :

– les propertyisont des identifiants de propriétés. Les fonctions d’agrégats (MIN, MAX, AVG et SUM) sont disponibles. La syntaxe * peut être utilisée pour obtenir la valeur de l’ensemble des propriétés applicables sur les classes présentes dans la clause FROM ;

– les class_tablei représentent des identifiants de classes suivis éventuellement du nom d’une table. Cet identifiant peut être suivi de l’opérateur * qui permet de référencer les instances de cette classe et de toutes ses sous-classes ;

– les exp_propisont des expressions booléennes sur les propriétés. Les opérateurs de quantification universelle ALL_OF et de quantification existentielle SOME_OF sont fournis pour les collections ; – les OP_logisont des opérateurs booléens (éventuellement parenthèsés).

Voici un exemple de requête sur les données.

Exemple. Retourner le contenu des messages dont le titre contient le mot sioc. SELECT sioc_org:Post.content,

FROM sioc_org:Post*

WHERE sioc_org:Post.title LIKE ’%sioc%’

Explication. La clause FROM de cette requête retourne les instances de la classe de code Post et de ses sous-classes. Une seule table étant associée à cette classe, il n’est pas nécessaire de préciser le nom de la table dans laquelle les instances sont recherchées. La clause SELECT retourne la valeur de la propriété content. La clause WHERE s’interprète comme pour une requête SQL classique. Elle permet donc de restreindre le résultat retourné aux messages dont la valeur de la propriété title contient le mot sioc.

En CQL, l’interrogation des ontologies et des données est ainsi clairement distinguée. Ce langage ne permet pas d’interroger conjointement les ontologies et les données d’une BDBO.

4.1.2 Analyse du langage CQL par rapport aux exigences définies

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

Le langage CQL permet d’exprimer des requêtes au niveau ontologique indépendamment des tables de la BDBO qui sont créées pour structurer ces données dans la BDBO (exigence 1). Par contre, il ne permet pas de définir des concepts non canoniques (exigence 2). L’aspect linguistique d’une ontolo-gie est pris en compte par CQL, d’une part, pour décrire les éléments d’une ontoloontolo-gie et, d’autre part, pour permettre la définition de valeur d’attributs dans différentes langues naturelles. CQL satisfait donc l’exigence 3. Notons cependant qu’il ne supporte pas le multilinguisme au niveau des données.

Au niveau du modèle d’ontologies supporté, le langage CQL est lié au modèle PLIB. En effet, la majorité des noms d’attributs et des noms d’entités PLIB sont définis comme des mots clés de ce langage et, aucune modification n’est possible dans ce modèle. CQL ne satisfait donc pas l’exigence 4.

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

Le langage CQL permet de définir des tables au niveau logique d’une BDBO pour stocker les ins-tances des classes (exigence 6). Ces insins-tances peuvent être recherchées à partir du nom de ces tables. La syntaxe proposée pour cela est proche de celle de SQL (exigence 5).

Exigences 7 et 8 (Définition et manipulation des ontologies et des données)

Le langage CQL propose un langage de définition et de manipulation de données permettant de créer des ontologies et de leur associer des instances selon l’hypothèse de typage ontologique fort. Il répond donc à l’exigence de pouvoir définir et manipuler les données d’une BDBO. Par contre, il ne permet pas de manipuler le modèle d’ontologies représentant les ontologies créées. Il répond donc partiellement à l’exigence de pouvoir définir et manipuler les ontologies d’une BDBO.

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

Le langage d’interrogation qu’il propose permet d’interroger des ontologies (exigence 9). Par contre, une distinction claire est faite entre l’interrogation des ontologies et l’interrogation des données. CQL ne permet ainsi pas d’effectuer des requêtes à la fois sur les ontologies et les données (exigence 10).

Exigences 11 et 12 (Implantation du langage)

Niveau implantation, à notre connaissance, aucune sémantique formelle n’a été associée au langage CQL (exigence 11). Par contre, la suite d’outils TopLib¹³a été développée pour faciliter et exploiter ce langage (exigence 12).

Synthèse et conclusion

Le tableau 2.3 synthétise l’analyse du langage CQL par rapport aux exigences définies.

Ainsi, le langage CQL présente la particularité de conserver un degré de compatibilité avec les bases de données traditionnelles. Il présente cependant les limitations principales suivantes par rapport à nos exigences :

– être lié au modèle PLIB. Le langage encode les différents éléments de ce modèle dans sa gram-maire ;

– séparer l’interrogation de l’ontologie et des données en deux langages distincts qui ne peuvent pas être combinés ;

– ne pas permettre la définition de concepts non canoniques ;

Exigences CQL

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.3 – Analyse du langage CQL par rapport aux exigences définies

– ne pas être fondé sur une sémantique formelle. Seule la syntaxe de CQL est définie dans ces spécifications, ce qui rend difficile de déterminer la sémantique des énoncés de ce langage. Lié au modèle PLIB, le langage CQL ne satisfait pas nos exigences. Dans la section suivante nous évaluons le langage SOQA-QL conçu pour être indépendant d’un modèle d’ontologies particulier.