This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
agenda_des_journees_continuum_du_6_avril_au_9_janvier_2010 [2010/04/09 10:48] tigli |
agenda_des_journees_continuum_du_6_avril_au_9_janvier_2010 [2010/04/12 10:57] |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Agenda des journées CONTINUUM du 6 au 9 avril 2010 ====== | ||
- | |||
- | Présents : | ||
- | * L'I3S sera représenté par G. Rey et JY Tigli. | ||
- | * IIHM LIG, Joelle Coutaz et Emric Fontaine | ||
- | * HADAS LIG, Fabrice Jouanot, Yanis, Marie-Christine Rousset | ||
- | |||
- | ===== Mardi 6 avril 14h30 - 18h ===== | ||
- | |||
- | Bilan des sujets à aborder : | ||
- | * Interface WComp / Ethylen, ou connecter la démo du photoshufler à WComp | ||
- | * Interface travaux HADAS avec la plateforme CONTINUUM / WComp | ||
- | * Annexe : discussion avec IIHM sur les investissements mi-lourds CNRS à mettre en cohérence entre Nice et Grenoble | ||
- | * Reprendre la modélisation du contexte dans les scenarii prospectifs et industriels | ||
- | * Annexe : Modalités de l'évaluation à mi parcours | ||
- | |||
- | |||
- | ===== Mercredi 7 avril 9h30 - 18h ===== | ||
- | |||
- | == Base de données HADAS == | ||
- | |||
- | |||
- | Proto permettant de représenter et raisonner sur le contexte. | ||
- | Vous le trouverez à l'adresse http://conquer.liglab.fr/ | ||
- | |||
- | Nous n'avons défini que 2 comptes pour que vous puissiez manipuler (modifier et interroger) les données du contexte. | ||
- | |||
- | joelle.coutaz@imag.fr pass: <nom_du_projet>/etch | ||
- | |||
- | tigli@polytech.unice.fr pass: <nom_du_projet>/buzz | ||
- | |||
- | |||
- | == Architecture Implémentatoire Continuum == | ||
- | |||
- | Cf. Schéma général implémentatoire | ||
- | |||
- | ===== Jeudi 8 avril 9h30 - 18h ===== | ||
- | |||
- | == Matin : Meta-UI == | ||
- | |||
- | Trois Meta_UI : | ||
- | * pour Contexte Manager, | ||
- | |||
- | |||
- | * pour Base de connaissance, | ||
- | |||
- | * A l'initiative du User | ||
- | * Pour l'observabilité | ||
- | * Pour la prédictabilité | ||
- | |||
- | * pour Tisseur d'AA | ||
- | |||
- | Cf. Schéma de Gaetan | ||
- | |||
- | |||
- | == Après-midi : Accès à la BdC == | ||
- | |||
- | BdC représentée par des triplets : Objet / relation / Objet | ||
- | Les Objet peuvent être des Types, des instances ... | ||
- | |||
- | ex. | ||
- | |||
- | (aTV2, Type, TV) | ||
- | |||
- | (aTV2, Where, Bedroom) | ||
- | |||
- | ceci peut s'exprimer sous forme de prédicat ; | ||
- | |||
- | Where(aTV2, Bedroom) | ||
- | |||
- | format : RDFS | ||
- | |||
- | Langage de requête : SPARQL | ||
- | |||
- | ex. | ||
- | |||
- | SELECT ?x | ||
- | WHERE { | ||
- | ?x type TV | ||
- | } | ||
- | |||
- | retour : | ||
- | |||
- | <result> | ||
- | <res> aTv </res> | ||
- | <res> aTv2 </res> | ||
- | </result> | ||
- | |||
- | autre requete SPARQL : | ||
- | |||
- | SELECT ?x | ||
- | WHERE{ | ||
- | ?x type Device | ||
- | ?x offers ?y | ||
- | ?y type Alert | ||
- | } | ||
- | |||
- | |||
- | Par contre SPARQL ne permet que des requêtes et non des INSERT .... | ||
- | Il faut étendre le langage. | ||
- | |||
- | Par contre SPARQL est limité à RDF ce qui oblige à saturer le graphe RDF à partir de RDFS pour utiliser | ||
- | SPARQL (inférer les relations qui n'apparaissent pas dans RDF, déductible de RDFS) | ||
- | |||
- | Les autres commandes CONSTRUCT ... | ||
- | |||
- | Aujourd'hui la BdC est accessible au travers un Web Service : | ||
- | |||
- | add_class() | ||
- | find(s,o,p); | ||
- | add_instance() | ||
- | ... | ||
- | |||
- | |||
- | TODO ::: Hadas | ||
- | |||
- | * La BdC devient un service UPnP | ||
- | * Interface de la BdC en entrée : les méthodes : add(), update(), query(); delete() | ||
- | * Interface de la BdC en sortie : émission d'événement (string) (chaine de caractère pour compléter l'info sur l'event) | ||
- | |||
- | TODO ::: Rainbow | ||
- | |||
- | * Modifier UPnP Wizard designer pour envoi de add()/delete() vers la base ... (apparition / disparition de device) | ||
- | * Créer le container qui va rafraichir la base (update() ) fonction des events envoyer par les devices de l'infrastructure (il faudra probablement créer des AAs pour connecter le WSD BdC et ces WSD de ces nouvaux devices) | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | ===== Vendredi 9 avril 9h30 - 12h ===== | ||
- | |||
- | Réunion avec Emric : | ||
- | TODO : Faire les Devices UPnP sur table, PC (display), Téléphone pour la démonstration Photoshuffler. | ||
- | |||
- | |||
- | TEST OK : | ||
- | |||
- | * Serveur UPnP sur Table émulée sur PC (implémentation méthode + event) OK | ||
- | * Serveur UPnP sur Table réelle (implémentation méthode + event) : quelques problèmes de sensibilité et fréquence de rafraichissement de la table. Les events sont néanmoins reçus par le devicespy. | ||
- | * Serveur UPnP sur Table réelle testée depuis WComp OK | ||
- | |||