This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
compte_rendu_02_fevrier_2011 [2011/02/02 10:39] lavirotte created |
compte_rendu_02_fevrier_2011 [2011/02/02 16:39] (current) lavirotte |
||
---|---|---|---|
Line 10: | Line 10: | ||
* Rappel sur l'architecture globale du projet | * 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. |