Modèle de données permettant de représenter les ontologies

Le modèle de données permettant d’exploiter les ontologies stockées au niveau ontologique de l’ar-chitecture ANSI/SPARC étendue est constitué de l’ensemble des constructeurs du modèle d’ontologies utilisé. Or, ce modèle de données ne doit pas être spécifique d’un modèle d’ontologies particulier (exi-gence 4). Deux approches sont possibles. La première consiste à définir un modèle de données figé contenant l’ensemble des constructeurs des différents modèles d’ontologies. Le langage SOQA-QL a suivi cette approche. Cependant, vu la quantité et la diversité des constructeurs fournis par les modèles d’ontologies, seuls les constructeurs importants ont été inclus dans le modèle de données de SOQA-QL. En conséquence, cette approche ne permet pas de prendre en compte les constructeurs spécifiques d’un modèle d’ontologies donné (cf. chapitre 2, section 4.2.2).

La seconde approche est duale à la première. Elle consiste à définir un modèle de données exten-sible ne contenant initialement que les constructeurs partagés par les modèles d’ontologies. Cette ap-proche n’est intéressante que lorsque l’ensemble des constructeurs partagés est important. Or, nous avons constaté dans le chapitre 1, section 3, que c’est le cas pour les modèles d’ontologies. Nous nous propo-sons donc de construire le langage OntoQL sur un modèle d’ontologies noyau contenant cet ensemble de constructeurs puis de définir des mécanismes permettant des extensions de ce modèle.

2.1.1 Le modèle d’ontologies noyau du langage OntoQL

La figure 4.1 présente les éléments de ce modèle d’ontologies noyau sous la forme simplifiée d’un modèle UML. Voici une description des éléments de ce modèle.

– Une ontologie (Ontology) définit un domaine d’unicité des noms (namespace). Elle regroupe la définition d’un ensemble de concepts : des classes et des propriétés.

– Une classe (Class) possède un identifiant interne à la BDBO (oid) et un identifiant indépendant de celle-ci (code). Sa définition comporte une partie textuelle (name, definition), éventuel-lement donnée dans plusieurs langues naturelles (MultilingualString). Ces classes sont or-ganisées selon une structure de graphe acyclique qui représente les relations d’héritage multiple (directSuperclasses).

– Les propriétés (Property) possèdent également un identifiant (interne et externe) et une partie textuelle éventuellement définie dans plusieurs langues naturelles. Chacune des propriétés doit être définie sur la classe ou sur l’une des super-classes des instances qu’elle décrit (scope). Chaque propriété a un codomaine (range) qui permet de contraindre son domaine de valeurs. – Le type de données (Datatype) d’une propriété peut être un type simple (PrimitiveType) tel

que le type entier (IntType) ou le type chaînes de caractères (StringType). Une propriété peut également prendre ses valeurs dans une classe en faisant référence à ses instances (RefType). Il n’y a donc pas de composition. Enfin, cette valeur peut être une collection dont les éléments sont soit de type simple soit des références à des instances d’une classe (CollectionType).

Ce modèle noyau est soumis aux contraintes suivantes :

– les cycles dans la hiérarchie de subsomption sont interdits.

Nous avons introduit ces contraintes car elles sont en particulier définies dans le modèle PLIB. Notons qu’elles sont également introduites dans le modèle de données exploité par le langage RQL.

Ontology namespace: String Concept oid: Int code: String name: MultilingualString definition: MultilingualString definedBy 1 Class Property scope 1 Datatype range 1 RefType onClass 1 PrimitiveType CollectionType maxCardinality: String ofDatatype 1 directSuperclasses 0..* BooleanType NumberType

StringType DateType ArrayType

IntType RealType MutlilingualStringType

F. 4.1 – Le modèle d’ontologies noyau du langage OntoQL

2.1.2 Extensions du modèle d’ontologies noyau

L’extension du modèle noyau doit permettre d’ajouter des constructeurs proposés par un modèle d’ontologies particulier (dimension structurelle) et, autant que possible, permettre d’associer une séman-tique à ces nouveaux constructeurs (dimension sémanséman-tique). Ces extensions doivent également préserver les contraintes que nous avons imposées sur le modèle noyau.

2.1.2.1 Dimension structurelle de l’extension du modèle noyau

