Modèle de données du niveau ontologique, couche OCC

An niveau ontologique, le modèle de données est constitué des classes et des propriétés des onto-logies ainsi que des instances de ces classes. Conformément au noyau commun des différents modèles d’ontologies que nous avons défini au chapitre 1, section 3, ces classes et ces propriétés sont

identi-fiées indépendamment d’une BDBO en utilisant un espace de noms. Elles sont caractérisées par une description textuelle éventuellement multilingue et organisées dans une hiérarchie autorisant l’héritage multiple. Les instances de ces classes possèdent un identifiant et sont caractérisées par des valeurs de propriétés. Seules des contraintes de typage et de cardinalité peuvent être définies sur ces instances et leurs valeurs de propriétés. Nous n’avons pas inclus d’autres contraintes telles que l’unicité car peu de modèles d’ontologies permettent actuellement de définir ce type de contrainte.

Contrairement au niveau logique où les tables et les colonnes constituent un modèle structurel pour les instances, au niveau ontologique, les classes et les propriétés ne constituent qu’un modèle possible pour les instances. En effet, la structure des instances d’une classe peut n’être composée que d’un sous-ensemble des propriétés définies sur cette classe. Afin de permettre de manipuler cette structure (exi-gence 6), qui constitue l’aspect conceptuel des données (les éléments d’une ontologie utiles pour une application donnée), nous avons choisi de la représenter explicitement dans le modèle de données du niveau ontologique. Ainsi, chaque classe peut être liée à une extension qui stocke les instances de cette classe ainsi que leur caractérisation sous forme de valeurs de propriétés. L’extension d’une classe ne comprend que le sous-ensemble des propriétés qui sont utilisées pour en décrire les instances.

sioc:Post - oid - name - has_reply - has_container - title - content - note - has_creator

oid title has_creator

2 The SIOC ontology 10 … sioc:Item - oid - name - has_reply - has_container oid name

1 _{Logo de l’ontologie SIOC} … sioc=http://rdfs.org/sioc/ns “An article or message posted to a Forum” “Un article ou un message posté sur un forum”

“A Forum that a User is subscribed to” “Un forum auquel un utilisateur est abonné” oid subscriber_of [100, 101] email dupont@gabaro.com last_name dupont 10 sioc:User - oid - name - first_ame - last_name - email - subscriber_of

Représentation des instances des concepts : extension Représentation des concepts : caractérisation

F. 3.1 – Illustration du modèle de données du niveau ontologique

La figure 3.1 illustre une utilisation du modèle de données du niveau ontologique sur l’exemple de l’ontologie SIOC. Sur la partie gauche, nous avons représenté les classes Item, Post (sous-classe de Item) et User avec l’ensemble des propriétés définies et héritées par ces classes. Ces classes sont défi-nies dans l’espace de noms http://rdfs.org/sioc/ns dont l’alias est sioc. Ces classes et propriétés sont associées à une description. Sur cette figure, nous avons seulement indiqué un extrait de la des-cription textuelle associée à la classe Post et à la propriété subscriber_of. Chacune des classes est également associée à une extension représentée sur cette figure sous la forme d’une table. Chaque ex-tension comprend la propriété oid qui permet d’identifier les instances d’une classe de manière unique

ainsi que les propriétés utilisées pour décrire les instances.

Cet exemple montre que l’ensemble des propriétés applicables sur une classe n’est pas forcément utilisé pour en construire l’extension. Par exemple, l’extension de la classe User ne comprend pas les propriétés name et first_name. Il montre également que les propriétés des extensions ne sont pas né-cessairement héritées. Par exemple, la propriété name utilisée dans l’extension de la classe Item n’est pas présente dans l’extension de la classe Post sous-classe de la classe Item.

Comme le montre le tableau 3.7, le modèle de données du niveau ontologique présente des simi-litudes avec le modèle relationnel-objet. Dans ce dernier, des tables typées peuvent être créées à partir d’un type utilisateur pour en stocker les instances décrites par des valeurs d’attributs. Un type utilisateur correspond donc à une classe, une table typée à une extension et un attribut à une propriété. Les types utilisateur, comme les classes, sont organisés dans une hiérarchie (même si seul l’héritage simple est autorisé pour les types utilisateur).

Modèle relationnel-objet Modèle de données du niveau ontologique

Type utilisateur Classe

Attribut Propriété

Héritage simple entre types Héritage multiple entre classes

Table typée (ensemble des attributs) Extension (sous-ensemble des propriétés) Héritage de table

Référence d’objet Référence d’instance

Type primitifs Type primitifs

Type collection Type collection

Composition Méthode

Identification universelle des classes et des propriétés Description des classes et des propriétés

Type chaîne de caractères multilingues

T. 3.7 – Correspondances entre le modèle de données relationnel-objet et le modèle de données du niveau ontologique

