User Tools

Site Tools


compte_rendu_14_janvier_2011

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
compte_rendu_14_janvier_2011 [2011/01/14 11:51]
tigli
compte_rendu_14_janvier_2011 [2011/01/14 16:44] (current)
tigli
Line 1: Line 1:
-====  Meeting ​29 novembre 2010 à Grenoble ​====+====  Meeting ​14 janvier 2011 par Visio====
  
 === Présents === === Présents ===
Line 11: Line 11:
 == Quelques rappels sur nos deadlines == == Quelques rappels sur nos deadlines ==
  
-  * RETARD ​::: Octobre 2010 : D3.2 : Découverte d'​alignement et d'​assemblages : LIG/HADAS +  * Octobre 2010 ::: RETARD ::: D3.2 : Découverte d'​alignement et d'​assemblages : LIG/HADAS 
-  * RETARD ​::: Décembre 2010 : D3.3 :  Raisonnement sur les propriétés et la continuité de service : LIG/HADAS +  * Décembre 2010 ::: RETARD ::: D3.3 :  Raisonnement sur les propriétés et la continuité de service : LIG/HADAS 
-  * Février 2011 : D2.32 : +  * Février 2011 : D2.32 : S'​adapter au contexte, second démonstrateur (Cf. logiciel dans l'​architecture générale) : I3S/ Rainbow 
-  * Février 2011 : D3.4 : +  * Février 2011 : D3.4 : Maîtriser l'​hétérogénéité,​ démonstrateur (Cf. logiciel dans l'​architecture générale):​ LIG /​HADAS ​ 
-  * Février 2011 : D4.3.2 : +  * Février 2011 : D4.3.2 : Mettre l'​utilisateur dans la boucle, démonstrateur (Cf. logiciel dans l'​architecture générale) : LIG / IIHM 
-  * Février 2011 : D5.1 : +  * Février 2011 : D5.1 : Prototype de dispositif Gemalto : GEMALTO ​ 
-  * Mai 2011 : D5.2.2 : +  * Mai 2011 : D5.2.2 : Adaptation et Développement ​ des WebServices métiers version prototypée pour démonstrateur final : Suez environnement / Lyonnaise des eaux  
 +  * Sept 2011 : D5.3.2 : Démonstrateur final : I3S / Rainbow 
  
 == Quelques nouvelles sur le suivi du projet == == Quelques nouvelles sur le suivi du projet ==
  
-RDV JY Tigliavec ​Lyonnaise des eaux (Laurent Kuta) et Ludotic pour définir le panel des utilisateurs qui testeront les interfaces du Weco (28 janvier matin) ​+  * RDV JY Tigli avec Lyonnaise des eaux (Laurent Kuta) et Ludotic pour définir le panel des utilisateurs qui testeront les interfaces du Weco (28 janvier matin)  
 +  * Echanges avec I3S/GemAlto pour spécifier l'​interface le dispositif GemAlto et le Weco (TODO :: Vérifier que les capteurs du dispositif ont bien été définis ​ avec Suez environnement et Lyonnaise des eaux
  
-== Démonstration par Emeric, reconnaissance langage naturel ==  
  
-Voir D4.1 et D4.2 : deux principes de meta-IHM :  
-  * méthode graphique de liaison entre photos d'​objets de la maison 
-  * méthode en langage pseudo naturelle (avec guidelines pour des phrases syntaxiquement et sémantiquement correctes) 
  
-== Présentation par Emeric de la grammaire du langage pseudo naturel (Cf. document)  ​==+== Questions ​  ==
  
-Exemple : Je veux ouvrir ​les volets quand il fait jour et quand il ne fait pas froid.+  * Quel nouveau deadline pour les D3.2 et D3.3 d'​HADAS ? 
 +     * Le D3.2 est en cours de finalisation 
 +     * Le D3.3 nécessite quelques échanges ​ entre les équipes, courant février, et sera donc finalisé à la fin de cette période
  
-Arbre :+==== Le point sur les travaux ​ en cours pour le second et dernier démonstrateur Weco ====
  
