MÉMOIRE DE STAGE DE MASTER 2

Académie de Montpellier

Université Montpellier IISciences et Techniques du Languedoc

MÉMOIRE DE STAGE DE MASTER 2

effectué au laboratoire

Agrotechnology & Food Science Group,

Wageningen University & Research Center

Spécialité :Professionnelle et Recherche unifiée en Informatique

Une application Smartphone pour un systèmede recommandations alimentaires

personnaliséespar Anne Tireau

Soutenu le 13 Septembre 2010

Sous la direction de : Nicole Koenderinck

Devant le jury composé de :

Président : Rodolphe Giroudeau

Rapporteurs : Isabelle Mougenot: Abdelkader Gouaich

Remerciements

Je tiens à remercier, dans un premier temps, toute l’équipe pédagogique de l’univer-sité Montpellier II et les intervenants professionnels responsables du MASTER Infor-matique IFPRU, pour avoir assuré la partie théorique de celle-ci.

Je remercie également Madame Nicole Koenderinck ma tutrice au sein du départementde recherche Food & Biobased Research à l’Université de Wageningen (Pays-Bas) pourson accueil et son encadrement tout au long de ce stage.

Je tiens à remercier tout particulièrement et à témoigner toute ma reconnaissance àMadame Isabelle Mougenot pour son intérêt pour mon travail, ses conseils, son aide etsa disponibilité.

Un grand merci à toute l’équipe Information Management pour m’avoir fait décou-vrir un nouveau laboratoire de recherche, une autre façon de travailler et aussi une autreculture. Plus particulièrement, je remercie Hajo pour avoir facilité mon intégration etpour les discussions variées.

Pour finir, je n’oublie pas mes collègues de l’UMR MISTEA qui m’ont accueillie ily a 5 ans déjà dans leur équipe et qui m’ont encouragée à faire ce Master. Je les remerciepour tout leur soutien et leur aide précieuse. Je pense particulièrement à Brigitte, Nadineet Pascal.

iii

Table des matières

Introduction 1

1 Contexte et objectifs 31.1 Contexte du domaine applicatif . . . . . . . . . . . . . . . . . . . . . . 31.2 Objectifs informatiques . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Etat de l’art 112.1 Ontologies et outils du Web Semantic . . . . . . . . . . . . . . . . . . 112.2 Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3 La plateforme Smartphone . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Modèles de connaissances 213.1 Processus de conception et interaction entre les composants ontologiques 223.2 Ontologie des produits du Restaurant du Futur . . . . . . . . . . . . . . 253.3 Ontologies pour les préférences des consommateurs . . . . . . . . . . . 313.4 Ontologies de recommandations . . . . . . . . . . . . . . . . . . . . . 35

4 Mise en œuvre au travers d’une architecture logicielle 414.1 Architecture du prototype PEA et démarche de personnalisation . . . . 42

4.1.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.1.2 Démarche de personnalisation . . . . . . . . . . . . . . . . . . 44

4.2 Mise en œuvre opérationnelle d’un système à base de connaissances . . 454.2.1 Vocabulaire partagé . . . . . . . . . . . . . . . . . . . . . . . . 464.2.2 Serveur de stockage de données RDF . . . . . . . . . . . . . . 464.2.3 L’acquisition de données RDF et la constitution du jeu de tests . 464.2.4 Des modèles de connaissances aux objets métiers : exploitation

de SPARQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.3 Personnalisation du menu du jour : RoFAdvisedMenu . . . . . . . . . . 52

4.3.1 Évolution du modèle d’objet métier . . . . . . . . . . . . . . . 524.3.2 Gestion des conseils et des recommandations . . . . . . . . . . 544.3.3 Annotation advised et avoid . . . . . . . . . . . . . . . . . . . 54

v

TABLE DES MATIÈRES

4.3.4 Gestion de la tentation . . . . . . . . . . . . . . . . . . . . . . 574.3.5 Caractéristique pertinente . . . . . . . . . . . . . . . . . . . . 584.3.6 Gestion du plateau virtuel . . . . . . . . . . . . . . . . . . . . 59

4.4 Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.5 Application sur Smartphone . . . . . . . . . . . . . . . . . . . . . . . 66

5 Conclusion 75

Bibliographie 77

Annexes 79

A Questionnaire pour les consommateurs du RoF 81

B Analyse : scénarios et domaines des ontologies 87

C Facteurs essentiels du choix d’aliments 99

D Mode de vie du consommateur 103

E Concept de MeasurementCharacteristic 105

F Turtle code of Consumer 107

G Infrastructure des données 109G.1 Infrastructure des produits . . . . . . . . . . . . . . . . . . . . . . . . 109G.2 Infrastructure des produits . . . . . . . . . . . . . . . . . . . . . . . . 111G.3 Infrastructure des données intégrée . . . . . . . . . . . . . . . . . . . . 113

H Vocabulaire partagé 115

vi

Introduction

Ce stage de Master 2 s’est déroulé dans le département de recherche Food & BiobasedResearch à l’Université de Wageningen (Pays-Bas). L’objectif appliqué était de proposeraux clients d’un restaurant - self service expérimental , le Restaurant du Futur, un pro-totype de système de diffusion de conseils alimentaires qui convienne à leur mode devie, leurs caractéristiques physiques et physiologiques ainsi qu’à leurs goûts alimen-taires. Pour cela, il s’est avéré nécessaire d’avoir un environnement de connaissancesqui représente les différentes connaissances sur les menus (produits ou aliments as-sociés, leurs caractéristiques et valeurs nutritives) et sur les consommateurs référencés(caractéristiques physiques, préférences, mode de vie, objectifs diététiques, etc...), et quipermette de délivrer des conseils diététiques personnalisés. Pour aider le consommateurdans sa démarche, il est important que lorsqu’il se déplace dans le restaurant pour faireses choix, il dispose de l’information pertinente. La création de cet environnement aconstitué la première étape du stage. L’objectif à long terme est la prise en compte dela localisation des produits et du consommateur pour lui donner des conseils en tempsréel, adaptés à la gestion des tentations possibles et respectant ses objectifs diététiques.Une des originalités de l’approche est de proposer une application sur un environnementmobile, tel qu’un Smartphone.Pour ce faire, une ontologie sera construite pour chaque pan de connaissance, des don-nées seront élicitées et des ontologies locales définies à partir de ces données spéci-fiques. Dans ce but, les technologies et langages du Web Sémantique sont mises à profit.L’ensemble de ces ontologies est exploité au sein de l’environnement de connaissance.L’attention est portée sur la définition d’une architecture appropriée à leur exploitationpar des usagers finaux aux travers de plateformes mobiles.

La démarche générale sera testée et validée au travers de la réalisation d’un pro-totype. Ce prototype est développé à l’aide de différents outils : l’éditeur d’ontologieTopBraid, le système de gestion de connaissances Sesame, les langages du Web Séman-tique RDF/S, OWL et SPARQL, ainsi qu’un Web Service RestFul basé sur le frameworkRestlet et pour la plateforme mobile Windows Phone 7 Silverlight, XAML et C#.

Le rapport est structuré de la façon suivante : le contexte du stage et les objectifs in-formatiques dégagés font l’objet du premier chapitre. Les principaux outils utilisés sont

1

TABLE DES MATIÈRES

introduits dans l’état de l’art au chapitre 2. Les modèles de connaissance que nous avonsdéveloppés sont décrits au chapitre 3. Toute la partie mise en œuvre est détaillée dans lechapitre 4, de l’architecture du prototype du système de diffusion des conseils person-nalisés à l’application sur Smartphone. Des perspectives sont ensuite dégagées autourde plusieurs questions de recherche liées aux ontologies. La conclusion, chapitre 5, clôtla partie principale du mémoire. Des chapitres annexes sont donnés pour compléter l’in-formation, tant technique que associée à l’application (diététique, préférences).

2

Chapitre 1

Contexte et objectifs

1.1 Contexte du domaine applicatifLe contexte dans lequel ce stage a été réalisé est présenté ici. Il s’agit d’en expliquer

les grandes lignes afin de justifier les choix conceptuels ou technologiques qui serontfaits par la suite. Nous introduisons aussi le projet FOVEA sans lequel ce stage n’auraitpas eu lieu.

Les gouvernements des pays occidentaux ont mis en place de vastes campagnesd’information pour sensibiliser les populations à leur mode alimentaire. L’idée est doncde poser les bases d’une vie plus saine sans rien imposer. Ces campagnes, qui passentpar exemple par la diffusion de spots publicitaires, coûtent cher et ne récoltent quedes résultats plutôt médiocres. Or il est postulé que l’efficacité du message serait plusgrande si ce message était personnalisé. En effet, les conseils donnés jusqu’alors sontdes conseils généraux portant soit sur l’alimentation, soit sur la santé et rencontrent unaccueil assez limité de la part de la population. Les principaux reproches qui sont faitsà ces conseils, par trop généraux, sont les suivants :

– ils ne tiennent compte ni des préférences ou aversions alimentaires, ni des in-tolérances ou allergie alimentaires éventuelles ;

– ils ne considèrent, en aucun cas, les dépenses physiques journalières de la per-sonne ;

– ils sont en arrière plan au moment du choix ;– ils ne se doublent pas d’un travail de prévention portant sur une évaluation des

mauvaises habitudes alimentaires de tout un chacun.Dans ce contexte, le projet Food Valley Eating Advisor (FOVEA) 1 a été mis en placeet a pour un de ses objectifs, la création de la base d’un système de diffusion d’infor-mations axé sur la personne. Ce système est attendu de fournir à toute personne des

1. http://www.fovea-project.org/UK/

3

http://www.fovea-project.org/UK/


conseils personnalisés pour une alimentation plus saine et une activité physique plusadaptée.

Le département de recherche Food & Biobased Research est l’un des partenairesdu projet FOVEA. Ce département fait partie du centre Wageningen University & Re-search (WUR) 2 aux Pays-Bas. Ses domaines d’expertise portent sur les sciences sen-sorielles et le comportement alimentaire d’une part et sur les systèmes dit "intelligents"et la recherche appliquée en vision d’autre part. Cette double compétence en fait undépartement de recherche de choix pour la bonne conduite du projet FOVEA. J’ai étéplus spécifiquement accueillie dans l’équipe Information Management 3 dont les activ-ités sont ancrées dans le second axe "systèmes intelligents". Un système dit intelligentest vu, ici, comme un système automatisé enrichi d’une couche logicielle traitant de laconnaissance afin d’en élargir le périmètre de fonctionnalités. Dans cette optique et deconcert avec trois entreprises privées, le département de recherche Food & BiobasedResearch, a créé en 2007, le Restaurant du Futur 4, pour mener à bien ses recherchessur le comportement des consommateurs et les moteurs qui influent sur leurs choix ali-mentaires. Dans le projet FOVEA, Food & Biobased Research se positionne à l’échelledu restaurant pour répondre de manière appliquée et proposer un cas d’étude bien réel àla problématique du sujet. A partir des études menées dans ce cadre, les chercheurs deFood & Biobased Research développent des modèles conceptuels orientés vers de la per-sonnalisation de conseils alimentaires en vertu de différents facteurs : physiologiques,ethniques, financiers, éducationnels, liés aux modes de vie, etc. Le restaurant sert alorsde domaine d’étude et vient instancier les modèles construits. Il est alors plus facile devalider les modèles construits.

Le Restaurant du Futur est un restaurant d’entreprise, en libre-service, situé surle centre de l’Université de Wageningen (cf. figure 1.1). Ce restaurant est, avant tout,une zone d’expériences et d’études où les expérimentations en laboratoire portent sur ledomaine sensoriel des aliments : odeur, couleur, goût, etc.. La salle principale du restau-rant, quant à elle, permet d’étudier le comportement des consommateurs et leurs choixalimentaires durant un repas. Cela peut inclure l’étude de l’influence des paramètres liésaux produits : composition, goût, emballage, présentation ou informations associées(prix, nom, etc.). L’environnement est aussi pris en compte : agencement de la salle,couleur des buffets, des tables et des chaises, circulation dans le restaurant, influencede la luminosité, de la température ambiante... Ces informations sont collectées grâce àdes capteurs, notamment des caméras dont les séquences vidéos sont analysées et an-notées. A cela s’ajoutent des caisses enregistreuses, reliées à des systèmes de gestion

2. http://www.wur.nl/UK/3. http://www.fbresearch.nl/InformationManagement/4. http://www.restaurantvandetoekomst.wur.nl/UK/

4

http://www.wur.nl/UK/

http://www.fbresearch.nl/InformationManagement/

http://www.restaurantvandetoekomst.wur.nl/UK/

1.1 Contexte du domaine applicatif

de données, qui consignent les achats des consommateurs. En outre, chaque nouveauclient peut s’inscrire et répondre à un questionnaire (cf. annexe A). Celui-ci permettraaux chercheurs d’avoir une idée du mode de vie des usagers ou des relations entretenuesavec les aliments (détection de néophobie 5, par exemple). Cette démarche d’acquisitionet de valorisation d’information est importante et difficile, car l’étude du comportementimplique que la collecte des informations sur les consommateurs soit la moins intru-sive possible pour ne pas influencer leurs comportements. Ceci va aussi nécessiter del’expertise dans le domaine des nouvelles technologies de l’information et de la commu-nication, afin d’optimiser les traitements et leurs exploitations. C’est dans ce domainequ’intervient l’équipe Information Management. Dans ce contexte, les projets actuelle-ment en cours de réalisation portent sur des systèmes de reconnaissance visuelle depersonnes, de comportements et de produits ou sur le système d’intégration de données.

FIGURE 1.1 – Restaurant du Futur : buffet de la salle principale, caisse enregistreuse,salle de contrôle des caméras

La personnalisation des conseils va aussi dépendre des connaissances disponiblessur le consommateur, dans le cadre du restaurant.

Pour le consommateur, il pourra s’agir de :– ses caractéristiques physiques et physiologiques,– ses préférences alimentaires (goût / aversion),– l’historique de consommations des derniers jours,– ses habitudes alimentaires,

5. Néophobie : crainte de tout ce qui est nouveau.

5


– ses objectifs diététiques (régime végétarien ou hypocalorique par exemple),– son mode de vie (célibataire, déplacements fréquents, etc.),– son activité sportive,– son comportement face à la nourriture (importance des repas dans sa vie, etc.).Pour le Restaurant du Futur, la personnalisation va dépendre de l’environnement

mais surtout des connaissances possédées sur les produits disponibles :– la composition des menus,– les produits avec leurs caractéristiques et leurs valeurs nutritives. Notons que les

caractéristiques peuvent être assez fines, car elles concernent également tout cequi fait qu’un produit peut attirer ou rebuter un consommateur (goût amer, odeurde vanille...).

1.2 Objectifs informatiquesModèles de connaissances : l’objectif du projet est de proposer les premières briquesdu système de conseils alimentaires personnalisés, pour le Restaurant du Futur. L’unedes exigences du système, et l’un des enjeux informatiques ici, est la formalisation desconnaissances des différents domaines nécessaires. Cette formalisation va permettreune exploitation plus fine et poussée des informations et des données à disposition. Parexemple, elle pourra faciliter l’accès à l’information et à l’inférence de nouveaux faits.La particularité de ces modèles, ou composants ontologiques dans notre cas, est qu’ilsdevront être capables d’être combinés de manière intelligente, afin d’être exploitablespar le modèle de conseils. De plus, ils devront pouvoir évoluer et être enrichis pours’orienter vers un système de plus en plus complet.

Dans cette problématique, mon stage a tout d’abord consisté à proposer les premiersmodèles de connaissances, en se basant pour commencer sur l’existant, c’est-à-dire lesdonnées et les informations déjà disponibles. Dans un second temps, l’objectif du stageétait de mettre en œuvre ces composants ontologiques et de concevoir un premier proto-type du système de diffusion des conseils personnalisés ou PEA pour Personal EatingAdvisor en anglais.

Les exigences du système PEA sont triples : le système doit personnaliser les mes-sages, donner des retours à l’utilisateur sur ses choix et être mobile afin d’être présentau moment du choix. L’idée est de proposer un début de solution aux limitations desconseils généraux diffusés actuellement. Le but ici est avant tout pédagogique.

La personnalisation du message diffusé peut influencer son efficacité. Elle vaêtre guidée par les recommandations du modèle de conseils, en fonction des préférencesde l’utilisateur. Il s’agit de la forme et du contenu du message :

6

1.2 Objectifs informatiques

Forme : données textuelles, images, diagrammes, couleurs... Cette idée provient desconclusions de l’étude de l’influence des informations nutritives de Stubenitskyet al. (2000), et suppose que le type de format d’information utilisé pourrait in-fluencer l’efficacité du message. Par exemple, le nombre de calories (informationtextuelle) d’un aliment correspondant à un plat allégé, n’aura pas forcément deportée sur la personne qui n’a pas la notion de la ration qui lui est nécessaire.

Contenu : c’est l’information pertinente pour le consommateur. Il s’agit ici d’être enaccord avec le régime diététique du consommateur. Par exemple, donner la teneuren sel d’un produit reste surtout pertinent pour l’utilisateur qui suit un régime dit"sans sel".

Il en résulte, que cette personnalisation servira de guide pour la partie IHM 6 du systèmede diffusion de l’information.

Les réactions du système au choix du consommateur sont aussi des fonction-nalités attendues. Elles peuvent être vues comme une première solution au manque deretour à l’utilisateur sur ses mauvais choix. Comme par exemple, la proposition d’unealternative s’avérant plus pertinente que le choix opéré par le client. Une autre solutionest la mise en place du concept de plateau virtuel, ou Tray en anglais. Avant mêmede se trouver dans la cantine, l’utilisateur pourra ajouter ou supprimer des aliments deson plateau virtuel et consulter une évaluation globale de ses choix : résumé de l’apportcalorique de son repas pré-sélectionné, par exemple, ou réception d’une alerte au dé-passement d’un seuil fixé et personnalisé. Ainsi, il pourra ajuster ses choix en fonctiond’un plateau virtuel et de ses objectifs.

La mobilité de la solution est aussi une exigence importante pour aider la per-sonne, et qui va influencer le choix de l’architecture du système. En effet, dans lecas de l’utilisation du plateau virtuel, vu précédemment, la mobilité permettrait à l’u-tilisateur d’optimiser la composition de son plateau pendant ses choix. Cela est vraiaussi de façon plus générale, pour aider la personne à améliorer son comportement.Un des phénomènes à prendre en compte est celui de la tentation. Il influence énormé-ment les choix du consommateur et dépend souvent du contact avec les produits. Cequ’aimeraient les chercheurs, c’est de pouvoir, dans une prochaine version, coupler leconseiller à un système de géolocalisation des produits et du consommateur afin de leprévenir s’il s’approche de produits estimés comme "dangereux" ou au contraire de luiproposer un chemin optimal vers les produits bénéfiques. De ce fait, nous avons choisiune plate-forme mobile, type ordiphone ou Smartphone en anglais, pour restituer lesconseils. En effet, ils allient la capacité et les fonctionnalités nécessaires.

6. IHM : Interface Homme-Machine

7


L’objectif de mon stage est donc double. Premièrement, il s’agit de modéliser lescomposants ontologiques des domaines concernant une vaste préoccupation humaine :à savoir l’alimentation. Deuxièmement, il est aussi question de proposer un prototyped’architecture et d’application sur Smartphone capable de restituer au consommateur lemenu avec les conseils personnalisés et s’appuyant sur ces composants ontologiques.

La solution proposée est schématisée par la figure 1.2 où les principaux acteurs duprototype sont représentés avec leurs rôles. Un environnement de connaissances associéaux données collectées sera exploité par un modèle de conseils alimentaires person-nalisés que nous avons considéré comme une boîte noire. Sa tâche est de fournir lesrecommandations nécessaires à la constitution d’un menu issu de notre environnementet personnalisé, c’est-à-dire dont les informations seront restituées de manière perti-nente pour le consommateur. La plateforme choisie pour l’utilisateur est le Smartphoneafin de l’aider lors de ses choix au sein du Restaurant du Futur.

FIGURE 1.2 – Architecture générale du prototype

Trois profils de consommateurs établis avec les chercheurs et une diététicienne ontguidé notre étude. En effet, le domaine est très vaste et il fallait réduire dans un pre-mier temps l’espace de complexité. Par rapport au modèle de conseils et aux donnéesdisponibles, le prototype intègre des fonctionnalités restreintes. Il s’agissait cependant

8

1.2 Objectifs informatiques

de valider la globalité de l’approche. Les profils définis apportent individuellement uneproblématique bien identifiée pour laquelle il est attendu que le système apporte desréponses. Le profil principal et prioritaire est celui de John, détaillé ci-après. Le sec-ond profil est celui de Wim un sportif qui désire se préparer pour une compétition et ledernier profil est celui d’Esther, une environnementaliste (qui veut manger biologique)qui a une intolérance à la tomate. Vous trouverez en Annexe B, chapitre 1, le détail denos profils.

John est un homme de 50 ans et mesure 1 mètre 80. Il fait partie de l’équipeInformation Management, travaille devant son ordinateur toute la journée et a une ac-tivité sédentaire. Il est un consommateur régulier du Restaurant du Futur, puisqu’il ymange quatre fois par semaine. Il n’apporte jamais d’aliment extérieur au restaurant.Il a rarement de repas de travail, mais déjeune souvent avec les autres membres del’équipe. John n’est pas sportif, habite trop loin de son travail pour venir en vélo, etvient donc en voiture. Son IMC 7 est d’environ 30, donc il doit perdre du poids et c’estpourquoi il a un régime alimentaire basses calories particulier. Le problème est queJohn est gourmand et habitué à choisir des plats sucrés, il prend toujours un dessertpour finir son repas.

Recommandations diététiques pour John : dans le cadre d’un projet pour leRestaurant du Futur, John s’est rendu chez une diététicienne qui lui a listé les recom-mandations suivantes, en concordance avec le projet du restaurant :

Rec. 1 : le repas est divisé en catégories pour chacunes desquelles un produit doit êtrechoisi ;

Rec. 2 : Soupe, prendre une soupe de type bouillon ou basse calorie ;

Rec. 3 : Pain, prendre maximum deux tranches de pain complet ;

Rec. 4 : Assortiment pour sandwich, prendre maximum deux tranches de fromage :

Rec. 5 : Salade, prendre une salade naturelle ;

Rec. 6 : la somme des calories des produits choisis doit être inférieure à 600 kcal.

Exemple simple de scénario d’utilisation du Smartphone : John quitte son lab-oratoire vers 12h30, et se dirige avec les autres membres de l’équipe vers le Restaurantdu Futur pour aller déjeuner, son Smartphone en poche. Juste avant d’arriver, John sortson Smartphone et lance l’application Lunch@RoF, le premier écran d’accueil souhaitela bienvenue à John sur l’application et lui indique que le menu du jour est disponible.Arrivé au restaurant, John prend un plateau et ses couverts, puis consulte la liste des

7. IMC : Indice de Masse Corporelle

9


