Connaissance du Contexte, Confidentialité et Accès Mobiles : une Approche Web Sémantique et Multi-agents Le travail que je vous présente aujourd’hui, je l’ai effectué pendant mon post-doc à l’Université de Carnegie Mellon. Je vais me focaliser sur un aspect de ce travail qui est la réconciliation de la mise à disposition de connaissances personnelles et contextuelles d’une part et le respect de la vie privée et de la confidentialité d’autre part. Fabien Gandon(1,2) - Norman Sadeh(1) (1)School of Computer Science - Carnegie Mellon University (2)Equipe ACACIA – INRIA Sophia Antipolis

Scénarii motivants & projet myCampus Informatique mobile, ubiquitaire, ambiante sources d’info multiples: agenda, infra. WiFi, etc. Collaborations entre organisations partage sélectif des infos: fournisseurs, délais, etc. Interface sémantique unifiée et sécurisée pour l’accès aux ressources privées e-Wallet Projet pilote: myCampus (Carnegie Mellon) Campus comme microcosme d’essai Assistance au quotidien par services accessibles sur réseau sans fil Services connaissant contexte + Respect vie privée Web sémantique & Services Web & Agents & WiFi Il y a deux grandes familles de scénarios motivants derrières ces travaux: Des scénarios essentiellement axés sur la mobilité et la connaissance du contexte où l’on utilise de multiples sources d’informations sur l’utilisateur et le contexte de son accès au système. Des scénarios de collaboration en particulier entre entreprises, avec des contraintes de partage sélectif des informations entre partenaires. Dans ces deux scénarios, le e-Wallet est un composant qui fournit une interface sémantique unifiée et sécurisée pour l’accès aux ressources privées des acteurs. (i.e. les ressources privées auxquelles ils veulent donner un accès contrôlé) Le principal projet de recherche est myCampus. On utilise le campus de Carnegie comme microcosme d’essai. Couvert par près de 700 bornes réseau sans fil c’est un environnement idéal pour tester l’utilisation au quotidien de dispositifs mobiles pour l’accès à des services en ligne. En particulier pour tester l’intégration de la connaissance du contexte lors du déroulement d’un service.

Contexte du projet et interactions myCampus: environnement conscient du contexte et visant à améliorer l’accès aux services pour la vie au quotidien sur le campus de Carnegie Mellon BBN, IBM, HP, Symbol, Boeing, Fujitsu, Amazon Air Force Research Laboratory Defense Advanced Research Project Agency (DARPA) Interactions with SONAT: notification & conscience utilisateur (D.o.D.) CoSAR (I-X, KAoS/CoABS Grid): notification (AIAI) SWAP: Semantic Web and Peer-to-peer (IST) AURA and III: Info. Ambiante et domotique (CMU)

Plan d’attaque Introduction (ou pourquoi il n’y a plus de moquette dans mon bureau) Scénarii motivants Projet myCampus Survol technique (si! si ! Il faut en parler un peu) Architecture globale de la plateforme multi-agents Architecture interne du e-Wallet Services : évaluations & retours (ou les vertus du crash test) Première maquette (v1) Étude en largeur: le démonstrateur (v2) Étude en profondeur d’un service

FIPA ACL messages and OWL Content JADE platform User Interaction Agent Directory Facilitator Agent (FIPA) Agent Management e-Wallet Manager Ontologist Task-Specific Agents pages jaunes & pages blanches Agent Annuaire bibliothèques d'outils d'interaction (http, smtp, etc.) Agent d'Interaction ontologies et faits du profil utilisateur, règles d'invocation de services et de confidentialité Agent e-Wallet moteur d'inférence, bibliothèques d'appel de services web et de sécurité Agents-Services Internet Web sémantique Services Web réseaux Utilisateur PDA L’architecture globale du système est une plateforme multi-agents autorisant la distribution des services et des ressources.

FIPA ACL messages and OWL Content Servlet behavior HTTP Request session behavior User Interaction Agent session HTTP Request session behavior FIPA ACL messages and OWL Content HTTP Request session Tomcat server Directory Facilitator Agent (FIPA) HTTP Request Agent Management Agent (FIPA) e-Wallet Manager Agent Une première famille d’agents gère la connectivité et les interactions avec les utilisateurs. En particulier, dans notre cas, elle permet aux Assistant Electroniques connectés au réseau sans fil d’interagir avec le système. Ontologist Agent Task-Specific Agents JADE platform

FIPA ACL messages and OWL Content HTTP Request User Interaction Agent FIPA ACL messages and OWL Content Type Service Owner … Yellow Pages Directory Facilitator Agent (FIPA) Name Address … Agent Management Agent (FIPA) White Pages e-Wallet Manager Agent Des agents hérités de la norme FIPA gèrent les pages jaunes et les pages blanches du système permettant en particulier aux utilisateurs de voir quels sont les services disponibles. Ontologist Agent Task-Specific Agents JADE platform

