Coopération entre Transiscope et In Common

Topic ouvert pour échanger sur les coopérations possibles entre les 2 projets. Comment pouvons nous coopérer? qu’est ce que chaque projet peut apporter à l’autre? quelles sont les attentes de chaque projet concernant l’autre?
les topics liés :



1 Like

@natacha à mentionné sur https://riot.im/app/#/room/#transiscope:matrix.virtual-assembly.org :
" In Common ne propose pas de cartographie, ni de portail public pour accéder aux cartes, il s’agit plutôt de se préocuper de la validité des données et de leur mise à jour, en proposant un format partagé et une API qui permettent de partager les sources afin de facilité leur mise à jour et s’assurer collectivement de leur pertinence dans une cartographie des communs.
A nos yeux l’espace de collaboration se situe donc dans la clarification des bsoins de chacun des projets, est ce que cela fait sens?"

Oui c’est bien ce que nous imaginons,

Mais surtout dans un premier temps ce qui serait important est de discuter avec vous des spécifications de l?API telles qu’elles sont présentées ici: API Specification v0

aussi ce que @how expliquait au printemps dernier

qui se voit matérialisé maintenant, c’est pourquoi nous souhaitons nous engager dans le groupe Intermapping.

Une première version de l’api existe ici, elle te permettra déjà de récupérer les données de dewey maps comme demandé plus haut, mais surtout à terme (dans un objectif de quelques mois) intégrera un système d’agents.

Bonjour,
je crois commencer à comprendre pourquoi nous ne nous sommes pas reliés plus tôt. Il me semble que In Common cherche à trouver une solution pour garantir la modération des données alors que Transiscope fait confiance à la source pour respecter sa charte et revient vers la source a posteriori si celle ci n’est pas respectée.
Transiscope a pour objectif principal, l’impact auprès du grand public et des “spécialistes” alors que In Common souhaite garantir le protocole de communication et la modération.
Transiscope fait avec les données qui existent sans demander d’effort à la source alors que In Common veut refondre le protocole de publication de ces données à la source. Transiscope n’a donc pas besoin d’une API spécifique mais fait avec les API/datas/fichiers existants.

Je ne suis pas sûr de ce que j’ai écrit sur In Common et je pose ces différences que j’ai compris pour en discuter.
Je ressens aussi une différence philosophique/politique qui n’engage que moi. J’ai l’impression que Transiscope est sur une logique “libérale” tout en prenant soin de communs (décentralisation dans un cadre éthique) et que In common est sur une logique plus “communiste” (centralisation de la gestion des biens communs). Il n’y a aucune critique ni louange d’un des 2, je souhaite juste rentrer au fond des choses (raison d’être et intention politique).

Je voie quelques pistes de coopération :

  • Transiscope pourrait exprimer ses données en respectant l’API In Common
  • In Common pourrait demander à intégrer ses données dans Transiscope (nous n’intégrons que les collectifs qui en font la demande)
  • Utiliser la même plateforme de visualisation ( GoGoCarto ) et l’améliorer ensemble
  • il y en a sans doute plein d’autres…

Exactement c’est bien cela l’enjeu, faire confiance à la source est une bonne idée pour lancer et dynamiser un projet mais lorsque le projet grandi il est important d’envisager une modération afin de ne pas se trouver submergés, et on ne peut trouver le temps de faire un retour à la source de ce type, wikipedia est un très bon exemple de ce type de problèmes ou finalement on se retrouve à reproduire les biais du système.

Pour la politique je ne peux parler que pour moi, et oui, je suis certaine de ne pas être libérale, aucun doute, mais communiste ben… non plus. Pour ce qui est de critères techniques, IN COMMON est bien un projet décentralisé, la gestion des agents revient à chaque entité, mais elle permet de supplanter un défaut de présence d’une entité par une personne extérieure par exemple.

excellent, c’est vraiment ce que nous devons discuter, savoir si le format propos vous permet de faire cela, aussi nous nous proposions de visiter @Sebastian qui se trouve dans le sud ouest comme nous une bonne part de l’année.

Excellent nous en ferons la demande merci

Oui je crois que c’est une bonne idée encore à confirmer avec le reste de l’équipe

Nous avons une divergence sur ce sujet. Nous pensons que les sources sont autonomes pour gérer leur modération comme elles le souhaitent tant que les données qui remontent dans Transiscope respectent la charte. Si elle n’est pas respecté nous pouvons tout simplement déréférencer la source tant qu’elle n’a pas trouvé de solution. Nous souhaitons également mettre en place un bouton sur l’interface graphique pour que les utilisateurs puissent signifier à la source que une donnée ne respecte pas la charte. Transiscope en serait informé et pourrait intervenir si cela revient trop souvent sur une source pour trouver un protocole technique/humain pour éviter de les déréférencer.

Je veux bien plus d’explication/documentation sur ce sujet

Salut @simon.louvet.zen,