catégories d’aliments disponibles aujourd’hui, il sait en regardant la liste qu’il pourratrouver des soupes adaptées à son régime (point vert devant la catégorie des soupes).Arrivé devant le buffet des soupes, il se rend compte que toutes lui donnent envie. Iljoue le jeu et consulte la liste des soupes sur son Smartphone et voit qu’une des soupesest signalée comme "à éviter" par une marque rouge, mais que l’autre est conseillée(marque verte). Il se sert de la soupe conseillée et juste avant de repartir pour choisir lasuite, il ajoute dans le plateau virtuel de son Smartphone la soupe choisie. Il continueainsi de suite. Avant de quitter le self, il passe devant le buffet des desserts et a envie dese laisser tenter par une crème au chocolat, il consulte le résumé du plateau virtuel etvoit qu’il n’a pas dépassé les 600 kcal conseillées. Il ajoute la crème au plateau virtuelet là, une alerte rouge lui indique que le total des calories de son repas va dépasserles 700 kcal. Un peu déçu, John supprime la crème de son plateau virtuel et chercheun dessert alternatif parmi les desserts conseillés, il trouve une mousse de fruits quiconvient juste, il voit que cette mousse est située sur le buffet des fruits, il s’y rend toutcontent, car il adore aussi cette sorte de produits, il la met sur son plateau physique etva payer ses produits à la caisse.

10

Chapitre 2

Etat de l’art

Pour mettre en place le prototype de diffusion d’informations alimentaires person-nalisées pour les consommateurs du Restaurant du Futur, nous avons eu besoin d’unlarge spectre de notions et de technologies. La démarche est de baser ce système surdes connaissances que nous avons choisies de représenter sous forme d’ontologies et enutilisant les langages de représentation du Web Sémantique. Le système en lui mêmecomprend un système permettant d’exploiter ces connaissances. L’architecture mise enplace est distribuée et le moyen de consultation des conseils alimentaires est une plate-forme de type ordiphone.

2.1 Ontologies et outils du Web Semantic

Ontologies

Dans le contexte de l’informatique et des sciences de l’information, une ontologiepeut être définie comme un ensemble de concepts et de relations permettant de mod-éliser un domaine de connaissances (Gruber (2009)). Dans concepts sont incluses lasignification et les contraintes logiques d’application d’une représentation.

Nous pouvons distinguer plusieurs types d’ontologie, regroupés et commentés parPsyché et al. (2003). Cette classification va dépendre du but de l’ontologie, de l’étendueet de la précision du domaine modélisé :

– les ontologies de représentation des connaissances : formalisation des connais-sances ;

– les ontologies supérieures ou de haut niveau : ontologies universelles qui ne dépen-dent pas de domaine, ni de problème particulier. Elles concernent des conceptstrès généraux comme le temps, les évènements, l’espace, les actions... Ces con-cepts doivent être consensuels entre une grande communauté ;

11

Etat de l’art

– les ontologies génériques ou méta-ontologies : moins génériques que les précé-dentes, mais assez pour être réutilisables à travers plusieurs domaines (exempleOBOE 1) ;

– les ontologies de domaine : ensemble de vocabulaires et de concepts qui décritun domaine d’application, basé sur la connaissance du domaine où la tâche estréalisée ;

– les ontologies de tâches : pour conceptualiser des tâches (diagnostic, planifica-tion...) spécifiques dans les systèmes ;

– les ontologies d’application : les plus spécifiques, domaine restreint, destinées àl’exécution d’une tâche. Un concept correspond souvent à un rôle joué par uneentité dans le système.

Les ontologies peuvent exploiter le fonctionnement du Web de plusieurs manières,Berners-Lee et al. (2001) :

– pour améliorer la pertinence des recherches, par concept,– pour associer à une page des structures de connaissance et à des règles d’in-

férence.

Web Sémantique

L’approche actuelle du Web Sémantique, ou Web des données, est basée sur l’idéede travailler, au niveau du Web, à partir de concepts plutôt que de documents, qui con-tiendraient alors des informations, ou métadonnées, formalisées pour être traitées au-tomatiquement par des agents logiciel. Le Web de données est fondé sur une pile delangages et protocoles issus du Web et propres au Web Sémantique (illustration figure2.1), conçus pour être compris sémantiquement et utilisables par les programmes. LeW3C 2 supervise le développement des standards, propre aux Web Sémantique, commeRDF 3, RDFS 4, OWL 5 ou SPARQL 6 que nous allons décrire.

RDF : pour Resource Description Framework, Manola & Miller (2004), un langagepour représenter des informations à propos de ressources sur le Web. RDF est destinéaux situations où ces informations ont besoin d’être traitées par des applications au lieud’être seulement affichées pour les personnes. Les informations peuvent être échangéesentre les applications sans perte de sens. RDF est fondé sur l’idée d’identifier les chosesen utilisant des URI 7, et en décrivant les ressources en fonction de propriétés et de

1. OBOE : OBOE : Extensible Observation Ontology2. W3C : World Wide Web Consortium3. RDF : Resource Description Framework4. RDFS : Resource Description Framework Schema5. OWL : Web Ontology Language6. SPARQL : SPARQL Protocol and RDF Query Language7. URI : Uniform Resource Identifier, identificateurs de ressource Web

12

2.1 Ontologies et outils du Web Semantic

FIGURE 2.1 – Pyramide des technologies du Web Sémantique

valeurs de propriétés. De ce fait, on pourra traduire des informations simples sur lesressources sous forme de graphe, où les nœuds représentent des ressources et les arcsles propriétés. RDF emploie une terminologie particulière, illustrée par la figure 2.2,pour indiquer les diverses parties des déclarations :

– le sujet concerne ce qui est décrit,– le prédicat correspond à la propriété,– l’objet est la valeur de la propriété.

FIGURE 2.2 – Représentation graphique d’un triplet RDF

La sérialisation des déclarations, ou triplets, peut avoir différents formats, Segaran et al.(2009) : notation N-Triples 8 (syntaxe verbeuse), N3 9 (syntaxe condensée) et RDF/XML 10

8. http://www.w3.org/2001/sw/RDFCore/ntriples/9. http ://www.w3.org/DesignIssues/Notation3

10. http ://www.w3.org/TR/REC-rdf-syntax/

13

http://www.w3.org/2001/sw/RDFCore/ntriples/

Etat de l’art

(syntaxe officielle).

RDFS : pour RDF Schema, permet de décrire les ressources du vocabulaire RDF. Ildéfini la notion de classe et de propriété. Il permet de définir des hiérarchies de classeset de propriétés.

OWL : pour Web Ontology Language, Mcguinness & van Harmelen (2004) et Segaranet al. (2009), est un langage RDF pour la définition de classes et de propriétés (RDFS),mais aussi pour permettre plus de raisonnements et des inférences basées sur les rela-tions. Ce langage est divisé en trois sous-langages dont la complexité et l’expressivitéaugmentent. OWL-Lite, le plus simple, OWL-DL 11, basé sur les logiques de descriptionet OWL-Full, le plus expressif mais dont la calculabilité n’est pas garantie.

SPARQL : pour SPARQL Protocol and RDF Query Language, Prud’hommeaux &Seaborne (2008), SPARQL est un langage d’interrogation standard pour les graphesRDF. Il est capable de rechercher des motifs de graphe (graph patterns) obligatoires etoptionnels ainsi que leurs conjonctions et leurs disjonctions. SPARQL gère également letest extensible des valeurs et la contrainte des interrogations par un graphe RDF source.Les résultats des interrogations SPARQL peuvent être des ensembles de résultats oudes graphes RDF. Ce langage d’interrogation ne permet pas, comme le fait SQL 12 pourles bases de données relationnelles, d’insertion, de modification ou de suppression detriples.

Outils d’exploitations

Sesame est un logiciel libre. Ce "framework" Java, développé au départ par la so-ciété hollandaise Aduna dans le cadre d’un projet européen, évolue actuellement grâceà un projet communautaire et hébergé par OpenRDF. Sesame 13 va fournir les fonction-nalités nécessaires au stockage de triplets RDF ainsi que des librairies d’interrogationet de manipulation de ces triplets. Sesame va également fournir le raisonneur RDFS,subsumption de classes et de propriétés par exemple et OWL DLP avec l’extensionOWLIM. Il est facilement extensible grâce au développement de la communauté, citonspar exemple des adapteurs Jena pour faciliter le passage entre les deux API 14, Elmo quifournit une API, basée sur les annotations Java, permettant un mapping entre structuremétier et ontologie.

11. OWL-DL : Ontology Web Language Description Logics)12. SQL : Structured Query Language13. http://www.openrdf.org/14. API : Application Programming Interface

14

http://www.openrdf.org/

2.2 Web Service

Jena est aussi un outil libre et similaire à Sesame. Jena 15 a été développé au départ parla société Hewlett-Packard Labs Semantic Web Programme. L’API est plus complètecar elle inclut nativement le support de OWL. De plus, ce "framework" Java fournitégalement plusieurs raisonneurs internes et permet l’utilisation de Pellet, raisonneurOWL-DL.

2.2 Web Service

Ils vont permettre de mettre en place l’architecture distribuée pour l’utilisation d’uneplateforme mobile. Il existe deux grands types de Web Service : les architectures REST 16

et l’utilisation des standards liés à XML 17.

Les Web Services RESTful sont basés sur un type d’architectures fondées sur lesconcepts de ressources et d’agents et développées dans la thèse de Roy Fielding, Field-ing (2000). Le principe est qu’un composant logiciel puisse lire ou modifier une ressourceen utilisant une représentation (XML ou JSON 18 par exemple) de cette ressource. Commedans le domaine du Web Sémantique, l’URI a un rôle important et doit suffire pouridentifier une ressource. Les services basés sur rest utilise le protocole HTTP, définipar le norme RFC2616, voir Fielding et al. (1999). Ce protocole fournit les opérationsnécessaires à la manipulation des ressources : GET, POST, PUT, DELETE, etc.. L’in-convénient de REST est que le client doit conserver localement les données, puis quec’est un service sans état, ce qui peut poser des problèmes de charge.

Les Web Services basés sur les technologies du W3C reposent sur un ensemblede protocoles et de standards utilisés au départ pour l’échange de données entre en-vironnements hétérogènes. Les trois éléments principaux sont SOAP (Simple ObjectAccess Protocol) pour l’échange des messages pour l’appel et réponse de méthodesentre les deux environnements, WSDL (Web Service Description Language) pour la de-scription des messages échangés (type de données, opérations...) et enfin les annuairesUDDI (Universal Description Discovery and Integration) pour le référencement et ladécouverte des Services Web. L’inconvénient dû à la multitude des technologies est laperformance qui est moins importante.

15. http://openjena.org/16. REST : Representational State Transfer17. XML : eXtensible Markup Language18. JSON : JavaScript Object Notation

15

http://openjena.org/

Etat de l’art

2.3 La plateforme Smartphone

Un smartphone ou ordiphone peut être différencié d’un téléphone portable ou d’unassistant électronique de poche (ADP) 19 par ses fonctionnalités. Un smartphone intègreactuellement un client de messagerie, un navigateur web, des fonctionnalités GPS 20,de synchronisation avec des outils d’ordinateur de bureau type "organiseur" commeagenda, carnet d’adresse, dictaphone (Charlesworth (2009)).

Le système d’exploitation Windows Phone 7 a été choisi pour notre prototype. Cesystème sera disponible en octobre 2010 mais dès à présent Microsoft met à dispositionun ensemble d’outils de développement gratuits, à savoir :

– un émulateur Windows Phone 7,– l’EDI 21 Visual Studio 2010 Express pour Windows Phone CTP 22,– la plateforme de développement Silverlight pour Windows Phone CTP,– le framework XNA 4.0 Game Studio CTP (destiné au développement de jeux, il

n’a pas été utilisé pour notre projet).Le fait que soit livré un ensemble d’outils complets et faciles à installer a contribué auchoix de la plate-forme Windows Phone 7. De plus, nous avons choisi Silverlight caril permet de migrer facilement le prototype Smartphone vers un site web. Enfin, nousavons particulièrement tenu compte des compétences des membres l’équipe dans lestechniques liées à Silverlight et C# et par-là même de la future maintenance et évolutiondu produit.

L’émulateur Windows Phone 7 est une application 23 de type "ordinateur de bureau"permettant de simuler le système d’exploitation Windows Phone 7. Il fournit un environ-nement de virtualisation pour déployer, déboguer et tester les applications développées.Il a été conçu pour fournir la même ergonomie et les mêmes performances qu’un réelordiphone. De plus, il requiert les mêmes exigences de développement. Toutefois, il nefournit pas pour l’instant tous les programmes natifs de Windows Phone 7 (e.g. la fonc-tion de téléphonie, de camera ou de GPS). Ceci n’a pas été préjudiciable à cette versiondu prototype car seules les fonctionnalités de réseau (pour la communication avec leWeb Service) et la présence d’une zone de stockage persistante (pour l’enregistrementde la configuration des paramètres utilisateur) ont été utiles.

19. PDA : Personal digital assistant20. Géolocalisation par satellites ou Global Positioning System21. Environnement de développement intégré22. CTP : Community Technology Preview indique que les outils sont en pré-version)23. Windows Phone Emulator : http ://msdn.microsoft.com/en-

us/library/ff402563%28v=VS.92%29.aspx

16


Microsoft Visual Studio 2010 Express pour Windows Phone CTP permet de créerdes applications Silverlight pour Windows Phone 7. Il permet de déployer l’applicationdirectement sur l’émulateur ou sur un appareil Windows Phone 7.

Silverlight est une implémentation du Framework Microsoft .Net, destinée à créer desapplications interactives riches (ou RIA 24 en anglais) sur le Web, multiplateformes etnavigateurs Web. Les bibliothèques de classes fournies par Silverlight pour WindowsPhone donnent des classes, composants, contrôles et éléments d’interface utilisateurspécialement adaptés aux applications sur ordiphone Windows Phone 7. Ils correspon-dent à une version améliorée de Sivlerlight 3 classique sans offrir toutes les fonction-nalités de Silverlight 4 (la version actuelle).Silverlight peut être décrit comme un sous-ensemble de la technologie Microsoft Win-dows Presentation Foundation 25 (WPF) et va notamment donner accès aux fonctionnal-ités de liaison de données (data binding en anglais).

L’infrastructure de liaison de données est importante pour cette technologie etpour le modèle de programmation d’applications Silverlight. Elle permet de lier l’inter-face utilisateur (e.g. une ListBox) à un objet de données (e.g. tableau d’objet). Il gèrele flux entre les deux : lorsque l’un des deux change, les modifications sont répercutéesautomatiquement sur l’autre élément par un moteur de liaison. La figure 2.3 montre leséléments qui entrent en jeu dans la liaison 26.

FIGURE 2.3 – Concepts de base d’une liaison de données

24. Rich Internet Application, dont la première définition et description des fonctionnalités sontdécrites par Allaire (2002)

25. http://msdn.microsoft.com/fr-fr/library/cc903925%28v=VS.95%29.aspx26. http://msdn.microsoft.com/fr-fr/library/cc278072%28v=VS.95%29.aspx

17

http://msdn.microsoft.com/fr-fr/library/cc903925%28v=VS.95%29.aspx

http://msdn.microsoft.com/fr-fr/library/cc278072%28v=VS.95%29.aspx

Etat de l’art

XAML XAML (eXtensible Application Markup Language) est un langage de bal-isage basé sur XML (eXtensible Markup Language). Dans Silverlight, le rôle princi-pal de XAML est de décrire l’apparence visuelle de l’interface utilisateur. La logiqueest définie dans un fichier associé appelé code-behind ou code joint. L’avantage deson utilisation est la séparation des rôles des personnes : les concepteurs graphisteset développeurs de l’application.Le code-behind est un objet d’un langage du Common Language Runtime (CLR), com-posant du Framework Microsoft .Net, comme C#. Lorsque l’application est compilée,la page correspondant au code XAML est partielle et complétée par le code joint. Cecode va permettre notamment la gestion de la logique comme la gestion des évènementsde l’interface.

Le patron de conception Modèle-Vue-VueModèle (MVVM), 27 est un patron de con-ception architectural basé sur le design pattern Modèle-Vue-Controleur (MVC) bienconnu. Ce modèle est utilisé massivement et fait partie des bonnes pratiques de concep-tion pour les applications Silverlight. C’est donc ce patron de conception qui structurel’application ordiphone du projet avec trois types d’objets : des vues écrites en XAMLet C#, des classes ModelVue en C# et des objets modèles présentant les données, dedeux types C# et XML. La figure 2.4 28 représente les interactions entre les vues, lesdonnées et le modèle de présentation. Ici on voit le rôle de la liaison de données qui vapermettre de lier la vue et le modèle de présentation sans qu’il soit nécessaire de faireréférence à la vue et donc de coder la mise à jour de la vue et tester les interactions. Onva donc avoir une liaison dynamique entre ces deux composants.

FIGURE 2.4 – Schéma du modèle Modèle-Vue-VueModèle

Dans ce patron de conception, le modèle de présentation va faire le lien entre lemodèle (données) et les vues. Dans notre projet, nous avons mis à disposition les don-nées par l’intermédiaire d’un Web Service RESTFull sous forme de données XML, voir

27. MVVM : Model-View-ViewModel en anglais28. Présentation du modèle disponible à l’adresse http://live.visitmix.com/MIX10/Sessions/EX14

18

http://live.visitmix.com/MIX10/Sessions/EX14


section 4.4. L’exploitation de XML avec Silverlight est possible avec l’interface de pro-grammation LINK to XML 29.

LINK to XML est proche du modèle DOM 30 car le document XML est chargé en mé-moire. Le document peut être interrogé ou modifié. LINK 31 est un langage de requêtesproche de SQL 32 ou XPath (non disponible sous Silverlight pour Windows Phone).

29. Complément disponible à l’adresse : http://msdn.microsoft.com/library/bb308960.asp30. DOM : Document Object Model31. LINK : Language Integrated Query32. SQL : Structured Query Language

19

http://msdn.microsoft.com/library/bb308960.asp

Chapitre 3

Modèles de connaissances

Introduction

Les modèles de connaissances, au sein du système PEA (Personal Eating Advisor),jouent un rôle prépondérant, dans le sens où ils vont permettre une consultation adaptéede l’information et par là même, guider l’interface homme-machine de diffusion. Deplus, ils vont être un support à la résolution des problèmes posés et être exploités par lemodèle de conseils alimentaires.

Deux champs principaux de connaissances sont impliqués dans le système PEA etsont à la base de la grande majorité des modules ontologiques, ces champs couvrentle Restaurant du Futur et les consommateurs. Les deux champs sont reliés par un bonnombre de passerelles et vont permettre au système de répondre aux problématiquesdu projet, à savoir, fournir des conseils alimentaires pertinents et personnalisés à unconsommateur. A cette fin, plusieurs relations de dépendance ou de réutilisation vontexister entre nos modules ontologiques. Par ailleurs, étant dans un contexte complexeet de recherche, ils sont amenés à s’étendre et à inclure des concepts de domaines com-plémentaires, comme par exemple, celui de la perception sensorielle ou de la diété-tique. Ainsi, nous avons conçu nos modèles comme une collection de composants on-tologiques mis en relation et réutilisés, afin de prévoir les futures extensions.

Nous présenterons, en premier lieu, le processus de conception et l’organisationgénérale des composants avec leurs interactions, section 3.1, puis nous détaillerons leurformalisation dans les sections suivantes.

21


3.1 Processus de conception et interaction entre les com-posants ontologiques

Processus de développement

Nos ontologies ont été développées en se basant sur la méthodologie "Ontology De-velopment 101" décrite par Noy & Mcguinness (2001). Les première étapes de détermi-nation du domaine et de la portée des ontologies, ainsi que, la liste des termes importantssont joints en annexe B, chapitres 2 et 3.

Pour les définir, nous nous sommes, en premier, appuyés sur l’existant, c’est-à-direles données disponibles : les produits, l’identification des employés, les enquêtes, etc..Par la suite, certains pans de connaissances ont été mis en exergue en interrogeant unexpert du comportement des consommateurs et une diététicienne. Enfin, nous avons prisen compte l’expertise de l’institut au travers d’articles scientifiques publiés par l’institutdans le domaine.

Nous avons formalisé nos modèles de connaissances avec le langage du Web Séman-tique OWL, standards du W3C. En effet, il apporte plus d’expressivité que les langagesRDF et RDFS, sur lesquels, il s’appuie. Et plus précisément, nous avons utilisé les car-actéristiques de OWL DL pour pouvoir raisonner dans un espace qui reste calculable etdécidable.

Chacun des composants a été défini à l’aide de l’éditeur TopBraid. Dans la suite dece document, le format de restitution des définitions des ontologies peut varier : pseudonotation UML fournie par l’éditeur, code Turtle 1 ou format XML/RDF.

Le cas du modèle de conseils alimentaires personnalisés

Le modèle de conseils est développé par les chercheurs en sciences du comporte-ment des consommateurs. Son rôle est de fournir des conseils pertinents. Durant monstage, nous l’avons considéré comme une boîte noire. Afin que le système puisse tenircompte des recommandations du modèle, nous avons créé une ontologie spécifique,destinée à l’expression des recommandations. La figure 3.1 schématise le principe del’intégration allant du modèle au système. Les modules ontologiques des consomma-teurs, des menus et produits sont en entrée. Pour la sortie, nous utilisons l’ontologie desrecommandations ou Advise dans notre projet.

Stratégie de combinaison des composants ontologiques

Un composant, en génie logiciel, est une unité de composition, avec un contexte dedépendances explicites. Szyperski complète la définition dans Broy et al. (1998) : un

1. Turtle - Terse RDF Triple Language, submission standard W3C référencée à l’adresse http://www.w3.org/TeamSubmission/turtle. Chaque triplet est exprimé textuellement de manière compacte.

22

http://www.w3.org/TeamSubmission/turtle

http://www.w3.org/TeamSubmission/turtle

3.1 Processus de conception et interaction entre les composants ontologiques

FIGURE 3.1 – Interaction entre le modèle de conseils et les ontologies

composant logiciel peut être déployé indépendamment et peut être sujet de compositiond’un tiers.

De la même façon, nos composants ontologiques ont des propriétés similaires. Ilssont réutilisables, composés d’autres composants, composables et possède une autonomierelative. La figure 3.2 représente, à l’aide de la notation UML, les trois composants ma-jeurs, à savoir :

– une ontologie du contexte du restaurant avec la définition des menus et de l’envi-ronnement matériel,

– une ontologie pour décrire les produits,– une ontologie pour définir les consommateurs.

FIGURE 3.2 – Représentation des composants ontologiques majeurs, au travers d’undiagramme de composants UML

23


Nous avons aussi représenté l’ontologie des recommandations, Advise, car elle joue eneffet un rôle particulier dans notre système.

Une zone en pointillés a été ajoutée afin de représenter le lien fort qui existe en-tre l’ontologie du contexte du restaurant et l’ontologie des produits. Ceci nous pousse,souvent tout au long de ce document, à ne considérer qu’une seule ontologie, celle desproduits. En pratique cela est dû au fait que nous retrouvons un lien de composition en-tre les menus et les produits, et que l’ontologie de description de l’environnement (table,chaise, luminosité...) du restaurant reste encore à construire.

Sur ce schéma, les ontologies sont exploitées par deux éléments (noeuds) : le mod-èle et le système de diffusion. Dans les deux cas, des ontologies différentes sont actives,ou utilisées, par les acteurs : le contexte, les produits, les consommateurs et les recom-mandations par le modèle de conseils et le contexte/menu et les recommandations parle système de diffusion. Ceci correspond au premier type de modularité entre nos on-tologies.

