Jérôme GENSEL (avec la bénédiction… mais sans le contrôle de Cécile CAPPONI)

1. METEO : un système de types pour la représentation des connaissances par objets Jérôme GENSEL (avec la bénédiction… mais sans le contrôle de Cécile CAPPONI) un résumé de [CAPPONI98] Présentation équipe AROM du 01/04/99

2. Ce dont on va parler : types et RPO • Justifications • Tout est objet (et réciproquement) ? • Où sont les types ? • Metéo • Exploitation de Metéo • Conclusion

3. Ce dont on ne parlera pas • Détails techniques de l'implémentation du couplage Metéo/Tropes • Détails techniques de l'implémentation du couplage Metéo2/Java points à discuter avec Cécile les 8 et 9 avril prochains

4. Objectifs des systèmes de RPO 1) Permettre la représentation structurée et fidèle des connaissances issues d'une modélisation d'un domaine d'application - classes + instances - ordre partiel de spécialisation entre les classes 2) Favoriser l'exploitation homogène des connaissances représentées en vue d'en inférer de nouvelles - mécanismes d'inférences (classification, attachement procédural, filtrage, …)

5. Utilité d'un système de types 1) Vérification de cohérence d'une base de connaissances - classes + instances typées car attributs typés  vérifications de types Mais système de type RPO  systèmes de types classiques car - ensemble de valeurs évolutif - vérifications ensemblistes sur les domaines - redondances dans l'expression de ces domaines

6. Utilité d'un système de types 2) Ouverture vers la programmation - attributs typés car opérations utiles même en RPO - ouverture vers des composantes procédurales impliquant des types de données simples… et complexes (séquence, date, matrice, arborescence, …)

7. Utilité d'un système de types 2) Ouverture vers la programmation solution 1 : décrire ces types de données par des classes de la RPO - Situe au même niveau d'abstraction la classe gène (structure moléculaire biologique représentée) et la classe séquence (structure de données informatique) - pas de méthode... Cette solution n'en est pas une….

8. Utilité d'un système de types 2) Ouverture vers la programmation solution 2 : décrire et gérer ces types de données à l'aide un système de types - extensible - chargé de la complétude et de la correction des inférences et des vérifications de cohérence activées dans les bases de connaissances et impliquant les types de données associés aux attributs Solution adoptée !

9. Tout est objet (et réciproquement) ? 2 problématiques 1) vérifications de types et redondances 2) besoin de types de données externes

10. Vérifications de types et redondances - les vérifications de types impliquent les sous-ensembles de valeurs construits à l'aide des descripteurs des attributs Mais le langage de modélisation est volontairement expressif  1 domaine = multiples expressions syntaxiques

11. Vérifications de types et redondances Exemple : nombre-de-pattes $un entier $intervalle [0,8] $sauf {1,3,5,7} ou nombre-de-pattes $un entier $domaine {0, 2, 4, 6, 8}  Besoin de normaliser pour accélérer les décisions (attachement et spécialisation)

12. Vérifications de types et redondances • La normalisation - combiner les descripteurs et éliminer l'information redondante vers une expression unique d'un sous-ensemble de valeurs d'attribut - permet de conclure à l'égalité de 2 domaines • L'expression normalisée n'est pas stockée au niveau de la RPO (les utilisateurs souhaitent conserver leurs expressions)  recalculer ? NON ! Stocker au niveau du système de types - les expressions normalisées des ss-ens. de valeurs - la définition des opérations ensembliste de manipulation de ces expressions normalisées

13. Besoin de types de données externes • Seuls les types de base (du langage de programmation hôte) sont gérés par le SRPO • Pour les autres types de données  programmer en externe et référencer ?  déclarativité préservée…mais

14. Besoin de types de données externes Exemple Classe Gène-protéique sorte-de Gène attributs : promoteur $un Seq1 $card[2,6] codon-int $un Seq1 $card[3,3] $valeur ('T'.'A'.'C') seq-ARN $un Seq2 sib-exec Traduct(seq-cod) seq-cod ... Seq1, Seq2 : types de données développés en externe Traduct : méthode écrite en langage hôte manipulant des valeurs de types Seq1

15. Besoin de types de données externes Le problème… Seq1, Seq2 sont des boîtes noires pour le SRPO  pas d'interprétation des descripteurs de la RPO utilisés sur ces types  pas d'interprétation des descripteurs : card sur Seq1 ???  pas de vérification possible des résultats des méthodes Il faut permettre l'interprétation des descripteurs même lorsqu'appliqués à des types de données externes