Les constructeurs du modèle noyau étant représentés par des entités et des attributs, l’ajout de nou-veaux constructeurs consiste à étendre le modèle noyau par de nouvelles entités et de nounou-veaux attributs.

Exemple. La figure 4.2 présente l’ajout des constructeurs de restrictions OWL AllValuesFrom et Some-ValuesFrom(partie grisée de la figure) au modèle d’ontologies noyau de OntoQL (partie non grisée).

Class Property scope 1 Restriction SomeValuesFromRestriction AllValuesFromRestriction onProperty 1 allValuesFrom 1 someValuesFrom 1

F. 4.2 – Exemple d’extensions du modèle d’ontologies noyau du langage OntoQL

sont caractérisées par les valeurs qu’elles prennent pour une propriété donnée. Pour représenter la notion de restriction dans le modèle d’ontologies noyau, nous avons introduit l’entité Restriction. Cette entité hérite de l’entité Class. De cette manière, chaque instance de cette entité sera consi-dérée comme une classe. Elle possède un attribut onProperty qui indique la propriété sur laquelle porte une restriction. Les constructeurs AllValuesFrom et SomeValuesFrom sont deux construc-teurs de restriction. Ils ont donc été introduits dans le modèle noyau comme deux nouvelles entités héritant de Restriction (et donc également de l’attribut onProperty). Les instances d’une res-triction AllValuesFrom (respectivement SomeValuesFrom) ne doivent prendre comme valeurs de la propriété indiquée par l’attribut onProperty que des instances (respectivement au moins une ins-tance) d’une classe donnée. Cette classe est indiquée par l’attribut allValuesFrom (respectivement someValuesFrom).

Les constructeurs d’un modèle d’ontologies peuvent ainsi être ajoutés au modèle noyau. Cette tâche peut même être automatisée pour les modèles d’ontologies pour lesquels un méta-modèle a été défini. C’est le cas pour le modèle PLIB dont le méta-modèle est défini en EXPRESS dans les normes ISO 13584 et également pour les modèles RDF-Schema et OWL dont un méta-modèle en UML a été défini par l’OMG dans [ODM, 2006]. Ainsi, la capacité d’extension du modèle noyau permet de représenter dans une BDBO l’ensemble des descriptions données dans une ontologie et ceci, quel que soit le modèle d’ontologies avec lequel elles sont définies.

2.1.2.2 Dimension sémantique de l’extension du modèle noyau

Considérons maintenant le problème plus délicat d’associer une sémantique aux extensions intro-duites. Lorsque cette extension est obtenue par spécialisation, les nouvelles entités héritent du compor-tement de leurs super-entités. Ce comporcompor-tement est défini dans la sémantique opérationnelle du modèle noyau. Ainsi, toute spécialisation de l’entité Class définit une nouvelle catégorie de classes, mais celles-ci conservent, par héritage, le comportement usuel d’une classe. Toute instance de l’entité Class (ou d’une quelconque spécialisation) définit un conteneur susceptible d’être associé à des instances. Le nom de ce conteneur est généré par une fonction dite de concrétisation qui permet d’y accéder à partir de sa re-présentation dans le modèle d’ontologies. De même, toute spécialisation de l’entité Property définit des relations associant des instances de classes à des domaines de valeurs. Le nom de ces relations est

égale-ment dérivé des instances de propriétés qui les définissent. Enfin, les spécialisations de l’entité Datatype définissent des domaines de valeurs permettant de typer des propriétés. L’héritage permet donc d’asso-cier la sémantique définie dans le modèle d’ontologies noyau aux nouveaux constructeurs. Par contre, il ne permet pas de leur en associer une nouvelle. Ainsi, une restriction OWL AllValuesFrom pourra être associée à des instances (héritage du comportement d’une classe). Par contre, ceci n’indique pas que ces instances peuvent être dérivées à partir d’une requête OntoQL. Nous verrons cependant que les différents langages proposés par OntoQL offrent une solution pour définir cette sémantique (cf. section 4.1).