Une autre caractéristique de nos ontologies est la sous-composition et le partage decomposants. Ceci est lié à la propriété de réutilisation des ontologies. Par exemple, lafigure 3.3 schématise une partie des relations des ontologies Measure et Diet, que nousavons spécialement définies pour le projet, et dont le but est respectivement de décrireles mesures (e.g. masse, prix, etc.) et les régimes alimentaires des consommateurs.

FIGURE 3.3 – Représentation des composants Measure et Diet, avec la notation UML

24

3.2 Ontologie des produits du Restaurant du Futur

L’ontologie locale des mesures va réutiliser l’ontologie OUM (cf. section 3.2). Mea-sure est utilisée pour annoter toutes les caractéristiques mesurables de nos modèles.Ainsi, elle est utilisée pour décrire les caractéristiques physiques (taille, poids...) d’unconsommateur, ou encore les caractéristiques nutritives d’un produit. Au besoin, nouspouvons connecter le composant des Measure aux ontologies, pour ajouter des types deconnaissances mesurées. La définition des régimes alimentaires, Diet sur la figure 3.3, etdes produits sont d’autres exemples d’utilisation de composants "partagés". Ainsi l’on-tologie Sensory&Strucure est utilisée par le consommateur pour décrire ses préférencesgustatives, tandis que dans le cadre de l’ontologie des produits on décrit les goûts.

Dans les sections suivantes, nous détaillerons la modélisation des modules ontologiquesdes produits du restaurant, section 3.2, des consommateurs, section 3.3 et enfin la défi-nition des recommandations du modèle de conseils, section 3.4.

3.2 Ontologie des produits du Restaurant du FuturLe but de l’ontologie du Restaurant du Futur (RoF) est de modéliser le contexte d’un

restaurant : matériel (disposition des buffets, des meubles, des plats...) et le contenu (lemenu, catégories...). Une ontologie des produits est aussi nécessaire pour décrire lesproduits impliqués dans les menus. Ces modèles sont spécifiques à notre prototype etutilisables pour la restitution du menu à l’utilisateur. Pour cette modélisation, nous noussommes appuyés sur les données acquises concernant les produits et les menus.

Les données disponibles sont de plusieurs types :– les catégories et les buffets existants au restaurant ;– la définition des menus par saison de trois mois ;– les produits : nom, prix, masse, caractéristiques nutritives, végétarien ou non,

catégories du restaurant d’appartenance, buffet où ils sont disposés, disponibil-ité (quotidienne ou variable), etc.

Product est le concept principal de notre modèle. Il correspond à un élément d’unmenu, un aliment solide ou liquide simple (e.g. une pomme) ou plus sophistiqué com-posé d’ingrédients (e.g. tagliatelles au saumon). Certains produits sont cuisinés sur placepar le chef, d’autres élaborés au-dehors. La figure 3.4, générée avec l’éditeur TopBraid,correspond à la définition d’un produit et montre ses relations avec les autres conceptsdu restaurant.

Graphiquement, les propriétés d’objets sont précédées d’un rectangle bleu, les pro-priétés de types de données d’un rectangle vert. Chaque nom de concept ou de pro-priété est précédé d’un identificateur d’espace de nommage défini par l’utilisateur, ici,

25


prod correspond à l’espace de nommage http ://www.wurvoc.org/rof/product# et measà http ://www.wurvoc.org/rof/measurement#. L’espace de nommage, dans les standardsdu W3C, correspond à un vocabulaire spécifique. Différents espaces de nommage per-mettent ainsi de tirer parti de différents vocabulaires et structures dans une ontologie,l’utilisation d’identificateurs permet de rendre la présentation plus lisible et d’évitertoute ambiguïté entre les structures exploitées. Ainsi, l’entité Product fait référence àdeux vocabulaires qui correspondent à la définition du module ontologique des produitset au composant des mesures, détaillé section 3.2.

L’entité Product est caractérisée par plusieurs types de propriétés qui vont portersur : ses caractéristiques mesurables ou non et sa place dans le contexte du restaurant.

FIGURE 3.4 – Ontologie pour décrire les produits disponibles au RoF

26


L’illustration d’un produit est donnée par la propriété hasIcon de cible un nomdu fichier. La gestion de l’affichage de l’image se fera ensuite par l’application. C’estune propriété importante au niveau du domaine d’application, car l’aspect des plats entreen jeu lors de du choix de certains consommateurs. Cette propriété est aussi utilisée parle concept Category. Un produit qui n’a pas d’illustration, utilise celle de sa catégorie.

La localisation des produits et des buffets dans le restaurant va permettre demettre en place, l’aide à l’accès aux produits en évitant le phénomène de tentation :alerte visuelle, tactile ou chemin optimal (cf. section 1). Pour répondre à ce besoin, lapropriété hasLocalisation de domaine Product ou Category a été ajoutée. Dans cetteversion, la localisation est représentée pour l’application par un nom de fichier de carteprédéfinie du restaurant avec un buffet mis en surbrillance (cf. fig. 3.5). Si nous n’avonspas la localisation d’un produit, sa localisation est celle du buffet.

FIGURE 3.5 – Exemple de localisation du buffet des soupes

La représentation de l’agrégation de produits dans des catégories, sur des buf-fets ou pour les menus est établie au travers des propriétés d’objets belongsTo et aggre-gates (cf. figure 3.4). La figure 3.6, générée avec TopBraid, représente leur définition.Ces propriétés sont inverses, la propriété belongsTo a pour domaine Product et d’imageformée par l’union des concepts Buffet, Category et Menu ce qui signifie qu’un produitpeut appartenir à des menus, des catégorie ou des buffets. La propriété aggregates vapermettre d’accéder aux produits en partant de l’élément regroupant : catégories, menuou même localisation. Cette définition facilite la navigation entre les éléments et l’accèsaux produits.

Dans notre modélisation, nous avons favorisé l’utilisation de relations entre nos pro-duits d’autres concepts car cette structuration est souple et va permettre de faire évoluerla catégorisation des produits. Par exemple, les produits laitiers sont actuellement répar-tis dans deux catégories du restaurant : "beurre et sauce" et "dessert". Or, pour identifierles produits à base de lait de vache (en cas d’intolérance par exemple), nous allons avoir

27


besoin de nous appuyer sur un autre type de connaissances et utiliser l’ontologie desproduits laitier, déjà existante.

L’idée des propriété belongsTo et aggregates est de représenter le concept de com-position. Odell (1998) définit la composition comme un mécanisme servant à former unobjet entier en utilisant d’autres objets comme parties. La représentation de la composi-tion est un sujet en développement dans le cadre du W3C, voir Rector & Welty (2005)sur la représentation de la composition. En effet, elle n’est pas native au formalismecomme peut l’être la spécialisation et nécessite un modélisation manuelle.

FIGURE 3.6 – Définition de la propriété belongsTo

Les caractéristiques mesurables des produits sont définies à l’aide du vocabu-laire d’un composant que nous avons défini Measure. Nous avons choisi de modéliserce concept par une relation n-aire entre :

– une variable ou Metrological_concept ;– une unité Unit_of_measure ;– une valeur qui peut être numérique, booléenne ou symbolique.

Le but est de pouvoir représenter, par exemple, qu’"une portion de tiramisu a une massede 85 grammes".

La difficulté ici a été de représenter une relation n-aire, entre plusieurs éléments,alors qu’en général les propriétés dans le Web Sémantique sont des relations binairesentre deux instances. La solution choisie est celle qui est aussi explicitée dans le doc-ument du W3C de Noy & Rector (2006), c’est-à-dire l’introduction d’une classe pourune relation, ici le concept de MeasurementCharacteristic. Le listing 3.1, représente ladéfinition, en Turtle, du concept que nous avons appelé MeasurementCharacteristic.

Une propriété hasValue avec comme sous-classe hasNumericalValue va nous per-mettre de renseigner la valeur de la mesure. Deux autres propriétés d’objet vont venircompléter l’information de la valeur à savoir measureOf et hasUnitOfMeasure pourla variable mesurée et l’unité de mesure. Ces trois propriétés sont fonctionnelles (cf.

28


annexe E, listings E.1 et E.2), c’est-à-dire que pour une instance de MeasurementChar-acteristic ces propriétés auront une unique instance.

Listing 3.1 – Code Turtle de la définition de MeasurementCharacteristicmeas:MeasurementCharacteristic

a owl:Class ;rdfs:label " Measurement c h a r a c t e r i s t i c "@en ;rdfs:subClassOf owl:Thing ;rdfs:subClassOf

[ a owl:Restriction ;owl:maxCardinality " 1 " ^^xsd:nonNegativeInteger ;owl:onProperty meas:hasDateOfMeasure

] ;rdfs:subClassOf

[ a owl:Restriction ;owl:maxCardinality " 1 " ^^xsd:nonNegativeInteger ;owl:onProperty meas:hasValue

] ;rdfs:subClassOf

[ a owl:Class ;owl:intersectionOf ( [ a owl:Restriction ;

owl:allValuesFrom oum:Unit_of_measure ;owl:onProperty meas:hasUnitOfMeasure

] [ a owl:Restriction ;owl:allValuesFrom oum:Metrological_concept ;owl:onProperty meas:measureOf

] )] ;

rdfs:subClassOf[ a owl:Restriction ;owl:maxCardinality " 1 " ^^xsd:nonNegativeInteger ;owl:onProperty meas:hasUnitOfMeasure

] ;rdfs:subClassOf

[ a owl:Restriction ;owl:cardinality " 1 " ^^xsd:nonNegativeInteger ;owl:onProperty meas:measureOf

] .

L’instanciation des propriétés measureOf et hasUnitOfMeasure est rendue obliga-toire par l’indication de cardinalités avec le langage OWL (restriction cardinality). Deplus, l’intersection des restrictions sur l’unité et la variable mesurées va permettre, parinférence d’un raisonneur, de définir par restriction les éléments de la classe Measure-mentCharacteristic directement par les propriétés de l’instance. La figure 3.7 montrel’organisation des concepts, notamment la réutilisation de l’ontologie OUM 2 (Ontologyof Units of Measure) développée par mon équipe d’accueil et décrite par Rijgersberget al. (2010). L’utilisation de cette ontologie permet de déléguer le lien et la sémantiquede l’unité et de la variable et leur lien à l’ontologie importée. Seule la notion de devise,que nous avons ajoutée, manquait pour décrire les prix des produits. Enfin, l’utilisationde OUM permettra, dans le futur, de lier les autres applications basées sur OUM et no-tamment d’accéder facilement au Web Service de conversion d’unités 3. La figure C.1

2. Disponible à l’adresse http://www.wurvoc.org/vocabularies/om-1.6/3. Disponible à l’adresse http://www.wurvoc.org/services/oum.jsp

29

http://www.wurvoc.org/vocabularies/om-1.6/

http://www.wurvoc.org/services/oum.jsp


de l’annexe E représente les instanciations de l’exemple précédent grâce au concept deMeasurementCharacteristic.

FIGURE 3.7 – Concepts des caractéristiques mesurables

La sous-classe NutritiveCharacteristic de MeasurementCharacteristic possède égale-ment la propriété nutrient qui va nous permettre de modéliser les caractéristiques nutri-tives des produits. Le principe est le même que précédemment, sauf que la variable estdépendante du nutriment. Par exemple, la dose de sucre contenue dans la pomme est enfait une masse de sucre, l’annexe E, figure C.2, montre sa représentation. Pour gérer lasémantique du nutriment, nous avons réutilisé l’ontologie développée par mon équiped’accueil, qui est en fait une taxonomie des nutriments (cf. fig. 3.8).

L’ontologie développée ici, pour décrire les produits et leurs rôles dans le restau-rant, est faite en fonction des connaissances déjà disponibles dans le projet FOVEA etau RoF. Elle reste suffisante tant que le modèle n’est pas stabilisé mais devra évoluerassez rapidement dans un premier temps avec l’introduction de la notion d’ingrédients,puis dans un second temps avec l’annotation des produits par rapport à leurs origines etleurs sensations et structures gustatives.

30

3.3 Ontologies pour les préférences des consommateurs

FIGURE 3.8 – Extrait de la taxonomie des nutriments

3.3 Ontologies pour les préférences des consommateursL’objectif du projet est de proposer des conseils personnalisés aux consommateurs et

de les aider à faire les bons choix pour une alimentation adaptée. Ces conseils ou recom-mandations sont personnalisées en fonction des caractéristiques du consommateur et deses préférences. Dans le domaine applicatif de mon projet, une des originalités est detenir compte de ces préférences alimentaires. Ces connaissances alimenteront le modèlede conseils. Les recommandations produites porteront sur le contenu d’un menu maisaussi sur la forme du message.

La définition du modèle s’est faite en deux phases : la première assez générale, grâceà la littérature scientifique du domaine et la seconde plus "appliquée". Cette dernière estbasée sur nos trois profils et sur les données disponibles, à savoir :

– identité de la personne, accessible grâce à l’administration de l’institut,– résultat d’une enquête (mode de vie, interaction avec la nourriture, etc.),– goûts alimentaires au restaurant (historique des précédents repas).

Ainsi, plusieurs composants ontologiques ont été produits. Ils pourront être assemblés etcomplétés en fonction des besoins du modèle. La version intégrée dans la mise en oeuvredu prototype est plus légère et ne contient que l’extension de l’entité de la personne etles résultats de l’enquête.

La définition d’un consommateur est actuellement liée à son identité au sein del’établissement. Les données seront issues directement des bases de données de l’insti-tut. Par exemple, la figure 3.9 montre une instanciation du concept Consumer. John estdéfini par son identité : nom, prénom, année de naissance, numéro de carte d’employé.Ce sont des propriétés de type de données. Il est à noter que la classe Consommateur

31

est définie avec des restrictions sur la cardinalité exprimant le caractère obligatoire deces propriétés. Notamment le WURCardNumber, identifiant de l’employé à l’institut,est sous forme XML de type :< o w l : R e s t r i c t i o n >

< o w l : c a r d i n a l i t y r d f : d a t a t y p e =" h t t p : / /www. w3 . org / 2 0 0 1 / XMLSchema#n o n N e g a t i v e I n t e g e r ">1< / o w l : c a r d i n a l i t y >

< o w l : o n P r o p e r t y r d f : r e s o u r c e =" h t t p : / /www. wurvoc . o rg / r o f / consumer #hasWURCardNumber " / >

< / o w l : R e s t r i c t i o n >

FIGURE 3.9 – Description de John

Le choix alimentaire des consommateurs est un comportement complexe et sonétude est pluridisciplinaire (science du comportement, biologie et physiologie, économie,mercatique, sociologie et psychologie). Köster (2009) reprend, dans son article, l’ap-proche de Jos Mojet, experte en science des consommateurs à l’Institut de recherchede Wageningen, pour exprimer la complexité du domaine et les différents aspects. Elledécrit en 2001 (cf. annexe C) les différents facteurs qui influencent le comportement duchoix des consommateurs concernant l’alimentation. Nous avons adapté cette proposi-tion pour certains de nos composants ontologiques, puisqu’une partie correspond bienau domaine étudié dans le cadre des recherches menées au Restaurant du Futur.

Les aspects biologiques et physiologiques correspondent aux caractéristiques dela personne : physiques, génétiques, etc.. Au niveau modélisation, nous avons différen-cié les caractéristiques mesurables (taille, poids par exemple) des autres caractéristiques(sexe de la personne). De plus, la propriété d’objet hasPhysicalProperty, dérivée parla suite en fonction des différentes caractéristiques physiques de l’utilisateur permetd’une part, de pouvoir naviguer directement jusqu’aux caractéristiques physiques duconsommateur, d’autre part, de contrôler la signature de la relation (domaine et image)de chacune des sous-propriétés. Par exemple, listing 3.2, la propriété hasWeight possèdepour domaine un objet de type Consumer et d’image une instance de concept Weight.Enfin, ce choix de modélisation nous permettra de récupérer l’ensemble des propriétésphysiques par l’utilisation directe de la propriété mère, ce qui est utile dans le cas degénération d’interface.

32

3.3 Ontologies pour les préférences des consommateurs

Listing 3.2 – Code Turtle de la définition de hasWeightcons:hasWeight

a owl:ObjectProperty ;rdfs:domain cons:Consumer ;rdfs:label " has we i gh t " ^^xsd:string ;rdfs:range cons:Weight ;rdfs:subPropertyOf cons:hasPhysicalProperty .

Pour définir les mesures nous avons réutilisé la définition de MeasurementCharac-teristic, décrite dans le listing 3.1, qui va nous permettre de lier une variable, une unitéet une valeur. Pour l’instant, les principales variables physiques sont définies, à savoir :taille, poids et IMC. Nous les avons définies en plusieurs étapes. La définition en codeTurtle du listing 3.3 du concept de poids montre que nous avons créé, dans un premiertemps, une sous-classe du concept de mesure ; puis, nous avons affiné sa définition parrestriction à la mesure du poids oum :height et en rendant la date de mesure obligatoire.L’objectif ici était de faciliter l’acquisition des données puisque seule la déclarationd’une mesure de type Height est suffisante pour le raisonneur pour avoir le type devariable mesurée. De plus, il permet un contrôle plus fin des informations nécessairescomme dans le cas de la date et du poids.

Listing 3.3 – Code Turtle de la définition de Weightcons:Weight

a owl:Class ;rdfs:label " Weight@en " ^^xsd:string ;rdfs:subClassOf meas:MeasurementCharacteristic ;rdfs:subClassOf

[ a owl:Restriction ;owl:hasValue oum:weight ;owl:onProperty meas:measureOf

] ;rdfs:subClassOf

[ a owl:Restriction ;owl:cardinality " 1 " ^^xsd:nonNegativeInteger ;owl:onProperty meas:hasDateOfMeasure

] ;meas:measureOf oum:weight .

Les propriétés physiques de la personne dans notre cas sont les plus pertinentes, carelles suffisent aux diététiciens pour donner des premières recommandations. De ce fait,nous avons fait évoluer le concept de Consumer pour y ajouter des cardinalités plusprécises (cf. annexe F).

Les facteurs psychologiques et liés au contexte entrent aussi en compte lors duchoix des aliments. Il s’agit, par exemple, de la motivation, des habitudes alimentairesou de vie. Pour modéliser ces derniers, je me suis appuyée sur l’enquête faite auprès desconsommateurs du restaurant. Dans l’état actuel du projet, c’est l’une des sources im-portantes pour les chercheurs, puisque l’acquisition doit se faire le moins intrusive pos-sible pour ne pas influencer le comportement des consommateurs. L’enquête est donnée

33


en annexe A. Elle couvre également le domaine des facteurs contextuels, comme lecadre de vie. Au niveau modèle, nous avons défini des concepts, comme Household quireprésente le foyer de la personne (cf. annexe D, fig. D.1), lequel va être caractériségrâce à des propriétés par le nombre d’enfants, le statut marital, la localisation ainsi quepar les habitudes d’achats du foyer. Il s’agit du concept de ShoppingHabit qui permetde connaître le type d’aliments achetés (produits du commerce équitable par exemple),le type de magasin et la fréquence d’achat.Sur le même principe que précédemment, nous avons modélisé le concept de l’activitésportive d’une personne (cf. annexe D, fig. D.2) avec des propriétés d’objet pour le typede sport, la fréquence et le niveau.La modélisation de ces notions est faite sur le même principe : un élément central (Shop-pingHabit ou SportiveActivity ) lié par des propriétés (inShopOfType ou concerned-Sport) à des concepts de type (par exemple : les magasins d’alimentation FoodProduct-ShopType ou les types de sports disponibles Sport). L’avantage ici est que, si le besoinapparaît de définir plus finement les concepts des types de magasins ou les différentssports, nous pourrons faire évoluer facilement notre ontologie de base en créant ou im-portant de nouvelles connaissances produites par d’autres organismes comme la FAOpar exemple pour les magasins ou le lien vers une ontologie des sports.

La notion de régime alimentaire est un concept que nous avons commencé à représen-ter ici. D’autres ontologies et structures de connaissances existent mais restent bien sou-vent trop orientées vers le domaine de la santé par rapport au domaine du projet et tropcomplexes par rapport à nos besoins en matière de prototypage. L’idée ici était plutôtd’essayer de représenter le type de régime alimentaire souhaité par un consommateur,ainsi que ses objectifs. Pour débuter, nous nous sommes appuyés sur nos trois profils.Ce composant ontologique minimal fait intervenir plusieurs types de facteurs décrits etillustrés par Köster (2009). La figure 3.10 illustre cette modélisation. Un consommateurpeut avoir un ou plusieurs régimes alimentaires : DietPreference. Ce concept intègrela représentation d’une relation n-aire de propriétés d’objets. adviser représente celuiqui est à l’origine de cette préférence. En effet, à la base, le consommateur lui-mêmeveut suivre un régime particulier, par exemple "manger biologique". Le système/diététi-cien aura également un objectif pour le consommateur, par exemple un régime avec peud’hydrates de carbone. Le modèle devra ensuite gérer ces souhaits et ou ces conflits etproduire des conseils. La propriété reason et son image ReasonType correspondent à lanotion de facteur de motivation et de facteur contextuel socio-culturel (la religion ou ledésir de s’alimenter à partir des produits issus du commerce équitable par exemple). Ceconcept est associé au concept de niveau d’importance défini pour l’instant simplementpar ses instances :

Listing 3.4 – Code Turtle de la définition d’ImportanceLevel:ImportanceLevel

34

3.4 Ontologies de recommandations

a owl:Class ;rdfs:subClassOf owl:Thing ;owl:oneOf (:AbsoluteImportance :HighImportance :LowImportance :MediumImportance )

.

Un régime alimentaire préférentiel est aussi défini par un type de régime : DietType.Ce concept peut nous permettre de définir des régimes et est schématisé figure 3.11.Cette figure illustre qu’il est possible d’indiquer l’importance donnée au prix ou à l’en-vironnement dans ce type de régime. De plus, la propriété involved, définie listing 3.5,est spécialisée en sous-propriété avoided, favored, needed et prohibited. Ces propriétésvont permettre de définir les implications entre le régime et :

– un nutriment (de l’ontologie sur les nutriments), par exemple le régime "low_calory_diet"avoided energy ;

– un produit (du restaurant), par exemple le régime "without_tiramisu_diet" prohib-ited tiramisu ;

– un allergène (de l’ontologie Allergens 4)), par exemple le régime "peanut_intolerant_diet"prohibited Peanut ;

– une perception (de l’ontologie Sensory_and_structure 5)), par exemple le régime"chocolateFlavour_favored_diet" favored ChocolateFlavour.

Listing 3.5 – Code Turtle de la définition d’involved:involved

a owl:ObjectProperty ;rdfs:comment " i n v o l v e d p r o d u c t o r c h a r c a t e r i s t i c o f a p r o d u c t "@en ;rdfs:domain :DietType ;rdfs:label " i n v o l v e d "@en ;rdfs:range

[ a owl:Class ;owl:unionOf (:Characteristic allergens:Allergen nutri:Nutrient :Product

)] .

Ces composants ontologiques sur les consommateurs et les régimes alimentairesvont donc nous permettre de formaliser :

– l’identification du consommateur ;– ses caractéristiques biologiques et physiologiques ;– les aspects psychologiques liés à ses habitudes de vie ;– le régime alimentaire souhaité / nécessaire à la personne.

