-1.g. @@ Tâches dites "de gestion de connaissances" et leurs supports (SGC, SGBC, SBC)

Connaissance tacite: connaissance qui n'est pas explicite, i.e., qui n'a pas été décrite précisément dans un document ou un SGBC. Certaines connaissances, comme les savoir-faire et la reconnaissance de situations ou d'objets (visages, écriture, ...), sont difficiles à décrire ou définir précisément et donc à représenter. En psychologie cognitive, cette distinction se retrouve dans la distintion entre mémoire procédurale et mémoire déclarative.

"Gestion des connaissances" (au sens des industriels) [knowledge management]: ensemble des techniques permettant de collecter/extraire, analyser, organiser et partager des informations, le plus souvent à l'intérieur d'une organisation, e.g., les connaissances importantes d'un employé (carnet d'adresses, trucs/expertise, etc.) avant qu'il ne parte à la retraite.
Ces informations sont généralement stockées sous la forme de documents informels, très rarement via des représentations de connaissances, du moins jusqu'à présent.
Un outil permettant une telle gestion est un système de gestion de connaissances (SGC) [knowledge management system (KMS)].

"Gestion|ingénierie des connaissances" (au sens des universitaires) [knowledge engineering]: ensemble des techniques permettant de collecter/extraire, représenter, organiser et de partager des représentations de connaissances.
Un système de gestion de BC (SGBC) [KB management system (KBMS)] est un des outils permettant une telle gestion. D'autres outils sont ceux de collection/extraction et analyse de connaissances qui aident à créer un SGBC.

Système à base de connaissances (SBC): tout outil exploitant des représentations de connaissances par exemple pour résoudre certains problèmes. Techniquement, un SGBC est aussi un SBC mais est rarement classé en tant que tel. Les systèmes experts sont des SBCs mais ne sont pas forcément basés sur des "connaissances profondes" (représentations détaillées de connaissances nécessaires à un raisonnement).

Gestion de contenu [Enterprise Content Management (ECM)] : prendre en compte sous
forme électronique des informations qui ne sont pas structurées, comme les
documents électroniques, par opposition à celles déjà structurées dans les SGBD. Ceci peut
être vu comme un cas particulier de "gestion des connaissances, au sens des industriels".
De plus, si des métadonnées "précises" sont utilisées pour indexer les documents,
"gestion de contenu" implique aussi des tâches d'ingénierie des connaissances".

Le terme "contenu" a donc divers sens contradictoires. Dans "gestion de contenu", ce terme réfère à des données non structurées. Dans "recherche de documents/informations par le contenu", il réfère à la sémantique des informations, par opposition à leur structure ou leurs aspects lexicaux (orthographe, ...). Dans "recherche d'images par le contenu", il réfère soit à la sémantique de l'image (les choses qu'elle contient et leur relations spatiales), soit à des caractéristiques visuelles de l'image comme les textures, couleurs et formes qu'elle contient.

-1.g. Tâches dites "de gestion de connaissances" et leurs supports (SGC, SGBC, SBC)

Question de contrôle (après réponse aux questions éventuelles des étudiants):
- représentez graphiquement et en FL les relations de sous-typage et d'exclusion
  entre SBC, SGC, SE, SGBC et SGBD,
- représentez graphiquement et en FL les relations de sous-typage et/ou de sous-tâche
  entre "gestion de contenu", "gestion de connaissances, au sens des industriels" (GCI) et
  "gestion des connaissances, au sens des universitaires" (GCU)
  (note: une relation de sous-tâche ne peut pas directement lier deux types de tâches,
  elle ne peut lier que des instances de tâches -> utilisez des multiplicités).

//solution en FL:
SGC  >  excl{ SGBD  (SBC > SE SGBC) };
process
  > (GCI  //Gestion/ingénierie des Connaissances au sens des Industriels
       >  excl{ GCI_sur_donnees   //ce que la plupart des industriels font
               (GCI_sur_connaissances
                   > (GCU  //... au sens des universitaires
                        subtask: GCI __[any->0..*, 0..*<-any]  //rare mais possible
                     ))
              },
       subtask:  gestion_de_contenu __[any->0..*, 0..*<-any]
                 GCU __[any->0..*, 0..*<-any]  //e.g., pour certaines meta-data en GCI
    )
    (gestion_de_contenu  subtask: GCI __[any->0..*, 0..*<-any]);
    
//note: la multiplicité/cardinalité "any->0..*" (ou 0..*<-any) peut être omise

+1.s.bc. @@ Base de données/connaissances, ontologie, SGBC, SGBD

Répertoire d'information [information repository]: base de données ou base de connaissances.

Base de données (BD) [database (DB)]: collection structurellement organisée de données. En effet, dans une BD, il n'existe essentiellement que trois 'types de relations' explicites : partie(-de), type(-de), attribut(-de).
Un document structuré (par exemple, un document XML) peut être considéré comme une BD. Inversement, une BD peut être stockée dans un document structuré. Les types de données autorisées - et leurs inter-relations possibles - sont souvent énumérés dans un "schéma de BD".
Ce schéma est fixe (prédéfini): l'utilisateur de la BD ne peut pas ajouter dynamiquement (i.e., déclarer ou définir) de nouveaux types de données et ne peut pas définir de nouveaux types de relations.
Un document XML peut être plus souple qu'une BD relationnelle: il est aussi souple
qu'une BD orientée objet dans la représentation de certaines hiérarchies (e.g., celles structurées par
des relations partie-de) et peut aussi ne pas avoir de schéma associé (auquel cas il peut stocker
n'importe quoi mais aucun contrôle n'est alors effectué).
Une BC peut stocker n'importe quel type de contenu et néanmoins permettre de nombreux
contrôles car les relations et les objets qu'elles relient ont des contraintes|définitions associées
exploitables pour effectuer des inférences logiques.
SGBD [DBMS]: système de gestion de BD [DB management system].
Certains SGBDs - e.g., les NoSQL - ne semblent pas avoir de schéma : ils ne gèrent que des tableaux
associatifs (donc plusieurs tables|objets possibles mais seulement 2 colonnes par table :
"nom d'attribut de l'objet" - "valeur pour cet attribut"). Il est possible de dire qu'ils n'ont pas
de schéma mais, techniquement ou virtuellement, ils ont en fait un schéma fixe très
général (chaque table doit avoir les deux colonnes mentionnées ci-dessus) que même le
concepteur de la BD ne peut changer.

Base de connaissances (BC) [(machine readable) knowledge base (KB)]: collection de représentations de connaissance (RCs).
L'utilisateur d'une BC peut y ajouter dynamiquement de nouveaux types d'objets (via des définitions ou déclarations) et les utiliser.
Une BC est composée d'une ontologie et, généralement, d'une base de faits exprimée grâce aux termes définis dans l'ontologie.
SGBC [KBMS]: système de gestion de BC [KB management system].

Base de faits: ensemble de croyances.

Ontologie: ensemble de termes formels avec, associés à ceux-ci et portant sur eux, des définitions partielles/totales et des croyances.

Onto-terminologie: ensemble de termes formels ou informels connectés entre eux par des relations sémantiques ou lexicales.

Thésaurus: ensemble de termes informels liés par des relations sémantiques ou lexicales.

+1.s.bc. Base de données/connaissances, ontologie, SGBC, SGBD

Exercice (avec début de solution donné et expliqué) :
- représentez en FL-DF puis en FL les relations de sous-typage, d'exclusion
  et de sous-partie /* et de "outil support" (pm#supporting_tool) */ entre les termes en gras de la page précédente.

//solution étendue en FL-DF:
                entity
               /        \
              />         \>
             /            \  
            v              v
        tool--exclusion-->information_repository
        /   \                         |      \
       />    \>                       |>      \>
      v       v                       v        v 
   DBMS    KBMS --[0..*]--p--[0..*]-->KB       DB<--[0..*]--p--[0..*]--DBMS
              |                      /| |\___
              |                     / | \    \________________
              |>                  p/  p   p                   \p /*part*/
              |                   /   |     \                  \
              |             [0.1]/    [1]    \[0..1]            \[0..1]
              v                 v     v       v                  v
          WebKB         fact_base  ontology   onto-terminology   thesaurus
              |                       ↑            /    \[0..*]  ↑[0..1]
              |instance                \-[1]--p---/       \---p--/
              v
      WebKB_on_the_12/11/2010

//Notes: 1) For relations from a type or to a named instance
//          the default multiplicities are [any->0..*] and [0..* <-any]
//          (hence, [0..* <-any] is sometimes ommited above).
//          'any->' and '<-any' can be (and are) also ommited. 
//          'most->' or '<-54%' would need to be explicitly mentionned.
//       2) Compared to the solution in FL below, the above solution in FL-DF
//          does not represent some relations from the parts of 'KB' :
//          - their 'subtype of' relations to 'information_repository'
//          - the exclusion relations between them

entity
  > excl  //the next subtypes (tool and information_repository) are exclusive
    { (tool > (DBMS  part:  DB __[any->0..*, 0..*<-any])
              (KBMS  part:  KB __[any->0..*, 0..*<-any],
                     exclusion: DBMS,
                     >  (WebKB  instance:  WebKB_on_the_12/11/2010)
              )
      )
      (information_repository
         > excl  //the next subtypes are exclusive
           { (KB  part: fact_base        __[any->0..1, 0..*<-any]  //any KB has for
                        ontology         __[any->1,    0..*<-any]  // part only 1
                        onto-terminology __[any->0..1, 0..*<-any]  // ontology,
                        thesaurus        __[any->0..1, 0..*<-any], 
                  > ontology  //an ontology is a KB that has for part only 1 ontology
             )
             DB
             base_of_fact
             thesaurus
             (onto-terminology  part:  ontology  __[any->1, 0..*<-any]
                                thesaurus __[any->0..1, 0..*<-any]
             )
           }
      )
    };

+1.s.web. Web 2.0/3.0/sémantique, web de données/connaissances

