compte_rendu_02_fevrier_2011
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
compte_rendu_02_fevrier_2011 [2011/02/02 13:56] lavirotte |
compte_rendu_02_fevrier_2011 [2011/02/02 16:39] (current) lavirotte |
||
|---|---|---|---|
| Line 16: | Line 16: | ||
| * Planning et livraison | * 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. | ||
compte_rendu_02_fevrier_2011.1296651380.txt.gz · Last modified: 2011/02/02 13:56 by lavirotte
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
