resume_des_echanges_pleniere_continuum_15_mars_2011
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
|
resume_des_echanges_pleniere_continuum_15_mars_2011 [2011/03/15 11:54] tigli [Exposé I3S Prototype pour l'évaluation V2 (final) :] |
resume_des_echanges_pleniere_continuum_15_mars_2011 [2011/03/15 17:09] tigli |
||
|---|---|---|---|
| Line 2: | Line 2: | ||
| ===== Modification du Bilan : ===== | ===== Modification du Bilan : ===== | ||
| - | * Cf. les étoiles dans la présentation bilan corrigée (sur SVN) | + | * Cf. les étoiles dans la présentation bilan corrigée (sur SVN et dans page précédente) |
| ===== Exposé LudoTIC : ===== | ===== Exposé LudoTIC : ===== | ||
| Line 39: | Line 39: | ||
| * TODO :: associer un rapport papier D5.1 pour mettre en avant une contribution innovante (scientifique?) (sur la base du document de demande de dépôt de brevet) | * TODO :: associer un rapport papier D5.1 pour mettre en avant une contribution innovante (scientifique?) (sur la base du document de demande de dépôt de brevet) | ||
| * TODO :: prototype Clef en collaboration avec Suez Environnement et Lyonnaise des eaux | * TODO :: prototype Clef en collaboration avec Suez Environnement et Lyonnaise des eaux | ||
| + | |||
| + | PERSPECTIVES par rapport aux remarques de l'ANR : | ||
| + | * rajouter au mécanisme de RPC propriétaire (TUBE) une gestion de contrat dynamique (à la UPnP) qui pourrait être un plus brevetable (?) | ||
| + | * le service UPnP associé pourrait alors récupérer tout aussi dynamiquement le contrat du device | ||
| ===== Exposé I3S Prototype pour l'évaluation V2 (final) : ===== | ===== Exposé I3S Prototype pour l'évaluation V2 (final) : ===== | ||
| - | * TODO ::: Clef de vanne | + | Résumé des TODOs : |
| + | * TODO ::: réaliser le Dispositif Clef de vanne intégrant l'équipement GemAlto | ||
| * TODO ::: Partie haute (au-dessus des AAs) de l'architecture | * TODO ::: Partie haute (au-dessus des AAs) de l'architecture | ||
| - | * TODO ::: BdC | + | * TODO ::: intégration complète de la BdC |
| - | * TODO ::: Meta IHM | + | * TODO ::: intégration complète de la Meta IHM |
| - | * TODO ::: intégration de contexte | + | * TODO ::: intégration complète du gestionnaire de contexte |
| + | * TODO ::: fournir les Web Services Métier au format UPnP ou WS (W3C) | ||
| + | * TODO ::: intégration du Sécurité de LoginPeople | ||
| - | * TODO ::: Web Services Métier | + | Planning intermédiaire : |
| + | |||
| + | * Gemalto Fev : Dispositif GemAlto : Mars 2011 | ||
| + | * LoginPeople : Service Sécurité : (pas de deadline fixé par le document A : plutôt Avril 2011) | ||
| + | * Suez Env : Services Métiers - Avril 2011 | ||
| + | * I3S - IIHM - HADAS : Architecture Soft au dessus Juin 2011 | ||
| + | |||
| + | Attention : Prototype v2 pour la deuxième phase d'évaluation de LudoTIC (évaluation terrain) | ||
| + | TODO :: Identifier les spécifications du prototype et réaliser le prototype pour mi-avril (version V1 bis) | ||
| - | * TODO ::: Sécurité | ||
| ===== Pause Repas : ===== | ===== Pause Repas : ===== | ||
| + | 12h30 - 14h | ||
| + | |||
| + | ===== Exposé 5 : prototype architecture V0 ===== | ||
| + | * Avancée du démonstrateur D4.3.2 IIHM (Emeric) | ||
| + | * <observable (device source)> LINK <device sink> | ||
| + | * LINK est influencé par l'action considérer (ex. écouter ou voir) en sélectionnant des catégories de devices source et devices sink reliés (LINK) | ||
| + | * Cas (2) non abordé : | ||
| + | * Quand l'action (ex. écouter) joue entre un device source destiné a priori à un device sink de différente catégorie (ex. ObservablePosition ->(écouter) -> DeviceAudio) | ||
| + | * La génération de l'AA est alors moins triviale (plus Observable.port -> DeviceSink.port) | ||
| + | * PERSPECTIVE ::: Proposition de mise en place de toute une partie simulée en complément de la meta-ihm (en LPN, ou inconique), donc simulation du GdC et d'un environnement (infrastructure simulée) seconde life. | ||
| + | * Evolution liée de la BdC HADAS (Anis) | ||
| + | * TODO :: BdC à la capacité d'enrichir les meta-données des dispositifs (ex. localisation dans une chambre est équivalent à la localisation dans la maison) | ||
| + | * TODO :: La BdC est capable de détecter un changement de contexte, le transmet au GdC qui sélectionne les AAs souhaités. | ||
| + | |||
| + | * Evolution liée de WComp (meta-données et AA) Rainbow (Vincent) | ||
| + | * TODO ::: Suite à la remarque d'Anis, le nom est une meta-donnée, on a donc plus qu'une liste de meta-données, il faut donc tolérer des filtres basés sur des expressions régulières sur cahqe meta-données + des opérateurs logiques entre. | ||
| + | * TODO ::: rajouter les stratégies de sélection des jointputs (n parmi n, 1 parmi nb , ...) | ||
| + | |||
| + | TODO :: rajouter à l'interface le What (Device Source ou observable), l'action et le Where (Device Sink) | ||
| + | TODO :: doit-on et comment faire évoluer le traitement pour atteindre des cas 2 | ||
| + | |||
| + | ===== Exposé 6 AA et gestion du contexte dans le respect des 3 couches à partir de la grammaire du langage pseudo naturel (JY-Gaëtan) ===== | ||
| + | |||
| + | TODO :: Clore le débat sur le GdC :un contexte est associé à un ensemble de prédicats , le nombre de noeuds (situations) correspond au nombre d'états possibles de l'ensemble des prédicats. Chaque situation est associée à une liste d'AA. | ||
| + | |||
| + | TODO :: Faire le travail du LPN vers la liste des prédicats en passant par la BdC (à préparer en équipe Rainbow) | ||
| + | |||
| + | TODO :: Corriger le papier AA structurel et AA Comportemental et envoyer à Grenoble | ||
| + | |||
| + | ===== Exposé 7 : BdC ===== | ||
| + | |||
| + | * BdC connecté au niveau stratégique pour aligner les observables / device sink abstrait aux concrets | ||
| + | * TODO :: BdC qui récupère les meta-data dynamiques des Devices (OK) | ||
| + | * Enrichissement des metadonnées des devices par la BdC : NON (on subit l'infrastructure) | ||
| + | * TODO :: relation BdC / niveau LPN (OK pour l'action, à faire pour la partie Contexte (matching condition contextuelle LPN vers prédicats) ... Cf. travaux futurs) | ||
| + | * Générer pointcut (après alignement) OK ? | ||
| + | * TODO :: relation BdC / GdC | ||
| + | |||
| + | TODO ::: Echanges de mails pour clarifier les échanges BdC et reste de l'architecture | ||
| + | |||
| + | ===== Suggestions ===== | ||
| + | |||
| + | * Publications et Workshops : | ||
| + | * Workshop à IHM 2011 pour Continuum (Conférence du Lundi 24 octobre 2011 - Jeudi 27 octobre 2011) | ||
| + | * a voir dans le cadre des Interactions Homme/Machine | ||
| + | * Publications sur quoi, où et quand (?) : | ||
| + | |||
| + | * Pour Jacques quels sont les retours à faire à l'ANR : Projets trop courts - trop peu d'infos retournées par l'ANR en cas de refus. | ||
| + | |||
| + | * Ne pas oublier Demande de prolongement du projet sans incidence financière (Quand la déclencher ? 6 mois ? 12 mois ?) | ||
| + | |||
| + | * Ne pas oublier les rapports financiers à T0+24 | ||
| + | |||
| + | * TODO ::: Incrémenter les papiers qui tournent (rapport Emeric-Anis-Vincent-Joelle) | ||
| + | |||
| + | ===== Discussions : Deux groupes de travail ===== | ||
| + | |||
| + | ==== LudoTIC - I3S - Suez Environnement - Lyonnaise des eaux : ==== | ||
| + | |||
| + | TODO ::: Fixer une date : doodle de Stéphane | ||
| + | |||
| + | ==== I3S - IIHM - HADAS : Architecture Continuum ==== | ||
| + | |||
| + | TODO ::: Fixer une date : | ||
| + | |||
| + | ==== I3S - LoginPeople ==== | ||
| + | TODO ::: Fixer une date | ||
| + | Use Cases à partir desquels on a la liste des devices à mettre en œuvre | ||
resume_des_echanges_pleniere_continuum_15_mars_2011.txt · Last modified: 2011/03/15 17:42 by rey
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