WWW (Web) [World Wide Web]: (système hypermédia sur l')ensemble des ressources (documents ou élément de documents, bases de données/connaissances, ...) accessibles via internet. À l'origine, techniquement, le Web n'est que l'implémentation d'un système hypertexte très simple (HTTP + HTML + navigateur Web) sur Internet (i.e., via TCP et DNS).

Web 2.0: mot "fourre-tout" (utilisé à partir de 2001 mais enfin passé de mode) désignant
- les technologies liées à la construction de pages Web dynamiques (i.e., générables),
  e.g., le DOM (Document Object Model) et Ajax (Asynchronous Javascript and XML), et
- la participation des internautes à la construction et indexation de documents Web via des
  sites/systèmes collaboratifs tels que les wikis, les blogs, les réseaux sociaux, les folksonomies
  et les systèmes de sciences citoyennes.
Par opposition à la partie du Web 2.0 du Web, le reste est un "Web de documents statiques (i.e., non dynamiques)".

Web 3.0: mot "fourre-tout" (utilisé à partir de 2009) désignant les futures applications, combinaisons et évolutions des technologies récentes et en particulier celles liées
- au Web Sémantique,
- à la mobilité, l'universalité et l'accessibilité: internet des objets, indépendance vis à vis des
  supports matériels et des systèmes d'exploitation, ...
- au graphisme vectoriel (e.g., SVG qui est en fait maintenant une ancienne technologie) et
  aux formulaires XForms.

+1.s.web. @ Web 2.0/3.0/sémantique, web de données/connaissances

"Web sémantique" [Semantic Web]: mot (surtout utilisé à partir de 1996, soit 4 ans après la naissance officielle du Web) désignant

• soit les ressources (informations) du Web indexées par des méta-données, lesquelles sont organisées (et donc "représentées", notamment via des langages standardisés par le W3C) de telle sorte que des agents logiciels puissent effectuer des inférences logiques sur ces informations.
  De nos jours, le terme "Web des données" ["data Web" ou "Linked data"] est souvent utilisé pour désigner ce sens de "Web sémantique". En effet, ce web sémantique n'est pas un "web de (représentations de) connaissances": il contient beaucoup de données et quelques connaissances (méta-données) pour les indexer (de plus, ces connaissances sont très simples et souvent non syntaxiquement/sémantiquement valides).
• soit les technologies permettant de créer ces méta-données et les exploiter. Il faut noter que la vision originelle pour le Web sémantique était de permettre à des machines de comprendre et répondre à des requêtes humaines complexes, en prenant en compte le sens des ressources sur le Web et le sens de ces requêtes. Ce web sémantique là implique un web de connaissances et est encore très loin d'être réalisé.

Par opposition à la partie Web sémantique du Web, le reste est un "Web peu/non compréhensible par les machines".

Définitions plus précises (et équivalentes entre elles) pour le 1er sens de "Web Sémantique" :
- sous-ensemble des informations du Web dont le sens a été au moins partiellement défini dans
  des formats standards (et donc que des logiciels peuvent utiliser pour faire
  certaines déductions logiques pour de la résolution de problèmes ou être plus (inter-)opérables).
- connaissances du Web exprimées dans des langages standards et
  informations indexées par ces connaissances ou méta-données.

+1.s.web. Web 2.0/3.0/sémantique, web de données/connaissances

Règles élémentaires du Web des données [(Linked) Data Web]:
- identifier et relier le plus possible de choses en utilisant des adresses URI HTTP,
- fournir à ces adresses des informations lisibles par les humains et par les machines
  (en utilisant des langages formels intuitifs ou bien en fournissant différentes
  versions écrites avec des différents langages; e.g., via le mécanisme de
  redirection HTTP code 302 et la variable User-Agent contenu dans les entêtes des
  requêtes HTTP, un serveur peut afficher une page en RDF/XML pour une machine ou
  une page HTML pour le navigateur d'une personne).

Exercice de contrôle (après réponse aux questions éventuelles des étudiants):
- représenter graphiquement, en utilisant des patatoides puis un graphe,
  les intersections entre les différents webs présentés jusqu'à présent
- après l'ajout de relations sous-type et exclusion au graphe par l'enseignant,
  concevoir une représentation linéaire (alias, textuelle) de ce graphe.
La solution pour le graphe est à la page suivante.

+1.s.web. Web 2.0/3.0/sémantique, web de données/connaissances

Ci-dessous, une représentation/modélisation/solution possible, dans la notation FL,
pour le graphe demandé dans l'exercice précédent.
La page suivante propose une représentation graphique des 9 premières lignes ci-dessous.
Note: ici, "web" ou "WWW" réfère seulement à un ensemble de "descriptions" ou de
    "containeurs de descriptions" (fichiers, base de données, ...),
    et non pas aussi aux techniques/applications qui exploitent cet ensemble.

web
  instance of: first_order_type,  //optional (see Note 2 below)
  subtype:
     (static_web  instance: static_WWW)
     (web_2.0                    //juste pour l'exemple car 
        instance:  WWW_2.0,      // introduire/représenter 
        exclusion: static_web    // les types web_2.0, web_3.0, ...
     )                           // semblent peu intéressants
     (semantic_web 
        subtype: (knowledge_web  instance:  Knowledge_WWW)
                 (data_web  instance:  Data_WWW,
                            exclusion: knowledge_web),
          //no exclusion with web_2.0 and web_statique since one can imagine
          // an instance of semantic_web that is also static or web_2.0
        instance: Semantic_WWW,
        part:  knowledge_web __[any->a]
               data_web __[some->a]
     ), 
  instance: WWW_3.0  WWW_2.0_and_3.0  //not yet already declared above
            (WWW 
               part: (WWW_2.0
                        part: WWW_2.0_and_3.0)
                     (WWW_3.0
                        part: WWW_2.0_and_3.0
                              (Semantic_WWW
                                 part: (Data_WWW
                                          part: Knowledge_WWW)
                              ))
            );

/* Note 1: ">" can be used instead of "subtype:".
   Note 2: we could assume that, by default, a category that has subtypes is
           a first-order type, unless it has instance which (by the same rule)
           is a type;  not all languages or inference engines assume that.
   Note 3: the above representation assume that, by default, all
           categories (types or individuals) with different names 
           are different;  since this is not the case for most semantic web
           languages and inference engines, we could add the 3 following lines.
*/
{WWW   WWW_2.0   WWW_3.0   WWW_2.0_and_3.0 
 Semantic_WWW  Data_WWW   Knowledge_WWW} _[collective_set];
{semantic_web  web_2.0  web_statique} _[collective_set];


//To represent that "no instance of 'semantic_web' can share a part with an
//   instance of 'static_web'", i.e., that "no semantic web has for (proper) part 
//   something which is a (proper) part of a static_web", here are three
//   equivalent ways in FL:
semantic_web
  not part: (thing  part: static_web  __[?x->a]
            ) __[any->?x];

any semantic_web  not part: (a thing  part: a static_web);

no semantic_web  part: (a thing  part: a static_web);   

+1.s.2. Web 2.0/3.0/sémantique, web de données/connaissances

Représentation graphique - dans la notation FL-DF (FL Display Form) -
des 9 premières lignes du code FL de la page précédente.
Les représentations graphiques prennent beaucoup de place et ne sont pas automatiquement interprétables.
FL-DF ne sera donc utilisée dans ce cours que au tableau ou pour illustrer ce que peuvent être des représentations graphiques de connaissances plus complexes.

first_order_type | |instance v -----web-------------- | | |subtype |subtype v v static_web <---exclusion--- web_2.0 | | |instance |instance v v static_WWW WWW_2.0

+1.s.2. @@ Web 2.0/3.0/sémantique, web de données/connaissances

Insuffisances du Web classique dues à son peu de méta-données/organisation/sémantique:
- recherches sur des informations peu/in-organisées -> résultats redondants, qui doivent
  être interprétés et combinés par l'homme (seuls des traitements lexicaux ou structurels
  peuvent être appliqués), (faible) ratio rappel/précision ou précision/rappel [precision/recall],
  recherches sensibles au vocabulaire utilisé, ...
- faible interopérabilité et flexibilité des logiciels et des
  bases de données (et des bases de connaissances si peu de relations
  existent entre les éléments de ces bases pour relier ces éléments).

Note: recherches à base de mot-clés avec des listes de
documents/paragraphes/phrases pour résultats
[document retrieval / question answering]   ->
(faible) ratio rappel/précision ou précision/rappel, redondances et inorganisation,
même si des techniques (automatiques) d'extraction de connaissances sont appliquées (e.g., analyse terminologique/syntaxique/sémantique du langage naturel).
Jusqu'en 2015, Google utilisait la BC Freebase mais ne faisait que de la recherche de documents :
il ne répondait pas de manière précise à des questions précises.

Pour avoir des résultats organisés [knowledge retrieval/browsing],
il faut que les auteurs des diverses informations les relient (organisent)
entre elles par des relations sémantiques.
Même dans le futur, des techniques automatiques plus avancées ne
pourront extraire ce qui n'a pas été écrit ou représenté.

Questions de contrôle (après réponse aux questions éventuelles des étudiants):
1. La recherche de documents va t-elle beaucoup s'améliorer dans le futur ?  Si oui, pourquoi ?
2. La recherche d'informations précises va t-elle beaucoup s'améliorer ?  Pourquoi/comment ?

1. Non, la "Note:" ci-dessus explique pourquoi;

2. Oui, le 1er paragraphe de cette page - et ce cours en entier - expliquent pourquoi.

0.s.web. W3C, standards et couches du Web sémantique

World Wide Web Consortium (W3C): comité international développant les standards du
WWW.  Son portail inclut un portail pour le Web sémantique et ses technologies principales standardisées:
- la "famille d'ontologies de langages" OWL,
  une extension de l'ontologie RDFS, un vocabulaire pour spécifier quelques relations
  sémantiques élémentaires telles que "sous-type de" ("subClassOf" en RDFS) et
  "instance de" ("type" en RDFS),
- le modèle de données RDF qui force les documents RDF/XML ("RDF linéarisé|sérializé avec XML)
  à suivre la convention de linéarisation et normalisation de XML dite "alternating"|"fully striped"
  afin de rendre les structures de données plus (ré-)utilisables ; lire le document
  "Why RDF model is different from the XML model",
- des syntaxes (notations), e.g., RDF/XML (linéarisation de RDF avec XML),
  RDFa (pour stocker des connaissances très simples dans des tags HTML),
  Turtle (syntaxe simple),  Notation3 (alias N3, une extension de Turtle),
  SPARQL (une extension de Turtle pour l'interrogation et la mise à jour de bases RDF)
- le mécanisme de conversion syntaxique GRDDL basé sur des schémas de transformation
  (typiquement en XSLT) fournis par les fournisseurs d'informations,
- les ontologies complémentaires POWDER (pour une description élémentaire de ressources),
  SAWSDL (pour une description élémentaire de services),
  SKOS (pour l'organisation de termes informels) et RIF (pour l'écriture de règles).

Les couches du Web sémantique selon le W3C:

Note: RDF/XML n'est plus obligatoire et, à terme, va cesser d'être la norme de-facto   (Turtle pourrait le devenir).

0.s.web. W3C, standards et couches du Web sémantique

Question de contrôle (après réponse aux questions éventuelles des étudiants):
1. représentez (graphiquement puis en FL) les relations sous-type et exclusion
    qui existent entre RDF, RDFS, RDF/XML, RDFa, Turtle, N3, SPARQL et
    les supertypes communs de ces types;
2. expliquez pourquoi le modèle RDF est différent du modèle XML, et
    donnez un moyen de voir si un modèle/langage est plus souple et puissant qu'un autre ?

//1) solution (étendue) en FL:
KRL_element
  > excl{
      (language_ontology
          >  (OWL  > (OWL-Full  part: 1..* OWL-DL)
                     (OWL-DL    part: 1..* OWL-Lite,  logic: SHOIN)
                     (OWL-Lite  part: 1..* RDFS,      logic: SHIF)
                     (OWL_2    logic: SROIQ)
             (RDFS  part of: 1..* OWL-Lite)
      )
      (data_model >  RDF)
      (KRL_syntax >  excl{ RDF/XML  RDFa  
                           (N3  part of: 0..* SPARQL)
                           (SPARQL part: 1..* Turtle)
                           (Turtle  part of:  0..* SPARQL   0..* N3)
                         }
      )
      (logic > (description_logic
                  instance:  SROIQ  SHOIN  SHIF,
                  part of:  First-order_logic
               ),
         instance: First-order_logic
      )
    };

//2) Le modèle de XML (ou des BDD, ou des approches orientées objet) est un
     modèle d'arbre dont les noeuds sont implicitement reliés par des relations 
     de type "part" et peuvent être typés ou avoir des attributs. Il y a donc
     seulement 3 types de relations possibles : partie, type, attribut).
     Ainsi, le modèle de XML 
     - oblige ses utilisateurs à effectuer des choix arbitraires (e.g., 
       mettre la classe d'objet Employee dans Employer, ou inversement),
     - n'encourage pas (et donc aussi, ne force pas) la représentation
       explicite (i.e., comme des entités du 1er ordre) des relations
       entre objets; un utilisateur peut néanmmoins employer XML (ou une
       approche orientée objet) pour définir et utiliser un modèle de
       graphe, i.e., pour définir et n'utiliser que des classes d'objets
       comme Concept et Relation.
     RDF est un modèle de graphe qui permet de créer des relations typées entre
     des individus ou types de concepts. En effet, il déclare des types d'objets
     tels que "ConceptNode" et "RelationNode" (cf. 0.s.BDD).
     Ainsi, il force ses utilisateurs à les utiliser et donc à représenter
     des informations de manière plus précise et flexible qu'avec XML.
     E.g., tout autre utilisateur peut, à tout moment, ajouter de nouveaux types
     de concept/relation et les utiliser conjointement avec/sur les objets déjà
     existants; il n'y a pas de schémas de données fixe/prédéfini.

     Un modèle/langage est plus souple et puissant qu'un autre s'il inclut plus de
     composants ou si ses composants permettent de définir les composants de l'autre.

0.s.objet. Objet/symbole/phrase formel(le) ou non

Objet lexicalement formel: objet (d'information) lexicalement unique dans les fichiers où il est déclaré ou utilisé. Un URI est un objet lexicalement formel car c'est un terme unique à l'échelle du Web (c'est un "identifiant global" dans un format standard du Web). Une façon de rendre un terme lexicalement unique est de le préfixer ou postfixer par un identifiant de sa source. E.g., en N3, pm:bird réfère à un objet dont la source est identifié par pm (qui peut être une abréviation pour Philippe Martin, l'auteur de ce document). pm:bird réfère à sens particulier du mot "bird" pour pm. Dans les LRCs de WebKB, e.g., en FE et FCG, la syntaxe à utiliser n'est pas pm:bird mais pm#bird ou bird%pm.

Objet (sémantiquement) formel: objet dont la source a déclaré qu'il avait un sens unique, en utilisant un LRC et/ou en lui donnant une définition précise. Pour avoir un sens unique, cet objet doit aussi être lexicalement unique (dans les fichiers où il est déclaré ou utilisé).
Si l'objet formel est une description, il doit être composé uniquement de symboles formels.
Un objet non formel peut être informel ou semi-formel (détails plus loin).

Terme formel [formal term]: terme déclaré ou défini comme ayant un sens unique par sa source. S'il est défini, il est possible qu'il n'ait pas d'identificateur; dans ce cas, il s'agit d'une définition anonyme (lambda-abstraction).
Un URI est un terme unique à l'échelle du Web (i.e., c'est un "identifiant global") et dans un format standard. Toutefois, un URI n'est un terme (sémantiquement) formel que si son créateur a précisé à quelle chose unique cet URI réfère, e.g., à un document unique ou bien l'objet que ce document décrit.
Un terme formel réfère à une catégorie [category], i.e.,
- soit à un individu [individual] (un objet qui ne peut avoir d'instance;
  les types qui ont pour instances des individus sont des types du 1er ordre),
  e.g., pm#Paris__capitale_de_la_France_en_2010 ou toute instance d'un type de relation
- soit à un type de concept [concept type] ("classe" en RDFS), e.g.,
  pm#capitale_de_la_France et   n'importe quel (représentant d'un des) sens du mot "bird";
  note: rdf#property (alias, owl#property, sumo#binary_predicate, pm#binary_predicate_type)
  est un sous-type de pm#relation_type qui est un sous-type de pm#1st_order_type qui est le
  type de tous les types du 1er ordre (d'où son nom) et qui est donc un type du second ordre
- soit à un type de relation [relation type] ("propriété" en RDFS), e.g.,
  pm#parent et pm#auteur.

Terme informel: mot (ou expression non quantifiée) lexicalement ou sémantiquement ambiguë, i.e., ayant plusieurs sens. Dans les langues naturelles comme l'anglais, la plupart des mots sont ambigus.
De plus, le contexte est souvent pris en compte pour omettre des précisions, e.g., le mot "chambre" est souvent utilisé sans préciser s'il s'agit d'une chambre d'hôtel, funéraire, d'enregistrement, d'appareil photographique, etc. Dans les LRCs, les termes informels sont souvent représentés entre double quotes. Par exemple, dans les LRCs de WebKB, "bird" et en#"bird", réfèrent respectivement à la chaîne de caractères "bird" et au mot anglais "bird". Dans le cadre de ce cours, les doubles quotes doivent être utilisées pour encadrer les objets informels.

0.s.objet. Objet/symbole/phrase formel(le) ou non

Questions de contrôle (après réponse aux questions éventuelles des étudiants):
- 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
                )));

0.s.quantif. Quantificateur, définition, phrase bien formée

Quantificateur de la logique du premier ordre: quantificateur existentiel (-> "un" ["a"], "il existe", "au moins 1", "1..*")  et  quantificateur universel (-> "quelque soit" ["for all"], "chaque" ["every", "each"]).
Quantificateur numérique: individuel (e.g., "2", "au moins 2", "entre 2 et 35") ou statistique (e.g, "35%", "au moins 60%").
Phrase: observation ou bien définition.
Définition d'un terme T: phrase quantifiant universellement T sauf que, contrairement à une observation, une définition n'est ni vraie ni fausse, elle ne fait que définir un terme (cf. cet exemple).

Phrase bien formée [well-formed statement]: phrase conforme à une syntaxe, e.g., la syntaxe d'un LRC (donc directement interprétable dans une logique) ou la syntaxe d'un langage naturel. Toute phrase bien formée est
- soit une définition (e.g., une procédure en Java),
- soit (la représentation d')une croyance (e.g., une observation, une préférence, une théorie).
Par exemple, "un carré est un rectangle" est une définition (de "carré"), alors que "(apparemment / il se trouve que) les oiseaux volent" est une croyance.
Une phrase peut être composée de plusieurs sous-phrases explicitement connectées par des relations sémantiques ou implicitement connectées par une relation "et". Une phrase relie des objets par des relations sémantiques ou lexicales.

Questions de contrôle (après réponse aux questions éventuelles des étudiants):
1) les phrases suivantes ont-elles plus de chances d'être des définitions que des croyances:
    "les arbres ont des feuilles",  "un chanteur chante",  "cette phrase est fausse";
2) les phrases suivantes sont-elles bien formées en français:
    "Un chapeau.",  "Les idées colorées dorment furieusement.",  "Regarde !".

//solutions:   1) non, oui, non     2) non, oui, oui

0.s.mult. Multiplicité, cardinalité

//solution en N3 pour la 2ème phrase:
N3:  wing_part  rdfs:subPropertyOf  part;
                rdfs:range  wing.
     bird rdfs:subClassOf [a owl:Restriction;
                               owl:onProperty  wing_part  owl:cardinality 2;
                               owl:allValuesFrom bird].

0.s.langage. Noeud, langage de représentations de connaissances

Noeud (ou expression): un terme associé à un quantificateur; de plus, un noeud est soit
- un "noeud concept" si le terme est un type de concept (alors appelé type de ce noeud)
  ou bien un individu (dans ce cas, le quantificateur est omis ou ignoré), e.g.,
  "a cat", "every French bird", "chaque pm#Paris_capitale_de_la_France";
- un "noeud relation" si le noeud permet de créer une relation (comme dans un graphe)
  entre plusieurs noeuds concept (ou depuis un noeud concept si la relation est unaire);
  dans ce cas le quantificateur est existentiel (il est souvent omis) et
  le terme doit être un type (presque tous les LRCs obligent à ce que cela soit un
  type de relation), e.g., "color:" dans "a hat, color: a red".

Langage de représentation de connaissances (LRC): langage permettant d'écrire des "représentations de connaissance", i.e., des phrases ayant une interprétation dans une logique.
Un LRC a généralement un seul modèle de données (modèle structurel) (qui décrit les composants du langage et comment ils peuvent s'agencer) et une seule notation textuelle ou graphique (syntaxe permettant d'écrire des phrases textuellement ou graphiquement). Une notation a une grammaire permettant de décider si une phrase est structurellement correcte ou pas. Tout modèle structurel et notation de LRC a une interprétation dans une logique. Il peut y avoir de nombreuses notations pour un même modèle ou une même logique.

Note: la section 0.s.1erOrdre rappelle ce qu'est un(e) entité/type/phrase/logique/notation d'ordre 0, 1, 2..*.

0.s.semant. Objet/relation sémantique

Objet sémantique: objet dont le ou les sens ("le sens" si l'objet est formel) a été au moins partiellement défini (par rapport à d'autres objets) via des "relations sémantiques" avec un LRC. E.g., compte-tenu de la définition des relations sémantiques pm:subtype (inverse de rdfs:subClassOf) et rdfs:instanceOf, si pm déclare pm:domestic_cat comme pm:subtype de pm:cat, et pm:cat comme pm:subtype (sous-type) de pm:feline, alors tout individu déclaré comme étant une instance de pm:domestic_cat est aussi (transitivement) déclaré comme étant une instance de pm:feline et hérite des propriétés associées à pm:feline.
Exemple de représentations en FL, FCG et N3:
    FL   :   pm#domestic_cat  <  (pm#cat  <  pm#feline);
    FL   :   pm#domestic_cat  pm#supertype: (pm#cat  pm#supertype:  pm#feline);
    FCG:   [pm#domestic_cat,   pm#subtype of:  (pm#cat  pm#supertype:  pm#feline)];
    N3  :   pm:domestic_cat  rdfs:subClassOf  [pm:cat  rdfs:subClassOf  pm:feline].
L'origine de la dernière relation de type rdfs:subClassOf est pm:cat, sa destination est pm:feline.
Note: une relation de type pm#subtype relie des types, pas des individus, il n'a donc pas besoin de quantifier ces types.

Relation sémantique: "noeud relation" sémantique plus les objets directement reliés par ce noeud relation. Une relation sémantique peut être utilisée pour relier des objets formels mais peut aussi être utilisée pour relier des objets non complètement formels. Dans ce dernier cas, tous les sens de chaque objet sont reliés à tous les sens des autres objets.
Exemples de classes de relations sémantiques de base:  relations d'équivalence,
généralisation [e.g., logical deduction, supertype, instance_of, more_general_term],
sous-partie [e.g., sub_process, substance, physical_part],
thème [e.g., agent, object, recipient, instrument],  argumentation,
contextualisation spatiale/temporelle/source [e.g., place, duration, date, author].
Cliquez ici pour une liste de types de relations.
Une relation sémantique est orientée et peut être unaire, binaire, ternaire, etc.
Si elle est binaire, elle a un seul noeud origine et un seul noeud destination.
Le modèle RDF ne propose que des relations binaires et utilise le vocabulaire suivant:
"relation sémantique"->[triplet],   //i.e., le W3C parle de "triplets" pas de relations
"noeud relation"->[predicate],   //terme hérité de la logique des prédicats (1er ordre) "type de relation"->[property],   //très mauvais choix du W3C car
    //   - le terme ne rappelle pas qu'il s'agit d'un type, et
    //   - une relation n'appartient pas à un objet et n'en est donc pas une propriété
"noeud origine"->[(predicate) subjet / (property) domain],
"noeud destination"->[(predicate) object / (property) range].

Relation lexicale: objet formel ne pouvant être utilisé qu'entre des symboles informels.
Une relation lexicale n'est donc pas une relation sémantique.
E.g.: homonyme, antonyme, les relations entre chaînes de caractères, ...

0.s.formel. Commande, connaissance (semi-)formelle

Commande dans une BC: i) "phrase affirmée" dans une BC, ou bien ii) requête dans/sur une BC (pour obtenir une information ou l'exécution d'un processus).

