Differences

This shows you the differences between two versions of the page.

--- scenario-lum [2025/02/28 18:57]
47.128.49.246 old revision restored (2025/01/21 17:58)
+++ scenario-lum [2025/04/15 02:35] (current)
47.128.115.29 old revision restored (2025/01/22 17:42)
@@ Line 1: / Line 1: @@
+====== Modification de luminosité dans une pièce: Découverte de pattern sensorimoteur par deux objets ======
-Dans le point de vue prÃ©cÃ©dent, l'accent a Ã©tÃ© mis sur le fonctionnement
+Ce scénario reprend le principe de //flux d'instances d'évènements// entre
-globale du modÃ¨le. De ce point de vue, au contraire, nous allons nous
+les différents avatars définit dans [[scenario-nocaptor | une réflexion
-concentrÃ©, pas Ã  pas, sur les suites logiques d'Ã©vÃ¨nements pouvant arriver
+sur la création de pattern pour un objet sans capteur]].
-Ã  un systÃ¨me d'apprentissage.
-=== Variables d'entrÃ©es et DÃ©coupe ===
+===== Introduction =====
-Reprennons Ã  partir de la dÃ©coupe d'une variable d'entrÃ©e,
+==== Les objets ====
-par exemple V<sub>2:2</sub>.
-{{wiki:V2_2.png}}
+Dans une même pièce se trouve :
+  * Un système d'éclairage (lampe), avec interrupteur et capteur de luminosité.
+  * Une fenêtre équipée d'un store électrique, avec un interrupteur permettant de faire monter ou descendre plus ou moins le store (pas de capteur de luminosité).
+==== La routine de travail de Billy ====
-== Couple DÃ©couper - SimilaritÃ© (D-S) ==
+Billy, notre utilisateur, se lève et se rend dans son bureau. Faisant encore
+nuit, Billy allume la lumière, il est 6h.
-L'apprentissage de la dÃ©coupe d'une variable
+Vers 8h Billy sait qu'il fait jour dehors, il éteint donc la lumière et ouvre
-d'entrÃ©e est implÃ©mentÃ© par un couple D-S. Leurs
+en grand les stores électrique de sa fenêtre.
-intÃ©ractions, dont nous allons voir le fonctionnement,
-permet de connaÃ®tre la "pertinence" du dÃ©coupage
+Ceux-ci reste ouvert jusqu'à ce que, vers 19h, Billy se rende compte
+que le soleil se couche. Billy allume donc la lumière de son bureau,
+puis ferme les stores.
+Billy reste ensuite dans son bureau jusqu'à 22h, il éteint alors la lumière
+avant de partir.
+(oui, Billy travaille beaucoup plus qu'il ne le devrait).
+L'action se déroule dans le bureau de notre utilisateur, Billy,
+et ce durant plusieurs semaines.
+==== Les variables d'entrée du système ====
+Au départ de ce scénario, les avatars n'ont pas encore identifiés de pattern
+récurrents, il n'existe donc pas encore de variables internes (ou de **flux
+d'instances**), uniquement des variables d'entrées continues correspondant aux
+capteurs et actionneurs des objets.
+  * Pour le système d'éclairage les variables d'entrées sont :
+    - l'état de l'interrupteur du système d'éclairage, que nous nommeront V<sub>1:1</sub>.
+    - l'intensité lumineuse de la pièce, nommée V<sub>1:2</sub>.
+  * Pour la fenêtre équipée d'un store électrique :
+    - l'état de l'actionneur de store, nommée V<sub>2:1</sub> (-1 : descendre le store, 1 : monter le store, 0 : sinon).
+    - Pourcentage d'ouverture du store, nommée V<sub>2:2</sub> (allant de 0, le store est fermé, à 1 le store est ouvert).
+En se basant sur les actions de Billy, décrites précédemment,
+nous pouvons supposer que les variables d'entrée du système
+d'objets connectés varieraient, plus ou moins, comme présenté
+sur les graphiques ci-dessous.
+{{wiki:rplot_all_scenario_lum.png}}
+Le but étant de voir comment le système
+d'éclairage et le store pourraient arriver
+à faire la relation entre la levée du store
+et l'augmentation de luminosité, via leurs échanges.
+{{wiki:rplot_v12_v22_relation.png}}
+===== Système d'apprentissage (point de vue du système d'éclairage) =====
+Nous allons voir dans cette partie le fonctionnement
+du système d'apprentissage, en prenant le point de
+vue de l'avatar du système d'éclairage.
+Le système d'apprentissage est basé sur un système multi agents
+qui arriveront, par leurs interactions, d'extraire des motifs
+pertinents pour les interactions des avatars entre eux.
+De plus il utilise un système de flux d'évènements lui permettant
+d'échanger des informations avec les systèmes d'apprentissages des
+autres avatars de la société (ici le store).
+==== Couples Producteur-Similarité ====
+Le système multi agents d'apprentissage implémente
+des agents différencié en trois rôles :
+  * Les agents //Producteur//, qui manipulent des données et tentent d'en créer de nouvelles, ils sont différenciés en deux rôles :
+    * Les agents **Découper**, qui sont liés aux variables d'entrées du système d'apprentissage (correspondant aux données venant des capteurs et actionneurs de l'objet).
+    * Les agents **Association**, qui sont liés aux flux d'évènements (internes ou externes) et cherchent à associer des évènements provenants de ses flux pour en créer de nouveaux.
+  * Les agents **Similarité**, qui eux sont toujours liés à un agent //Producteur//, tentent de différencier les types //d'instances d'évènements// et d'identifier les plus pertinents.
+Ainsi les agents du système d'apprentissage fonctionnent
+toujours en **Couples Producteur-Similarité**.
+=== Couple Découper - Similarité (D-S) ===
+L'apprentissage de la découpe d'une variable
+d'entrée est implémenté par un couple D-S. Leurs
+interactions, dont nous allons voir le fonctionnement,
+permet de connaître la "pertinence" du découpage
 d'une variable en particulier. Ils font varier leurs
-paramÃ¨tres en explorant l'espace de marquage vu prÃ©cÃ©demment.
+paramètres en explorant l'espace de marquage vu précédemment.
-== DÃ©coupe ==
+== Découpe ==
-L'agent DÃ©couper d'un couple D-S associÃ© Ã  la variable V<sub>2:2</sub>
+L'agent Découper d'un couple D-S associé à la variable V<sub>2:2</sub>
-a pour paramÃ¨tre un Ît qui est la taille de la fenÃªtre de dÃ©coupe.
+a pour paramètre un Δt qui est la taille de la fenêtre de découpe.
 {{wiki:decoupe.png}}
-L'agent DÃ©couper va alors parcourir la variable d'entrÃ©e en faisant
+L'agent Découper va alors parcourir la variable d'entrée en faisant
-"glisser" sa fenÃªtre de dÃ©coupe le long des variations. La fenÃ¨tre
+"glisser" sa fenêtre de découpe le long des variations. La fenêtre
-peut Ãªtre simplement glissante, ou bien glissante et suivant les
+peut être simplement glissante, ou bien glissante et suivant les
-variations de la variable d'entrÃ©e, comme sur l'image ci-dessus.
+variations de la variable d'entrée, comme sur l'image ci-dessus.
-La portion dÃ©coupÃ©e par l'agent DÃ©couper est alors reprÃ©sentÃ© sous
+La portion découpée par l'agent Découper est alors représenté sous
 la forme d'un histogramme.
-== SimilaritÃ© et DiffÃ©renciation ==
+== Similarité ==
-Les histogrammes produit par l'agent DÃ©couper sont alors rÃ©cupÃ©rÃ©
+Les histogrammes produit par l'agent Découper sont alors récupéré
-par l'agent SimilaritÃ© qui lui associÃ©.
+par l'agent Similarité qui lui associé.
-Celui ci compare les nouvelles instances d'Ã©vÃ¨nement avec ceux qu'il
+Celui ci compare les nouvelles instances d'évènement avec ceux qu'il
-a stockÃ© prÃ©cÃ©demment, ou plutÃ´t avec l'histogramme reprÃ©sentant la moyenne
+a stocké précédemment, ou plutôt avec l'histogramme représentant la moyenne
-de chaque groupe d'instances similaires. Cette "moyenne" peut Ãªtre considÃ©rÃ©
+de chaque groupe d'instances similaires. Cette "moyenne" peut être considéré
-comme un prÃ©-concept d'Ã©vÃ¨nement.
+comme un pré-concept d'évènement.
-La fonction de comparaison utilisÃ©e pour diffÃ©rencier les instances dÃ©coupÃ©es
+La fonction de comparaison utilisée pour différencier les instances découpées
-en une fonction d'intersection entre les deux histogrammes reprÃ©sentant les
+en une fonction d'intersection entre les deux histogrammes représentant les
 instances.
 {{wiki:similarite.png}}
-Ainsi l'agent SimilaritÃ© du couple D-S "rangera" les nouvelles instances
+Ainsi l'agent Similarité du couple D-S "rangera" les nouvelles instances
-d'Ã©vÃ¨nements avec celles qui lui sont le plus similaire, modifiant par la
+d'évènements avec celles qui lui sont le plus similaire, modifiant par la
-mÃªme la moyenne de ce groupe d'instance. Si aucun groupe n'est trouvÃ© pour
+même la moyenne de ce groupe d'instance. Si aucun groupe n'est trouvé pour
-une instance, alors un nouveau lui correspondant sera crÃ©Ã©.
+une instance, alors un nouveau lui correspondant sera créé.
-n.b: le paramÃ¨tre de l'agent SimilaritÃ© serait sont seuil d'acceptation
+Les paramètres des agents Similarité est leur seuil de similarité, c'est
-de similaritÃ©, mais cela reste Ã  confirmer.
+à dire le seuil qui leur fait dire si oui ou non deux instances sont similaires.
-== Feedback et sÃ©lection de concept ==
+=== Couple Association Similarité (A-S) ===
-Avant que la moyenne d'un groupe d'instance soit considÃ©rÃ©e comme un rÃ©el
+Déterminer l'intérêt d'associer un flux à un autre est
-concept d'Ã©vÃ¨nement, l'agent SimilaritÃ© d'un couple D-S va calculer l'intÃ©rÃªt
+la fonction des couples A-S. Les couples A-S de type
-de chaque prÃ©-concept, et marquer le maximum de ces intÃ©rÃªts dans l'espace de
+//Explorateur// se déplaçant et marquant l'intérêt des
-marquage des couple D-S.
+paramètres testés dans l'espace de marquage.
+== Association ==
+L'agent Association d'un couple A-S prend pour référence
+le flux (interne ou externe) au quel il est affecté dans
+l'espace de marquage. Les paramètres de l'agent Association
+étant les autres flux auquel il tente d'associer son flux
+de référence.
+Un agent Association créé donc des motifs basés sur une
+association d'un évènement **e1** et d'un évènement **e2**,
+puis créé des instances de ce motif à chaque fois que des
+instances de e1 et e2 sont captées, toujours une de chaque,
+une puis l'autre, séparé d'un certain Δt pouvant être nul (voir
+négatif).
+{{wiki:motif.png?250}}
+== Similarité ==
+Tout comme pour le couple D-S précédemment présenté, l'agent
+Similarité va comparer et trier les différentes instances de
+l'association.
+La similarité entre deux associations est calculé par rapport
+à la différence entre les Δt de chaque associations. L'agent
+Similarité d'un couple A-S "rangera" donc les instances produite
+par l'agent Association selon leurs Δt.
+<note>
+TODO : image/illustration
+</note>
+==== L'espace de marquage ====
+A partir des éléments de la section précédente, décrivant les
+agents et les couples d'agents, nous pouvons décrire les choix
+des paramètres de ces agents comme l'exploration d'un **espace
+en trois dimensions** par les couples d'agents.
+{{wiki:hemis_marquage.png}}
+Ces trois dimensions représentent :
+  - Les variables ou flux, auquels peuvent se lier les couples.
+  - Les paramètres possibles de l'agent //Producteur//.
+  - Les paramètres possibles de l'agent //Similarité//.
+Cet **espace en trois dimensions** sert de "mémoire" au
+couples du même type qui le **marque** pour se "souvenir" des
+paramètres potentiellement intéressants pour une variable
+ou un flux, à la manière d'un dépôt de phéromones. Il existe
+donc un **espace de marquage** par type de couple (voir plus
+si certains agents implémente plusieurs fonctions différentes,
+ex. deux espaces pour les couple D-S si les agents Découper
+ont deux fonctions de découpe possibles).
+Pour les **espaces de marquage**, les couples d'agents se
+différencient en deux types : les **Explorateurs** et les
+**Exploiteurs**.
+=== Les explorateurs ===
+Comme leurs nom l'indique, ceux sont les couples "bougeant"
+le plus dans l'espace de marquage, afin de déterminer
+rapidement quels sont les paramètres les plus pertinents
+pour une variable donnée.
+Les //Explorateurs// commencent par se fixer à une position
+fortement marquée (ou aléatoire si aucun marquage), puis se
+déplacent en "spiral" jusqu'à trouver une place libre.
+Alors ils testent les paramètres un certain temps, marque
+l'emplacement de l'intérêt maximum trouvé, puis se redéplacent.
+=== Les exploiteurs ===
+Ce type de couple se fixe sur les emplacements les plus
+marqués, peuvent se déplacer légèrement autour et se
+"téléporter" d'un emplacement pertinent à un autre.
+Les //Exploiteurs// continue de marquer l'intérêt de
+l'emplacement, les couples A-S y rajoute un marquage
+de prédiction, permettant de donner plus de poids à
+un emplacement.
+==== Feedback d'intérêt ====
+Dans la section précédente nous avons parlé du marquage
+d'un intérêt dans **l'espace de marquage**. Celui-ci est
+calculé à partir d'un **feedback d'intérêt** dont se sert
+les agents Similarité pour classer les instances d'évènement
+en groupe, chaque groupe ayant un intérêt, c'est l'intérêt
+maximum qui est marqué dans l'espace de recherche aux coordonées
+correspondant à la variable et aux paramètres des agents.
+=== L'intérêt intrapersonnel ===
+Une découpe de variable, ou une association de flux, est évalué sur
+sa capacité à découvrir des motifs pertinents pour soi, sans prendre
+en compte autrui. Cet intérêt sert essentiellement au marquage de
+n'importe quels évènements captés, que se soit des évènements internes
+comme externes.
+**L'intérêt intrapersonnel** se calcule à partir de la **spécificité**,
+le **poids** et la **précision** des évènements évaluées.
+La **spécificité** d'un évènement est calculé à partir de la différence
+entre l'évènement et la moyenne générale de tous les évènements. La
+spécificité permet ainsi d'identifier les évènements "sortant du lot".
+Le **poids** d'un évènement correspond à son nombre d'occurence
+par rapport au nombre d'occurence des autres évènements.
+La **précision** d'un évènement, pour l'intérêt, peut être calculé
+à partir de l'écart type des similarités entre les instances d'un
+évènement.
+=== L'intérêt interpersonnel ===
+Pour nuancer le poids de l'intérêt intrapersonnel sur l'intérêt
+global d'un évènement, et aussi pour éviter une certaine redondance
+des motifs appris par les différents systèmes, un **intérêt
+interpersonnel** est calculé.
+Cet **intérêt interpersonnel** prend en essentiellement l'aspect
+social de l'apprentissage et permet de donner un intérêt plus
+fort pour les motifs étant plus pertinents d'indiquer aux autres,
+c'est à dire du système (le //moi//) vers les autres systèmes (//autrui//).
+L'**intérêt interpersonnel** est calculé à partir du **nombre de
+flux/variables internes utilisé(e)s** pour l'élaboration du concept
+d'évènement évalué et du **nombre de flux/variables nécessaires** pour
+la création d'une instance en fonction du type de couple (1 pour les
+couple D-S et 2 pour les couples A-S).
+Ainsi cet intérêt permet de donner plus de poids aux évènements n'utilisant
+que de flux/variables internes, puis aux évènements associant un flux interne
+et externe, et enfin les associations de deux flux externes.
+<note tip>
+Concernant les motifs "d'intéraction" :
+Une certaine redondance de l'apprentissage se retrouve lors de la
+découverte de motifs dit "d'intéraction", c'est à dire mettant
+en jeux plusieurs systèmes, donc des associations entre un flux
+interne et un flux externe. Un même motif peut potentiellement
+être appris et diffusé par deux systèmes différents.
+Exemple (en restant du point de vue du système d'éclairage) :
+le store m'indique qu'il s'est ouvert (V2:2, ou V2:1, voir un motif
+associant les deux), je capte une augmentation de la luminosité (V1:2)
+que je communique aussi. L'association de l'ouverture du store (e1) et de
+l'augmentation de la luminosité (e2) est faite par les deux systèmes et
+les deux systèmes créent des flux correspondant à cette association, il
+y a donc redondance.
+Cette redondance est elle un mal ?
+Doit-on utiliser cette redondance à notre avantage et l'utiliser
+pour faire un consensus sur des motifs communs à certains objet ?
+Si oui comment détecter qu'un même motif a été découvert par deux
+systèmes différents et comment arriver à un consensus et comment
+décider lequels des systèmes aura pour rôle de notifier les autres
+des instances de ce motif ?
+D'un autre point de vue, cette redondance est elle nécessaire ?
+Ne pourait on pas faire en sorte "d'orienter" l'apprentissage
+pour qu'un minimum de système, au mieux un seul, découvre ce motif ?
+Personellement je penche plus vers ce second point de vue. Nous
+pourrions par exemple donner plus d'intérêt à un concept d'association,
+ou d'interaction, si l'évènement e2 de cette association est capté par un flux
+interne.
+Pour reprendre l'exemple: dans l'association "ouverture store" -> "augmentation
+luminosité", e2 provient d'un flux interne pour le système d'éclairage l'association
+et d'un flux externe pour le store. L'association aura donc un plus fort intérêt à
+être exploité par le système d'éclairage que par le store électrique.
+Partir sur ce principe permettrait de trouver plus rapidement des motifs "d'intéraction"
+complexe, c'est à dire mettant en jeu plusieurs avatars.
+De plus vérifier qu'un motif est "vrai" est plus facile que de détecter une redondance
+(avis personnel), quand bien même qu'avant d'être diffusé un motif est passé par une
+longue phase vérification, donc les systèmes n'ont pas vraiment de "raison" vérifier la
+véracité d'un motif, juste de regarder si il leur est utile ou non. De plus les systèmes
+ont les mêmes capacités d'apprentissage, raison de plus pour qu'ils se fasse "confiance"
+leur de l'apprentissage de motif d'intéraction (je ne parle ici que d'apprentissage et non
+de synchronisation entre eux).
+</note>
+=== Calcul du feedback ===
+Le feedback d'intérêt **Ί** d'un évènement e se calcule donc à partir du rapport
+de son intérêt intrapersonnel **Ί<sub>α</sub>** sur son intérêt interpersonnel
+**Ί<sub>ε</sub>**.
+Pour le calcul de **Ί<sub>α</sub>** d'un évènement, notons sa spécificité **s**,
+sa précision **p**, son poids **π**.
-Le feedback d'intÃ©rÃªt d'un prÃ©-concept d'Ã©vÃ¨nement est calculÃ© Ã  partir de la
-spÃ©cificitÃ© de cet Ã©vÃ¨nement, c'est Ã  dire si l'Ã©vÃ¨nement "sort du lot", et
-de la rÃ©curence de cet Ã©vÃ¨nement. Pour faire simple, parmis tous les Ã©vÃ¨nements
-"rare", celui qui aura le plus fort intÃ©rÃªt sera celui qui arrive le plus souvent,
-donc potentiellement le moins dÃ» au hasard.
 <code>
