Langage d’Interrogation des Ontologies (LIO)

Le LIO permet d’exprimer des requêtes sur les ontologies d’une BDBO. Ces requêtes sont construites de manière identique aux requêtes portant sur les données sauf que, dans ce cas, les entités et les attributs (noms précédés par # sauf utilisation de l’espace de noms particulier défini en section 2.2.1) sont utilisés à la place des classes et des propriétés.

2.5.1 Exemples de requêtes

Les entités et attributs utilisés dans les requêtes sont soit ceux du modèle d’ontologies noyau du langage OntoQL (cf. tableau 4.1), soit ceux ajoutés avec le LDO. Nous illustrons le langage obtenu par des exemples.

Exemple. Rechercher les espaces de noms des ontologies stockées dans la BDBO. SELECT #namespace FROM #Ontology

Explication. Les ontologies de la BDBO sont des instances de l’entité #Ontology. Les espaces de noms qu’elles définissent sont donnés par l’attribut #namespace. Pour retrouver les espaces de noms des ontologies de la BDBO, il suffit donc de réaliser la projection de l’entité #Ontology sur l’attribut #namespace.

Les opérateurs orientés-objets, introduits dans le langage permettant d’interroger les données au niveau ontologique, peuvent également être utilisés pour interroger les ontologies. L’exemple suivant montre l’utilisation d’une expression de chemin.

Exemple. Rechercher l’identifiant externe des propriétés de type référence vers les instances de la classe Post.

SELECT p.#code

FROM #Property AS p, #RefType AS t WHERE p.#range = t.#oid

AND t.#onClass.#code = ’Post’

Explication. Pour retrouver les propriétés de type référence, une jointure est réalisée entre les entités #Property, contenant les propriétés des ontologies, et #RefType, contenant les types référence. La classe utilisée par un type référence est indiquée par l’attribut #onClass. Une expression de chemin est construite à partir de cet attribut afin de ne garder que les types références portant sur la classe dont l’identifiant externe (#code) est Post.

Les valeurs des attributs peuvent être indiquées dans plusieurs langues naturelles. Une syntaxe iden-tique à celle utilisée pour les propriétés permet d’obtenir la valeur d’un attribut dans une langue naturelle donnée.

Exemple. Rechercher le nom en français et en anglais des classes et propriétés de l’ontologie SIOC. SELECT #name[FR], #name[EN]

FROM #Concept

WHERE #definedBy.#namespace = ’http://rdfs.org/sioc/ns’

Explication. L’entité #Concept regroupe les classes et les propriétés des ontologies. Pour ne retourner que celles appartenant à l’ontologie SIOC, une expression de chemin est utilisée à partir des attributs #definedBy, qui indique l’ontologie dans laquelle une classe ou une propriété est définie, et #name-spacequi indique l’espace de noms d’une ontologie. Le nom de chaque classe et de chaque propriété est retourné en français ([FR]) et en anglais ([EN]).

Ces exemples montrent que le langage OntoQL permet de découvrir les ontologies conservées dans une BDBO. Cependant, les attributs disponibles dans le modèle noyau ne sont pas toujours suffisants pour certaines requêtes, comme celles décrites dans la section suivante.

2.5.2 Attributs dérivés prédéfinis

Une requête typique portant sur les ontologies d’une BDBO consiste à rechercher l’ensemble des sous-classes (directes et indirectes) pour une classe donnée. Le langage OntoQL ne supportant pas la récursivité présente dans SQL mais qui n’est pas implantée dans tous les SGBD, cette requête ne peut être exprimée. De même, une autre requête usuelle consiste à rechercher les propriétés applicables (héritées et définies sur une classe donnée). Les requêtes de ce type ne peuvent être exprimées que très difficilement avec OntoQL. Pour permettre d’exprimer ce type de requêtes, nous avons ajouté des attributs prédéfinis à ceux issus du modèle d’ontologies noyau de OntoQL. Ces attributs sont dérivés à l’aide de fonction utilisateur. L’implantation du langage OntoQL sur une BDBO doit donc comprendre la définition des fonctions utilisateur permettant de calculer ces attributs. Par exemple, pour implanter le langage OntoQL sur la BDBO OntoDB qui utilise le SGBD PostgreSQL, nous avons défini ces fonctions avec le langage PL/PgSQL.

La liste des attributs dérivés prédéfinis, que nous avons décidé d’ajouter, est présentée dans le ta-bleau 4.2. Il indique, pour chaque attribut, l’entité sur laquelle il est défini ainsi qu’une description in-formelle de cet attribut. Nous avons ajouté des attributs facilitant le parcours de la hiérarchie de classes. Ainsi, l’attribut #superclasses permet d’obtenir les identifiants de toutes les super-classes d’une classe donnée et les attributs #directSubclasses et #subclasses, les identifiants de ses sous-classes di-rectes et indidi-rectes rangés dans un tableau. Nous avons également ajouté des attributs permettant de récupérer les identifiants des propriétés définies (#scopeProperties), applicables (#properties) et utilisées (#usedProperties) associées à une classe, également rangés dans un tableau.

Ces attributs sont utiles pour découvrir les ontologies d’une BDBO comme le montre les exemples suivants.

Attributs Domaine Définition informelle

#superclasses #Class Retourne les identifiants internes des super-classes (directes et indirectes) d’une classe donnée.

#directSubclasses #Class Retourne les identifiants internes des sous-classes directes d’une classe donnée (inverse de #directSuperclasses). #subclasses #Class Retourne les identifiants internes des sous-classes (directes et

indirectes) d’une classe donnée (inverse de #superclasses). #scopeProperties #Class Retourne les identifiants internes des propriétés définies sur

une classe donnée (inverse de #scope).

#properties #Class Retourne les identifiants internes des propriétés applicables (définies et héritées) sur une classe donnée.

#usedProperties #Class Retourne les identifiants internes des propriétés utilisées pour décrire les instances d’une classe donnée (propriétés présentes dans l’extension de la classe).

T. 4.2 – Les attributs dérivés prédéfinis SELECT csup.#name

FROM #Class AS c,

UNNEST(c.#superclasses) AS csup WHERE c.#name = ’Post’

Explication. L’opérateur UNNEST permet de dégrouper la relation contenant les classes par rapport à l’attribut #superclasses. Ceci permet d’obtenir un itérateur csup sur les super-classes de la classe sur laquelle l’itérateur c se trouve. Pour obtenir le nom de la super-classe courante il suffit donc de projeter la classe csup sur l’attribut #name.

Exemple. Rechercher le nom des propriétés utilisées sur la classe Post, ainsi que le nom de la classe sur laquelle ces propriétés ont été définies.

SELECT prop.#name, prop.#scope.#name FROM #Class AS c,

UNNEST(c.#usedProperties) AS prop WHERE c.#name = ’Post’

Explication. L’opérateur UNNEST est utilisé comme dans l’exemple précédent pour obtenir un itérateur (prop) sur les propriétés utilisées pour construire l’extension de la classe c. Cet itérateur est utilisé pour obtenir le nom de ces propriétés ainsi que le nom de leur domaine en utilisant une expression de chemin.

Exemple. Rechercher le nom des propriétés ainsi que le nom de leur type de données. SELECT p.#name,

CASE WHEN p.#range IS OF (REF(#StringType)) THEN ’String’ WHEN p.#range IS OF (REF(#IntType)) THEN ’Int’

WHEN p.#range IS OF (REF(#RefType)) THEN ’RefType’ ELSE ’Unknown’ END

FROM #Property AS p

Explication. L’attribut #range retourne une référence vers le type de données d’une propriété. Cette requête teste le type de cette référence (opérateur IS OF) et retourne une chaîne de caractères repré-sentant le type de données. Par exemple, si le type de données de la propriété p est un type référence (IS OF (REF(#RefType))), la chaîne de caractères ’RefType’ sera retournée.

2.5.3 Paramétrage du langage

Nous avons vu que les instructions OntoQL sont paramétrées par les espaces de noms et la langue naturelle utilisés. Ces paramètres sont également utilisés pour exploiter les ontologies.

2.5.3.1 Paramétrage par la langue naturelle utilisée

Commençons par la langue naturelle. Pour permettre d’exprimer une requête multilingue non seule-ment sur les données mais aussi sur les ontologies, les noms des entités et des attributs peuvent être définis dans plusieurs langues naturelles en utilisant la clause DESCRIPTOR.

Exemple. Rechercher le nom des propriétés utilisées sur la classe Post (Message en français), ainsi que le nom de la classe sur laquelle ces propriétés ont été définies en exprimant une requête en français. SELECT prop.#nom, prop.#domaine.#nom

FROM #Classe AS c,

UNNEST(c.#propriétésUtilisées) AS prop WHERE c.#nom = ’Message’

USING LANGUAGE FR

Explication. Cette requête a été exprimée en anglais dans la section précédente. Dans, cette exemple, la clause USING LANGUAGE permet d’indiquer que la requête est écrite en français. Les entités et attri-buts de cette requête sont ainsi identifiés par leur nom en français. Par exemple, l’attribut qui indique le domaine d’une propriété, nommé #scope en anglais, est indiqué par le nom #domaine. Ce langage s’applique également aux valeurs des attributs définis par une chaîne multilingue (’Message’).

2.5.3.2 Paramétrage par les espaces de noms utilisés

Considérons maintenant le cas des espaces de noms. Pour l’exploitation des données à base onto-logique, ces espaces de noms sont utilisés pour identifier les éléments d’une requête. Une possibilité serait que ces espaces de noms influencent également le résultat d’une requête. Cependant, donner deux sens à ce mécanisme nous a semblé une source de confusion. Donc, ce mécanisme peut être utilisé pour exploiter les ontologies seulement pour éviter de devoir utiliser le préfixe #.

Exemple. Rechercher les noms des classes de l’ontologie SIOC sans utiliser le préfixe #. SELECT c.name

FROM class AS c

WHERE c.definedBy.namespace = ’http://rdfs.org/sioc/ns’ USING NAMESPACE ’http://lisi.ensma.fr/ontoql’

Explication. L’espace de noms utilisé étant http://lisi.ensma.fr/ontoql, les éléments de cette requête sont considérés comme des entités et des attributs. Cette requête nécessite d’utiliser l’attribut #definedBypour ne rechercher que les classes de l’ontologie SIOC.

La présentation du LIO termine la description des traitements disponibles pour exploiter les gies d’une BDBO. Le langage OntoQL permet donc d’interroger d’un côté les données à base ontolo-gique et de l’autre, les ontologies d’une BDBO. Ceci laisse entrevoir la possibilité de combiner ces deux niveaux d’interrogation.

3 Interrogation conjointe des ontologies et des données

L’exigence 10 requiert que le langage permette d’interroger à la fois l’ontologie et les données. Cette exigence a été définie parce que le langage doit permettre d’une part de rechercher des classes avec leurs instances (ontologies vers données) et d’autre part d’effectuer des requêtes sur les instances en récupérant en même temps leur description ontologique (données vers ontologies).