RC informelle: RC utilisant uniquement des objets informels sauf éventuellement pour indiquer la source de la phrase. E.g., en Formalized English (FE), u1#u2#"birds fly" est une phrase informelle interprétée/traduite par u1 à partir d'une ou plusieurs phrases de la source u2.

RC formelle: (représentation de) connaissance (RC) utilisant uniquement des objets formels. E.g., en FE,  u1#`any u1#bird is pm#agent of a pm#flight´ est une phrase formelle et une définition partielle par u1 de u1#bird : elle spécifie que pour être un u1#bird, une condition nécessaire est de voler (en permanence).

RC semi-formelle: RC utilisant des objets formels et informels. E.g., en FE, u2#`every u1#bird is pm#agent of a flight´ est la croyance semi-formelle ("flight" étant informel) de u2 selon laquelle "chaque u1#bird vole". Un autre exemple en FE:
    u3#` u3#every_daylight__birds_flies_during_it
             = `every "daylight" ?t `every u1#bird is pm#agent of a "flight" with pm#time ?t´ ´ ´.
Ce dernier exemple est une définition par u3 du terme u3#every_daylight__birds_flies_during_it comme référant à une phrase non encore affirmée (dans la BC) représentant de façon semi-formelle que "chaque jour, chaque oiseau vole tant qu'il fait jour".
Peu de LRCs permettent de représenter des objets informels ou semi-formels.

0.s.contexte. Méta-phrases (contextes)

Méta-phrase: phrase dont au moins un objet est une phrase.
E.g.,  "John pense que 'il fait beau' ",  `Tom#birds_fly = John#"birds fly"´  et  "Cette phrase est fausse".

Phrase contextualisée: phrase + ses méta-phrases contextualisantes associées.

Méta-phrase contextualisante: méta-phrase spécifiant des conditions (e.g., date, place) pour que la ou les phrases objets soient vraies.  Exemple:  `Tom is believer of ` `Mary liking him´ in 2003´ ´
Non-exemple:   `Tom#birds_fly = John#"birds fly"´.

Contexte d'une phrase: toutes les méta-phrases qui directement ou non, la contextualise. Il est souvent difficile/impossible de représenter tout le contexte d'une phrase: une description ne peut souvent qu'être partielle.

Ci-dessous, un exemple en En, FE, FCG, N3 et KIF.

//Exceptionally, for readability reasons, an action ("liking") is used as a relation En : Tom believes Mary likes him (now) in 2003, and that before she did not. FE : Tom is believer of ` ?p `Mary is liking Tom´ at time 2003´ and is believer of `!?p has for successor_time 2003´. FE : Tom#` ?p `Mary is liking Tom´ at time 2003´. Tom#`!?p has for successor_time 2003´. //Alternatives for the last sentence : // Tom#`!?p has for time_a_time_before 2003´ //this is not a classic relation // Tom#`!?p has for time a time that has for successor 2003´ FL : [Tom believer of: [?p [Mary agent of: (a liking object: Tom)] time: 2003], believer of: [!?p successor_time: 2003] ]; N3 : { :p {[a :Liking; :agent :Mary; :object :Tom]} :time "2003"} :believer :Tom. :not_p negation :p. {:not_p :successor_time "2003"} :believer :Tom. KIF: (exists (?p) (and (= ?p '(exists ((?l liking)) (and (agent ?l Mary) (object ?l Tom)))) (believer ^(time ,?p 2003) Tom) (believer ^(successor_time (not ,?p) 2003) Tom)))

Question de contrôle (après réponse aux questions éventuelles des étudiants):
- représentez en En, FE, FCG et N3 la phrase suivante
  "Tom croit qu'il est possible qu'il aime Mary".

FL:  [Tom  may be agent of: (a love  object: Mary)]  believer: Tom

FL:  [ [Tom  agent of: (a love  object: Mary)]
       modality: a situational_possibility
     ]
     believer: Tom;

//Examples of modalities: situational_possibility (<- "may be/do"),
//  physical_possibility (<- "can do"),
//  deontological_necessity (<- "should/must do"),
//  psychological_necessity (<- "compelled to do")

0.s.contexte. Méta-phrases (contextes)

