Ontology Evolution and Source Autonomy in Ontologybased Data Warehouses

1
Ontology Evolution and Source Autonomy in
Ontology-based Data Warehouses

• Nguyen Xuan Dung nguyenx_at_ensma.fr
• Ladjel Bellatreche bellatreche_at_ensma.fr
• Guy Pierra pierra_at_ensma.fr

2
Contexte

• Sources de données
• Distribuées
• Hétérogènes (schématiques, sémantiques)
• Autonomes (indépendance de chaque source)

Decision Support
Programmes dapplications

• Besoins
• Intégration automatique de données
• Gestion de lévolution de données

Entrepôt de données
Bases de données
Bases de connaissances
Web
3
Contexte
Ontologie partagée (OP)
ontologie locale 1
ontologie locale i
ontologie locale
Source de données
Source de données
Source de données

• Hypothèses (pour une intégration automatique de
  données)
• Existence dune ontologie (de domaine)
  conceptuelle et partagée (OP).
• Chaque source possède une ontologie locale (O)
  qui référence OP.

• Problématique Chaque source et lontologie
  partagée peuvent évoluer indépendamment
• Gestion dévolution du contenu (schéma et
  population)
• Gestion dévolution de lontologie

4
Plan

• Approche dintégration a priori par articulation
  dontologies
• Historique dune instance de données
• Contraintes dévolutions de lontologie
• Versions flottantes de concepts ontologiques
• Conclusion

5
Base de données à base ontologique
Usual content of DB structure
OBDB structure

• Même support pour les données et lontologie
  BDBO ltO, I,Sch,Pop,Mgt

Ontology structure (meta-schema) (4)
Data structure (meta-base) (2)
O
Sch
Data meaning (ontology) (3)
Données (BDR, BDO, BDRO) (prescription)
DB content (data) (1)
Représentation de lontologie (description)
I
Pop
M
OP
6
Modèle PLIB

• Modèle classe/propriété pour lontologie de
  domaine
• Orienté caractérisation et non déduction
  (canonique, contient seulement des propriétés)
• Décrit, ne prescrit pas le schéma est un
  sous-ensemble de l ontologie
• Chaque propriété est typée classe ? co-domaine
• 2 relations de subsomption OOSub (héritage) et
  OntoSub (pas d héritage, mais importation)
• Référençable (UI) ? Multilingue,
• 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 lensemble 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
Exemple Ontologie PLIB BDBO
F C11 ltComposants, Partsgt
identification dun concept
noms associés à ce concept

• F C1 P11 ltfournisseur, suppliergt
• F C1 P21 ltgarantie, warrantygt

F C1 P21 ltgarantie, warrantygt
OOSub
code de propriété
code de classe
code de fournisseur
version
F C23 ltDisqueDur, HardDiskgt

• F C2 P11 ltcapacité, capacitygt
• F C2 P22 lttaille, sizegt

8
Architecture de notre système dintégration

• Entrées n BDBOs (Oi, Ii, Schi, Popi, Mi) OP
• Sortie 1 BDBO

Entrepôt de données

• Scénarii dintégration proposés
• FragmentOnto Oi ? OP
• ExtendOnto et ProjOnto
• chaque source définit sa Oi,
• ci ? Oi référence (par relation de subsomption)
  la plus petite classe subsumante de OP
  (manuellement).

Résolution conflits
Correspondance dontologie
BDBO S1
BDBO Sn
BDBO S2
9
Scénario ExtendOnto

• Extension de OP
• Pas de perte dinformation au niveau instances de
  données

BDBO2
a0, a1, a2
BDBO1
C1
a0 a1 a2 f
E
a1 a2 a3 e
F
C2
Ontologie partagée
Ontologie partagée étendue
a0, a1, a2, a3, a4
a0, a1, a2
C1
a0, a1, a2, a3, a4
C2
a1, a2, a3, e
E
a0, a1, a2, f
F
10
Exemple de lévolution asynchrone
OP 3
1. Comment les données de la S1 sont mises à jour
dans l entrepôt ?
2. Peut on accéder aux données de S1 à travers la
nouvelle version de OP ?
O12
11
Évolution de contenu

• Évolution de schéma ? reconnaître un composant
  (instance de données) même sil 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 lunion 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 lontologie
• trace du cycle de vie dinstances de données à
  travers un couple de propriétés
  (VersionMin,VersionMax)
• duplicata dinstance 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 lontologie

• Évolution asynchrone des différentes ontologies
  tout en conservant les relations inter-ontologies
• Principe de continuité dontologies ...tout
  axiome vrai pour une certaine version de
  lontologie 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é)

Ok ltCk,Pk,Subk,Applickgt version k de O
15
Modèle de gestionVersions flottantes de
concepts ontologiques

• Accéder aux données via une seule version de
  lontologie version courante
• la plus grande version connue dune classe (dune
  propriété),
• permettant dinterpréter toutes instances
  dentrepôt

16
Conclusion

• Intégration automatique par articulation
  dontologies
• 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 dhistorisation des ontologies