FIPA ACL messages and OWL Content HTTP Request User Interaction Agent FIPA ACL messages and OWL Content Directory Facilitator Agent (FIPA) Agent Management Agent (FIPA) e-Wallet Manager Agent Une famille d’agents gère les ontologies disponibles permettant aux autres agents de se procurer l’ontologie dont ils ont besoin et à l’administrateur de modifier les copies locales des ontologies. XSLT edition visualization Ontologist Agent download Ontologies Task-Specific Agents JADE platform

FIPA ACL messages and OWL Content User Interaction Agent FIPA ACL messages and OWL Content Directory Facilitator Agent (FIPA) Agent Management Agent (FIPA) XSLT OWL (ontologies, annotations) Rules (definitions, services, privacy) Queries e-Wallet Manager Agent JESS edition results Nous allons maintenant nous focaliser sur le dernier type d’agent présent dans le système: le e-Wallet qui fournit donc une interface sémantique unifiée et sécurisée pour l’accès aux ressources privées des utilisateurs. Ontologist Agent Task-Specific Agents JADE platform

Principe et fonctionnalités du e-Wallet Ici un e-Wallet par utilisateur Interface sémantique unifiée et sécurisée gérant… …connaissance statique; ex: nom, courriel …connaissance dynamique; ex: en conduisant… …services personnels/publics (services Web) connaissance fournie & règles d’invocation ex: agenda, localisation …préférences de confidentialité règles de contrôle d’accès; ex: mes collègues peuvent… règles de révision par… …abstraction ex: indiquer le bâtiment mais pas la salle …falsification ex: dire cafétéria quand dans salle coffres Dans les scénarios suivant il y a un e-Wallet par utilisateur. Le e-Wallet gère différents types de connaissances: Premièrement, la connaissance statique: par exemple le nom, l’adresse mail Deuxièmement, la connaissance dite dynamique: par exemple des préférences du style lorsque je conduit je ne veux pas recevoir de messages. C’est un premier type de règle; ce sont des règles de production Troisièmement, la connaissance des ressources personnelles ou publiques permettant d’obtenir des connaissances supplémentaires. Ce sont des règles à attachements procéduraux permettant par exemple d’interroger l’agenda de l’utilisateur lorsque l’on a besoin de connaissances sur ses activités. Le ressources sont disponibles sous forme de services Web. Enfin quatrièmement, les connaissances sur la confidentialité. Elles se divisent en deux types de règles: des règles d’accès (par exemple, mes collègues peuvent savoir où je suis sur le campus) et des règles de révision qui contrôlent le niveau de détail et d’exactitude des réponses données par le e-Wallet. La révision inclut donc l’abstraction (par exemple mes collègues peuvent connaître le bâtiment mais pas la salle exacte où je me trouve) et la falsification (lorsque je suis dans la salle des coffres, il est préférable de répondre que je suis à la cafétéria adjacente)

Implantation du e-Wallet Moteur XSLT & Feuilles de style de traduction Modèle triplets & OWL en CLIPS Règles & attachement procédural Règles en chaînage arrière Règle en chaînage arrière Règles en chaînage avant Faits en CLIPS Ontologies en CLIPS JESS Ontologies en OWL Humain Homme Femme désignation nom titre Descriptions en OWL Homme: #fgandon nom gandon localisation Bâtiment:SmithHall Règles en ROWL Humain:?x membre Groupe:?g Humain:?y collègue Services en WOWL Entité:?x position Lieu:?l ip ?ip_add Besoin: Connu: Appel: Service Web Localisation WiFi (ip_add) Confidentialité en SOWL *:#fgandon position Lieu:?l *:demandeur collègue Besoin: Test: Révision: Bâtiment Requête en QOWL Résultat en OWL Homme:#fgandon position Lieu:?l L’implantation repose sur XSLT (transformation du XML) et JESS pour les inférences. Dans les scénarios que nous regardons ici il y a 6 types d’entrées… Il y a en plus une description de RDF, RDFS et OWL Lite en CLIPS A chaque entrée est associée une transformation XSLT pour obtenir sa représentation en CLIPS… JESS est ensuite utilisé pour résoudre les requêtes Le chaînage arrière est simulé par la technique de réification des besoins. Les langages de règles sont équivalents à des clauses de Horns avec variables. Et les attachements procéduraux sont utilisées pour les règles nécessitant un appel à des extensions de JESS ou des Services externes tels que les services Web enveloppant des ressources personnelles (ex: agenda pocket outlook) Chaînage avant & arrière (réification besoins) Clauses de Horns avec variables Attachement procédural (extensions, services Web)

FIPA ACL messages and OWL Content HTTP Request User Interaction Agent FIPA ACL messages and OWL Content Directory Facilitator Agent (FIPA) Agent Management Agent (FIPA) e-Wallet Manager Agent Ontologist Agent Task-Specific Agents JADE platform

