(Section 1.4.1. du cours) TP Sol. – Exemples d'organisation de types de concepts

Reliez par un maximum de relations les termes (de types de concepts) 'Knowledge_management', 'Knowledge_engineering', 'DBMS', 'KBMS' et 'Information' tels que définis en cours, mais en n'utilisant que des relations ayant des types parmi les suivants : `subtype' (que vous pouvez abrévier par 's'), `exclusion' (alias, 'disjointWith' ; vous pouvez abrévier par 'e' ), `tool' et `input' (n'abréviez pas ; 'i' est l'abréviation de `instance').
... Utilisez la notation de votre choix et indiquez son nom.

FL :    Knowledge_management
          tool: 0..* DBMS,
          input: 0..* (Information exclusion: Knowledge_management),
          \. (Knowledge_engineering   tool: 0..* (KBMS exclusion: DBMS Knowledge_management) ).

Pour le "Circle-ellipse problem", quasiment toutes les méthodes "possibles" listées par la page Wikipidia pointée
ne passent pas à l'échelle car ce sont des "sur-représentations (par sur-restriction)"
(comme l'utilisation d'un booléen pour "Male, Female, ..." ; cf. page précédente).
La bonne représentation (celle qui distingue les différentes notions) est la suivante :

Mathematical_ellipse
 \. exclusion{ (Mathematical_circle  \. Circle_with_a_display_method) 
               (Mathematical_ellipse_that_is_not_a_circle   //2 distinct foci
                  \. Ellipse-that-is-not-a-circle_with_a_display_method) 
             }.

La plupart des méthodes "possibles" listées par la page Wikipidia pointéee ne passent pas à l'échelle car,
pensant que 2 classes sont suffisantes, ce que représentent leurs auteurs est ci-dessous (et c'est faux ; c'est de la "sur-representation") :

Ellipse-that-is-not-a-circle_with_additional_methods_for_display
 \. Circle_with_additional_methods_for_display.

Toutefois, les sections "Factor out common functionality into an abstract base class" (→ la 2.1.8 si les sections étaient numérotées),
la "(2.3) Challenge the premise of the problem" et la "(1.3) Allow for a weaker contract on Ellipse"

1. reconnaissent (directement ou non) le problème ; ce problème est aussi indiqué dans le 1er paragraphe de l'article : c'est la violation du "Liskov substitution principle" ou, plus clairement et complètement, de la sémantique d'un relation sous-classe),
2. s'approchent de la solution ci-dessus, sans toutefois être aussi clair et complet.
   • La classe "EllipseOrCircle" du 2.1.8 est la classe "Mathematical_ellipse" ci-dessus.
   • Dans le 2.3, c'est plus compliqué : la classe "OneDiameterFigure" du 2.3 semble être la classe "Circle_with_a_display_method" ci-dessus, et la classe "TwoDiameterFigure" semble être la classe "Ellipse-that-is-not-a-circle_with_a_display_method" mais la conclusion du 2.3 en fait une sous-classe de "OneDiameterFigure", ce qui n'est sémantiquement pas possible si cette dernière est bien "Circle_with_a_display_method" (toute ellipse n'est pas aussi un cercle, même si cela arrange le programmeur).
   • La 1.3 pointe aussi, très rapidement, le problème mais sa solution est très partielle : son titre est bon mais elle n'introduit pas de nouvelle classe en plus de Ellipse et Circle.

En conclusion, les "solutions possibles" recensées dans cette page Wikipedia (à part celles de la 2.1.8, mais sa description est incomplète) essaient de résoudre leur problème via des techniques de programmation (souvent compliquées) – ou en ignorant le cas général (comme dans la 1.3) – au lieu de simplement changer et compléter la modélisation des notions impliquées pour qu'elle soit correcte par rapport à la réalité (-> donc ici, correctement représenter par représenter la sémantique d'un cercle et d'une ellipse dans le cas général, puis représenter des sous-classes, et utiliser des relations de sous-classe correctes).

(Section 1.4.1. du cours) TP Sol. – Exemples d'organisation de types de concepts - Objet/symbole/phrase formel(le) ou non

Questions de contrôle (après réponse aux questions éventuelles des étudiants sur l'utilisation de "#" dans les sections 1.3.2 et 1.4.3) :
- en FE, FCG et RDF, les termes suivants sont-ils formels: "hat", pm#hat, hat%pm, pm:hat
- les termes suivants peuvent-ils (normalement, d'après leur nom en français) référer
  à un type de concept, à un type de relation, à un individu:
  "hat", pm#Paris, pm#person, pm#type_de_relation_transitive, pm#relation, wn#part.
- reliez les termes suivants par des relations de type  pm#instance,  pm#equal ('='),
  pm#subtype ('>')  et  pm#extended_specialization ('.>': toute relation de spécialisation qui
  n'est ni une relation sous-type, ni une relation instance):
    en#"city",   wn#city,   wn#capital,   en#"Paris",   wn#Paris___the_French_capital,
    pm#Paris_the_city_which_was_the_French_capital_in_2010,   pm#Paris_in_1860.
     

en#"city"
  .>  (en#"Paris"  .> wn#Paris___the_French_capital)
      (wn#city
         > (wn#capital
              pm#instance:
                (wn#Paris___the_French_capital 
                   =   pm#Paris_the_city_which_was_the_French_capital_in_2010,
                   .>  pm#Paris_in_1860  //the Paris of 1860
                )));


//if we assume that en#"Paris" refers to only 1 individual,
//                              the current French capital,
//then  en#"Paris" = wn#Paris___the_French_capital
//  and the above representation can be precised as follows:
en#"city"
  .>  (wn#city
         > (wn#capital
              pm#instance:
                (wn#Paris___the_French_capital 
                   =   pm#Paris_the_city_which_was_the_French_capital_in_2010
                       en#"Paris",
                   .>  pm#Paris_in_1860
                )));