3.4 Ontologies de recommandationsDans notre projet, le Personal Eating Advisor Model, ou modèle de conseils, fournira

des "recommandations" (ou Requirements) offrant les fonctionnalités suivantes :

4. Ontologie développée par l’équipe IM-WUR : http ://www.wurvoc.org/allergens5. Ontologie développée par l’équipe IM-WUR : http ://www.wurvoc.org/sensory_and_structure

35


FIGURE 3.10 – Représentation de la préférence d’un régime alimentaire

FIGURE 3.11 – Représentation des types de régimes alimentaires

36


– conseiller ou éviter certains éléments du menu (produit, buffet ou catégorie),– cibler les caractéristiques pertinentes pour le consommateur (personnalisation du

contenu du message),– guider l’affichage des informations et conseils au niveau de l’interface utilisa-

teur(Smartphone).

Ne connaissant pas encore la forme de la sortie des "recommandations", j’ai choiside modéliser un composant ontologique permettant de formaliser les "recommanda-tions". Cette modélisation pourra ainsi utiliser les mêmes concepts (vocabulaire con-trôlé) définis précédemment pour les produits et les consommateurs. Les "recommanda-tions" ainsi modélisées seront utilisées pour exploiter les connaissances disponibles surle menu du jour et les produits et ainsi fournir les fonctionnalités attendues du modèlesde conseils.

FIGURE 3.12 – Ontologie pour décrire les conditions pour le repas

Pour la modélisation, je me suis appuyée sur les profils définis avec les chercheurset dégager les conditions types pouvant être fournies par le modèle de conseils. De plus,nous avons montré le scénario de John à une diététicienne qui a nous a donné le type deconseils diététiques qu’elle aurait pu prescrire.

37


Techniquement, l’idée est qu’en sortie du modèle de conseils, une instance du con-cept AdvisedLunch soit créée. Cette instance est composée de :

Une collection de conseils ou d’Advice La figure 3.12 montre que chacun des conseilspeut être isAdvised ou isAvoid. Ils peuvent concerner (relation concernType) unconcept de l’ontologie des produits, par exemple Product ou Category. Cette rela-tion a pour cible un objet OWL de type Class. Ce conseil peut respecter des con-ditions qui concernent des caractéristiques de l’élément : Requirement ou qui con-cernent des variables mesurées : MeasurementCharacteristic ou NutritiveCharac-teristic. La capture d’écran de l’éditeur TopBraid, figure 3.13, illustre la représen-tation de l’expression "John doit prendre des produits qui appartiennent à la caté-gorie des salades et qui ont la propriété d’avoir une présentation naturelle 6".

FIGURE 3.13 – Capture d’écran TopBraid, conseil pour John de prendre une saladefraîche

Une caractéristique pertinente pour le consommateur Il s’agit ici de définir une Mea-surementCharacteristic ou une NutritiveCharacteristic préférentielle pour John.Cette variable a pour portée le repas complet et peut être associée à des conditionsMeasurementCharacteristic ou NutritiveCharacteristic qui vont permettre d’ex-primer le fait par exemple que John ne devrait pas ingérer plus de 600 kcal durantson repas (cf. figure 3.14). Par la suite, nous verrons que cette caractéristique estaffichée en priorité et est associée à un traitement particulier dans l’applicationSmartphone.

6. Par opposition aux salades sous film disponibles au restaurant

38


FIGURE 3.14 – Recommandation globale d’un repas de 600 kcal maximum pour John(TopBraid)

La notion de tentation durant le choix des produits est associée au concept Tempta-tionMode. Il possède la propriété owl :oneOf contenant trois instances fullTemp-tation, moderateTemptation et freeTemptation.

Le mode d’affichage donné par le concept TypeOfDataDisplayAdvice va avoir des con-séquences pour l’application Smartphone. En ce qui concerne notre version, seulele mode rawData existe et est implémenté dans notre système.

Conclusion

Nous avons modélisé plusieurs composants ontologiques réutilisables, composablesd’ontologies locales (e.g. Measure) ou externes (e.g. OUM) et combinables en fonctiondes besoins afin d’avoir un ensemble de connaissances évolutives. Ces composants on-tologiques ont été modélisés à partir des données disponibles, par discussion avec lesexperts du domaine et de l’expertise de l’institut de recherche à travers la littératureproduites dans le domaine.

Trois principales structures ont étés produites et permettent de formaliser les con-naissances suivantes :

– le contexte du restaurant : le menu, les catégories, les buffets avec les ali-ments ou produits disponibles accompagnés de leurs caractéristiques (nutritive,prix, etc.) ;

39


– le consommateur : identité, caractéristiques physiques, éducation, habitude ali-mentaire, activité sportive, etc. ainsi que le régime alimentaire souhaité ou néces-saire ;

– les recommandations du modèle de conseils : collection de conseils permettantd’annoter les éléments du contexte du restaurant comme "conseillés" ou "à éviter",définition de caractéristiques pertinentes, le type de gestion de la tentation et lemode d’affichage conseillé.

La suite de ce document est consacrée à la mise en oeuvre opérationnelle de nosontologies à travers un environnement de connaissances. Son exploitation par la pre-mière version de notre prototype de diffusion de conseils alimentaires personnalisés estconsultable depuis une plateforme mobile type Smartphone.

40

Chapitre 4

Mise en œuvre au travers d’unearchitecture logicielle

Introduction

Des modèles de connaissances appropriés ont été définis (voir chapitre 3), afin desatisfaire les exigences fonctionnelles du système PEA (Personal Eating Advisor). Cesexigences portent sur l’apport de conseils alimentaires personnalisés et adaptés, auxconsommateurs du Restaurant du Futur. A cet effet, les modèles de connaissances con-struits, se consacrent à la représentation des aliments et des menus du jour proposés auxconsommateurs par le restaurant, ainsi qu’à la représentation du profil du consommateuret aux recommandations qui peuvent lui être faites en terme d’alimentation.

Il s’agit maintenant de proposer une mise en œuvre de ces modèles, de mettre enplace un prototype du système de diffusion de conseils alimentaires personnalisés, etainsi de valider notre approche, basée sur de la connaissance et sur les technologies duWeb sémantique. Le prototype à mettre en place, doit répondre à plusieurs contraintesimposées par le système PEA, et qui concernent la personnalisation du menu et dumessage diffusé, les feedbacks ou réactions du système et enfin la mobilité. Les solutionsapportées pour la prise en charge de ces contraintes sont détaillées ci-dessous :

La personnalisation du menu du jour nous oblige à considérer chaque consomma-teur de manière différente. L’idée retenue, est d’ajouter des annotations aux élémentsdu menu afin d’orienter ces éléments du menu vers des profils de consommateurs. Ainsipar exemple, une annotation qui a pour propriété le statut et comme domaine de valeurs("à éviter", avoid en anglais et "conseillé", advised en anglais), a été définie. La déter-mination du statut s’appuie sur les recommandations émises par le modèle de conseils(cf. sections 3.1 et 3.4).

41

Mise en œuvre au travers d’une architecture logicielle

La personnalisation du message diffusé permet de déterminer les informations quivont s’avérer pertinentes à afficher, ainsi que leur format d’affichage. Pour cette pre-mière version du prototype, nous nous sommes limités à une seule caractéristique per-tinente mesurable. La pertinence sera déterminée par la suite par le modèle de conseils.Toutefois, dans le cadre de notre prototype, la caractéristique considérée est paramétra-ble et manipulée à l’aide de l’ontologie des recommandations. De la même manière, leformat donné au message, sera, dans le futur, défini par le biais du modèle de conseils,mais demeure, pour cette version, limité à l’affichage des données de base (variable,valeur et unité).

Les réactions du système au choix des utilisateurs vont se traduire, pour notre proto-type, par l’implémentation de la notion de plateau virtuel. Cette fonctionnalité permettrad’avoir un retour global sur l’ensemble des produits choisis. L’utilisateur aura ainsi lapossibilité de simuler son repas et d’ajuster ses choix.

La mobilité est nécessaire pour que l’utilisateur puisse avoir l’information à disposi-tion alors qu’il est en train de faire son choix. Cet argument a joué en faveur du choixd’une plate-forme de consultation ordiphone, ou Smartphone en anglais.

La première section de ce chapitre est consacrée à la présentation générale de l’archi-tecture logicielle mise en place, et du processus de personnalisation. La section suivantetraite de la mise en oeuvre opérationnelle d’un système à base de connaissances (SBC),section 4.2. Puis les sections 4.3, 4.4 et 4.5 décriront, respectivement, la mise en oeuvrede la couche métier, la mise à disposition des ressources et l’application de consultationsur Smartphone.

4.1 Architecture du prototype PEA et démarche de per-sonnalisation

4.1.1 ArchitectureLe prototype mis en place, figure 4.1, est constitué de plusieurs éléments : un sys-

tème à base de connaissances, un module métier, un Web Service, et une application surSmartphone.

Système à base de connaissances (SBC) : son rôle est de permettre le stockage et l’-exploitation de nos connaissances. Il contient les composants ontologiques dévelop-pés (cf. section 3), une base de faits contenant les profils des consommateurs, ainsique les menus, les produits et leurs caractéristiques.

42

4.1 Architecture du prototype PEA et démarche de personnalisation

FIGURE 4.1 – Architecture générale du prototype

43


Module d’acquisition : son rôle est de convertir les données acquises sous formattexte, en faits. Ce module est un module annexe, qui permet d’alimenter la basede faits à partir d’informations émanant du restaurant

Modèle de conseils : son rôle va être d’interroger le SBC afin de consulter les connais-sances sur le consommateur et le menu du jour, puis de produire les recommanda-tions alimentaires personnalisées sur les produits qui vont influer la constitutiondu menu et l’affichage des informations associées. L’implémentation de ce mod-èle n’entre pas dans le cadre de mon stage.

La couche métier : est constituée de deux modules. Le premier module a pour but deconvertir nos connaissances en objets métiers, manipulables par les procéduresde création de menu. Le deuxième module a pour objectif de constituer à partirdu menu du jour un menu "métier" personnalisé pour un consommateur. Troisgrandes fonctionnalités sont nécessaires :– le marquage d’éléments du menu ou du contexte du restaurant (produit, caté-

gorie ou buffet) comme étant "conseillé" ou "à éviter" ;– la gestion de la caractéristique principale ;– la gestion de la tentation par suppression des produits considérés comme à

éviter ;– la gestion au niveau des classes métier du plateau virtuel de l’utilisateur.

Web Service : permet de mettre à disposition les informations sur le menu du jourfourni par le restaurant, comprenant également les produits figurant dans le menuet leurs caractéristiques. Pour un consommateur identifié, son menu "personnal-isé" est également restitué au travers du Web Service.

L’application Smartphone : est une application qui facilite la consultation du menuet gère la manière dont sont affichées les informations sur l’interface face auxrecommandations émises par le système.

4.1.2 Démarche de personnalisationNous avons séparé dans notre prototype, les connaissances, gérées par le SBC, les

traitements métiers développés sous forme de modules logiciels et l’interface de con-sultation (l’ordiphone). La démarche choisie, commence par fournir aux utilisateurs dusystème, un menu de base qui correspond plus précisémemt à celui du jour de la con-sultation. Ce menu consultable n’est donc pas immédiatement personnalisé, les donnéessont au format texte et la caractéristique pertinente est choisie par défaut pour le sys-tème, à savoir, la quantité de calorie d’un produit (exprimée en kilocalorie). L’idée estque lorsqu’un utilisateur "connu", pour lequel il existe un profil dans notre base de con-naissances, se connecte, le système :

1. crée un menu métier, identique au menu général par copie,

44

4.2 Mise en œuvre opérationnelle d’un système à base de connaissances

2. extrait de la base de connaissances les recommandations associées à l’utilisateur,

3. applique chacune des règles métiers : annotation (advised ou avoid) des élémentset gestion de la tentation,

4. prépare le message à diffuser en fonction de la caractéristique pertinente issue desrecommandations,

5. met en place, pour l’utilisateur, un objet métier correspondant à son plateau virtuel,concept de Tray dans notre projet, paramétré grâce aux recommandations (par ex-emple l’ingestion de 600 kcal par repas).

Nous avons choisi de modifier un objet métier plutôt que directement des connaissancescar certaines règles de personnalisation peuvent, par exemple, nécessiter des calculs.

Nous avons également choisi de gérer, autant que possible, les traitements métiersur le serveur et non pas sur l’application de consultation. Par exemple, le contenu duplateau virtuel est géré au niveau de l’application principale et non pas sur le Smart-phone. De cette manière, le déploiement de l’application, qui peut être distribué surplusieurs plateformes, va s’avérer facilité. Enfin la plate-forme de consultation aura toutde même la charge du mode d’affichage, la disposition des éléments sur l’interface,car ces derniers éléments demeurent très dépendants de la configuration des machinesclientes.

4.2 Mise en œuvre opérationnelle d’un système à basede connaissances

L’objectif principal d’un système à base de connaissances est d’exploiter des con-naissances d’un domaine, afin de permettre la résolution de problèmes pouvant êtrecomplexes dans le champ de ce domaine. Le Ber et al. (2006) précise cette définition enajoutant que ces connaissances doivent être de plus rendues disponibles et stockées à ceteffet. La mise en œuvre s’adosse alors à une architecture comprenant : une base de con-naissances relative au domaine, une base de faits ou données caractérisant le problème,et enfin un moteur d’inférence dont le rôle est de manipuler les bases pour conduire unraisonnement menant à la résolution d’un problème.

L’architecture proposée (figure 4.1 ) pour le prototype s’appuie sur le "framework"sémantique Sesame, voir section 2.1. Sesame va fournir les fonctionnalités nécessairesau stockage de triplets RDF ainsi que des librairies d’interrogation et de manipulationde ces triplets. Sesame va également fournir le raisonneur RDFS et OWL DLP avecl’extension OWLIM. Le choix de Sesame dans ce travail, est en accord avec la largeutilisation qui est faite de cet outil au sein de mon équipe d’accueil. Certains membresde l’équipe participent, d’ailleurs, activement à ses évolutions et enrichissements et ap-

45


partiennent à la communauté qui supporte ce projet de développement.

La mise en oeuvre du prototype s’articule autour de trois éléments d’importance quisont abordés dans le détail dans cette section, à savoir, un serveur de stockage RDF, unjeu de données venant alimenter le référentiel de connaissances et un module logicield’exploitation de la base RDF adossé à l’API Sesame et au langage SPARQL.

4.2.1 Vocabulaire partagéAfin de pouvoir exploiter dans l’application les concepts présents dans nos ontolo-

gies, nous avons défini un paquetage java structurant le vocabulaire de nos ontologies.Pour chaque composant ontologique utile, nous avons défini une classe qui est carac-térisé par des membres statiques comme l’espace de nom, le préfixe et les concepts,propriétés et instances remarquables, qui nous sont d’utilité. L’annexe H montre lareprésentation UML partielle de ce paquetage.

4.2.2 Serveur de stockage de données RDFNotre environnement de connaissances a pour élément central un serveur de base de

données RDF afin de donner plus de flexibilité au système. Il s’agit aussi d’en faciliterl’accès en mode distribué. Différents modules, notamment d’acquisition et de consul-tation de données vont pouvoir se partager les accès avec le serveur de triplets. Dansce sens, nous avons mis en place un moteur de servlets Tomcat, et nous avons définides servlets permettant la connexion avec la base de données construite sous Sesame.L’architecture retenue, nous donne également accès à une interface d’administration dela base, OpenRDF Workbench, qui s’avère très pratique en terme de fonctionnalités :interface d’interrogation, gestion et d’exploration du dépôt, etc..

4.2.3 L’acquisition de données RDF et la constitution du jeu de testsLes graphes RDF relatifs aux personnes ont été créés manuellement avec l’outilTopBraid. Nous avons instancié nos composants ontologiques des préférences des per-sonnes et des recommandations avec les scénarios de John, Wim et Esther.

Le graphe RDF du contexte et des produits du RoF est produit automatiquement,au travers d’un composant logiciel défini au sein de notre application (appelé toSesame,sur le schéma figure 4.1). Ce module défini en java permet l’instanciation du contextedu restaurant, des catégories et des buffets. Il permet également d’instancier, à partir defichiers textes dans un format propriétaire que nous avons nous même défini, les menus,par saison de trois mois et les produits disponibles avec toutes leurs caractéristiques, et

46

en particulier les caractéristiques nutritives. Cette deuxième phase est cependant semi-automatique, elle nécessite en effet une phase de validation et de consolidation, avec parexemple l’ajout d’un fichier d’illustration pour ce qui concerne les produits.

L’implémentation du composant logiciel Java de conversion est basée sur l’APISesame. La première étape est de créer un référentiel RDF, puis d’y ajouter les tripletscréés et enfin de l’exporter. La construction des triplets est basée sur la lecture desfichiers au format propriétaire. Un problème rencontré porte sur "l’éclatement" de l’in-formation, ce qui nous oblige à incrémenter dynamiquement le graphe des triplets, auregard des données déjà instanciées. Un exemple en est l’ajout du prix à un produit in-stancié au préalable, listings 4.1 et 4.2. Il s’agit, d’abord, d’identifier le produit dans legraphe RDF à l’aide de son identifiant (iddb) de base de données (cf. listing 4.1), Puis,listing 4.2, d’instancier une mesure du prix avec sa valeur et son unité et enfin de mettreen relation cette instance avec celle du produit.

Listing 4.1 – Recherche de l’instance de produitStringBuilder query = new StringBuilder ( ) ;query .append ( " SELECT ? prod " ) ;query .append ( " WHERE { " ) ;query .append ( " ? prod a <" + PROD .PRODUCT + "> . " ) ;query .append ( " ? prod <" + PROD .HAS_DATABASEID +"> \ " " + iddb + " \ " . " ) ;query .append ( " } " ) ;TupleQueryResult result = con .prepareTupleQuery (QueryLanguage .SPARQL , query .toString ( ) )

.evaluate ( ) ;

Listing 4.2 – Ajout du prix à un produiti f (idProd != n u l l ) { / / we found t h e p r o d u c t

i f ( !tokens [ 1 ] . trim ( ) .isEmpty ( ) && !tokens [ 1 ] . trim ( ) .equals ( " 0 " ) ) {/ / c r e a t e a RDF o b j e c tURI idMeasure = factory .createURI (PROD .NAMESPACE , " p r i c e _ "+idDBProduct ) ;/ / c r e a t e an i n s t a n c e o f t y p e M e a s u r e m e n t C h a r a c t e r i s t i ccon .add (idMeasure , RDF .TYPE , MEAS .MEASUREMENT_CHARACTERISTIC ) ;/ / add p r i c e t o p r o d u c t w i th t h e h a s M e a s u r e m e n t C h a r a c t e r i s t i c p r e d i c a tcon .add (idProd , MEAS .HAS_MEASUREMENT_CHARACTERISTIC , idMeasure ) ;/ / add t h e v a l u e o f p r i c econ .add (idMeasure , MEAS .HAS_NUMERICAL_VALUE , factory .createLiteral (tokens [ 1 ] . trim ( )

, XMLSchema .STRING ) ) ;/ / add v a r i a b l econ .add (idMeasure , MEAS .MEASURE_OF , PROD .COST ) ;/ / add u n i tcon .add (idMeasure , MEAS .HAS_UNIT_OF_MEASURE , PROD .EURO ) ; ;

}}

Notre environnement va donc contenir nos composants ontologiques ainsi que lesdonnées sous forme de graphes RDF provenant :

– de trois profils de consommateurs et leurs recommandations,– du contexte du restaurant : catégories, buffets et menu sur trois mois,

47


– de la liste des produits disponibles avec leurs caractéristiques.L’exploitation de la base RDF se fait grâce à l’API Sesame et au langage de requêtesSPARQL.

4.2.4 Des modèles de connaissances aux objets métiers : exploita-tion de SPARQL

Le module présenté, ici, est assujetti à l’exploitation de la base de connaissancesafin d’en créer des objets métiers. Notre démarche est de construire, au préalable, unmenu, vu comme un objet métier, qui sera consultable par tous les utilisateurs. Par lasuite, ce menu est personnalisé par la couche métier de notre système en fonction desrecommandations du modèle de conseils. La figure 4.2 correspond au diagramme declasses du module java développé.

Nous observons tout d’abord que, seul un sous-ensemble de concepts des com-posants ontologiques est représenté. En effet, nous avons besoin, sous forme d’ob-jet métier, du concept de consommateur, des concepts consultables par l’utilisateur, àsavoir, le contexte et les produits disponibles. De plus, certains composants ontologiques,non nécessairement consultables, servent à la sélection de produit. Enfin, certain con-cepts comme ceux des caractéristiques de produits sont regroupés. En effet, les carac-téristiques des produits représentées de manière hiérarchique dans l’ontologie (cf. sec-tion 3.2), ont été "aplaties vers le haut", c’est-à-dire que nous avons choisi de ne con-struire qu’une seule classe métier Characteristic. Nous n’avons pas besoin d’exploiterla spécialisation des concepts pour nos traitements et c’est ce qui explique ce choix quivise la simplicité de représentation.

Lien entre instances de concepts et d’objets métiers

Les objets métiers et les instances dans l’ontologie sont liés au travers de l’URIde l’instance RDF. Cette information est un identifiant unique dans les technologiesdéveloppées par le W3C. La classe abstraite RoFElement, cf. firgure 4.2, va fourniraux classes spécialisées un élément instance de concept de base. En effet, ils seront tousdéfinis par les attributs id pour l’URI de l’instance, name pour l’argument de l’instanceou instance sans espace de nommage et par un label attribué en fonction de la languechoisie.

Schéma de réutilisation et de paramétrage par spécialisation

Le schéma de conception des classes principales correspond à un schéma de réu-tilisation en programmation orientée objets. Il est basé, ici, sur la spécialisation et laredéfinition de méthodes.

48


FIGURE 4.2 – Diagramme de classes UML partiel du module métier : conversion RDFvers objets métier

49

Spécialisation de classes : la classe abstraite RoFElement va correspondre à une in-stance d’un concept RDF de base, par spécialisation les autres classes RoFCategory,RoFBuffet, RoFProduct et RoFMenu vont hériter de ces attributs et être enrichies. Pourcela, nous utilisons la méthode initRoFElement dans le constructeur de cette classe mèreafin de préparer le paramétrage des classes filles, voir listing 4.3.

Paramétrage par spécialisation : chaque sous-type de RoFElement va être paramétrégrâce à la méthode initRoFElement, définie comme abstraite dans la sur-classe RoFEle-ment et qui devra donc être implémentée dans chaque sous-classe. Cette méthode con-struit une requête SPARQL et interroge la base de données RDF avec l’API Sesame afinde compléter l’instance d’objet par les attributs propres à la classe, voir l’appel listing4.4.

Listing 4.3 – Code paramétrable : constructeur de la classe RoFElement/∗ ∗∗ From an URI , t h e o b j e c t i s i n i t i a l i z e by t h e ’ i n i t R o F E l e m e n t ’ which mean wi th Sesame

r e p o s i t o r y i n t h i s v e r s i o n . ∗ @param URI of t h e e l e m e n t .∗ /