16. Où sont les types ? Attributs - d'abord typés par un descripteur principal ($un, $ens, $liste) qui définit un type abstrait pour l'attribut - puis restreints par d'autres descripteurs qui définissent des ss-ens. de valeurs du type abstrait associé ($domaine,$sauf, $int, ..),

17. Où sont les types ? Attributs  2 niveaux de types 1) les types de données (réel, entier, …) 2) les sous-ensembles de valeurs spécifiés par l'utilisateur ([6.2, 14.3], {2, 5, 7}, …)  Les domaines des attributs sont manipulés par des opérations ensemblistes (, , , , …) utilisées pour l'attachement et la spécialisation

18. Où sont les types ? Classes - sa description peut être assimilée à un type record [Cardelli84] type record = fonction d'un ensemble non-ordonné d'étiquettes (les attributs) vers un ensembles de types (les domaines) - attachement et spécialisation se basent sur des opérations ensemblistes définies pour les types records Les opérations ensemblistes ont une sémantique commune indépendante de la nature du type de données référencé

19. Où sont les types ? En conclusion 2 niveaux de types 1) types de données (valeurs + opérations) 2) gestion des parties de ces types Structure algébrique des parties d'un type de données T = <V, O> (où V : ensemble de valeurs et O : ensemble d'opérations) <2V, E> où E contient plusieurs opérations ensemblistes

20. Cahier des charges du système de types Le système de types devra permettre : - l'ajout de types externes (non disponibles dans la RPO) - la gestion des parties de ces nouveaux types - l'expression normalisée d'ensembles de valeurs Rôles du système de types : 1) typer les descripteurs de connaissances 2) normaliser les types obtenus 3) assurer la persistance de ces types parallèlement aux entités auxquelles ils correspondent

21. Architecture du système de types Types de données Parties (intervalles, types records, …) Valeurs (entiers, valeurs records, …) Langage de Programmation relations Classes attributs intensions extensions Opérations ensemblistes Domaine d'application Instances valeurs d'attributs extensions Opérations sur les valeurs intensions Classification inférences Système de connaissances Système de types

22. Metéo Module Extensible de Types Elaborés pour les Objets 2 niveaux de types : 1) C-type : implémentation d'un type de données (donnée structurée + opérations) + implémentation des opérations ensemblistes 2) -type : expressions d'un sous-ensemble de valeur d'un C-type

23. Les C-types Un C-type T est défini, de façon minimale par 2 opérations : 1) T : U  {0,1} : prédicat d'appartenance d'une valeur quelconque de l'univers U à l'ensemble des valeurs de T 2) =T : T x T  {0,1} : prédicat d'égalité entre 2 valeurs de T + d'autres opérations selon les C-types Metéo définit une base minimale de C-type Exemple : le C-type Liste muni de l'opération map Ces opérations sont disponibles au sein du SRPO

24. Base hiérarchique de C-types Univers Types de base Construits Enumérés Ordonnés Collection Record Symbole Liste Ensemble Discrets Denses caractère Chaîne Réel Booléen Entier

25. EOLE EOLE : un langage interne d'expressions ensemblistes Il correspond au second niveau de types de Metéo Dédié à l'expression sous forme normale de sous-ensembles de valeurs issus des C-types A un ss-ens de valeurs (domaine d'attribut) ou de valeurs records (record de classe) est associé un ss-ens de valeurs de Metéo exprimé en EOLE Ces termes sont appelés des -types

26. Les -types A chaque C-type T = <VT, OT> est associé une structure algébrique <2VT, E> Metéo définit pour T, la syntaxe d'expression des éléments de 2VT et implémente :  , T : 2VT x T  {0,1} : appartenance  , T : 2VT x 2VT  {0,1} : inclusion  , T : 2VT x 2VT  2VT : plus grand minorant (intersection)  , T : 2VT x 2VT  2VT : plus petit majorant (union) / , T : 2VT x 2VT  2VT : différence

27. Les -types Les termes de EOLE sont -types t = <T, E(T)> où T est le C-type de rattachement de t, et E(T) une expression syntaxique normalisée  2 ensembles de valeurs égaux ont même -type les termes de EOLE comporte des champs Exemples de -types -type Discret 1 champ domaine liste ordonnée d'intervalles de valeurs à bornes fermées <Entier ; [6, 18]+[45, +Entier]> -type Construits plusieurs champs E(Liste) =<type-ref tL; domaine d1 ; sauf d2 ; card c> <Liste ; *<Entier ; [2, 8]>, TOUT, {(4, 5, 6) (4, 5, 7)};[2, +]>

28. -sous-typage et treillis de -types Les -types d'un même C-type sont partiellement ordonnés par -sous-typage (inclusion ensembliste issu de  , T) Opération implémentée pour chaque C-type par combinaison de conditions sur les champs d'expression des -types -type Discret : - sous-typage = test d'inclusion des listes d'intervalles

29. -sous-typage et treillis de -types -type Construits plus complexe t1=<Construits;[t'1;D1;S1]> et t2=<Construits;[t'2;D2;S2]> avec t'1=<T,E1(T)> et t'2=<T;E2(T)>

30. Treillis de -types et -sous-typage Les -types sont organisés en treillis à partir du -sous-typage, de  , T et de  , T Le -sous-typage permet de comparer des -types issus de C-types  mais liés par le C-sous-typage Exemple Pair et Entier si Pair  Entier grâce au -sous-typage, le -type <Entier; [2,5]+[10,13]> réécrit en <Pair;[2,4]+[10,12]> inclut le -type <Pair;[2;4]>

31. Interface RPO/Metéo Typage des entités de représentation 3 étapes 1) interprétation des descripteurs d'attributs vers les champs d'un -type typage des classes vers des -types records (étiquettes = noms des attributs ; types associés = liens vers les -types des attributs) 2) Normalisation des champs du -type obtenu à partir de la procédure de normalisation définie pour le C-type 3) insertion du -type dans le treillis issu de son C-type

