Warning: Illegal offset type in /home/nfo/prog/lib.php on line 1231
La Société-Réseau - Chapitre 15 : La quantification de l'existant

La Société-Réseau - Chapitre 15 : La quantification de l'existant

08-01-2019 9 min #150502

Bonjour, bienvenue dans le logiciel ! Nous allons créer un Big-Data et quelques les outils pour jouer avec.

Que ce soit des biens, du travail ou des ressources, tout objet d'une transaction doit faire l'objet d'une description détaillée. Nous avons aboli l'administration « papier », mais quand même il reste un travail à faire, c'est de consigner l'existant.

L'intérêt est majeur pour nous, car avec cette infrastructure nous voulons rendre possible l'intégration de nouvelles données ou composantes de problèmes, afin de les résoudre et de produire de la justice. Le logiciel tiendra compte des données dont il dispose, donc on veut qu'il dispose du maximum de données afin d'augmenter sa précision. Sans cela, sans cette base « matérielle », on en revient à devoir résoudre des problèmes tels qu'ils jaillissent dans des esprits irrités et impotents. (Ceux des politiciens.)

15.1 - Les chaînes de blocs

On a dans notre informatique, tout ce qui existe, est fait, est produit, est inventé, échangé. Cela peut paraître beaucoup, mais je vous promets que ça l'est éminemment moins que tout ce que Big Brother a récolté comme données sur vous...

Encore mieux, on garde la trace de tous les travaux entrepris par les hommes, de sorte que le temps offre à en mesurer les conséquences, et d'en tirer les leçons. Même les ressources naturelles, sont exprimées au moyen de leur capacité, de l'entretien qu'elles nécessitent, et du traitement des déchets qui y affère. Tout, absolument tout est consigné. Là, voilà ! On a un bon début de réponse à la question du rapport à la réalité du système.

Pour ce faire nous allons employer les techniques qui permettent le maximum de gain de temps en évitant autant que possible la répétition de données connues(1). Pour cette raison il y aura une base de données de descriptions d'objets qui se consolidera et qu'il suffira d'attacher aux objets courants. En fait les objets auront un code barre qui donnera leur ID. Et à partir de cet ID, on pourra remonter tout ce qui est entré dans sa constitution, aussi bien les matières premières utilisées, leur provenance et leur traitement, et les personnes intervenues tout au long de la chaîne.

En détail, un objet quelconque, mettons une vieille voiture, est identifiée avec ses caractéristiques jugées pertinentes, et qui la différencie de toutes les autres. D'une part, on crée un lien vers ses spécifications techniques du constructeur, et de l'autre on consigne les éléments qui la caractérise, numéro de série, date de fabrication, kilométrage, accidents, réparations, etc.

Cet objet informatique connaît tout au long de sa vie des transformations, des mises à jour de son état. Il peut changer de propriétaire, mais aussi s'intégrer à d'autres objets. Par exemple le destin de la fraise se retrouvant en haut d'un gâteau, détruira la compétence de l'objet « fraise » à être transférée, et son ID ira s'ajouter parmi les composants de l'objet « gâteau » (numéro trois cent vingt mille quatre cent deux).

Suivre le destin d'un objet (et reconstituer la composition d'un gâteau) revient visualiser sa chaîne de blocs (Blockchains) qui pourra relater « pomme, de telle variété, de tel poids, cultivée ici, transportée là, distribuée ici » dans le moindre gâteau, trouvé n'importe où. N'est-ce pas le meilleur moyen de certifier la qualité de ce qu'on nous vend ? Il faut seulement que ce traçage soit organisé de façon systémique. (Là où aujourd'hui il faut enquêter pour révéler l'ignominie.)

15.2 - Les Clusters

La base du fonctionnement des clusters est de pouvoir s'intégrer à d'autres clusters. Chacun d'entre eux peut être de type RED, BLUE ou GREEN (matériel, professionnel, ressources), et en adopter les champs respectifs qui permettent une description. Principalement, ils contiennent un emplacement pour lister les objets parents, qui entrent dans la constitution de l'objet, et une somme de paramètres. Un champ « clone » sert à utiliser un cluster de référence, et un statut stipule si le cluster est disponible, utilisé ou détruit. Un dernier champ fait état des transactions opérées sur ce cluster, donné par un ID de transaction.

L'intérêt des clones de clusters est de récupérer les propriétés d'un cluster abstrait, qui ne peut subir de transactions, mais servir de référence à de multiples clusters.

Illustration 11: Schéma d'un cluster

15.3 - La topologie des clusters

Nous voulons observer la circulation des marchandises et pouvoir remonter à tous les intervenants depuis la plus petite extraction de particule sous un caillou. Pour cela on a une chaîne de blocs qui rassemble des intervenants de façon topologique. On peut utiliser le terme usuel de « chaînes de blocs » (Blockchains), mais comme les blocs sont des clusters (des « grappes »), on peut dire aussi une « chaîne de clusters » (Clusterchains). La différence c'est que les clusters peuvent se brancher les uns aux autres de façon à former un arbre taxonomique.