p u b l i c RoFElement (URI id ) {s u p e r ( ) ;t h i s .id = id ;t h i s .name = t h i s .id .getFragment ( ) .toString ( ) ;t h i s . l a b e l = t h i s .searchLabel ( ) ;t h i s .initRoFElement ( ) ; / / p l u g i n a r c h i t e c t u r e A n n e

}

Listing 4.4 – Exemple de code paramétrant : méthode définie dans sa classe RoFCate-goryp u b l i c c l a s s RoFCategory e x t e n d s RoFElement imp lemen t s Comparable<RoFCategory> {

. . ./∗ ∗∗ I n i t i a l i z e t h e e l e m e n t from t h e Sesame r e p o s i t o r y wi th t h e u r i o f t h e o b j e c t .∗ /

p u b l i c vo id initRoFElement ( ) {i f ( t h i s .id != n u l l )

t r y {RepositoryConnection con = SesameForRoF .Instance ( ) .getSesame ( ) .getConnection ( ) ;/ / b u i l d s p a r q l que ryStringBuilder query = new StringBuilder ( ) ;query .append ( "SELECT ? l a b ? i c " ) ;query .append ( "WHERE { " ) ;query .append ( " OPTIONAL { <" + t h i s .getId ( ) +"> <"+ PROD .HAS_ICON +"> ? i c } . " ) ;query .append ( " OPTIONAL { <" + t h i s .getId ( ) +"> <" + RDFS .LABEL + "> ? l a b . " ) ;query .append ( " FILTER ( l a n g ( ? l a b ) = \ " " + ConfigRoF .LANGUAGE + " \ " ) } . " ) ;query .append ( " } " ) ;TupleQueryResult result = con .prepareTupleQuery (QueryLanguage .SPARQL , query .

toString ( ) ) .evaluate ( ) ;/ / r e s u l tList<String> reslib = result .getBindingNames ( ) ;i f (result .hasNext ( ) ) {BindingSet binds = result .next ( ) ;i f (reslib .contains ( " i c " ) && binds .getValue ( " i c " ) != n u l l ) t h i s .icon = new

RoFImage (binds .getValue ( " i c " ) .stringValue ( ) ) ;

50

i f (reslib .contains ( " l a b " ) && binds .getValue ( " l a b " ) != n u l l ) t h i s . l a b e l =binds .getValue ( " l a b " ) .stringValue ( ) ;

}. . .

} } }

Cette structure permet une réutilisation et une évolution future plus facile.

Traduction des relations belongsTo et aggregates

Les composants ontologiques de définition du RoF et des produits, cf. section 3.2,utilisent les propriétés inverses belongsTo et aggregates pour définir les relations entreles produits et les menus, les catégories et les buffets. Nous avons traduit cette notion deplusieurs manières, suivant les cas (cf. diagramme de classes figure 4.1) :

– par une composition la tentationla tentationla tentationproductsmenupour traduirequ’un menu est composé de produits, avec la relation productBelongsToMenu surle diagramme de classes ;

– par l’association belongsToCategory entre un produit et une catégorie ;– par l’association belongsToBuffet entre un produit et une buffet.

Les associations vont amener plus de flexibilité lors de la consultation des produits parcatégories et/ou buffets.

La classe RoFMenu joue également le rôle de gestionnaire du contexte du restaurantpar les deux autres compositions des classes RoFCategory et RoFBuffet qui apparaissentlors des menus. Une des raisons de ce choix de conception est que dans cette version duprototype, le menu est le point d’entrée pour la consultation des produits.

En raison du rôle de "conteneur" joué par le menu, nous avons choisi de gérer laprofondeur de conversion des objets Menu, mais aussi Product avec les caractéristiques,grâce à la méthode particulière buildItem. Elle va construire le produit et les menuscomplets c’est-à-dire, dotés de leurs composants (cf. exemple du listing 4.5).

Listing 4.5 – Extrait de la méthode buildItem de la classeRoFMenu/∗ ∗∗ Find a l l p r o d u c t s , c a t e g o r i e s , b u f f e t s a v a i l a b l e f o r a l u n c h i n t h e r e p o s i t o r y .∗ /