32. Interface RPO/Metéo Hiérarchie de spécialisation Entier att1 $un chaîne att2 $un C' att3 $un entier att4 $un entier att5 $liste entier [-inf,+inf] [-inf,0]+[4,7]+[9,+inf] att2 $domaine(C'1,C'2) att3 $sauf (1,2,3,8) [-inf,0]+[7,7]+[11,+inf] att4 $int ]-inf,0],[4,+inf[ $sauf 8 att3 $int [-6,14] $sauf2 [-6,1]+[3,14] [11,14] att3 $sauf(4,5,6,8,9,10) att5 $parmi (11,12,13,14) $card [1,3] 

33. Extensibilité de Metéo Ajout dynamique d'un C-type - sélection d'un C-super-type - liens vers le code des opérations minimales (appartenance et égalité) et opérations exigées par le C-super-type Exemple (import-data-type Date Date hérite de Ordonné et Discret super-type : Discret (tri, minimum, gestion des parties) equal : dateq Metéo génère Liste(Date) et Ens(Date) member : datep order : ldate succ : +day pred : -day )

34. Extensibilité de Metéo Génération de l'implémentation de la structure algébrique des parties du nouveau type Exemple Date représentée par un triplet d'entiers (jj,mm,aaaa) la description de l'attribut period-exam $un Date $int [(13,05,1999) ; (20,05,1999)[ $sauf (18,05,1999), (19,05,1999) sera traduite par le -type <Date;[(13,05,1999),(17,05,1999)]>

35. Implémentation de Metéo Implémentation "objet" naturelle - les C-types sont des classes dont les attributs sont les champs de description du C-type. Les méthodes de ces classes sont les opérations ensemblistes de manipulation des -types, les fonctions associées au C-type (appartenance, égalité) - les -types sont les instances de ces classes (infos statiques pour le -sous-typage : sur--types, sous--types)

36. Exploitation de Metéo Délégation des opérations sur les descriptions - il existe dans Metéo l'équivalent des deux relations de base de la RPO (attachement et spécialisation)  effectuées sur les -types (normalisation + stockage)   efficacité dans les processus décisionnels - classification d'instances et de classes  classification dans les treillis de -types (amélioration : algorithme de Petko)  algos d'aide à la construction ou à la comparaison de bases de connaissances avec phases de vérification ou d'inférences couplage avec Metéo   efficacité

37. Exploitation de Metéo L'exemple du couplage Metéo/Tro(e)p(e)s : Metéo est également exploité pas - les notions de concepts, points de vue et passerelles - la révision dans les bases de connaissances (Crampé 97) - la catégorisation symbolique (Valtchev & Euzenat 95) - les outils pour la constructions de bases de connaissances consensuelles (Tayar 95) - les contraintes (Gensel 95)  proposition d' une fusion Metéo/Micro (Capponi & Gensel 97)

38. Conclusion Idée : reprendre les principes de Metéo (les étendre ?) et construire un système de types pour AROM Typage similaire pour classes et attributs Typage spécifique des relations ? Ce qui est sûr : le code Talk de Metéo n'est pas réexploitable directement du fait des grandes  entre l'approche objet Talk et l'approche objet Java qu'à cela ne tienne : Metéo 2 sera livré fin avril !

39. Poisson d'avril !!!