Ce cours (préparé par Dr. Philippe MARTIN) introduit quelques apports du partage des connaissances via l'ingénierie des connaissances [knowledge engineering] (qui est à distinguer de la "gestion des connaissances, au sens commun" et encore plus du "management des connaissances") pour la veille technologique, la veille stratégique, la veille concurrentielle et donc l'intelligence économique. 1. Informations et connaissances 1.1. Définitions générales 1.1.1. Abréviations, Chose, Objet|Information 1.1.2. Information: données vs. connaissances 1.1.3. Exemples de représentations de connaissances 1.1.4. Lexical/structurel/sémantique 1.1.5. Terme/phrase formel(e)/semi-formel(le)/informel(le) 1.1.6. Base de données/connaissances 1.2. L'intérêt d'utiliser des BCs au lieu de BdDs 1.3. La difficulté de créer des BCs 1.4. Organisation par généralisation/implication/exclusion/correction 1.4.1. Organisation de types de concepts 1.4.2. Organisation de RCs par généralisation/implication/exclusion 1.4.3. Exemples de corrections additives 1.4.4. Types de concept de plus haut-niveau essentiels 1.4.5. Types de relation essentiels - Graphique 1.5. Tâches dites "de gestion de connaissances" et leurs supports 1.6. Web 2.0/3.0/sémantique, web de données/connaissances 1.7. Introduction à des protocoles de partage de connaissances 1.7.1. Protocole d'édition de BC par corrections additives seulement 1.7.2. Protocole de réplication entre BCs 2. Exercices 2.1. Discussion structurée: exemples 1 2.2. Discussion structurée: exemples 2 2.3. Exemples de fichiers/sujets liés à la coopération 2.4. Autres exemples de sujets
E.g.
(latin: exempli gratia): "par exemple".
I.e. (latin: id est):
"c'est-à-dire".
Vs.: "versus".
/: "ou bien" ( "ou" est non-exclusif, par défaut).
|: (quasi-)"alias" (entre 2 termes, dans le contexte où
ils sont définis).
Rappel:
Chose [thing]: tout ce à quoi quelqu'un peut penser est une chose.
Donc, tout ce qui est (implicitement ou explicitement) logiquement quantifié est une chose.
E.g.: "une ville" (→ utilisation du quantificateur existentiel
"il existe au moins une"), "Londres", "3 personnes".
Objet (d'information)|information [(informational) object,
resource]: (groupe de)
symbole(s)|identificateur(s)|identifiant(s)|mot(s) référant à une chose (ou donc à plusieurs).
S'il y a un groupe (décomposable), la composition suit une
syntaxe (formelle ou informelle).
Dans ce cours, compte-tenu des définitions des termes
"donnée" [data] et "connaissance" [knowledge],
"Objet (d'information)|information" est leur généralisation:
"Information = donnée ou bien connaissance".
Dans ce cours, contrairement à d'autres définitions souvent moins précises,
(Représentation de) connaissance (RC) [knowledge (representation)]:
information qui est, au moins partiellement, représentée et organisée
Exemples dans les 2 pages suivantes.
Donnée [data]: information qui n'est pas une RC.
Base|répertoire d'informations
[information repository]:
base de données (BdD) ou bien base de connaissances (BC).
Système de gestion d'information: système de gestion de BdDs (SGBD) [DBMS] ou bien système de gestion de BCs (SGBC) [KBMS]; attention (cf. section 1.9), la plupart des "systèmes à base de connaissances" (SBCs) et des "systèmes de gestion de connaissances" (SGCs) sont des SGBDs et non des SGBCs tels qu'ici définis.
En: By definition, a flying_bird_with_2_wings is a bird that flies and has two wings.
LP: Flying_bird_with_2_wings (b) :=
Bird(b) ∧ ∃f Flight(f) ∧ agent(f,b)
∧ ∃w1,w2 Wing(w1) ∧ Wing(w2) ∧ part(b,w1) ∧ part(b,w2) ∧ w1!=w2
FE: any Flying_bird_with_2_wings is a Bird that is agent of a Flight and
has for part 2 Wing.
FL: Flying_bird_with_2_wings = ^(Bird agent of: a Flight, part: 2 Wing).
RDF+OWL2 / Turtle:
:Flying_bird_with_2_wings owl:intersectionOf
(:Bird [a owl:Restriction; owl:onProperty :agent; owl:someValuesFrom :Flight]
[a owl:Restriction; owl:onProperty :wingPart; owl:qualifiedCardinality 2]);
| UML_model / UML_concise_notation: |  |
En: On March 21st 2016, John Doe believed that in 2015 and in the USA,
at least 78% of adult healthy carinate birds were able to fly.
FL: [ [ [ [ [at least 78% of Adult Healthy Carinate_bird is able to be agent of: a Flight ]
place: USA ] time: 2015 ] believer: John_Doe ] time: 2016-03-21 ].
FE: ` ` ` ` `at least 78% of Adult Healthy Carinate_bird is able to be agent of: a Flight´
at place USA´ at time 2015´ for believer John_Doe´ at time 2016-03-21´.
IKLmE / Turtle:
[rdf:value
[rdf:value
[rdf:value
[rdf:value
[rdf:value [rdf:value [:agent_of [a :Flight]
]; pm:q_ctxt [quantifier "78to100pc";
rdf:type :Adult, :Healthy,
:Carinate_bird ]
]; pm:ctxt [:modality :Physical_possibility]
]; pm:ctxt [:place :USA]
]; pm:ctxt [:time "2015"]
]; pm:ctxt [:believer :John_Doe]
]; pm:ctxt [:time 2016-03-21] ].
Lexical: relatif à la décomposition d'un (groupe de) mot(s)|symbole(s) en ses(leurs) composants, généralement des lettres. E.g.:
Structurel: relatif à
Sémantique: relatif à une RC, i.e. à une représentation (partielle/totale)
du ou des sens d'un objet.
Phrase|formule|RC [formula|sentence|statement|KR]: "groupe de mots|symboles" (→ objet d'information structuré) qui peut-être affirmé ou nié et donc qui dénote|représente une "situation" (i.e., soit un état, e.g. "Jean est assis", soit un processus, e.g. "Jean marche"). C'est donc aussi quelque chose qui a ou peut avoir une valeur de vérité (e.g., vrai ou faux) mais d'autres choses peuvent avoir une valeur de vérité, e.g. les variables booléennes.
Terme|expression: (groupe de) mot(s)|symbole(s) (→ objet d'information) qui n'est pas une phrase. Un identificateur de phrase est un terme qui réfère à une phrase.
Interprétation/sémantique basée sur des modèles
(une des méthodes formelles pour définir une
sémantique): fonction associant
- chaque "terme" (au sens logique) utilisée à une chose, et
- chaque "phrase|formule|RC" à une valeur de vérité.
Terme/phrase formel(le):
terme ayant – par convention, déclaration ou construction –
un sens unique, e.g. un mot-clé ou "identificateur unique" dans un programme ou une
expression syntaxiquement correcte composée de termes formels plus élémentaires.
Attention, un sens particulier peut avoir de nombreux "identificateurs uniques".
Phrase|RC formelle: RC composée uniquement de termes formels.
RC partiellement formelle: RC incluant des termes formels et d'autres informels.
Syntaxe formelle:
syntaxe|grammaire composée de termes formels et selon laquelle
les termes non-terminaux|composés|structurés se décompose en termes primitifs|terminaux.
BC: ensemble d'identifiants (uniques ou pas) et de RCs les utilisant
parties: |
|
BdD: base d'informations qui n'est pas une BC.
parties: |
|
sous-types: |
- BdDs relationnelles/orientées-objet/déductives/associatives/... Notes: i) une "BdD RDF" est en fait une BC; ii) plus un SGBD (ou langage formel) est expressif, et plus sa base est normalisée, plus il se rapproche d'un SGBC. - documents XML/JSON/Latex - base de documents qui ne sont pas de BCs - données indexées par des identificateurs provenant de folksonomies / ontologies (e.g. comme dans les wikis sémantiques); Linked data – e.g. le Web Sémantique – réfère à un ensemble de BCs et aux données que ces BCs indexent ou relient). |
La possibilité de
Une BC, une fois construite, a beaucoup d'avantages par rapport à une BdD (sauf sur des critères de performances lorsque les types de requêtes sont connus) MAIS, comme pour un programme, créer une BC (ré-)utilisable est difficile !
Comme toujours : garbage in, garbage out !
FL-DF: Person FL: Person Man↗s £ s↖Woman subtype: Woman ↑t ( Man instance: James_Bond, James_Bond exclusion: Woman ).
Legend. "-s→": supertype (subtypeOf); "-t→": type (instanceOf); "£": exclusion
La RC ci-dessus vous paraît-elle correcte ?
L'utiliseriez-vous dans un(e) programme/BdD orienté(e)-objet ?
Pensez-vous que cette organisation passerait à l'échelle, i.e.,
pensez-vous que vous pourriez ajouter des types ou des instances
sans avoir à corriger certaines relations ?
Si non, quelles relations sont à corriger ?
Pour répondre aux questions précédentes
(et donc pour décider d'une hiérarchie dans un(e) programme/BdD orienté(e)-objet),
il faut généraliser.
Faisons-le. En supposant que les termes suivants de la liste ci-dessous
sont des termes formels qui
réfèrent au sens le plus commun que ces mots ont en anglais,
veuillez les organiser
– en FL-DF (FL Display Form) ou
FL (in its default Linear Form),
en faisant bien attention à la syntaxe et à l'indentation (vous allez voir que plus il y a de
termes, plus l'usage de FL-DF est compliqué !) –
via toutes les relations possibles de type
Note: vous pouvez abrévier "subtype: " par "\.".
Thing \. (Physical_thing \. (Animal \. (Dog instance: Diesel_the_dog The_most_famous_dog_named_Togo) //+ Dog_character ? (Human_being exclusion: Dog, \. (Man instance: Sean_Connery Brent_Spinner) //+ James_Bond ? (Woman exclusion: Man) (Human_person \. Natural|Physical_human-person_from_a_legal_aspect) ) ) ) (Person \. (Legal_person|entity exclusion: Natural|Physical_person_from_a_legal_aspect) (Natural|Physical_person_from_a_legal_aspect \. Natural|Physical_human-person_from_a_legal_aspect ) Human_person //+ Human_movie-character and Android_character ? ) (Movie_character //exclusion: Physical_thing ? \. (Human_movie-character instance: (James_Bond actor: Sean_Connery) ) (Android_character instance: (Data_the_android actor: Brent_Spinner) ) //exclusion: Human_movie-character ? (Dog_character instance: (The_character_of_the_most_famous_dog_named_Togo actor: Diesel_the_dog ) ) ).
Quelles relations de l'exemple initial sont fausses ?
Quelques règles importantes:
Entity £ Process Bird↗ ↖Counting //or: Flight Tweety↗
`no Bird can be agent of a Counting´ //false belief £ £ £ `at least 1 Bird ⇐ `at least 50% of Bird `every Clever Bird can be agent of can be agent of can be agent of a Counting´ a Counting´ a Counting´ ⇑ ⇖ ⇖↘ ⇗↙ `1 Bird `Tweety can be `every Bird can be agent of a Counting can be agent of that has for duration agent of a Counting´ at least 0.5 Hour´ a Counting´ ⇑//if ... ⇑↓ `Tweety has been agent of a Counting `every Bird|Bat can with duration at least 0.5 Hour´ be agent of a Counting´
Legend. "→": generalization that is not an implication, e.g. subtypeOf, instanceOf; "⇒": implication; "£": exclusion ( x £ y <=> ((x ⇒ ¬y) ∨ (x → ¬y)) ); "can": is able to; every sentence is in FE; relation types are in italics; concept types begin by an uppercase; the authors of terms, sentences and relations are not represented (unlike in next page); in FE, "every" (alias 100%) and "%" are for "observations" and hence imply "at least 1", whereas "any" is for a "definition" and hence does not imply "at least 1"; the distinction is important since observations may be false while definitions cannot (since agents can give any identifier they want to the types they create) and thus cannot be corrected or contradicted
u1#`every bird is agent of a flight´ | \c=> _[u3] | ↘ u3#`at least 75% of healthy flying_bird can be agent of a flight´ | ↑ |c=>/^ _[u2] |c=> _[u3] ⇐ ... ↓ | u2#`every bird can be agent of a flight´
Legend.
"------(typeID) _[userID]----→": relation of type typeID, created by userID
"u1#...": u1 is the author of the prefixed statement;
"c=>/^": correction and implication and semantic/structural generalization;
"c=>": correction and implication (no specialization/generalization);
"⇐": implication relation with destination on the left; "every": 100%
thing (^anything that exists or that can be thought about^) \. partition { (situation (^anything "occuring" in a real/imaginary region of time&space^) \. partition { state (^situation that is not a process^) (process (^situation "making a change"^) \. (problem_solving_process (^e.g., software_lifecycle_process^) } situation_playing_a_role (^e.g., outcome, accomplishment^) ) (entity (^thing that is not a situation -> that may "participate" to one^) \. partition { (spatial_entity \. partition { (physical_entity \. entity_that_can_be_or_was_alive) spatial_non-physical_entity (^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 (^e.g., color, wavelength^) attribute_or_measure (^e.g., red, '620 to 740 nm'^) } (ufo#Externaly_Dependent_Mode part of: 1 Relator, ufo#externaly_dependent_on: 1..* Entity ) ) ) (ufo#Relator (^e.g., Marriage, Enrollment, Employment, Mandate^) ) } ) (non-spatial_entity_existentially_independent = non-spatial_substantial, \. partition { temporal_entity (^e.g., date, duration^) (non-spatial_non-temporal_substantial \. partition { (description_content/instrument/support \. description (^"dcon"; e.g., Type, proposition^) description_instrument (^e.g., language^) description_support (^e.g., file^) ) non-spatial_non-temporal_non-chrc/meas/desc_substantial(^e.g., justice^) } ) } ) } ) } entity_playing_a_role (^e.g., owner, agent^) ) } thing_playing_a_role (^e.g., creation, part^);
------------------------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)
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 commun / 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 SGBDs. 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.
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
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
"Web sémantique" [Semantic Web]: mot (surtout utilisé à partir de 1996, soit 4 ans après la naissance officielle du Web) désignant
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.
Conflit (sémantique) implicite entre deux phrases affirmées: incohérence ou redondance partielle/complète entre ces phrases, qui n'a pas été rendue explicite via une relation de "correction". Pour comparaison, voici deux exemples de conflits explicites (et donc résolus) entre deux croyances:
u2#` u1#`every bird is agent of a flight´ has for pm#corrective_specialization u2#`most healthy flying_bird are able to be agent of a flight´ ´. u2#` u1#`every bird can be agent of a flight´ has for pm#corrective_generalization u2#`75% of bird can be agent of a flight´ ´.
Les conflits entre des définitions provenant de différentes sources n'indiquent pas qu'une des définitions est meilleure que l'autre (car les définitions ne sont ni vraies ni fausses) mais indiquent qu'une des sources (i.e., un des auteurs de ces définitions) a mal compris la signification d'un terme défini par une autre source et donc que ces sources parlent de choses différentes et qu'elles devraient utiliser des termes formells différents.
"Protocole de coopération" minimal de haut niveau pour l'ajout/fusion sans-perte d'une phrase affirmée, créée par un utilisateur U1, dans une BC:
Un protocole minimal similaire peut être utilisé pour la suppression sans perte d'une d'une phrase affirmée. Les termes peuvent être ajoutés ou supprimés via l'ajout ou la suppression de phrases affirmées.
Si deux BCs sont développées plutôt indépendamment ou si une fusion de deux BC est une nouvelle BC "indépendante" (i.e., dont les objets ne sont pas reliés à ceux deux premières BCs), les objets des BCs sont mutuellement peu reliés entre eux et il y a des "conflits" implicites entre eux. Il est difficile de résoudre ces conflits et de relier ces objets entre eux, que ce soit manuellement ou automatiquement. Il est donc difficile 1) de rechercher, fusionner/aligner et exploiter ensemble les contenus des BCs, ou 2) de faire en sorte que des outils ou des groupes utilisant ces KBs travaillent ensemble.
La plupart des outils (semi-)automatiques liés au Web sémantique sont destinés à atténuer la difficulté de recherche, comparer et fusionner des ontologies développées (semi-)indépendamment. Ces outils sont utiles, mais ils n'intègrent pas leurs résultats dans une BC partagée: leurs sorties sont des nouveaux fichiers/BCs formels dont les objets ne sont pas liés (explicitement, via des relations sémantiques) aux objets des autres BCs (ou de nombreuses autres BCs) sur le Web, en particulier les BCs sources. Ainsi, dans un sens, ces outils contribuent au problème qu'ils atténuent partiellement. En outre, comme les fusions qu'ils effectuent ne sont pas "sans perte", les mises à jour faites ultérieurement sur les fichiers/BCs que ces outils créent ne peuvent facilement être utilisés pour mettre à jour les BCs sources.
La plupart des outils manuels liés au Web sémantique sont des éditeurs de BC privés (qui conduisent donc leurs utilisateurs à créer des BCs plutôt indépendantes entre elles) ou bien des serveurs/éditeurs de BC partagés (e.g., Ontolingua, OntoWeb, Ontosaurus, Freebase et les serveurs wiki sémantique) qui n'ont pas de protocole de coopération entrainant une intégration des connaissances "sans perte d'informations". Par conséquent, ces outils
Le protocole minimal de coopération décrit précédemment
permet aux utilisateurs de créer une BC de manière coopérative
sans avoir à s'accorder sur une terminologie ou des croyances.
Ce protocole est déclenché pour chaque changement dans la base et
doit donc s'appuyer sur un SGBC pour détecter les conflits implicites.
Toutefois, une approche similaire peut être utilisée - bien que de
manière plus asynchrone - chaque fois que des personnes détectent
des conflits implicites dans la BC. Ainsi, une telle approche peut également
être appliquée sur des BC semi-formelles.
Par conséquent, cette approche pourrait être utilisée dans des
wikis sémantiques afin de résoudre leurs nombreux problèmes (dont
leurs problèmes de gouvernance) causés par leur manque de structure.
Il peut sembler impossible d'utiliser des "modules-qui-soient-aussi-des-vues"
sur une grande échelle sans avoir un système centralisé.
Pourtant, il est possible de combiner
- la centralisation des informations (qui conserve un réseau unique
sémantique,
ce dont le partage des connaissances a besoin) avec
- l'approche basée sur le Web pour des actions distribuées.
A l'échelle du Web, cela impliquerait une BC virtuelle mondiale
composée de BCs réelles (qui seraient des modules-vues, comme
décrit précédemment) créées par des individus ou
des communautés,
sans système central de répartition/retransmission
d'informations/requêtes,
sans restrictions sur le contenu de chaque BC, et
sans que les serveurs de BCs individuels aient nécessairement à
s'inscrire à une super-communauté ou
à un réseau pair-à-pair (P2P).
Pour arriver à cela, il est nécessaire que le choix de la BC qu'un agent décide d'interroger ou de mettre à jour n'ait pas d'importance. Des ajouts, mises à jour ou requêtes d'objet effectués dans une BC doivent être retransmis toutes les autres BCs dont le domaine couvre cet objet. Plus précisément, pour satisfaire les spécifications ci-dessus, pour qu'un serveur de BCcc (BC construite coopérativement) soit un module-vue d'un ou plusieurs BCcc-GV (BCcc global virtuel), il faut que pour chaque terme T stocké dans sa BCcc, ce serveur
Ainsi, via des retransmissions entre serveurs, tous les objets utilisant T peuvent être ajoutés ou trouvés dans chaque nexus pour T. Cette exigence est une adaptation et un raffinement de la 4ème règle de l'approche "Web de données" du W3C: "il faut lier le plus possible de choses d'un module à des choses d'autres modules". En effet, pour obtenir un BCcc-GV, les modules doivent être gérées via des serveurs BCcc et il doit y avoir au moins un nexus pour chaque terme. Une conséquence est que lorsque les domaines de deux nexus se chevauchent, ils partagent les mêmes connaissances communes et il n'y a ni contradictions ni "redondances implicites" entre ces deux nexus. En d'autres termes, chaque BCcc est bien une vue sur une partie du BCcc-GV.
Types de relations de base (les versions entre parenthèses sont des alternatives qui peuvent être avantageuses dans les éditeurs qui vérifient l'usage correct/équilibré/symétrique des délimiteurs: '<', '>', '(', ')', '[', ']', ...) : "<=" (".:=") et "=>" ("=:.") : implication logique entre phrases, e.g. ` `Tom vit' <= `Tom vit en France' ' "<-" (".:-") et "->" ("-:.") : implication non purement logique (i.e. par règles autres que celles d'une logique et ces/des règles peuvent être implicites), "/^" et "\." (ou "^\") : généralisation/spécialization (purement logique ou non) entre types/phrases (le '^' est du côté le plus général, le '.' du côté le plus spécialisé, i.e. précis), e.g. `animal \. chat', `animal ^\ chat', `chat /^ animal' et, étant donné 2 phrases pSource et pDest, ` `pSource \. pDest' => `pSource <= pDest' ' "!" : négation ou exclusion (cf. exemples pages suivantes), "c" et "-c" : correction et "inverse de correction (cf. exemples pages suivantes)
Dans les exercices, vous devez, en utilisant les "types de relations utilisables" (page suivante), 1) corriger (et donc préciser, généraliser, nier, ...) toutes les phrases qui peuvent être corrigées, et 2) argumenter celles qui ne sont pas argumentées ou qui le sont insuffisamment ou incorrectement. Vous n'avez donc a priori pas besoin des relations "=>" et "->" pour cela mais vous pouvez par exemple avoir besoin de "c=>" et "<-". Toute correction doit être justifiée via une relation "contextualisante" (cf. ci-dessous). Toute phrase doit être compréhensible sans avoir à lire les phrases autour. Il est le plus souvent préférable qu'une phrase soit minimale, i.e. qu'aucun retrait d'informations ne la rende fausse.
"@pm" à la fin d'une phrase indique que l'auteur de la phrase est "pm" (Philippe Martin). Faites de même (pour vos phrases) avec votre nom+initialeDePrénom (e.g. "MartinP"). Dans ces exercices, l'auteur - d'une relation contextualisante (i.e. dans _[...]) est l'auteur de la source de la relation, - d'une relation non-contextualisante est l'auteur de la destination de la relation.
Combinaison des "types de relations de base" utilisables dans les exercices :
"\.<=" (ou "^\<="), "/^<=", "\.=>" (ou "^\=>"), "/^=>" : implication et spécialization/généralization, purement logiques, sans correction, e.g. ` "at least 1 animal has lived" \.<= "at least 1 cat has lived" ' ` "any cat is soft" \.=> "any white cat 1 cat is soft" ' (note : ce genre de relations apporte rarement de l'information intéressante et vous rapportera donc rarement des points mais si vous utilisez d'autres relations alors que ces relations s'appliquent vous aurez des points en moins ; tous les manques de précision (dont ce genre là) que vous corrigerez chez d'autres personnes - via les relations de correction ci-dessous - vous rapporteront des points)
"<=.", ".=>", "<-.", ".->" : implication (purement logique ou non) sans spécialization/généralization ni correction
"\._" (ou "\__"ou "^\__"), "__/^" : spécialization/généralization sans implication ni correction
(combinaison de chaque type de relation ci-dessus avec la notion de correction ; soit l'abréviation 'c' est placé du côté corrigé, soit "-c" est placé du côté correcteur) : "c\.<=", "c\.<-", "c/^<=", "c\.=>", "c\.->", "c/^=>", "c/^->", "\.<=-c", "\.<--c", "/^<=-c", "\.=>-c", "\.->-c", "/^=>-c", "/^->-c", "c<=.", "c.=>", "c<-.", "c.->", "c\.", "c/^" "<=.-c", ".=>-c", "<--.c", ".->-c", "\.-c", "/^-c" : spécialization/généralization ou implication, avec correction (celles avec "<=" ou "=>" seraient purement logiques sans la notion de correction), e.g. ` "at least 1 animal has lived" c\.<= "at least 2 cats have lived" ' ` "any cat is soft" c\.=> "any white cat 1 cat is soft" '
"=>!" ("=:.!"), "->!" ("-:.!"), "!.<=" ("!.:="), "!.<-" ("!.:-") : implication, purement logique ou non, de la négation de la destination (le "c" est implicite car l'usage de la négation implique une correction)
"c!=" ("!.:-") : la destination est une correction de la source (note : ce genre de relations apporte rarement de l'information intéressante et vous rapportera donc rarement des points)
? : une relation existe mais son type est inconnu (note : aucun point)
"Windows est moins bien conçu que Unix"@pm //"pm" est l'auteur de cette phrase <- ("Le code de Windows sont moins modulaires que celui d'Unix" c\. "Les codes des Windows sont, sur une majorité de critères, moins modulaire que celui des codes Unix même si l'architecture des systèmes d'exploitation Windows (-> NT et après) est considérée hybride alors que l'architecture d'Unix est considérée monolithique" ), <- ("La majorité des fonctionnalités des Windows sont moins bien que sur Unix"@pm c=> ("Il existe des fonctionnalités de(s) Windows qui sont moins bien que sur Unix" <- ("Le copier-coller sur Unix peut se faire plus rapidement que sur Windows, sans demander d'installer des compléments (ce qui est long)" <- { "Unix permet le coller par un clic de souris, Windows n'a que Ctrl-V", "le clic de souris est plus rapide que le Ctrl-V" } ) ), !.<- "Il y a plus d'applications sur Windows que sur les autres OSs"@xx _[ !<- "Qu'il y ait plus d'applications sur Windows que sur les autres OSs n'a rien à voir avec la conception de Windows"@pm ] //la relation "!<-" de yy contredit la relation "!<-" de xx ). "Le 1er oeuf qui a donné une poule a existé avant une poule" /^ "Toute entité a été engendrée (directement ou pas) par quelque chose", \. "Des bactéries ont donné des poissons qui ont donné un oeuf qui a donné une poule", !.<- ("C'est une proto-poule qui a pondu le premier oeuf de poule" !.<- ("Il y a eu des oeufs de poule pondus par des proto-poules en des temps différents" !.<- "la mutation qui fait qu'un oeuf de proto-poule est un oeuf de poule ne peut arriver qu'une fois, par définition de 'oeuf de poule' et de 'proto-poule' " ) ).
"Plus un support de cours est structuré, mieux c'est" <= "Plus un support de cours est structuré, plus il permet de comparer et donc retrouver/mémoriser/comprendre les informations contenues" ?p1, c\. ("Plus un support de cours est structuré, mieux c'est sauf qu'il peut être moins plaisant"@el \. ("Plus un support de cours est structuré, mieux c'est pour des raisons pédagogiques" ?p2 \. "Plus un support de cours est structuré et plaisant, mieux c'est pour des raisons pédagogiques", c\. "Plus un support de cours est structuré, dans la limite de ce que peuvent raisonnablement comprendre+apprendre ses étudiants (en moyenne)" mieux c'est pour des raisons pédagogiques" ) _[<- ("Pédagogiquent, un support de cours n'a pas à être plaisant au détriment de sa structuration" !<- "Lorsqu'un support de cours est déplaisant, il existe des étudiants qui ne vont pas le lire et donc ne vont pas apprendre"@el _[!.<- { "Si un étudiant ne lit pas un cours sous prétexte qu'il ne le trouve pas plaisant, cet étudiant a peu de chance d'apprendre de toute façon", ("Plus un cours est structuré, plus les étudiants qui le lisent apprennent" <= ?p1) } ] ) ] ). "Plus un support de cours est précis, mieux c'est" c\. ("Plus un support de cours est précis et structuré, mieux c'est pour sa compréhension" <= { ?p1, //cf ci-dessus "Plus un support de cours est précis, plus il est compréhensible" }, \. ("Plus un support de cours est précis et structuré, mieux c'est des raisons pédqgogiques" <= { ?p1, ?p2} ) ) _[<= "Plus on ajoute des précisions, plus le texte doit être structuré pour garder les informations aussi compréhensibles/retrouvables/mémorisables"].