Un autre point commun entre ces deux modèles est que chaque objet d’un type utilisateur, comme chaque instance d’une classe, possède un identifiant unique. L’ensemble des identifiants des objets d’un type T forme un type de données noté REF(T) (référence d’objet). Ces types de données peuvent éga-lement être construits à partir des classes. Une différence est que dans le modèle relationnel-objet une propriété de type REF(T) ne peut prendre ses valeurs que dans les tables typées correspondant au type T et non dans une de ses sous-tables. Sur l’exemple de l’ontologie SIOC, ceci imposerait que la propriété has_containerdéfinie sur la classe Item ne puisse prendre ses valeurs que dans la classe Container mais pas dans sa sous-classe Forum. Nous avons choisi de ne pas fixer cette contrainte sur les types références construits avec des classes d’une ontologie car elle se révélait trop contraignante pour di ffé-rents projets dans lesquels nous avons utilisé le langage OntoQL²¹. Bien entendu, ne pas imposer cette

contrainte engendre un coût sur le traitement des requêtes et sur la gestion de l’intégrité référentielle. Enfin, ces deux modèles de données supportent des types primitifs et des types collection. Dans le modèle du niveau ontologique, nous avons choisi de ne supporter que le type ARRAY qui permet de représenter la plupart des types collection disponibles dans les modèles d’ontologies.

Ce tableau montre également des différences entre ces deux modèles. Ces différences sont une consé-quence directe de la distinction que nous avons établie entre un schéma de base de données et une onto-logie. Ces différences sont les suivantes.

– Information incomplète. Une extension d’une classe d’une ontologie est similaire à une table typée associée à un type utilisateur dans le modèle relationnel-objet. Cependant, contrairement à un schéma de base de données qui prescrit les attributs qui caractérisent les instances d’un type utilisateur, une ontologie décrit les propriétés qui peuvent être utilisées pour décrire les instances d’une classe. En conséquence, alors qu’une table typée possède une colonne pour chaque attribut d’un type utilisateur, une extension d’une classe d’une ontologie peut ne contenir qu’un sous-ensemble des propriétés définies sur cette classe.

– Les relations de subsomption. Dans le modèle relationnel-objet, les attributs sont hérités selon la hiérarchie de types. Les tables typées étant définies à partir des attributs de leur type utilisateur, elles héritent également des attributs de leur super-table selon la hiérarchie de types. L’héritage entre tables peut être indiqué explicitement afin de permettre d’exprimer des requêtes qui portent sur une table ainsi que sur ces sous-tables.

Au niveau ontologique, les propriétés applicables sont distinguées des propriétés effectivement utilisées. Si les propriétés applicables sont héritées à travers la relation de subsomption comme dans le modèle de données relationnel-objet, ce n’est pas le cas de propriétés utilisées. Les classes peuvent être liées par une relation de subsomption sans exiger l’héritage des propriétés e ffecti-vement représentées. En conséquence, ce modèle ne permet pas de définir d’héritage entre les extensions. L’utilisation de classe offre ainsi beaucoup plus de flexibilité que l’utilisation de type utilisateur. C’est en particulier cette caractéristique qui est exploitée pour faciliter l’intégration d’informations [Nguyen-Xuan, 2006].

– Identification universelle des classes et des propriétés. Contrairement au modèle relationnel-objet où les identifiants des types utilisateurs ne sont uniques que dans le contexte d’une Base de Données Relationnelle-Objet (BDRO), les identifiants des classes et des propriétés sont définis dans le contexte d’un espace de noms permettant de référencer ces concepts à partir de n’importe quel environnement, indépendamment de la BDBO dans laquelle ils ont été définis.

– Description précise, éventuellement multilingue des classes et des propriétés. Les classes et les propriétés des ontologies sont associées à une description composée entre autre de noms et de définitions éventuellement définis dans plusieurs langues naturelles. Elles peuvent également être associées à de nombreux autres attributs et relations. Ces éléments permettent de définir pré-cisément les classes et les propriétés, ce qui est essentiel pour atteindre un consensus parmi une communauté.

Notons également que le modèle de données relationnel-objet présente des constructeurs qui ne sont pas supportés par les modèles d’ontologies. D’abord, ce modèle permet de définir plusieurs tables typées à partir d’un même type utilisateur. Actuellement, le modèle de données de OntoQL ne permet de définir

qu’une seule extension par classe. Nous verrons dans les perspectives d’évolutions du langage OntoQL présentées au chapitre suivant que c’est une extension prévue au langage OntoQL car cette capacité peut être particulièrement utile dans le contexte de l’intégration de données.

Un autre constructeur supporté par le modèle relationnel-objet mais absent de notre modèle de don-nées est la capacité de représenter des relations de composition en utilisant les types utilisateurs. En effet, un attribut dont le type de données est un type utilisateur T (et non REF(T)) représente une relation de composition (et non d’agrégation). En conséquence, les valeurs de cet attribut ne sont pas des objets possédant un identifiant. Ces valeurs sont supprimées en même temps que l’instance qu’elles décrivent. Cette relation est très peu représentée dans les modèles d’ontologies et nous ne l’avons donc pas inclue dans le modèle de données du niveau ontologique. Pour la même raison, nous n’avons pas permis la définition de méthodes sur les classes d’une ontologie ce qui est possible sur les types utilisateurs.

Dans cette section, nous avons présenté le modèle de données du niveau ontologique et montré qu’il présente des points communs avec le modèle relationnel-objet. Nous présentons maintenant des aspects syntaxiques du langage OntoQL qui permettent de manipuler les données à partir de ce niveau.