Ce n’est, par contre, pas le cas pour les attributs qui peuvent être ajoutés au modèle noyau. Par exemple, la sémantique des qualificatifs de propriétés introduits par OWL (inverse, symétrique et tran-sitive) ne peut pas être définie. OntoQL ne permet pas non plus d’associer une nouvelle sémantique aux types de données ajoutés (entité héritant de Datatype). Ainsi les types de données numériques PLIB associés à des unités de mesure (par exemple, int_measure_type) seront traités comme des types nu-mériques classiques alors qu’ils nécessitent d’en redéfinir les opérateurs pour prendre en compte l’unité de mesure. Proposer une solution à ces limitations fait partie de nos perspectives de travail (cf. conclusion finale).

2.2 Aspects syntaxiques

Le langage OntoQL doit permettre d’exploiter les ontologies d’une BDBO en se basant sur le modèle de données que nous venons de présenter. La syntaxe de ce langage doit donc prendre en compte le fait que ce modèle de données n’est pas figé tout en permettant de distinguer les traitements portant sur les données à base ontologique de ceux portant sur les ontologies.

2.2.1 Distinction des traitements portant sur les ontologies de ceux portant sur les données

Puisque le modèle d’ontologies noyau sur lequel le langage OntoQL est basé n’est pas statique, mais qu’il peut être étendu, les éléments de ce niveau de modélisation ne peuvent pas être codés comme des mots clés de sa grammaire. Donc, nous avons dû définir une convention permettant de reconnaître dans la grammaire un élément du modèle d’ontologies à partir de son seul nom. La convention que nous avons choisie est de préfixer chaque élément de ce modèle par le caractère #. Ce préfixe permet de savoir que la définition de cet élément doit être insérée ou recherchée dans le modèle d’ontologies éventuellement étendu du langage OntoQL. Ceci permet donc de distinguer la manipulation des données de la manipula-tion des ontologies. Notons que, bien que la même convenmanipula-tion soit utilisée pour les éléments du modèle noyau, les noms de ces éléments (par exemple, #Class) sont en fait des mots-clés qui ne peuvent pas être changés car ils font l’objet d’une interprétation sémantique pré-définie.

Par contre, le préfixe # peut être jugé peu commode. Pour ne pas imposer l’utilisation de ce préfixe, le langage OntoQL permet d’utiliser un espace de noms prédéfini http://lisi.ensma.fr/ontoql. Un élément de cet espace de noms est considéré comme un élément du modèle d’ontologies. Et donc, lorsque cette espace de noms est défini par défaut ou qu’il est précisé dans une requête, il n’est pas nécessaire de préfixer les éléments du modèle d’ontologies par #.

2.2.2 Utilisation des identifiants des éléments ontologiques

Lorsque l’on observe la figure 4.1, on constate que de nombreux attributs du modèle d’ontologies noyau sont de type référence. Les valeurs de ces attributs sont des identifiants internes d’ontologies, de classes, de propriétés ou de types de données. Ces identifiants étant des entiers, attribuer une valeur à ces attributs nécessite d’exprimer des requêtes pour les rechercher. Or, les ontologies, les classes, les propriétés et les types de données peuvent être identifiés plus simplement :

– les ontologies par leur espace de noms ;

– les classes et les propriétés par leur identifiant externe et/ou leur nom préféré ; – les types de données par leur nom.

Il serait donc particulièrement utile que ces identifiants puissent être utilisés pour attribuer une valeur aux attributs de type référence.

Les identifiants internes sont des entiers (syntaxe sans ’ ’) tandis que les identifiants externes évo-qués précédemment sont des chaînes de caractères (syntaxe avec ’ ’). Ces deux types d’identifiants peuvent donc être distingués dans la syntaxe OntoQL. En conséquence, ils peuvent tous deux être utili-sés pour définir la valeur d’attributs de type référence.

Les mécanismes syntaxiques définis dans cette section sont utilisés par les langages qui permettent de manipuler les ontologies d’une BDBO. Notre but étant que la syntaxe du langage OntoQL soit uni-forme pour les différents niveaux d’accès à une BDBO, nous nous sommes à nouveau basés sur les instructions de manipulation des types utilisateurs de SQL pour définir ces langages. Mais, cette fois-ci, le modèle de données considéré ne présente pas de différence majeure avec le modèle relationnel-objet. En effet, la seule différence entre une entité et un type utilisateur est que les entités peuvent être organi-sées dans une hiérarchie supportant l’héritage multiple (nécessaire, en particulier, pour le modèle PLIB). Les instructions proposées par OntoQL pour manipuler les ontologies restent donc similaires à celles de manipulation des types utilisateurs.