Ontology Evolution and Source Autonomy in Ontology-based Data Warehouses

Nguyen Xuan Dung nguyenx@ensma.fr Ladjel Bellatreche bellatreche@ensma.fr Guy Pierra pierra@ensma.fr Ontology Evolution and Source Autonomy in Ontology-based Data Warehouses

Contexte Sources de données: • Distribuées • Hétérogènes (schématiques, sémantiques) • Autonomes (indépendance de chaque source) Decision Support Programmes d’applications 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

Intégration automatique Entrepôt Contexte Ontologie partagée (OP) ontologie locale 1 ontologie locale ontologie locale i Source de données Source de données Source de données 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. 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

Approche d’intégration a priori par articulation d’ontologies Historique d’une instance de données Contraintes d’évolutions de l’ontologie Versions flottantes de concepts ontologiques Conclusion Plan

Base de données à base ontologique Usual content of DB structure OBDB structure • Même support pour les données et l’ontologie: BDBO = <O, I,Sch,Pop,M> 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 l’ontologie (description) I Pop M OP

ModèlePLIB • Modèle classe/propriété: pour l’ontologie 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 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)

OntoSub S1 F1 | C1:2 <DisqueDur> • F | C1 | P1:1 • F | C2 | P1:1* • F | C2 | P2:2* propriétés importées Ontologie locale: O1 propriétés définies localement • F1 | C1 | P1:2* <série> • F1 | C1| P2:1 <garantie> Schéma: Sch1 série (F1 | C1 | P1:2) taille (F | C2 | P2:2) garantie (F1 | C1 | P3:1) capacité (F | C2 | P1:1) Instances : I1 … … … … Exemple: Ontologie PLIB & BDBO F | C1:1 <Composants, Parts> identification d’un concept noms associés à ce concept • F | C1 | P1:1 <fournisseur, supplier> • F | C1 | P2:1 <garantie, warranty> F | C1 | P2:1 <garantie, warranty> OOSub code de propriété code de classe code de fournisseur version F | C2:3 <DisqueDur, HardDisk> • F | C2 | P1:1 <capacité, capacity> • F | C2 | P2:2 <taille, size>

Entrées : n BDBOs (Oi, Ii, Schi, Popi, Mi) + OP • Sortie: 1 BDBO Architecture de notre système d’intégration Entrepôt de données • Scénarii d’intégration proposés : • FragmentOnto : Oi OP • ExtendOnto et ProjOnto : • chaque source définit sa Oi, • ci  Oiréférence (par relation de subsomption) la plus petite classe subsumante de OP (manuellement). Résolution conflits Correspondance d’ontologie BDBO S1 BDBO Sn BDBO S2

Extension de OP • Pas de perte d’information au niveau instances de données a2 a3 a2 a3 e f e f a1 a1 a1 a1 Scénario ExtendOnto 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

OP 4 F | C1:1 <Composants, Parts> F | C1:1 <Composants, Parts> • F | C1 | P1:1 <fournisseur, supplier> • F | C1 | P2:1 <garantie, warranty> • F | C1 | P1:1 <fournisseur, supplier> • F | C1 | P2:1 <garantie, warranty> Évolution de la description d’une classe F | C2:3 <DisqueDur, HardDisk> F | C2:4 <DisqueDur, HardDisk> • F | C2 | P1:1 <capacité, capacity> • F | C2 | P2:2 <taille, size> • F | C2 | P1:1 <capacité, capacity> • F | C2 | P2:3 <taille, size> • F | C2 | P3:1 <Interface,Interface> Évolution du co-domaine d’une propriété Sch11 F1 | C1:2 <DisqueDur> • F | C1 | P1:1 • F | C2 | P1:1* • F | C2 | P2:2* I11 Sch12 • F1 | C1 | P1:2* <série> • F1 | C1| P2:1 <garantie> série (F1 | C1 | P1:2) taille (F | C2 | P2:2) garantie (F1 | C1 | P2:1) capacité (F | C2 | P1:1) série (F1 | C1 | P1:2) taille (F | C2 | P2:2) capacité (F | C2 | P1:1) I12 … … … … … … … 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

É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 contenu • Évolution de population se souvenir à quelles périodes un composant était disponible

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

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

É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é) Ok  Ok+1 Ok+1 Ik Ik Évolution des ontologies: Principe de continuité de l’ontologie Ok = <Ck,Pk,Subk,Applick>: version k de O :

mettre à jour les articulations entre classes de l’ontologie de l’entrepôt: Version Courante Version courante C (version 3) C (version 3) C (version 2) Résultat Mise à jour C1 (version 2) C2 (version 1) C2 (version 1) C1 (version 2) Entrepôt Source Entrepôt Modèle de gestion:Versions flottantes de concepts ontologiques • Accéder aux données via une seule version de l’ontologie: version courante: • la plus grande version connue d’une classe (d’une propriété), • permettant d’interpréter toutes instances d’entrepôt

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 Conclusion

Ontology Evolution and Source Autonomy in Ontology-based Data Warehouses