continuum

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====  Meeting 02 février 2011 à Grenoble ====

=== Présents ===

Rainbow :  Lavirotte, Rey

LIG :  Coutaz, Rousset, Jouanot, Fontaine, Anis

=== Ordre du jour  === 

  * Rappel sur l'architecture globale du projet
  * Réflexion sur la grammaire
  * méta-description des services
  * Impacte sur l'interconnexion avec la Base de Connaissance
  * Expérimentation
  * Planning et livraison

== Grammaire  ==

Concernant l'architecture, les impacts sont les suivants:
  * au niveau de la modélisation, nous avons un conteneur qui contient des proxy vers les différents éléments de l'infrastructure de continuum: BdC et GC forcément
  * Au niveau des pointcuts qui sont générés, soit nous avons: 
    * TV1|TV2|TV3: 
      * au niveau des instances qui sont générées par la Bdc en fonction des instances disponibles au moment de l'expression de l'utilisateur 
      * Ex: "Je veux connecter ce dispositif à la télévision dans le salon".
    * TV*|Miroir*|CadrePhoto*: 
      * au niveau des types qui ont été observables à un moment donné
      * Ex: "Je veux connecter ce dispositif à un observable"
    * SPARQL(displayable)
      * au niveau de la requête générique à évaluer au runtime
      * Ex: "Je veux connecter ce dispositif à un observable proche de moi"

Analyse de chacune des solutions:
 * Le solution 1 correspond à un script: on n'utilise les AA uniquement pour leur propriété de composition au runtime pour gérer les conflits entre les différentes règles qui s'appliquent.
 * La solution 2 exploitable la généricité des AA. Par contre, si la base de connaissance évolue (ajout d'information par incrément de l'ontologie), il est nécessaire de re-générer les points de coupes en fonction des nouvelles connaissances.
 * La solution 3 est complètement dynamique, mais ralenti l'évaluation. Non souhaitée non plus par HADAS. (supprime bien le lien entre AA et BdC qui posait problème dans l'architecture).

Par contre, il faut prévoir de conserver cette solution 3 dans la description des AA pour pouvoir faire une ré-évaluation quand la base de connaissance change (hors celle-ci est bien dynamique).

Étude du document travaillé par Jean-Yves pour la génération des AA à partir de la grammaire. Les conditions sont des conditions sur des observables qui sont issus du gestionnaire du contexte.

La méta-description des services pour être intégrer dans la Base de Connaissance:
  * Description syntaxique
  * Description sémantique pour la BdC (format à donner par HADAS)
  * Description end-user orientée pour la meta-IHM (format à donner par IIHM)

TODO:
  * HADAS et IIHM doivent fournir les formats attendus pour la meta-description des services pour que Rainbow intègre ces informations dans les services.