2.1. Coopération
2.1.1. Coopération et collaboration
2.1.2. Avantages/conditions pour une collaboration
2.1.3. Acteur idéal d'une collaboration
2.1.4. Outil idéal pour la collaboration
2.1.5. Coopération/travail-coopératif assisté par ordinateur
2.1.6. Logiciels collaboratifs, alias groupware
2.1.7. Protéger l'accés aux informations
2.1.8. Faciliter et personnaliser les interactions homme-machine
2.1.9. Représenter des informations d'une manière explicite et sans perte
2.1.10. Organiser des informations semi-formelles via des relations d'argumentation
2.1.11. Évaluation collaborative
Coopération ou co-opération (intentionnelle ou non):
interactions (volontaires, accidentelles ou forcées) entre des agents
qui combinent les efforts de ces agents.
Ainsi, un processus qui fait combiner (des résultats de) processus en
compétition est un processus qui les fait coopérer:
la concurrence n'est pas de la coopération mais peut être
utilisée par elle.
La coopération peut être distribuée ou centralisée,
synchrone ou non.
Des agents coopérants forment un "système coopératif".
Coopération intentionnelle: coopération entre des agents volontaires.
Collaboration:
coopération entre des agents volontaires ayant un
objectif identique, e.g., réaliser un échange commercial
ou un projet.
Par rapport à coopérer, collaborer est donc une notion plus
spécialisée (et plus forte) mais parvenir à faire coopérer
des gens (non motivés pour collaborer) est plus difficile.
Le terme "collaboration" est plus souvent associée à des activités
supervisées (et donc centralisées) que le terme "coopération".
Comme la coopération peut impliquer des personnes n'ayant pas
forçément un but identique ou la volonté de collaborer,
le terme "coopération" est plus souvent associé à des efforts
de guerre/paix, de développement économique d'un pays, à
la théorie des jeux, aux wikis et aux projets open source.
Intelligence d'essaim [swarm intelligence; parcourez cet article ainsi que celui sur les méta-heuritiques]: un comportement collectif, décentralisé et auto-organisé pouvant, selon certains points de vue, être interprété comme "intelligent". Ce comportement peut être naturel (e.g., le travail dans une colonie de fourmis, le rassemblement des oiseaux, le mouvement d'un banc de poissons) ou artificiel (agents en Intelligence Artificielle).
Intelligence collective: intelligence de groupe (convergence des comportements ou de connaissances dans un groupe) qui émerge lors de la collaboration ou de la concurrence entre de nombreuses personnes. L'intelligence collective est fortement liée à "l'intelligence d'essaim" mais ses agents sont plus souvent des personnes. Elle peut par exemple subvenir parce que la majorité des membres du groupe ont une "mentalité de troupeau/mouton" [herd mentality].
Exercice de compréhension et de représentation de connaissances:
- relier les types de concepts de "coopération", de "collaboration", de "groupe", de
"système de coopération" et de "système de collaboration" et d'essaim
(tels que définis ci-dessus) via des relations "sous-type", "exclusion" et "instrument" ("tool") ;
- raffiner/généraliser(/illustrer) au moins un des trois derniers concepts en utilisant
une relation "sous-type" (ou bien "instance" si vous ne trouvez qu'une
illustration).
thing
/ \
|s |s
v v
entity--#--situation
/ | | |
|s |s |s |s
v | v v
non-spatial_entity | state--#--process
| | | |
|s # | |s
v | v |
group spatial_entity |
| |
|s |
v v
system_of_cooperation <-[1..*]---(instrument)--- cooperation
| | |
|s |s |s
v v v
swarm system_of_collaboration <-[1..*]--(instrument)-- collaboration
|
|s
v
bee_swarm
//========= Representation in FL:
thing
> excl //the next direct subtypes are exclusive
{ (situation
exclusion: entity, //redundant with the "excl{...}" begun above
> excl{ state
(process
> (cooperation
instrument: 1..* system_of_cooperation,
> (collaboration
instrument: 1..* system_of_collaboration
)
)
)
}
)
(entity
> excl
{ spatial_entity
(non-spatial_entity
> (group
> (system_of_cooperation
> (swarm > bee_swarm)
system_of_collaboration
)
)
)
}
)
};
Avantages:
- plus grandes chances d'obtenir (plus facilement) quelque chose;
- pouvoir se spécialiser (i.e., ne pas tout faire/savoir) et donc être plus
efficace (division du travail);
- pouvoir connaître de nouvelles idées/habitudes et les appliquer;
- la valeur d'un réseau avec N noeuds peut être proportionnelle
à
N, N2 (Loi de Metcalfe) ou même 2N.
Inconvénients:
- à court terme: l'investissement en temps et/ou argent;
- si la collaboration échoue, perte de temps/argent/réputation;
- moins de vie privée puisque la collaboration implique l'accessibilité
des informations;
- le coût de la coordination dans une équipe de N personnes peut être
proportionnelle à
N, N2 ou même 2N.
Conditions usuelles pour collaborer avec une autre personne:
- au moins un but commun
- une chance de rencontrer ou bien collaborer de nouveau avec cette personne
- succès des précédentes rencontres ou collaboration avec
cette personne.
Des résultats en
économie expérimentale
indiquent que les êtres humains sont souvent coopératifs même
lorsque cela ne leur rapporte rien (e.g., ils aident des gens même
s'ils ont peu de chances de les revoir). Cela peut s'expliquer de la façon
suivante:
- même au niveau individuel, il est généralement payant
d'être systématiquement coopératif
lorsque les ressources sont limitées, comme le montrent la
théorie des jeux (en particulier
la théorie des jeux à somme nulle) et la théorie du livre "Tragedy of the commons";
- c'est encore plus vrai au niveau du groupe (un groupe dont les membres sont
coopératifs
est plus compétitif, ce qui est "en moyenne" payant
pour ses membres même si l'intérêt
de certains membres est
"sacrifié";
- beaucoup d'êtres humains sont suffisamment rationnels pour comprendre les
deux arguments précédents;
- la sélection naturelle (entre individus et entre groupes) a conduit à
ce que les êtres humains
soient relativement coopératifs lorsque
cela ne nuit pas à leurs intérêts.
D'autres raisons plus détaillées existent. Un certain nombre d'entre elles
se trouvent dans les articles de recherche de "Cooperation Commons". Cette vidéo est également intéressante.
Note sur le modèle open-source. Il est l'emblème d'un large mouvement coopératif atteignant ses objectifs. Toutefois, les mouvements open-source n'utilisent actuellement pas d'outils avancés pour aider la coopération. Ceci peut expliquer pourquoi ces mouvements ont du succès essentiellement lorsque le but à atteindre et ses sous-tâches sont bien définis et bien connus par leurs membres (c'est par exemple généralement le cas pour la conception d'un système d'exploitation).
Être "ouvert" (dans le sens de rechercher/donner des données/idées) est nécessaire pour coopérer, mais ce n'est pas une condition suffisante ni un critère caractéristique. En effet, il est également souvent payant d'être "ouvert" dans le contexte d'une compétition, comme c'est le cas en recherche et pour les organisateurs de concours scientifiques ou d'ingénierie.
Exercice:
raffiner/généraliser(/illustrer) au moins un avantage, un
inconvénient et une condition
(parmi ceux ci-dessus) en utilisant
à chaque fois au moins une relation sous-type(/instance).
Idéalement, un acteur (ou participant) d'une collaboration
L'idée maitresse du livre
"Wisdom of the Crowds" est que
"un groupe plus important est plus intelligent qu'un groupe plus petit"
- si les membres sont sages/rationnels (le livre développe le 2nd point
ci-dessus), et
- si "un dispositif existe pour que les jugements individuels soient
transformés
en une décision collective", donc si
un "outil idéal/adéquat pour la collaboration"
est utilisé.
Un problème principal est donc de créer de tels outils et que ceux-ci
puissent (aider les gens à) reconnaitre les meilleures
connaissances/idées/solutions.
Exercice:
1) compléter ou raffiner/généraliser(/illustrer) chacune des 4 types de
tâches ci-dessus
en utilisant à chaque fois au moins une relation
sous-type(/instance).
2) que peut faire - avec des outils du Web désormais classiques - une personne
souhaitant être "coopérative" à chaque fois qu'elle
reçoit un email relatif à
son travail et ne contenant pas ou peu
d'informations confidentielles ?
1) une application du 4ème point ci-dessus pour un pompier serait par exemple de
- créer des (ou de demander la création de) moyens d'échanges d'informations
publics/anonymes asynchrones: panneau d'affichage, site Web collaboratif (ou,
à défaut, une liste mail), "boîte à suggestions", etc.
- publier des informations via ces moyens d'échanges
- donner ou demander un cours, des astuces, ... pour le travail de pompier.
Idéalement, un outil d'aide à la collaboration devrait
Exercice:
- compléter ou raffiner(/illustrer) chacune des 5 types de tâches
ci-dessus
en utilisant à chaque fois au moins une relation
sous-type(/instance).
Collaboration assistée par ordinateur [Computer-supported_collaboration (CSC)]:
(étude de) l'utilisation des ordinateurs et/ou de l'intranet/internet pour
soutenir la collaboration au sein d'un groupe ou entre
groupes/organisations/communautés/sociétés.
En tant que champ
d'étude, le CSC inclut le CSCW (TCAO; cf. ci-dessous) mais se focalise sur
les systèmes de contrats
et de rendez-vous/coordination, e.g.,
les ventes aux enchères et les systèmes de marché.
Le terme SCC a émergé dans les années 1990 pour désigner un
champ d'étude généralisant les 3 anciens champs suivants:
Travail coopératif assisté par ordinateur (TCAO) [Computer supported cooperative work (CSCW)]:
(étude de) l'utilisation des ordinateurs ou en tant que support de
médiation dans des activités telles que la communication, la coordination,
la coopération, la concurrence, les jeux et l'art. Voici quelques exemples de
dimensions fondamentales du travail coopératif:
En résumé, la plupart des outils dits "de collaboration" sont actuellement
surtout des outils de communication d'informations (de manière synchrone ou pas,
à distance ou pas) et/ou de
modification d'un même fichier par divers utilisateurs.
Peu d'outils dits "de collaboration"
aident activement à coordonner/organiser des tâches et des informations.
Lors de l'étude ou la présentation d'un outil, il faut donc préciser et
approfondir ces trois distinctions.
Exercices:
* Lesquels des 4 types d'outils ci-dessus sont pertinents pour classifier les
types de systèmes suivants: "internet", la "publication de documents Web",
les "tableurs en ligne",
les "réseaux sociaux", les "systèmes pair-à-pair" et
les "bases de connaissances partagées" ?
* Comparez les 4 types d'outils ci-dessus et certains de leurs sous-types
en fonction des "5 types de tâches que, idéalement et selon le cours,
un outil d'aide à la collaboration devrait supporter".
Pour cela, vous étendrez la "table de comparaison+représentation" ci-dessous.
Dans ce type de table,
a) les intitulés de ligne et colonnes sont des types de concepts et
peuvent être organisés par une relation de spécialisation,
b) chaque cellule du tableau comporte un symbole spécifiant si oui ou non
les instances du type pour la ligne sont (et/ou seront bientôt) instances du
type pour la colonne. Voici une liste minimale de tels symboles :
"-" (pour "généralement pas"), "+" (pour "généralement"), et
"?" (pour "cela dépend beaucoup des sous-types du type de la ligne" ou
"pas assez d'informations ont pu être collectées pour
répondre").
| 1 | 2 | 3 | 4 | 5 | |
|---|---|---|---|---|---|
| groupware | ? | ? | ? | ? | ? |
| colocated_synchronous_groupware | |||||
| roomware | |||||
| colocated_asynchronous_groupware | |||||
| tea-toom_tool | |||||
| remote_synchronous_groupware | |||||
| video-conference_tool | |||||
| remote_asynchronous_groupware | |||||
| document-based_groupware | |||||
| classic wiki | |||||
| classic workflow | |||||
| KB-based_tool | |||||
| ideal_KB-based_tool | + | + | + | + | + |
Sécurité:
sûreté (protection contre des
événements indésirables) et
fiabilité
(capacité de maintenir des fonctions), même contre des agents volontaires.
Cela implique de maintenir la
disponibilité,
l'intégrité et la
confidentialité de certaines
informations, procédures ou machines. Cela implique également d'obliger la
responsabilité d'au moins certains
types d'actes, e.g., la lecture ou écriture de certains types d'informations.
Préservation de la vie privée: sécurité + anonymité (i.e., non seulement le contenu ou la nature de certaines informations ou actes est protégée, mais leur existence aussi; ainsi, l'identité des personnes liées à certaines informations ou actes ne peut être connue que par des personnes autorisées; les autorisations doivent idéalement ne pouvoir émaner que des personnes elles-mêmes).
Notion de "consensus" en tant que problème de sécurité informatique distribuée
(pour la tolérance aux pannes):
méthode à utiliser par un groupe de noeuds d'un réseau pour
prouver qu'ils sont accessibles et non corrompus, est d'arriver à fournir
indépendemment une même réponse à une question (ou, en d'autres
termes, "parvenir à un accord sur une seule valeur"). Le problème
lié à cela est "quel protocole utiliser pour y parvenir ?".
Ce problème est impossible à résoudre lorsque
i) l'un des noeuds/processus se bloque, et
ii) les processus communiquent par envoi de messages, n'ont pas d'horloge
commune et fonctionnent à des vitesses arbitrairement différentes.
Cette notion de "consensus" est peu liée à celle de
"consensus pour la prise d'une décision", qui est la notion à laquelle le terme "consensus" réfère dans le reste de ce document.
Une bonne interaction homme-machine (et donc interface homme-machine) (IHM) [HCI] est importante pour soutenir le partage d'informations et les autres tâches de collaboration.
Principes de conception d'interface avec l'utilisateur:
structure, cohérence, simplicité, visibilité, rétroaction,
tolérance, réutilisation ... Il y a
d'autres principes de conception d'affichage.
Le W3C se concentre sur les critères de
mobilité,
d'universalité (internationalisation) et
d'accessibilité.
Un résumé général est le suivant:
prendre en compte les possibilités, limites et problèmes
1) des différents éléments techniques (réseau, langages,
navigateurs, ...) et
2) des utilisateurs (vue, mémoire, compréhension, langues, ...).
Une conception centrée utilisateur
des interfaces, i.e. leur co-conception par l'utilisateur final, est une
bonne idée.
La théorie de l'activité
peut aussi aider la conception d'une interface homme-machine.
Plus important encore, des techniques de
personnalisation doivent être
utilisées pour
1) proposer différents modèles basés sur des groupes/profils,
2) proposer des recommandations basées sur les comportements passés
de l'utilisateur ou basées sur des préférences d'autres
gens (filtrage collaboratif), et
3) permettre aux utilisateurs d'adapter l'interface directement.
Corollaire de la règle sur "l'usage d'objets précis et de
métadonnées":
plus les éléments de l'IHM (i.e., de la présentation) et du contenu
sont séparés, plus ils sont fins, adressables et
précisément représentés (organisés),
plus il est possible de permettre leur personnalisation par chaque utilisateur.
Pour réellement supporter la coopération, un logiciel doit fournir une
liste organisée de paramètres de présentation et un
langage adapté pour la présentation.
La caractéristique la plus importante d'une IHM est que tous les objets liés à un objet particulier soient facilement accessibles à partir de lui.
Donc, idéalement, chaque objet "intéressant" doit pouvoir être
sélectionné et sa sélection par un utilisateur conduire à un
menu contextuel
(e.g., via un menu pop-up) permettant à l'utilisateur
d'explorer, de sélectionner et d'ajouter/modifier tous ses objets reliés, e.g., ses propriétés de présentation, des objets informationnels et les actions qui peuvent être faites sur cet objet ou via cet objet
(pour les objets reliés qui n'ont pas trait à la présentation,
les modifications doivent être sans perte, comme précisé dans la
section 2.1.9).
Dans des éditeurs de documents structurés bien
conçus, cela est possible mais l'ensemble des objets reliés est
limité à ceux identifiés par les schémas de structure,
de présentation et d'interaction/événement associés au
document en cours d'édition.
Pour un meilleur partage/recherche des connaissances et une meilleure
coopération, les objets doivent être représentés dans une
base de connaissances (BC), et donc, le menu contextuel associé à
un objet sélectionné devrait permettre l'exploration de la BC à
partir du point d'entrée constitué par cet objet.
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 formels 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.
Les relations d'argumentation (preuve, objection, argument, exemple ...) ne sont généralement pas transitives et ont donc tendance à conduire à des structures "spaghetti" qui aident peu la recherche des connaissances et les inférences. Les relations d'argumentation ne doivent être utilisées que lorsque ce qui doit être représenté ne peut l'être (au moins partiellement) d'une manière plus précise et organisée, typiquement via des relations de spécialisation ou de sous-processus. Si cela est nécessaire, des relations d'argumentation peuvent alors être utilisées dans le contexte externe de ces relations de spécialisation ou de sous-processus.
Pour les mêmes raisons et également pour normaliser les structures d'argumentation, au lieu d'utiliser des relations de type pm#objection, il vaut mieux utiliser des relations de type pm#corrective_specialization ou pm#corrective_generalization, avec des relations de type pm#argument dans leurs contextes externes. Ainsi, l'objection est indirectement affirmée et en plus une correction est donnée via une relation transitive et un argument est donné pour cette correction. Cette correction et cet argument vont faciliter l'acceptation de l'objection et peuvent être eux-mêmes des noeuds source de relations de correction.
Exemple de "discussion structurées" (structure d'argumentation multi-sources) avec la notation FL.
"knowledge_sharing_with_an_XML-based_language is advantageous" .< ("knowledge_sharing_with_an_XML-based_language is possible" .< knowledge_sharing_with_an_XML-based_language __[pm] ) __[pm], argument: – "XML is a standard" __[pm] – ("knowledge_management_with_classic_XML_tools is possible" corrective_specialization: "structural_knowledge_management_with_classic_XML_tools is possible" __[pm, argument: "classic XML tools only manage structures, not semantics" __[pm] ] ) __[pm], argument: "the use of URIs and Unicode is possible in XML" __[fg, objection: "the use of URIs and Unicode can easily be made possible in most syntaxes" __[pm#tbl#] ], objection: – ("the use_of_XML_by_KBSs implies several tasks to manage" argument: "the internal_model_of_KBSs is rarely XML" __[pm] ) __[pm] – ` "an increase of the number of tasks *t to_manage" has for consequence "an increase of the difficulty to develop software to manage *t" ´ __[pm], objection: – "knowledge_sharing_with_an_XML-based_language will force many persons (developers, specialists, etc.) to learn how to understand complex_XML-based_knowledge_representations" __[pm] – ("understanding complex_XML-based_knowledge_representations is difficult" argument: "XML is verbose" __[pm] ) __[pm];
Beaucoup d'outils du Web 2.0 permettent aux gens d'associer des commentaires à des ressources entières (documents/KBs/services) et de les évaluer en fonction d'un critère (ou de quelques critères) tels que "utilité", "étendue du domaine couvert" et "véracité ". Ces outils permettent aussi souvent de voter sur les annotations et/ou les ressources. Via des statistiques sur les annotations et les votes, ces outils génèrent des "recommandations" et permettent ainsi de la recherche/synthèse collaborative d'informations (également appelée "recherche sociale/concurrente"; sujet d'exposés).
Cependant, la sémantique et l'utilité d'une approche aussi grossière (dans les ressources qu'elle indexe) est limitée et limitante. Voici quelques raisons:
Pour éviter cela, un logiciel aidant réellement la
coopération devrait
Question: comment mesurer la confiance à accorder à un phrase ou à
une personne/source,
comment construire cette mesure collaborativement (i.e.,
comment les utilisateurs d'une BC peuvent-il construire collaborativement une
représentation de la réputation
d'une personne ou d'une phrase) ?
Voici un exemple de modèle de base pour une mesure par défaut destinée à évaluer "l'utilité d'une croyance".
Ce modèle ne précise pas les fonctions à utiliser pour les combinaisons et les pondérations. Le choix d'une fonction particulière est quelque peu arbitraire. Chaque utilisateur devrait donc connaître ces fonctions et devrait être autorisé à créer ses propres fonctions pour satisfaire ses buts ou ses préférences.
Les résultats des "mesures par défaut" doivent être utilisés par des méthodes de "présentation par défaut". E.g., les phrases ayant une très faible valeur d'utilité peut être par défaut affichées avec une police très petite.
Ainsi, les mesures par défaut prenant en compte au moins les
éléments cités ci-dessus devraient inciter les fournisseurs
d'informations à
- être prudent et précis dans leurs contributions, et
- à donner des arguments pour ces contributions.
En effet, contrairement à des discussions traditionnelles ou à des
commentaires anonymes, ici des phrases non réfléchies vont avoir une
influence sur les mesures d'utilité d'un auteur et donc sa réputation.
Cela peut conduire les utilisateurs à ne pas écrire des phrases en
dehors de son domaine d'expertise ou sans préalablement faire de
vérifications. Par exemple, quand une croyance d'un utilisateur est
contredite par un autre utilisateur, l'utilité de son auteur décroit
et il est ainsi incité à approfondir la structure argumentation sur
sa croyance ou à ôter cette croyance de la BC.
Avec le modèle ci-dessus, utiliser un nouveau pseudo lorsque l'on écrit n'importe quoi (diffamations, phrases non réfléchies/vérifiées, ...) mais aucune valeur d'utilité n'est associé à ce nouveau pseudo (et cette valeur pourra même devenir négative si d'autres utilisateurs repèrent la faible qualité des informations fournies via ce pseudo).
Le modèle ci-dessus a l'avantage de ne pas nécessiter de consensus mais peut être facilement adapté pour impliquer un consensus.