p u b l i c vo id buildItems ( ) {t h i s .products = new HashMap<URI ,RoFProduct> ( ) ;. . .RepositoryConnection con = SesameForRoF .Instance ( ) .getSesame ( ) .getConnection ( ) ;StringBuilder query = new StringBuilder ( ) ;query .append ( "SELECT ? prod ? b u f f ? c a t " ) ;query .append ( "WHERE { " ) ;query .append ( " ? prod a <" + PROD .PRODUCT + "> . " ) ;query .append ( " ? prod <" + PROD .BELONGS_TO + "> <" + t h i s .getId ( ) +"> . " ) ;. . .TupleQueryResult result = con .prepareTupleQuery (QueryLanguage .SPARQL , query .toString

( ) ) .evaluate ( ) ;w h i l e (result .hasNext ( ) ) {

. . .

51


RoFProduct prod = new RoFProduct ( new URI (bindingSet .getValue ( " prod " ) .stringValue ( ) )) ;

t h i s .products .put (prod .getId ( ) , prod ) ;. . .}

. . .

Pour résumer, nous avons donc mis en place un environnement de connaissancescomprenant :

– un serveur de base de données RDF Sesame, exploitable grâce à l’API Java Sesamefournissant également un système de raisonnement ;

– la définition de plusieurs composants ontologiques et des jeux de tests de con-sommateurs, menus, produits et caractéristiques ;

– un module de conversion d’objets RDF à des objets métiers java.

4.3 Personnalisation du menu du jour : RoFAdvisedMenu

Les développements précédents nous ont permis de mettre en place un environ-nement de connaissances et un module facilitant le passage d’instances RDF à des in-stances d’objets métiers. De ces développements, il en ressort la création, basée sur nosconnaissances, d’un menu complet (catégories, buffets, produits, caractéristiques). Nousallons maintenant nous intéresser à la personnalisation de ce menu pour un consomma-teur. Les trois profils d’utilisateur sont gérés par le SBC. A chacun d’eux sont associésdes recommandations (cf. section 3.4). La personnalisation du menu : annotation deséléments, personnalisation du message (contenu et forme), gestion de la tentation, estdécrite dans les parties suivantes, ainsi que la gestion du plateau virtuel.

4.3.1 Évolution du modèle d’objet métier

La figure 4.3 illustre les évolutions du diagramme de classes du module de créa-tion d’objets métier à partir de la base RDF. Les évolutions implémentent maintenantles premières règles métiers de la première version de notre prototype. Nous avons faitapparaitre le concept menu personnalisé avec la classe RoFAdvisedMenu. Cette classeest une spécialisation de la classe RoFMenu. Ce menu personnalisé est lié à un con-sommateur, qui va pouvoir personnaliser les éléments du menu (produits, catégories etbuffets), activer le processus de tentation et personnaliser le message diffusé en fonctionde la caractéristique pertinente pour l’utilisateur. De plus, les éléments personnalisablesont un nouvel attribut advised. Cet attribut peut contenir un entier correspondant à codedéfini dans la configuration du système : 1, conseillé ; -1,à éviter et 0, pas d’indication.Enfin, nous avons une classe Tray représentant le plateau virtuel de l’utilisateur.

52


FIGURE 4.3 – Diagramme de classes UML partiel du module métier : personnalisation

53

4.3.2 Gestion des conseils et des recommandations

Quand un utilisateur, dont le profil existe dans notre base RDF est instancié, une in-stance de la classe RoFAdvisedMenu est créée. Celle-ci est initialisée, à l’image du menudu jour général. Lors de l’initialisation de l’objet métier du consommateur, l’attributforAdvisedLunch va être lui-même initialisé avec l’URI correspondant à une instanceRDF AdvisedLunch, concept central de l’ontologie des recommandations (cf. section3.4). Pour rappel, ce concept est constitué d’une collection de conseils permettant d’an-noter les éléments du contexte du restaurant comme "conseillé" ou "à éviter", d’unedéfinition de caractéristiques pertinentes, du type de gestion de la tentation et du moded’affichage conseillé. L’idée ensuite est d’exploiter ce "lien" vers les recommandationspour l’utilisateur pour appliquer les fonctionnalités de personnalisation du menu (anno-tation, tentation et message personnalisé), sans avoir à créer d’objet métier correspon-dant aux recommandations mais s’en servir, par contre, pour sélectionner les élémentsdans la base RDF. Techniquement, on va être amené à créer des requêtes SPARQL dy-namiques en fonction des recommandations.

4.3.3 Annotation advised et avoid

Au départ, l’objet menu consacré à l’utilisateur est le même que le menu général,sans personnalisation. Il contient tout les objets métiers produits, catégories et buffetsdisponibles ce jours là au RoF. La méthode setAdvisementConcept(URI typeOfAdvise,int adviseValue) va en fonction du type de conseil, donnée dans l’ontologie par les re-lations (isAdvise ou isAvoid) récupérer tous les conseils (instances du concept Advice)et construire la requete SPARQL permettant, pour chaque conseil, de récupérer l’URIdes produits à annoter en fonction du type de relation visée. Si nous prenons l’exemplede John, la figure 4.4 illustre le fait que John a trois conseils alimentaires dont un con-cerne un élément du menu à éviter (isAvoid) et deux autres permettront d’indiquer leséléments considérés comme bénéfiques (isAdvised) et d’annoter comme tels nos objetsmétiers correspondants. Le listing 4.6 donne le code java permettant de sélectionner cesconseils.

Listing 4.6 – Extrait de la méthode setAdvisementConcept - construction d’une requêteSPARQL pour récupérer les instances d’Advicep u b l i c vo id setAdvisementConcept (URI typeOfAdvise , i n t adviseValue ) {. . .RepositoryConnection con = SesameForRoF .Instance ( ) .getSesame ( ) .getConnection ( ) ;/ / g e t a d v i s e d p r o d u c t e l e m e n t w i t h o u t measurement r e q u i r e m e n tStringBuilder query = new StringBuilder ( ) ;query .append ( "SELECT ? c t y p e ? advElem ? r e q " ) ;query .append ( "WHERE { " ) ;query .append ( " <" + t h i s .forAdvisedLunch + "> <" + typeOfAdvise + "> ? advElem . " ) ;query .append ( " ? advElem <" + ADV .CONCERN_TYPE + "> ? c t y p e . " ) ;query .append ( " ? advElem <" + ADV .HAS_REQUIREMENT + "> ? r e q . " ) ;

54

FIGURE 4.4 – Conseils pour John (TopBraid)

query .append ( " OPTIONAL { ? advElem <" + ADV .HAS_MEASUREMENT_REQUIREMENT + "> ?mr } ." ) ;

query .append ( " FILTER ( ! bound ( ?mr ) ) . " ) ;query .append ( " } " ) ;query .append ( "ORDER BY ? advElem " ) ;

. . .}

La deuxième étapes est la sélection des produits à annoter en fonction de la relationrecherchée. Pour continuer notre exemple, nous allons nous intéresser à un des conseilspour John, illustré par la figure 4.5. Ce conseil est donné pour des éléments de menude type Product, donné par la relation concernedType. Ce conseil est constitué de Re-quirement qui doivent tous être satisfait et permettent de sélectionner les produits. Icile premier Requirement indique que le produit appartient à la catégorie des soupes, ledeuxième que cette soupe doit être de type bouillon. L’extrait de la méthode setAdvise-mentConcept, listing 4.7, montre la création de la requête SPARQL en fonction des ré-sultats de la précédente. Chaque Requirement est traduit pas des instructions SPARQLde sélection et ajouter au précédent (connecteur logique AND, OR entre Advice). Ladernière instruction assigne à l’attribut advised du produit métier un entier traduisantpour le cas de John que le produit est conseillé.

Listing 4.7 – Extrait de la méthode setAdvisementConcept suite - construction d’unerequête SPARQL pour récupérer les instances de produit et annotationp u b l i c vo id setAdvisementConcept (URI typeOfAdvise , i n t adviseValue ) {. . .w h i l e (advElem != n u l l ) {

/ / new p r o d u c t t o f i n di f ( !ctype .contentEquals (ctypeOld ) | | !advElem .contentEquals (advElemOld ) ) {query = new StringBuilder ( ) ;query .append ( "SELECT ? prod " ) ;query .append ( "WHERE { " ) ;

}/ / r ema ined r e q u i r e m e n t t o addquery .append ( " { " ) ;

55


FIGURE 4.5 – Conseils concernant les soupes pour John (TopBraid)

56

query .append ( " ? prod a <" + ctype + "> . " ) ;query .append ( " <" + req + "> <" + ADV .HAS_INSTANCE_VALUE + "> ? i v a l " + i + " . " ) ;query .append ( " <" + req + "> <" + ADV .CONCERN_OBJECT_PROPERTY + "> ? oprop " + i + " .

" ) ;query .append ( " ? prod ? oprop " + i + " ? i v a l " + i + " . " ) ;query .append ( " } " ) ;query .append ( " UNION " ) ;query .append ( " { " ) ;query .append ( " ? prod a <" + ctype + "> . " ) ;query .append ( " <" + req + "> <" + ADV .HAS_INSTANCE_VALUE + "> ? i v a l " + i + " . " ) ;query .append ( " FILTER ( ? prod = ? i v a l " + i + " ) . " ) ;query .append ( " } " ) ;. . ./ / a n n o t a t i o nprodResult = con .prepareTupleQuery (QueryLanguage .SPARQL , query .toString ( ) ) .evaluate ( )

;w h i l e (prodResult .hasNext ( ) ) {prodBinds = prodResult .next ( ) ;URI prod = new URI (prodBinds .getValue ( " prod " ) .stringValue ( ) ) ;/ / t h e p r o d u c t i s a v a i l a b l ei f (products .containsKey (prod ) ) products .get (prod ) .setAdvise (adviseValue ) ;

. . .}}

Ce processus d’annotation peut s’effectuer également sur d’autre concepts commeles catégories ou des buffets.

4.3.4 Gestion de la tentation

La tentation est traduite dans l’ontologie des recommandations par un mode de ten-tation. Trois modes sont proposé dans notre prototype :

fullTemptation tous les produits conseillé ou pas sont visibles ;

moderateTemptation les produits déconseillés sont éliminés des produits visibles parle consommateur ;

freeTemptation seul les produits considérés comme bénéfiques sont laissé, tous lesautres, ceux considérés comme néfastes ou ceux dont on n’a pas fixé d’infor-mation sont supprimés du menu personnalisé.

Le mode de tentation est donné par l’ontologie des recommandations, pour John ils’agit du mode fullTemptation, donc les éléments ne sont pas supprimés. La figure 4.6schématise la formalisation de la tentation pour John.

Cette règle métier est implémentée par la fonction processTemptation() qui récupèreen premier le mode de tentation dans la base, puis suivant les modes de tentation vasupprimer de l’objet métier AdvisedMenu les éléments non souhaitable d’être mis àdisposition.

57


FIGURE 4.6 – Mode de tentation pour John (TopBraid)

4.3.5 Caractéristique pertinenteDans notre prototype, une seule caractéristique est traitée comme pertinente et sera

affichée en priorité, notamment un produit est associé à une seule information dansl’affichage et qui correspond à cette caractéristique. Par défaut, la caractéristique dedéfinie dans la configuration du système est l’énergie en kilo-calorie que peut fournir unaliment. Pour un menu à personnaliser, elle est formalisée avec l’ontologie des recom-mandations. Pour John, c’est aussi l’énergie qui est la caractéristique la plus pertinenteà afficher pour lui (cf. figure 4.7). Par contre pour Wim, c’est la quantité de vitamineet pour Esther le prix des aliments. Cette caractéristique peut donc être également unmesure nutritive.

FIGURE 4.7 – Caractéristique pertinent à afficher pour John (TopBraid)

Au niveau implémentation des objets métier, l’attribut firstMeasurement de type

58


URI, va correspondre à l’instance du type de mesure préféré par le consommateur. Parexemple, pour John on aura http://www.wurvoc.org/rof/johnTheDieter#john_preferedTypeOfMeasurement.Cet attribut est initialisé par les objets métiers par la fonction d’initialisation de l’objet.Ceci implique également un traitement spéciale pour cette caractéristique, qui est sélec-tionnée parmi toutes celles accompagnant le produit.

4.3.6 Gestion du plateau virtuel

Un utilisateur "connu" va avoir la possibilité de gérer un plateau virtuel. Pour cela,le type Tray a été défini. Il y a une relation d’agrégation entre produits et plateau. Unattribut de type Tray existe pour un consommateur, cf. diagramme de classe 4.3. Il estintéressante de remarquer que les recommandation définies au niveau du menu vont êtreservir à le paramétrer au niveau de la consultation et de paramétrer les réactions dusystème. Par exemple, une des recommandations de John (recommandation Rec. 6, cf.chapitre 1.1) de la part de la diététicienne, dit que son repas global ne doit pas dépasserplus de 600 kcal. Celle-ci est traduite dans notre ontologie (cf. figure 4.8) et sera ex-ploiter pour le plateau qui correspond au repas global. Cette exploitation, au niveau de lacouche métier de notre prototype, va consister à indiquer des propriétés pour le plateau.La gestion de l’affichage est laissé à l’application Smartphone. Au niveau implémen-tation, cette caractéristique globale est de type RoFCharacteristic est initialisée de lamême manière que les autres, par contre la gestion de ces caractéristiques se fait dansla classe RoFAdvisedMenu qui a pour attribut advisedMenuMeasurement, une structurede données (HashMap), issue de la relation de composition qui existe entre les typesRoFCharacteristic et RoFAdvisedMenu, voir diagramme de classes figure 4.3.

Pour résumer, la personnalisation du menu et les règles métiers sont gérées à par-tir du module java développé précédemment (voir section 4.2.4). Il est basé sur unearchitecture de réutilisation par spécialisation et paramétrable grâce à des requêtes d’in-terrogation SPARQL. L’évolution de ce module, va permettre de faire apparaitre lestypes RoFAdvisedMenu et RoFTray, attribut d’un consommateur, permettant respec-tivement la gestion de menu personnalisé, sur lequel on va pouvoir appliquer les règlesmétiers implémentées et la gestion du plateau virtuel. Les règles métiers implémentéessont : marquage des éléments (produit, catégorie ou buffet complet) comme considéréscomme bénéfiques ou néfastes au consommateur, personnalisation du message avec lasélection pour chaque produits des informations concernant une seule variable perti-nente, gestion de la tentation par suppression des produits visibles en fonction d’undegrés de liberté.

Ces objets ainsi construits vont être ensuite mis a disposition à travers une architec-ture distribuée afin d’être consultés grâce a une application sur Smartphone.

59

http://www.wurvoc.org/rof/johnTheDieter#john_preferedTypeOfMeasurement


FIGURE 4.8 – Recommandation globale d’un repas de 600 kcal maximum pour John(TopBraid)

4.4 Web ServiceLe système de diffusion a certaines exigences dont la consultation des menus et

produits, avec leurs caractéristiques, sur des plateformes mobiles. Pour répondre à cebesoin, nous avons mis en place une architecture distribuée, basée sur un Web Service.

En effet, les caractéristiques des Web Services ont orienté notre choix :– interaction entre systèmes hétérogènes, distants, avec couplage faible ;– utilisation des protocoles internet, notamment le protocole standard HTTP ;– échange de message XML possible ;– utilisation de clients légers possibles, type navigateur web.

En effet, il existe une grande variation de plateformes clientes de type ordiphone, etqui possède des caractéristiques matérielles, des systèmes d’exploitation et des langagesde programmation d’application différents, cas iPhone et Windows Phone par exemple.

L’architecture de services Web choisie est REST (voir section ). Ce choix a été faiten fonction de plusieurs critères :

– léger car basé uniquement sur le protocole HTTP, et donc moins de complexitéengendrée par l’utilisation des différents intermédiaires des architectures SOAPpar exemple ;

– architecture orientée ressources par rapport à une architecture basée sur les traite-ments ;

60

4.4 Web Service

– interface d’accès et de manipulation des ressources uniformes : GET, POST,DELETE du protocole HTTP ;

– possibilité, dans une version future, d’améliorer les interactions entre la base dedonnées RDF, Sesame, et un Web Service type REST par des extensions disponiblede Sesame.

Pour implémenter cette architecture, nous avons utilisé de le framework Open SourceRestlet, écrit en Java. Il correspondait bien à nos besoins : filtres d’accès aux ressourcesbasés sur XPath, support de représentation XML, extension permettant de déployer rapi-dement une application Restlet sur les téléphones mobiles Google Android.

Dans cette section est décrite l’implémentation de l’application est basée sur unearchitecture REST et permet la diffusion de ressources : les menus avec leur composition(produits, catégories, etc. mais aussi images).

Format d’échange

Nous avons choisi d’utilisé un format utilisant le langage XML pour communiquerentre le serveur et la plateforme mobile. Le listing 4.8 illustre un exemple de représen-tation XML permettant de décrire la catégorie "fruit" d’un menu.

Listing 4.8 – Extrait de représentation XML d’un menu< r o f >

<menu>http: / / www .wurvoc .org /rof /product#menu20100730<name>menu20100730< / name>< l a b e l >menu20100730< / l a b e l ><dateOfMenu>2010−07−30< / dateOfMenu>< c a t e g o r i e s >

< c a t e g o r y >http: / / www .wurvoc .org /rof /product#fruit. . .

http: / / www .wurvoc .org /rof /product#appel. . .

http: / / www .wurvoc .org /rof /product#dessertsAndJuicesBuffet< q u a n t i t i e s >

< q u a n t i t y >kilocalorie (mean ) < v a l u e >98 ,74 < / v a l u e >< v a r i a b l e >energie< / v a r i a b l e >http: / / www .wurvoc .org /vocabularies /om−mc−1.6 /energy

< / q u a n t i t y >. . .

< / r o f >

Ces données sont produites par notre module métier, en effet chaque classe im-plémente la fonction toXML qui produit un élément de type XML correspondant à la

61


description de son type et de ses attributs (cf. extrait du diagramme de classes, figure4.9). Cette implémentation est facilité par la spécialisation. Chaque élément de base vaavoir un identifiant, id, correspondant à l’URI de l’objet métier et instance RDF, ainsiqu’un label pour l’affichage dans la bonne langue et un nom.

FIGURE 4.9 – Extrait du diagramme de classes du module métier

La structure des données XML correspond à la structure arborescente de consul-tation du menu. Dans notre prototype nous avons implémenté la consultation du menugénérale par : "menu/catégorie/produit/caractéristiques". Dans le cas d’un menu person-nalisé, elle se fait par : "utilisateur/identifiant/menu/catégorie/produit/caractéristiques".Le plateau virtuel est consultable par "utilisateur/identifiant/plateau". Cette structurecorrespond vraiment à un consultation de ressources.

Application Restlet

Les classes développées à l’aide du framework Restlet sont données par la figure4.10. La classe LunchAtRoFApplication est la classe mère de l’application, elle va gérerles ressources. Pour cela, elle possède des attributs consumer et menu. Le premier estune collection java (ConcurrentMap) permettant de gérer les accès concurrents aux don-nées contenues. C’est une map associant l’identifiant d’un utilisateur, son numéro d’em-ployé, à une instance de type RoFConsummer. Ainsi chaque instance de consommateurdu système est géré par cette structure. L’attribut menu, correspond au menu du jourgénéral. Chaque menu est mis à jour automatiquement par le système, qui vérifie lesdates des menus de la consommation du service Web.Cette classe définie également, les routes ou chemins d’accès aux ressources. Le list-

ing 4.9 illustre plusieurs définitions de lien entre un chemin d’accès à une ressource

62

4.4 Web Service

FIGURE 4.10 – Diagramme de classes du Web Service

63


et une classe ressource (cf. figure 4.10). Certains chemins sont paramétrables par desfiltres, chaîne de caractères variable entre accolades. Par exemple, le paramètre wuriddu chemin "/user/wurid/tray" permet de sélectionner en fonction de l’identifiant le bonconsommateur et ensuite son plateau virtuel.

Listing 4.9 – Extrait de la classe LunchAtRoFApplication - initialisation des cheminsd’accès aux resources/∗ ∗ C r e a t e s a r o o t R e s t l e t t h a t w i l l r e c e i v e a l l incoming c a l l s . ∗ /@Overridep u b l i c s y n c h r o n i z e d Restlet createInboundRoot ( ) {

/ / C r e a t e a r o u t e r R e s t l e t t h a t d e f i n e s r o u t e s .Router router = new Router (getContext ( ) ) ;/ / De f in e a r o u t e w i t h o u t a d v i c e t o t h e menurouter .attach ( " / menu / " ,RoFMenuRessource . c l a s s ) ;. . ./ / De f in e a r o u t e f o r t h e r e s o u r c e " l i s t o f c a t e g o r i e srouter .attach ( " / menu / c a t e g o r i e s " , RoFCategoriesResource . c l a s s ) ;. . ./ / De f in e a r o u t e f o r t h e r e s o u r c e " l i s t o f c h a r a c t e r i s t i c s o f one p r o d u c trouter .attach ( " / menu / c a t e g o r i e s / { categoryName } / { productName } " , RoFCategoriesResource

. c l a s s ) ;. . ./ / De f in e a r o u t e f o r t h e r e s o u r c e " c l i e n t " and h i s menu ( da t e , i d )router .attach ( " / u s e r / { wur id } / menu " , RoFUserAdvisedMenuResource . c l a s s ) ;. . ./ / d e f i n e a r o u t e f o r t h e r e s o u r c e " c l i e n t " and h i s t r a y c o n t e n trouter .attach ( " / u s e r / { wur id } / t r a y " , RoFUserTrayResource . c l a s s ) ;. . .r e t u r n router ;

}

Méthodes implémentées : GET, PUT et DELETE

Chaque classe ressource est chargée de fournir des représentations de ressources,représentations XML pour nous, mais aussi d’y appliquer des traitements :

– GET : envoi de la représentation au format souhaité, par exemple la représentationXML d’un menu ou des catégories d’un menu ;

– DELETE : suppression d’un élément d’une représentation, par exemple un produitdu plateau ;

– POST : ajout d’un élément à une ressource, par exemple un produit au plateau.La signification de ces méthodes sont définies dans la norme RFC2616 de HTTP1.1 (cf.Fielding et al. (1999)).

Avant d’exécuter une des trois méthodes désignées ci-dessus, une méthode d’ini-tialisation du framework Restlet est exécutée automatiquement. Nous l’avons redéfinieafin de traiter les filtres et ainsi sélectionner les bonnes ressources ou objets métiers. Lelisting 4.10 montre l’implémentation de la méthode GET de la classe ressource gérantle plateau virtuel d’un consommmateur.

64

4.4 Web Service

Listing 4.10 – Extrait de la classe RoFUserTrayResource - implémentation de la méth-ode GET pour le plateau virtuelp u b l i c c l a s s RoFUserTrayResource e x t e n d s RoFElementResource {. . ./∗ ∗∗ R e t u r n s a d e s c r i p t i o n o f t h e r e s o u r c e t r a y∗ /

@Get ( " xml " )p u b l i c Representation toXml ( ) {

/ / G e n e r a t e t h e r i g h t r e p r e s e n t a t i o n a c c o r d i n g t o i t s media t y p e .t r y {

DomRepresentation representation = new DomRepresentation (MediaType .TEXT_XML ) ;

/ / G e n e r a t e a DOM document r e p r e s e n t i n g t h e consumerDocument doc = representation .getDocument ( ) ;

Element rElem = doc .createElement ( " r o f " ) ;doc .appendChild (rElem ) ;

Element eCons = doc .createElement ( " consumer " ) ;rElem .appendChild (eCons ) ;t h i s .consumer .toXml (doc , eCons , f a l s e ) ;eCons .appendChild ( t h i s .consumer .getAdvisedMenuToXml (doc , f a l s e ) ) ;eCons .appendChild ( t h i s .consumer .getTray ( ) .getTrayToXml (doc , f a l s e ) ) ;

doc .normalizeDocument ( ) ;

/ / R e t u r n s t h e XML r e p r e s e n t a t i o n o f t h i s document .r e t u r n representation ;

} c a t c h (IOException e ) {e .printStackTrace ( ) ;

}r e t u r n n u l l ;

}. . .}

Serveur d’images

Dans notre projet, chaque élément du menu est associé à une illustration. Pour met-tre à disposition ces images, nous avons ajouter un serveur de fichiers statiques à notreapplication. Nous avons utilisé pour cela le framework Restlet qui gère la notion derépertoire dédié et correspond à un accès vers un répertoire de notre serveur où se trouvestockées les images. Les images seront donc accessible pas leur nom.

Nous avons donc mis en place un Web Service REST, basé sur le framework JavaRestlet, permettant :

– de produire sous forme XML, la représentation des menus, des catégories demenu, des produits par catégories, des caractéristiques par produit, etc. ;

65


– de donner accès par un système d’adresses paramétrables, à des ressources per-sonnalisées ;

– de gérer l’ajout et la suppression de produit dans le plateau virtuel d’un consom-mateur ;

– de mettre à disposition les illustrations d’éléments de contexte du restaurant.

La suite du document est consacrée à l’application de consultation du Smartphone.

4.5 Application sur SmartphoneLe rôle de l’application ordiphone est essentiellement un l’affichage du menu. Sonbut est de permettre au consommateur de consulter son menu personnalisé par notresystème suivant les recommandations du modèle PEA. Dans l’architecture du systèmemis en place, nous avons essayé de limiter le plus possible les traitements effectuéspar l’ordiphone, le but étant de rester le plus possible souple face à l’hétérogénéité dumarché et des différents types de d’ordiphone.

Les cas d’utilisation utilisateur sont décrits par le diagramme UML figure 4.11. Pourrésumer, depuis son terminal mobile, l’utilisateur doit avoir accès aux fonctionnalitéssuivantes :

– consultation du menu : les catégories, les produits avec leurs détails,– consultation et gestion d’un plateau virtuel du repas,– enregistrement de l’application auprès de notre système.

Parmi ces fonctionnalités, la manière d’afficher les informations va rester sous la respon-sabilité du concepteur de l’application Smartphone. En effet, un jeu de méta-donnéesproduit par le PEA va fournir la manière dont il est souhaitable que les informationssoient affichées, par exemple les données brutes vs histogramme de la valeur nutrition-nelle des aliments. Dans ce prototype, seul le mode d’affichage "données brutes" estimplémenté.

Vues de l’application

La navigation entre les pages peut être schématisée grâce au diagramme UML d’ac-tivité fig. 4.12.

La partie vue de l’application est écrite avec le langage de balises XAML et le codejoint en C#.Il y a trois types de pages :

– les pages de registration et de bienvenue ;

66

4.5 Application sur Smartphone

FIGURE 4.11 – Diagramme des cas d’utilisation de l’application smartphone67


FIGURE 4.12 – Diagramme de navigation de l’application smartphone.Les recommandations WP7 impliquent : (i) depuis chaque page, l’application peut êtrestoppée (ii) le bouton "BackKey" permet de remonter l’historique de navigation, depuisn’importe quelle page, jusqu’à la page de démarrage

68

– les pages de consultation du menu, au nombre de trois :– la liste des catégories,– la liste des produits pour une catégorie,– le détail d’un produit avec ses principales caractéristiques et sa localisation dans

le restaurant ;– la page du plateau virtuel contenant une liste de produits.

L’utilisateur du Smartphone est représenté par la classe User, visible sur le dia-gramme de classes (figure 4.14) des principales vues. Chacune des classes contient unepropriété User. Cet objet correspond à l’objet RoFConsumer du module métier du sys-tème de diffusion et au concept Consumer de l’ontologie. Dans le cas de l’utilisateur, laliaison entre ces concepts dans l’ensemble du système, se fait grâce au numéro d’em-ployé du consommateur. Il va nous permettre de pouvoir accéder à la ressource per-sonnel sur le système de diffusion, voir section 4.4 sur le Web Service et l’accès aumenu personnalisé. Par exemple, l’url http ://www.wur.nl/LunchAtRoF/user/11090/traypermet d’obtenir la ressource correspondant au plateau virtuel de l’utilisateur dont l’i-dentifiant est 11090.

La fonctionnalité de Registation traite le cas de la première utilisation de l’appareil,et permet, après saisi du numéro d’employé wurid, de céer un espace de stockage isolé 1

et persistant au niveau de l’application. Cet espace stocke alors les paramètres utilisa-teurs nécessaires à la connexion au Web service.

Les classes CategoriesPage, CategoryPage et ProductDetailPage permettent respec-tivement d’afficher les catégories disponibles pour un menu, les produits disponiblespour une catégorie et les caractéristiques d’un produit donné. La classe TrayPage permetd’afficher la liste des produits contenus dans le plateau du consommateur ainsi qu’unbilan d’une propriété pertinente pour lui comme par exemple la somme des calories desproduits. L’exemple de code XAML, listing 4.11, créé un template qui, associé par laliaison de données {Binding Products} d’une collection en C#, va pour chaque élémentde la collection créer un nouvel item. La figure 4.13 montre le résultat obtenu pour uneliste de produits, des fruits.

Listing 4.11 – Code XAML - liaison de données avec une liste< Lis tBox I t e m s S o u r c e =" { Bind ing P r o d u c t s } " H o r i z o n t a l A l i g n m e n t =" S t r e t c h " Margin="

2 , 9 2 , 0 , 5 2 " Name=" LBProducts " V e r t i c a l A l i g n m e n t =" S t r e t c h " >< Li s tBox . I t emTempla t e >

< DataTempla te >< S t a c k P a n e l O r i e n t a t i o n =" H o r i z o n t a l " He igh t =" 72 " >

1. Isolated Storage en anglais est un système de fichier virtuel mis à disposition pour stocker lesdonnées des applications Silverlight. cf. http://msdn.microsoft.com/en-us/library/ff402541%28VS.92%29.aspx

69

http://msdn.microsoft.com/en-us/library/ff402541%28VS.92%29.aspx

http://msdn.microsoft.com/en-us/library/ff402541%28VS.92%29.aspx


FIGURE 4.13 – Smartphone - liste de fruits

70

< Rad ioBu t ton C o n t e n t =" " GroupName=" T r a y P r o d u c t s " Gr id . Row=" 1 " He ig h t =" 58 "H o r i z o n t a l A l i g n m e n t =" L e f t " Margin=" 0 , 0 , 0 , 0 " Name=" { Bind ing Id } "V e r t i c a l A l i g n m e n t =" Top " Checked=" RBSelec t_Checked " Width=" 64 " MinHeight=" 20 "MinWidth=" 20 " / >

<Image Source =" { Bind ing ImageUrl } " He igh t =" 58 " Width=" 77 " V e r t i c a l A l i g n m e n t =" C e n t e r" Margin=" 0 , 0 , 0 , 0 " / >

< S t a c k P a n e l Width=" 290 " He i gh t =" 72 " V e r t i c a l A l i g n m e n t =" S t r e t c h " >< Tex tBlock Text =" { Bind ing Labe l } " V e r t i c a l A l i g n m e n t =" Top " TextWrapping=" Wrap "

F o n t S i z e =" 25 " Foreg round =" White " Fon tFami ly =" Segoe WP" Margin=" 4 , 0 , 0 , 0 " / >< Tex tBlock Text =" { Bind ing F i r s t C h a r a c t } " V e r t i c a l A l i g n m e n t =" Top " TextWrapping="

Wrap " F o n t S i z e =" 18 " Foreg round =" White " Fon tFami ly =" Segoe WP" Margin=" 6 , 0 , 0 , 0" / >

< / S t a c k P a n e l ><Image He i gh t =" 30 " V i s i b i l i t y =" { Bind ing IMGK ook Vis i b i l i t y } " Width=" 30 "

H o r i z o n t a l A l i g n m e n t =" L e f t " Source =" { Bind ing IMGKookSource} " Name="IMGKook"V e r t i c a l A l i g n m e n t =" C e n t e r " / >

< / S t a c k P a n e l >< / Da taTempla te >

< / L i s tBox . I t emTempla t e >< / L i s tBox >

La liaison de donnée permet la mise à jours automatique de la vue. Pour cela, àchaque contexte de données de vue est associé un modèle de présentation que nousavons créé. Par exemple, au contexte de données de la vue TrayPage est associé lemodèle de présentation TrayViewModel.

Le modèle de présentation de l’application

Le "Modèle de présentation" a un rôle de liaison entre les vues et les données (lemodèle). Les données sont reçues par consommation du Web Service de notre système,sous forme de chaîne de caractères au format XML. La gestion du modèle dans notreconception va être géré directement par le modèle de présentation. Par exemple, l’in-stanciation du modèle de présentation du plateau virtuel, TrayViewModel, va impliquerles tâches suivantes :

– création d’un client web et envoie au Web Service, une requête GET sur le ressourcecorrespondante au plateau de l’utilisateur ;

– une fois le téléchargement des résultats effectué, parsage de la chaîne de carac-tères de réponse avec l’API LINK to XML et initialisation du modèle de présenta-tion ;

– utilisation des évènements, disponible en C#, afin de gérer les autres attributsdépendant du modèle.

Dans le cas, du plateau virtuel, nous avons développé les méthodes permettant de sup-primer (DELETE) et ajouter (POST) des éléments à la ressources RoFTray de notresystème.

Notons que nous avons choisi de faire appel au Web Service à chaque changementde vue, et non pas de charger la structure complète du menu au départ. Ce choix a été

71


FIGURE 4.14 – Diagramme de classes des vues

72


fait car un des scénarios, à développer dans une future version, prévois que les conseilsévoluent en fonction de chaque choix de l’utilisateur, ce qui impliquera de un recalculedu menu personnalisé.

Le diagramme de classes des modèles de présentation, figure 4.15, est proche desautres modèles développés dans notre prototype par les classes créées. Par contre, lesrelations entre elles sont plus forte car on utilise la composition de catégories dans unmenu, de produits dans une catégorie et le plateau, de caractéristiques dans un produit.La conséquence est que la structure est moins souple mais correspond au modèle denavigation défini (cf. figure 4.12)

Par rapport à l’ontologie de départ, nous n’avons utilisé que les concepts nécessairesà l’application Smartphone comme Category et Product. Ces concepts vont correspon-dre directement à deux classes du même nom. Comme pour le module de la couchemétier, une classe Item a été définie. Elle est composée de trois attributs dont id pourl’URI. L’attribut label de l’objet correspond à la chaîne de caractères, à afficher dansla langue souhaitée et name correspond à l’argument de l’URI. L’URI va permettre delier les objets (catégorie, produit, caractéristique, unité, etc.) à travers l’architecture dusystème de connaissances jusqu’au Smartphone. De plus il permet d’identifier et desélectionner des objets et ainsi de naviguer à travers les ressources (catégories, produits,etc.), tant au niveau de l’application Smartphone que du Web Service.

73


FIGURE 4.15 – Diagramme de classes de l’application Smartphone

74

Chapitre 5

Conclusion

A l’heure actuelle un environnement démontrant la faisabilité de l’approche estopérationnel sous forme de prototype et en cours d’expérimentation approfondie. Cetenvironnement intègre des composants ontologiques réutilisables, évolutifs et assem-blables en fonction des besoins. Ils permettent de formaliser les deux grands domainesnécessaires au projet, à savoir :

– le contexte du Restaurant du Futur : les menus avec leurs produits, leurs carac-téristiques et leurs valeurs nutritionnelles ;

– le consommateur : ses propriétés physiques et physiologiques, son de mode vieavec la description de son foyer et son type d’activité sportive, ainsi que ses ob-jectifs diététiques personnels.

Un troisième composant ontologique a été conçu pour modéliser les recommandationsdu modèle de conseils. De nouveaux modules ontologiques sont en préparation. Ce tra-vail a nécessiter d’aborder de nombreux sujets, au niveau de la conception d’ontologie,mais surtout celui du domaine pluridisciplinaire d’application : comportement du con-sommateur, nutrition, alimentation...

L’architecture informatique mise en place permet d’exploiter l’environnement deconnaissances et de mettre à disposition des consommateurs des menus accompagnésde conseils alimentaires personnalisés en fonction du menu du Restaurant du Futur.

Une application Smartphone a été développée sur Windows Phone 7, tournant actuelle-ment sur un émulateur, une des prochaines étapes est de la tester sur un appareil réel(date de sortie officielle octobre 2010). Mais dores et déjà, elle permet de tester plusieursscénarios et les trois profils. Le système a déjà permis de rajouter des recommandationsfacilement et de faire évoluer la complexité des conseils.

Au terme de ce stage, nous pouvons considérer que les objectifs initiaux ont étéatteints. Ils ont permis la rédaction d’un article, soumis en juillet, à une revue hollandaisedédiée à l’informatique pour l’agronomie.

Ce travail a été réalisé durant une période de cinq mois en Hollande, le premier moisa consisté en l’étude des besoins. Il a permis de proposer différents scénarios d’utilisa-

75

Conclusion

tion et de fonctionnalités de l’applications. Ce premier mois a conduit à la réalisationdes trois profils de consommateur, qui ont été validés avec les experts en science duconsommateur et de la nutrition lors de plusieurs présentations. Les deux mois suivantsont été consacrés à la modélisation des composants ontologiques, et à la constitution desjeux de test complets. Le mois suivant a été réservé à la conception et à l’implémenta-tion du système à base de connaissances, de la base du module métier et à la mise enplace du web service. Le dernier mois m’a permis de concevoir et d’implémenter l’ap-plication sur Smartphone et l’intégration des règles métiers au système. Le déroulementn’a pas été aussi linéaire, car la démarche a nécessité beaucoup d’aller retour entre lesdifférents modèles.

Au niveau personnel, ce stage m’a permis de découvrir un autre pays, d’autres habi-tudes alimentaires, de vie et de pouvoir améliorer mon anglais. Au niveau profession-nel, j’ai eu la chance d’intégrer une équipe de pointe dont les thématiques de recherchesappliquées m’intéressent vraiment et qui ont déjà amené à des réalisations logiciellesfonctionnelles. De plus, cela m’a permis de découvrir un autre mode de fonctionnementet de vision de la recherche en informatique appliquée. A cela s’ajoute que le domained’application correspond bien avec celui l’INRA, ou je travaille. Ce stage a permis deconsolider des collaborations entre les deux équipes et qui vont pouvoir évoluer.

L’étape suivante est la réalisation d’un module avancé de conseils, avec mise enplace d’un moyen permettant de combiner et donner la raison des différents conseils.En effet, plusieurs critères entrent en jeu (végétarien et calorie par exemple). Le modulede réaction du système au choix du l’utilisateur, basé sur la géo-localisation des produitsdans le restaurant, reste à faire évoluer. Au niveau scientifique, le modèle de conseils,actuellement en cours de création par les chercheurs en science du consommateur etde la nutrition, est à finaliser. L’interaction avec notre composant ontologique pour lareprésentation des recommandations sera alors a adapter. Au niveau de l’architecture, defuturs développements devront être prévus pour l’intégration de ce modèle de conseils.L’intégration devrait être facilitée par l’utilisation de la méthodologie objet, des patronsde conception qui apportent une souplesse à l’application.

Ce travail ouvre des perspectives de recherche par exemple, sur l’évolution dy-namique des ontologies en fonction du comportement de l’utilisateur et de ses réactionsaux conseils donnés, à différents pas de temps, y compris en temps réel. Une autre per-spective a trait à l’amélioration de la communication entre les différents modèles : deconnaissance, métier et consultation.

76

Bibliographie

Allaire J. (2002). Macromedia flash mx—a next-generation rich client. Macrome-dia white paper. Disponible à l’adresse http://download.macromedia.com/pub/flash/whitepapers/richclient.pdf.

Berners-Lee T., Hendler J. & Lassila O. (2001). The semantic web. Scientific American,284(5), 34–43.

Broy M., Deimel A., Henn J., Koskimies K., Plášil F., Pomberger G., Pree W., Stal M.& Szyperski C. (1998). What characterizes a (software) component ? Software -Concepts & Tools, 19, 49–56. 10.1007/s003780050007.

Charlesworth A. (2009). The ascent of the smartphone. Engineering & technology,4(3), 32–33.

Fielding R. (2000). Architectural Styles and the Design of Network-based Software Ar-chitectures. Thèse de doctorat, University of California, Irvine. Disponible à l’adressehttp://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.

Fielding R., Gettys J., Mogul J., Frystyk H., Masinter L., Leach P. & Berners-LeeT. (1999). Hypertext transfer protocol – http/1.1 (rfc 2616). Request For Com-ments. Available at http://www.ietf.org/rfc/rfc2616.txt, accessed7 July 2006.

Gruber T. (2009). Ontology. Ling Liu and M. Tamer Özsu (Eds.), Springer-Verlag.

Köster E. (2009). Diversity in the determinants of food choice : A psychological per-spective. Food Quality and Preference, 20(2), 70 – 82. European Conference onSensory Science of Food and Beverages 2006, European Conference on Sensory Sci-ence of Food and Beverages 2006. Disponible à l’adresse http://www.sciencedirect.com/science/article/B6T6T-4R5F002-2/2/9d36c0f3b95469e3d29887be9a49dfb9.

Le Ber F., Lieber J. & Napoli A. (2006). Les systèmes à base de connaissances.Dans Encyclopédie de l’informatique et des systèmes d’information, réd. J. Akoka& I. Comyn Wattiau, pp. 1197–1208. Vuibert. Disponible à l’adresse http://hal.inria.fr/inria-00201566/PDF/sbc-vuibert-06.pdf.

77

http://download.macromedia.com/pub/flash/whitepapers/richclient.pdf

http://download.macromedia.com/pub/flash/whitepapers/richclient.pdf

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

http://www.sciencedirect.com/science/article/B6T6T-4R5F002-2/2/9d36c0f3b95469e3d29887be9a49dfb9

http://www.sciencedirect.com/science/article/B6T6T-4R5F002-2/2/9d36c0f3b95469e3d29887be9a49dfb9

http://hal.inria.fr/inria-00201566/PDF/sbc-vuibert-06.pdf

http://hal.inria.fr/inria-00201566/PDF/sbc-vuibert-06.pdf

BIBLIOGRAPHIE

Manola F. & Miller E., (Réd.) (2004). RDF Primer. W3C Recommendation. WorldWide Web Consortium. Disponible à l’adresse : http://www.w3.org/TR/rdf-primer/.

Mcguinness D.L. & van Harmelen F. (2004). OWL web ontology language overview.W3C recommendation, W3C. Disponible à l’adresse : http://www.w3.org/TR/owl-features/.

Noy N. & Mcguinness D. (2001). Ontology development 101 : A guide to creating yourfirst ontology. Rap. Tech..

Noy N. & Rector A. (2006). Defining n-ary relations on the semantic web. W3C WorkingGroup Note. Disponible à l’adresse http://www.w3.org/TR/swbp-n-aryRelations.

Odell J. (1998). Six different kinds of composition. Advanced Object-Oriented Anal-ysis and Design Using UML. Disponible à l’adresse http://www.conradbock.org/compkind.html.

Prud’hommeaux E. & Seaborne A. (2008). SPARQL Query Language for RDF. W3CRecommendation. Disponible à l’adresse : http://www.w3.org/TR/rdf-sparql-query/.

Psyché V., Mendes O. & Bourdeau J. (2003). Apport de l’ingénierie ontologique auxenvironnements de formation à distance. Revue des Sciences et Technologies de l’In-formation et de la Communication pour l’Education et la Formation (STICEF), 10,89–126. Disponible à l’adresse http://sticef.univ-lemans.fr/num/vol2003/psyche-06s/sticef_2003_psyche_06s.htm.

Rector A. & Welty C. (2005). Simple part-whole relations in owl ontologies. W3CWorking Draft. Disponible à l’adresse http://www.w3.org/2001/sw/BestPractices/OEP/SimplePartWhole/index.html.

Rijgersberg H., Wigham M. & Top J. (2010). How semantics can improve engineer-ing processes : A case of units of measure and quantities. Advanced EngineeringInformatics. Accepted.

Segaran T., Taylor J. & Evans C. (2009). Programming the Semantic Web. O’Reilly,Cambridge, MA.

Stubenitsky K., Aaron J., Catt S. & Mela D. (2000). The influence of recipe modificationand nutritional information on restaurant food acceptance and macronutrient intakes.Public Health Nutrition, 3(02), 201–209.

78

http://www.w3.org/TR/rdf-primer/

http://www.w3.org/TR/owl-features/

http://www.w3.org/TR/owl-features/

http://www.w3.org/TR/swbp-n-aryRelations

http://www.conradbock.org/compkind.html

http://www.conradbock.org/compkind.html

http://www.w3.org/TR/rdf-sparql-query/

http://sticef.univ-lemans.fr/num/vol2003/psyche-06s/sticef_2003_psyche_06s.htm

http://sticef.univ-lemans.fr/num/vol2003/psyche-06s/sticef_2003_psyche_06s.htm

http://www.w3.org/2001/sw/BestPractices/OEP/SimplePartWhole/index.html

http://www.w3.org/2001/sw/BestPractices/OEP/SimplePartWhole/index.html

Annexes

79

Annexe A

Questionnaire pour les consommateursdu RoF

81

��

��

��

��

��

��

��

��

��

�

�

��

�

�

��

��

��!"�#��#��

��$��%�� &��#��

��%��%� �

'��

��$��(��%��)�� $� ��%��

��

�

��

�

�

��

�

�

*�

+��,� �-

� ��

�

��

�

.�

��-

� ��

�

��

�

/�

��-

� ��

�

��

�

0�

'��$��-

� ��

�

��

�

�

��

�

�

1�

+�� -

� ��

�

��

�

!�

��2��3-

� ��

�

� � � �

��

��

� ��

��

�� 4��(��

&��5��

,��

��$��%��)��

��

��

��

6��(��

7��(��

5� ��(��

8��%��

��

��

��

��

�� !"��

��

��#�� $� � ��

�

��9��

�� %� ��%

��

��)��

�� )�%��$�� $��

�

��!��"#��$��%��&��

��'��(�)*�+��,

��

�

:�

��2��3-

� ��

�

��

�

�

��

�

�

;�

��<�

�� 2��=%�� 6�3 -

� ��

�

��

�

>�

�� ?-

�

�6��2 ��)��@)��3

�4+

&4+

4+

74+

��

�

��

�

*"�� ?-

� ��

�

��

�

�

��

�

�

**�� ?-

�

��

��%��

��)��

