Laboratoire d’Informatique Scientifique et Industrielle

École Nationale Supérieure de Mécanique et d’Aérotechnique1, avenue Clément Ader - BP 40109 - 86961 Futuroscope cedex - France

Ontology Evolution and Source Autonomy

in Ontology-based Data Warehouses

Nguyen Xuan Dung nguyenx@ensma.frLadjel Bellatreche bellatreche@ensma.frGuy Pierra pierra@ensma.fr

2

Contexte

Decision SupportDecision Support ProgrammesProgrammesd’applicationsd’applications

Bases de Bases de connaissancesconnaissances

Bases deBases de donnéesdonnées

WebWeb

Sources de données:

Distribuées

Hétérogènes (schématiques,

sémantiques)

Autonomes (indépendance de chaque

source)

Entrepôt de données

Besoins

Intégration automatique de données

Gestion de l’évolution de données

3

Contexte

Hypothèses (pour une intégration automatique de données) :

Existence d’une ontologie (de domaine) conceptuelle et partagée (OP).

Chaque source possède une ontologie locale (O) qui référence OP.

Source de données

Source de données

Source de données

ontologie locale 1

ontologie locale i

ontologie locale

Ontologie partagée (OP)

Problématique : Chaque source et l’ontologie partagée peuvent évoluer indépendamment

Gestion d’évolution du contenu (schéma et population)

Gestion d’évolution de l’ontologie

Entrepôt

Intégration automatique

4

Plan

I. Approche d’intégration a priori par

articulation d’ontologies

II. Historique d’une instance de données

III. Contraintes d’évolutions de l’ontologie

IV. Versions flottantes de concepts ontologiques

V. Conclusion

5

Base de données à base

ontologique

Data structure (meta-base) (2)

DB content (data) (1)

Data meaning (ontology) (3)

Ontology structure (meta-

schema) (4)

Données (BDR, BDO, BDRO)

(prescription)

Représentation de l’ontologie

(description) Même support pour les données et l’ontologie: BDBO = <O, I,Sch,Pop,M>

OBDBstructure

Usual content of DB

structure

MOP

O

I

Sch

Pop

6

Modèle PLIB

Modèle classe/propriété: pour l’ontologie de domaine

1. Orienté caractérisation et non déduction (canonique, contient seulement des propriétés)

2. Décrit, ne prescrit pas: le schéma est un sous-ensemble de l ’ontologie

3. Chaque propriété est typée: classe co-domaine

4. 2 relations de subsomption: OOSub (héritage) et OntoSub (pas d ’héritage, mais

importation)

5. Référençable (UI) Multilingue,

6. Consensuelle (ISO-13584)

Modèle: pour les instances de classe

Tout composant (instance de classe):

– appartient à une classe de base (borne inférieure unique de l’ensemble des classes auquel

il appartient)

– est décrit par les valeurs des propriétés

– est identifié par une clé sémantique (un ensemble unique de valeurs des propriétés

choisies)

7

F1 | C1:2 <DisqueDur>

o F1 | C1 | P1:2* <série>o F1 | C1| P2:1 <garantie>

S1

F | C1 | P1:1 F | C2 | P1:1* F | C2 | P2:2*

propriétés importées

propriétés définies localement

Ontologie locale: O1

OntoSub

Schéma: Sch1

Instances : I1

capacité(F | C2 | P1:1)

…

taille(F | C2 | P2:2)

………

garantie(F1 | C1 | P3:1)

série(F1 | C1 | P1:2)

Exemple: Ontologie PLIB & BDBO

identification d’un concept noms associés à ce concept

F | C1 | P2:1 <garantie, warranty>

code de fournisseur

code de propriété

code de classe version

F | C1:1 <Composants, Parts>

F | C2:3 <DisqueDur, HardDisk>o F | C2 | P1:1 <capacité, capacity>o F | C2 | P2:2 <taille, size>

OOSub

o F | C1 | P1:1 <fournisseur, supplier>o F | C1 | P2:1 <garantie, warranty>

8

Architecture de notre système d’intégration

Résolutionconflits

Correspondance d’ontologie

BDBO S 1

BDBO S n

BDBO S 2

Entrepôt de données Entrées : n BDBOs (O i, I i, Sch i, Pop i,

M i) + OP

Sortie: 1 BDBO

Scénarii d’intégration proposés :

FragmentOnto : O i OP

ExtendOnto et ProjOnto :

• chaque source définit sa O i,

• c i O i référence (par relation de

subsomption) la plus petite classe

subsumante de OP (manuellement).

9

Scénario ExtendOnto

a1 a2 a3 e

BDBO 1

Ontologie partagée

E

a0 a1 a2 f

BDBO 2

F

C1

{a0, a1, a2}

C2

{a0, a1, a2, a3, a4}

C1{a0, a1, a2}

C2 {a0, a1, a2, a3, a4}