Avancement Introduction Survol technique Web sémantique, Web services & Connaissance du contexte Scénarii motivants & Projet myCampus Survol technique Architecture globale de la plateforme multi-agents Architecture interne du e-Wallet Services : évaluations & retours Première maquette (v1) Étude en largeur: le démonstrateur (v2) Étude en profondeur d’un service

FIPA ACL messages and OWL Content HTTP Request User Interaction Agent FIPA ACL messages and OWL Content Directory Facilitator Agent (FIPA) Agent Management Agent (FIPA) e-Wallet Manager Agent Enfin il y a une famille ouverte d’agents qui proposent des services aux utilisateurs. Ces agents peuvent être ajoutés et supprimés à chaud du système. Il utilisent le contexte et le connaissances disponibles sur les utilisateurs pour remplir leur tâche. Ontologist Agent Task-Specific Agents JADE platform

Crash Tests avec Concierge et Messager Concierge: suggérer où prendre son repas Préférences culinaires, endroit, temps qu'il fait E-Wallet, localisation par WiFi, service Web météo, UDDI pour liste reastaurants Liste ordonnée de restaurants Log = contexte + résultat + choix Messager: filtrer messages / intérêt & disponibilité Centres d'intérêt, activité courante / disponibilité E-Wallet, service Web d’accès à Pocket Outlook Filtrer, retarder et router les messages Log = contexte + décision + feedback

Préférences pour le Concierge et le Messager login préférences

Utilisation du Concierge et du Messager Feedback

Crash Tests et Extraits de la base de Log Test début 2003 sur campus Carnegie Mellon 3 jours, 11 utilisa., formation, logs 24/24, entretiens Ex: pour routage, contexte nécessaire ds 70% cas

Développement et validation de v2 Etude en largeur démonstrateur e-Wallet & plateforme Gestion à chaud des services: Fonctionnalités de base du e-Wallet Service météo & Cinéma (contexte, inférences & services web) Fonctionnalités de confidentialité Service de cartographie (Révision par abstraction) Scénario multi-e-Wallets Service de réunion Scénario informatique ambiante Service de présentation PowerPoint En // étude en profondeur d’1 service

Étude en profondeur d’un service S’informer des événements Facile à filtrer visuellement, pair à pair, situé + Difficile à noter, produire, distribuer, maintenir - Service de posters virtuels Messages virtuellmnt situés Parcours de l'utilisateur comme définition de filtres Collecter posters (caddie) Publicité a priori / par anticipation  Spécifications et maquettes Cycle itératif sur les prototypes How can we get more relevant information to the people who want it?

Cycle itératif (cas des interfaces) Cheminement Cognitif Observations 4 users – Task-based Walkthrough Strengths: Interest in the idea Interface was usable Weaknesses: Poster manipulation was hard to grasp Categories weren’t specific enough More/different info needed in posters

DONE Plan d’attaque Introduction Survol technique Web sémantique, Web services & Connaissance du contexte Scénarii motivants & Projet myCampus Survol technique Architecture globale de la plateforme multi-agents Architecture interne du e-Wallet Services : évaluations & retours Première maquette (v1) Étude en largeur: le démonstrateur (v2) Étude en profondeur d’un service DONE

Conclusion et discussions (I) Accès connaissances personnelles & contextuelles Mécanismes confidentialité au niveau sémantique Intégration dynamique : Ressources contextuelles pub/priv (services Web) Services proposés par agents Modèles (langages WS + ontologies) Tests et retours d’expérience: Logs, questionnaires, entretiens, observations Plus d’intelligence & de connaissances sur utilisateur & contexte (profil, passé,...)  extensibilité Réduire charge cognitive & intrusions (niche énorme composition & conscience contexte) L’idée principale était de réconcilier le respect de la vie privée avec la contextualisation des services dans un système ouvert. La première version de myCampus a été testée début 2003 avec pour objectif de valider le concept d’une plateforme de support aux accès mobiles à des services du Campus en ligne… La deuxième version démontrée fin 2003 a chercher à illustrer différents scénarios d’utilisation du e-Wallet…

Conclusion et discussions (II) Tests et retours d’expérience (suite): Tension: Interfaces dédiées - Interfaces génériques (intégration dynamique interfaces, widgets dédiés) Explication & visibilité résultats / comportements A venir… Développement services de sécurité (ex: crypto) E-Wallet: répercussions révisions, cohérence, etc. Réconcilier expressivité & ergonomie (générique/ad hoc, apprentissage) Passage à l’échelle et application réelle (Scénario Musée / III) Tester intégration capacités d’intégration (AURA & myCampus) L’idée principale était de réconcilier le respect de la vie privée avec la contextualisation des services dans un système ouvert. La première version de myCampus a été testée début 2003 avec pour objectif de valider le concept d’une plateforme de support aux accès mobiles à des services du Campus en ligne… La deuxième version démontrée fin 2003 a chercher à illustrer différents scénarios d’utilisation du e-Wallet…

Questions-réponses Source:http://www.firstmonday.org/issues/issue4_9/odlyzko/index.html