+Ί(e) = Ία(e)^δ / Ίε(e)^β
-    TODO: equation with MathJax
+avec :
+  Ία(e) = s(e) * p(e) * π(e)
+et
+  Ίε(e) = (Nb_Var_Necessary(e) + 1) - Nb_Internal_Var_Used(e)
+remarque: les coefficients δ et β ne sont présent que pour donner
+plus de "poids" à l'un ou l'autre des intérêt. Par défaut δ = β = 1.
+</code>
+=== Feedback Prédictif ===
+Lorsqu'un motif créé par un couple A-S semble "intéressant", celui-ci
+passe un mode "prédictif", les couples A-S tente alors d'utiliser ce
+motif pour prédire l'apparition d'évènement e2, à partir de l'apparition
+d'un évènement e1.
+Ce feedback prédictif est un score **s** caculé à partir d'une précision
+**acc**, qui est calculé à partir d'une tolérance **tol** (qui est l'écart
+type de la durée entre e1 et e2 lors des prédictions réussies) et de la
+fréquence d'apparition de e2.
+et d'une confiance **rel**, qui est le rapport de prédictions juste sur
+le nombre de prédictions tentés.
+<code>
+s = acc * rel
+avec :
+  rel = nb(prédictions) / nb(e1)
+et
+  acc = 1 - ( tol * freq(e2) )
 </code>