E F{a1, a2, a3, e} {a0, a1, a2, f}

Extension de OP

Pas de perte d’information au niveau instances de données

Ontologie partagée étendue

a3 ea1 a2 fa1

a3 ea1 a2 fa1

10

OP 3

Exemple de l’évolution asynchrone

F1 | C1:2 <DisqueDur>

o F1 | C1 | P1:2* <série>o F1 | C1| P2:1 <garantie>

F | C1 | P1:1 F | C2 | P1:1* F | C2 | P2:2*

Sch11

capacité(F | C2 | P1:1)

…

taille(F | C2 | P2:2)

………

garantie(F1 | C1 | P2:1)

série(F1 | C1 | P1:2)

F | C1:1 <Composants, Parts>

F | C2:3 <DisqueDur, HardDisk>o F | C2 | P1:1 <capacité, capacity>o F | C2 | P2:2 <taille, size>

o F | C1 | P1:1 <fournisseur, supplier>o F | C1 | P2:1 <garantie, warranty>

I11

O12

F | C1:1 <Composants, Parts>

F | C2:4 <DisqueDur, HardDisk>o F | C2 | P1:1 <capacité, capacity>o F | C2 | P2:3 <taille, size>o F | C2 | P3:1 <Interface,Interface>

o F | C1 | P1:1 <fournisseur, supplier>o F | C1 | P2:1 <garantie, warranty>

Évolution du co-domaine

d’une propriété

Évolution de la description d’une classe

OP 4

1. Comment les données de la S1 sont mises à jour dans l ’entrepôt ?

capacité(F | C2 | P1:1)

…

taille(F | C2 | P2:2)

……

série(F1 | C1 | P1:2)

Sch12

I12

2. Peut on accéder aux données de S1 à travers la nouvelle version de OP ?

11

Évolution de contenu

• Évolution de schéma reconnaître un

composant (instance de données) même s’il

est décrit par des propriétés un peu

différentes (une propriété peut être ajoutée /

supprimée)

• Évolution de population se souvenir à

quelles périodes un composant était

disponible

12

Modèle de gestion:

Représentation des historiques des instances: Solutions

existantes

Deux solutions possibles Stockage explicite: toutes les versions de chaque table sont stockées

+ facile à mettre en œuvre

- coût de stockage, traitement de requêtes nécessitant un parcours sur

les versions différentes

Stockage implicite : une seule version dont le schéma est obtenu en

faisant l’union de toutes les propriétés figurant dans les différentes

versions

+ éviter le parcours de plusieurs versions d ’une table, réduire le coût de

stockage

- calcul automatique du schéma de stockage, trace du cycle de vie de

données, ambiguïté de la sémantique des valeurs nulles

13

Modèle de gestion:

Représentation des historiques des instances: Notre

solution

Notre solution: stockage implicite [+sauvegarde du schéma]

calcul du schéma de stockage automatique grâce à la présence de

l’ontologie

trace du cycle de vie d’instances de données à travers un couple de

propriétés: (VersionMin,VersionMax)

duplicata d’instance de données évité par son UI (UI du fournisseur, UI de

la classe de base et la clé sémantique)

précision de la sémantique des valeurs nulles grâce à la sauvegarde du

schéma

14

Évolution des ontologies: Principe de continuité de l’ontologie

• Évolution asynchrone des différentes ontologies tout en conservant les

relations inter-ontologies

Principe de continuité d’ontologies: «...tout axiome vrai pour une certaine

version de l’ontologie restera vrai pour toutes les versions ultérieures»

Évolution de classes :

– ajouter des classes

– ajouter des propriétés

Évolution de propriétés

– co-domaine (extension de domaine de valeur d ’une propriété)

Ik Ik

Ok Ok+1 Ok+1Ok = <Ck,Pk,Subk,Applick>: version k de O :

15

Modèle de gestion:

Versions flottantes de concepts ontologiques

Accéder aux données via une seule version de l’ontologie: version

courante:

1. la plus grande version connue d’une classe (d’une propriété),

2. permettant d’interpréter toutes instances d’entrepôt

mettre à jour les articulations entre classes de l’ontologie de l’entrepôt:

Résultat

Version courante

Entrepôt

C

(version 2)

C1

(version 2)

C

(version 3)

Source

C2

(version 1)

Mise à jour

Entrepôt

Version Courante

C

(version 3)

C1

(version 2)

C2

(version 1)

16

Conclusion Intégration automatique par articulation d’ontologies

Problème d’évolution:

Contenu:

reconnaissance des instances, malgré le schéma évolutif,

tracibilité du cycle de vie par versionning [option]

Ontologie:

problème majeur: évolution asynchrone

solution proposée: basant sur le principe de continuité

d ’ontologies,

implémentation: modèle des versions flottantes ne pas

nécessaire d’historisation des ontologies