Représentez dans le LRC que vous souhaitez -- après l'avoir précisé -- et en respectant les règles de modélisation données en cours, la phrase "If a student S does not ask a teacher about a point P at a time T, this is because he (S) has understood this point before T or he does not want to learn P". Notes :
- pour représenter le "or", utilisez une relation de type "or" entre 2 phrases,
- rappelez vous qu'une relation est une phrase,
- en FL, 14 relations (dont 2 relations de type "time") suffisent pour la
  représentation demandée (→ 3 à 5 lignes); vous avez déjà vu plusieurs fois en cours
  les autres relations nécessaires.

FL:  [ [a student ?s  not agent of: (a asking  recipient: a teacher, object: a point ?p)]
       time: ?t ]
     => [ [ [?s agent of: (an understanding  object: ?p)] time: (?t2 successor: ?t) ] or:
          [?s not agent of: (a wanting  object: [?s agent of: (a learning object: ?p)]) ]
        ]

Représentez dans le LRC que vous souhaitez -- après l'avoir précisé -- et en respectant les règles de modélisation données en cours, la phrase "Having read the E5_course is sufficient for a student to represent this phrase". Notes :
- la solution à cet exercice ressemble à celle pour l'exercice précédent
  (avec 2 lignes au lieu de 4 ou 5),
- en FL, 4 relations suffisent pour la représentation demandée.

FL:  [a phrase ?p [a student ?s  agent of: (a reading  object: the E5_course)]
     => [?s  can be agent of: (a representing object: ?p)] ]

0.s.1erOrdre. @ Entité/type/phrase/logique/notation d'ordre 0, 1, 2..*, notation de haut niveau

