0.1. Buts de la Représentation de Connaissances (RC) [KR]
0.2. Exemples de "processus liés à la représentation de connaissances" (Pr_RCs) [KPs]
En anglais (avec "K." abréviant "Knowledge") :
- K. Acquisition, K. Extraction, K. Mining, K. Discovery, K. Classification,
K. Categorization
- K. Retrieval, K. Comparison, K. Mapping, K. Matching, K. Merging,
K. Evaluation, K. Validation, K. Analysis
- K. Representation, K. Normalization, K. Organization, K. Partitioning,
K. Modularization, K. Sharing
- K. Engineering, K. Modelling, K. Management, K. Edition, K. Exploitation
- K. Import, K. Interpretation, K. Translation, K. Export, K. Generation
- K. Inferencing (reasoning, deduction, abduction, induction, analogy/case-based,
Bayesian/fuzzy, monotonic, ...)
→ pas de relations (de spécialisation, sous-partie, ...)
bien définies, intuitives, non-arbitraires
→ pas de catégorisation (de Pr_RCs) passant à l'échelle
Heureusement, une catégorisation des objets sur lesquels portent ces Pr_RCs peut passer à l'échelle.
0.3. Types de plus haut niveaux
En FL :
Thing = owl#Thing,
\. p{ (
- Situation = ^"Thing occurring",
-
\. v_p{ State = ^"Situation not seen as a process",
(
- Process
-
\. (Knowledge-representation_related_process = KP)
)
}
)
(
- Entity
-
\. p{ (Characteristic_or_attribute_or_measure
\. Logic-or-computational_characteristic )
(Endurant //Thing retaining its identity across points in time
\. p{ (Spatial_entity
= Entity_with_dimension-or-location_in_a_space)
Non-spatial_endurant
})
}
)
}.
- En Formalized-English :
pm#Thing
is equal
to owl#Thing
and
has for `subtype partition´
the set
{ `
- Situation which is equal to ^"Thing occurring"
-
and which has for `viewpoint subtype partition´ the set
{ `State = ^"Situation not seen as a process"´,
`
- Process
- which has for
subtype `Knowledge-representation_related_process
which is equal to KP
´
}
´,
`
- Entity
- which has for `subtype partition´ the set
{ `Attribute_or_characteristic_or_measure which has for
subtype Logic-or-computational_characteristic´,
`Endurant which has for `subtype partition´ the set
{ `Spatial_entity which is equal to
Entity_with_dimension-or-location_in_a_space´,
Non-spatial_endurant
}´
}
´
}.
En UML étendu et concis :
Thing = owl#Thing
△
____|________
{complete, disjoint}
| |
- Situation
-
= ^"Thing occurring"
- Entity
-
△ {complete, disjoint}
________________|__________________________
| |
Attribute_or_characteristic_or_measure Endurant
△ △ {complete, disjoint}
| ____|____________________
Logic-or-computational_characteristic | |
Spatial_entity Non-spatial_endurant
En UML horizontal, étendu et concis :
Thing = owl#Thing
◁—P—
- Situation
- = ^"Thing occurring"
◁—V_P—
State = ^"Situation not seen as a process"
Process
- Entity
- ◁—P—
Attribute_or_characteristic_or_measure
- Endurant
- ◁—P—
Spatial_entity
Non-spatial_endurant
1. Les "objets de description" [Description Objects]
En FL :
Description_content-or-instrument-or-result-or-container
= Description_object, /
^ Non-spatial_endurant,
\. p{ Description_semantic-content
(
- Description_instrument-or-result = Information_object
- ,
\. p{ (Expression \. Type)
(Sentence = Statement)
}
c{ (Description_instrument
\. e{ (Language \. e{ Formal_language Informal_language } )
(Deductive_system = Proof_system Formal-logic_system)
(Formal_system
part: 1..* Formal_language 1..* Deductive_system )
})
(Description_result = Represented_information,
\. v_p{ (Represented_data \. Database)
(Represented_Knowledge = Knowledge_representation KR, \. KB)
}
(Specification
\. p{ Entity_specification
(Situation_specification
\. (Process_specification
\. (
- Software_or_software-specification
-
\. p{ Software_specification
(Software
\. p{ (Software_for_KPs
\. (Knowledge_management_system
= KBMS,
object: 1..* KB )
^`Software for evaluating
logic or computational
characteristics´ )
(Software_not_for_KPs
\. (Database_management_system
= DBMS,
object: 1..* Database
) )
})
}
) ) )
}) )
}
)
(Description_container \. e{ File Memory_area })
}.
1.0. Langages formels (= modèles et/ou notations)
1.1. Expressions (types, ...) / phrases (affirmations, procédures, règles, bases, ...)
La plupart des concepts utilisés à propos de systèmes formels (dont celles d'Anil, Fred, ...)
sont des sous-types de Description_instrument-or-result
ou de Logic-or-computational_characteristic (cf section 2.1).
Une fois ces types définis, les méthodes/règles de résolutions de problèmes
peuvent être représentées via des définitions de ces types
ou de types de processus de résolutions de problèmes.
Étapes pour la création d'une RC pour un partage de connaissances passant à l'échelle :
- Entrée directe ou via
1. la génération (par LLM, ...) de RCs pour une expression/phrase donnée en langage naturel,
2. la présentation en FE/FL/... des RCs, et
3. la confirmation/correction d'une RC
- Vérification de la cohérence, complétude et normalisation de la RC / BC, e.g. :
* toute paire d'expressions/phrases doit être reliée par une relation de
spécialisation+implication ou d'exclusion ou d'égalité
* toute phrase doit être soit une définition, soit une observation, soit une inférence
* toute observation doit être complètement contextualisée (→ temps, espace, auteur, modalité)
- Distribution de RCs/requêtes entre bases "nexus":
1. publication sur le Web d'une RC spécifiant exactement le "domaine" de ce "nexus" :
ce que cette base s'engage à admettre/stocker sans restriction (source/expressivité/..)
→ complétude ( / RCs existantes) d'un nexus pour son domaine
2. - pour chaque RC à la limite externe de ce domaine :
lien vers une RC dans un autre "nexus"
- retransmission (à un autre "nexus") de toute partie d'addition/requête non traitable en interne
→ complétude de l'ensemble des nexus pour leurs domaines
1.1.1. Règles/bases/... pour le partage de connaissances et la coopération
1.1.2. Logiciels(+applications) pour les Pr_RCs (au LIM)
Software_at_least_partially_created_by_at_least_one_member_of_the_LIM_of_the_UR
/^ Software,
\. p{ (Software_for_KPs_at_least_partially_created_by_at_least_one_member_of_the_LIM_of_the_UR
/^ Software_for_KPs,
\. (^`Software for evaluating logic or computational characteristics
created_by_at_least_one_member_of_the_LIM_of_the_UR´
/^ ^`Software for evaluating logic or computational characteristics´,
\. ^`The NTI+cTI software ranked 1st at TermComp 2022, 2023´ )
(KBMS_created_by_at_least_one_member_of_the_LIM_of_the_UR /^ KBMS,
\.
WebKB-1 WebKB-2
IKBS )
)
(Software_not_for_KPs_at_least_partially_created_by_at_least_one_member_of_the_LIM_of_the_UR
\. ^`User Interface created_by_at_least_one_member_of_the_LIM_of_the_UR´
)
}.
2.1. Caractéristiques logiques/computationnelles
Logic-or-computational_characteristic
\. c{ //'c': complete, not exclusive
(
- Formal-logic-system_characteristic
-
.[0..1 Formal-logic_system ?ls, 0..1 Property ?p -> ?attr] ?attr
\. (
- Logical-system_soundness
-
:=> "In a sound logical system ?ls, every satisfiable theory is consistent
(i.e., does not lead to a logical contradiction),
but the converse only holds if ?ls is complete"
\. (Logical-system_soundness_wrt_a_property
:= "a logical system ?ls is sound with respect to a property
if each of its theorems has that property",
\. (Logical-system_completeness_relative-to-a-property _(Semantical_validity)
= Logical-system_weak_soundness, //Tautologousness
:= "every sentence (well-formed formula) ?s that can be proved in the logical system ?ls
is logically valid wrt. the semantics of ?ls
(i.e, is also true on all interpretations or structures of the semantic theory for
the language ?l upon which ?ls is based): all its theorems are tautologies;
formally: ⊦?ls ?s; → ⊧?ls ?s;",
converse: Logical-system_semantic-completeness, //see below
\. (Logical-system_strong-soundness
:= "any sentence ?s of the language ?l upon which the logical system ?ls is based
that is derivable from a set ?ss of sentences of ?l
is also a logical consequence of ?ss, in the sense that any model that
makes all members of ?ss true will also make ?s true;
formally: ?ss ⊦?ls ?s → ?ss ⊧?ls ?s"
) ) )
)
(- Logical-system_completeness
-
\. (Functional_completeness
:= "a logical system is functionally complete if it has the logical connectives to
express all predicates, hence all 16 truth tables")
(Logical-system_completeness_wrt_a_property
:= "a logical system ?ls is called complete with respect to a particular property ?p
if every formula having the property can be derived using that system,
i.e. is one of its theorems",
\. (Logical-system_completeness_relative-to-a-property _(Semantical_validity)
= Logical-system_semantic-completeness, //Tautologousness
:= "?ls can derive every tautology (i.e., every formula ?s that is true):
all its tautologies are also its theorems; formally: ⊧?ls ?s → ⊦?ls ?s",
//Gödel's completeness theorem establishes semantic completeness for first-order logic
\. (Logical-system_refutation-completeness
:= "for every unsatisfiable set (of formulas) ?ss, the logical system ?ls
is able to derive false; formally: ?ss ⊧?ls ⊥ → ?ss ⊦?ls ⊥"
\. (Logical-system_strong-completeness
:= "for every set of premises ?ss, any formula ?s that semantically follows
from ?ss is derivable from ?ss; formally: ?ss ⊧?ls ?s → ?ss ⊦?ls ?s" ) )
(Logical-system_syntactical-completeness
= Logical-system_deductive-completeness Logical-system_maximal-completeness
Logical-system_negation-completeness,
:= "for each sentence (closed formula) ?s of the language of the
logical system ?ls, either ?s or ¬?s is a theorem of ?ls" ) ) )
)
(Logical-system_computational-characteristic
\. Logical-system_decidability )
)
(
- Computational_characteristic
-
.[0..1 Software_or_software-specification ?ls, 0..1 Property ?p -> ?attr] ?attr
\. ne{ (Complexity-or-decidability-or-termination_related_characteristic
\. Logical-system_decidability
Program_termination
Computational_complexity )
(Software_correctness_wrt_a_specification .[0..1 Software, Software_specification ?ss
-> ?attr] ?attr
\= (Software_partial-correctness_wrt_a_specification
:=> "if an answer is returned, it is correct",
\. (Software_total-correctness_wrt_a_specification
:=> "an answer is returned and it is correct" ) ),
\. (Software_functional-correctness_wrt_a_specification
= ^"Software_correctness_wrt_a_specification restricted to inputs and outputs:
for each input, the software must produce an output satisfying the specification" ) )
}
Logic-program_algorithmic-characteristic
)
}.
3. Conclusion : usages possibles du type de catégorisation introduite dans ce document
Valorisation puisque l'approche est une extension de l'approche "FAIR" qui, elle, ne fait que
rendre des ensembles de données accessibles et les indexer par quelques méta-données →
- Facilité de recherche mais de BdDs entières (au lieu de connaissances particulières)
- Accessibilité : les licences sont clarifiées, mais pas de contrôle d'accès sur/par des RCs
- Interopérabilité : usage de standards, mais cela ne reste que des données
- Ré-utilisabilité : simple répétition des points ci-dessus
Coopération entre chercheurs du LIM ou d'autres laboratoires
(e.g. ceux de l'Observatoire des Sciences de l'Univers de La Réunion : OSU-R),
suite à la représentation et comparaison de connaissances et problématiques de ces chercheurs
Utilisation pour l'enseignement puisque