-Pg :  +=== Les dernière évolutions ​de la meta IHM à partir ​du langage ​naturelle ​===
- +
-Intro : Je veux +
- +
-Action : ouvrir les volets (action unitaire) +
- +
-Boolean condition Op et +
- +
-Circonstance (when circonstance) : quand il fait jour   +
- +
-Circonstance (when circonstance) : quand il ne fait pas froid +
- +
- +
-== Conséquence sur les devices UPnP ==  +
- +
-Rajouter des meta données sur les devices UPnP  +
-et sur les services. +
-Annotation en pseudo langage.  +
- +
-Pas d'AA dans les meta-données des Services et Devices. +
- +
- +
-== Conséquence sur les AAs ==  +
- +
-Les AAs implémentent : +
- +
-Trigger := When | Where |.... avec logique booléenne / temporelle (events) +
- +
-Action := Méthodes .... avec logique booléenne / temporelle +
- +
-Problème :: les conditions ​de déclenchement de l'​action sont-elles des caractéristiques  +
-du contexte qui déclenche un AA ou les même conditions sont elles le membres droit de l'AA  +
- +
-Autre idée pour la continuité : abstraire la notion de condition (ex. il fait jour) pour la traduire par  +
-différents services ou devices. +
- +
- +
- +
-== Travail sur le scenario ​du fontainier pour la projection des phrases en langage ​pseudo naturel vers des AAs ==  +
- +
-Cas 1 : si (vitesse > x et milieu encombré) alors disable (S1 et S2)  +
- +
-Dans ce cas la condition correspond vraiment à un changement de contexte et la désactivation des AAs  +
-qui utilisent S1 et S2  +
- +
- +
-Idée : Cas généraux (deux cas) : +
- +
-condition contexte -> liste d'AA à activer / désactiver  +
- +
-AA : condition -> action  +
- +
- +
-Cas 2 : Me localiser sur la carte / Où suis-je +
- +
-Comment traduire en AA +
- +
-Cas 3 :  Problème du rétroappel ... +
-En fait il faut aussi annoter les méthodes+getter (ou rétro appel) qui "vont bien" comme méthode possible  +
-pour le device.  +
- +
-Vu le nombre de getter, il faut donc le faire à la main ...  +
- +
-exemple : checkbox pour piloter une light => l'​utilisation de checkbox.setchange__getvalue +
-pour une methode setchange() +
- +
-Cas 4 : problème de l'​initialisation (pas d'​initialisation avec WComp avant l'​émission d'​events)  +
- +
-Cas 5 : si le casque est baissé afficher la position des points d'​intérêt dans le casque +
- +
-Condition (si le casque est baissé)  +
-Action : afficher les points d'​intérêt dans le casque +
- +
- +
-Cas 6 : je veux regarder l'​état de ma machine à laver  +
-  * sous tension (On/Off) [boolean] +
-  * cycle [enum] +
-  * programme ​ [enum] +
-  * temperature [entier] +
-  * temps restant (heure de terminaison) [0..60] +
- +
-== Cinq problèmes : == +
- +
-- alignement des terminologies (afficher, montrer) ​  +
- +
-- introduction des composants intermédiaires (insertion de composants intermédiaires : recasteur, ...)  +
- +
-- gestion des signatures (par retroappel, ...) +
- +
-- deux niveaux de gestion des condition "​circonstancielles"​ (compléments circonstanciels) : niveau contexte  +
-ou membre gauche (trigger d'​action dans un AA)  +
- +
-- Problème de cohérence entre les états des composants à l'​initialisation (exemple plusieurs checkbox qui +
-attaque un light, si la checkbox est on et la light off, non seulement l'​initialisation aujourd'​hui ne gère pas la cohérence, mais en plus on ne sait pas si l'​état initial doit être On/On ou Off/Off) +
- +
- +
-1>  Alignement : +
- +
-Step 1  +
-Emric fonctionne avec une grammaire et des terminaux "​types"​ : exemple  +
-Audiosource , AudioSink dont il connait les méthodes types : +
- +
-Audiosource.setaudio +
- +
-Audiosink.getaudio  +
- +
-grâce à un "​terminal"​ comme écouter (mots clef action). +
- +
-Step 2  +
-Ensuite il fait une requête dans la BdC sur AudioSink.setaudio  +
-et AudioSource.getaudio pour récupérer les devices avec les méthodes ou events équivalents  +
- +
-Step 3  +
-Les metadonnées d'un devices devant fournir à la BdC les équivalences de ses méthodes et  +
-events en terme de méthodes et events "​types"​ pour préparer ces requêtes et les composants intermédiaires  +
-nécessaires à ces équivalences +
- +
-Attention :  +
- +
-- il faut que la BdC renvoie quand même un nom de "​famille"​ de devices telle GPS* ou par convention  +
-la BdC part du principe que tous les devices GPS* (ex. GPS1, GPS2) ont la même interface. Autre exemple, des pointcuts qui sont des "​ou"​ entre les devices possibles exemple Localisateur | GPS. +
- +
-ou +
- +
-- la partie pointcut matching fait appel à la BdC +
- +
-2> composants intermédiaires à rajouter ​ pour  rendre équivalentes des méthodes AudioSource.getaudio +
-avec des méthodes concrètes du service+
  
 +== Approche ==
 +Dans D4.1 et D4.2 : trois principes de meta-IHM : 
 +  * méthode utilisant un monde simulé
 +  * méthode graphique de liaison entre photos d'​objets de la maison
 +  * méthode en langage pseudo naturelle (avec guidelines pour des phrases syntaxiquement et sémantiquement correctes)
  
-3> retroappel : idem que 2> mais avec le retroappel+== Les travaux à mener identifiés == 
  
 +  * PB1 : définition de la grammaire du langage pseudo-naturelle
  
-4> gérer par redondance, si possible ​(ex. du disable)+  * PB2 : quelle(s) transformation(s) pour passer de phrases ​du langage aux différentes éléments de mise en oeuvre dans l'​architecture : 
 +     * Phrase et définition du contexte pour le déploiement d'un ensemble particulier d'AA 
 +     * Phrase et génération des AAs déployés dans ce contexte  
 +     * Phrase et requêtes à la BdC pour trouver des services et dispositifs qui correspondent aux terminaux de la phrase. L'​hypothèse dans ce cas étant que le langage pseudo-naturel s'​appuiera sur des services et dispositifs abstraits et que la BdC permettra la mise en correspondance des services et dispositifs concrets avec les services et  dispositifs abstraits (terminauxattendus. 
 +  * PB3 : possibilité d'​ajouter des metadonnées aux AAs disponibles et les intégrer ainsi dans la BdC pour pouvoir retrouver sur requête des AAs existants. ​
  
 +== Liste des TODOs du dernier meeting == 
  
 +Dans le cadre applicatif du scenario du fontainier (recherche de vanne + PDA / Casque)
  
-== TODOs == +  * Rainbow : Rajouter des metadonnées aux services et services pour dispositifs.
  
-Sur la base  ​du scenario du fontainier recherche ​de vanne + PDA / Casque+  * IIHM : Reprendre ​la grammaire ​du langage pseudo-naturel,​ définir le vocabulaire de base pour les actions et des noms terminaux de manière plus générale (type de device et méthodes et events) ​
  
 +  * Hadas : Spécifier les métadonnées dans les services et services pour dispositifs.
  
-Rainbow : Rajouter des metadonnées aux services et services pour dispositifs.+A priori aucun de ces TODOs n'a posé ou ne pose de difficulté
  
-IIHM Reprendre la grammaire du langage pseudo-naturel,​ définir le vocabulaire de base pour les actions  +== Méthodologie et travaux pour la suite ==
-et des noms terminaux de manière plus générale (type de device et méthodes et events) ​+
  
-Hadas : Spécifier ​les métadonnées ​dans les services ​et services pour dispositifs.+Parce que le problème de(s) transformation(s) du langage pseudo naturelle vers les éléments de la mise en œuvre, il nous faut dans un premier temps simplifier le langage utilisateur,​ proposer ​les principaux exemples de mise en œuvre ​et étudier ​ au cas par cas  les processus de transformation
  
 +  - Quelques phrases exemples
 +  - Etablir les conditions contextuelles qui en découlent
 +  - Etablir les AAs mis en oeuvre
 +  - Enumérer les terminaux (services et dispositifs abstraits attendus)
 +  - Enumérer quelques exemples de services et dispositifs réels et leur metadonnées
  
-Vers le second démonstrateur pour février .+Pour cela :
  
 +   * l'​équipe IIHM :
 +      * dépose sur le SVN la dernière grammaire du langage pseudo naturel
 +      * fournit une dizaine d'​exemple de phrases permettant d'​illustrer les possibilités du langage ​
 +      * fournit les aspects déjà générés (Cf. Emeric)
 +      * avance sur la grammaire du langage
 +   * l'​équipe HADAS : 
 +      * à partir du langage pseudo naturelle établir la liste des métadonnées attendues sur les dispositifs et l'​ontologie associée. ​
 +   * l'​équipe RAINBOW :
 +      * fournir la dernière grammaire des AAs (déposer sur le SVN) 
 +      * étudier le passage des phrases du langage pseudo naturel à la génération d'AAs et de conditions contextuelles pour leur application. ​
  
-== Prochaine Réunion ==+Un bilan et une mise en commun des réflexions seront faits lors du prochain meeting à Grenoble.
  
-Prévoir une plénière courant février (?) +== Prochains Meetings ==
  
 +  * Bilan prévu le Mercredi 2 Février à Grenoble sur les travaux LIG/I3S des prochains 15 jours 
 +  * Réunion plénière après les premiers tests d'​intégration des différents travaux des équipes : Cf. doodle (http://​www.doodle.com/​fyeh5vp5gbtnhka5)
 +      * OdJ :
 +      * Bilan sur les livrables et le planning
 +      * Bilan sur les premiers tests d'​intégration des démonstrateurs logiciels HADAS / IIHM / RAINBOW
 +      * avancées des travaux sur la sécurité avec MobileGov
 +      * avancées des travaux sur le dispositif GemAlto (et l'​ensemble des capteurs associés) ​
 +      * avancées sur les évaluations des interfaces par LudoTIC ​
 +      * Bilan sur la dissemination
 +      * ...
compte_rendu_14_janvier_2011.1295002299.txt.gz · Last modified: 2011/01/14 11:51 by tigli