continuum

User Tools

Site Tools

Trace:
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 revisionPrevious revision
Next revision		Previous revision
compte_rendu_14_janvier_2011 [2011/01/14 11:04] – tiglicompte_rendu_14_janvier_2011 [2011/01/14 15:44] (current) – tigli
Line 1: Line 1:
-====  Meeting 29 novembre 2010 à Grenoble ====+====  Meeting 14 janvier 2011 par Visio====
  
 === Présents === === Présents ===
Line 23: Line 23:
 == 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)    * 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) 
  
-== Questions et discussions du meeting  == 
  
-= Questions = + 
 +== Questions   ==
  
   * Quel nouveau deadline pour les D3.2 et D3.3 d'HADAS ?   * 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
  
-= Faire le point = +==== Le point sur les travaux  en cours pour le second et dernier démonstrateur Weco ====
  
-== Démonstration par Emeric, reconnaissance langage naturel == +=== Les dernière évolutions de la meta IHM à partir du langage naturelle ===
  
-Voir D4.1 et D4.2 : deux principes de meta-IHM : +== 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 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)   * 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)  == +== Les travaux à mener identifiés == 
- +
-Exemple : Je veux ouvrir les volets quand il fait jour et quand il ne fait pas froid. +
- +
-Arbre : +
- +
-Pg :  +
- +
-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 +
- +
- +
-3> retroappel : idem que 2> mais avec le retroappel+
  
 +  * 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 (terminaux) attendus. 
 +  * 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.1295003080.txt.gz · Last modified: 2011/01/14 11:04 by tigli