la principale différence entre Transiscope et IN COMMON n’est pas idéologique mais technique : notre modèle de menaces (threat model) conçoit que « la source » fait partie des acteurs potentiellement hostiles ; ce qui fait qu’une source qui intègrerait des données de greenwashing ne pourrait pas les faire apparaître dans la base de données publique d’IN COMMON, car elles ne correspondent pas à la charte : dans une optique de long terme, lorsqu’il y aura trop de données pour faire de la modération a posteriori, cette approche favorisera le respect de la charte et non la confiance à la source – on a trop vu d’initiatives, comme par exemple le label BIO, passer aux mains des géants de l’agro-industrie pour y intégrer des OGMs et de l’industrialisation… L’optique d’IN COMMON est donc de garantir la qualité des données plutôt que leur disponibilité immédiate.

C’est la route que nous avons exploré en priorité : il s’agira dans un premier temps d’affiner la granularité les données : la précision demandée par IN COMMON étant supérieure à celle que Transiscope utilise pour l’instant, et le format des champs est normé (par exemple dans le cas des numéros de téléphone…)

Tout à fait : non seulement cela permettrait d’ajouter un label de qualité et de réintégrer des données “améliorées”, pour participer d’une transition vers le modèle normé d’IN COMMON, cela permettrait également à terme de repérer dans les données de Transiscope celles qui ne concernent pas les Communaux.

La visualisation est un élément relativement accessoire dans IN COMMON : chaque mode de visualisation devrait pouvoir être développé indépendamment des données disponibles.

c’est bien cela l’enjeu, comment determiner que les données respectent la charte lorsque l’on change d’échelle.

A ce moment c’est vous qui prenez la décision et donc la centralisez… et puis encore une fois si quelqu’un ou plusieurs personnes se met(tent) à référencer tous les panneaux publicitaires par exemple aurez vous vraiment le temps d’adresser le problème.

Le principe est que la source se donne les moyens de son échelle. Ce n’est pas à Transiscope de lui dire comment faire. Nous vérifions ses moyens avant de les référencer et nous intervenons qu’en cas de non respect manifeste de la charte qui peuvent être du à un débordement de la sources (moyen de modération non suffisant) ou intentionnel (ca ne devrait pas arriver avec la selection que nous faisons en amont mais ca peut arriver). J’ai l’impression que nous avons une autre différence : toutes les sources de donnée qui en font la demande ne sont pas intégrées. Le groupe de travail “source” fait une sélection et a déjà refusé des jeux de données car ils ne présentaient pas toutes les garanties attendues ou qu’il ne voulais pas filtrer leurs données pour ne remonter que celles qui respectent la charte.

Quels sont les critères de sélection d’une source ? Est-ce que IN COMMON te paraît acceptable ?

On est en train d’affiner la documentation et le modèle de IN COMMON, je m’assurerais que tu sois tenu au courant des avancées au fur et à mesure.
Aussi on a un peu avancé depuis les spécifications V0mentionnées ci haut, notamment nous intégrerons les spécifications d’activity pub.

Oui c’est un élément important, je vais rédiger un topo spécifique, je te le partagerais asap

1 Like

Nous centralisons ce qui rentre dans le périmètre de notre projet (charte, interopérabilité…) en générant le moins possible d’ingérence/préjudices/efforts aux sources. Nous réfléchissons même à redistribuer aux sources une partie des financements que nous obtiendrons et à offrir des formations (technique, data, gouvernance, licences…) pour qu’elles aient les moyens nécessaires à assurer la qualité des données.

Je comprends mieux ce que tu veux dire par là mais effectivement nous avons une notion bien plus large de ce qu’est une source, ce peut être un individu qui prend une initiative dans sa zone très locale, nous ne nous permettrions jamais d’être intrusif dans son univers pour savoir si son apport est fiable ou non.

Oui c’est une approche vraiment intéressante qui complète bien votre démarche, d’agréger une communauté.

C’est à In Common de dire en quoi les données respectent la charte de Transiscope.


A première vue, seul le critère 3 de la Charte de Transiscope semble inscrit dans la charte de In Common. Nous devront donc trouver une solution de filtrage pour ne récupérer que les données qui respectent les autres points de la charte.
Info : Le critère 1 est en réflexion et pourrait évoluer vers une gouvernance partagée de l’alternative plutôt que une gouvernance exclusivement citoyenne.

Alors que nous demandons à cet individu de se référencer sur une source de confiance dans notre fonctionnement. C’est aussi une démarche philosophique dans laquelle nous considérons que l’action collective est devenue incontournable par rapport à l’action individuelle.

1 Like

commentaire à part : votre forum est vraiment top (ergonomie). quel est le logiciel?

C’est Discourse, oui, cela fait bien 25 ans que je pratique les forums et celui-là est incomparable. Nous comptons l’intégrer avec IN COMMON. GPL-power.