PERSONNALISER DES DOCUMENTS EN COMPOSANT DES SERVICES Claude Moulin 1, Sylvain Giroux 2, Raffaella Sanna 1, Alessandro Soro 1 1 CRS4 - Center for Advanced Studies, Research and Development in Sardinia, VI Strada Ovest, Z.I. Macchiareddu, Uta (CA), Italy moulin@crs4.it 2 Dept. of Mathematics and Computer Science, University of Sherbrooke, Sherbrooke, Canada, sylvain.giroux@dmi.usherb.ca Résumé : Notre recherche concerne l élaboration d une information personnalisée utilisant en particulier des données géo-référencées. Des documents sont créés par la collaboration de services distribués remplissant chacun un rôle bien défini, telle la gestion du profil de l utilisateur ou la fourniture d événements culturels relatifs à une position géographique. Notre solution est basée sur une forte interopérabilité entre services. Nous avons pour cela construit une ontologie qui permet aux services de parler la même langue et des outils qui leur permettent d exporter des données sous une forme RDF compatible avec l ontologie et ainsi compréhensible par tous. De plus, des règles d inférence permettent de filtrer les données et ainsi d accentuer la personnalisation. Nous illustrons notre propos en donnant l exemple de la construction d une documentation associée à un voyage. Mots-Clé : documents personnalisés, ontologie, services collaboratifs, RDF 1 Introduction Nous utilisons l architecture développée dans le cadre du projet e-mate 1 [2] [3] afin d étudier la phase de composition d un document virtuel. L architecture permet de déployer et de faire coopérer des services multi-modaux en ligne. Par multi-modal, nous entendons que le même service est accessible à partir d un ordinateur, d un assistant personnel, d un téléphone cellulaire, etc. Les objectifs du projet sont très proches des problèmes que mettent en exergue les recherches du Semantic Web [1] à savoir le fait de disposer sur le Web de données sous une forme exploitable par des applications et ainsi pas uniquement présentées sur un écran. Nous présentons dans cet article les caractéristiques d une solution permettant d obtenir une information personnalisée. Elle est basée sur l intégration de services de base. Ces services sont indépendants les uns des autres et destinés simplement à fournir une information sans connaissance du service destinataire. La solution inclut également la conception d un scénario dépendant du type d information désiré, qui se traduira par l élaboration d un service dit composite intégrant les services de base. Le modèle de service e-mate inclut des meta-données permettant de rechercher des 1. E-MATE signifie Architecture Multi-modale pour Environnement Télématique. Le projet e-mate se termine en juin 2002 et aura duré deux ans. http://www.crs4.it/nda/e-mate/
services dans un portail à l exclusion de toute autre information, une description de l interface utilisateur indépendante de toute modalité d accès et une description des entrées sorties permettant une intégration dynamique des services. Utilisant le modèle de l utilisateur, le service composite fournit une information adaptée à ses préférences et au contexte, et la construction de l interface proprement dite qui est prise en charge par l architecture elle-même prend en compte également le dispositif utilisé. L article présente à titre d exemple un planificateur de voyage. Ce service composite communique entre autres avec le service de personnalisation et avec des services spécifiques qui délivrent des descriptions d événements culturels et d horaires de vols, en vue de proposer un voyage à un touriste et sa documentation circonstanciée. Nous présentons également les caractéristiques du système que l implémentation de la chaîne de communication complète met en évidence. Il s agit principalement de la nécessité d une ontologie commune et partagée par l ensemble des services et de la présence de ponts entre les objets d un langage de programmation usuel tel Java et cette ontologie qui assurent l interopérabilité des services. 2 Le Scénario t-mate L assistant de voyage (t-mate) donne un exemple de planification d un voyage et de toutes ses phases, de la réservation des vols jusqu à la construction de l itinéraire du touriste et de l insertion dans son agenda des événements culturels qui pourraient l intéresser. Il est implémenté en composant un certain nombre de services et le profil utilisateur recueille les éléments clés requis pour apparier et sélectionner l information pertinente pour l utilisateur, basée sur son age, son sexe, ses préférences... Les services impliqués dans ce scénario sont : Un service d information sur les transports : il fournit une liste de dates de départ et d arrivée d avions ainsi que les villes concernées ; un service de recueil d événements culturels : pour un jour et une ville donnés, il fournit une liste d événements culturels ou sociaux (tels que cinéma, théâtre, sport... ) ; un agenda personnel : il conserve les rendez-vous de l utilisateur et lui envoie les courriels ou les messages SMS appropriés ; un service de personnalisation: il ordonne une liste d éléments (films, restaurants, musées... ) en fonction des préférences de l utilisateur ; un service de planification : il utilise l information sur les transports (service 1) pour réserver les billets et sauvegarder l heure de départ dans l agenda de l utilisateur (service 3). Il répertorie également les événements culturels disponibles (service 2) de façon à placer dans l agenda ceux qui correspondent au voyage et au profil de l utilisateur, en tenant compte évidemment des rendez-vous déjà pris. Il requiert enfin le profil utilisateur (service 4) pour filtrer l information et signale les événements qui correspondent au mieux aux préférences de l utilisateur. L implémentation et la composition de ces services soulève deux problèmes principaux. Tout d abord les services doivent être strictement découplés tant du point de vue du code que de l implémentation des types de données et ils doivent être malgré cela entre de manière pertinente dans une composition. En effet, un même service peut
entrer dans la composition de plusieurs scenarii. Ensuite l information doit être filtrée selon les préférences et les besoins de l utilisateur. La résolution de ces deux problèmes conduit notamment à élaborer une ontologie commune à l ensemble des services. En d autres termes, les services doivent accéder à une représentation partagée des concepts de façon à pouvoir communiquer pleinement. La personnalisation peut alors être accomplie d une part en filtrant l information disponible et d autre part en collectant les choix de l utilisateur lors de la fréquentation de la plate-forme. 3 Ontologie du Domaine Comme indiqué dans [10], les ontologies peuvent être utilisées pour résoudre trois types de problèmes : la communication entre les personnes, l interopérabilité entre les systèmes et l ingénierie des systèmes. Ceci reflète tout à fait la manière avec laquelle le contexte e-mate utilise les ontologies. L auteur d un scénario définit ou utilise une ontologie d un domaine (dans l exemple t-mate, celui des voyages et des loisirs) et l ajoute à l ontologie d e-mate qui définit les concepts généraux utilisés pour le profil de service ou celui de l utilisateur. Il est également nécessaire de représenter les concepts de la programmation orientée objet par des concepts ontologiques. Ceci est simplifié par des facilités de traduction que fournit l architecture e-mate. 3.1 Une Ontologie dans le Domaine des Voyages et des Loisirs Dans cette section nous utilisons des fragments d une ontologie du domaine des voyages et des loisirs que nous avons construite, pour illustrer les concepts ontologiques, les prédicats et les instances. Les lignes suivantes en montrent un extrait écrit dans le langage F-Logic [4] 1 : /* schema declaration */ monument::attraction. 2 museum::attraction. attraction::location. location[name=>>string; 3 issituatedin=>location]. trip[from=>>location; to=>>location; attractions=>>attraction]. preference[hasobjetc=>>resource; hasvalue=>>integer]. /* instances */ paris:location. 4 toureiffel:monument[name->>"tour Eiffel"; 5 issituatedin->>paris]. louvre:museum[name->>"musee du Louvre"; issituatedin->>paris]. 3.2 Transformation d Objets en Instances d Ontologie L infrastructure e-mate fournit des outils qui aident à résoudre les problèmes d interopérabilité, plus précisément la communication entre services en appariant objets et concepts ontologiques. Un parser vérifie la compatibilité sémantique et exécute les traductions nécessaires. Les services définissent indépendamment leur propres structures de données selon leurs besoins internes. Ils doivent fournir un document de mapping que 1. Les fichiers complets ont été générés avec OntoEdit [8]. 2. monument::attraction indique que monument est un sous-concept de attraction. 3. name est un prédicat ayant pour domaine location et image string. 4. paris est une instance du concept location. 5. La propriété name a pour l instance toureiffel la valeur "Tour Eiffel".
le parser e-mate utilisera pour construire dynamiquement une représentation RDF de ces données. Réciproquement, ce document de mapping est aussi utilisé pour construire des objets à partir d une représentations RDF. Par exemple le concept ontologique trip : trip::rankme[to=>location; from=>location; attractions=>>attraction]. peut être associée à la classe Java Trip : public class Trip implements Rankme { private Location from, to; private Attraction[] attractions; /* accessors omitted */ } 4 Personnalisation 4.1 Profil Utilisateur Le profil utilisateur est construit en utilisant deux sources d information principales. Au départ l utilisateur fixe quelques paramètres comme l âge, le sexe. Ensuite les services mettent à jour eux-mêmes d autres paramètres comme ses préférences, en modifiant par exemple des taux de fréquentation associés à certaines instances de concepts. Le service de personnalisation peut exporter le profil de l utilisateur dans un document écrit en RDFS. Celui-ci peut ainsi être ajouté à l ontologie et être l objet d inférences. Dans le profil utilisateur, il est possible d étendre l ontologie du domaine avec des déclarations et des définitions d instances de concepts que l ontologie ne contient pas elle-même. Par exemple, il est possible de déclarer de nouveaux monuments de Paris dans le profil utilisateur : notredame:monument[name->>"notre Dame"; issituatedin->>paris]. trocadero:monument[name->>"trocadero"; issituatedin->>paris]. Le profil utilisateur peut ensuite utiliser à la fois l ontologie commune et ses extensions pour spécifier les préférences de l utilisateur : p1:preference[hasobject->>{museum, trocadero}; hasvalue->>5]. p2:preference[hasobject->>notredame; hasvalue->>8]. p3:preference[hasobject->>{louvre, toureiffel}; hasvalue->>6]. La première ligne de l exemple précédent signifie que la préférence p1 a un niveau d intérêt de 5 et concerne à la fois le concept museum et l instance trocadero. La personnalisation peut utiliser les préférences rangées dans l ordre p2, p3 et p1 pour des comparaisons futures et pour des réservations. 4.2 Inférences basées sur le Profil Utilisateur Tandis qu il est généralement possible d exprimer dans un langage de représentation de connaissances, la structure d une hiérarchie de classes décrite dans un langage de programmation à objets usuel, le contraire n est pas nécessairement vrai. Des individus instances de plusieurs concepts, des taxonomies de propriétés particulières, des définitions
intensionnelles de concepts sont des exemples de modélisation puissants très difficiles voire impossibles à exprimer en programmation orientée objet. Cependant, les besoins requis par nos objectifs de recherche restreignent suffisamment l utilisation ontologique pour rendre possible cette double représentation. Le regroupement sous une forme commune, comme RDF(S), d éléments venant de sources différentes (ontologie du domaine, profil utilisateur et transformation de données) forme une base de faits sur laquelle le service de personnalisation peut inférer (pour l instant, en utilisant la logique du premier ordre). Pour ceci, quelques règles de base et des axiomes sont implémentés au niveau du système. Ainsi, toute propriété transitive génère les faits résultants non présents dans la base mais qui doivent absolument être pris en compte. La requête suivante montre l usage d une règle permettant de filtrer les faits selon les préférences de l utilisateur. FORALL Offer,Pref,Rank,Obj <- Offer:rankme AND Pref:preference AND Pref[hasObject->>Obj] AND EXISTS O match(offer,obj,o) AND Pref[hasValue->>Rank]. Cette règle recherche les préférences concordant avec une offre (de voyage) particulière et fait apparaître également le niveau de concordance associé ainsi que l objet associé : Offer = trip1 Pref = p1 Rank = 6.0 Obj = toureiffel 4.3 Création de Documents Virtuels Les règles d inférence proposent un certain nombre de résultats qui sont par exemple des offres de voyage. Ses offres sont soumises à l utilisateur qui en général en accepte une. L offre choisie est accompagnée de caractéristiques touristiques qui peuvent être des visites de musées, des propositions de restaurants, de spectacles, etc. Le planificateur peut ainsi s adresser aux services concernés pour obtenir une information qu il transformera en fragments de documents et élaborer ensuite une documentation circonstanciée du voyage accepté par le touriste : description des œuvres principales d un musée, critiques d un film, éléments historiques expliquant un monument, etc. Les services de l infrastructure e-mate étant multi-modaux cette documentation de voyage est accessible à partir de divers dispositifs comme un ordinateur de bureau ou bien un assistant personnel. Elle est disponible en plusieurs formats dont le langage HTML. Elle est également disponible en divers endroits et en particulier lors du voyage lui-même sur les sites intéressants. 5 Conclusion et Travaux Futurs Dans cet article nous avons essayé de répondre au problème de la composition d un document personnalisé en basant notre solution sur la réutilisation non pas de l information elle-même mais des applications (ou services) indépendantes qui la fournissent. Cette solution permet en particulier sans changer le scénario d utilisation, et le service composite associé, de remplacer une application intermédiaire par une autre, ayant les mêmes propriétés, mais plus récente, plus puissante ou plus adaptée. C est la voie que choisit également le Semantic Web en favorisant l effort de standardisation des Web services [9]. Nous avons montré comment des services peuvent fournir ou échanger une information tout en restant indépendants les uns des autres et du scénario qui les exploitent. Ils doivent
cependant fournir des meta data décrivant leurs points d intégration et un document dit document de matching, utilisé pour représenter leurs données dans une forme compatible avec une ontologie commune. Bien sûr les éléments de cette stratégie peuvent être améliorés. Tout d abord, pour éviter de partager la même ontologie, chaque service pourrait dépendre d une ontologie spécifique et les résultats sur la recherche de traduction d ontologies pourraient être utilisés pour adapter notre système. Puis, pour obtenir une meilleure personnalisation, nous pourrions aller au-delà de la logique du premier ordre, en utilisant par exemple, une logique probabiliste basée sur les réseaux bayesiens [5]. Références [1] Berners-Lee, T., Hendler, J., Lassila, O.: The Semantic Web. Scientific American (May 2001), p. 35 43. [2] Giroux, S., et al., Mobilite, Personnalisation et Information geo-referencee, JFIADSMA 2001, Montréal, Canada. [3] Davide Carboni, Sylvain Giroux, Eloisa Vargiu, Claude Moulin, Stefano Sanna, Alessandro Soro, Gavino Paddeu, e-mate: An open architecture to support mobility of users, proceedings of the Fifth International Baltic Conference on Databases and Information Systems (BalticDB&IS 2002), p. 227 241, Tallinn, Estonia, June 3-6, 2002. [4] Kifer, M., Lausen, G., Wu, J.: Logical Foundations of Object-Oriented and Frame- Based Languages. Journal of the ACM (1995). [5] Koller, D., Pfeffer, A.: Probabilistic frame-based systems. Fifteenth National Conference on Artificial Intelligence, Madison, Wisconsin (1998), p. 580 587. [6] Lassila, O., Swick, R. R.: Resource Description Framework (RDF) Model and Syntax Specification. W3C Recommendation, 22 February 1999. http://www.w3.org/consortium/process-20010719/ [7] Mizoguchi, R., Kitamura, Y., Foundation of Knowledge Systematization: Role of Ontological Engineering, Industrial Knowledge Management - A Micro Level Approach. Rajkumar Roy Ed., Springer-Verlag (2000) Chapter 1, p. 17 36. [8] OntoEdit Development Environment, http://www.ontoprise.de/com/start products.htm [9] T. Sollazzo, S. Handschuh, S. Staab, M. Frank. Semantic Web Service Architecture - Evolving Web Service Standards toward the Semantic Web. Proc. of the 15th International FLAIRS Conference. Pensacola, Florida, May 16-18, 2002. AAAI Press. [10] Uschold, M., Grüninger, M.: Ontologies: Principles, Methods and Applications. The Knowledge Engineering Review, V.11, N.2 (1996).