User Tools

Site Tools


compte_rendu_14_janvier_2011

This is an old revision of the document!


Meeting 29 novembre 2010 à Grenoble

Présents

Rainbow : Hourdin, Lavirotte, Tigli, Rey

LIG : Coutaz, Jouanot, Fontaine, Anis

Ordre du jour

Quelques rappels sur nos deadlines
  • RETARD ::: Octobre 2010 : 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
  • Février 2011 : D2.32 :
  • Février 2011 : D3.4 :
  • Février 2011 : D4.3.2 :
  • Février 2011 : D5.1 :
  • Mai 2011 : D5.2.2 :
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)

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)

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

4> gérer par redondance, si possible (ex. du disable)

TODOs

Sur la base du scenario du fontainier recherche de vanne + PDA / Casque

Rainbow : Rajouter des metadonnées aux services et services pour dispositifs.

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.

Vers le second démonstrateur pour février .

Prochaine Réunion

Prévoir une plénière courant février (?)

compte_rendu_14_janvier_2011.1295002299.txt.gz · Last modified: 2011/01/14 11:51 by tigli