Date : 28 mars 2011

Adresse: Salle 318, Polytech'Nice Sophia Antipolis

Horaires : 15h30 - 17h

• Rainbow / I3S : Stéphane Lavirotte, Vincent Hourdin, Nicolas Ferry, Christophe Vergoni, Gaëtan Rey

Le but de cette réunion était de faire le point sur le Gestionnaire de Contextes (GdC) et ces interactions avec la Base de Connaissances (BdC).

• Problème des méta-données dynamiques dans l'infrastructure actuelle de Continuum
• Fonction et interaction de la BdC avec le reste de l'infrastructure
• Fonction et interaction du GdC avec le reste de l'infrastructure

L'objectif final étant de pouvoir répondre aux questions posés par Anis pour converger rapidement vers un prototype fonctionnel pour le démonstrateur industriel

La BdC interroge directement les dispositifs et prendre en charge elle même :

• l'apparition/disparition des services dispositifs pour mettre à jour sa propre base d'instance
• les MetaData des dispositifs via la méthode getMetaData(), au format défini précédemment, à savoir : une chaine de caractères (attribut/valeur) de la forme: name=value&name=value&name=value…
• les Données de certains services pour dispositifs. On pense qu'il n'est pas nécessaire de tous les prendre en compte sinon la BdC va crouler sous les données mais qu'il faudrait qu'elle utilise certaines de ces données pour illustrer les travaux d'hadas (inférences par exemple), cf Démo du prototype industriel.

1) est ce que la méthode update ne risque t elle pas de flooder le réseau si la bdc prend en compte les data du monde ?

2) Si la BdC forwards tous les évènements sans les utiliser cela n'a pas de sens. Le GdC peut aussi bien s'abonner à eux. L'idée d'origine (cf les réunions sur Grenoble d'il y a un an au moins) était que la BdC puisse souscrire seulement aux évènements utile en fonction des besoins du GdC. De plus, il ne faudrait pas un seul évènement mais un par contexte/prédicat, pour ne pas à avoir à réévaluer tous les prédicats (surcharge inutile sur le GdC et aussi de la BdC).

3) problème de la hiérarchie de classe : exemple a un instant t, on a dans la BdC la hiérarchie de classes suivante (elle est le résultat de diverses inférences) Véhicule→Voiture→Citroen→C2→(maC2), donc on retrouve potentiellement cette information dans les AA générés, mais on peut également en retrouver une version partielle comme par exemple Véhicule→Voiture→C2→(maC2). Cependant, dans le proxy du service on a Véhicule→Voiture→(maC2). Donc le matching des AA va poser problème. De plus, si on match uniquement sur l'instance, 1) les AA n'exploite pas leur potentiel, 2) on ne voit plus vraiment le travail de la BdC.

4) Comment peut on enrichir la BdC avec de nouvelles règles d'inférence ? (exemple: pour que le GdC ou plus logiquement le niveau stratégique puisse déployer de nouvelles règles d'inférence) Le format ? Anis, peux tu faire une interface UpNp pour cela ? peux tu écrire comme exemples les règles sur le scénario industriel (cf. ci-dessous) ? Comme cela, on pourra tous se baser la dessus.

Pour la démo du prototype industriel, on a retenu lors d'une plénière 3 situations (dans la voiture / extérieur avec les mains libre / extérieur les mains non libre). Donc on propose d'avoir simplement les 2 contextes suivants (les listes d'AA ne sont pour le moment pas défini, on travail dessus pour avoir les bons services avec Suez-env et LdE) :

Prédicat : est ce que bob est dans la voiture ? → règle d'inférence à déployer dans la BdC : utilisation de la position d'un dispositif mobile appartenant à bob pour déduire celle de bob

Prédicat : prédicat précédent + est ce que bob à les mains libres ? → règle d'inférence à déployer dans la BdC : information déduite de l'utilisation de la clé de vanne.

En gros, pour définir un contexte, on doit

• Définir les règles d'inférence (si celles-ci n'existent pas) pour que la BdC puisse calculer les prédicats du contexte (là, il faut qu'on voit le format qui va bien pour vous, normalement c'est emeric qui devrait générer cela, sinon faut les écrire à la main); Qui déploie ces règles ?
  • Le Gdc (les règles sont jointes aux contextes, mais pb des règles déjà déployées (est ce vraiment un pb pour la BdC si on déploie des règles déjà existantes)) ?
  • Le générateur de niveau stratégique (normalement lui il a une connaissance globale) ?
• Définir les prédicats (on a dit pour le moment qu'on se limite à de simples requêtes sparql avec des opérateurs logique entre les prédicats) : la BdC ne fait que répondre aux prédicats via la méthode query ?
• Définir les AAs et les attacher à chaque situation

Mais il faut aussi que

• La BdC puisse s'abonner aux bonnes informations (data des services pour dispositifs). Comment ?
• Le GdC s'abonne à la BdC de manière indépendante pour chaque contexte. 2 solutions
  • modification de l'interface Upnp de la BdC à chaque abonnement (une par contexte, et on fixe le nom de celle-ci)?
  • ajout d'un id aux évènements qui permet de connaitre le contexte qui change (inférence de données avec les règles associées au contexte id)

Gaëtan travaille sur un format pour la description du contexte en fonction des réponses aux éléments ci-dessus.