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

Contexte Distribuées Hétérogènes (schématiques, sémantiques) 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

Contexte Entrepôt Intégration automatique 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 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

Plan 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

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) Représentation de l’ontologie (description) DB content (data) (1) I Pop M OP

Modèle PLIB 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)

F | C1 | P2:1 <garantie, warranty> 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 fournisseur code de classe code de propriété F | C2:3 <DisqueDur, HardDisk> version F1 | C1:2 <DisqueDur> F1 | C1 | P1:2* <série> 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 F | C2 | P1:1 <capacité, capacity> F | C2 | P2:2 <taille, size> 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)

Architecture de notre système d’intégration 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  Oi référence (par relation de subsomption) la plus petite classe subsumante de OP (manuellement). Résolution conflits Correspondance d’ontologie BDBO S1 BDBO S2 BDBO Sn

Scénario ExtendOnto Extension de OP Pas de perte d’information au niveau instances de données Scénario ExtendOnto {a0, a1, a2} BDBO2 BDBO1 C1 E a0 a1 a2 f a1 a2 a3 e F C2 Ontologie partagée {a0, a1, a2, a3, a4} Ontologie partagée étendue a2 f a1 a3 e a1 {a0, a1, a2} C1 {a0, a1, a2, a3, a4} C2 {a1, a2, a3, e} E {a0, a1, a2, f} F a3 e a1 a2 f a1

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

É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

Deux solutions possibles 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

Notre solution: stockage implicite [+sauvegarde du schéma] 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 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é) Ok = <Ck,Pk,Subk,Applick>: version k de O : Ik Ik Ok  Ok+1  Ok+1

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 mettre à jour les articulations entre classes de l’ontologie de l’entrepôt: Résultat Version courante Entrepôt C (version 2) C1 (version 3) Source C2 (version 1) Mise à jour Entrepôt Version Courante C (version 3) C1 (version 2) C2 (version 1)

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