%�� A�2��3��)�� >

%�� A��)��B�>��

��

��

�

��

�

*.��C�� 2�� 3?-

� ��

�

��

�

*/�5�%� ��%��?-

� ��

�

��

�

�

��

�

�

*0�5�%�� 2%��3?-

� ��

�

� � � � � �

��

�

*1�8��/��)�%�� 2�� 3?-

� ��

�

��

�

�

��

�

�

*!�� )��$� �� )��2�� 3?-

�

��

��%��

��

��

��

��

4��

��

��

��

�

4��

��

��

�

8��

��

��

�

��

��

��

�

&��)��

��

��

�

7��

��

��

�

��

�

��

�

*:�5�%�� $�� D�� ?-

�

��%��

��

��

��

��

��

�

��

�

�

��

�

�

*;��%��A-

�

��(��

��

�(��

��

�(��

��

�

E��

��

��

��

��

��

��

��

��

��

8��

��%��

��

��

��

��

�

8� ��%

��

��

��

��

�

8��8� ��%

%�� )�8

%��

��

��

��

�

8��

��

��

��

��

7��

��%��

��

��

��

�

�� )�8

%��%��

��

��

��

�

8��

��8��

�� $��

��

��

��

�

8��

��$��

�� 8�%��

��

��

��

��

�

8�%��

��

��

��

��

��

�

8��%

��

��

��

��

��

�

��

�

�

��

�

�

*>�(�� %�� ?-

�E��

��

4��

9��

F��

��

�

��

� � � � � �

�

."�8�� )� ��?-

�E��

��

4��

9��

F��

��

�

��

�

.*�(�� %�� ?-

�E��

��

4��

9��

F��

��

�

��

�

..�8��%��)� �� ?-

�E��

��

4��

9��

F��

��

�

��

�

�

��

�

�

./�(�� %�� ?-

�E��

��

4��

9��

F��

��

�

��

�

.0�8�� )� ��?-

�E��

��

4��

9��

F��

��

�

��

�

.1�5�%�� $�� $��%��?-

�E��

��

4��

9��

F��

��

�

��

�

.!�(�� %��?-

�E��

��

4��

9��

F��

��

�

��

�

�

��

�

�

.:�8�� )� �� ?-

�E��

��

4��

9��

F��

��

�

��

�

.;�(�� %��$� �� %�?-

�E��

��

4��

9��

F��

��

�

��

�

.>�(��

��%�� ?-

�E��

��

4��

9��

F��

��

�

� � � �

��

�

/"�8�� )� ��%�?-

�E��

��

4��

9��

F��

��

�

��

�

�

��

�

�

/*�(�� %��?-

�E��

��

4��

9��

F��

��

�

��

�

/.�(��%

�� %

��?-

�E��

��

4��

9��

F��

��

�

��

�

//�8��%��$��)� �� $�� ?-

�E��

��

4��

9��

F��

��

�

��

�

/0�(�� %��?-

�E��

��

4��

9��

F��

��

�

��

�

�

��

�

�

/1�(�� $�� ?-

�E��

��

4��

9��

F��

��

�

��

�

/!�8��)� �� ?-

�E��

��

4��

9��

F��

��

�

��

�

/:��

��)� ��%�� ?-

�E��

��

4��

9��

F��

��

�

��

�

/;�(�� %�� )�%�� ?-

�E��

��

4��

9��

F��

��

�

� � � � � �

��

�

�

��

�

�

/>�(�� ?-

�E��

��

4��

9��

F��

��

�

��

�

0"�(�� $�� $��?-

�E��

��

4��

9��

F��

��

�

��

�

0*�(�� %��%��%��?-

�E��

��

4��

9��

F��

��

�

��

�

0.�8��%��$��G)� �� $�� ?-

�E��

��

4��

9��

F��

��

�

��

�

�

��

�

�

0/�(�� %��?-

�E��

��

4��

9��

F��

��

�

��

�

00�5�%�� $��%

��

��$��%

��%��?-

�E��

��

4��

9��

F��

��

�

��

�

01�(��)�%��?-

�E��

��

4��

9��

F��

��

�

��

�

0!�(�� %��$�� ?-

�E��

��

4��

9��

F��

��

�

��

�

�

��

�

�

0:�5�%�� $��%��%��?-

�E��

��

4��

9��

F��

��

�

� � � �

��

�

0;�(�� %�� ?-

�E��

��

4��

9��

F��

��

�

��

�

0>�(��%��%��%��?-

�E��

��

4��

9��

F��

��

�

��

�

1"�(�� %�� ?-

�E��

��

4��

9��

F��

��

�

��

�

�

��

�

�

1*��

�� ?-

�E��

��

4��

9��

F��

��

�

� �

��

��

��

��!�!��!�"#�$�%�� !�� !��&��!��'�(��

Annexe B

Analyse : scénarios et domaines desontologies

87

The

onto

logi

es

Ann

eTi

reau

Mar

ch,2

9th

2010

Tabl

ede

smat

ière

s

1So

me

scen

ario

sfor

the

appl

icat

ion

51.

1Sc

enar

io1

:Joh

nth

edi

eter

..

..

..

..

..

..

..

..

..

..

..

..

51.

2Sc

enar

io2

:Wim

the

spor

tsm

an.

..

..

..

..

..

..

..

..

..

..

61.

3Sc

enar

io3

:Est

hert

heen

viro

nmen

talis

t.

..

..

..

..

..

..

..

..

61.

4Fe

edba

cksc

enar

ios

..

..

..

..

..

..

..

..

..

..

..

..

..

..

7

2D

eter

min

eth

edo

mai

nof

the

onto

logi

es13

2.1

Pers

onal

prop

erty

..

..

..

..

..

..

..

..

..

..

..

..

..

..

.13

2.2

Con

sum

erho

useh

old

..

..

..

..

..

..

..

..

..

..

..

..

..

.13

2.3

Con

sum

erac

tivity

..

..

..

..

..

..

..

..

..

..

..

..

..

..

.13

2.4

Pers

onal

traj

ecto

ryab

outf

ood

..

..

..

..

..

..

..

..

..

..

..

142.

5C

onsu

mer

beha

viou

r.

..

..

..

..

..

..

..

..

..

..

..

..

..

142.

6C

onsu

mer

with

food

/hab

its.

..

..

..

..

..

..

..

..

..

..

..

142.

7A

tthe

rest

aura

nt.

..

..

..

..

..

..

..

..

..

..

..

..

..

..

.15

2.8

Food

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

152.

9Ty

peof

Feed

back

..

..

..

..

..

..

..

..

..

..

..

..

..

..

.16

3Im

port

antt

erm

sin

the

onto

logy

173.

1A

bout

Food

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

173.

2A

bout

Con

text

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

.17

3.3

Abo

utob

ject

ive/

traj

ecto

ry.

..

..

..

..

..

..

..

..

..

..

..

.18

3.4

Abo

utPr

efer

ence

..

..

..

..

..

..

..

..

..

..

..

..

..

..

.18

3.5

Abo

utPr

ofile

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

.18

3.6

Abo

utPe

rson

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

.19

3.7

Abo

utTy

peO

fFee

dbac

k.

..

..

..

..

..

..

..

..

..

..

..

..

.19

3

Cha

pitr

e1

Som

esc

enar

iosf

orth

eap

plic

atio

n

1.1

Scen

ario

1:J

ohn

the

diet

er

John

isa

mal

e,50

year

sold

and

1.80

met

erta

ll(F

ig.1

.1).

He

wor

ksin

the

Info

rmat

ion

Man

agem

ent

team

,in

fron

tof

his

scre

enal

lth

eda

yan

ddo

esn’

ttr

avel

alo

t.H

e’s

are

gula

rcus

tom

erof

the

Res

taur

anto

fthe

Futu

re(R

oF),

sinc

ehe

eats

atle

ast4

days

per

wee

k.H

ene

ver

com

esat

the

rest

aura

ntw

ithan

exte

rnal

food

.He

has

rare

lyw

orki

nglu

nch,

buth

eea

tsof

ten

with

the

mem

bers

ofhi

ste

am.J

ohn

isn’

tasp

orts

man

and

heliv

esto

ofa

rfr

omhi

sw

ork

toco

me

with

abi

ke,s

ohe

com

esby

car.

His

BM

Iis

abou

t30

,so

heha

sto

loos

ew

eigh

tand

that

’sw

hyhe

has

apa

rtic

ular

less

calo

rie

diet

.The

prob

lem

isth

atJo

hnis

gree

dyan

dis

used

toch

oose

swee

tco

urse

,he

alw

ays

take

sa

dess

ertt

ofin

ish

his

lunc

h.

FIG

UR

E1.

1–

John

’sca

se

5

Som

esc

enar

iosf

orth

eap

plic

atio

n

Dur

ing

the

wee

kJo

hn’s

eate

nat

the

Res

taur

anto

fthe

Futu

re.W

ear

eW

edne

sday

and

sow

ekn

oww

hath

eat

eth

ela

st2

days

(Tab

.1.1

).W

eal

sokn

owof

wha

this

lunc

his

com

pose

dfr

omth

ebe

ginn

ing

ofhi

sco

min

gin

the

RoF

.

TAB

LE

1.1

–Jo

hn’s

lunc

hM

onda

yTu

esda

yJu

ice

&Sm

ooth

ies

Milk

&fr

uit

Milk

&fr

uit

Fres

hmad

eSo

upSo

epB

ospa

dden

stoe

len

Soep

chin

ese

groe

nten

Bre

ad&

Bak

e-of

fsB

olza

chtw

itB

olza

chtw

itH

otm

eals

&sn

acks

Bam

iori

enta

lFr

ikan

del

Des

sert

&Ju

ices

Mon

okw

ark

aard

beiP

erz-

Mar

acM

ono

dess

ert

Cof

fee

&Te

aca

ppuc

cino

1.2

Scen

ario

2:W

imth

esp

orts

man

Wim

isa

mal

e,26

year

sold

and

he’s

1.92

met

erta

ll.H

ew

orks

inth

eV

isio

nte

amfr

om1

year

now

.His

wor

kis

stre

ssfu

lbec

ause

heha

sjus

tbeg

una

stat

e-of

-the

-art

proj

ectw

itha

loto

fpr

essu

re.B

utW

imlik

eco

mpe

titio

n.T

hat’s

why

heha

sne

vert

hele

ssch

osen

tow

ork

inpa

rttim

e(7

0%)s

ince

heca

nde

vote

alo

toft

ime

toFo

otba

ll,hi

spr

efer

red

spor

t.T

hus

Wim

play

sin

the

amat

eur

cham

pion

ship

.Thi

sye

arhi

ste

amha

sev

ery

chan

ceto

win

the

cham

pion

ship

whi

chw

illbe

gin

in2

mon

ths

only

.So,

heha

sdo

uble

dal

lhi

str

aini

ng.O

fcou

rse

heal

soco

ntin

ues

toco

me

bybi

cycl

eto

his

wor

k:6

0km

ever

yda

ys.

And

tota

keno

chan

ces,

he’s

deci

ded

tore

spec

tapa

rtic

ular

spor

tive

diet

,with

the

help

ofR

oFA

dvis

eApp

s,to

bein

grea

tsha

pedu

ring

the

cham

pion

ship

!Cur

rent

lyW

imdo

n’t

have

any

heal

thpr

oble

m.H

e’s

notp

artic

ular

lydi

fficu

ltup

onfo

od,h

elik

essn

ack

food

,be

caus

era

pidl

yea

ten

and

note

xpan

sive

.He

does

n’tl

ike

big

orof

ficia

llun

ch.

From

the

begi

nnin

gof

the

wee

kW

imha

sea

ten

atth

eR

esta

uran

toft

heFu

ture

.We

are

Wed

nesd

ayan

dso

we

know

wha

the

ate

the

last

2da

ys(T

ab.1

.2).

We

also

know

ofw

hath

islu

nch

isco

mpo

sed

from

the

begi

nnin

gof

his

com

ing

inth

eR

oF.

1.3

Scen

ario

3:E

sthe

rth

een

viro

nmen

talis

tE

sthe

ris

afe

mal

e,39

year

sol

dan

dhe

’s1.

72m

eter

tall.

She

issl

iman

din

good

heal

th.T

heon

lypr

oble

mis

that

she’

sto

mat

oin

tole

ranc

e.W

hati

sre

ally

impo

rtan

tfor

heri

s"t

osa

veth

ew

orld

",sh

e’s

ahu

man

istp

erso

nan

dso

,she

wan

tsth

em

osts

heco

uld

eato

rgan

ic,f

air-

trad

eor

anim

al-f

rien

dly

food

.She

isve

ryca

refu

llyof

wha

ther

eat.

She

wor

ksw

ithJo

hnan

dco

me

ever

yda

yto

the

RoF

.She

ofte

nco

mes

with

her

own

food

,

6

1.4

Feed

back

scen

ario

s

TAB

LE

1.2

–W

im’s

lunc

hM

onda

yTu

esda

yJu

ice

&Sm

ooth

ies

Mel

k1/

4lit

erM

elk

1/4

liter

Sala

dsR

auw

kost

/sal

adeb

arm

idde

lH

otm

eals

&sn

acks

Bro

odje

hotd

ogPi

zza

Turk

seD

esse

rt&

Juic

esB

anaa

nL

emon

ades

Spri

tefle

sje

drin

km

osto

ften

(fru

itju

ice

orw

arm

tea)

.Lik

ea

loto

fwom

ensh

elo

ves

choc

olat

ean

dsh

eof

ten

give

sin

the

tem

ptat

ion

tota

kech

ocol

ate

dess

erto

rwar

mch

ocol

ate

atth

een

dof

the

lunc

h,ev

enif

she

has

eate

non

e’s

fill.

She

mak

esa

bits

port

sth

ew

eeke

nd(h

ike

inth

ena

ture

)and

she

com

esev

ery

days

with

herb

icyc

le(a

gain

stth

epo

llutio

nof

cour

se).

Dur

ing

the

wee

kE

sthe

r’s

eate

nat

the

Res

taur

anto

fth

eFu

ture

.We

are

Wed

nesd

ayan

dso

we

know

wha

tshe

ate

the

last

2da

ys(T

ab.1

.3).

We

also

know

ofw

hath

erlu

nch

isco

mpo

sed

from

the

begi

nnin

gof

herc

omin

gin

the

RoF

.

TAB

LE

1.3

–E

sthe

r’s

lunc

hM

onda

yTu

esda

yJu

ice

&Sm

ooth

ies

Tira

mis

uSa

lads

Rau

wko

st/s

alad

ebar

mid

del

Fres

hmad

eSo

upSo

epC

ourg

ette

Hot

mea

ls&

snac

ksZ

alm

moo

tO

mel

etM

etK

aas

Des

sert

&Ju

ices

Des

sert

1,30

Cof

fee

&Te

aca

ppuc

cino

1.4

Feed

back

scen

ario

sFr

omin

form

atio

nab

outt

hepe

rson

and

the

RoF

’sm

enu

we

wan

tto

advi

seou

rcon

su-

mer

abou

tfoo

dth

atco

uld

fitth

eir.

The

rear

em

any

solu

tions

toad

vise

them

:by

emai

l,w

ebor

Smar

tpho

ne.T

here

also

diff

eren

tsol

utio

nto

acce

ssto

the

info

rmat

ion.

Mea

nsof

com

mun

icat

ion

E-m

ails

olut

ion

John

isat

his

offic

ean

dre

ceiv

esan

e-m

aila

roun

d11

o’cl

ock.

Thi

se-

mai

lcon

tain

sa

sele

ctio

nan

da

advi

seof

food

sfo

rhi

m(F

ig.1

.2).

John

can

prin

tor

just

notic

eth

ee-

mai

ladv

ise

and

goto

the

RoF

fort

helu

nch.

7

Som

esc

enar

iosf

orth

eap

plic

atio

n

FIG

UR

E1.

2–

John

’se-

mai

l

Web

solu

tion

John

isat

his

offic

ean

dlo

gon

his

coun

tatt

heR

oFA

dvis

eW

ebsi

te.

May

behe

rece

ived

ane-

mai

lto

info

rmhi

mth

athe

can

conn

ect

toit.

The

nhe

can

navi

gate

thro

ugh

the

prod

ucta

vaila

ble

atth

eR

oF.T

hepr

oduc

tsar

eso

rted

for

him

.He

has

acce

ssto

apr

edefi

nese

lect

ion

offo

odan

din

form

atio

nab

outt

heir,

buta

lso

toal

lth

eot

herf

ood

avai

labl

eto

day.

Web

/Wap

solu

tion

for

mob

ileT

heea

rly

solu

tion

coul

dha

veor

bea

mob

ileph

one

vers

ion

and

beus

edat

the

RoF

.

Smar

tpho

ne’A

ppss

olut

ion

John

sync

hron

ize

his

Smar

tpho

neto

upda

teth

eR

oFA

d-vi

seA

pps

athi

sof

fice

orw

ithW

ifi/3

Gac

cess

atth

eR

oF.H

eca

nus

eit

atth

eR

oF.

Wed

nesd

aysc

enar

ios

Fort

hedi

ffer

ents

olut

ion,

we

choo

seSm

artp

hone

repr

esen

tatio

n."

Pres

elec

ted

prod

ucts

olut

ion

The

food

are

sele

cted

and

sort

edac

cord

ing

:–

the

cont

exto

fthe

lunc

h(m

ainl

yth

eda

ilym

enu

ofth

eR

oF),

–Jo

hn’s

pref

eren

ces

(wha

tJoh

n’s

likes

and

wan

ts),

–Jo

hn’s

profi

le(J

ohn’

snu

triti

vene

eds)

.Q

uest

ion

:W

hat

dow

epr

opos

ea

men

u(l

ink

betw

een

cour

ses)

ora

prod

ucts

per

cate

gory

?In

this

docu

men

tw

eco

nsid

erth

atfo

rea

chca

tego

ryw

eca

nad

vise

one

orm

ore

prod

uct.

Aft

erup

date

his

Smar

tpho

neJo

hnca

nw

atch

onhi

sSm

artp

hone

wha

tare

RoF

Adv

i-se

App

spr

opos

esfo

rhi

mto

day.

Itco

uld

beat

his

offic

eor

atth

eR

oF.H

eca

nna

viga

teth

roug

hth

eR

oF’s

cate

gori

es(F

ig.1

.3)

and

look

ing

for

info

rmat

ions

abou

tfo

ods

and

8

1.4

Feed

back

scen

ario

s

mak

ehi

sfin

alch

oice

.

FIG

UR

E1.

3–

navi

gatio

nby

Smar

tpho

ne’s

Cat

egor

ies

Whe

nJo

hnex

plor

eon

eca

tego

ry,h

eca

nw

atch

som

epr

oduc

twhi

char

ese

lect

edan

dso

rted

byth

esy

stem

.For

each

prod

uct

heca

nac

cess

toco

mpl

emen

tary

and

rele

vant

info

rmat

ion

forh

im(F

ig.1

.4).

FIG

UR

E1.

4–

sele

cted

and

sort

edpr

oduc

tsan

dm

ore

deta

ils

Dyn

amic

alte

rnat

ives

solu

tion

Inth

esa

me

way

that

the

earl

yso

lutio

n,Jo

hnne

eds

toup

date

his

Smar

tpho

ne’s

RoF

Adv

iseA

pps

and

may

beto

have

aW

ifi/3

Gac

cess

(de-

pend

ing

ofth

ete

chno

logy

chos

en).

The

nat

his

offic

eor

atth

eR

oFhe

can

cons

ulth

e’s

9

Som

esc

enar

iosf

orth

eap

plic

atio

n

Smar

tpho

nean

dse

arch

wha

the

wan

tsto

eatt

oday

.Whe

nhe

sele

cts

and

item

,the

sys-

tem

dyna

mic

ally

prop

ose

tohi

mal

tern

ativ

es.T

hese

alte

rnat

ives

are

sele

cted

and

sort

edby

the

syst

emac

cord

ing

his

pref

eren

ces

(Fig

.1.5

).

FIG

UR

E1.

5–

Oth

ers

alte

rnat

ives

Dyn

amic

advi

ceso

lutio

n:M

yTr

ayL

ike

the

conc

epto

fba

sket

ina

Web

site

stor

e,Jo

hnca

nin

the

sam

ew

ayad

dspr

oduc

ton

his

virt

ual

and

real

tray

.Fro

mth

ishe

can

acce

ssto

asu

mm

ariz

eof

his

lunc

h.T

hepr

opos

ition

ofth

esy

stem

ism

ore

dyna

mic

,be

caus

ean

othe

rcr

iteri

ais

wha

the

has

alre

ady

chos

e.So

,Jo

hnca

nju

ggle

with

the

prod

uctt

oco

mpo

sean

dm

ake

com

prom

ise

betw

een

his

choi

ceto

build

his

lunc

h...

(if

heha

sth

etim

eto

).(F

ig.1

.6)

Info

rmat

ion

disp

laye

d

Lik

efo

od,t

hein

form

atio

nsab

outf

ood

and

thei

rgr

anul

arity

are

sele

cted

for

John

.N

otal

lthe

info

rmat

ion

are

disp

laye

dby

the

syst

em.T

here

also

are

man

ym

eans

todi

s-pl

ayit.

Itco

uld

beJo

hn’s

choi

ceor

dete

rmin

edby

his

know

ledg

eab

outf

ood

(nut

ritio

n,tr

acea

bilit

y,et

c.).

We

coul

dpr

opos

ead

ding

tora

wda

tasy

mbo

lsto

help

(Fig

.1.7

)

10

1.4

Feed

back

scen

ario

s

FIG

UR

E1.

6–

My

Tray

FIG

UR

E1.

7–

raw

data

disp

layi

ng

11

Cha

pitr

e2

Det

erm

ine

the

dom

ain

ofth

eon

tolo

gies

2.1

Pers

onal

prop

erty

–W

hatp

hysi

calp

rope

rtie

sha

veth

eco

nsum

er?

(age

,siz

e,B

MI..

.)–

Wha

tare

his

Bio

phys

ical

prop

ertie

s?(a

bout

oro-

gast

roin

test

inal

phys

iolo

gy)

–W

hati

shi

sG

enet

icba

ckgr

ound

?(W

eigh

tpro

blem

fam

ily...

)

2.2

Con

sum

erho

useh

old

–H

owm

any

peop

lear

ein

his

hous

ehol

d?

age

?ge

nder

?–

Who

goto

shop

ping

forf

ood

?–

Who

isco

okin

g?

2.3

Con

sum

erac

tivity

–D

oes

hew

ork

alo

t?(M

easu

rem

ent?

)–

How

man

yho

urs

perd

aydo

eshe

wor

k?

–W

hatd

oes

hedo

the

wee

kend

?Sp

orts

?C

ooki

ng?

Act

iviti

es?

–H

owm

any

part

ies/

dinn

erdo

eshe

goby

mon

th?

–D

oes

hedo

spor

ts?

–W

hatk

ind

ofsp

orts

?Fr

eque

ncy

?L

evel

?D

urat

ion

?–

How

does

heco

me

tow

ork

?–

How

man

yki

lom

etre

?Fr

eque

ncy

?

13

Det

erm

ine

the

dom

ain

ofth

eon

tolo

gies

2.4

Pers

onal

traj

ecto

ryab

outf

ood

–W

hatp

erso

nalt

raje

ctor

yha

sth

eco

nsum

er?

–D

iett

raje

ctor

y?

–W

eigh

t:lo

st?

Kee

pst

able

?G

etw

eigh

t?–

Sodi

um:l

ow?

Bal

ance

?→

All

com

pone

nt,n

utri

men

t,vi

tam

ins.

..(f

at,s

ugar

,sal

t,B

...)t

reat

men

t/die

t–

Spor

tive

:hig

h?

less

?–

Veg

etar

ian

:wha

tkin

d?

–E

cono

mic

traj

ecto

ry?

–Fa

irtr

ade

?–

Che

ap?

–E

nvir

onm

enta

ltra

ject

ory

?–

Ani

mal

frie

ndly

?–

Org

anic

?–

Why

this

reas

on?

–A

esth

etic

–H

ealth

(fee

ling

bette

r...)

/Illn

ess

(alle

rgy,

diab

etes

,ano

rexi

a,jo

int,

back

ache

...)

–R

elig

ion

–Pe

rson

alco

nvic

tion

–A

ctiv

ity(s

port

s...)

–So

cial

rela

tion

(fam

ily,w

ork.

..)

2.5

Con

sum

erbe

havi

our

–W

hata

rehi

sPe

rson

alkn

owle

dge

abou

tfoo

d?

–W

hata

rehi

spr

evio

usex

peri

ence

sor

hist

ory

indi

etan

dfo

od?

–W

hati

shi

sty

peof

cogn

ition

’ski

nd?

(loo

ks,h

eard

,kin

esic

sse

nsib

ility

)

2.6

Con

sum

erw

ithfo

od/h

abits

–H

owim

port

anti

sfo

od/e

atin

gfo

rthe

cons

umer

?–

Doe

she

like

eatin

g?

–H

owlo

ngis

his

lunc

htim

edu

ring

the

wee

k?

–H

owlo

ngis

his

lunc

htim

edu

ring

the

wee

kend

?–

Doe

she

mis

slu

nch

time

?W

hati

sth

efr

eque

ncy

ofth

is?

–W

hati

sth

eco

mpo

sitio

nof

his

lunc

hdu

ring

the

wee

k?

14

2.7

Att

here

stau

rant

–D

oes

heof

ten

drin

kw

ine,

beer

oran

othe

ralc

ohol

icdr

ink

?–

How

man

yco

urse

ofa

mea

lhas

one

lunc

h?

–D

oes

heta

kea

coff

ee,t

eaor

choc

olat

eaf

terl

unch

?

–Is

hefo

ndof

good

food

?–

Wha

tis

mor

eim

port

antq

ualit

yor

quan

tity

?–

How

muc

hdo

eshe

eat?

–W

hatt

aste

does

hepr

efer

?Sw

eet?

Salt

?H

ot?

Spic

y?

...–

Doe

sex

istf

ood

that

heun

cond

ition

allo

ves

orha

tes?

–H

owdo

eshe

choo

sehi

sfo

od:b

ysm

ell,

look

...?

–W

hich

info

rmat

ion

does

hene

ed?

(org

anic

...)

–D

oes

hew

ante

atin

ga

food

ifit

look

sgo

odor

ifso

meo

neea

tsit

?–

Doe

she

like

tryi

ngne

wfo

od?

–D

oes

helik

eva

ryhi

sm

enu

?

–D

oes

heea

twith

outb

eing

hung

ry?

–D

oes

emot

ion/

feel

mak

ehe

hung

ryor

satia

te?

–D

oes

hefe

elsa

tiate

dw

hen

his

mea

lwas

finis

hed

?

–H

owm

any

time

perw

eek

does

hego

toth

eR

oF?

2.7

Att

here

stau

rant

–W

hatd

oes

heal

read

yha

veon

his

tray

?–

Doe

she

see

alla

ltern

ativ

efo

odin

the

rest

aura

nt?

–Is

hehu

ngry

?–

How

man

ype

ople

are

with

him

?–

Isit

aw

orki

nglu

nch

with

nego

tiatio

n...

?–

Isit

aca

lmlu

nch

with

good

colle

ague

s?–

How

man

ytim

eha

she

tolu

nch

?–

Doe

she

have

adr

ink

inth

istr

ay?

–D

oes

hebr

ing

his

own

lunc

h?

Wha

tis

it?

Forw

hatk

ind

ofco

urse

?

2.8

Food

–In

wha

tcat

egor

yis

it?

(Fru

it...)

–W

hata

reth

eirn

utri

tive

prop

ertie

s?–

Itis

new

erin

the

men

u?

Spec

ialm

enu

?(C

hris

tmas

...)

15

Det

erm

ine

the

dom

ain

ofth

eon

tolo

gies

–W

ithw

hatd

oes

itco

mbi

new

ell?

–W

hati

sits

orig

in?

(For

eign

spec

ialit

y...)

–W

hati

sits

trac

eabi

lity

?(F

airt

rade

)–

How

does

itlo

ok?

smel

l?–

Isa

phot

oof

itav

aila

ble

?

2.9

Type

ofFe

edba

ck–

Wha

tkin

dof

feed

back

/inf

orm

atio

ndo

eshe

need

?–

Doe

she

prov

ide

info

rmat

ion

onw

here

tofin

dth

efo

od?

–D

oes

hene

edal

tern

ativ

es?

–If

heju

stne

edra

win

form

atio

nab

outf

ood

?W

hatk

ind

?–

Hav

ehe

need

toac

cess

his

lunc

hhi

stor

y?

–D

oes

hepr

efer

rece

ive

anem

ailw

ithth

em

enu

and/

orpr

opos

ition

befo

rego

ing

tolu

nch

?–

Doe

she

need

anin

tera

ctiv

ena

viga

tion

amon

gth

efo

od’s

info

rmat

ion

?

16

Cha

pitr

e3

Impo

rtan

tter

msi

nth

eon

tolo

gy

3.1

Abo

utFo

odT

his

conc

eptc

ould

repr

esen

tone

ofth

efin

alpr

oduc

toft

here

stau

rant

(for

exam

ple

:It

alia

nto

mat

oso

up).

–Pr

oduc

torF

ood

(nam

eof

each

cour

seav

aila

ble

inth

eR

oF?

inen

glis

h+du

tch

oron

lyin

dutc

h?)

–In

gred

ient

:com

posi

tion

ofth

ePr

oduc

t(to

mat

o,sa

lmon

,cum

in...

),al

lthe

nam

e?

avai

labi

lity

?–

Ori

gin

ofin

gred

ient

,pro

duct

.Thi

sis

info

rmat

ion

abou

ttra

ceab

ility

.–

Cat

egor

yof

the

ingr

edie

nts

(veg

etab

le,f

ruit,

mea

t,fis

h...)

–N

utri

tive

prop

ertie

s:E

nerg

y(u

nit)

,Fat

(uni

t),V

itam

in,e

tc.

–A

ppea

ranc

eof

the

Prod

uct/

Pres

enta

tion

(loo

k,sm

ell,

colo

r,et

c.)

–R

ecip

epr

oper

ties

:tem

pera

ture

,fri

edfo

od,..

.

–Q

uant

ity/S

ize

ofth

epr

oduc

t:pe

r100

g,pe

rcen

t(un

it?)

–C

ateg

ory

ofth

epr

oduc

t(ju

stin

the

RoF

orm

aybe

larg

er?)

–C

osto

fthe

prod

uct

3.2

Abo

utC

onte

xtT

his

cont

extc

ould

beab

outt

heco

ntex

toft

helu

nch.

–M

ater

ialc

onte

xt:

–M

enu

–R

esta

uran

toft

heFu

ture

envi

ronm

ent:

desc

ript

ion

ofth

ero

om(t

able

,col

orof

sit..

.),of

the

disp

ositi

onof

the

plat

,sta

ff,s

ound

,etc

.

17

Impo

rtan

tter

msi

nth

eon

tolo

gy

–W

eath

er:t

empe

ratu

re,l

ight

...,

–Ti

me/

date

ofth

eof

the

lunc

h;

–H

uman

cont

ext:

–de

scri

ptio

nof

the

soci

alco

ntex

t:ho

wm

any

peop

leea

twith

him

,rel

ax/w

ork

lunc

h,–

desc

ript

ion

ofth

etim

ehe

has

fort

helu

nch

;

3.3

Abo

utob

ject

ive/

traj

ecto

ry

Wha

tdoe

sth

eco

nsum

erw

ant?

Wha

tis

the

obje

ctiv

eof

the

syst

em/d

iet?

–D

iet:

vege

tari

an,s

port

ive,

rest

rict

,var

iabi

lity

ofco

urse

,dis

cove

ring

,etc

.–

Eco

nom

ic:f

airt

rade

,che

ap/e

xpan

sive

–E

nvir

onm

ent:

anim

alfr

iend

ly,o

rgan

ic–

Tast

e/Se

nsiti

ve:Q

ualit

y/Q

uant

ity–

Rea

son

:Rel

igio

n,H

ealth

,Aes

thet

ic,A

ctiv

ity,S

ocia

l...

–C

onst

rain

t(st

reng

thof

)/Im

port

ance

ofth

ecr

iteri

a–

Dat

e

3.4

Abo

utPr

efer

ence

Wha

tdoe

sth

eco

nsum

erlik

e(a

ndw

ould

wan

t)?

–Fo

od–

Con

text

–O

bjec

tive

3.5

Abo

utPr

ofile

The

"Pro

file"

coul

dbe

com

pose

dof

info

rmat

ions

abou

tthe

cons

umer

and

anu

triti

onpr

ofile

,may

bevi

ewlik

eex

pert

rule

.Fo

rexa

mpl

e:

→a

spor

tive

pers

on,f

emal

e,30

year

sol

d,1.

70m

need

s45

0K

calp

erlu

nch

;→

ape

rson

with

BM

I>35

need

sto

follo

wa

less

calo

rie

diet

;

–Ty

pe:S

port

ive,

BM

I>,B

MI<

–N

eeds

:Ene

rgy

(uni

t),F

at(u

nit)

,

18

3.6

Abo

utPe

rson

3.6

Abo

utPe

rson

–Id

entit

ypr

oper

ties

:firs

t-na

me,

last

-nam

e,so

finum

ber

–W

ork

prop

ertie

s:e

mpl

oyer

,add

ress

,tel

epho

nenu

mbe

r,em

ail,

WU

R-c

ard

num

-be

r–

Hou

seho

ldpr

oper

ties

:typ

e:s

ingl

e,to

geth

erw

ithou

tchi

ldre

n...

;–

Hea

lthpr

oper

ties

:illn

ess

–Ph

ysic

alpr

oper

tyge

nder

,age

/bir

th,w

eigh

t(un

it),l

engt

h(u

nit)

,BM

I(un

it,la

bel)

–C

hoic

ebe

havi

our:

wha

tcou

ldin

fluen

cehi

m(f

ood,

cont

ext..

.)–

Gen

etic

back

grou

nd–

Hab

its–

Act

ivity

3.7

Abo

utTy

peO

fFee

dbac

k–

Food

info

rmat

ion

need

ed–

Type

–C

omm

unic

atio

nm

eans

:em

ail,

web

,iPh

one

–U

ser-

frie

ndlin

ess

:tex

t,nu

mer

ical

,col

or,t

raffi

clig

ht,p

erce

nt,g

raph

19

Annexe C

Facteurs essentiels du choix d’aliments

99

Irritation Boredom Aversion

1.3

Modelling Data-integration

& Co-ordination

0Intrinsic product characteristics

Perception1

Psychologicalfactors

3

Situational factors

4

Biological & Physiological

factors 2

Extrinsic product characteristics Expectations

6

Socio-culturalfactors

5

Cognition Emotion Motivation Decision making

3.1

Memory Previous experiences

Learning 3.2

ClaimsBrand label Packaging

6.1

Integrity Sustainability

6.2

Culture Religion Economics Climate

5.1

Appearance Interaction Taste Smell

Texture Trigeminal 1.1

Personality traitsHabits Attitudes

3.3

Genetic factors Immuno system

Brain imaging 2.1

Age/Gender Physical condition

Sensory acuity 2.2

Time Social context

Physical context 4.1

Coping Assimilation Habituation

4.2

Trust in Industry & Government

5.2

Societal beliefs norms values

5.3

Intentionality Signification Attribution

4.3

Risk perception 6.3

Essential factors that influence eating and drinking behaviour and food choice

Oro-gastro- intestinal physiology

2.3

Complexity Adaptation

Dynamic contrast 1.2

Copyright J. Mojet ATO 2001

FBR MRLEIFBR MR LEI

FBR-CS MR LEI

FBR-CS

FBR-CS

FBR-CS

FBR-CS

FBR-CS MR FBR-CS MR LEI

MR LEI

FBR-CS

FBR-CS

MR LEI

HV

FBR-CS HV

HV?

product situationconsumerCharacteristics of

FIGURE C.1 – Représentation de la masse d’une part de tiramisu avec TopBraid

FIGURE C.2 – Représentation de la masse d’hydrate de carbone d’une pomme avecTopBraid

Annexe D

Mode de vie du consommateur

.

FIGURE D.1 – Représentation du concept Household avec TopBraid

FIGURE D.2 – Représentation du concept SportiveActivity avec TopBraid

103

Annexe E

Concept de MeasurementCharacteristic

Listing E.1 – Définition de la propriété fonctionnelle measureOf en code Turtlemeas:measureOf

a owl:FunctionalProperty , owl:ObjectProperty ;rdfs:domain

[ a owl:Class ;owl:unionOf ( < h t t p : / /www. wurvoc . o rg / r o f / a d v i c e # TypeOfMeasurement>

meas:MeasurementCharacteristic )] ;

rdfs:label " measure o f "@en ;rdfs:range oum:Metrological_concept .

Listing E.2 – Définition de la propriété fonctionnelle hasUnitOfMeasure en code Turtlemeas:hasUnitOfMeasure

a owl:FunctionalProperty , owl:ObjectProperty ;rdfs:domain meas:MeasurementCharacteristic ;rdfs:label " has u n i t "@en ;rdfs:range oum:Unit_of_measure .

105

Annexe F

Turtle code of Consumer

cons:Consumera owl:Class ;rdfs:comment " P e r so n who i s a consumer o f t h e R e s t a u r a n t o f t h e F u t u r e "@en ;rdfs:label " Consumer " ^^xsd:string ;rdfs:subClassOf owl:Thing ;rdfs:subClassOf

[ a owl:Restriction ;owl:cardinality " 1 " ^^xsd:nonNegativeInteger ;owl:onProperty cons:hasWURCardNumber

] ;rdfs:subClassOf

[ a owl:Restriction ;owl:cardinality " 1 " ^^xsd:nonNegativeInteger ;owl:onProperty cons:hasLastName

] ;rdfs:subClassOf

[ a owl:Restriction ;owl:cardinality " 1 " ^^xsd:nonNegativeInteger ;owl:onProperty cons:hasFirstName

] ;rdfs:subClassOf

[ a owl:Restriction ;owl:cardinality " 1 " ^^xsd:nonNegativeInteger ;owl:onProperty cons:hasGender

] ;rdfs:subClassOf

[ a owl:Restriction ;owl:cardinality " 1 " ^^xsd:nonNegativeInteger ;owl:onProperty cons:hasHeight

] ;rdfs:subClassOf

[ a owl:Restriction ;owl:allValuesFrom cons:Height ;owl:onProperty cons:hasHeight

] ;rdfs:subClassOf

[ a owl:Restriction ;owl:minCardinality " 1 " ^^xsd:nonNegativeInteger ;owl:onProperty cons:hasWeight

] ;rdfs:subClassOf

[ a owl:Restriction ;

107

Turtle code of Consumer

owl:allValuesFrom cons:Weight ;owl:onProperty cons:hasWeight

] .

108

Annexe G

Infrastructure des données

G.1 Infrastructure des produits

109

Productparameters

Kassa DB Sodexo DB?Sodexo

menu-cyclus DB?

- PersoonID- producten- prijs- tijdstip vanafrekenen- ...

- Weeknummer- Menuitems(aanbod)

- ProductID- nutrienten- ingredienten- kcal- ...

Data-bronnen

Data-bronnengeborgd

Data-model

Sync-protocol

SCOMP0056\RvdT_RawData

SCOMP0056\RvdT_DataModel

Backup-protocol



111

Persoonsparameters

Internetenquêtedatabase

Acces DB metpersoon-pas-

koppeling

WageningenBasis

Administratie

Persoon: - naam- leeftijd- opgegeven gewicht- lengte- geslacht

Persoon: - naam- e-mail- WUR-card nummer

Persoon: - naam- e-mail- pasnummer

Weegschaal

Gewicht: - tijdstip- gewicht

Data-bronnen

Data-bronnengeborgd

Data-model

Sync-protocol

SCOMP0056\RvdT_RawData

SCOMP0056\RvdT_DataModel

Backup-protocol

G.3 Infrastructure des données intégrée

G.3 Infrastructure des données intégrée

113

Parameter RVDT- Lighting RVDT [string]- RVDT doors open / close [boolean]- RVDT curtains open / close [boolean]- Utilization [float] <%>- Indoor temperature [float] <° C>- Area smell [string]- Sound [string]- Cash position [string]

Weather- Outdoor [float] <° C>- Sun [float] <%>- Precipitation [string]- Weather forecast [string] Assortment

- Bestaat_uit: Menu items- Menu-cycle [string]

Menu item- Ingredients [string]- Nutritional value [string]- Energy value [string]- Weight [float] <kg>- Price [float] <Eur>- Category [string]- Presentation [string]- Description [string]- Crockery size [string]- Portion size [string]

Waste- Product: Menu items- Weggooier: Person- Volume [float] <kg>- GFT / rest [list]

Choice behavior- Invloed_van: Environmental factors- Selectie_van: Menu item- Entry in electoral area RVDT [time]- Leaving select portion RVDT [time]- Gait [[float] [float]]- Viewing habits [string]- Water at lunch? [Boolean]- Packed lunch from home [boolean]

Person- Sex [list]- BMI [float]- Age [int] <jaar>- Preferred feedback [string]- Has travel behavior: choice behavior- Does eating: Individual Eetgedra

Group- Groepseetgedrag: Groepseetgedrag- Bestaat_uit: Persons- Group size [int]- Animated nature [string]

Environment Factor- Operation: Staff- Preparation: Buffets- Device: Furniture- Opportunity: Special occasion- Actuele_weer: Weather- Settings: Parameter RVDT

Individual Eetgedrag- Invloed_van: Environmental factors- Order of consumption [string]- Hapsnelheid [float] <hap/minuut>- Chewing time [float] <kauwbeweging / minuut>- Hapgrootte [string]- Meal time [float] <sec>- Seating [string]- Seat selection [string]

Groepseetgedrag- Invloed_van: Environmental factors- Average meal duration [float] <sec>- Imitation eating? [boolean]

Chair- Description [string]- Position [string]

Table- Description [string]- Position [string]

Furniture- Heeft_stoel: Chair- Heeft_tafel: Table

Special occasion- Days of the week [list]- Season [list]- Description [string]

Buffet- Classification: Menu item- Position [string]- Lighting [string]

Staff- Sex [list]- Age [int] <jaar>- Behavior [string]

Annexe H

Vocabulaire partagé

115

Vocabulaire partagé

FIGURE H.1 – Paquetage vocabulary, diagramme de classes partiel

116

MÉMOIRE DE STAGE DE MASTER 2

Documents

Transcript of MÉMOIRE DE STAGE DE MASTER 2