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 (":=>" si définitionnelle, ".=>" si descriptive), e.g. ` `Tom vit en France' .=> `Tom vit' ' //description (-> ".") d'une inférence logique (-> "=>") Toutefois, dans ce cours, le '.' pour les implications logiques descriptives peut être omis (c'est l'option pas défaut dans ce cours) "<~" et "~>" : implication non purement logique (i.e. par règles autres que celles d'une logique et ces/des règles peuvent être implicites), e.g. ` `Tom mange' :~> `Tom est heureux' ' //définition (-> ":") d'une inférence non logique (-> "~>") "_/^" et "\_" : généralisation/spécialisation (purement logique ou non) entre types/phrases, e.g. étant donné 2 phrases pSource et pDest, ` `pSource \_ pDest' => `pSource <= pDest' ' "!" : négation (e.g., l'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 _[...] ou __[...]) 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 :
"\_<=", "/^<=", "\_=>", "/^=>" : implication et spécialisation/généralisation, 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 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écialisation/généralisation ni correction
"\__", "__/^" : spécialisation/généralisation 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", "\_-c", "/^-c" : spécialisation/généralisation 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 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)
//Le "@pm" à la fin de la 1ère ligne/phrase de l'exemple ci-dessous // spécifie que pm est l'auteur de cette phrase. Dans les phrases après la 1ère, // "@pm" est omis pour les phrases créées par pm (<- le créateur pas défault est pm). "La conception des Windows est moins bonne que celle d'Unix"@pm //"pm" est l'auteur de cette phrase <~> ("(Chaque) Windows est moins bien conçu que (chaque) Unix" \_ (` .`the Quality _of_ the Design _of_ each Windows´ is lower than .`the Quality _of_ the Design _of_ each Unix´ ´ <=> `each Windows is result of a Design with attribute a Quality that is lower than each Quality that is attribute of any Design which has for result a Unix´, <=> [Windows result of _[each ->.]: (a Design attribute: (a Quality lower than: each ^(Quality attribute of: any ^(Design result: a Unix) ) __[ ] ) ) //this context could be used to set relations of ] // correction/specialization/... on the last "lower than" relation ) //This last representation is object-based: it is the most precise+organized -> the best ), //This document uses relations on sentences (because it is easier) but, as you shall see, // this sentence-based representation is not scalable (-> "spaghetti net" result) c\_ ("Les codes des Windows sont moins modulaires que les codes des Unix" c\_ ("Les codes des Windows sont, sur une majorité de critères, moins modulaires que ceux des Unix" \_ (` ^`the modularity _of_ the code _of_ each Windows_OS´ is lower _["on a majority of criteria] than ^`the modularity _of_ the code _of_ each Unix_OS´ ´ <=> `each Windows_OS < _(modularity_on_a_majority_of_criteria): each Unix´ ) ), //the above '<' refers to the "lower than" relation and it has // a parameter: relations, like functions, may have parameters !-<~~ "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"@xx __[!-<~~ "Les notions hybride/monolithique ont peu de rapport avec la 'modularité de code logiciel' au sens commun" ] ), //la relation "!-<~~" de pm invalide la relation "!-<~~" de xx <~~ ("La majorité des fonctionnalités des Windows sont moins bien que sur Unix" c/^-> ("Il existe des fonctionnalités des 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 par défaut que le 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" ] //la relation ".!-<~~" de pm invalide la relation ".!-<~~" de xx ). "Le 1er oeuf qui a donné (s'est-transformé-en/engendré/évolué-en) une poule a existé avant une poule"@xx /^~> ("Une entité a été donnée (directement ou pas) par quelque chose (d'existant)"@xx <~\_ "Toute entité a été donnée (directement ou pas) par quelque chose (d'existant)"@xx ), <~\_ "Des bactéries ont donné des poissons qui ont donné un oeuf qui a donné une poule"@xx, !-<~~ ("C'est une proto-poule qui a engendré/donné/pondu le premier oeuf de poule" \_!-<~ ("Il y a pu y avoir des oeufs de poule pondus par des proto-poules en des temps différents"@xx \__ "Il y a eu une ou plusieurs proto-poules qui a donné un oeuf de poule" ) __[ !-<~~ "'\_!-<~' n'est pas logique" ], \__ "Il y a eu une ou plusieurs proto-poules qui a donné un oeuf de poule" ).
Les discussions structurées de cette page sont complémentables via ce Google Doc. "Plus un support de cours est structuré, mieux c'est sur au moins un critère" <~~ "Plus un support de cours est structuré, plus il permet de comparer et donc retrouver/mémoriser/comprendre les informations contenues" ?p1, <~~ ("Plus un support de cours est structuré, mieux c'est globalement même s'il n'est pas plaisant"@el \__ ("Plus un support de cours est structuré, mieux c'est globalement pour des raisons pédagogiques même s'il n'est pas plaisant" ?p2 <~~ ("Plus un support de cours est structuré, mieux c'est globalement pour des raisons pédagogiques et, pédagogiquement, un support de cours n'a pas à être plaisant au détriment de sa structuration" <-/^ ("Pédagogiquement, un support de cours n'a pas à être plaisant" ?p3 //note: qu'un cours se retienne plus facilement s'il utilise des // formes contrastées, variées ou multimédia est hors-sujet ici !-<~~ "Lorsqu'un support de cours est déplaisant, il y a plus de chances qu'il y ait des étudiants qui ne le lisent pas et qui 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 chances d'apprendre de toute façon", ("Plus un cours est structuré, plus les étudiants qui le lisent peuvent apprendre" <~~ ?p1 ) } ] ) ), \__ "Plus un support de cours est structuré et plaisant mieux c'est globalement pour des raisons pédagogiques" ), "Plus un support de cours est structuré, dans la limite de ce que des étudiants motivés peuvent raisonnablement (et en moyenne) comprendre+apprendre, mieux c'est pour des raisons pédagogiques" ). "Plus un support de cours est précis, mieux c'est globalement" 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 pour des raisons pédagogiques" <~~ { ?p1, ?p2} ) ) __[<~~ "Plus on ajoute des précisions, plus le texte doit être structuré pour garder les informations aussi compréhensibles/retrouvables/mémorisables"].
Les discussions structurées de cette page sont complémentables via ce Google Doc. "'Communiquer des informations importantes en cours magistral' ne doit pas reposer sur de la dictée ou de la prise de notes" <=> "En cours magistral, aucune communication importante ne doit reposer sur de la dictée ou de la prise de notes" <~/^ ?ImportanteCommSurtoutPasViaMethodeLenteEtMediaTemporaireEtBruitableEtSéquentiel, //cf. fin de page <~~ "Par rapport à la lecture d'une information écrite, une prise de notes (sous dictée ou pas) implique un temps beaucoup plus long et une qualité de reproduction souvent détrimentale à la relecture et la compréhension" "Prendre des notes (sous dictée ou pas), et donc écrire, peut empêcher de se concentrer sur le contenu de ce qui est écrit et donc entraîner une perte de compréhension ou d'informations orales" ("En cours magistral, aucune information importante ne doit être donnée seulement oralement" <~~ ("Une information donnée seulement oralement n'est pas forcément entendue dont par les absents" <~/^ ?argumentContreTmpMedia) ("Une information donnée oralement n'est pas forcément bien notée/retrouvables, dont par les absents" <~/^ ?argumentContreSeqMedia), ~~> ("En cours magistral (CM) (-> pas en "classe inversée" pure), un support de CM doit seulement être lu (et éventuellement commenté par des informations amusantes ou motivantes mais pas importantes)" ~~> "Que ce soit pour une classe inversée ou pas, le support de cours doit être le même", <~~ "En cours magistral (CM), seulement lire le support de cours permet à ceux qui ont préparé leur cours (i.e. à ceux qui ont fait leur boulot d'étudiant) de réviser et de poser des questions sur les points qu'ils n'ont pas compris" ) ). "'Communiquer une information importante' ne doit pas seulement utiliser un 'media temporaire' (i.e., où l'information n'est pas conservée, e.g. la voie orale)" ?ImportanteCommPasSeulementViaMediaTemporaire <=> "Aucune information importante ne doit être communiquée seulement via un 'média temporaire'", <~~ "Une information donnée seulement via un 'media temporaire' n'est pas forcément reçue (e.g. entendue) et elle est pas (re-)trouvable dans ce media", <-\_ ("'Communiquer une information importante' ne doit pas (seulement <~) utiliser un 'media temporaire' tout en imposant aux destinataires une méthode lente ?ml pour la sauvegarde dans un media non temporaire (e.g. la dictée ou de la prise de notes)" ?ImportanteCommPasViaMethodeLenteDeSauvegardeDansUnMediaNonTemporaire <~~ ("Si une méthode plus rapide que ?ml (e.g. automatique) peut être utilisée pour sauvegarder une information dans un media non temporaire, le choix de ?ml par l'auteur ?a de la communication ?c est une perte de temps que cet auteur ne peut éthiquement motiver" <~~ "même si ?ml a des avantages, le destinataire de ?c peut l'appliquer plus tard et c'est éthiquement à lui - pas à ?a - de gérer son temps" ) ) "'Communiquer une information importante' ne doit pas seulement utiliser un 'media bruitable' (i.e., où l'information peut facilement être déformée et donc non/mal/incorrectement reçue, e.g. la voie orale) ?ImportanteCommPasSeulementViaMediaBruitable <~~ "Une information donnée seulement via un 'media bruitable' peut être non/mal/incorrectement reçue". "'Communiquer une information importante' ne doit pas seulement utiliser un 'media séquentiel' (i.e., où l'information n'est pas retrouvable/visualisable sans avoir à parcourir/voir/écouter/... d'autres informations, e.g. la voie orale et les vidéos dont le contenu de chaque seconde importante n'est pas complètement indexé)" ?ImportanteCommPasSeulementViaMediaSéquentiel <~~ "Une information donnée seulement via un 'media séquentiel' n'est pas facilement (re-)trouvable" ?argumentContreMediaSéquentiels. "'Communiquer des informations importantes' ne doit surtout pas seulement utiliser un media temporaire, séquentiel et bruitable" ?ImportanteCommSurtoutPasSeulementViaMediaTemporaireEtBruitableEtSéquentiel <~/^ ?ImportanteCommPasSeulementViaMediaTemporaire ?ImportanteCommPasSeulementViaMediaBruitable ?ImportanteCommPasSeulementViaMediaSéquentiel, <-\_ "'Communiquer des informations importantes' ne doit surtout pas (seulement<~) utiliser un media temporaire, séquentiel et bruitable, tout en imposant aux destinataires une méthode lente pour la sauvegarde dans un media non temporaire (e.g. la dictée ou de la prise de notes)" ?ImportanteCommSurtoutPasViaMethodeLenteEtMediaTemporaireEtBruitableEtSéquentiel <~/^ ?ImportanteCommPasSeulementViaMediaTemporaire ?ImportanteCommPasSeulementViaMediaBruitable ?ImportanteCommPasSeulementViaMediaSéquentiel ? ?ImportanteCommPasViaMethodeLenteDeSauvegardeDansUnMediaNonTemporaire .
Les discussions structurées de cette page sont complémentables via ce Google Doc. 'Dire "je n\'ai rien compris" sans rien préciser d'autre, n'est pas ce que l'on attend d'un étudiant' <~~ { "Un étudiant doit être coopératif avec son enseignant (-> indirectement, avec les autres étudiants)", ('Dire "je n\'ai rien compris" sans rien préciser d'autre, n'est pas constructif/coopératif' \__ "Dire 'je n'ai pas tout compris' (sans rien préciser d'autre) n'est pas constructif/coopératif"@FontaineE, <~~ { 'Il est faux de dire "je n\'ai rien compris" à propos de phrases si i) leur langage/notation/... et au moins une partie de leurs termes sont connus de la personne qui lit ces phrases, et ii) ne pas pouvoir lire/comprendre une partie des phrases n'empêche pas de comprendre le reste' 'Dire "je n\'ai rien compris" à propos d'une ou plusieurs phrases ne permet pas à à l'auteur de ces phrases de savoir quoi modifier pour aider à la compréhension' } ) }. 'Dire d'un objet d'information "je ne l\'ai pas compris" n'implique pas que cet objet soit améliorable" ~~>! 'Dire d'un objet d'information "je ne l\'ai pas compris" implique que cet objet est améliorable', ! 'Dire d'un objet d'information "je ne l\'ai pas compris" implique que cet objet n'est pas améliorable", <~~ "Une personne peut ne pas comprendre un objet d'information pour des raisons non attribuables à son auteur, e.g., parce que i) elle n'en comprend pas le langage, ou ii) elle n'a pas compris ni recherché le sens de termes qui n'ont pas à être défini/référé dans l'objet, ou iii) elle n'a pas bien lu certaines notions (idées, notations, ...) ou iv) elle n'a pas accédé à des termes dont les définitions n'étaient que \"référés\" dans l'objet car ils n'avaient pas à être définis dans l'objet", //même si de meilleures références peuvent être ajoutées, ce n'est pas un contre-argument à la 1ère phrase <~~ 'Lorsque les informations nécessaires pour comprendre un objet d'information sont facilement accessibles (e.g., parce que l'objet les inclut ou les réfère) et compréhensibles par les lecteurs auxquels l'objet d'information est destiné, le fait qu'un lecteur de cet objet dise "je ne le comprends pas" n'implique pas un problème dans l'objet mais implique que ce lecteur n'a pas accédé ou n'a pas fait attention aux informations en question'.
Les discussions structurées de cette page sont complémentables via ce Google Doc. "Using tabulations in programming is bad (practice)" <~> "Programming using tabulations is problematic" "Tabulations should NOT be used in programming", <~~ "Tabulations lead to an indentation which depends on where the platform, tool, or user preferences with which the file is viewed (thus, this file is often completely messed up if any other platform, tool or user preference is used)".
Google Docs sur des phrases de cette version étendue de "Rôles/devoirs de l'enseignant et de l'étudiant" :
pour le groupe 1a,
pour le groupe 1b,
pour le groupe 2.
Google Docs pour d'autres sujets non directement liés à la coopération :
pour le groupe 1a,
pour le groupe 1b,
pour le groupe 2.