Illustration 12: Schéma des dépendances entre clusters, de différentes natures

15.4 - Les critères

Un cluster est un bloc défini par son ID unique. Il possède des critères qui le définissent, communs à des groupes et des critères particuliers. Pour ajouter un nouveau critère, on a besoin de le nommer (l'attribut), de lui affecter un référentiel (l'unité de mesure), et enfin une propriété (un nombre ou une qualité).

Illustration 13: propriétés d'un cluster (http://tlex.fr/app/cluster)

Par exemple on peut ajouter l'attribut « température », lui associer un référentiel « degrés Celsius », et enfin une valeur « 18 ».

La structure logicielle en épines que nous avons dû utiliser (chaque entrée appartient à une table distincte et dépend d'une autre de façon récursive), permettrait sur un site de petites annonces de se référer à un produit dès qu'apparaissent les caractéristiques reconnues d'après celles informées à un moment ou à un autre par les utilisateurs.

(J'ai fais le travail qui consiste à créer ce logiciel pour ausculter son fonctionnement.)

15.5 - Les dépendances

Chaque cluster peut très bien posséder des dépendances, qui sont d'autres objets considérés comme intégrés à l'objet en cours.

Un cluster peut être un objet constitué de pièces mécaniques (qu'on peut elles-mêmes ausculter) et qui ont été assemblées (avec une dépendance de type « travail » - BLUE, et une autre de type « espace de travail - GREEN) pour faire le montage des pièces.

Un cluster peut aussi être un lot de marchandises, contenant 32 clusters identiques, avec aucune propriété particulière ni aucune main-d'œuvre.

Illustration 14: Structure des clusters d'un vélo (http://tlex.fr/app/cluster)

15.6 - La circulation et son approbation

Quand un cluster est créé - et n'importe qui peut en créer - il est directement mit en mode « disponible ». Les autres modes sont « usité », et « détruit ». C'est le trans-acteur (on va appeler ça comme ça) qui avalise la transaction. Il le fait sur une base de données distincte, où y figurent les motifs de cet accord, ainsi que le moyen de reconstituer l'état des données qui ont permit la décision au moment où elle a été prise (grâce à une timeline(2) d'activités). Quand l'opération est terminée, le propriétaire a changé (ou pas) le statut du cluster passe du mode « disponible » à celui approprié et le cluster est intégré à un autre cluster (ou pas). Tout ceci ne fait qu'exprimer informatiquement une simple vente.

15.7 - L'assemblage

Sur le schéma des dépendances, j'ai pris l'exemple d'un vélo, le cluster « vélo » est constitué de propriétés (couleur, date de fabrication) et de dépendances qui chacune ont des propriétés (cadre aluminium, roues, accessoires...). Il constitue un bloc indivisible, et leur valeur d'usage est celle de ses composants, et de leur état.

15.8 - Instantanéité

Un des effets surprenants de cette informatique, qui consiste à changer le propriétaire d'un cluster, est qu'on peut opérer des transactions instantanées, en piochant des produits dans un masse de produits capturés à la volée. Un objet tel que notre vélo peut très bien être assemblé en une nanoseconde, auquel cas les ordres de circulation des biens sont donnés jusqu'à l'endroit prévu pour leur assemblage. C'est comme si un robot s'assemblait lui-même pièce par pièce !

On peut aussi imaginer un cluster fantôme, purement hypothétique, qui ne déclenche aucune transaction, afin de « voir » le résultat final. (Note : penser à créer le simulateur 3D qui va avec.)

15.9 - Perspectives

Un tel suivi de l'activité humaine, incluant la production et la circulation des biens, la contribution de chacun, le relevé de l'usage des ressources et des biens publics, est une source de données providentielle pour concevoir des mécanismes de redistribution jugés équitables. C'est un Big Data dans lequel on peut puiser une infinité d'informations et essayer tout autant de méthodes de traitements. Qui sait ce qui pourrait en découler d'autre ?

En tous cas, on peut prévoir l'extraordinaire valeur de ce suivi, notamment dans la lutte contre la criminalité. En réalité aucune activité ne peut se dérouler en dehors du système puisqu'il est conçu pour prendre en charge, assumer, permettre les aspirations des humains et des peuples. C'est là qu'on voit à quel point le degrés d'honnêteté des gens est lié à la justesse de leur système social. Cela constitue un saut évolutif quantique.

(1)Ce qui n'est pas le cas habituellement du Big-Data, qui jouit de la redondance.

(2)Permet de remonter dans le temps

- networksociety 180718

 Proposer une solution