Rappels (du cours de GL et de systèmes d'information) à propos des entités/types/logiques d'ordre 0/1/2.

Entité du 1er ordre: élément d'information pouvant être mis dans une variable,
e.g., une fonction en C.  Contre-exemples en C++ : un attribut, un résultat de fonction.
Plus vos modélisations (dont vos programmes) utilisent des entités de 1er ordre (ou lieu d'entités d'ordre 0), plus elles seront génériques et donc facilement extentibles, paramétrable, (ré-)utilisables, ...  Pour cela, il vous faut donc utiliser des langages expressifs (-> logique d'ordre supérieur) et des notations de haut niveau (cf. page suivante).

Type (d'ordre 1, 2, ...): élément d'information qui peut avoir au moins une instance,
e.g., pm#cat (qui pour instance pm#Tom_the_cat), pm#Type qui a pour instance pm#cat et le type de relation '>'.
Individu (ou "type d'ordre 0"): élément d'information qui n'est pas un type,
e.g., pm#Tom_the_cat et `pm#mammal > pm#cat´.

Type du 2nd-ordre: type ayant pour instance un type du 1er ordre, lequel a pour instance un individu (catégorie ne pouvant être instanciée).

Logique d'ordre 0 (alias, logique propositionnelle): logique n'ayant pas de variable (quantifiée).
Logique d'ordre 1 (alias, logique des prédicats, un type de prédicat étant assimilable à
un type de relation unaire ou non, ou encore à un type de concept ou un type de relation):
logique ou seuls les individus (explicitement nommés ou anonymes) peuvent
être quantifiées (et donc mis dans des variables),
e.g., la définition suivante est une "phrase du 1er ordre" et nécessite une logique du 1er ordre.

En : the relation "ancestor" is transitive since the ancestor of an ancestor is an ancestor. LP : instance(owl#Transitive_property, ancestor) <= ∀?x ∀?y ∀?z (ancestor(?x,?y) ∧ ancestor(?y,?z)) => ancestor(?x,?z) KIF : (<= (instance owl#Transitive_property ancestor) (forall (?x ?y ?z) (=> (and (ancestor ?x ?y) (ancestor ?y ?z)) (ancestor ?x ?z) )) )

Logique d'ordre 2..* (alias, logique d'ordre supérieur): logique où les types (de concept/relation/quantification) peuvent être quantifiés,
e.g., la définition suivante est une "phrase du 2nd ordre" et nécessite une logique du second ordre car elle comporte un quantificateur universel sur des relations.

En : ?r is a owl#Transitive_property ?r iff ?r(?x,?y) and ?r(?y,?z) implies ?r(?x,?z) LP : ∀?r owl#Transitive_property (?r) <=> ∀?x ∀?y ∀?z ( ?r(?x,?y) ∧ ?r(?y,?z) ) => ?r(?x,?z) KIF : (forall (?r) (<=> (owl#Transitive_property ?r) (forall (?x ?y ?z) (=> (and (?r ?x ?y) (?r ?y ?z)) (?r ?x ?z))) )) KIF : (defrelation owl#Transitive_property (?r) := (forall (?x ?y ?z) (=> (and (?r ?x ?y) (?r ?y ?z)) (?r ?x ?z))) ) FL : owl#Transitive_property (?r) := [ [^x ?r: (^y ?r: ^z)] => [^x ?r: ^z] ]; //^x, ^y et ^z are free variables, i.e., implicitely universally quantified FL : [__ every pm#relation ?r, every pm#thing ?x, every pm#thing ?y, every pm#thing ?z] [ [owl#Transitive_property ?r] <=> [ [?x ?r: (?y, ?r: ?z)] => [?x ?r: ?z] ] ];

Logique du 2nd-ordre: logique permettant de quantifier des relations/prédicats. Définir la transitivité demande une logique du 2nd-ordre, mais définir une relation transitive particulière (e.g., subtype) ne demande pas une logique du 2nd-ordre.
Seules certaines logiques du 2nd-ordre (e.g., logiques modales, logiques temporelles) permettent de raisonner sur certaines phrases contextualisées (e.g., phrases contextualisées dans le temps, phrases utilisant des opérateurs modaux) mais écrire des méta-phrases ne requiert pas une logique du 2nd-ordre.
Exemple de moteur d'inférence du 2nd-ordre: CASL.
Exemple de moteur d'inférence du 1er-ordre: Otter.
Exemple de raisonnement nécessitant une logique modale: la "preuve ontologique de l'existence de Dieu" de Gödel<-Leibnitz<-Anselm (ensuite affinée par Anderson).

0.s.1erOrdre. @ Entité/type/phrase/logique/notation d'ordre 0, 1, 2..*, notation de haut niveau

Notation du 2nd-ordre: notation permettant d'utiliser des variables pour les relations/prédicats et de les quantifier. Une notation du 2nd-ordre n'implique pas nécessairement un moteur d'inférence du 2nd-ordre pour l'utiliser, en particulier si les phrases du 2nd-ordre sont des définitions. En effet, il n'existe souvent qu'un nombre fini de catégories de 1er ordre concernées par ces définitions et il est souvent possible d'appliquer (instancier) la définition du 2nd-ordre à ces catégories (e.g., instancier la notion de transitivité à chaque relation transitive). Le moteur d'inférences peut alors ne pas prendre en compte la définition du 2nd-ordre.
La même méthode peut souvent être utilisée pour transformer des phrases du 1er-ordre en phrases n'utilisant que OWL-Full ou OWL-DL.
Il faut également noter que OWL-DL a des types du second-ordre (e.g., owl#transitive_property, owl#functional_property) qui sont exploités par les moteurs d'inférences prenant en compte OWL-DL, sans que OWL-DL soit pour autant une logique du second-ordre.
L'expressivité d'une BC - et donc ses caractéristiques vis à vis des critères de complétude des raisonnements qui peuvent être effectués via cette BC - n'est donc pas "déterminée" par la notation utilisée pour rentrer les informations dans cette BC.
De plus, un moteur d'inférences peut toujours choisir de ne pas utiliser toutes les informations de la BC. Il sera alors plus efficace mais ses résultats pourront être incomplets ou non toujours valides. C'est un choix qui ne peut être fait que dans le contexte d'une application. E.g., pour de la recherche d'information, effectuer de simples recherches de spécialisations et/ou généralisations par comparaisons de graphes est souvent suffisant. Ainsi, pour de la recherche d'information, il est intéressant de retourner la phrase "Les autruches ne volent pas" à la requête "Est-ce que les oiseaux volent ?" même si ni "Les oiseaux volent" ni sa négation ne sont des implications logiques de "Les autruches ne volent pas".
En conclusion, pour modéliser et partager des informations générales (e.g., des phrases en langage naturel) il vaut mieux utiliser un langage plus expressif que RDF+OWL/XML pour éviter de mal représenter ces informations (e.g., représenter "par définition, un oiseau vole" au lieu de "En France, en 2010, selon l'étude de Dr X, au moins 80% des oiseaux en bonne santé sont capable de voler". OWL et, plus généralement, les logiques de descriptions, sont des logiques pour effectuer certains types de raisonnements de manière efficace ou, du moins, dans des temps prédictibles. Adopter ces logiques est donc un bon choix pour certaines applications mais n'est pas un bon choix pour un standard d'échange d'informations comme RDF+OWL/XML se veut être.

Notation de haut niveau: notation qui permet de représenter des phrases générales de manière concises et normalisées (et donc dont les représentations expressives et normalisées sont généralement faciles à comparer, même par simple comparaison de graphes). Ceci implique (entres autres) la possibilité d'utiliser des contextes, des quantificateurs numériques et d'autres raccourcis (détails en section 4.1). FCG, FE et FL sont des notations de haut niveau. KIF est expressif mais n'est pas de haut niveau. Les notations utilisant le modèle RDF+OWL ne sont pas de haut niveau. Les notations ayant une syntaxe XML ne sont pas de haut niveau.

0.s.BDD. Représentation d'une BC via une BDD;
modèles de données

class Object : {/*...*/} ; class ObjectReference : {/*...*/}; //pointer, database id, ... class Quantifier : Object {/*...*/}; class Node : Object //concept (node) or relation (node) { RelationRefArray get_relations (/*rel. selection parameters*/); RelationRefArray set_relations (/*rel. selection parameters*/); // references to relations connected (from/)to this node, // directly or not ("directly" is a default in the parameters); //1 relation selection parameter is the relation type: subtype, // type, creator, ... (a relation "creator" is (implicitly or // not) about the node representation, not its semantic content) //A node that has a meta-statement (black/white context) // has a relation of type pm#meta-statement (note: any node // that is existentially quantified (e.g., a relation) is a // statement (and probably a sub-statement) and conversely ; // a statement is either a belief, definition or command (e.g. // a query). //A (concept) node that is a meta-statement has a relation of // type pm#first_node and/or pm#embedded_node (an n-ary relation) //1 other parameter should allow the selection of binary } // relations that are "from"/"to" this node class ConceptNode : Node //alias "concept" { //The code should not "know" that actually relations are stored // in concepts, or concepts are stored in relations, or neither. //Similarly, the code should not "know" that node quantifiers // are stored in nodes or in relations: QuantifierRef quantifier_get (/*rel. selection parameters*/); QuantifierRef quantifier_set (/*rel. selection parameters*/); //A node that is a formal/informal "term" (e.g., a word, a type, // a date, ...) has no/all quantifier(s). //A node that has a quantifier is not named (it is not a term). //A particular user is a term ; a set/class of users is not. } //A node may have for creator/believer a (set of) user(s). class RelationNode : Node //alias "relation" { //a relation has directly or indirectly related concepts NodeRefArray relatedConcepts_get (/*concept selection parameters*/); NodeRefArray relatedConcepts_set (/*concept selection parameters*/); QuantifierRefArray quantifiers_get (/*concept selection parameters*/); QuantifierRefArray quantifiers_set (/*concept selection parameters*/); //these are the quantifiers of the linked concepts; } //the existential quantifier of a relation is implicit

+1.e.types. Types d'inférences

Lire OWL 2 Profiles et, en particulier, sa section 5: Computational Properties (+ rappel : décidabilité).

Inférence: méthode de raisonnement pour, à partir de connaissances (alors appelées "données" ou "faits" de l'inférence, qu'ils soient vérifiés ou non), générer une autre connaissance (alors appelée "résultat" de l'inférence). Lorsqu'une méthode n'est pas logique (et donc non sûre), son résultat doit être testée par rapport à des observations. Il existe quatre types principaux d'inférences: la déduction (seul type d'inférence logique), l'induction, l'abduction et l'analogie.

Déduction: méthode de raisonnement dont le résultat contient moins d'information que les faits sources. Le résultat est donc sûr si les faits sont sûrs. Le modus ponens est une règle de déduction logique. E.g.:
Données:  Tweety is a bird.   Every bird flies  (alias: if b is a bird, then b flies).
Résultat:   Tweety flies.
Plus formellement: si "A implique B" et "A est vrai" alors "B est vrai" (modus ponens).

Induction: généralisation (non sûre) à partir d'exemples. E.g.:
Données:   Tweety, Polly and Hooty are birds.   Tweety, Polly and Hooty fly.
Résultat:   Every bird flies  (alias: if b is a bird, then b flies).
Plus formellement: lorsque tous les exemples (d'instances) d'un objet A impliquent B,
l'induction suppose que toutes les instances de A impliquent B.

Abduction: génération d'une hypothèse pour expliquer un fait. E.g.:
Données:  Tweety flies.   Every bird flies  (alias: if b is a bird, then b flies).
Résultat:   Tweety is a bird.
Plus formellement: si "A implique B" et "B est vrai" alors "A est vrai".

Analogie: génération à partir de propriétés communes. Ces propriétés peuvent être trouvées par des méthodes statistiques et/ou de comparaison symbolique (comme illustré plus loin). L'analogie peut être vue comme une généralisation des autres types d'inférences, comme illustré par la figure suivante.

Note: dans son sens général, l'argumentation rassemble toutes les techniques utilisables pour convaincre. Les arguments utilisant la déduction sont logiques, les autres sont fallacieux.

+1.e.types. Types d'inférences

+1.e.comp. @ Comparaison et recherche de termes et de phrases

Tous les moteurs d'inférences proposent un moyen de savoir si une (phrase "proche" d'une) phrase particulière existe dans une BC, ou peut être déduite de cette BC, ou si sa négation ne peut être déduite de cette BC. Pour permettre de spécifier de telles requêtes, divers opérateurs de recherche peuvent donc être proposés; ils prennent en paramètre une "phrase requête".
Le langage de requête proposé peut ne contenir qu'un opérateur (qui peut par exemple être noté "?" ou être implicite) mais peut proposer des moyens de combiner diverses requêtes ou commandes.
Généralement, le langage de requêtes proposé est une extension du langage proposépour affirmer des phrases.
Il est généralement plus facile pour un moteur d'inférences de gérer de manière exacte et complète des requêtes exprimées avec une notation pour une logique du 1er ordre que des affirmations effectuées avec une notation pour une logique du 1er ordre.
Dans WebKB, le langage de requêtes/commandes est appelé FC (For Control). Il propose divers opérateurs qui peuvent utiliser des phrases requêtes écrites dans divers LRCs. Toutes les requêtes peuvent être écrites avec l'opérateur "?", les autres opérateurs sont des abréviations.
Ci-dessous, quelques exemples commentés. Lorsque non-explicitée, la notation ici utilisée pour les phrases requêtes est FL.

À propos de '>=' (spécialisation), '.>=' (spécialisation étendue), '=>' et '<=>' entre phrases:
-   '<=>' est l'équivalence logique entre phrases; entre termes, on utilise '='.
-   `A .>= B´:  B contient/représente plus d'informations que A, ou A = B.
-   `A >= B´:  idem sauf que A et B sont des formules logiques "simples",
     i.e., existentielles conjonctives avec ou sans contextes négatifs,
     i.e., utilisant ∃ et/ou ∧ mais pas ¬, ∀, ni de quantificateurs numériques.
Avec des formules "simples", on a:   (A > B) <=> (B => A) <=> (A .> B)
  De manière générale, on a seulement:   (A > B) => ( (B => A) ∧ (A .> B) )

? [a pm#cat part: a paw] //-> réseau (et donc hiérarchie de spécialisation étendue) // des phrases de la BC qui impliquent ceci //Pas de réponse -> faux ?? [a pm#cat part: a paw] //renvoie True s'il y a au moins une réponse, False sinon ? [a pm#cat part: a paw] <= ?s //-> idem ?s [a pm#cat part: a paw] <= ?s //-> liste (et non réseau) des phrases impliquant [...] ? [a pm#cat part ^2..4: a paw] //-> chaîne de 2 à 4 relations "part" (avec leurs contextes // si elles en ont) reliant pm#cat à "paw" ? [a pm#cat part ^1..*: a paw] //-> chaîne d'au moins une relation "part" reliant pm#cat à "paw" ? [a pm#cat part ^+ : a paw] //idem (note: même si ceci est sans réponse, [a pm#cat part: a paw] // peut être vrai via d'autres définitions/règles/relations que des relations "part"; // en effet, le `^+´ étant une expression régulière sur des chemins de relations, // la recherche de réponse se fait par comparaison de graphes/chemins et non via // un mécanisme complet de déduction logique comme avec "<=") ? [a pm#cat part: a paw] <=^1 ?s //-> réseau des phrases directement et explicitement impliquantes ? [a pm#cat part: a paw] =>^1 ?s //-> 1 relation "=>" directe et explicite de [...] à ?s ? [a pm#cat part: a paw] =<^1 ?s //-> 1 specialisation directe et explicite de ?s à [...] ? [a pm#cat part: a paw] >=^1 ?s //-> réseau des phrases directement et explicitement spécialisantes ? [a pm#cat part: ?x] //-> réseau des phrases impliquant que pm#cat a des sous-parties ?x [a pm#cat part: ?x] //-> objets sous-parties de pm#cat ? [pm#cat >^1 ?x] //-> hiérarchie des sous-types directs de pm#cat ? pm#cat >^1 ?x //idem (car en FL, les [] de premier niveau sont optionnels) ? `pm#cat has for direct pm#subtype ?´ //idem avec la notation FE pour la phrase requête ? [pm#cat < ?x, > ?y] //-> hiérarchie des super-types et sous-types de pm#cat ?x,y [pm#cat < ?x, > ?y] //-> liste des super-types et sous-types, préfixés par "?x=" et "?y=" ? [pm#cat !pm#exclusion: ?x] //-> réseau des (phrases montrant les) termes non exclusifs à pm#cat ?s [pm#cat pm#part: 4 leg] !pm#exclusion: ?s //-> liste des phrases non exclusives à [...] ? [a pm#cat (pm#relation: a pm#thing)^1..3 pm#emplacement: fr#"France"] //-> chaîne de // 1 à 3 relations entre une instance de pm#cat et quelque chose ayant pour // pm#emplacement quelque chose qui en Français est appelé "France" ?3 [a pm#cat part: ?x] //renvoie au maximum 3 graphes réponses ?3:x [a pm#cat part: ?x] //renvoie au maximum 3 valeurs pour ?x ??:x [a pm#cat part: ?x] //renvoie True si ?x existe et si son quantificateur est différent de 0|no ?2..4:x [a pm#cat part: ?x] //renvoie au maximum 4 valeurs pour ?x ou aucune s'il n'y en a pas au moins 2 ??3:x [a pm#cat part: ?x] //renvoie True s'il y a au moins 3 valeurs pour ?x, False sinon

Note: ci-dessus, les expressions du type "quelles phrases de la BC impliquent ..." réfère à des phrases "minimales" (car sinon, la BC pouvant elle-même être considérée comme une (grosse) phrase, la réponse serait la BC entière). Ici, "minimale" signifie "qui serait - ou pourrait être - faux si un élément était omis". Une phrase minimale inclut donc ses phrases contextualisantes. Par exemple,
si la requête est :   ? [a pm#animal  pm#part:  4 leg] >=^1 ?s
et si la BC contient la phrase suivante :
      [  [2 pm#cat   pm#part:  4 ^(leg  color: a yellow),  owner:  pm#Tom]    time: 21/12/2010]
alors une réponse est :
      [  [2 pm#cat   pm#part:  4 ^(leg  color: a yellow)]    time: 21/12/2010]
La précision "owner: pm#Tom" n'a pas à être incluse dans une réponse minimale, par contre
il vaut mieux inclure précision "color: a yellow" car

1. la requête ci-dessus recherche des s // 1 à 3 relations entre une instance de pm#cat et quelque chose ayant pour // pm#emplacement quelque chose qui en Français est appelé "France" ?3 [a pm#cat part: ?x] //renvoie au maximum 3 graphes réponses ?3:x [a pm#cat part: ?x] //renvoie au maximum 3 valeurs pour ?x ??:x [a pm#cat part: ?x] //renvoie True si ?x existe et si son quantificateur est différent de 0|no ?2..4:x [a pm#cat part: ?x] //renvoie au maximum 4 valeurs pour ?x ou aucune s'il n'y en a pas au moins 2 ??3:x [a pm#cat part: ?x] //renvoie True s'il y a au moins 3 valeurs pour ?x, False sinon

   Note: ci-dessus, les expressions du type "quelles phrases de la BC impliquent ..." réfère à des phrases "minimales" (car sinon, la BC pouvant elle-même être considérée comme une (grosse) phrase, la réponse serait la BC entière). Ici, "minimale" signifie "qui serait - ou pourrait être - faux si un élément était omis". Une phrase minimale inclut donc ses phrases contextualisantes. Par exemple,
   si la requête est :   ? [a pm#animal  pm#part:  4 leg] >=^1 ?s
   et si la BC contient la phrase suivante :
         [  [2 pm#cat   pm#part:  4 ^(leg  color: a yellow),  owner:  pm#Tom]    time: 21/12/2010]
   alors une réponse est :
         [  [2 pm#cat   pm#part:  4 ^(leg  color: a yellow)]    time: 21/12/2010]
   La précision "owner: pm#Tom" n'a pas à être incluse dans une réponse minimale, par contre
   il vaut mieux inclure précision "color: a yellow" car

   1. la requête ci-dessus recherche des spécializations (directes) de "leg" et donc l'utilisateur sera probablement intéressé par "leg color: a yellow"; de plus, si le type "yellow_leg" avait été utilisé au lieu de "leg color: a yellow", c'est bien "yellow_leg" qui aurait été retourné ;
   2. si "4% ^(leg  color: a yellow)" avait été utilisé au lieu de "4 ^(leg color: a yellow)", c'est bien "4% ^(leg  color: a yellow)" et non "4% leg" qui aurait été retourné pour que la réponse soit correcte
      (note: ceci n'est qu'un exemple, "4% ..." ne peut guère avoir de sens commun en destination d'une relation de type "part").

+1.e.comp. @ Comparaison et recherche de termes et de phrases

Exercice de contrôle
Si l'on suppose que la BC [KB] ne contient que
   pm#relation  >  (part  pm#type: pm#transitive_relation_type)  pm#type  pm#supertype;
   B1  part _[every->a]: (B2 part _[every->a]: (B3 part _[any->a]: B4)),  < A1,  > C1;
   //i.e.:   B1  < A1,  > C1;   every B1  part: a B2;   any  B2 part: a B3;   any B3 part: a B4;
quelles réponses doit donner un moteur d'inférences aux requêtes FL suivantes
s'il connait la sémantique de pm#transitive_relation_type, pm#type et pm#supertype ?

/*1.*/ ? [a B1 part: a B4] /*2.*/ ? [a B1 part ^1: a B4] /*3.*/ ? [a B1 part ^1: a ?x] /*4.*/ ?x [a B1 part ^1: ?x] /*5.*/ ? [a B1 part: a (?x < A1)] /*6.*/ ?x [a B1 part: ?x] /*7.*/ ? [B1 pm#relation ^1: a ?x] /*8.*/ ?x [B1 pm#relation ^1: ?x] /*9.*/ ? [B1 pm#relation: a ?x]

+1.e.fusion. Jointure/fusion de phrases

Jointure de deux phrases: création d'une 3ème phrase composée des deux phrases fusionnées (alias, jointes) sur certains noeuds, par exemple car ils sont identiques.

Jointure dirigée: les noeuds à joindre sont spécifiés en paramètre de la jointure. Un noeud joint est une spécialisation des deux noeuds à joindre.
E.g., une jointure de  [a cat, place: a table]  et  [Tom, place: some (furniture, color: a red)]
sur leurs premiers noeuds est:   [Tom, place: a table, place: some (furniture, color: a red)].

Jointure maximale: jointure non dirigée qui
- maximise le nombre de noeuds concept et/ou relation joints, et/ou
- minimise le nombre de noeuds concept et/ou relation dans la phrase résultante, et/ou
- sélectionne la zone/phrase jointe la plus spécialisée.
Il peut bien-sûr y avoir plusieurs solutions alternatives dans chaque cas.
E.g., une jointure maximale de  [a cat, place: a table]  et
[Tom, place: some (furniture, color: a red)]  est:   [Tom, place: some (table, color: a red)].

Note: un langage de script similaire au shell d'unix peut être utilisé pour combiner des commandes.
C'est le cas avec le langage FC (For Control) de WebKB.  E.g.:
  if (? [a cat])
  then ? [a pm#cat] <= ?s   |   maximal_join
  fi   //jointure maximale des phrases de la BC qui impliquent l'existence d'un pm#cat

0.o.0. Ontologies de language / haut niveau / domaine / ...

Ontologie de langage (de représentation de connaissances) (e.g., RDFS, OWL, ...): ontologie formelle dont les termes décrivent un modèle de données (+ logique/sémantique) utilisable pour représenter des connaissances. E.g., binary relation, subtype, cardinality, ...

Ontologie lexicale (alias, de langage naturel) (e.g., à partir de WordNet): ontologie dont les termes formels représentent le sens de termes informels d'un langage naturel.

Ontologie de haut niveau (e.g., DOLCE): ontologie dont les termes formels représentent des distinctions générales (e.g., entité, situation, space, time, part-of, ...) généralement utiles pour organiser/contrôler toute ontologie qui n'est pas une ontologie de langage.

Ontologie fondamentale [fundational ontology]: ontologie formelle de haut niveau dont les termes sont très précisément définis et, le plus souvent, sont relatifs à un seul thème, e.g., relations spatiales/temporelles/partie-de.

Ontologie de domaine: ontologie dont les termes sont relatifs à un domaine, e.g., la radiographie, l'élevage des poules, ...

0.o.m.task.0. Méthodologie/tâches/modèles d'ingénierie des connaissances

Tâches:
- évaluation des différentes contraintes (buts, compétences, ressources, ...)
- extraction et modélisation de connaissances dans une BC
- développement+validation d'un SBC et intégration à d'autres outils
- maintenance, révisions, évaluations.

Bibliothèque de (modèle de) tâches génériques: décomposition de tâches (classiques pour la résolution de problème) en méthodes (chaque méthode est une façon d'exécuter une tâche) et décomposition de chaque méthode en sous-tâches (il s'agit d'un modèle de tâche).
La bibliothèque de la méthodologie KADS-I (pour l'acquisition des connaissances et la création de SBCs) offrait des modèles de tâches pour des tâches d'analyse (e.g., prédiction, surveillance, diagnostic, évaluation), de modification (e.g., planification, configuration) et de synthèse (e.g., modélisation, conception, reconstruction).
Dans KADS-II, afin de faciliter la réutilisation et la combinaison des modèles de tâches, les auteurs de KADS se sont focalisés sur les tâches génériques les plus primitives (en anglais: assignment, planning_and_reconstruction, modeling, design, modeling, prediction, assessment, correction, monitoring, diagnostic, repair).

Cliquez ici pour une représentation de divers modèles de KADS-I (dont un modèle de tâche pour le "diagnostic systèmatique") dans le formalisme de Graphes Conceptuels.

0.o.m.task.1. Cycle de vie "logiciel" / "acquisition des connaissances"

Sous-tâches de "modélisation|analyse|spécification & conception" de logiciel :
- analyse & spécification des besoins --> modèle|schéma conceptuel
- conception du logiciel et de ses bases d'informations --> modèle de conception

Cycle de vie en "ingénierie des connaissances"   (Heijst & al., 1996) :

0.o.m.task.2. Tâches génériques de résolution de problème

Hiérarchie de spécialisation sur les "tâches génériques" dans
la "méthodologie d'acquisition des connaissances" KADS-I  (Breuker & al., 1987)
(tâches dont les "modèles génériques" sont à sélectionner, suivre et combiner
 lors de l'élicitation et modélisation de connaissances
  -> méthodologie "dirigée par les modèles" et donc "descendante") :

analyse_de_système identification (d'une catégorie) classification classification_simple diagnostic (identification d'une catégorie de faute) diagnostic_faute_unique diagnostic_par_classification_heuristique (modèle du domaine : modèle de faute) diagnostic_systématique (modèle du domaine : modèle de rectitude) localisation_structurelle localisation_causale diagnostic_fautes_multiples évaluation (de correspondance ou d'adéquation : identification d'une classe de décision) surveillance (identification d'une incompatibilité entre une norme et une observation) prédiction (d'un état passé ou futur du système) prédiction_de_comportement prédiction_de_valeurs modification_de_système réparation remède contrôle maintenance synthèse_de_système transformation conception conception_par_transformation conception_par_raffinement conception_par_raffinement_à_flot_unique conception_par_raffinement_à_flots_multiples configuration planification modélisation

0.o.m.task.3. Exemple de modèle de tâche générique

Diagnostic systématique" dans KADS-I :

0.o.m.task.4. Tâches et méthodes dans CommonKADS

En théorie, dans KADS (et dans d'autres méthodologies), une tâche ne se
décompose pas directement en sous-tâches :
une tâche est un but qui a des méthodes alternatives pour être atteint
et chaque méthode définit une décomposition en sous-tâches.

Le choix entre différentes méthodes pour une tâche est souvent fait lors de la
modélisation, en fonction des contraintes de l'application visée.
Toutefois, lorsque cela est possible, il est préférable de modéliser la façon d'effectuer
un tel choix pour que le SBC final puisse l'effectuer dynamiquement en fonction des
informations dont il disposera.
Il s'agit alors de modéliser une tâche qui effectue des choix entre des méthodes.

Le choix de l'ordre entre des sous-tâches d'une méthode est le plus souvent
déterminé dynamiquement en fonction des diverses contraintes
statiques (e.g., relations entre les tâches) et dynamiques (données fournies lors
d'une exécution). Ce choix peut être effectué par le "moteur d'inférences sur
règles (déclaratives)" utilisé, ou peut être modélisé dans une tâche séparée,
e.g., une tâche de planification [planning, scheduling].

Dépendance entre les "tâches génériques" dans CommonKADS   (Breuker, 1994) :

0.o.m.task.5. Approches dirigées par les modèles / données

L'élicitation et modélisation des connaissances, i.e.,
la construction de modèles de tâches et d'objets utilisés par ces tâches, peut être
- "dirigée par les modèles" et donc "descendante"
- "dirigée par les données" (interviews/articles d'experts, ...) et donc "ascendante"
- mixte (de manière opportuniste ou systématique).

Avec la popularisation du Web sémantique (liée à la prise de conscience des limites
du Web classique et, plus généralement, des nombreux problèmes liés au peu de
prise en compte des relations sémantiques dans les approches GL/BDD classiques),
les méthodologies de modélisation|analyse|spécification & conception de logiciel
prennent de plus en plus en compte les résultats des méthodologies de
modélisation de connaissances.
Toutefois, actuellement, cette prise en compte reste limitée. Ainsi, ce qui est appelé
"dirigée par les modèles" dans les 1ères méthodologies (celles pour le logiciel)
correspond à ce qui est appelé "dirigée par les données" dans les 2ndes.
A partir d'une section similaire à celle-ci, le cours de Génie Logiciel a introduit
- et partiellement fusionné - les 2 types de méthodologies
(puisque les 2ndes généralisent les 1ères et simplifient leur apprentissage)
mais il ne donnera pas d'exercice (ni d'évaluation) sur les modèles de tâches.
Par contre, les définitions liées à "tâche" (e.g., le lien entre "tâche" et "méthode")
pourra faire l'objet d'évaluations.

0.o.descr. Contenu/medium de description

Entité d'information [information entity]: objet(s) qui sont/contiennent de l'information ou permettent d'exprimer/rechercher de l'information.
Deux spécialisations non exclusives de "entité d'information" sont:
"contenu de description" et "instrument de description".

Contenu de description [description content]: affirmation/requête d'information et donc les objets suivants (tels que définis précédemment): commande, information, phrase affirmée, croyance, définition, donnée, connaissance, web.

Instrument de description [description medium]: objet(s) permettant de décrire de l'information et donc les objets suivants (tels que définis précédemment): langage, phrase non encore affirmée, symbôle, élément graphique, terme, identificateur, URI, quantificateur, catégorie (individu ou type de concept/relation).

0.o.tc. Types de concept de plus haut-niveau essentiels

La page suivante présente une organisation formelle (en FL) des
"types de concept" de haut-niveau les "plus importants" dans le sens où
ce sont ceux qui
- sont le plus intuitifs à utiliser pour catégoriser des sens de mots
  (contrairement à, par exemple, "abstrait", "divisible", ...),
- ont le plus de liens d'exclusion entre eux (donc ceux qui permettent le plus de
  détections d'erreur de modélisation)
- sont le plus facilement utilisables pour des signatures de
  "type de relations" primaires (i.e., non définissables par rapport à
  d'autres types de relations)
- sont les plus faciles à utiliser (avec leurs types de relations primaires associées)
  comme guide pour l'élicitation et la modélisation de connaissances.

Tout type de concept que vous représentez doit spécialiser un des
types de concept en "caractères gras non italiques" de la page suivante.
Des types de relations associées à ces types de concept sont ensuite donnés.

Les 2 pages qui suivent la page suivante propose une présentation plus
informelle de types de concepts de haut niveau.

Exercice à effectuer pendant la lecture de la page suivante :
- Pour au moins 3 sens du terme "représentation de connaissances", citez leurs
  généralisations parmi les types de concepts de page suivante.
  Note: en français ou en anglais, "représentation" a une dizaine de sens,
    ceux évidents lorsque l'on rajoute les adjectifs "théatrale", "syndicale", ...

en#"knowledge-representation"
  .> (pm#knowledge-representation_process  < pm#process)
     (pm#knowledge-representation_content  < pm#description)
     (pm#knowledge-representation_character-string  < pm#description_instrument)
     (pm#knowledge-representation_physical-support  < pm#physical_entity);

0.o.tc. Types de concept de plus haut-niveau essentiels

En FL (note : la section 0.o.meta (Résumé) donne une typologie complémentaire pour les types de 2nd-ordre) :

thing (^anything that exists or that can be thought about^) > partition { (situation (^"situ"; anything "occuring" in a real/imaginary region of time&space, aka. occurrent, perdurant, process, event^) > partition { state (^"stat"; situation that is not a process^) (process (^"proc"; situation "making a change"^) > (problem_solving_process (^e.g., software_lifecycle_process^) > KADS_generic_process (e.g., KADS_systematic_diagnosis^) ) (process_playing_a_role (e.g., consuming_process, creating_process^) > event (^"evnt"; process considered instantaneous from some viewpoint^) ) ) } situation_playing_a_role (^e.g., outcome, accomplishment^) ) (entity (^"enti"; thing that is not a situation -> that may "participate" to one, aka. endurant, i.e., "individual wholly present whenever it is present"^) > partition { (spatial_entity (^"spac", spatial substantial (existentially independent endurant) ^) > partition { (physical_entity (^"phys"^) > entity_that_can_be_or_was_alive) spatial_non-physical_entity (^"snpe"; e.g., geometry_object^) } spatial_object_playing_a_role (^e.g., place, physical_entity_part/substance^) ) (non-spatial_entity > partition { (non-spatial_entity_existentially_dependent_on_another_entity = ufo#Moment, > partition { (ufo#Intrisic_Moment > (ufo#Mode (^e.g.: John's desire, Intention, Perception, Symptom, Skill^) = characteristic_or_attribute_or_measure, > partition { characteristic (^"chrc"; e.g., color, wavelength^) attribute_or_measure (^"meas"; e.g., red, '620 to 740 nm'^) } (ufo#Externaly_Dependent_Mode part of: 1 Relator, ufo#externaly_dependent_on: 1..* Entity ) ) ) (ufo#Relator (^"rltr"; e.g., Marriage, Enrollment, Employment, Mandate^) part: 2..* ufo#Externaly_Dependent_Mode ) } ) (non-spatial_entity_existentially_independent = non-spatial_substantial, > partition { temporal_entity (^"time"; e.g., date, duration^) (non-spatial_non-temporal_substantial > partition { (description_content/instrument/support (^"desc"^) > description (^"dcon"; e.g., Type, proposition^) description_instrument (^"dins"; e.g., language^) description_support (^"dsup"; e.g., file^) ) non-spatial_non-temporal_non-chrc/meas/desc_substantial (^"nsto", e.g., justice^) } ) } ) } ) } entity_playing_a_role (^e.g., owner, agent^) ) } thing_playing_a_role (^e.g., creation, part^);

0.o.tc. Types de concept de plus haut-niveau essentiels

Top-level concept type specialization hierarchy (e.g., usable for
categorizing information, especially since at each level the "*1*" and the
"*2*" types form a partition; the other types are not exclusive with the first two).

Thing //anything 1sit. Situation //thing "occuring" in a (real or not) region of time/space 1sit.1proc. Process //thing making a change 1sit.1proc.1transf. Transformation //e.g., aggregation, removal 1sit.1proc.2ntransf. Non-transformation //e.g., move, selection/association 1sit.2stat. State //situation that is not a process 1sit.3role. Role_of_situation //partition only wrt same link 1sit.3role.1rSit. Role_of_situation_wrt_a_situation //e.g., Successor 1sit.3role.2rEnt. Role_of_situation_wrt_an_entity //e.g., Generator //e.g., Process_with_input_an_entity 2ent. Entity //thing "involved" in a situation 2ent.1spa. Spatial_entity 2ent.1spa.1phys. Physical_entity //e.g., Animal (e.g., Person) 2ent.1spa.2nphys. Non-physical_spatial-entity 2ent.2nspa. Non-spatial_entity 2ent.2nspa.attr. Attribute-or-Quality-or-Measure 2ent.2nspa.n-attr. Non-AttributeOrQualityOrMeasure_non-spatial_entity 2ent.3role. Role_of_entity //partition only wrt same link 2ent.3role.1rSit. Role_of_entity_wrt_a_situation 2ent.3role.1rSit.1descr. Situation_description_entity 2ent.3role.1rSit.2parti. Process_participant //or: Situation_non-description_entity 2ent.3role.1rSit.2parti.1in. Process_in-participant //e.g., Agent, Object, Parameter 2ent.3role.1rSit.2parti.2out. Process_out-participant //e.g., recipient, created_entity 2ent.3role.2rEnt. Role_of_entity_wrt_an_entity 3role. Role_of_thing //e.g., temporal role like a phase, such as // beginning_process/ending_process or, for a person, minor/adult 3role.1rSit. Role_of_thing_wrt_a_situation 3role.2rEnt. Role_of_thing_wrt_an_entity

0.o.tr. Types de relations essentiels

À partir d'un processus (en FL ci-dessous, graphiquement page suivante) :

any process relation_from_process_to_spatial_entity : 0..* spatial_entity, relation_from_process_to_temporal_entity : 1..* temporal_entity, relation_from_process_to_event : 1..* event, relation_from_process_to_state : 1..* state, relation_from_process_to_process_attribute: 0..* process_attribute, relation_to_process_participant : 1..* participant, relation_to_another_process : 0..* process, relation_to_description : 0..* description; relation_from_process_to_spatial_entity > from_place place to_place via_places; relation_from_process_to_temporal_entity > since_time time duration until_time; relation_from_process_to_event > triggering_event ending_event; relation_from_process_to_state > (predecessor_state > beginning_state precondition cause) (successor_state > end_state postcondition consequence purpose); relation_from_process_to_process_attribute > manner speed; relation_to_process_participant > (relation_to_used_object alias: object, > input object parameter material instrument) (relation_to_participating_agent > agent initiator) (relation_to_created-or-modified_participant > (relation_to_created-or-modified_object > input-output_object generated_object deleted_object) (relation_to_modified_agent > patient experiencer recipient) ); relation_to_another_process > specializing_process generalizing_process sub-process method embedding_process; relation_to_description //useful for annotating but not for modelling knowledge/software > description;

Note. Il y a de nombreuses manières de formaliser des contraintes sur l'ordre d'exécution
de différent processus.  Ces différentes manières pourraient être représentées via des
spécialisations des types de relations 'predecessor_state' et 'successor_state'.
- Le langage des "réseaux de Petri" [Petri net] est un des formalismes les plus expressifs
  (lire la page pointée). Il étend le langage des automates d'états finis.
- D'autres modèles permettant de représenter le parrallélisme|concurrence entre
  processus sont : [process algebra], [actor model] et [trace theory].

0.o.tr. @@ Types de relation essentiels - Graphique

------------------------0..*--> |______________________________ spatial_entity temporal_entity <--1..*--------------------------- (relation_to_another_spatial_entity) ^ ^ | \0..* 1..*/ | \ / | (relation_from_process_to_spatial_entity \ /(relation_from_process_to_temporal_entity | > from_place place \ / > since_time time duration to_place via_places) \ / until_time) | \ / | \ / (relation_from_state_to_temporal_entity)| ---0..*--> process_attribute \ / | |____________________________________________ | | --------------------------------1..*--> event | (relation_from_process_to_process_attribute \ | | /(relation_from_process_to_event | > manner speed) \ | | / > triggering_event ending_event) | \ | | / | \| |/ | 1..* state <--------------------------------- process ---------------------------------------> 1..* state | (predecessor_state / | | \ (successor_state | | > beginning_state / | | \ > end_state postcondition | | precondition cause) / | | \ consequence purpose) | |(part) | | | | (part)| | | | | | | | (relation_to_process_participant | | | |(relation_to_created-or-modified_participant | | > (relation_to_used_object | | | | > (relation_to_created-or-modified_object | | alias: object, | | | | > input-output_object generated_object | | > input_object parameter | | | | deleted_object) | | material instrument) | | | | (relation_to_modified_agent | | (relation_to_participating_agent| | | | > patient experiencer recipient) ) | | > agent initiator) ) | | | | | v v | | v v 1..* state <----------------- 1..* participant | | 0..* participant -----------------------> 1..* state (state) / \ (state) / \ (relation_to_description / \(relation_to_another_process > description) / \ > specializing_process generalizing_process | | sub-process method embedding_process) | | 0..*| |0..* ---------------------------0..*--> v v |_________________________________ description process (relation_to_another_description | | \ > generalizing-description | | \ sub-description correction) | | ------------------------0..*--> description_medium | | (description_medium) | | agent <--1..*--------------------------/ \----------------------------0..*--> description_container (description_believer) (description_container)

0.o.tr. Types de relation essentiels - exercice

Exercice :
1. Représentez en FL la phrase suivante en vous aidant des types de relations de la page précédente.
  "The content of the sentence '2% of men that travel from Chicago to Boston from 14:00 to 16:00
    on a Friday, gnaw all their nails' can be described by this sentence".
2. Il manque d'importantes relations à cette représentation de connaissance pour qu'elle soit
  précise/vraie/utile. Lesquelles ?

//2. This sentence is likely to be false if more details are not given, e.g., 
//   precisions about when the referred travels occured, on which airline, ...


//1. In FL:
[2% ^(man  agent of: (a travel  from_place: Chicago, to_place: Boston,
                                since_time: 14:00, until_time: 16:00, time: a Friday) ) ?m
     agent of: (a gnawing  object: every ^(nail  part of: ?m))
] description: "2% of men that travel from Chicago to Boston from 14:00 to 16:00
                on a Friday, gnaw all their nails";


//1. In FL-DF:
--------------------------------------------------------------------------------------
| man --agent of _[2% ^m ^-> a ^t]--> travel --from_place _[any ^t ^-> .]--> Chicago |
|  |                                       |--to_place _[^t ^-> .]--> Boston         |
|  |                                       |--since_time _[^t ^-> .]--> 14:00        |
|  |                                       |--until_time _[^t ^-> .]--> 16:00        |
|  |                                       |--time _[^t ^-> a]--> Friday             |
|  |--agent of _[^m -> a ?g]--> gnawing --object _[?g -> every ?n]---                |
|  |--part _[^m <- ?n]--------> nail <------------------------------|                |
--------------------------------------------------------------------------------------
 |
 |--description _[. -> .]--> "2% of men that travel from Chicago to Boston from 14:00 to 16:00
                              on a Friday, gnaw all their nails"   // "_[. -> .]" is optional


//1. One alternative way in FL-DF:
man --agent of _[= ?d1,  2% ^m ^-> a ^t,  //"= ?d1" (or "?d1"): reference for this relation
  |             ]--> travel --from_place _[?d2,  any ^t ^-> .]--> Chicago
  |                       |--to_place _[?d3,  ^t ^-> .]--> Boston
  |                       |--since_time _[?d4,  ^t ^-> .]--> 14:00
  |                       |--until_time _[?d5,  ^t ^-> .]--> 16:00
  |                       |--time _[?d6,  ^t ^-> a]--> Friday 
  |--agent of _[?d8,  ^m -> a ?g]--> gnawing --object _[?d7,  ?g -> every ?n]---  
  |--part _[?d9, ^m <- ?n]---------> nail <------------------------------------|

{a description ?d1, a description ?d2, a description ?d3, a description ?d4, a description ?d5, 
 a description ?d6, a description ?d7, a description ?d8, a description ?d9
} --part of _[distr . -> a ?d]--> description --description of _[. -> a ?s]--> situation
                                                                                      ^
"2% of men that travel from Chicago to Boston                                         |
 from 14:00 to 16:00 on a Friday, gnaw all their nails" --description of _[. -> ?s]---|

0.o.tr. À propos des questions qui/quoi/quand/où/comment

Exercice :
- Catégorisez des types de relations pouvent répondre aux questions
  "who/what/why/where/when/how". Utiliser 'wh-/how_relation' pour identifier
  leur plus proche supertype commun. Qu'en déduisez-vous concernant l'utilisation
  des "wh-/how relations" pour l'élicitation, la catégorisation, et la
  normalisation des connaissances (-> leur comparabilité et donc leur exploitabilité) ?

wh-/how_relation _(*)  (^this type permits to categorize relations based on
 who/what/why/where/when/how questions; this is a subjective and ineffective
 way of categorizing relations;
 since the meaning of these questions are subjective and not normalizing, 
 they should not be used for knowledge elicitation^)
 > how_relation
   who_relation  what_relation  why_relation  where_relation  when_relation;

   how_relation
    > instrument  method  sub_process 
      (how_much_relation
        > duration  relation_to_attribute_or_quality_or_measure 
          relation_from_collection_to_number);

   who_relation (^e.g., agent  initiator,  patient, experiencer, recipient^)
    > relation_to_participating_agent  relation_to_modified_agent
      owner  generator  creator;  //for normalization purposes, do not use
      //these last three types nor relations from agent to process

   what_relation
    > object/result  process_attribute  mereological_relation  method 
      relation_from_collection  relation_to_collection  contextualizing_relation;

   why_relation (^e.g., cause, method, goal, triggering_event,  ...^)
    > relation_from_process_to_state  relation_from_process_to_event;
      //for normalization purposes, do not use relations to process

   where_relation (^e.g., where, from/to where, ...^)
    > relation_to_spatial_entity   part_of  member_of; 
      //for normalization purposes, do not use '...-of' relations

   when_relation
    > relation_to_temporal_entity

0.o.tr. Exemple de formulaire d'entrée semi-formel pour un process

Process type [give an identifier (e.g., wn#travel) or an informal name (e.g., "travel")]:

Where does it occur [e.g., in FL, `from:wn#Paris, to:"Berlin", via: ["Strasbourg", "Bohn"]´]:

When does it occur [e.g., `from:1/1/2001, to:31/12/2001,
              frequency: "every 2nd Tuesday of the month", duration: 8 wn#hour´]:

After/before which process(es) does it occur [e.g., `triggering_event: wn#full_moon´]:

After/before which state(s) does it occur [e.g., `precondition: "John is at Paris"´]:

Who does/experiences/... it [e.g., `agent: JohnDoe.info, experiencer: JohnDoe.info´]:

What does it use/generate/... [e.g., `material: "100 kg of fuel", tool: a wn#train´]:

Which (direct) subprocesses does it involve [e.g., `subprocess: pm#train_changing´]:

Where is it described [e.g., `description: ThomsonSalesmanTravelsToBerlin.info´]:

0.o.meta. Méta-propriétés: (anti/semi-)rigidité, ...

Type/propriété essentiel(le) (alias, toujours nécessaire) pour un objet (type ou individu):
l'objet doit avoir cette propriété (i.e., doit avoir le type représentant cette propriété) dans tous les "mondes possibles (imaginables)".
<- notions de "monde" et de "nécessité" de la logique du second-ordre;
<- notion de "définition" dans les langages dont l'expressivité est inférieure à la logique du 2nd-ordre.
E.g., la propriété "avoir un cerveau" peut être vue (définie) comme essentielle pour tout mammifère vivant: "every mammal must have a brain in every possible world" ou `any mammal necessarily has a brain´.
La propriété "être dur" ne peut être essentielle pour les éponges car une éponge peut devenir molle.

Type/propriété rigide [+R property/type]:
propriété essentielle à toutes les instances possibles de cette propriété
(en d'autres termes, toute instance de cette propriété a nécessairement cette propriété), i.e.,
p est rigide <=> nécessairement, si p est toujours vrai dans un monde alors p est vrai dans tous les mondes.
Formellement:   rigide(p) <=> (□ ∀x ( p(x) => □ p(x) ) )
E.g. "avoir un cerveau" n'est pas une propriété rigide car il est possible d'imaginer que des objets qui ont un cerveau dans notre monde n'en aient pas dans un monde imaginaire. Par contre, "être ou avoir été un mammifère" ou "avoir des mammelles pour une mammifère femelle" sont des propriétés rigides.

Type/propriété semi-rigide [-R property/type]: propriété pouvant être essentielle pour certains objets et pas pour d'autres.
E.g., "avoir un cerveau" est une propriété semi-rigide car certains (types d')objets doivent en avoir et d'autres non.

Type/propriété anti-rigide [~R property]: propriété jamais essentielle.
Un type anti-rigide ne peut généraliser que des types anti-rigides.
E.g., une ontologie ne peut spécifier que le type "étudiant" généralise le type "personne" si l'auteur de ce dernier type considère que "être une personne" est une propriété rigide.

Ces notions sont recommendées entre autres par Ontoclean (une méthodologie pour créer/analyser des ontologies): afin de préciser le sens d'un type et d'éviter certaines erreurs de modélisation, tout type devrait être spécifié (directement ou non) comme instance de ontoclean#rigid_type (R), ontoclean#not-rigid (-R) ou ontoclean#anti-rigid_type (~R)

Exercice de contrôle
- un type anti-rigide est-il aussi semi/non-rigide ?
- pour chacun des types suivants, indiquez ceux qui sont non-rigides ou anti-rigides :
  thing, place, country,   group, social_entity, amount_of_matter,
  physical_object, currently_or_previously_living_thing, animal, vertebrate, person, fruit, apple,
  red_thing, red_apple, agent, legal_agent, food, butterfly, caterpillar.

1) Oui
2) -R: red_thing,
   ~R: red_apple, agent, legal_agent, food, caterpillar, butterfly

0.o.meta. Méta-propriétés: ..., identité, ...

Type/propriété (d'un objet) suppléant un critère d'identification [(+I) +O(wned by an objet) property/type]:
propriété fournissant un critère suffisant pour distinguer l'objet (à qui appartient cette propriété) d'un autre objet
(critère nécessairement commun à 2 objets identiques, e.g., un même objet à différentes dates).
L'expression "suppléant un critère" veut dire qu'un tel critère n'est pas hérité d'une généralisation de cette propriété: il n'appartient qu'à cette propriété et à ses spécialisations.
Exemple: peut-on avoir les relations suivantes ?
    time_duration
        example:   "60 minutes"   "1 hour",   //identical objects
        > (interval_of_points_in_time
                example: "13:00-14:00, on the 13/08/2012"
                               "13:00-14:00, on the 17/03/2008");
La relation '>' ci-dessus est impossible car des intervals de points dans le temps sont toujours différents même s'ils ont la même durée, alors que deux durées peuvent être identiques. En d'autres termes, un interval de points dans le temps n'est pas une durée, il a une durée.
Plus précisément, deux intervals de temps sont les mêmes si et seulement si ils ont les mêmes parties. Ce critère est connu sous le nom de "extensionalité méréologique". Il s'applique à toutes les choses qui peuvent être vues comme la somme de leurs parties. Le type "interval_of_points_in_time" est donc +O, comme l'est le type "amount of matter". En effet, une "quantité-portion de matière" réfère à par exemple à 5 litres particuliers d'eau ou 3,5 kilogrammes particuliers d'argile. Ces litres/kilogrammes particuliers ne réfèrent pas à une substance ("eau", "argile"), ni à un volume ou un poids.
Même si le critère d'identification est difficile à définir, le fait de noter que deux objets ont des "propriétés essentielles" différentes (et donc des critères d'identification différents même si non définis) permet de les différencier. E.g., pour une "statue d'argile", sa forme est une "propriété essentielle" mais pour la "quantité-portion d'argile" qui compose cette statue cette forme n'est pas une "propriété essentielle" (la même portion d'argile peut être ré-utilisée pour une autre statue). Ces deux types objets sont donc différents. Ils doivent donc être distingués dans une ontologie et lors d'une représentation de connaissances.

Type/propriété (d'un objet) "portant un critère d'identification" [+I-O (or, simply, +I) property/type]:
comme ci-dessus sauf que le critère est hérité d'une généralisation de cette propriété.

Type/propriété (d'un objet) ne portant pas de critère d'identification [-I(dentifying) property/type].

Dans diverses méthodologies (dont OntoClean), les types +O ou +I sont appelés "sortals".
Un sortal ne peut généraliser que des sortals et son critère est hérité par ces sortals.
Tout individu devrait être instance d'au moins un sortal. Ceci rejoint le motto de Quine: "No entity without identity" [Quine, 1969].
Si une chose est instance de différents types, ceux-ci doivent être généralisés par un type portant un critère d'identification pour cette chose.
Ainsi, toute chose doit instancier un unique "type plus général" portant son critère d'identification.
Dans les ontologies dites 3D, chaque (type d')objet est associé à un point dans le temps, afin de ne pas avoir à associer des "types (et critères d'identification) exclusifs" à un même objet qui évolue dans le temps (e.g., le type "student" puis le type "non-student", ou encore le type "caterpillar" puis le type "butterfly"). Dans les autres ontologies, il faut utiliser des contextes pour gérer ces cas ou créer des objets 3D.

Exemple de modélisation incorrecte détectée via de telles notions, suivie d'une correction.

Exercice de contrôle
- un type +O est-il aussi +I+O si "+I" n'est pas l'abréviation de +I-O ?
- un type +O est-il aussi "+I" si "+I" est l'abréviation de +I-O ?
- donner au moins un critère d'identification pour distinguer deux triangles.
- pour chacun des types suivants, indiquez s'il est +O, +I ou -I :
  thing, amount_of_matter, place, country, geographical_region,
  group, group of people, social_entity, organization,
  physical_object, living_thing, animal, lepidopteran, vertebrate, person, fruit, apple,
  red_thing, red_apple, agent, legal_agent, food, caterpillar, butterfly.

- oui
- non
- taille de chacun des 3 cotés de chaque triangle
- +O: amount_of_matter, place, country, physical_object, living_thing,
      animal, lepidopteran, fruit, apple, organization, group, person       
  +I-O: food, red_apple, vertebrate, group of people,
        legal_agent, geographical_region, caterpillar, butterfly
  -I: thing, agent, red_thing, social_entity

0.o.meta. Méta-propriétés: ..., unité, ...

Critère d'unité (CU) d'un objet: une ou plusieurs "relations d'unification" exprimant ce qui relie les sous-parties de l'objet, et permettant donc de savoir
- pourquoi l'objet est un "tout" [whole] plutôt qu'une somme arbitraire de choses, et
- ce qui ne peut faire partie de l'objet.
Il y a différentes sortes de "tout" (et donc de relations d'unification), e.g., "topologique" (morceau de charbon, ...), "morphologique" (constellation, ...) et "fonctionnel" (marteau, bikini, ...).

Type/propriété unifiant homogène [+U property/type]: dont toutes les instances portent un même CU, que celui-ci soit connu ou pas. Exemple de types +U: ocean

Type/propriété unifiant hétérogène [-U property/type]: dont toutes les instances portent un CU (et sont donc chacune un "tout") mais pas nécessairement le même. Un exemple d'un tel type est "legal_agent" si à la fois des personnes et des companies (avec différent CUs) peuvent être de ce type.

Type/propriété non-unifiant [~U property/type]: dont au moins une instance ne porte pas de CU. E.g., "amount_of_matter" et "amount_of_water" puisque leurs instances ne sont pas nécessairement des touts (rien ne permet de "reconnaitre" une sous-partie de ces instances; toute sous-partie d'une instance d'un de ces types est d'ailleurs aussi une instance de ce type).

L'UC d'un type doit être hérité par ses spécialisations.
Un type ~U ne peut avoir que des types ~U pour spécialisations.
Les charactéristiques +U et ~U (mais pas -U) sont donc héritées dans la hiérarchie de spécialisation.

Exercice de contrôle
- un type ~U est-il aussi -U ?
- pour chacun des types suivants, indiquez s'il est +U, -U ou ~U :
  thing, amount_of_matter, place, country, geographical_region,
  group, group of people, social_entity, organization,
  physical_object, living_thing, animal, lepidopteran, vertebrate, person, fruit, apple,
  red_thing, red_apple, agent, legal_agent, food, caterpillar, butterfly.

1) non
2) +U: country, social_entity, organization, physical_object,
       living_thing, animal, vertebrate, person, lepidopteran, caterpillar, butterfly,
       fruit, apple, red_apple
   -U: thing, place, agent, legal_agent, geographical_region, red_thing
   ~U: amount_of_matter, food,  group, group of people

0.o.meta. Méta-propriétés: ..., dépendence, ...

Type/propriété non-dépendant [-D property]: dont l'existence d'au moins une de ses instances n'implique pas l'existence d'une autre chose.

Type/propriété dépendant [+D property]: chacune de ses instances implique l'existence d'une autre chose. Ce(tte) propriété/type est non-rigide.
La charactéristique +D (mais pas -D) est héritée dans la hiérarchie de spécialisation.

Type/propriété spécifique constamment dépendant: chacune de ses instances implique l'existence d'un objet particulier, différent pour chaque instance, e.g., l'existence d'une personne est "dépendante" de son cerveau.

Type/propriété générique constamment dépendant: chacune de ses instances implique l'existence d'un objet, e.g., l'existence d'un élève dépend de l'existence d'un enseignant.

Attribution: type de choses qui, tel "red_thing", ont un certain attribut (e.g., couleur, poids, ...) avec un certain type de valeur (e.g., rouge, rouge clair, 28 à 34 kg, ...). Les attributions dépendent des attributs. Ils ont peu de contraintes associées et sont difficiles à classer sans répéter le classement de ces attributs et/ou de leurs valeurs. Il vaut donc mieux associer directement des attributs à des individus et ainsi éviter de définir des attributions.

[Phased sortal]: type anti-rigide dont les instances peuvent changer de "critère d'identification" (et donc de type) au cours de leur existence, e.g., le type "student" puis le type "non-student", ou encore le type "caterpillar" puis le type "butterfly".
Comme tout sortal doit être instance d'au moins un type de sortal, le terme "lepidopteran" doit être utilisé pour généraliser "caterpillar" et "butterfly".
De manière similaire, un "pays" (au sens géo-politique) peut disparaitre (il est dépendant d'un contexte politique) sans que la région géographique de ce pays ne disparaisse (celui-ci n'est pas dépendant d'une autre entité: il n'a pas de critère d'unité). Les deux notions sont donc à distinguer.

0.o.meta. Méta-propriétés: ..., dépendence et rôle, ...

Rôle: type charactérisant la manière dont une chose peut participer à une situation (état ou processus) et donc être dépendant de cette situation (e.g., de nombreux sortals peuvent être vues comme "nourriture" et donc être aussi classés en fonction de ce rôle). Comme il s'agit d'une participation "possible" et non systématique, ce type est anti-rigide, et donc ne peut généraliser un type rigide. E.g., "animal" ne peut spécialiser "agent" (d'un processus): un animal n'est pas un agent, il "peut" être un agent. De même, "legal_agent" ne peut généraliser "person" et "organisation". Un rôle n'a pas de critère d'identification associé.

Exemple de modélisation incorrecte détectée via de telles notions, suivie d'une correction.

Exercice de contrôle
- parmi les types suivants, indiquez ceux qui sont +D :
  thing, amount_of_matter, place, country, geographical_region,
  group, group of people, social_entity, organization,
  physical_object, living_thing, animal, lepidopteran, vertebrate, person, fruit, apple,
  red_thing, red_apple, agent, legal_agent, food, caterpillar, butterfly.

Solutions:
  +D: country, person, agent, legal_agent, food
  Pour les autres types, voyez l'ontologie ci-dessous qui est
  indexée avec les diverses méta-propriétés jusqu'ici présentées
  (cliquez sur la figure pour une explication détaillée).

  

0.o.meta. Concepts méta-ontologiques: ..., mixin & 1er résumé

[Mixin/dispersive types]: types ayant différent critères d'identité.

Résumé des types [universals] d'entités-qui-ne-sont-pas-des-attributs [Substantial universals] proposés par OntoUML, un langage de modélisation d'ontologies
(pour une explication détaillée, cliquez sur la figure et allez à la page numérotée "106" dans le document téléchargé (page 129 de ce PDF).

0.o.meta. Concepts méta-ontologiques: ..., résumé

Résumé des types de second-ordre [universals] pour des entités (endurants)
(pour une explication détaillée, cliquez sur la figure et lisez la section 2.2) :

//In FL and reusing the terms introduced in the 0.o.tc Section (note: in the UFO/OntoUML methodology, // any type should be categorized as instance of 1 of those in bold below, yellow above) : ufo#Universal = Type, //2nd order type > partition { (ufo#Perdurant_Universal = Situation_type) //not in the above figure (ufo#Endurant_Universal = Entity_type, //any individual (i:): wholly present when present > partition { (ufo#Moment_Universal //i: inheres-in (existentially-depend-on) an Endurant > partition //e.g.: a person's headache, a covalent bond between atoms { (ufo#Intrisic_Moment_Universal //i: inheres in *1* indiv, e.g., Apple's color > (ufo#Mode_Universal //e.g.: John's desire, Intention, Perception, = Characteristic-or-attribute-or-measure_type, // Symptom, Skill > ufo#Externaly_Dependent_Mode_Universal //i: part of a Relator and ) ) // externaly dependent on an Endurant ufo#Relator_Universal //i: mediates 2..* Endurant, composed of } ) // 2..* Externaly_Dependent_Mode, e.g., Marriage, Service agreement, // Enrollment, Employment, Presidential mandate (ufo#Substantial_Universal //i: existentially-independent Endurant > partition { (ufo#Sortal_Universal > partition //+I (ou +I+O) { (ufo#Rigid_Sortal > partition //i: if exists, necessarily so { (ufo#Sustance_Sortal > excl { ufo#Kind //+I for unique instance, e.g., Person //parts are distinct, e.g., "CPU functional_part of: a computer" ufo#Collective //parts not distinguished, e.g., Forest } ) ufo#SubKind //e.g.: Man < Person (+I supplied by Person) } ) (ufo#AntiRigid_Sortal > partition //e.g.: Student, Husband { ufo#Phase //relationally independent, e.g., Child < Person ufo#Role //relationally dependent, e.g., Student < Person } ) // Student mediator/relator: Enrollment } ) (ufo#Mixin_Universal > partition //aggregates properties of distinct Sortals { (ufo#Rigid_Mixin //e.g., Work_of_Art, People, Organization, Law > ufo#Category //rigid and relationally independent ) //e.g., Furniture > Table Chair; Physical_Object (ufo#NonRigid_Mixin //e.g., Insurable, Contract ? > (ufo#NonRigid_Mixin > ufo#RoleMixin //e.g., Customer > Individual_C Corporate_C ) ) } ) } ) } ) };