-C'est lorsqu'un couple D-S de type //Exploiteur// se positionnera, dans l'espace
+Le maximum des scores est ajouté à l'intérêt dans l'espace de marquage des
-de marquage, sur les paramÃ¨tres de dÃ©coupe de V<sub>2:2</sub> que la crÃ©ation de
+couple A-S pour la variable et les paramètres associés, leurs donnant ainsi
-Flux d'instance se fera pour les concept ayant la plus haute spÃ©cificitÃ©.
+plus de poids.
-== Conception de flux d'instances ==
-Comme dit prÃ©cÃ©demment, les couples D-S vont extraire
+<note tip>
-des //concepts d'Ã©vÃ¨nements// et crÃ©er des //flux d'instances d'Ã©vÃ¨nements//.
+Pour l'instant le feedback prédictif sera utilisé comme ceci, mais
-Ces flux pourraient correspondre Ã  des flux RSS (ou tout autre outils permettant
+n'est pas exclu d'être modifié.
-le partage d'un "fil d'Ã©vÃ¨nements"), ils seront ainsi mis Ã  jour part l'agent
-SimilaritÃ© du couple associÃ©, Ã  chaque fois que l'agent DÃ©couper extrait une
-nouvelle //instance d'Ã©vÃ¨nement// correspondant au //concept d'Ã©vÃ¨nement//
-du flux.
-Supposons qu'Ã  partir de V<sub>2:2</sub> deux concepts d'Ã©vÃ¨nements soient
+Une possibilité serait d'utiliser les formules utilisées en statistique
-crÃ©Ã©s.
+pour évaluer un classifieur.
-TODO : image
+Le score serait calculé à partir :
-Il y aura donc de flux de crÃ©Ã© par le couple D-S affectÃ© Ã  cette variable
+  * d'une **sensibilité** qui est le rapport des **vrais positifs** ou VP (les prédictions juste) sur toute les prédictions dite comme vrais (toutes les fois où l'on a supposé l'arrivé de e2 à partir de e1).
-d'entrÃ©e. Ces flux Ã©tant internes du point de vue du store et externe
-du point de vue du systÃ¨me d'Ã©clairage.
-<code>
+  * et d'une **spécificité** qui est le rapport des **vrais négatifs** ou VN (les prédictions dite fausses et vraiment fausses) sur toutes les fois où l'on a dit que e2 n'arrivera pas après e2.
-Exemple de description d'un flux en JSON-LD :
-{
+Si nous voulons utiliser ces formules il faudra donner la possibilité
-  "@context": "http://www.w3.org/ns/activitystreams",
+au couple A-S prédicteur de dire Oui ou Non à la question : un évènement
+e2 arrivera-t-il après cet évènement e1 ?
-  "@type": "Activity",
+Ceci pourrait être fait à partir d'un de l'écart de temps entre les deux
+instances, par exemple : si e2 n'est pas encore apparu un temps T après
+l'apparition d'un évènement e1, alors il n'arrivera surement jamais.
+</note>
-  "published": "2016-01-25T12:34:56Z"
+==== Flux d'instances ====
-  "author": {
+Lorsqu'un concept d'évènement, qu'il soit découvert part un couple D-S
-    "@type": "Object",
+ou A-S, est déterminé comme "intéressant" alors un **flux d'instances**
+correspondant au concept d'évènement est créé pour pouvoir y partager
+les instances de ce concept (c'est à dire les instances similaires
+au concept d'évènement) avec les autres systèmes.
-    "@id": "URI de l'objet / URI du flux"
+=== Identification ===
-  }
-  "orderedItems": [
+Du point de vue d'un système, et donc de ses agents, un flux est perçu
-    {
+comme un **flux interne** si celui-ci a été créé par le système, et
-      "@type": "Event"
+comme un **flux externe** si il a été créé par un autre système.
-        ...
+<note>
-    },
+Par exemple :
-    {
-      "@type": "Event"
-       ...
+Du point de vue du système d'éclairage, les flux d'instances correspondant
-    }
+aux concepts : augmentation soudaine de la luminosité,
-  ]
+augmentation progressive de la luminosité, diminution soudaine de la luminosité,
-}
+interrupteur passe à ON, interrupteur passe à OFF, etc... seront perçus
-</code>
+comme des **flux interne** car créé par le système d'éclairage.
+A l'inverse, les flux correspondant aux concepts : store s'ouvrent, store
+se ferme; seront perçu comme des **flux externes**.
+</note>
+Pour aider à l'identification d'un flux par un système, et ses agents,
+est associé au flux URI du système l'ayant créé (donc l'URI de l'avatar)
+et l'URI du concept correspondant au flux (généré par le système). Les
+agents d'un système connaiteront l'URI de l'objet.
+{{wiki:flux_notation.png}}
+<note>
+TODO : mettre à jour l'image quand une notation aura été définie.
+</note>
+=== API de transfert d'instances ===
+<note important>
+Le fonctionnement de l'API de flux n'est, pour le moment, pas clairement
+définie. Ce qui est écrit dans cette section sont des idées sur le fonctionnement
+général de l'API et sur l'adaptation possible de protocoles, API ou frameworks déjà
+existant pour les besoins du système d'apprentissage.
+</note>
+== Fonctionnement hypothétique ==
+Si nous prenons le point de vue d'un avatar, le principe des flux
+reviens à proposer un service de notification d'évènements aux autres
+avatars de la société.
+<note>
+Le mot service utilisé ici ne correspond pas forcément
+à un service web à proprement parlé, ce n'est peut être pas
+le bon mot à employer.
+</note>
+Ainsi lorsque le système d'apprentissage créé un flux correspondant
+à un concept d'évènement, un flux/service de notification est alors
+créé par l'avatar et les autres avatars de la société sont avertis
+de la création du service de notification. (par la même, si un service
+de notification est détruit, les autres avatars seront avertis de sa
+destruction, et le flux externe du système d'apprentissage sera détruit).
+Lorsqu'un avatar est avertis de la création d'un service de notification,
+son système d'apprentissage créera un flux d'instance correspondant.
+Lorsqu'un couple A-S prendra pour référence un flux externe, cela signifiera
+que l'avatar "s'abonne" au service de notification proposé par un autre avatar.
+De la même manière un avatar "s'abonnera" à un service de notification si un
+couple A-S tente d'associer son flux référence à un flux externe.
+== Protocoles, API, frameworks déjà existants ==
+Pour implémenter une API permettant de mettre en place de tel fonctionnalités,
+adapter certains protocole/API/frameworks à nos besoins pourrait être pertinents.
+Ci-dessous sont listés quelques API potentiels :
+  * Les flux RSS
+Le mode de fonctionnement des [[https://fr.wikipedia.org/wiki/RSS | flux RSS]] semble
+plutôt bien correspondre au principe des flux d'instances (d'ailleurs c'est de là qu'ils
+tirent leurs noms). Cependant les flux RSS ont quelque faiblesse, se sont des fichiers
+XML où sont écrit toutes les notifications et sont accessible par tous. De plus se sont
+les outils "abonnés" qui regarde, à intervals réguliers, si des modifications on eu lieu
+dans le fichier XML. Ce ne sont donc pas de réelles "notification" fait d'un serveur à un
+terminal (pour notre cas, d'un avatar à un avatar) et il faudrait mettre en place un
+programme permettant de détecter la création (ou la suppression) d'un flux dans la société.
+  * Le réseau Usenet et le protocole NNTP/S
+Le réseau [[https://fr.wikipedia.org/wiki/Usenet | Usenet]] est à la base un système
+de réseaux de forums permettant le partage rapide, à des groupes "d'abonnés", de nouvelles
+(ou news) concernant un forum. Il utilise le protocole [[https://tools.ietf.org/html/rfc3977 | NNTP]]
+qui a été conçu spécialement pour le transport de news dans un réseau, il existe en version
+"sécurisé": NNTPS. La [[https://tools.ietf.org/html/rfc1036 | RFC1036]] décrit le format
+standard des échanges de messages dans un réseau Usenet.
+==== Récapitulatif =====
+Avant de passer au fonctionnement pas à pas de l'apprentissage en prenant le point de vue
+du store électrique, voici un récapitulatif du fonctionnement général du système d'apprentissage.
+=== Variables d'entrées & Découpe d'instances d'évènements ===
+Les **couples D-S** vont explorer leur **espace de marquage** en y déposant l'intérêt maximum
+trouvé avec les paramètres associés. Ce marquage sert de mémoire pour retrouver
+facilement des paramètres pertinents et va aussi influencer les déplacements des
+couple D-S dans l'espace de marquage, c'est à dire dans leurs choix de paramètres.
+L'agent **Découper** d'un couple D-S fait "glisser" une fenêtre de découpe sur
+la variable d'entrée, créant ainsi des instances d'évènement. L'agent **Similarité**
+associé à cet agent **Découper**, c'est à dire formant un couple avec, va "trier"
+par "type" d'instance plus ou moins similaire et évaluer l'intérêt Ί de chaque
+"type" d'instance. (L'intérêt max trouvé avec leurs paramètres est la valeur
+déposé dans l'espace de marquage).
+Une fois des "type" d'instances validé comme "intéressants" ceux-ci deviennent
+des **concepts d'évènements**, des **flux d'instances** sont créés et lorsque
+l'agent Découper d'un couple D-S produit une instance d'évènement correspondant
+à un concept d'évènements, l'agent Similarité lié diffuse l'instance par le flux.
-n.b: Le fonctionnement de l'API de notification et de partage de flux n'est pour
+{{wiki:flux_creation.png}}
-l'instant pas clairement dÃ©finie.
-=== Flux d'instances et Association ===
+=== Flux d'instances & Association d'évènements ===
-Reprennons Ã  partir du moment oÃ¹ tous les flux (internes et externes)
+Le système à maintenant accès des **flux d'instances** lui permettant d'étre informé
-de tous les objets de la sociÃ©tÃ© soient crÃ©Ã©s et accessible par le store.
+lors de l'apparition d'une instance d'un concept d'évènement.
-===== ProblÃ¨mes =====
+Ces flux d'instances peuvent aussi bien être des **flux internes**, c'est à dire des
+flux créés et mis à jour par le système, que des **flux externes**, c'est à dire des
+flux créés et mis à jour par d'autre système.
-  * Supposons que dans cette piÃ¨ce nous rajoutons un chauffage Ã©lectrique connectÃ©, comment faire en sorte que les Ã©changes entre les objets se "spÃ©cialisent" ?
+A partir de ces flux des **couples A-S** vont tenter d'associer deux concepts d'évènements
+en regardant si ils ont l'air plus ou moins corrélés, c'est à dire si l'un arrive toujours
+après l'autre avec toujours le même délai.
-Les Ã©vÃ¨nements proposÃ© par les flux d'instances du chauffage sont en effet peu utile pour le
+Pour cela ils vont parcourir leur espace de marquage, ainsi l'agent **Association** d'un
-systÃ¨me d'Ã©clairage (peut Ãªtre un peu moins pour le store),
+couple A-S prend un flux, et donc le concept d'évènement associer, comme référence et
-le but ici serait qu'au flux externes d'un systÃ¨me, voir Ã  tout l'objet proposant ces flux,
+va explorer les possibilités de combinaisons via ses paramètres. Les instances d'associations
-soit associÃ© un feedback "d'utilitÃ©". Puisque les systÃ¨mes
+produite par l'agent **Association** sont récupéré, trier et évalué par l'agent **Similarité**
-d'apprentissage cherche prioritairement des associations avec pour rÃ©fÃ©rence leurs
+associé.
-flux d'instances internes, nous pouvons facilement l'imaginer Ã©valuer l'utilitÃ©
-d'un flux d'instances externes lui ayant permis ou non de trouver des motifs
-avec pour rÃ©fÃ©rences ses concepts personnels.
-  * Supposons maintenant que dans une autre piÃ¨ce un systÃ¨me d'Ã©clairage identique au notre soit installÃ©, comment permettre que ce nouveau systÃ¨me d'Ã©clairage apprenne plus vite avec l'aide de notre systÃ¨me d'Ã©clairage ?
+Comme pour les couples D-S, l'intérêt maximum trouvé avec des paramètres est noté dans l'espace
+de marquage.
-  * En plus du feedback d'intÃ©rÃªt, il est censÃ© il y avoir un feedback prÃ©dictif, comment un motif pourrait passer un "mode prÃ©dictif" s'il prend en compte des flux externes ?
+L'intérêt Ί de chaque "type" d'instance d'évènement association, c'est à dire les
+différents types de délai entre les deux évènements associé, est calculé à partir
+de la spécificité et la redondance de ce "type" d'instance, mais aussi à partir
+du nombre de flux internes qui a entres en jeux lors de l'association. Ainsi, pour
+une spécificié et redondance, plus d'intérêt est affecté à des associations entre deux
+flux internes, puis entre un flux interne et un flux externe, puis entre deux flux externes.
-  * Comment les avatars pourrait arriver, de maniÃ¨re Ã©mergente, Ã  un consensus concernant un motif, pour que celui soit "commun" Ã  la sociÃ©tÃ© ou Ã  un groupe ?
+Les associations sont aussi évalué à partir de leur capacité prédictive. Et une fois
+qu'une association a été déterminé comme "intéressante" et permettant des prédictions
+fiable, alors un flux d'instance est créé pour y faire passer les instances de cet
+évènement (qui est l'association de deux évènements), et donc potentiellement "avertir"
+autrui de l'arrivé des instances de cet évènement.
+A partir de ce flux d'instance, autrui pourra peut être créer des associations pertinentes,
+qui pourrons me permettre de créer des associations pertinentes, et ainsi de suite.
+{{wiki:flux_association.png}}

DokuWiki

Site Tools

Differences

Page Tools