Rapport Stage PFE

Acadmie de Montpellier
Universit Montpellier II
Sciences et Techniques du Languedoc
MMOIRE DE STAGE DE MASTER 2
effectu au laboratoire
Agrotechnology & Food Science Group,
Wageningen University & Research Center
Spcialit :
Professionnelle et Recherche unifie en Informatique
Une application Smartphone pour un systme

de recommandations alimentaires
personnalises
par Anne Tireau
Soutenu le 13 Septembre 2010
Sous la direction de : Nicole Koenderinck
Devant le jury compos de :
Prsident : Rodolphe Giroudeau
Rapporteurs : Isabelle Mougenot

: Abdelkader Gouaich
ii
Remerciements
Je tiens remercier, dans un premier temps, toute lquipe pdagogique de luniver-

sit Montpellier II et les intervenants professionnels responsables du MASTER Infor-
matique IFPRU, pour avoir assur la partie thorique de celle-ci.
Je remercie galement Madame Nicole Koenderinck ma tutrice au sein du dpartement

de recherche Food & Biobased Research lUniversit de Wageningen (Pays-Bas) pour
son accueil et son encadrement tout au long de ce stage.
Je tiens remercier tout particulirement et tmoigner toute ma reconnaissance

Madame Isabelle Mougenot pour son intrt pour mon travail, ses conseils, son aide et
sa disponibilit.
Un grand merci toute lquipe Information Management pour mavoir fait dcou-
vrir un nouveau laboratoire de recherche, une autre faon de travailler et aussi une autre
culture. Plus particulirement, je remercie Hajo pour avoir facilit mon intgration et
pour les discussions varies.
Pour finir, je noublie pas mes collgues de lUMR MISTEA qui mont accueillie il
y a 5 ans dj dans leur quipe et qui mont encourage faire ce Master. Je les remercie
pour tout leur soutien et leur aide prcieuse. Je pense particulirement Brigitte, Nadine
et Pascal.
iii
Table des matires
Introduction 1
1 Contexte et objectifs 3
1.1 Contexte du domaine applicatif . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Objectifs informatiques . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Etat de lart 11
2.1 Ontologies et outils du Web Semantic . . . . . . . . . . . . . . . . . . 11
2.2 Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 La plateforme Smartphone . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Modles de connaissances 21
3.1 Processus de conception et interaction entre les composants ontologiques 22
3.2 Ontologie des produits du Restaurant du Futur . . . . . . . . . . . . . . 25
3.3 Ontologies pour les prfrences des consommateurs . . . . . . . . . . . 31
3.4 Ontologies de recommandations . . . . . . . . . . . . . . . . . . . . . 35
4 Mise en uvre au travers dune architecture logicielle 41

4.1 Architecture du prototype PEA et dmarche de personnalisation . . . . 42
4.1.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.2 Dmarche de personnalisation . . . . . . . . . . . . . . . . . . 44
4.2 Mise en uvre oprationnelle dun systme base de connaissances . . 45
4.2.1 Vocabulaire partag . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.2 Serveur de stockage de donnes RDF . . . . . . . . . . . . . . 46
4.2.3 Lacquisition de donnes RDF et la constitution du jeu de tests . 46
4.2.4 Des modles de connaissances aux objets mtiers : exploitation
de SPARQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3 Personnalisation du menu du jour : RoFAdvisedMenu . . . . . . . . . . 52
4.3.1 volution du modle dobjet mtier . . . . . . . . . . . . . . . 52
4.3.2 Gestion des conseils et des recommandations . . . . . . . . . . 54
4.3.3 Annotation advised et avoid . . . . . . . . . . . . . . . . . . . 54
v
TABLE DES MATIRES
4.3.4 Gestion de la tentation . . . . . . . . . . . . . . . . . . . . . . 57

4.3.5 Caractristique pertinente . . . . . . . . . . . . . . . . . . . . 58
4.3.6 Gestion du plateau virtuel . . . . . . . . . . . . . . . . . . . . 59
4.4 Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.5 Application sur Smartphone . . . . . . . . . . . . . . . . . . . . . . . 66
5 Conclusion 75
Bibliographie 77
Annexes 79
A Questionnaire pour les consommateurs du RoF 81
B Analyse : scnarios et domaines des ontologies 87
C Facteurs essentiels du choix daliments 99
D Mode de vie du consommateur 103
E Concept de MeasurementCharacteristic 105
F Turtle code of Consumer 107
G Infrastructure des donnes 109

G.1 Infrastructure des produits . . . . . . . . . . . . . . . . . . . . . . . . 109
G.2 Infrastructure des produits . . . . . . . . . . . . . . . . . . . . . . . . 111
G.3 Infrastructure des donnes intgre . . . . . . . . . . . . . . . . . . . . 113
H Vocabulaire partag 115
vi
Introduction
Ce stage de Master 2 sest droul dans le dpartement de recherche Food & Biobased
Research lUniversit de Wageningen (Pays-Bas). Lobjectif appliqu tait de proposer
aux clients dun restaurant - self service exprimental , le Restaurant du Futur, un pro-
totype de systme de diffusion de conseils alimentaires qui convienne leur mode de
vie, leurs caractristiques physiques et physiologiques ainsi qu leurs gots alimen-
taires. Pour cela, il sest avr ncessaire davoir un environnement de connaissances
qui reprsente les diffrentes connaissances sur les menus (produits ou aliments as-
socis, leurs caractristiques et valeurs nutritives) et sur les consommateurs rfrencs
(caractristiques physiques, prfrences, mode de vie, objectifs dittiques, etc...), et qui
permette de dlivrer des conseils dittiques personnaliss. Pour aider le consommateur
dans sa dmarche, il est important que lorsquil se dplace dans le restaurant pour faire
ses choix, il dispose de linformation pertinente. La cration de cet environnement a
constitu la premire tape du stage. Lobjectif long terme est la prise en compte de
la localisation des produits et du consommateur pour lui donner des conseils en temps
rel, adapts la gestion des tentations possibles et respectant ses objectifs dittiques.
Une des originalits de lapproche est de proposer une application sur un environnement
mobile, tel quun Smartphone.
Pour ce faire, une ontologie sera construite pour chaque pan de connaissance, des don-
nes seront licites et des ontologies locales dfinies partir de ces donnes spci-
fiques. Dans ce but, les technologies et langages du Web Smantique sont mises profit.
Lensemble de ces ontologies est exploit au sein de lenvironnement de connaissance.
Lattention est porte sur la dfinition dune architecture approprie leur exploitation
par des usagers finaux aux travers de plateformes mobiles.
La dmarche gnrale sera teste et valide au travers de la ralisation dun pro-

totype. Ce prototype est dvelopp laide de diffrents outils : lditeur dontologie
TopBraid, le systme de gestion de connaissances Sesame, les langages du Web Sman-
tique RDF/S, OWL et SPARQL, ainsi quun Web Service RestFul bas sur le framework
Restlet et pour la plateforme mobile Windows Phone 7 Silverlight, XAML et C#.
Le rapport est structur de la faon suivante : le contexte du stage et les objectifs in-
formatiques dgags font lobjet du premier chapitre. Les principaux outils utiliss sont
1
TABLE DES MATIRES
introduits dans ltat de lart au chapitre 2. Les modles de connaissance que nous avons
dvelopps sont dcrits au chapitre 3. Toute la partie mise en uvre est dtaille dans le
chapitre 4, de larchitecture du prototype du systme de diffusion des conseils person-
naliss lapplication sur Smartphone. Des perspectives sont ensuite dgages autour
de plusieurs questions de recherche lies aux ontologies. La conclusion, chapitre 5, clt
la partie principale du mmoire. Des chapitres annexes sont donns pour complter lin-
formation, tant technique que associe lapplication (dittique, prfrences).
2
Chapitre 1
Contexte et objectifs
1.1 Contexte du domaine applicatif

Le contexte dans lequel ce stage a t ralis est prsent ici. Il sagit den expliquer
les grandes lignes afin de justifier les choix conceptuels ou technologiques qui seront
faits par la suite. Nous introduisons aussi le projet FOVEA sans lequel ce stage naurait
pas eu lieu.
Les gouvernements des pays occidentaux ont mis en place de vastes campagnes
dinformation pour sensibiliser les populations leur mode alimentaire. Lide est donc
de poser les bases dune vie plus saine sans rien imposer. Ces campagnes, qui passent
par exemple par la diffusion de spots publicitaires, cotent cher et ne rcoltent que
des rsultats plutt mdiocres. Or il est postul que lefficacit du message serait plus
grande si ce message tait personnalis. En effet, les conseils donns jusqualors sont
des conseils gnraux portant soit sur lalimentation, soit sur la sant et rencontrent un
accueil assez limit de la part de la population. Les principaux reproches qui sont faits
ces conseils, par trop gnraux, sont les suivants :
ils ne tiennent compte ni des prfrences ou aversions alimentaires, ni des in-
tolrances ou allergie alimentaires ventuelles ;
ils ne considrent, en aucun cas, les dpenses physiques journalires de la per-
sonne ;
ils sont en arrire plan au moment du choix ;
ils ne se doublent pas dun travail de prvention 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 place
et a pour un de ses objectifs, la cration de la base dun systme de diffusion dinfor-
mations ax sur la personne. Ce systme est attendu de fournir toute personne des
1. http://www.fovea-project.org/UK/
3
conseils personnaliss pour une alimentation plus saine et une activit physique plus
adapte.
Le dpartement de recherche Food & Biobased Research est lun des partenaires
du projet FOVEA. Ce dpartement fait partie du centre Wageningen University & Re-
search (WUR) 2 aux Pays-Bas. Ses domaines dexpertise portent sur les sciences sen-
sorielles et le comportement alimentaire dune part et sur les systmes dit "intelligents"
et la recherche applique en vision dautre part. Cette double comptence en fait un
dpartement de recherche de choix pour la bonne conduite du projet FOVEA. Jai t
plus spcifiquement accueillie dans lquipe Information Management 3 dont les activ-
its sont ancres dans le second axe "systmes intelligents". Un systme dit intelligent
est vu, ici, comme un systme automatis enrichi dune couche logicielle traitant de la
connaissance afin den largir le primtre de fonctionnalits. Dans cette optique et de
concert avec trois entreprises prives, le dpartement de recherche Food & Biobased
Research, a cr en 2007, le Restaurant du Futur 4 , pour mener bien ses recherches
sur le comportement des consommateurs et les moteurs qui influent sur leurs choix ali-
mentaires. Dans le projet FOVEA, Food & Biobased Research se positionne lchelle
du restaurant pour rpondre de manire applique et proposer un cas dtude bien rel
la problmatique du sujet. A partir des tudes menes dans ce cadre, les chercheurs de
Food & Biobased Research dveloppent des modles conceptuels orients vers de la per-
sonnalisation de conseils alimentaires en vertu de diffrents facteurs : physiologiques,
ethniques, financiers, ducationnels, lis aux modes de vie, etc. Le restaurant sert alors
de domaine dtude et vient instancier les modles construits. Il est alors plus facile de
valider les modles construits.
Le Restaurant du Futur est un restaurant dentreprise, en libre-service, situ sur

le centre de lUniversit de Wageningen (cf. figure 1.1). Ce restaurant est, avant tout,
une zone dexpriences et dtudes o les exprimentations en laboratoire portent sur le
domaine sensoriel des aliments : odeur, couleur, got, etc.. La salle principale du restau-
rant, quant elle, permet dtudier le comportement des consommateurs et leurs choix
alimentaires durant un repas. Cela peut inclure ltude de linfluence des paramtres lis
aux produits : composition, got, emballage, prsentation ou informations associes
(prix, nom, etc.). Lenvironnement est aussi pris en compte : agencement de la salle,
couleur des buffets, des tables et des chaises, circulation dans le restaurant, influence
de la luminosit, de la temprature ambiante... Ces informations sont collectes grce
des capteurs, notamment des camras dont les squences vidos sont analyses et an-
notes. A cela sajoutent des caisses enregistreuses, relies des systmes de gestion
2. http://www.wur.nl/UK/
3. http://www.fbresearch.nl/InformationManagement/
4. http://www.restaurantvandetoekomst.wur.nl/UK/
4
1.1 Contexte du domaine applicatif
de donnes, qui consignent les achats des consommateurs. En outre, chaque nouveau
client peut sinscrire et rpondre un questionnaire (cf. annexe A). Celui-ci permettra
aux chercheurs davoir une ide du mode de vie des usagers ou des relations entretenues
avec les aliments (dtection de nophobie 5 , par exemple). Cette dmarche dacquisition
et de valorisation dinformation est importante et difficile, car ltude du comportement
implique que la collecte des informations sur les consommateurs soit la moins intru-
sive possible pour ne pas influencer leurs comportements. Ceci va aussi ncessiter de
lexpertise dans le domaine des nouvelles technologies de linformation et de la commu-
nication, afin doptimiser les traitements et leurs exploitations. Cest dans ce domaine
quintervient lquipe Information Management. Dans ce contexte, les projets actuelle-
ment en cours de ralisation portent sur des systmes de reconnaissance visuelle de
personnes, de comportements et de produits ou sur le systme dintgration de donnes.
F IGURE 1.1 Restaurant du Futur : buffet de la salle principale, caisse enregistreuse,

salle de contrle des camras
La personnalisation des conseils va aussi dpendre des connaissances disponibles

sur le consommateur, dans le cadre du restaurant.
Pour le consommateur, il pourra sagir de :
ses caractristiques physiques et physiologiques,
ses prfrences alimentaires (got / aversion),
lhistorique de consommations des derniers jours,
ses habitudes alimentaires,
5. Nophobie : crainte de tout ce qui est nouveau.
5
ses objectifs dittiques (rgime vgtarien ou hypocalorique par exemple),

son mode de vie (clibataire, dplacements frquents, etc.),
son activit sportive,
son comportement face la nourriture (importance des repas dans sa vie, etc.).
Pour le Restaurant du Futur, la personnalisation va dpendre de lenvironnement
mais surtout des connaissances possdes sur les produits disponibles :
la composition des menus,
les produits avec leurs caractristiques et leurs valeurs nutritives. Notons que les
caractristiques peuvent tre assez fines, car elles concernent galement tout ce
qui fait quun produit peut attirer ou rebuter un consommateur (got amer, odeur
de vanille...).
1.2 Objectifs informatiques

Modles de connaissances : lobjectif du projet est de proposer les premires briques
du systme de conseils alimentaires personnaliss, pour le Restaurant du Futur. Lune
des exigences du systme, et lun des enjeux informatiques ici, est la formalisation des
connaissances des diffrents domaines ncessaires. Cette formalisation va permettre
une exploitation plus fine et pousse des informations et des donnes disposition. Par
exemple, elle pourra faciliter laccs linformation et linfrence de nouveaux faits.
La particularit de ces modles, ou composants ontologiques dans notre cas, est quils
devront tre capables dtre combins de manire intelligente, afin dtre exploitables
par le modle de conseils. De plus, ils devront pouvoir voluer et tre enrichis pour
sorienter vers un systme de plus en plus complet.
Dans cette problmatique, mon stage a tout dabord consist proposer les premiers
modles de connaissances, en se basant pour commencer sur lexistant, cest--dire les
donnes et les informations dj disponibles. Dans un second temps, lobjectif du stage
tait de mettre en uvre ces composants ontologiques et de concevoir un premier proto-
type du systme de diffusion des conseils personnaliss ou PEA pour Personal Eating
Advisor en anglais.
Les exigences du systme PEA sont triples : le systme doit personnaliser les mes-
sages, donner des retours lutilisateur sur ses choix et tre mobile afin dtre prsent
au moment du choix. Lide est de proposer un dbut de solution aux limitations des
conseils gnraux diffuss actuellement. Le but ici est avant tout pdagogique.
La personnalisation du message diffus peut influencer son efficacit. Elle va

tre guide par les recommandations du modle de conseils, en fonction des prfrences
de lutilisateur. Il sagit de la forme et du contenu du message :
6
Forme : donnes textuelles, images, diagrammes, couleurs... Cette ide provient des
conclusions de ltude de linfluence des informations nutritives de Stubenitsky
et al. (2000), et suppose que le type de format dinformation utilis pourrait in-
fluencer lefficacit du message. Par exemple, le nombre de calories (information
textuelle) dun aliment correspondant un plat allg, naura pas forcment de
porte sur la personne qui na pas la notion de la ration qui lui est ncessaire.
Contenu : cest linformation pertinente pour le consommateur. Il sagit ici dtre en
accord avec le rgime dittique du consommateur. Par exemple, donner la teneur
en sel dun produit reste surtout pertinent pour lutilisateur qui suit un rgime dit
"sans sel".
Il en rsulte, que cette personnalisation servira de guide pour la partie IHM 6 du systme
de diffusion de linformation.
Les ractions du systme au choix du consommateur sont aussi des fonction-

nalits attendues. Elles peuvent tre vues comme une premire solution au manque de
retour lutilisateur sur ses mauvais choix. Comme par exemple, la proposition dune
alternative savrant plus pertinente que le choix opr par le client. Une autre solution
est la mise en place du concept de plateau virtuel, ou Tray en anglais. Avant mme
de se trouver dans la cantine, lutilisateur pourra ajouter ou supprimer des aliments de
son plateau virtuel et consulter une valuation globale de ses choix : rsum de lapport
calorique de son repas pr-slectionn, par exemple, ou rception dune alerte au d-
passement dun seuil fix et personnalis. Ainsi, il pourra ajuster ses choix en fonction
dun 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 larchitecture du systme. En effet, dans le
cas de lutilisation du plateau virtuel, vu prcdemment, la mobilit permettrait lu-
tilisateur doptimiser la composition de son plateau pendant ses choix. Cela est vrai
aussi de faon plus gnrale, pour aider la personne amliorer son comportement.
Un des phnomnes prendre en compte est celui de la tentation. Il influence norm-
ment les choix du consommateur et dpend souvent du contact avec les produits. Ce
quaimeraient les chercheurs, cest de pouvoir, dans une prochaine version, coupler le
conseiller un systme de golocalisation des produits et du consommateur afin de le
prvenir sil sapproche de produits estims comme "dangereux" ou au contraire de lui
proposer un chemin optimal vers les produits bnfiques. De ce fait, nous avons choisi
une plate-forme mobile, type ordiphone ou Smartphone en anglais, pour restituer les
conseils. En effet, ils allient la capacit et les fonctionnalits ncessaires.
6. IHM : Interface Homme-Machine
7
Lobjectif de mon stage est donc double. Premirement, il sagit de modliser les
composants ontologiques des domaines concernant une vaste proccupation humaine :
savoir lalimentation. Deuximement, il est aussi question de proposer un prototype
darchitecture et dapplication sur Smartphone capable de restituer au consommateur le
menu avec les conseils personnaliss et sappuyant sur ces composants ontologiques.
La solution propose est schmatise par la figure 1.2 o les principaux acteurs du
prototype sont reprsents avec leurs rles. Un environnement de connaissances associ
aux donnes collectes sera exploit par un modle de conseils alimentaires person-
naliss que nous avons considr comme une bote noire. Sa tche est de fournir les
recommandations ncessaires la constitution dun menu issu de notre environnement
et personnalis, cest--dire dont les informations seront restitues de manire perti-
nente pour le consommateur. La plateforme choisie pour lutilisateur est le Smartphone
afin de laider lors de ses choix au sein du Restaurant du Futur.
F IGURE 1.2 Architecture gnrale du prototype
Trois profils de consommateurs tablis avec les chercheurs et une ditticienne ont
guid notre tude. En effet, le domaine est trs vaste et il fallait rduire dans un pre-
mier temps lespace de complexit. Par rapport au modle de conseils et aux donnes
disponibles, le prototype intgre des fonctionnalits restreintes. Il sagissait cependant
8
de valider la globalit de lapproche. Les profils dfinis apportent individuellement une

problmatique bien identifie pour laquelle il est attendu que le systme apporte des
rponses. Le profil principal et prioritaire est celui de John, dtaill ci-aprs. Le sec-
ond profil est celui de Wim un sportif qui dsire se prparer pour une comptition et le
dernier profil est celui dEsther, une environnementaliste (qui veut manger biologique)
qui a une intolrance la tomate. Vous trouverez en Annexe B, chapitre 1, le dtail de
nos profils.
John est un homme de 50 ans et mesure 1 mtre 80. Il fait partie de lquipe
Information Management, travaille devant son ordinateur toute la journe et a une ac-
tivit sdentaire. Il est un consommateur rgulier du Restaurant du Futur, puisquil y
mange quatre fois par semaine. Il napporte jamais daliment extrieur au restaurant.
Il a rarement de repas de travail, mais djeune souvent avec les autres membres de
lquipe. John nest pas sportif, habite trop loin de son travail pour venir en vlo, et
vient donc en voiture. Son IMC 7 est denviron 30, donc il doit perdre du poids et cest
pourquoi il a un rgime alimentaire basses calories particulier. Le problme est que
John est gourmand et habitu choisir des plats sucrs, il prend toujours un dessert
pour finir son repas.
Recommandations dittiques pour John : dans le cadre dun projet pour le

Restaurant du Futur, John sest rendu chez une ditticienne qui lui a list les recom-
mandations suivantes, en concordance avec le projet du restaurant :
Rec. 1 : le repas est divis en catgories pour chacunes desquelles un produit doit tre
choisi ;
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 infrieure 600 kcal.
Exemple simple de scnario dutilisation du Smartphone : John quitte son lab-

oratoire vers 12h30, et se dirige avec les autres membres de lquipe vers le Restaurant
du Futur pour aller djeuner, son Smartphone en poche. Juste avant darriver, John sort
son Smartphone et lance lapplication Lunch@RoF, le premier cran daccueil souhaite
la bienvenue John sur lapplication 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
catgories daliments disponibles aujourdhui, il sait en regardant la liste quil pourra

trouver des soupes adaptes son rgime (point vert devant la catgorie des soupes).
Arriv devant le buffet des soupes, il se rend compte que toutes lui donnent envie. Il
joue le jeu et consulte la liste des soupes sur son Smartphone et voit quune des soupes
est signale comme " viter" par une marque rouge, mais que lautre est conseille
(marque verte). Il se sert de la soupe conseille et juste avant de repartir pour choisir la
suite, il ajoute dans le plateau virtuel de son Smartphone la soupe choisie. Il continue
ainsi de suite. Avant de quitter le self, il passe devant le buffet des desserts et a envie de
se laisser tenter par une crme au chocolat, il consulte le rsum du plateau virtuel et
voit quil na pas dpass les 600 kcal conseilles. Il ajoute la crme au plateau virtuel
et l, une alerte rouge lui indique que le total des calories de son repas va dpasser
les 700 kcal. Un peu du, John supprime la crme de son plateau virtuel et cherche
un dessert alternatif parmi les desserts conseills, il trouve une mousse de fruits qui
convient juste, il voit que cette mousse est situe sur le buffet des fruits, il sy rend tout
content, car il adore aussi cette sorte de produits, il la met sur son plateau physique et
va payer ses produits la caisse.
10
Chapitre 2
Etat de lart
Pour mettre en place le prototype de diffusion dinformations alimentaires person-

nalises pour les consommateurs du Restaurant du Futur, nous avons eu besoin dun
large spectre de notions et de technologies. La dmarche est de baser ce systme sur
des connaissances que nous avons choisies de reprsenter sous forme dontologies et en
utilisant les langages de reprsentation du Web Smantique. Le systme en lui mme
comprend un systme permettant dexploiter ces connaissances. Larchitecture mise en
place est distribue 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 linformatique et des sciences de linformation, une ontologie

peut tre dfinie comme un ensemble de concepts et de relations permettant de mod-
liser un domaine de connaissances (Gruber (2009)). Dans concepts sont incluses la
signification et les contraintes logiques dapplication dune reprsentation.
Nous pouvons distinguer plusieurs types dontologie, regroups et comments par

Psych et al. (2003). Cette classification va dpendre du but de lontologie, de ltendue
et de la prcision du domaine modlis :
les ontologies de reprsentation des connaissances : formalisation des connais-
sances ;
les ontologies suprieures ou de haut niveau : ontologies universelles qui ne dpen-
dent pas de domaine, ni de problme particulier. Elles concernent des concepts
trs gnraux comme le temps, les vnements, lespace, les actions... Ces con-
cepts doivent tre consensuels entre une grande communaut ;
11
Etat de lart
les ontologies gnriques ou mta-ontologies : moins gnriques que les prc-

dentes, mais assez pour tre rutilisables travers plusieurs domaines (exemple
OBOE 1 ) ;
les ontologies de domaine : ensemble de vocabulaires et de concepts qui dcrit
un domaine dapplication, bas sur la connaissance du domaine o la tche est
ralise ;
les ontologies de tches : pour conceptualiser des tches (diagnostic, planifica-
tion...) spcifiques dans les systmes ;
les ontologies dapplication : les plus spcifiques, domaine restreint, destines
lexcution dune tche. Un concept correspond souvent un rle jou par une
entit dans le systme.
Les ontologies peuvent exploiter le fonctionnement du Web de plusieurs manires,
Berners-Lee et al. (2001) :
pour amliorer la pertinence des recherches, par concept,
pour associer une page des structures de connaissance et des rgles din-
frence.
Web Smantique
Lapproche actuelle du Web Smantique, ou Web des donnes, est base sur lide
de travailler, au niveau du Web, partir de concepts plutt que de documents, qui con-
tiendraient alors des informations, ou mtadonnes, formalises pour tre traites au-
tomatiquement par des agents logiciel. Le Web de donnes est fond sur une pile de
langages et protocoles issus du Web et propres au Web Smantique (illustration figure
2.1), conus pour tre compris smantiquement et utilisables par les programmes. Le
W3C 2 supervise le dveloppement des standards, propre aux Web Smantique, comme
RDF 3 , RDFS 4 , OWL 5 ou SPARQL 6 que nous allons dcrire.
RDF : pour Resource Description Framework, Manola & Miller (2004), un langage
pour reprsenter des informations propos de ressources sur le Web. RDF est destin
aux situations o ces informations ont besoin dtre traites par des applications au lieu
dtre seulement affiches pour les personnes. Les informations peuvent tre changes
entre les applications sans perte de sens. RDF est fond sur lide didentifier les choses
en utilisant des URI 7 , et en dcrivant les ressources en fonction de proprits et de
1. OBOE : OBOE : Extensible Observation Ontology
2. W3C : World Wide Web Consortium
3. RDF : Resource Description Framework
4. RDFS : Resource Description Framework Schema
5. OWL : Web Ontology Language
6. SPARQL : SPARQL Protocol and RDF Query Language
7. URI : Uniform Resource Identifier, identificateurs de ressource Web
12
2.1 Ontologies et outils du Web Semantic
F IGURE 2.1 Pyramide des technologies du Web Smantique
valeurs de proprits. De ce fait, on pourra traduire des informations simples sur les
ressources sous forme de graphe, o les nuds reprsentent des ressources et les arcs
les proprits. RDF emploie une terminologie particulire, illustre par la figure 2.2,
pour indiquer les diverses parties des dclarations :
le sujet concerne ce qui est dcrit,
le prdicat correspond la proprit,
lobjet est la valeur de la proprit.
F IGURE 2.2 Reprsentation graphique dun triplet RDF
La srialisation des dclarations, ou triplets, peut avoir diffrents formats, Segaran et al.
(2009) : notation N-Triples 8 (syntaxe verbeuse), N3 9 (syntaxe condense) 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
Etat de lart
(syntaxe officielle).
RDFS : pour RDF Schema, permet de dcrire les ressources du vocabulaire RDF. Il
dfini la notion de classe et de proprit. Il permet de dfinir des hirarchies de classes
et de proprits.
OWL : pour Web Ontology Language, Mcguinness & van Harmelen (2004) et Segaran
et al. (2009), est un langage RDF pour la dfinition de classes et de proprits (RDFS),
mais aussi pour permettre plus de raisonnements et des infrences bases sur les rela-
tions. Ce langage est divis en trois sous-langages dont la complexit et lexpressivit
augmentent. OWL-Lite, le plus simple, OWL-DL 11 , bas sur les logiques de description
et OWL-Full, le plus expressif mais dont la calculabilit nest pas garantie.
SPARQL : pour SPARQL Protocol and RDF Query Language, Prudhommeaux &
Seaborne (2008), SPARQL est un langage dinterrogation standard pour les graphes
RDF. Il est capable de rechercher des motifs de graphe (graph patterns) obligatoires et
optionnels ainsi que leurs conjonctions et leurs disjonctions. SPARQL gre galement le
test extensible des valeurs et la contrainte des interrogations par un graphe RDF source.
Les rsultats des interrogations SPARQL peuvent tre des ensembles de rsultats ou
des graphes RDF. Ce langage dinterrogation ne permet pas, comme le fait SQL 12 pour
les bases de donnes relationnelles, dinsertion, de modification ou de suppression de
triples.
Outils dexploitations
Sesame est un logiciel libre. Ce "framework" Java, dvelopp au dpart par la so-
cit hollandaise Aduna dans le cadre dun projet europen, volue actuellement grce
un projet communautaire et hberg par OpenRDF. Sesame 13 va fournir les fonction-
nalits ncessaires au stockage de triplets RDF ainsi que des librairies dinterrogation
et de manipulation de ces triplets. Sesame va galement fournir le raisonneur RDFS,
subsumption de classes et de proprits par exemple et OWL DLP avec lextension
OWLIM. Il est facilement extensible grce au dveloppement de la communaut, citons
par exemple des adapteurs Jena pour faciliter le passage entre les deux API 14 , Elmo qui
fournit une API, base sur les annotations Java, permettant un mapping entre structure
mtier et ontologie.
11. OWL-DL : Ontology Web Language Description Logics)

12. SQL : Structured Query Language
13. http://www.openrdf.org/
14. API : Application Programming Interface
14
2.2 Web Service
Jena est aussi un outil libre et similaire Sesame. Jena 15 a t dvelopp au dpart par
la socit Hewlett-Packard Labs Semantic Web Programme. LAPI est plus complte
car elle inclut nativement le support de OWL. De plus, ce "framework" Java fournit
galement plusieurs raisonneurs internes et permet lutilisation de Pellet, raisonneur
OWL-DL.
2.2 Web Service

Ils vont permettre de mettre en place larchitecture distribue pour lutilisation dune
plateforme mobile. Il existe deux grands types de Web Service : les architectures REST 16
et lutilisation des standards lis XML 17 .
Les Web Services RESTful sont bass sur un type darchitectures fondes sur les
concepts de ressources et dagents et dveloppes dans la thse de Roy Fielding, Field-
ing (2000). Le principe est quun composant logiciel puisse lire ou modifier une ressource
en utilisant une reprsentation (XML ou JSON 18 par exemple) de cette ressource. Comme
dans le domaine du Web Smantique, lURI a un rle important et doit suffire pour
identifier une ressource. Les services bass sur rest utilise le protocole HTTP, dfini
par le norme RFC2616, voir Fielding et al. (1999). Ce protocole fournit les oprations
ncessaires la manipulation des ressources : GET, POST, PUT, DELETE, etc.. Lin-
convnient de REST est que le client doit conserver localement les donnes, puis que
cest un service sans tat, ce qui peut poser des problmes de charge.
Les Web Services bass sur les technologies du W3C reposent sur un ensemble
de protocoles et de standards utiliss au dpart pour lchange de donnes entre en-
vironnements htrognes. Les trois lments principaux sont SOAP (Simple Object
Access Protocol) pour lchange des messages pour lappel et rponse de mthodes
entre les deux environnements, WSDL (Web Service Description Language) pour la de-
scription des messages changs (type de donnes, oprations...) et enfin les annuaires
UDDI (Universal Description Discovery and Integration) pour le rfrencement et la
dcouverte des Services Web. Linconvnient d la multitude des technologies est la
performance qui est moins importante.
15. http://openjena.org/
16. REST : Representational State Transfer
17. XML : eXtensible Markup Language
18. JSON : JavaScript Object Notation
15
Etat de lart
2.3 La plateforme Smartphone

Un smartphone ou ordiphone peut tre diffrenci dun tlphone portable ou dun
assistant lectronique de poche (ADP) 19 par ses fonctionnalits. Un smartphone intgre
actuellement un client de messagerie, un navigateur web, des fonctionnalits GPS 20 ,
de synchronisation avec des outils dordinateur de bureau type "organiseur" comme
agenda, carnet dadresse, dictaphone (Charlesworth (2009)).
Le systme dexploitation Windows Phone 7 a t choisi pour notre prototype. Ce

systme sera disponible en octobre 2010 mais ds prsent Microsoft met disposition
un ensemble doutils de dveloppement gratuits, savoir :
un mulateur Windows Phone 7,
lEDI 21 Visual Studio 2010 Express pour Windows Phone CTP 22 ,
la plateforme de dveloppement Silverlight pour Windows Phone CTP,
le framework XNA 4.0 Game Studio CTP (destin au dveloppement de jeux, il
na pas t utilis pour notre projet).
Le fait que soit livr un ensemble doutils complets et faciles installer a contribu au
choix de la plate-forme Windows Phone 7. De plus, nous avons choisi Silverlight car
il permet de migrer facilement le prototype Smartphone vers un site web. Enfin, nous
avons particulirement tenu compte des comptences des membres lquipe dans les
techniques lies Silverlight et C# et par-l mme de la future maintenance et volution
du produit.
Lmulateur Windows Phone 7 est une application 23 de type "ordinateur de bureau"

permettant de simuler le systme dexploitation Windows Phone 7. Il fournit un environ-
nement de virtualisation pour dployer, dboguer et tester les applications dveloppes.
Il a t conu pour fournir la mme ergonomie et les mmes performances quun rel
ordiphone. De plus, il requiert les mmes exigences de dveloppement. Toutefois, il ne
fournit pas pour linstant tous les programmes natifs de Windows Phone 7 (e.g. la fonc-
tion de tlphonie, de camera ou de GPS). Ceci na pas t prjudiciable cette version
du prototype car seules les fonctionnalits de rseau (pour la communication avec le
Web Service) et la prsence dune zone de stockage persistante (pour lenregistrement
de la configuration des paramtres utilisateur) ont t utiles.
19. PDA : Personal digital assistant

20. Golocalisation par satellites ou Global Positioning System
21. Environnement de dveloppement intgr
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 crer
des applications Silverlight pour Windows Phone 7. Il permet de dployer lapplication
directement sur lmulateur ou sur un appareil Windows Phone 7.
Silverlight est une implmentation du Framework Microsoft .Net, destine crer des
applications interactives riches (ou RIA 24 en anglais) sur le Web, multiplateformes et
navigateurs Web. Les bibliothques de classes fournies par Silverlight pour Windows
Phone donnent des classes, composants, contrles et lments dinterface utilisateur
spcialement adapts aux applications sur ordiphone Windows Phone 7. Ils correspon-
dent une version amliore de Sivlerlight 3 classique sans offrir toutes les fonction-
nalits de Silverlight 4 (la version actuelle).
Silverlight peut tre dcrit comme un sous-ensemble de la technologie Microsoft Win-
dows Presentation Foundation 25 (WPF) et va notamment donner accs aux fonctionnal-
its de liaison de donnes (data binding en anglais).
Linfrastructure de liaison de donnes est importante pour cette technologie et

pour le modle de programmation dapplications Silverlight. Elle permet de lier linter-
face utilisateur (e.g. une ListBox) un objet de donnes (e.g. tableau dobjet). Il gre
le flux entre les deux : lorsque lun des deux change, les modifications sont rpercutes
automatiquement sur lautre lment par un moteur de liaison. La figure 2.3 montre les
lments qui entrent en jeu dans la liaison 26 .
F IGURE 2.3 Concepts de base dune liaison de donnes
24. Rich Internet Application, dont la premire dfinition et description des fonctionnalits sont
dcrites par Allaire (2002)
25. http://msdn.microsoft.com/fr-fr/library/cc903925%28v=VS.95%29.aspx
26. http://msdn.microsoft.com/fr-fr/library/cc278072%28v=VS.95%29.aspx
17
Etat de lart
XAML XAML (eXtensible Application Markup Language) est un langage de bal-

isage bas sur XML (eXtensible Markup Language). Dans Silverlight, le rle princi-
pal de XAML est de dcrire lapparence visuelle de linterface utilisateur. La logique
est dfinie dans un fichier associ appel code-behind ou code joint. Lavantage de
son utilisation est la sparation des rles des personnes : les concepteurs graphistes
et dveloppeurs de lapplication.
Le code-behind est un objet dun langage du Common Language Runtime (CLR), com-
posant du Framework Microsoft .Net, comme C#. Lorsque lapplication est compile,
la page correspondant au code XAML est partielle et complte par le code joint. Ce
code va permettre notamment la gestion de la logique comme la gestion des vnements
de linterface.
Le patron de conception Modle-Vue-VueModle (MVVM), 27 est un patron de con-

ception architectural bas sur le design pattern Modle-Vue-Controleur (MVC) bien
connu. Ce modle est utilis massivement et fait partie des bonnes pratiques de concep-
tion pour les applications Silverlight. Cest donc ce patron de conception qui structure
lapplication ordiphone du projet avec trois types dobjets : des vues crites en XAML
et C#, des classes ModelVue en C# et des objets modles prsentant les donnes, de
deux types C# et XML. La figure 2.4 28 reprsente les interactions entre les vues, les
donnes et le modle de prsentation. Ici on voit le rle de la liaison de donnes qui va
permettre de lier la vue et le modle de prsentation sans quil soit ncessaire de faire
rfrence la vue et donc de coder la mise jour de la vue et tester les interactions. On
va donc avoir une liaison dynamique entre ces deux composants.
F IGURE 2.4 Schma du modle Modle-Vue-VueModle

Dans ce patron de conception, le modle de prsentation va faire le lien entre le
modle (donnes) et les vues. Dans notre projet, nous avons mis disposition les don-
nes par lintermdiaire dun Web Service RESTFull sous forme de donnes XML, voir
27. MVVM : Model-View-ViewModel en anglais
28. Prsentation du modle disponible ladresse http://live.visitmix.com/MIX10/Sessions/EX14
18
section 4.4. Lexploitation de XML avec Silverlight est possible avec linterface de pro-
grammation LINK to XML 29 .
LINK to XML est proche du modle DOM 30 car le document XML est charg en m-
moire. Le document peut tre interrog ou modifi. LINK 31 est un langage de requtes
proche de SQL 32 ou XPath (non disponible sous Silverlight pour Windows Phone).
29. Complment disponible ladresse : http://msdn.microsoft.com/library/bb308960.asp

30. DOM : Document Object Model
31. LINK : Language Integrated Query
32. SQL : Structured Query Language
19
Chapitre 3
Modles de connaissances
Introduction
Les modles de connaissances, au sein du systme PEA (Personal Eating Advisor),

jouent un rle prpondrant, dans le sens o ils vont permettre une consultation adapte
de linformation et par l mme, guider linterface homme-machine de diffusion. De
plus, ils vont tre un support la rsolution des problmes poss et tre exploits par le
modle de conseils alimentaires.
Deux champs principaux de connaissances sont impliqus dans le systme PEA et

sont la base de la grande majorit des modules ontologiques, ces champs couvrent
le Restaurant du Futur et les consommateurs. Les deux champs sont relis par un bon
nombre de passerelles et vont permettre au systme de rpondre aux problmatiques
du projet, savoir, fournir des conseils alimentaires pertinents et personnaliss un
consommateur. A cette fin, plusieurs relations de dpendance ou de rutilisation vont
exister entre nos modules ontologiques. Par ailleurs, tant dans un contexte complexe
et de recherche, ils sont amens stendre et inclure des concepts de domaines com-
plmentaires, comme par exemple, celui de la perception sensorielle ou de la dit-
tique. Ainsi, nous avons conu nos modles comme une collection de composants on-
tologiques mis en relation et rutiliss, afin de prvoir les futures extensions.
Nous prsenterons, en premier lieu, le processus de conception et lorganisation

gnrale des composants avec leurs interactions, section 3.1, puis nous dtaillerons leur
formalisation dans les sections suivantes.
21
3.1 Processus de conception et interaction entre les com-

posants ontologiques
Processus de dveloppement
Nos ontologies ont t dveloppes en se basant sur la mthodologie "Ontology De-
velopment 101" dcrite par Noy & Mcguinness (2001). Les premire tapes de dtermi-
nation du domaine et de la porte des ontologies, ainsi que, la liste des termes importants
sont joints en annexe B, chapitres 2 et 3.
Pour les dfinir, nous nous sommes, en premier, appuys sur lexistant, cest--dire
les donnes disponibles : les produits, lidentification des employs, les enqutes, etc..
Par la suite, certains pans de connaissances ont t mis en exergue en interrogeant un
expert du comportement des consommateurs et une ditticienne. Enfin, nous avons pris
en compte lexpertise de linstitut au travers darticles scientifiques publis par linstitut
dans le domaine.
Nous avons formalis nos modles de connaissances avec le langage du Web Sman-
tique OWL, standards du W3C. En effet, il apporte plus dexpressivit que les langages
RDF et RDFS, sur lesquels, il sappuie. Et plus prcisment, nous avons utilis les car-
actristiques de OWL DL pour pouvoir raisonner dans un espace qui reste calculable et
dcidable.
Chacun des composants a t dfini laide de lditeur TopBraid. Dans la suite de
ce document, le format de restitution des dfinitions des ontologies peut varier : pseudo
notation UML fournie par lditeur, code Turtle 1 ou format XML/RDF.
Le cas du modle de conseils alimentaires personnaliss

Le modle de conseils est dvelopp par les chercheurs en sciences du comporte-
ment des consommateurs. Son rle est de fournir des conseils pertinents. Durant mon
stage, nous lavons considr comme une bote noire. Afin que le systme puisse tenir
compte des recommandations du modle, nous avons cr une ontologie spcifique,
destine lexpression des recommandations. La figure 3.1 schmatise le principe de
lintgration allant du modle au systme. Les modules ontologiques des consomma-
teurs, des menus et produits sont en entre. Pour la sortie, nous utilisons lontologie des
recommandations ou Advise dans notre projet.
Stratgie de combinaison des composants ontologiques

Un composant, en gnie logiciel, est une unit de composition, avec un contexte de
dpendances explicites. Szyperski complte la dfinition dans Broy et al. (1998) : un
1. Turtle - Terse RDF Triple Language, submission standard W3C rfrence ladresse http://www.
w3.org/TeamSubmission/turtle. Chaque triplet est exprim textuellement de manire compacte.
22
3.1 Processus de conception et interaction entre les composants ontologiques
F IGURE 3.1 Interaction entre le modle de conseils et les ontologies
composant logiciel peut tre dploy indpendamment et peut tre sujet de composition
dun tiers.
De la mme faon, nos composants ontologiques ont des proprits similaires. Ils
sont rutilisables, composs dautres composants, composables et possde une autonomie
relative. La figure 3.2 reprsente, laide de la notation UML, les trois composants ma-
jeurs, savoir :
une ontologie du contexte du restaurant avec la dfinition des menus et de lenvi-
ronnement matriel,
une ontologie pour dcrire les produits,
une ontologie pour dfinir les consommateurs.
F IGURE 3.2 Reprsentation des composants ontologiques majeurs, au travers dun

diagramme de composants UML
23
Nous avons aussi reprsent lontologie des recommandations, Advise, car elle joue en
effet un rle particulier dans notre systme.
Une zone en pointills a t ajoute afin de reprsenter le lien fort qui existe en-
tre lontologie du contexte du restaurant et lontologie des produits. Ceci nous pousse,
souvent tout au long de ce document, ne considrer quune seule ontologie, celle des
produits. En pratique cela est d au fait que nous retrouvons un lien de composition en-
tre les menus et les produits, et que lontologie de description de lenvironnement (table,
chaise, luminosit...) du restaurant reste encore construire.
Sur ce schma, les ontologies sont exploites par deux lments (noeuds) : le mod-
le et le systme de diffusion. Dans les deux cas, des ontologies diffrentes sont actives,
ou utilises, par les acteurs : le contexte, les produits, les consommateurs et les recom-
mandations par le modle de conseils et le contexte/menu et les recommandations par
le systme de diffusion. Ceci correspond au premier type de modularit entre nos on-
tologies.
Une autre caractristique de nos ontologies est la sous-composition et le partage de
composants. Ceci est li la proprit de rutilisation des ontologies. Par exemple, la
figure 3.3 schmatise une partie des relations des ontologies Measure et Diet, que nous
avons spcialement dfinies pour le projet, et dont le but est respectivement de dcrire
les mesures (e.g. masse, prix, etc.) et les rgimes alimentaires des consommateurs.
F IGURE 3.3 Reprsentation des composants Measure et Diet, avec la notation UML
24
3.2 Ontologie des produits du Restaurant du Futur
Lontologie locale des mesures va rutiliser lontologie OUM (cf. section 3.2). Mea-
sure est utilise pour annoter toutes les caractristiques mesurables de nos modles.
Ainsi, elle est utilise pour dcrire les caractristiques physiques (taille, poids...) dun
consommateur, ou encore les caractristiques nutritives dun produit. Au besoin, nous
pouvons connecter le composant des Measure aux ontologies, pour ajouter des types de
connaissances mesures. La dfinition des rgimes alimentaires, Diet sur la figure 3.3, et
des produits sont dautres exemples dutilisation de composants "partags". Ainsi lon-
tologie Sensory&Strucure est utilise par le consommateur pour dcrire ses prfrences
gustatives, tandis que dans le cadre de lontologie des produits on dcrit les gots.
Dans les sections suivantes, nous dtaillerons la modlisation des modules ontologiques
des produits du restaurant, section 3.2, des consommateurs, section 3.3 et enfin la dfi-
nition des recommandations du modle de conseils, section 3.4.

Le but de lontologie du Restaurant du Futur (RoF) est de modliser le contexte dun
restaurant : matriel (disposition des buffets, des meubles, des plats...) et le contenu (le
menu, catgories...). Une ontologie des produits est aussi ncessaire pour dcrire les
produits impliqus dans les menus. Ces modles sont spcifiques notre prototype et
utilisables pour la restitution du menu lutilisateur. Pour cette modlisation, nous nous
sommes appuys sur les donnes acquises concernant les produits et les menus.
Les donnes disponibles sont de plusieurs types :

les catgories et les buffets existants au restaurant ;
la dfinition des menus par saison de trois mois ;
les produits : nom, prix, masse, caractristiques nutritives, vgtarien ou non,
catgories du restaurant dappartenance, buffet o ils sont disposs, disponibil-
it (quotidienne ou variable), etc.
Product est le concept principal de notre modle. Il correspond un lment dun

menu, un aliment solide ou liquide simple (e.g. une pomme) ou plus sophistiqu com-
pos dingrdients (e.g. tagliatelles au saumon). Certains produits sont cuisins sur place
par le chef, dautres labors au-dehors. La figure 3.4, gnre avec lditeur TopBraid,
correspond la dfinition dun produit et montre ses relations avec les autres concepts
du restaurant.
Graphiquement, les proprits dobjets sont prcdes dun rectangle bleu, les pro-
prits de types de donnes dun rectangle vert. Chaque nom de concept ou de pro-
prit est prcd dun identificateur despace de nommage dfini par lutilisateur, ici,
25
prod correspond lespace de nommage http ://www.wurvoc.org/rof/product# et meas

http ://www.wurvoc.org/rof/measurement#. Lespace de nommage, dans les standards
du W3C, correspond un vocabulaire spcifique. Diffrents espaces de nommage per-
mettent ainsi de tirer parti de diffrents vocabulaires et structures dans une ontologie,
lutilisation didentificateurs permet de rendre la prsentation plus lisible et dviter
toute ambigut entre les structures exploites. Ainsi, lentit Product fait rfrence
deux vocabulaires qui correspondent la dfinition du module ontologique des produits
et au composant des mesures, dtaill section 3.2.
Lentit Product est caractrise par plusieurs types de proprits qui vont porter
sur : ses caractristiques mesurables ou non et sa place dans le contexte du restaurant.
F IGURE 3.4 Ontologie pour dcrire les produits disponibles au RoF
26
Lillustration dun produit est donne par la proprit hasIcon de cible un nom
du fichier. La gestion de laffichage de limage se fera ensuite par lapplication. Cest
une proprit importante au niveau du domaine dapplication, car laspect des plats entre
en jeu lors de du choix de certains consommateurs. Cette proprit est aussi utilise par
le concept Category. Un produit qui na pas dillustration, utilise celle de sa catgorie.
La localisation des produits et des buffets dans le restaurant va permettre de

mettre en place, laide laccs aux produits en vitant le phnomne de tentation :
alerte visuelle, tactile ou chemin optimal (cf. section 1). Pour rpondre ce besoin, la
proprit hasLocalisation de domaine Product ou Category a t ajoute. Dans cette
version, la localisation est reprsente pour lapplication par un nom de fichier de carte
prdfinie du restaurant avec un buffet mis en surbrillance (cf. fig. 3.5). Si nous navons
pas la localisation dun produit, sa localisation est celle du buffet.
F IGURE 3.5 Exemple de localisation du buffet des soupes
La reprsentation de lagrgation de produits dans des catgories, sur des buf-

fets ou pour les menus est tablie au travers des proprits dobjets belongsTo et aggre-
gates (cf. figure 3.4). La figure 3.6, gnre avec TopBraid, reprsente leur dfinition.
Ces proprits sont inverses, la proprit belongsTo a pour domaine Product et dimage
forme par lunion des concepts Buffet, Category et Menu ce qui signifie quun produit
peut appartenir des menus, des catgorie ou des buffets. La proprit aggregates va
permettre daccder aux produits en partant de llment regroupant : catgories, menu
ou mme localisation. Cette dfinition facilite la navigation entre les lments et laccs
aux produits.
Dans notre modlisation, nous avons favoris lutilisation de relations entre nos pro-
duits dautres concepts car cette structuration est souple et va permettre de faire voluer
la catgorisation des produits. Par exemple, les produits laitiers sont actuellement rpar-
tis dans deux catgories du restaurant : "beurre et sauce" et "dessert". Or, pour identifier
les produits base de lait de vache (en cas dintolrance par exemple), nous allons avoir
27
besoin de nous appuyer sur un autre type de connaissances et utiliser lontologie des
produits laitier, dj existante.
Lide des proprit belongsTo et aggregates est de reprsenter le concept de com-
position. Odell (1998) dfinit la composition comme un mcanisme servant former un
objet entier en utilisant dautres objets comme parties. La reprsentation de la composi-
tion est un sujet en dveloppement dans le cadre du W3C, voir Rector & Welty (2005)
sur la reprsentation de la composition. En effet, elle nest pas native au formalisme
comme peut ltre la spcialisation et ncessite un modlisation manuelle.
F IGURE 3.6 Dfinition de la proprit belongsTo
Les caractristiques mesurables des produits sont dfinies laide du vocabu-

laire dun composant que nous avons dfini Measure. Nous avons choisi de modliser
ce concept par une relation n-aire entre :
une variable ou Metrological_concept ;
une unit Unit_of_measure ;
une valeur qui peut tre numrique, boolenne ou symbolique.
Le but est de pouvoir reprsenter, par exemple, qu"une portion de tiramisu a une masse
de 85 grammes".
La difficult ici a t de reprsenter une relation n-aire, entre plusieurs lments,
alors quen gnral les proprits dans le Web Smantique sont des relations binaires
entre deux instances. La solution choisie est celle qui est aussi explicite dans le doc-
ument du W3C de Noy & Rector (2006), cest--dire lintroduction dune classe pour
une relation, ici le concept de MeasurementCharacteristic. Le listing 3.1, reprsente la
dfinition, en Turtle, du concept que nous avons appel MeasurementCharacteristic.
Une proprit hasValue avec comme sous-classe hasNumericalValue va nous per-
mettre de renseigner la valeur de la mesure. Deux autres proprits dobjet vont venir
complter linformation de la valeur savoir measureOf et hasUnitOfMeasure pour
la variable mesure et lunit de mesure. Ces trois proprits sont fonctionnelles (cf.
28
annexe E, listings E.1 et E.2), cest--dire que pour une instance de MeasurementChar-
acteristic ces proprits auront une unique instance.
Listing 3.1 Code Turtle de la dfinition de MeasurementCharacteristic
meas: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
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
owl:onProperty meas:hasUnitOfMeasure
] ;
rdfs:subClassOf
owl:cardinality " 1 " ^^xsd:nonNegativeInteger ;
] .
Linstanciation des proprits measureOf et hasUnitOfMeasure est rendue obliga-

toire par lindication de cardinalits avec le langage OWL (restriction cardinality). De
plus, lintersection des restrictions sur lunit et la variable mesures va permettre, par
infrence dun raisonneur, de dfinir par restriction les lments de la classe Measure-
mentCharacteristic directement par les proprits de linstance. La figure 3.7 montre
lorganisation des concepts, notamment la rutilisation de lontologie OUM 2 (Ontology
of Units of Measure) dveloppe par mon quipe daccueil et dcrite par Rijgersberg
et al. (2010). Lutilisation de cette ontologie permet de dlguer le lien et la smantique
de lunit et de la variable et leur lien lontologie importe. Seule la notion de devise,
que nous avons ajoute, manquait pour dcrire les prix des produits. Enfin, lutilisation
de OUM permettra, dans le futur, de lier les autres applications bases sur OUM et no-
tamment daccder facilement au Web Service de conversion dunits 3 . La figure C.1
2. Disponible ladresse http://www.wurvoc.org/vocabularies/om-1.6/
3. Disponible ladresse http://www.wurvoc.org/services/oum.jsp
29
de lannexe E reprsente les instanciations de lexemple prcdent grce au concept de

MeasurementCharacteristic.
F IGURE 3.7 Concepts des caractristiques mesurables
La sous-classe NutritiveCharacteristic de MeasurementCharacteristic possde gale-

ment la proprit nutrient qui va nous permettre de modliser les caractristiques nutri-
tives des produits. Le principe est le mme que prcdemment, sauf que la variable est
dpendante du nutriment. Par exemple, la dose de sucre contenue dans la pomme est en
fait une masse de sucre, lannexe E, figure C.2, montre sa reprsentation. Pour grer la
smantique du nutriment, nous avons rutilis lontologie dveloppe par mon quipe
daccueil, qui est en fait une taxonomie des nutriments (cf. fig. 3.8).
Lontologie dveloppe ici, pour dcrire les produits et leurs rles dans le restau-
rant, est faite en fonction des connaissances dj disponibles dans le projet FOVEA et
au RoF. Elle reste suffisante tant que le modle nest pas stabilis mais devra voluer
assez rapidement dans un premier temps avec lintroduction de la notion dingrdients,
puis dans un second temps avec lannotation des produits par rapport leurs origines et
leurs sensations et structures gustatives.
30
3.3 Ontologies pour les prfrences des consommateurs
F IGURE 3.8 Extrait de la taxonomie des nutriments

Lobjectif du projet est de proposer des conseils personnaliss aux consommateurs et
de les aider faire les bons choix pour une alimentation adapte. Ces conseils ou recom-
mandations sont personnalises en fonction des caractristiques du consommateur et de
ses prfrences. Dans le domaine applicatif de mon projet, une des originalits est de
tenir compte de ces prfrences alimentaires. Ces connaissances alimenteront le modle
de conseils. Les recommandations produites porteront sur le contenu dun menu mais
aussi sur la forme du message.
La dfinition du modle sest faite en deux phases : la premire assez gnrale, grce
la littrature scientifique du domaine et la seconde plus "applique". Cette dernire est
base sur nos trois profils et sur les donnes disponibles, savoir :
identit de la personne, accessible grce ladministration de linstitut,
rsultat dune enqute (mode de vie, interaction avec la nourriture, etc.),
gots alimentaires au restaurant (historique des prcdents repas).
Ainsi, plusieurs composants ontologiques ont t produits. Ils pourront tre assembls et
complts en fonction des besoins du modle. La version intgre dans la mise en oeuvre
du prototype est plus lgre et ne contient que lextension de lentit de la personne et
les rsultats de lenqute.
La dfinition dun consommateur est actuellement lie son identit au sein de

ltablissement. Les donnes seront issues directement des bases de donnes de linsti-
tut. Par exemple, la figure 3.9 montre une instanciation du concept Consumer. John est
dfini par son identit : nom, prnom, anne de naissance, numro de carte demploy.
Ce sont des proprits de type de donnes. Il est noter que la classe Consommateur
31
est dfinie avec des restrictions sur la cardinalit exprimant le caractre obligatoire de
ces proprits. Notamment le WURCardNumber, identifiant de lemploy linstitut,
est sous forme XML de type :
<owl:Restriction>
< 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 . o r g / 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 r g / r o f / c o n s u m e r #
hasWURCardNumber " / >
</ owl:Restriction>
F IGURE 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). Kster (2009) reprend, dans son article, lap-
proche de Jos Mojet, experte en science des consommateurs lInstitut de recherche
de Wageningen, pour exprimer la complexit du domaine et les diffrents aspects. Elle
dcrit en 2001 (cf. annexe C) les diffrents facteurs qui influencent le comportement du
choix des consommateurs concernant lalimentation. Nous avons adapt cette proposi-
tion pour certains de nos composants ontologiques, puisquune partie correspond bien
au domaine tudi dans le cadre des recherches menes au Restaurant du Futur.
Les aspects biologiques et physiologiques correspondent aux caractristiques de

la personne : physiques, gntiques, etc.. Au niveau modlisation, nous avons diffren-
ci les caractristiques mesurables (taille, poids par exemple) des autres caractristiques
(sexe de la personne). De plus, la proprit dobjet hasPhysicalProperty, drive par
la suite en fonction des diffrentes caractristiques physiques de lutilisateur permet
dune part, de pouvoir naviguer directement jusquaux caractristiques physiques du
consommateur, dautre part, de contrler la signature de la relation (domaine et image)
de chacune des sous-proprits. Par exemple, listing 3.2, la proprit hasWeight possde
pour domaine un objet de type Consumer et dimage une instance de concept Weight.
Enfin, ce choix de modlisation nous permettra de rcuprer lensemble des proprits
physiques par lutilisation directe de la proprit mre, ce qui est utile dans le cas de
gnration dinterface.
32
Listing 3.2 Code Turtle de la dfinition de hasWeight

cons:hasWeight
a owl:ObjectProperty ;
rdfs:domain cons:Consumer ;
rdfs:label " h a s w e i g h t " ^^xsd:string ;
rdfs:range cons:Weight ;
rdfs:subPropertyOf cons:hasPhysicalProperty .
Pour dfinir les mesures nous avons rutilis la dfinition de MeasurementCharac-

teristic, dcrite dans le listing 3.1, qui va nous permettre de lier une variable, une unit
et une valeur. Pour linstant, les principales variables physiques sont dfinies, savoir :
taille, poids et IMC. Nous les avons dfinies en plusieurs tapes. La dfinition en code
Turtle du listing 3.3 du concept de poids montre que nous avons cr, dans un premier
temps, une sous-classe du concept de mesure ; puis, nous avons affin sa dfinition par
restriction la mesure du poids oum :height et en rendant la date de mesure obligatoire.
Lobjectif ici tait de faciliter lacquisition des donnes puisque seule la dclaration
dune mesure de type Height est suffisante pour le raisonneur pour avoir le type de
variable mesure. De plus, il permet un contrle plus fin des informations ncessaires
comme dans le cas de la date et du poids.
Listing 3.3 Code Turtle de la dfinition de Weight

cons:Weight
a owl:Class ;
rdfs:label " Weight@en " ^^xsd:string ;
rdfs:subClassOf meas:MeasurementCharacteristic ;
rdfs:subClassOf
owl:hasValue oum:weight ;
] ;
rdfs:subClassOf
owl:onProperty meas:hasDateOfMeasure
] ;
meas:measureOf oum:weight .
Les proprits physiques de la personne dans notre cas sont les plus pertinentes, car
elles suffisent aux ditticiens pour donner des premires recommandations. De ce fait,
nous avons fait voluer le concept de Consumer pour y ajouter des cardinalits plus
prcises (cf. annexe F).
Les facteurs psychologiques et lis au contexte entrent aussi en compte lors du

choix des aliments. Il sagit, par exemple, de la motivation, des habitudes alimentaires
ou de vie. Pour modliser ces derniers, je me suis appuye sur lenqute faite auprs des
consommateurs du restaurant. Dans ltat actuel du projet, cest lune des sources im-
portantes pour les chercheurs, puisque lacquisition doit se faire le moins intrusive pos-
sible pour ne pas influencer le comportement des consommateurs. Lenqute est donne
33
en annexe A. Elle couvre galement le domaine des facteurs contextuels, comme le

cadre de vie. Au niveau modle, nous avons dfini des concepts, comme Household qui
reprsente le foyer de la personne (cf. annexe D, fig. D.1), lequel va tre caractris
grce des proprits par le nombre denfants, le statut marital, la localisation ainsi que
par les habitudes dachats du foyer. Il sagit du concept de ShoppingHabit qui permet
de connatre le type daliments achets (produits du commerce quitable par exemple),
le type de magasin et la frquence dachat.
Sur le mme principe que prcdemment, nous avons modlis le concept de lactivit
sportive dune personne (cf. annexe D, fig. D.2) avec des proprits dobjet pour le type
de sport, la frquence et le niveau.
La modlisation de ces notions est faite sur le mme principe : un lment central (Shop-
pingHabit ou SportiveActivity ) li par des proprits (inShopOfType ou concerned-
Sport) des concepts de type (par exemple : les magasins dalimentation FoodProduct-
ShopType ou les types de sports disponibles Sport). Lavantage ici est que, si le besoin
apparat de dfinir plus finement les concepts des types de magasins ou les diffrents
sports, nous pourrons faire voluer facilement notre ontologie de base en crant ou im-
portant de nouvelles connaissances produites par dautres organismes comme la FAO
par exemple pour les magasins ou le lien vers une ontologie des sports.
La notion de rgime alimentaire est un concept que nous avons commenc reprsen-
ter ici. Dautres ontologies et structures de connaissances existent mais restent bien sou-
vent trop orientes vers le domaine de la sant par rapport au domaine du projet et trop
complexes par rapport nos besoins en matire de prototypage. Lide ici tait plutt
dessayer de reprsenter le type de rgime alimentaire souhait par un consommateur,
ainsi que ses objectifs. Pour dbuter, nous nous sommes appuys sur nos trois profils.
Ce composant ontologique minimal fait intervenir plusieurs types de facteurs dcrits et
illustrs par Kster (2009). La figure 3.10 illustre cette modlisation. Un consommateur
peut avoir un ou plusieurs rgimes alimentaires : DietPreference. Ce concept intgre
la reprsentation dune relation n-aire de proprits dobjets. adviser reprsente celui
qui est lorigine de cette prfrence. En effet, la base, le consommateur lui-mme
veut suivre un rgime particulier, par exemple "manger biologique". Le systme/ditti-
cien aura galement un objectif pour le consommateur, par exemple un rgime avec peu
dhydrates de carbone. Le modle devra ensuite grer ces souhaits et ou ces conflits et
produire des conseils. La proprit reason et son image ReasonType correspondent la
notion de facteur de motivation et de facteur contextuel socio-culturel (la religion ou le
dsir de salimenter partir des produits issus du commerce quitable par exemple). Ce
concept est associ au concept de niveau dimportance dfini pour linstant simplement
par ses instances :
Listing 3.4 Code Turtle de la dfinition dImportanceLevel

:ImportanceLevel
34
3.4 Ontologies de recommandations
a owl:Class ;
owl:oneOf ( :AbsoluteImportance :HighImportance :LowImportance :MediumImportance )
.
Un rgime alimentaire prfrentiel est aussi dfini par un type de rgime : DietType.
Ce concept peut nous permettre de dfinir des rgimes et est schmatis figure 3.11.
Cette figure illustre quil est possible dindiquer limportance donne au prix ou len-
vironnement dans ce type de rgime. De plus, la proprit involved, dfinie listing 3.5,
est spcialise en sous-proprit avoided, favored, needed et prohibited. Ces proprits
vont permettre de dfinir les implications entre le rgime et :
un nutriment (de lontologie sur les nutriments), par exemple le rgime "low_calory_diet"
avoided energy ;
un produit (du restaurant), par exemple le rgime "without_tiramisu_diet" prohib-
ited tiramisu ;
un allergne (de lontologie Allergens 4 )), par exemple le rgime "peanut_intolerant_diet"
prohibited Peanut ;
une perception (de lontologie Sensory_and_structure 5 )), par exemple le rgime
"chocolateFlavour_favored_diet" favored ChocolateFlavour.
Listing 3.5 Code Turtle de la dfinition dinvolved

: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 rgimes alimentaires

vont donc nous permettre de formaliser :
lidentification du consommateur ;
ses caractristiques biologiques et physiologiques ;
les aspects psychologiques lis ses habitudes de vie ;
le rgime alimentaire souhait / ncessaire la personne.

Dans notre projet, le Personal Eating Advisor Model, ou modle de conseils, fournira
des "recommandations" (ou Requirements) offrant les fonctionnalits suivantes :
4. Ontologie dveloppe par lquipe IM-WUR : http ://www.wurvoc.org/allergens
5. Ontologie dveloppe par lquipe IM-WUR : http ://www.wurvoc.org/sensory_and_structure
35
F IGURE 3.10 Reprsentation de la prfrence dun rgime alimentaire
F IGURE 3.11 Reprsentation des types de rgimes alimentaires
36
conseiller ou viter certains lments du menu (produit, buffet ou catgorie),

cibler les caractristiques pertinentes pour le consommateur (personnalisation du
contenu du message),
guider laffichage des informations et conseils au niveau de linterface utilisa-
teur(Smartphone).
Ne connaissant pas encore la forme de la sortie des "recommandations", jai choisi

de modliser un composant ontologique permettant de formaliser les "recommanda-
tions". Cette modlisation pourra ainsi utiliser les mmes concepts (vocabulaire con-
trl) dfinis prcdemment pour les produits et les consommateurs. Les "recommanda-
tions" ainsi modlises seront utilises pour exploiter les connaissances disponibles sur
le menu du jour et les produits et ainsi fournir les fonctionnalits attendues du modles
de conseils.
F IGURE 3.12 Ontologie pour dcrire les conditions pour le repas
Pour la modlisation, je me suis appuye sur les profils dfinis avec les chercheurs
et dgager les conditions types pouvant tre fournies par le modle de conseils. De plus,
nous avons montr le scnario de John une ditticienne qui a nous a donn le type de
conseils dittiques quelle aurait pu prescrire.
37
Techniquement, lide est quen sortie du modle de conseils, une instance du con-
cept AdvisedLunch soit cre. Cette instance est compose de :
Une collection de conseils ou dAdvice La figure 3.12 montre que chacun des conseils
peut tre isAdvised ou isAvoid. Ils peuvent concerner (relation concernType) un
concept de lontologie 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 caractristiques de llment : Requirement ou qui con-
cernent des variables mesures : MeasurementCharacteristic ou NutritiveCharac-
teristic. La capture dcran de lditeur TopBraid, figure 3.13, illustre la reprsen-
tation de lexpression "John doit prendre des produits qui appartiennent la cat-
gorie des salades et qui ont la proprit davoir une prsentation naturelle 6 ".
F IGURE 3.13 Capture dcran TopBraid, conseil pour John de prendre une salade
frache
Une caractristique pertinente pour le consommateur Il sagit ici de dfinir une Mea-
surementCharacteristic ou une NutritiveCharacteristic prfrentielle pour John.
Cette variable a pour porte le repas complet et peut tre associe des conditions
MeasurementCharacteristic ou NutritiveCharacteristic qui vont permettre dex-
primer le fait par exemple que John ne devrait pas ingrer plus de 600 kcal durant
son repas (cf. figure 3.14). Par la suite, nous verrons que cette caractristique est
affiche en priorit et est associe un traitement particulier dans lapplication
Smartphone.
6. Par opposition aux salades sous film disponibles au restaurant
38
F IGURE 3.14 Recommandation globale dun repas de 600 kcal maximum pour John
(TopBraid)
La notion de tentation durant le choix des produits est associe au concept Tempta-
tionMode. Il possde la proprit owl :oneOf contenant trois instances fullTemp-
tation, moderateTemptation et freeTemptation.
Le mode daffichage donn par le concept TypeOfDataDisplayAdvice va avoir des con-
squences pour lapplication Smartphone. En ce qui concerne notre version, seule
le mode rawData existe et est implment dans notre systme.
Conclusion
Nous avons modlis plusieurs composants ontologiques rutilisables, composables
dontologies locales (e.g. Measure) ou externes (e.g. OUM) et combinables en fonction
des besoins afin davoir un ensemble de connaissances volutives. Ces composants on-
tologiques ont t modliss partir des donnes disponibles, par discussion avec les
experts du domaine et de lexpertise de linstitut de recherche travers la littrature
produites dans le domaine.
Trois principales structures ont ts produites et permettent de formaliser les con-
naissances suivantes :
le contexte du restaurant : le menu, les catgories, les buffets avec les ali-
ments ou produits disponibles accompagns de leurs caractristiques (nutritive,
prix, etc.) ;
39
le consommateur : identit, caractristiques physiques, ducation, habitude ali-

mentaire, activit sportive, etc. ainsi que le rgime alimentaire souhait ou nces-
saire ;
les recommandations du modle de conseils : collection de conseils permettant
dannoter les lments du contexte du restaurant comme "conseills" ou " viter",
dfinition de caractristiques pertinentes, le type de gestion de la tentation et le
mode daffichage conseill.
La suite de ce document est consacre la mise en oeuvre oprationnelle de nos
ontologies travers un environnement de connaissances. Son exploitation par la pre-
mire version de notre prototype de diffusion de conseils alimentaires personnaliss est
consultable depuis une plateforme mobile type Smartphone.
40
Chapitre 4
Mise en uvre au travers dune

architecture logicielle
Introduction
Des modles de connaissances appropris ont t dfinis (voir chapitre 3), afin de
satisfaire les exigences fonctionnelles du systme PEA (Personal Eating Advisor). Ces
exigences portent sur lapport de conseils alimentaires personnaliss et adapts, aux
consommateurs du Restaurant du Futur. A cet effet, les modles de connaissances con-
struits, se consacrent la reprsentation des aliments et des menus du jour proposs aux
consommateurs par le restaurant, ainsi qu la reprsentation du profil du consommateur
et aux recommandations qui peuvent lui tre faites en terme dalimentation.
Il sagit maintenant de proposer une mise en uvre de ces modles, de mettre en

place un prototype du systme de diffusion de conseils alimentaires personnaliss, et
ainsi de valider notre approche, base sur de la connaissance et sur les technologies du
Web smantique. Le prototype mettre en place, doit rpondre plusieurs contraintes
imposes par le systme PEA, et qui concernent la personnalisation du menu et du
message diffus, les feedbacks ou ractions du systme et enfin la mobilit. Les solutions
apportes pour la prise en charge de ces contraintes sont dtailles ci-dessous :
La personnalisation du menu du jour nous oblige considrer chaque consomma-

teur de manire diffrente. Lide retenue, est dajouter des annotations aux lments
du menu afin dorienter ces lments du menu vers des profils de consommateurs. Ainsi
par exemple, une annotation qui a pour proprit le statut et comme domaine de valeurs
(" viter", avoid en anglais et "conseill", advised en anglais), a t dfinie. La dter-
mination du statut sappuie sur les recommandations mises par le modle de conseils
(cf. sections 3.1 et 3.4).
41
Mise en uvre au travers dune architecture logicielle
La personnalisation du message diffus permet de dterminer les informations qui

vont savrer pertinentes afficher, ainsi que leur format daffichage. Pour cette pre-
mire version du prototype, nous nous sommes limits une seule caractristique per-
tinente mesurable. La pertinence sera dtermine par la suite par le modle de conseils.
Toutefois, dans le cadre de notre prototype, la caractristique considre est paramtra-
ble et manipule laide de lontologie des recommandations. De la mme manire, le
format donn au message, sera, dans le futur, dfini par le biais du modle de conseils,
mais demeure, pour cette version, limit laffichage des donnes de base (variable,
valeur et unit).
Les ractions du systme au choix des utilisateurs vont se traduire, pour notre proto-
type, par limplmentation de la notion de plateau virtuel. Cette fonctionnalit permettra
davoir un retour global sur lensemble des produits choisis. Lutilisateur aura ainsi la
possibilit de simuler son repas et dajuster ses choix.
La mobilit est ncessaire pour que lutilisateur puisse avoir linformation disposi-
tion alors quil est en train de faire son choix. Cet argument a jou en faveur du choix
dune plate-forme de consultation ordiphone, ou Smartphone en anglais.
La premire section de ce chapitre est consacre la prsentation gnrale de larchi-

tecture logicielle mise en place, et du processus de personnalisation. La section suivante
traite de la mise en oeuvre oprationnelle dun systme base de connaissances (SBC),
section 4.2. Puis les sections 4.3, 4.4 et 4.5 dcriront, respectivement, la mise en oeuvre
de la couche mtier, la mise disposition des ressources et lapplication de consultation
sur Smartphone.
4.1 Architecture du prototype PEA et dmarche de per-

sonnalisation
4.1.1 Architecture
Le prototype mis en place, figure 4.1, est constitu de plusieurs lments : un sys-
tme base de connaissances, un module mtier, un Web Service, et une application sur
Smartphone.
Systme base de connaissances (SBC) : son rle est de permettre le stockage et l-
exploitation de nos connaissances. Il contient les composants ontologiques dvelop-
ps (cf. section 3), une base de faits contenant les profils des consommateurs, ainsi
que les menus, les produits et leurs caractristiques.
42
4.1 Architecture du prototype PEA et dmarche de personnalisation
F IGURE 4.1 Architecture gnrale du prototype
43
Module dacquisition : son rle est de convertir les donnes acquises sous format
texte, en faits. Ce module est un module annexe, qui permet dalimenter la base
de faits partir dinformations manant du restaurant
Modle de conseils : son rle va tre dinterroger le SBC afin de consulter les connais-
sances sur le consommateur et le menu du jour, puis de produire les recommanda-
tions alimentaires personnalises sur les produits qui vont influer la constitution
du menu et laffichage des informations associes. Limplmentation de ce mod-
le nentre pas dans le cadre de mon stage.
La couche mtier : est constitue de deux modules. Le premier module a pour but de
convertir nos connaissances en objets mtiers, manipulables par les procdures
de cration de menu. Le deuxime module a pour objectif de constituer partir
du menu du jour un menu "mtier" personnalis pour un consommateur. Trois
grandes fonctionnalits sont ncessaires :
le marquage dlments du menu ou du contexte du restaurant (produit, cat-
gorie ou buffet) comme tant "conseill" ou " viter" ;
la gestion de la caractristique principale ;
la gestion de la tentation par suppression des produits considrs comme
viter ;
la gestion au niveau des classes mtier du plateau virtuel de lutilisateur.
Web Service : permet de mettre disposition les informations sur le menu du jour
fourni par le restaurant, comprenant galement les produits figurant dans le menu
et leurs caractristiques. Pour un consommateur identifi, son menu "personnal-
is" est galement restitu au travers du Web Service.
Lapplication Smartphone : est une application qui facilite la consultation du menu
et gre la manire dont sont affiches les informations sur linterface face aux
recommandations mises par le systme.
4.1.2 Dmarche de personnalisation

Nous avons spar dans notre prototype, les connaissances, gres par le SBC, les
traitements mtiers dvelopps sous forme de modules logiciels et linterface de con-
sultation (lordiphone). La dmarche choisie, commence par fournir aux utilisateurs du
systme, un menu de base qui correspond plus prcismemt celui du jour de la con-
sultation. Ce menu consultable nest donc pas immdiatement personnalis, les donnes
sont au format texte et la caractristique pertinente est choisie par dfaut pour le sys-
tme, savoir, la quantit de calorie dun produit (exprime en kilocalorie). Lide est
que lorsquun utilisateur "connu", pour lequel il existe un profil dans notre base de con-
naissances, se connecte, le systme :
1. cre un menu mtier, identique au menu gnral par copie,
44
4.2 Mise en uvre oprationnelle dun systme base de connaissances
2. extrait de la base de connaissances les recommandations associes lutilisateur,

3. applique chacune des rgles mtiers : annotation (advised ou avoid) des lments
et gestion de la tentation,
4. prpare le message diffuser en fonction de la caractristique pertinente issue des
recommandations,
5. met en place, pour lutilisateur, un objet mtier correspondant son plateau virtuel,
concept de Tray dans notre projet, paramtr grce aux recommandations (par ex-
emple lingestion de 600 kcal par repas).
Nous avons choisi de modifier un objet mtier plutt que directement des connaissances
car certaines rgles de personnalisation peuvent, par exemple, ncessiter des calculs.
Nous avons galement choisi de grer, autant que possible, les traitements mtier
sur le serveur et non pas sur lapplication de consultation. Par exemple, le contenu du
plateau virtuel est gr au niveau de lapplication principale et non pas sur le Smart-
phone. De cette manire, le dploiement de lapplication, qui peut tre distribu sur
plusieurs plateformes, va savrer facilit. Enfin la plate-forme de consultation aura tout
de mme la charge du mode daffichage, la disposition des lments sur linterface,
car ces derniers lments demeurent trs dpendants de la configuration des machines
clientes.
4.2 Mise en uvre oprationnelle dun systme base

de connaissances
Lobjectif principal dun systme base de connaissances est dexploiter des con-
naissances dun domaine, afin de permettre la rsolution de problmes pouvant tre
complexes dans le champ de ce domaine. Le Ber et al. (2006) prcise cette dfinition en
ajoutant que ces connaissances doivent tre de plus rendues disponibles et stockes cet
effet. La mise en uvre sadosse alors une architecture comprenant : une base de con-
naissances relative au domaine, une base de faits ou donnes caractrisant le problme,
et enfin un moteur dinfrence dont le rle est de manipuler les bases pour conduire un
raisonnement menant la rsolution dun problme.
Larchitecture propose (figure 4.1 ) pour le prototype sappuie sur le "framework"

smantique Sesame, voir section 2.1. Sesame va fournir les fonctionnalits ncessaires
au stockage de triplets RDF ainsi que des librairies dinterrogation et de manipulation
de ces triplets. Sesame va galement fournir le raisonneur RDFS et OWL DLP avec
lextension OWLIM. Le choix de Sesame dans ce travail, est en accord avec la large
utilisation qui est faite de cet outil au sein de mon quipe daccueil. Certains membres
de lquipe participent, dailleurs, activement ses volutions et enrichissements et ap-
45
partiennent la communaut qui supporte ce projet de dveloppement.
La mise en oeuvre du prototype sarticule autour de trois lments dimportance qui

sont abords dans le dtail dans cette section, savoir, un serveur de stockage RDF, un
jeu de donnes venant alimenter le rfrentiel de connaissances et un module logiciel
dexploitation de la base RDF adoss lAPI Sesame et au langage SPARQL.
4.2.1 Vocabulaire partag

Afin de pouvoir exploiter dans lapplication les concepts prsents dans nos ontolo-
gies, nous avons dfini un paquetage java structurant le vocabulaire de nos ontologies.
Pour chaque composant ontologique utile, nous avons dfini une classe qui est carac-
tris par des membres statiques comme lespace de nom, le prfixe et les concepts,
proprits et instances remarquables, qui nous sont dutilit. Lannexe H montre la
reprsentation UML partielle de ce paquetage.
4.2.2 Serveur de stockage de donnes RDF

Notre environnement de connaissances a pour lment central un serveur de base de
donnes RDF afin de donner plus de flexibilit au systme. Il sagit aussi den faciliter
laccs en mode distribu. Diffrents modules, notamment dacquisition et de consul-
tation de donnes vont pouvoir se partager les accs avec le serveur de triplets. Dans
ce sens, nous avons mis en place un moteur de servlets Tomcat, et nous avons dfini
des servlets permettant la connexion avec la base de donnes construite sous Sesame.
Larchitecture retenue, nous donne galement accs une interface dadministration de
la base, OpenRDF Workbench, qui savre trs pratique en terme de fonctionnalits :
interface dinterrogation, gestion et dexploration du dpt, etc..
4.2.3 Lacquisition de donnes RDF et la constitution du jeu de tests

Les graphes RDF relatifs aux personnes ont t crs manuellement avec loutil
TopBraid. Nous avons instanci nos composants ontologiques des prfrences des per-
sonnes et des recommandations avec les scnarios de John, Wim et Esther.
Le graphe RDF du contexte et des produits du RoF est produit automatiquement,

au travers dun composant logiciel dfini au sein de notre application (appel toSesame,
sur le schma figure 4.1). Ce module dfini en java permet linstanciation du contexte
du restaurant, des catgories et des buffets. Il permet galement dinstancier, partir de
fichiers textes dans un format propritaire que nous avons nous mme dfini, les menus,
par saison de trois mois et les produits disponibles avec toutes leurs caractristiques, et
46
en particulier les caractristiques nutritives. Cette deuxime phase est cependant semi-
automatique, elle ncessite en effet une phase de validation et de consolidation, avec par
exemple lajout dun fichier dillustration pour ce qui concerne les produits.
Limplmentation du composant logiciel Java de conversion est base sur lAPI

Sesame. La premire tape est de crer un rfrentiel RDF, puis dy ajouter les triplets
crs et enfin de lexporter. La construction des triplets est base sur la lecture des
fichiers au format propritaire. Un problme rencontr porte sur "lclatement" de lin-
formation, ce qui nous oblige incrmenter dynamiquement le graphe des triplets, au
regard des donnes dj instancies. Un exemple en est lajout du prix un produit in-
stanci au pralable, listings 4.1 et 4.2. Il sagit, dabord, didentifier le produit dans le
graphe RDF laide de son identifiant (iddb) de base de donnes (cf. listing 4.1), Puis,
listing 4.2, dinstancier une mesure du prix avec sa valeur et son unit et enfin de mettre
en relation cette instance avec celle du produit.
Listing 4.1 Recherche de linstance de produit

StringBuilder query = new StringBuilder ( ) ;
query . append ( " SELECT ? p r o d " ) ;
query . append ( " WHERE { " ) ;
query . append ( " ? p r o d a < " + PROD . PRODUCT + " > . " ) ;
query . append ( " ? p r o d < " + PROD . HAS_DATABASEID + " > \ " " + iddb + " \ " . " ) ;
query . append ( " } " ) ;
TupleQueryResult result = con . prepareTupleQuery ( QueryLanguage . SPARQL , query . toString ( ) )
. evaluate ( ) ;
Listing 4.2 Ajout du prix un produit

i f ( idProd ! = n u l l ) { / / we f o u n d 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 t
URI 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 c
con . add ( idMeasure , RDF . TYPE , MEAS . MEASUREMENT_CHARACTERISTIC ) ;
/ / add p r i c e t o p r o d u c t w i t h 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 t
con . add ( idProd , MEAS . HAS_MEASUREMENT_CHARACTERISTIC , idMeasure ) ;
/ / add t h e v a l u e o f p r i c e
con . add ( idMeasure , MEAS . HAS_NUMERICAL_VALUE , factory . createLiteral ( tokens [ 1 ] . trim ( )
, XMLSchema . STRING ) ) ;
/ / add v a r i a b l e
con . add ( idMeasure , MEAS . MEASURE_OF , PROD . COST ) ;
/ / add u n i t
con . add ( idMeasure , MEAS . HAS_UNIT_OF_MEASURE , PROD . EURO ) ; ;
}
}
Notre environnement va donc contenir nos composants ontologiques ainsi que les
donnes sous forme de graphes RDF provenant :
de trois profils de consommateurs et leurs recommandations,
du contexte du restaurant : catgories, buffets et menu sur trois mois,
47
de la liste des produits disponibles avec leurs caractristiques.

Lexploitation de la base RDF se fait grce lAPI Sesame et au langage de requtes
SPARQL.
4.2.4 Des modles de connaissances aux objets mtiers : exploita-

tion de SPARQL
Le module prsent, ici, est assujetti lexploitation de la base de connaissances
afin den crer des objets mtiers. Notre dmarche est de construire, au pralable, un
menu, vu comme un objet mtier, qui sera consultable par tous les utilisateurs. Par la
suite, ce menu est personnalis par la couche mtier de notre systme en fonction des
recommandations du modle de conseils. La figure 4.2 correspond au diagramme de
classes du module java dvelopp.
Nous observons tout dabord que, seul un sous-ensemble de concepts des com-
posants ontologiques est reprsent. En effet, nous avons besoin, sous forme dob-
jet mtier, du concept de consommateur, des concepts consultables par lutilisateur,
savoir, le contexte et les produits disponibles. De plus, certains composants ontologiques,
non ncessairement consultables, servent la slection de produit. Enfin, certain con-
cepts comme ceux des caractristiques de produits sont regroups. En effet, les carac-
tristiques des produits reprsentes de manire hirarchique dans lontologie (cf. sec-
tion 3.2), ont t "aplaties vers le haut", cest--dire que nous avons choisi de ne con-
struire quune seule classe mtier Characteristic. Nous navons pas besoin dexploiter
la spcialisation des concepts pour nos traitements et cest ce qui explique ce choix qui
vise la simplicit de reprsentation.
Lien entre instances de concepts et dobjets mtiers

Les objets mtiers et les instances dans lontologie sont lis au travers de lURI
de linstance RDF. Cette information est un identifiant unique dans les technologies
dveloppes par le W3C. La classe abstraite RoFElement, cf. firgure 4.2, va fournir
aux classes spcialises un lment instance de concept de base. En effet, ils seront tous
dfinis par les attributs id pour lURI de linstance, name pour largument de linstance
ou instance sans espace de nommage et par un label attribu en fonction de la langue
choisie.
Schma de rutilisation et de paramtrage par spcialisation

Le schma de conception des classes principales correspond un schma de ru-
tilisation en programmation oriente objets. Il est bas, ici, sur la spcialisation et la
redfinition de mthodes.
48
F IGURE 4.2 Diagramme de classes UML partiel du module mtier : conversion RDF
vers objets mtier
49
Spcialisation de classes : la classe abstraite RoFElement va correspondre une in-

stance dun concept RDF de base, par spcialisation les autres classes RoFCategory,
RoFBuffet, RoFProduct et RoFMenu vont hriter de ces attributs et tre enrichies. Pour
cela, nous utilisons la mthode initRoFElement dans le constructeur de cette classe mre
afin de prparer le paramtrage des classes filles, voir listing 4.3.
Paramtrage par spcialisation : chaque sous-type de RoFElement va tre paramtr

grce la mthode initRoFElement, dfinie comme abstraite dans la sur-classe RoFEle-
ment et qui devra donc tre implmente dans chaque sous-classe. Cette mthode con-
struit une requte SPARQL et interroge la base de donnes RDF avec lAPI Sesame afin
de complter linstance dobjet par les attributs propres la classe, voir lappel listing
4.4.
Listing 4.3 Code paramtrable : 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 w i t h 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 o f t h e e l e m e n t .
/
p u b l i c RoFElement ( URI id ) {
super () ;
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 architectureAnne
}
Listing 4.4 Exemple de code paramtrant : mthode dfinie dans sa classe RoFCate-
gory
p u b l i c c l a s s RoFCategory e x t e n d s RoFElement i m p l e m e n 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 w i t h t h e u r i o f t h e o b j e c t .
/
p u b l i c v o i d initRoFElement ( ) {
i f ( t h i s . id ! = n u l l )
try {
RepositoryConnection con = SesameForRoF . Instance ( ) . getSesame ( ) . getConnection ( ) ;
/ / b u i l d s p a r q l query
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 + " \ " ) } . " ) ;
TupleQueryResult result = con . prepareTupleQuery ( QueryLanguage . SPARQL , query .
toString ( ) ) . evaluate ( ) ;
// result
List<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 rutilisation et une volution future plus facile.
Traduction des relations belongsTo et aggregates

Les composants ontologiques de dfinition du RoF et des produits, cf. section 3.2,
utilisent les proprits inverses belongsTo et aggregates pour dfinir les relations entre
les produits et les menus, les catgories et les buffets. Nous avons traduit cette notion de
plusieurs manires, suivant les cas (cf. diagramme de classes figure 4.1) :
par une composition la tentationla tentationla tentationproductsmenupour traduire
quun menu est compos de produits, avec la relation productBelongsToMenu sur
le diagramme de classes ;
par lassociation belongsToCategory entre un produit et une catgorie ;
par lassociation belongsToBuffet entre un produit et une buffet.
Les associations vont amener plus de flexibilit lors de la consultation des produits par
catgories et/ou buffets.
La classe RoFMenu joue galement le rle de gestionnaire du contexte du restaurant
par les deux autres compositions des classes RoFCategory et RoFBuffet qui apparaissent
lors des menus. Une des raisons de ce choix de conception est que dans cette version du
prototype, le menu est le point dentre pour la consultation des produits.
En raison du rle de "conteneur" jou par le menu, nous avons choisi de grer la
profondeur de conversion des objets Menu, mais aussi Product avec les caractristiques,
grce la mthode particulire buildItem. Elle va construire le produit et les menus
complets cest--dire, dots de leurs composants (cf. exemple du listing 4.5).
Listing 4.5 Extrait de la mthode buildItem de la classeRoFMenu

/
Find a l l products , 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 lunch in the r e p o s i t o r y .
/
p u b l i c v o i d buildItems ( ) {
t h i s . products = new HashMap<URI , RoFProduct > ( ) ;
...
query . append ( "SELECT ? p r o d ? b u f f ? c a t " ) ;
query . append ( " ? p r o d a < " + PROD . PRODUCT + " > . " ) ;
query . append ( " ? p r o d < " + 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 ( " p r o d " ) . stringValue ( ) )
);
t h i s . products . put ( prod . getId ( ) , prod ) ;
...
}
...
Pour rsumer, nous avons donc mis en place un environnement de connaissances

comprenant :
un serveur de base de donnes RDF Sesame, exploitable grce lAPI Java Sesame
fournissant galement un systme de raisonnement ;
la dfinition de plusieurs composants ontologiques et des jeux de tests de con-
sommateurs, menus, produits et caractristiques ;
un module de conversion dobjets RDF des objets mtiers java.
4.3 Personnalisation du menu du jour : RoFAdvisedMenu

Les dveloppements prcdents nous ont permis de mettre en place un environ-
nement de connaissances et un module facilitant le passage dinstances RDF des in-
stances dobjets mtiers. De ces dveloppements, il en ressort la cration, base sur nos
connaissances, dun menu complet (catgories, buffets, produits, caractristiques). Nous
allons maintenant nous intresser la personnalisation de ce menu pour un consomma-
teur. Les trois profils dutilisateur sont grs par le SBC. A chacun deux sont associs
des recommandations (cf. section 3.4). La personnalisation du menu : annotation des
lments, personnalisation du message (contenu et forme), gestion de la tentation, est
dcrite dans les parties suivantes, ainsi que la gestion du plateau virtuel.
4.3.1 volution du modle dobjet mtier

La figure 4.3 illustre les volutions du diagramme de classes du module de cra-
tion dobjets mtier partir de la base RDF. Les volutions implmentent maintenant
les premires rgles mtiers de la premire version de notre prototype. Nous avons fait
apparaitre le concept menu personnalis avec la classe RoFAdvisedMenu. Cette classe
est une spcialisation de la classe RoFMenu. Ce menu personnalis est li un con-
sommateur, qui va pouvoir personnaliser les lments du menu (produits, catgories et
buffets), activer le processus de tentation et personnaliser le message diffus en fonction
de la caractristique pertinente pour lutilisateur. De plus, les lments personnalisables
ont un nouvel attribut advised. Cet attribut peut contenir un entier correspondant code
dfini dans la configuration du systme : 1, conseill ; -1, viter et 0, pas dindication.
Enfin, nous avons une classe Tray reprsentant le plateau virtuel de lutilisateur.
52
F IGURE 4.3 Diagramme de classes UML partiel du module mtier : 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 cre. Celle-ci est initialise, limage du menu
du jour gnral. Lors de linitialisation de lobjet mtier du consommateur, lattribut
forAdvisedLunch va tre lui-mme initialis avec lURI correspondant une instance
RDF AdvisedLunch, concept central de lontologie des recommandations (cf. section
3.4). Pour rappel, ce concept est constitu dune collection de conseils permettant dan-
noter les lments du contexte du restaurant comme "conseill" ou " viter", dune
dfinition de caractristiques pertinentes, du type de gestion de la tentation et du mode
daffichage conseill. Lide ensuite est dexploiter ce "lien" vers les recommandations
pour lutilisateur pour appliquer les fonctionnalits de personnalisation du menu (anno-
tation, tentation et message personnalis), sans avoir crer dobjet mtier correspon-
dant aux recommandations mais sen servir, par contre, pour slectionner les lments
dans la base RDF. Techniquement, on va tre amen crer des requtes SPARQL dy-
namiques en fonction des recommandations.
4.3.3 Annotation advised et avoid

Au dpart, lobjet menu consacr lutilisateur est le mme que le menu gnral,
sans personnalisation. Il contient tout les objets mtiers produits, catgories et buffets
disponibles ce jours l au RoF. La mthode setAdvisementConcept(URI typeOfAdvise,
int adviseValue) va en fonction du type de conseil, donne dans lontologie par les re-
lations (isAdvise ou isAvoid) rcuprer tous les conseils (instances du concept Advice)
et construire la requete SPARQL permettant, pour chaque conseil, de rcuprer lURI
des produits annoter en fonction du type de relation vise. Si nous prenons lexemple
de John, la figure 4.4 illustre le fait que John a trois conseils alimentaires dont un con-
cerne un lment du menu viter (isAvoid) et deux autres permettront dindiquer les
lments considrs comme bnfiques (isAdvised) et dannoter comme tels nos objets
mtiers correspondants. Le listing 4.6 donne le code java permettant de slectionner ces
conseils.
Listing 4.6 Extrait de la mthode setAdvisementConcept - construction dune requte

SPARQL pour rcuprer les instances dAdvice
p u b l i c v o i d setAdvisementConcept ( URI typeOfAdvise , i n t adviseValue ) {
...
/ / g e t a d v i s e d p r o d u c t element w i t h o u t measurement r e q u i r e m e n t
query . append ( "SELECT ? c t y p e ? advElem ? r e q " ) ;
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
F IGURE 4.4 Conseils pour John (TopBraid)
query . append ( " OPTIONAL { ? advElem < " + ADV . HAS_MEASUREMENT_REQUIREMENT + " > ? mr } .
");
query . append ( " FILTER ( ! bound ( ? mr ) ) . " ) ;
query . append ( "ORDER BY ? advElem " ) ;
...
}
La deuxime tapes est la slection des produits annoter en fonction de la relation

recherche. Pour continuer notre exemple, nous allons nous intresser un des conseils
pour John, illustr par la figure 4.5. Ce conseil est donn pour des lments de menu
de type Product, donn par la relation concernedType. Ce conseil est constitu de Re-
quirement qui doivent tous tre satisfait et permettent de slectionner les produits. Ici
le premier Requirement indique que le produit appartient la catgorie des soupes, le
deuxime que cette soupe doit tre de type bouillon. Lextrait de la mthode setAdvise-
mentConcept, listing 4.7, montre la cration de la requte SPARQL en fonction des r-
sultats de la prcdente. Chaque Requirement est traduit pas des instructions SPARQL
de slection et ajouter au prcdent (connecteur logique AND, OR entre Advice). La
dernire instruction assigne lattribut advised du produit mtier un entier traduisant
pour le cas de John que le produit est conseill.
Listing 4.7 Extrait de la mthode setAdvisementConcept suite - construction dune
requte SPARQL pour rcuprer les instances de produit et annotation
p u b l i c v o i d 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 d
i f ( ! ctype . contentEquals ( ctypeOld ) | | ! advElem . contentEquals ( advElemOld ) ) {
query = new StringBuilder ( ) ;
query . append ( "SELECT ? p r o d " ) ;
}
/ / r e m a i n e d r e q u i r e m e n t t o add
query . append ( " { " ) ;
55
F IGURE 4.5 Conseils concernant les soupes pour John (TopBraid)
56
query . append ( " ? p r o d a < " + ctype + " > . " ) ;

query . append ( " < " + req + " > < " + ADV . HAS_INSTANCE_VALUE + " > ? i v a l " + i + " . " ) ;
query . append ( " < " + req + " > < " + ADV . CONCERN_OBJECT_PROPERTY + " > ? o p r o p " + i + " .
");
query . append ( " ? p r o d ? o p r o p " + i + " ? i v a l " + i + " . " ) ;
query . append ( " UNION " ) ;
query . append ( " { " ) ;
query . append ( " ? p r o d a < " + ctype + " > . " ) ;
query . append ( " < " + req + " > < " + ADV . HAS_INSTANCE_VALUE + " > ? i v a l " + i + " . " ) ;
query . append ( " FILTER ( ? p r o d = ? i v a l " + i + " ) . " ) ;
...
/ / annotation
prodResult = con . prepareTupleQuery ( QueryLanguage . SPARQL , query . toString ( ) ) . evaluate ( )
;
w h i l e ( prodResult . hasNext ( ) ) {
prodBinds = prodResult . next ( ) ;
URI prod = new URI ( prodBinds . getValue ( " p r o d " ) . stringValue ( ) ) ;
/ / the product is available
i f ( products . containsKey ( prod ) ) products . get ( prod ) . setAdvise ( adviseValue ) ;
...
}}
Ce processus dannotation peut seffectuer galement sur dautre concepts comme

les catgories ou des buffets.
4.3.4 Gestion de la tentation

La tentation est traduite dans lontologie 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 dconseills sont limins des produits visibles par
le consommateur ;
freeTemptation seul les produits considrs comme bnfiques sont laiss, tous les
autres, ceux considrs comme nfastes ou ceux dont on na pas fix dinfor-
mation sont supprims du menu personnalis.
Le mode de tentation est donn par lontologie des recommandations, pour John il
sagit du mode fullTemptation, donc les lments ne sont pas supprims. La figure 4.6
schmatise la formalisation de la tentation pour John.
Cette rgle mtier est implmente par la fonction processTemptation() qui rcupre
en premier le mode de tentation dans la base, puis suivant les modes de tentation va
supprimer de lobjet mtier AdvisedMenu les lments non souhaitable dtre mis
disposition.
57
F IGURE 4.6 Mode de tentation pour John (TopBraid)
4.3.5 Caractristique pertinente

Dans notre prototype, une seule caractristique est traite comme pertinente et sera
affiche en priorit, notamment un produit est associ une seule information dans
laffichage et qui correspond cette caractristique. Par dfaut, la caractristique de
dfinie dans la configuration du systme est lnergie en kilo-calorie que peut fournir un
aliment. Pour un menu personnaliser, elle est formalise avec lontologie des recom-
mandations. Pour John, cest aussi lnergie qui est la caractristique la plus pertinente
afficher pour lui (cf. figure 4.7). Par contre pour Wim, cest la quantit de vitamine
et pour Esther le prix des aliments. Cette caractristique peut donc tre galement un
mesure nutritive.
F IGURE 4.7 Caractristique pertinent afficher pour John (TopBraid)
Au niveau implmentation des objets mtier, lattribut firstMeasurement de type
58
URI, va correspondre linstance du type de mesure prfr par le consommateur. Par

exemple, pour John on aura http://www.wurvoc.org/rof/johnTheDieter#john_preferedTypeOfMeasurement
Cet attribut est initialis par les objets mtiers par la fonction dinitialisation de lobjet.
Ceci implique galement un traitement spciale pour cette caractristique, qui est slec-
tionne parmi toutes celles accompagnant le produit.
4.3.6 Gestion du plateau virtuel
Un utilisateur "connu" va avoir la possibilit de grer un plateau virtuel. Pour cela,

le type Tray a t dfini. Il y a une relation dagrgation entre produits et plateau. Un
attribut de type Tray existe pour un consommateur, cf. diagramme de classe 4.3. Il est
intressante de remarquer que les recommandation dfinies au niveau du menu vont tre
servir le paramtrer au niveau de la consultation et de paramtrer les ractions du
systme. Par exemple, une des recommandations de John (recommandation Rec. 6, cf.
chapitre 1.1) de la part de la ditticienne, dit que son repas global ne doit pas dpasser
plus 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 la
couche mtier de notre prototype, va consister indiquer des proprits pour le plateau.
La gestion de laffichage est laiss lapplication Smartphone. Au niveau implmen-
tation, cette caractristique globale est de type RoFCharacteristic est initialise de la
mme manire que les autres, par contre la gestion de ces caractristiques se fait dans
la classe RoFAdvisedMenu qui a pour attribut advisedMenuMeasurement, une structure
de donnes (HashMap), issue de la relation de composition qui existe entre les types
RoFCharacteristic et RoFAdvisedMenu, voir diagramme de classes figure 4.3.
Pour rsumer, la personnalisation du menu et les rgles mtiers sont gres par-
tir du module java dvelopp prcdemment (voir section 4.2.4). Il est bas sur une
architecture de rutilisation par spcialisation et paramtrable grce des requtes din-
terrogation SPARQL. Lvolution de ce module, va permettre de faire apparaitre les
types RoFAdvisedMenu et RoFTray, attribut dun consommateur, permettant respec-
tivement la gestion de menu personnalis, sur lequel on va pouvoir appliquer les rgles
mtiers implmentes et la gestion du plateau virtuel. Les rgles mtiers implmentes
sont : marquage des lments (produit, catgorie ou buffet complet) comme considrs
comme bnfiques ou nfastes au consommateur, personnalisation du message avec la
slection pour chaque produits des informations concernant une seule variable perti-
nente, gestion de la tentation par suppression des produits visibles en fonction dun
degrs de libert.
Ces objets ainsi construits vont tre ensuite mis a disposition travers une architec-
ture distribue afin dtre consults grce a une application sur Smartphone.
59
F IGURE 4.8 Recommandation globale dun repas de 600 kcal maximum pour John
(TopBraid)
4.4 Web Service

Le systme de diffusion a certaines exigences dont la consultation des menus et
produits, avec leurs caractristiques, sur des plateformes mobiles. Pour rpondre ce
besoin, nous avons mis en place une architecture distribue, base sur un Web Service.
En effet, les caractristiques des Web Services ont orient notre choix :
interaction entre systmes htrognes, distants, avec couplage faible ;
utilisation des protocoles internet, notamment le protocole standard HTTP ;
change de message XML possible ;
utilisation de clients lgers possibles, type navigateur web.
En effet, il existe une grande variation de plateformes clientes de type ordiphone, et

qui possde des caractristiques matrielles, des systmes dexploitation et des langages
de programmation dapplication diffrents, cas iPhone et Windows Phone par exemple.
Larchitecture de services Web choisie est REST (voir section ). Ce choix a t fait
en fonction de plusieurs critres :
lger car bas uniquement sur le protocole HTTP, et donc moins de complexit
engendre par lutilisation des diffrents intermdiaires des architectures SOAP
par exemple ;
architecture oriente ressources par rapport une architecture base sur les traite-
ments ;
60
4.4 Web Service
interface daccs et de manipulation des ressources uniformes : GET, POST,

DELETE du protocole HTTP ;
possibilit, dans une version future, damliorer les interactions entre la base de
donnes RDF, Sesame, et un Web Service type REST par des extensions disponible
de Sesame.
Pour implmenter cette architecture, nous avons utilis de le framework Open Source
Restlet, crit en Java. Il correspondait bien nos besoins : filtres daccs aux ressources
bass sur XPath, support de reprsentation XML, extension permettant de dployer rapi-
dement une application Restlet sur les tlphones mobiles Google Android.
Dans cette section est dcrite limplmentation de lapplication est base sur une
architecture REST et permet la diffusion de ressources : les menus avec leur composition
(produits, catgories, etc. mais aussi images).
Format dchange
Nous avons choisi dutilis un format utilisant le langage XML pour communiquer
entre le serveur et la plateforme mobile. Le listing 4.8 illustre un exemple de reprsen-
tation XML permettant de dcrire la catgorie "fruit" dun menu.
Listing 4.8 Extrait de reprsentation XML dun menu
<rof>
<menu>
http: / / www . wurvoc . org / rof / product#menu20100730
<name>menu20100730< / name>
< l a b e l >menu20100730< / l a b e l >
<dateOfMenu >20100730< / dateOfMenu >
<categories>
<category>
http: / / www . wurvoc . org / rof / product#fruit
...
<products>
<product>
http: / / www . wurvoc . org / rof / product#appel
...
<buffet>
http: / / www . wurvoc . org / rof / product#dessertsAndJuicesBuffet
</ buffet>
<quantities>
<quantity>
kilocalorie ( mean ) 
< value >98 ,74< / value >
< v a r i a b l e >energie< / v a r i a b l e >
http: / / www . wurvoc . org / vocabularies / ommc 1 . 6 / energy
</ quantity>
...
</ rof>
Ces donnes sont produites par notre module mtier, en effet chaque classe im-
plmente la fonction toXML qui produit un lment de type XML correspondant la
61
description de son type et de ses attributs (cf. extrait du diagramme de classes, figure
4.9). Cette implmentation est facilit par la spcialisation. Chaque lment de base va
avoir un identifiant, id, correspondant lURI de lobjet mtier et instance RDF, ainsi
quun label pour laffichage dans la bonne langue et un nom.
F IGURE 4.9 Extrait du diagramme de classes du module mtier
La structure des donnes XML correspond la structure arborescente de consul-

tation du menu. Dans notre prototype nous avons implment la consultation du menu
gnrale par : "menu/catgorie/produit/caractristiques". Dans le cas dun menu person-
nalis, elle se fait par : "utilisateur/identifiant/menu/catgorie/produit/caractristiques".
Le plateau virtuel est consultable par "utilisateur/identifiant/plateau". Cette structure
correspond vraiment un consultation de ressources.
Application Restlet
Les classes dveloppes laide du framework Restlet sont donnes par la figure
4.10. La classe LunchAtRoFApplication est la classe mre de lapplication, elle va grer
les ressources. Pour cela, elle possde des attributs consumer et menu. Le premier est
une collection java (ConcurrentMap) permettant de grer les accs concurrents aux don-
nes contenues. Cest une map associant lidentifiant dun utilisateur, son numro dem-
ploy, une instance de type RoFConsummer. Ainsi chaque instance de consommateur
du systme est gr par cette structure. Lattribut menu, correspond au menu du jour
gnral. Chaque menu est mis jour automatiquement par le systme, qui vrifie les
dates des menus de la consommation du service Web.
Cette classe dfinie galement, les routes ou chemins daccs aux ressources. Le list-
ing 4.9 illustre plusieurs dfinitions de lien entre un chemin daccs une ressource
62
4.4 Web Service
F IGURE 4.10 Diagramme de classes du Web Service
63
et une classe ressource (cf. figure 4.10). Certains chemins sont paramtrables par des
filtres, chane de caractres variable entre accolades. Par exemple, le paramtre wurid
du chemin "/user/wurid/tray" permet de slectionner en fonction de lidentifiant le bon
consommateur et ensuite son plateau virtuel.
Listing 4.9 Extrait de la classe LunchAtRoFApplication - initialisation des chemins

daccs 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 . /
@Override
p u b l i c s y n c h r o n i z e d Restlet createInboundRoot ( ) {
/ / Create a router Restlet that defines routes .
Router router = new Router ( getContext ( ) ) ;
/ / D e f i n 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 menu
router . attach ( " / menu / " , RoFMenuRessource . c l a s s ) ;
...
/ / Define a route fo r the resource " l i s t of c a t e g o r i e s
router . attach ( " / menu / c a t e g o r i e s " , RoFCategoriesResource . 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 " 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 t
router . attach ( " / menu / c a t e g o r i e s / { c a t e g o r y N a m e } / { productName } " , RoFCategoriesResource
. class ) ;
...
/ / 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 menu ( d a t e , i d )
router . attach ( " / u s e r / { w u r i d } / menu " , RoFUserAdvisedMenuResource . c l a s s ) ;
...
/ / define a route 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 t
router . attach ( " / u s e r / { w u r i d } / t r a y " , RoFUserTrayResource . c l a s s ) ;
...
r e t u r n router ;
}
Mthodes implmentes : GET, PUT et DELETE

Chaque classe ressource est charge de fournir des reprsentations de ressources,
reprsentations XML pour nous, mais aussi dy appliquer des traitements :
GET : envoi de la reprsentation au format souhait, par exemple la reprsentation
XML dun menu ou des catgories dun menu ;
DELETE : suppression dun lment dune reprsentation, par exemple un produit
du plateau ;
POST : ajout dun lment une ressource, par exemple un produit au plateau.
La signification de ces mthodes sont dfinies dans la norme RFC2616 de HTTP1.1 (cf.
Fielding et al. (1999)).
Avant dexcuter une des trois mthodes dsignes ci-dessus, une mthode dini-
tialisation du framework Restlet est excute automatiquement. Nous lavons redfinie
afin de traiter les filtres et ainsi slectionner les bonnes ressources ou objets mtiers. Le
listing 4.10 montre limplmentation de la mthode GET de la classe ressource grant
le plateau virtuel dun consommmateur.
64
4.4 Web Service
Listing 4.10 Extrait de la classe RoFUserTrayResource - implmentation de la mth-

ode GET pour le plateau virtuel
p u b l i c c l a s s RoFUserTrayResource e x t e n d s RoFElementResource {
...
/
Returns a d e s c r i p t i o n of the resource 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 .
try {
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 c o n s u m e r
Document doc = representation . getDocument ( ) ;
Element rElem = doc . createElement ( " r o f " ) ;

doc . appendChild ( rElem ) ;
Element eCons = doc . createElement ( " c o n s u m e r " ) ;

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 ( ) ;
}
return null ;
}
...
}
Serveur dimages
Dans notre projet, chaque lment du menu est associ une illustration. Pour met-
tre disposition ces images, nous avons ajouter un serveur de fichiers statiques notre
application. Nous avons utilis pour cela le framework Restlet qui gre la notion de
rpertoire ddi et correspond un accs vers un rpertoire de notre serveur o se trouve
stockes les images. Les images seront donc accessible pas leur nom.
Nous avons donc mis en place un Web Service REST, bas sur le framework Java
Restlet, permettant :
de produire sous forme XML, la reprsentation des menus, des catgories de
menu, des produits par catgories, des caractristiques par produit, etc. ;
65
de donner accs par un systme dadresses paramtrables, des ressources per-

sonnalises ;
de grer lajout et la suppression de produit dans le plateau virtuel dun consom-
mateur ;
de mettre disposition les illustrations dlments de contexte du restaurant.
La suite du document est consacre lapplication de consultation du Smartphone.
4.5 Application sur Smartphone

Le rle de lapplication ordiphone est essentiellement un laffichage du menu. Son
but est de permettre au consommateur de consulter son menu personnalis par notre
systme suivant les recommandations du modle PEA. Dans larchitecture du systme
mis en place, nous avons essay de limiter le plus possible les traitements effectus
par lordiphone, le but tant de rester le plus possible souple face lhtrognit du
march et des diffrents types de dordiphone.
Les cas dutilisation utilisateur sont dcrits par le diagramme UML figure 4.11. Pour
rsumer, depuis son terminal mobile, lutilisateur doit avoir accs aux fonctionnalits
suivantes :
consultation du menu : les catgories, les produits avec leurs dtails,
consultation et gestion dun plateau virtuel du repas,
enregistrement de lapplication auprs de notre systme.
Parmi ces fonctionnalits, la manire dafficher les informations va rester sous la respon-
sabilit du concepteur de lapplication Smartphone. En effet, un jeu de mta-donnes
produit par le PEA va fournir la manire dont il est souhaitable que les informations
soient affiches, par exemple les donnes brutes vs histogramme de la valeur nutrition-
nelle des aliments. Dans ce prototype, seul le mode daffichage "donnes brutes" est
implment.
Vues de lapplication
La navigation entre les pages peut tre schmatise grce au diagramme UML dac-
tivit fig. 4.12.
La partie vue de lapplication est crite avec le langage de balises XAML et le code
joint en C#.
Il y a trois types de pages :
les pages de registration et de bienvenue ;
66
F IGURE 4.11 Diagramme des cas dutilisation de lapplication smartphone

67
F IGURE 4.12 Diagramme de navigation de lapplication smartphone.

Les recommandations WP7 impliquent : (i) depuis chaque page, lapplication peut tre
stoppe (ii) le bouton "BackKey" permet de remonter lhistorique de navigation, depuis
nimporte quelle page, jusqu la page de dmarrage
68
les pages de consultation du menu, au nombre de trois :

la liste des catgories,
la liste des produits pour une catgorie,
le dtail dun produit avec ses principales caractristiques et sa localisation dans
le restaurant ;
la page du plateau virtuel contenant une liste de produits.
Lutilisateur du Smartphone est reprsent par la classe User, visible sur le dia-
gramme de classes (figure 4.14) des principales vues. Chacune des classes contient une
proprit User. Cet objet correspond lobjet RoFConsumer du module mtier du sys-
tme de diffusion et au concept Consumer de lontologie. Dans le cas de lutilisateur, la
liaison entre ces concepts dans lensemble du systme, se fait grce au numro dem-
ploy du consommateur. Il va nous permettre de pouvoir accder la ressource per-
sonnel sur le systme de diffusion, voir section 4.4 sur le Web Service et laccs au
menu personnalis. Par exemple, lurl http ://www.wur.nl/LunchAtRoF/user/11090/tray
permet dobtenir la ressource correspondant au plateau virtuel de lutilisateur dont li-
dentifiant est 11090.
La fonctionnalit de Registation traite le cas de la premire utilisation de lappareil,

et permet, aprs saisi du numro demploy wurid, de cer un espace de stockage isol 1
et persistant au niveau de lapplication. Cet espace stocke alors les paramtres utilisa-
teurs ncessaires la connexion au Web service.
Les classes CategoriesPage, CategoryPage et ProductDetailPage permettent respec-

tivement dafficher les catgories disponibles pour un menu, les produits disponibles
pour une catgorie et les caractristiques dun produit donn. La classe TrayPage permet
dafficher la liste des produits contenus dans le plateau du consommateur ainsi quun
bilan dune proprit pertinente pour lui comme par exemple la somme des calories des
produits. Lexemple de code XAML, listing 4.11, cr un template qui, associ par la
liaison de donnes {Binding Products} dune collection en C#, va pour chaque lment
de la collection crer un nouvel item. La figure 4.13 montre le rsultat obtenu pour une
liste de produits, des fruits.
Listing 4.11 Code XAML - liaison de donnes avec une liste

< L i s t B o x I t e m s S o u r c e = " { B i n d i n g 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= " L B P r o d u c t s " V e r t i c a l A l i g n m e n t = " S t r e t c h " >
<ListBox . ItemTemplate>
<DataTemplate>
< 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 " H e i g h t = " 72 " >
1. Isolated Storage en anglais est un systme de fichier virtuel mis disposition pour stocker les
donnes des applications Silverlight. cf. http://msdn.microsoft.com/en-us/library/ff402541%28VS.92%
29.aspx
69
F IGURE 4.13 Smartphone - liste de fruits
70
< R a d i o B u t t o n C o n t e n t = " " GroupName= " T r a y P r o d u c t s " G r i d . Row= " 1 " H e i g 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= " { B i n d i n g I d } "
V e r t i c a l A l i g n m e n t = " Top " Checked = " R B S e l e c t _ C h e c k e d " Width = " 64 " M i n H e i g h t = " 20 "
MinWidth= " 20 " / >
<Image S o u r c e = " { B i n d i n g I m a g e U r l } " H e i g h 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 " H e i g h 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 " >
< T e x t B l o c k T e x t = " { B i n d i n g L a b e l } " V e r t i c a l A l i g n m e n t = " Top " T e x t W r a p p i n g = " Wrap "
F o n t S i z e = " 25 " F o r e g r o u n d = " White " F o n t F a m i l y = " Segoe WP" Margin = " 4 , 0 , 0 , 0 " / >
< T e x t B l o c k T e x t = " { B i n d i n g 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 " T e x t W r a p p i n g = "
Wrap " F o n t S i z e = " 18 " F o r e g r o u n d = " White " F o n t F a m i l y = " Segoe WP" Margin = " 6 , 0 , 0 , 0
" />
</ StackPanel>
<Image H e i g h t = " 30 " V i s i b i l i t y = " { B i n d i n g I M G K o o k V i s 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 " S o u r c e = " { B i n d i n g IMGKookSource } " Name= " IMGKook "
V e r t i c a l A l i g n m e n t =" Center " / >
</ StackPanel>
< / DataTemplate>
< / ListBox . ItemTemplate>
< / ListBox>
La liaison de donne permet la mise jours automatique de la vue. Pour cela,

chaque contexte de donnes de vue est associ un modle de prsentation que nous
avons cr. Par exemple, au contexte de donnes de la vue TrayPage est associ le
modle de prsentation TrayViewModel.
Le modle de prsentation de lapplication

Le "Modle de prsentation" a un rle de liaison entre les vues et les donnes (le
modle). Les donnes sont reues par consommation du Web Service de notre systme,
sous forme de chane de caractres au format XML. La gestion du modle dans notre
conception va tre gr directement par le modle de prsentation. Par exemple, lin-
stanciation du modle de prsentation du plateau virtuel, TrayViewModel, va impliquer
les tches suivantes :
cration dun client web et envoie au Web Service, une requte GET sur le ressource
correspondante au plateau de lutilisateur ;
une fois le tlchargement des rsultats effectu, parsage de la chane de carac-
tres de rponse avec lAPI LINK to XML et initialisation du modle de prsenta-
tion ;
utilisation des vnements, disponible en C#, afin de grer les autres attributs
dpendant du modle.
Dans le cas, du plateau virtuel, nous avons dvelopp les mthodes permettant de sup-
primer (DELETE) et ajouter (POST) des lments la ressources RoFTray de notre
systme.
Notons que nous avons choisi de faire appel au Web Service chaque changement
de vue, et non pas de charger la structure complte du menu au dpart. Ce choix a t
71
F IGURE 4.14 Diagramme de classes des vues
72
fait car un des scnarios, dvelopper dans une future version, prvois que les conseils
voluent en fonction de chaque choix de lutilisateur, ce qui impliquera de un recalcule
du menu personnalis.
Le diagramme de classes des modles de prsentation, figure 4.15, est proche des
autres modles dvelopps dans notre prototype par les classes cres. Par contre, les
relations entre elles sont plus forte car on utilise la composition de catgories dans un
menu, de produits dans une catgorie et le plateau, de caractristiques dans un produit.
La consquence est que la structure est moins souple mais correspond au modle de
navigation dfini (cf. figure 4.12)
Par rapport lontologie de dpart, nous navons utilis que les concepts ncessaires
lapplication Smartphone comme Category et Product. Ces concepts vont correspon-
dre directement deux classes du mme nom. Comme pour le module de la couche
mtier, une classe Item a t dfinie. Elle est compose de trois attributs dont id pour
lURI. Lattribut label de lobjet correspond la chane de caractres, afficher dans
la langue souhaite et name correspond largument de lURI. LURI va permettre de
lier les objets (catgorie, produit, caractristique, unit, etc.) travers larchitecture du
systme de connaissances jusquau Smartphone. De plus il permet didentifier et de
slectionner des objets et ainsi de naviguer travers les ressources (catgories, produits,
etc.), tant au niveau de lapplication Smartphone que du Web Service.
73
F IGURE 4.15 Diagramme de classes de lapplication Smartphone
74
Chapitre 5
Conclusion
A lheure actuelle un environnement dmontrant la faisabilit de lapproche est

oprationnel sous forme de prototype et en cours dexprimentation approfondie. Cet
environnement intgre des composants ontologiques rutilisables, volutifs et assem-
blables en fonction des besoins. Ils permettent de formaliser les deux grands domaines
ncessaires au projet, savoir :
le contexte du Restaurant du Futur : les menus avec leurs produits, leurs carac-
tristiques et leurs valeurs nutritionnelles ;
le consommateur : ses proprits physiques et physiologiques, son de mode vie
avec la description de son foyer et son type dactivit sportive, ainsi que ses ob-
jectifs dittiques personnels.
Un troisime composant ontologique a t conu pour modliser les recommandations
du modle de conseils. De nouveaux modules ontologiques sont en prparation. Ce tra-
vail a ncessiter daborder de nombreux sujets, au niveau de la conception dontologie,
mais surtout celui du domaine pluridisciplinaire dapplication : comportement du con-
sommateur, nutrition, alimentation...
Larchitecture informatique mise en place permet dexploiter lenvironnement de
connaissances et de mettre disposition des consommateurs des menus accompagns
de conseils alimentaires personnaliss en fonction du menu du Restaurant du Futur.
Une application Smartphone a t dveloppe sur Windows Phone 7, tournant actuelle-
ment sur un mulateur, une des prochaines tapes est de la tester sur un appareil rel
(date de sortie officielle octobre 2010). Mais dores et dj, elle permet de tester plusieurs
scnarios et les trois profils. Le systme a dj permis de rajouter des recommandations
facilement et de faire voluer la complexit des conseils.
Au terme de ce stage, nous pouvons considrer que les objectifs initiaux ont t
atteints. Ils ont permis la rdaction dun article, soumis en juillet, une revue hollandaise
ddie linformatique pour lagronomie.
Ce travail a t ralis durant une priode de cinq mois en Hollande, le premier mois
a consist en ltude des besoins. Il a permis de proposer diffrents scnarios dutilisa-
75
Conclusion
tion et de fonctionnalits de lapplications. Ce premier mois a conduit la ralisation

des trois profils de consommateur, qui ont t valids avec les experts en science du
consommateur et de la nutrition lors de plusieurs prsentations. Les deux mois suivants
ont t consacrs la modlisation des composants ontologiques, et la constitution des
jeux de test complets. Le mois suivant a t rserv la conception et limplmenta-
tion du systme base de connaissances, de la base du module mtier et la mise en
place du web service. Le dernier mois ma permis de concevoir et dimplmenter lap-
plication sur Smartphone et lintgration des rgles mtiers au systme. Le droulement
na pas t aussi linaire, car la dmarche a ncessit beaucoup daller retour entre les
diffrents modles.
Au niveau personnel, ce stage ma permis de dcouvrir un autre pays, dautres habi-

tudes alimentaires, de vie et de pouvoir amliorer mon anglais. Au niveau profession-
nel, jai eu la chance dintgrer une quipe de pointe dont les thmatiques de recherches
appliques mintressent vraiment et qui ont dj amen des ralisations logicielles
fonctionnelles. De plus, cela ma permis de dcouvrir un autre mode de fonctionnement
et de vision de la recherche en informatique applique. A cela sajoute que le domaine
dapplication correspond bien avec celui lINRA, ou je travaille. Ce stage a permis de
consolider des collaborations entre les deux quipes et qui vont pouvoir voluer.
Ltape suivante est la ralisation dun module avanc de conseils, avec mise en
place dun moyen permettant de combiner et donner la raison des diffrents conseils.
En effet, plusieurs critres entrent en jeu (vgtarien et calorie par exemple). Le module
de raction du systme au choix du lutilisateur, bas sur la go-localisation des produits
dans le restaurant, reste faire voluer. Au niveau scientifique, le modle de conseils,
actuellement en cours de cration par les chercheurs en science du consommateur et
de la nutrition, est finaliser. Linteraction avec notre composant ontologique pour la
reprsentation des recommandations sera alors a adapter. Au niveau de larchitecture, de
futurs dveloppements devront tre prvus pour lintgration de ce modle de conseils.
Lintgration devrait tre facilite par lutilisation de la mthodologie objet, des patrons
de conception qui apportent une souplesse lapplication.
Ce travail ouvre des perspectives de recherche par exemple, sur lvolution dy-
namique des ontologies en fonction du comportement de lutilisateur et de ses ractions
aux conseils donns, diffrents pas de temps, y compris en temps rel. Une autre per-
spective a trait lamlioration de la communication entre les diffrents modles : de
connaissance, mtier et consultation.
76
Bibliographie
Allaire J. (2002). Macromedia flash mxa next-generation rich client. Macrome-

dia white paper. Disponible ladresse http://download.macromedia.com/pub/flash/
whitepapers/richclient.pdf.
Berners-Lee T., Hendler J. & Lassila O. (2001). The semantic web. Scientific American,
284(5), 3443.
Broy M., Deimel A., Henn J., Koskimies K., Plil F., Pomberger G., Pree W., Stal M.
& Szyperski C. (1998). What characterizes a (software) component ? Software -
Concepts & Tools, 19, 4956. 10.1007/s003780050007.
Charlesworth A. (2009). The ascent of the smartphone. Engineering & technology,
4(3), 3233.
Fielding R. (2000). Architectural Styles and the Design of Network-based Software Ar-
chitectures. Thse de doctorat, University of California, Irvine. Disponible ladresse
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.
Fielding R., Gettys J., Mogul J., Frystyk H., Masinter L., Leach P. & Berners-Lee
T. (1999). Hypertext transfer protocol http/1.1 (rfc 2616). Request For Com-
ments. Available at http://www.ietf.org/rfc/rfc2616.txt, accessed
7 July 2006.
Gruber T. (2009). Ontology. Ling Liu and M. Tamer zsu (Eds.), Springer-Verlag.
Kster E. (2009). Diversity in the determinants of food choice : A psychological per-
spective. Food Quality and Preference, 20(2), 70 82. European Conference on
Sensory Science of Food and Beverages 2006, European Conference on Sensory Sci-
ence of Food and Beverages 2006. Disponible ladresse http://www.sciencedirect.
com/science/article/B6T6T-4R5F002-2/2/9d36c0f3b95469e3d29887be9a49dfb9.
Le Ber F., Lieber J. & Napoli A. (2006). Les systmes base de connaissances.
Dans Encyclopdie de linformatique et des systmes dinformation, rd. J. Akoka
& I. Comyn Wattiau, pp. 11971208. Vuibert. Disponible ladresse http://hal.inria.
fr/inria-00201566/PDF/sbc-vuibert-06.pdf.
77
BIBLIOGRAPHIE
Manola F. & Miller E., (Rd.) (2004). RDF Primer. W3C Recommendation. World
Wide Web Consortium. Disponible ladresse : http://www.w3.org/TR/rdf-primer/.
Mcguinness D.L. & van Harmelen F. (2004). OWL web ontology language overview.
W3C recommendation, W3C. Disponible ladresse : http://www.w3.org/TR/
owl-features/.
Noy N. & Mcguinness D. (2001). Ontology development 101 : A guide to creating your
first ontology. Rap. Tech..
Noy N. & Rector A. (2006). Defining n-ary relations on the semantic web. W3C Working
Group Note. Disponible ladresse 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 ladresse http://www.conradbock.org/
compkind.html.
Prudhommeaux E. & Seaborne A. (2008). SPARQL Query Language for RDF. W3C
Recommendation. Disponible ladresse : http://www.w3.org/TR/rdf-sparql-query/.
Psych V., Mendes O. & Bourdeau J. (2003). Apport de lingnierie ontologique aux
environnements de formation distance. Revue des Sciences et Technologies de lIn-
formation et de la Communication pour lEducation et la Formation (STICEF), 10,
89126. Disponible ladresse 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. W3C
Working Draft. Disponible ladresse 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 Engineering
Informatics. Accepted.
Segaran T., Taylor J. & Evans C. (2009). Programming the Semantic Web. OReilly,
Cambridge, MA.
Stubenitsky K., Aaron J., Catt S. & Mela D. (2000). The influence of recipe modification
and nutritional information on restaurant food acceptance and macronutrient intakes.
Public Health Nutrition, 3(02), 201209.
78
Annexes
79
Annexe A
Questionnaire pour les consommateurs

du RoF
81
/RJRXW_0\$FFRXQW_$GPLQ7RROV

:HLJKWLQNJ

0RGLI\6XUYH\ 3$*(&21',7,216 '21( 35(9,(: 35,17
_0RGLI\6XUYH\ 7KLVVXUYH\LVFXUUHQWO\/2&.('IRUHGLWLQJE\$QQH7LUHDX,WZLOOEHFRPHDYDLODEOHDIWHUWKH\XQORFNLWRUDIWHUPLQXWHV

KDVSDVVHGZLWKQRDFWLYLW\&OLFNKHUHWRXQORFNDQGH[LWWKHVXUYH\

7KHPRGLI\VXUYH\SDJH
FRQWDLQVDOOWKHIXQFWLRQV
UHODWHGWR6XUYH\'HVLJQ >1R7LWOH(QWHUHG@
7KLVVXUYH\KDVDWOHDVWRQHUHVSRQVH2QO\OLPLWHGFKDQJHVDUHDOORZHGRQDVXUYH\ZLWKUHVSRQVHV7RIXOO\HGLWWKLV
VXUYH\\RXPXVWILUVWGHOHWHDOORIWKHUHVSRQVHVZKLFKFDQEHGRQHE\FOLFNLQJKHUH
3DJH+HOS
5YG7986WXGHQWHQ+XLGLJHHQTXHWH
7H[W5HSODFHPHQW :RUNHPDLODGGUHVVILUVWQDPHODVWQDPH#ZXUQOLIHPSOR\HGDW:85
>1R7LWOH(QWHUHG@
&RS\WKHWH[WWRNHQIURP

WKHEHORZOLVWSDVWHWKH

FRSLHGWH[WLQWRWKH
GHVLUHGORFDWLRQLQWKH
VXUYH\
:HOFRPHWRWKHLQWDNHVXUYH\RIWKH5HVWDXUDQWRIWKH)XWXUH
8VHU'DWD7RNHQV

7KHVXUYH\
VOHQJWKLVDSSUR[LPDWHO\TXHVWLRQV$OOTXHVWLRQVPXVWEHDQVZHUHG3HUTXHVWLRQRQO\D
(PDLO'DWD7RNHQV :KHUHDUH\RXHPSOR\HG"
VLQJOHDQVZHULVDOORZHG
+LGGHQ'DWD7RNHQV :85RWKHUV$GPLQLVWUDWLRQ)%VWDII
<RXUILUVWLPSUHVVLRQLVXVXDOO\EHVW'RQ
WRYHUWKLQN\RXUDQVZHUWKHUHDUHQRJRRGRUEDGDQVZHUV
,WHP$QVZHU7RNHQV
$)6*
36*
3ULQW6XUYH\
$6*

3UHYLHZ7KLV6XUYH\ (6*

>1R7LWOH(QWHUHG@
*R7R6XUYH\/LVW

:KDWLV\RXUKLJKHVWOHYHORIHGXFDWLRQ"

*LYHQ$FFHVV&RGH

>1R7LWOH(QWHUHG@

)LUVWQDPH

:KDWLV\RXUKRXVHKROGW\SH"
VLQJOH
OLYLQJWRJHWKHUZLWKRXWFKLOGUHQ
OLYLQJWRJHWKHUFKLOGUHQRXWRIKRPH
/DVWQDPH
ZLWKFKLOGUHQSDUWO\DWKRPH\RXQJHVWXQGHU

ZLWKFKLOGUHQSDUWO\DWKRPH\RXQJHVW!\HDU

RWKHU

:KDWDUHWKHILUVWIRXUILJXUHVRI\RXU]LSFRGHKRPHDGGUHVV"

<HDURIELUWK

+RZGR\RXXVXDOO\WUDYHOWRZRUN"

>1R7LWOH(QWHUHG@

*HQGHU
>1R7LWOH(QWHUHG@

+RZRIWHQGR\RXGRVSRUWVZHHNO\DYHUDJH"

/HQJWKLQFP

,IIRRGWDVWHVJRRGWR\RXGR\RXHDWPRUHWKDQXVXDO"
1HYHU 5DUHO\ 6RPHWLPHV 2IWHQ 9HU\RIWHQ
,QWKHODVW\HDUVZKHUHGLG\RXWUDYHOWRSULYDWHO\DQGSURIHVVLRQDOO\"

'R\RXKDYHDGHVLUHWRHDWZKHQ\RXKDYHQRWKLQJWRGR"

>1R7LWOH(QWHUHG@

,I\RXKDYHSXWRQZHLJKWGR\RXHDWOHVVWKDQ\RXXVXDOO\GR"
:KHUHGR\RXRUVRPHERG\HOVHLQ\RXUKRXVHKROGJRVKRSSLQJIRRGSURGXFWV"
DOZD\V RIWHQ UHJXODUO\ UDUHO\ QHYHU

6XSHUPDUNHW
6PDOOHUVKRSV
,QWHUQHW
0DUNHW
3HWUROVWDWLRQVHWF
(DWLQJRXWRIKRPH >1R7LWOH(QWHUHG@

+RZRIWHQGR\RXEX\RUJDQLFDQGRUIDLUWUDGHSURGXFWV"

DOZD\V
'R\RXKDYHDGHVLUHWRHDWZKHQ\RXDUHGHSUHVVHGRUGLVFRXUDJHG"
RIWHQ 1HYHU 5DUHO\ 6RPHWLPHV 2IWHQ 9HU\RIWHQ
UHJXODUO\

UDUHO\
QHYHU

,IIRRGVPHOOVDQGORRNVJRRGGR\RXHDWPRUHWKDQXVXDO"
>1R7LWOH(QWHUHG@

:KDWLV\RXUUHDFWLRQWRWKHIROORZLQJVWDWHPHQWV

1HLWKHU +RZRIWHQGR\RXUHIXVHIRRGRUGULQNRIIHUHGEHFDXVH\RXDUHFRQFHUQHGDERXW\RXUZHLJKW"
'LVDJUHH 'LVDJUHH 'LVDJUHH GLVDJUHH $JUHH $JUHH $JUHH
VWURQJOH PRGHUDWHO\ VOLJKWO\ QRU VOLJKWO\ PRGHUDWHO\ VWURQJO\
DJUHH

,DPFRQVWDQWO\
VDPSOLQJQHZDQG
GLIIHUHQWIRRGV
,GRQ
WWUXVWQHZ

IRRGV
,I,GRQ
WNQRZ 'R\RXKDYHDGHVLUHWRHDWZKHQ\RXDUHIHHOLQJORQHO\"
ZKDWLVLQDIRRG, 1HYHU 5DUHO\ 6RPHWLPHV 2IWHQ 9HU\RIWHQ
ZRQ
WWU\LW

,OLNHIRRGVIURP

GLIIHUHQWFRXQWULHV
(WKQLFIRRGORRNV

WRRZHLUGWRHDW
$WGLQQHUSDUWLHV,

ZLOOWU\QHZIRRG
,DPDIUDLGWRHDW
WKLQJV,KDYH >1R7LWOH(QWHUHG@
QHYHUKDGEHIRUH
,DPYHU\

SDUWLFXODUDERXW

WKHIRRGV,ZLOO
HDW ,I\RXVHHRUVPHOOVRPHWKLQJGHOLFLRXVGR\RXKDYHDGHVLUHWRHDWLW"
,ZLOOHDWDOPRVW
DQ\WKLQJ
,OLNHWRWU\QHZ

HWKQLFUHVWDXUDQWV

'R\RXKDYHDGHVLUHWRHDWZKHQVRPHERG\OHWV\RXGRZQ"
>1R7LWOH(QWHUHG@

'R\RXKDYHWKHGHVLUHWRHDWZKHQ\RXDUHLUULWDWHG"

'R\RXWU\WRHDWOHVVDWPHDOWLPHVWKDQ\RXZRXOGOLNHWRHDW"


>1R7LWOH(QWHUHG@

,I\RXKDYHVRPHWKLQJGHOLFLRXVWRHDWGR\RXHDWLWVWUDLJKWDZD\"


'R\RXILQGLWKDUGWRUHVLVWHDWLQJGHOLFLRXVIRRGV"

>1R7LWOH(QWHUHG@

'R\RXGHOLEHUDWHO\HDWOHVVLQRUGHUQRWWREHFRPHKHDYLHU"

'R\RXKDYHDGHVLUHWRHDWZKHQ\RXDUHFURVV"

'R\RXKDYHDGHVLUHWRHDWZKHQWKLQJVDUHJRLQJDJDLQVW\RXRUZKHQWKLQJVKDYHJRQHZURQJ"

'R\RXZDWFKH[DFWO\ZKDW\RXHDW"

,I\RXZDONSDVWDVQDFNEDURUDFDIpGR\RXKDYHWKHGHVLUHWREX\VRPHWKLQJGHOLFLRXV"

,I\RXZDONSDVWWKHEDNHUGR\RXKDYHWKHGHVLUHWREX\VRPHWKLQJGHOLFLRXV"

>1R7LWOH(QWHUHG@

'R\RXKDYHDGHVLUHWRHDWZKHQ\RXDUHDSSURDFKLQJVRPHWKLQJXQSOHDVDQWWRKDSSHQ"


'R\RXKDYHWKHGHVLUHWRHDWZKHQ\RXDUHHPRWLRQDOO\XSVHW"

>1R7LWOH(QWHUHG@

+RZRIWHQGR\RXWU\QRWWRHDWEHWZHHQPHDOVEHFDXVH\RXDUHZDWFKLQJ\RXUZHLJKW"

'R\RXGHOLEHUDWHO\HDWIRRGVWKDWDUHVOLPPLQJ"

'R\RXHDWPRUHWKDQXVXDOZKHQ\RXVHHRWKHUVHDWLQJ"

,I\RXVHHRWKHUVHDWLQJGR\RXDOVRKDYHWKHGHVLUHWRHDW"

'R\RXKDYHDGHVLUHWRHDWZKHQ\RXDUHERUHGRUUHVWOHVV"

:KHQ\RXKDYHHDWHQWRRPXFKGR\RXHDWOHVVWKDQXVXDOWKHIROORZLQJGD\V"

>1R7LWOH(QWHUHG@

'R\RXJHWWKHGHVLUHWRHDWZKHQ\RXDUHDQ[LRXVZRUULHGRUWHQVH"


+RZRIWHQLQWKHHYHQLQJGR\RXWU\QRWWRHDWEHFDXVH\RXDUHZDWFKLQJ\RXUZHLJKW"

'R\RXKDYHDGHVLUHWRHDWZKHQ\RXDUHIULJKWHQHG"

'R\RXWDNHLQWRDFFRXQW\RXUZHLJKWZLWKZKDW\RXHDW"

'R\RXKDYHDGHVLUHWRHDWZKHQ\RXDUHGLVDSSRLQWHG"

>1R7LWOH(QWHUHG@

:KHQ\RXDUHSUHSDULQJDPHDODUH\RXLQFOLQHGWRHDWVRPHWKLQJ"

3RZHUHGE\6HOHFW6XUYH\1(7Y
&RS\ULJKW:DJHQLQJHQ85$JURWHFKQRORJ\DQG)RRG6FLHQFHV*URXS
Annexe B
Analyse : scnarios et domaines des

ontologies
87
The ontologies
Anne Tireau
March, 29th 2010

Table des matires
1 Some scenarios for the application 5

1.1 Scenario 1 : John the dieter . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Scenario 2 : Wim the sportsman . . . . . . . . . . . . . . . . . . . . . 6
1.3 Scenario 3 : Esther the environmentalist . . . . . . . . . . . . . . . . . 6
1.4 Feedback scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Determine the domain of the ontologies 13

2.1 Personal property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Consumer household . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Consumer activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Personal trajectory about food . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Consumer behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Consumer with food / habits . . . . . . . . . . . . . . . . . . . . . . . 14
2.7 At the restaurant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.8 Food . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.9 Type of Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Important terms in the ontology 17

3.1 About Food . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 About Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 About objective/trajectory . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4 About Preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5 About Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.6 About Person . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.7 About TypeOfFeedback . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3
Some scenarios for the application
During the week Johns eaten at the Restaurant of the Future. We are Wednesday and
so we know what he ate the last 2 days (Tab. 1.1). We also know of what his lunch is
composed from the beginning of his coming in the RoF.
TABLE 1.1 Johns lunch

Monday Tuesday
Chapitre 1 Juice & Smoothies Milk & fruit Milk & fruit
Freshmade Soup Soep Bospaddenstoelen Soep chinese groenten
Bread & Bake-offs Bol zacht wit Bol zacht wit
Some scenarios for the application Hot meals & snacks Bami oriental Frikandel
Dessert & Juices Mono kwark aardbei Perz- Marac Mono dessert
Coffee & Tea cappuccino
1.1 Scenario 1 : John the dieter

John is a male, 50 years old and 1.80 meter tall (Fig. 1.1). He works in the Information
1.2 Scenario 2 : Wim the sportsman
Management team, in front of his screen all the day and doesnt travel a lot. Hes a Wim is a male, 26 years old and hes 1.92 meter tall. He works in the Vision team from
regular customer of the Restaurant of the Future (RoF), since he eats at least 4 days per 1 year now. His work is stressful because he has just begun a state-of-the-art project with
week. He never comes at the restaurant with an external food. He has rarely working a lot of pressure. But Wim like competition. Thats why he has nevertheless chosen to
lunch, but he eats often with the members of his team. John isnt a sportsman and he work in part time (70%) since he can devote a lot of time to Football, his preferred sport.
lives too far from his work to come with a bike, so he comes by car. His BMI is about Thus Wim plays in the amateur championship. This year his team has every chance to
30, so he has to loose weight and thats why he has a particular less calorie diet. The win the championship which will begin in 2 months only. So, he has doubled all his
problem is that John is greedy and is used to choose sweet course, he always takes a training. Of course he also continues to come by bicycle to his work : 60 km every days.
dessert to finish his lunch. And to take no chances, hes decided to respect a particular sportive diet, with the help
of RoFAdviseApps, to be in great shape during the championship ! Currently Wim dont
have any health problem. Hes not particularly difficult upon food, he likes snack food,
because rapidly eaten and not expansive. He doesnt like big or official lunch.
From the beginning of the week Wim has eaten at the Restaurant of the Future. We
are Wednesday and so we know what he ate the last 2 days (Tab. 1.2). We also know of
what his lunch is composed from the beginning of his coming in the RoF.
1.3 Scenario 3 : Esther the environmentalist

Esther is a female, 39 years old and hes 1.72 meter tall. She is slim and in good
health. The only problem is that shes tomato intolerance. What is really important for
her is "to save the world", shes a humanist person and so, she wants the most she could
F IGURE 1.1 Johns case eat organic, fair-trade or animal-friendly food. She is very carefully of what her eat. She
works with John and come every day to the RoF. She often comes with her own food,
5 6
1.4 Feedback scenarios Some scenarios for the application
TABLE 1.2 Wims lunch

Monday Tuesday
Juice & Smoothies Melk 1/4 liter Melk 1/4 liter
Salads Rauwkost/ saladebar middel
Hot meals & snacks Broodje hotdog Pizza Turkse
Dessert & Juices Banaan
Lemonades Sprite flesje
drink most often (fruit juice or warm tea). Like a lot of women she loves chocolate and
she often gives in the temptation to take chocolate dessert or warm chocolate at the end
of the lunch, even if she has eaten ones fill. She makes a bit sports the weekend (hike in F IGURE 1.2 Johns e-mail
the nature) and she comes every days with her bicycle (against the pollution of course).
Web solution John is at his office and log on his count at the RoF Advise Website.
During the week Esthers eaten at the Restaurant of the Future. We are Wednesday Maybe he received an e-mail to inform him that he can connect to it. Then he can
and so we know what she ate the last 2 days (Tab. 1.3). We also know of what her lunch navigate through the product available at the RoF. The products are sorted for him. He
is composed from the beginning of her coming in the RoF. has access to a predefine selection of food and information about their, but also to all
the other food available today.
TABLE 1.3 Esthers lunch
Monday Tuesday Web/Wap solution for mobile The early solution could have or be a mobile phone
Juice & Smoothies Tiramisu version and be used at the RoF.
Salads Rauwkost/ saladebar middel
Freshmade Soup Soep Courgette SmartphoneApps solution John synchronize his Smartphone to update the RoF Ad-
Hot meals & snacks Zalmmoot Omelet Met Kaas vise Apps at his office or with Wifi/3G access at the RoF. He can use it at the RoF.
Dessert & Juices Dessert 1,30
Coffee & Tea cappuccino
Wednesday scenarios
For the different solution, we choose Smartphone representation."
1.4 Feedback scenarios Preselected product solution The food are selected and sorted according :
From information about the person and the RoFs menu we want to advise our consu- the context of the lunch (mainly the daily menu of the RoF),
mer about food that could fit their. There are many solutions to advise them : by email, Johns preferences (what Johns likes and wants),
web or Smartphone. There also different solution to access to the information. Johns profile (Johns nutritive needs).
Question : What do we propose a menu (link between courses) or a products per
category ? In this document we consider that for each category we can advise one or
Means of communication
more product.
E-mail solution John is at his office and receives an e-mail around 11 oclock. This
e-mail contains a selection and a advise of foods for him (Fig. 1.2). John can print or After update his Smartphone John can watch on his Smartphone what are RoFAdvi-
just notice the e-mail advise and go to the RoF for the lunch. seApps proposes for him today. It could be at his office or at the RoF. He can navigate
through the RoFs categories (Fig. 1.3) and looking for informations about foods and
7 8
1.4 Feedback scenarios Some scenarios for the application
make his final choice. Smartphone and search what he wants to eat today. When he selects and item, the sys-
tem dynamically propose to him alternatives. These alternatives are selected and sorted
by the system according his preferences (Fig. 1.5).
F IGURE 1.3 navigation by Smartphones Categories

F IGURE 1.5 Others alternatives
When John explore one category, he can watch some product which are selected and
sorted by the system. For each product he can access to complementary and relevant
information for him (Fig. 1.4). Dynamic advice solution : My Tray Like the concept of basket in a Web site store,
John can in the same way adds product on his virtual and real tray. From this he can
access to a summarize of his lunch. The proposition of the system is more dynamic,
because another criteria is what he has already chose. So, John can juggle with the
product to compose and make compromise between his choice to build his lunch... (if
he has the time to). (Fig. 1.6)
Information displayed
Like food, the informations about food and their granularity are selected for John.
Not all the information are displayed by the system. There also are many means to dis-
play it. It could be Johns choice or determined by his knowledge about food (nutrition,
traceability, etc.). We could propose adding to raw data symbols to help (Fig. 1.7)
F IGURE 1.4 selected and sorted products and more details
Dynamic alternatives solution In the same way that the early solution, John needs
to update his Smartphones RoFAdviseApps and maybe to have a Wifi/3G access (de-
pending of the technology chosen). Then at his office or at the RoF he can consult hes
9 10
1.4 Feedback scenarios
F IGURE 1.6 My Tray
F IGURE 1.7 raw data displaying
11
Determine the domain of the ontologies
2.4 Personal trajectory about food

What personal trajectory has the consumer ?
Diet trajectory ?
Weight : lost ? Keep stable ? Get weight ?
Sodium : low ? Balance ?
Chapitre 2 All component, nutriment, vitamins... (fat, sugar, salt, B...) treatment/diet
Sportive : high ? less ?
Vegetarian : what kind ?
Determine the domain of the ontologies Economic trajectory ?
Fair trade ?
Cheap ?
Environmental trajectory ?
Animal friendly ?
2.1 Personal property Organic ?
Why this reason ?
What physical properties have the consumer ? (age, size, BMI...) Aesthetic
What are his Biophysical properties ? (about oro-gastro intestinal physiology) Health (feeling better...) / Illness (allergy, diabetes, anorexia, joint, backache...)
What is his Genetic background ? (Weight problem family...) Religion
Personal conviction
Activity (sports...)
Social relation (family, work...)
2.2 Consumer household
How many people are in his household ? age ? gender ? 2.5 Consumer behaviour
Who go to shopping for food ?
Who is cooking ? What are his Personal knowledge about food ?
What are his previous experiences or history in diet and food ?
What is his type of cognitions kind ? (looks, heard, kinesics sensibility)

2.3 Consumer activity
Does he work a lot ? (Measurement ?) 2.6 Consumer with food / habits
How many hours per day does he work ?
How important is food / eating for the consumer ?
What does he do the weekend ? Sports ? Cooking ? Activities ? Does he like eating ?
How many parties/dinner does he go by month ?
How long is his lunch time during the week ?
Does he do sports ? How long is his lunch time during the weekend ?
What kind of sports ? Frequency ? Level ? Duration ? Does he miss lunch time ? What is the frequency of this ?
How does he come to work ?
How many kilometre ? Frequency ? What is the composition of his lunch during the week ?
13 14
2.7 At the restaurant Determine the domain of the ontologies
Does he often drink wine, beer or an other alcoholic drink ? With what does it combine well ?
How many course of a meal has one lunch ? What is its origin ? (Foreign speciality...)
Does he take a coffee, tea or chocolate after lunch ? What is its traceability ? (Fair trade)
How does it look ? smell ?
Is he fond of good food ? Is a photo of it available ?
What is more important quality or quantity ?
How much does he eat ?
2.9 Type of Feedback
What taste does he prefer ? Sweet ? Salt ? Hot ? Spicy ? ...
Does exist food that he unconditional loves or hates ? What kind of feedback / information does he need ?
Does he provide information on where to find the food ?
How does he choose his food : by smell, look... ? Does he need alternatives ?
Which information does he need ? (organic...) If he just need raw information about food ? What kind ?
Does he want eating a food if it looks good or if someone eats it ? Have he need to access his lunch history ?
Does he like trying new food ? Does he prefer receive an email with the menu and/or proposition before going to
Does he like vary his menu ? lunch ?
Does he need an interactive navigation among the foods information ?
Does he eat without being hungry ?
Does emotion/feel make he hungry or satiate ?
Does he feel satiated when his meal was finished ?
How many time per week does he go to the RoF ?
2.7 At the restaurant

What does he already have on his tray ?
Does he see all alternative food in the restaurant ?
Is he hungry ?
How many people are with him ?
Is it a working lunch with negotiation... ?
Is it a calm lunch with good colleagues ?
How many time has he to lunch ?
Does he have a drink in this tray ?
Does he bring his own lunch ? What is it ? For what kind of course ?
2.8 Food
In what category is it ? (Fruit...)
What are their nutritive properties ?
It is newer in the menu ? Special menu ? (Christmas...)
15 16
Important terms in the ontology
Weather : temperature, light...,

Time/date of the of the lunch ;
Human context :
description of the social context : how many people eat with him, relax/work
lunch,
description of the time he has for the lunch ;
Chapitre 3
Important terms in the ontology 3.3 About objective/trajectory

What does the consumer want ? What is the objective of the system/diet ?
Diet : vegetarian, sportive, restrict, variability of course, discovering, etc.
3.1 About Food Economic : fair trade, cheap/expansive
Environment : animal friendly, organic
This concept could represent one of the final product of the restaurant (for example : Taste/Sensitive : Quality/Quantity
Italian tomato soup). Reason : Religion, Health, Aesthetic, Activity, Social...
Product or Food (name of each course available in the RoF ? in english+dutch or Constraint (strength of) / Importance of the criteria
only in dutch ?) Date
Ingredient : composition of the Product (tomato, salmon, cumin...), all the name ?
availability ? 3.4 About Preference
Origin of ingredient, product. This is information about traceability.
Category of the ingredients (vegetable, fruit, meat, fish...)
What does the consumer like (and would want) ?
Nutritive properties : Energy (unit), Fat (unit), Vitamin, etc. Food
Appearance of the Product / Presentation (look, smell, color, etc.) Context
Recipe properties : temperature, fried food,... Objective
Quantity/Size of the product : per 100g, percent (unit ?)

Category of the product( just in the RoF or maybe larger ?) 3.5 About Profile
Cost of the product
The "Profile" could be composed of informations about the consumer and a nutrition
profile, maybe view like expert rule.
3.2 About Context For example :
This context could be about the context of the lunch. a sportive person, female, 30 years old, 1.70 m needs 450 Kcal per lunch ;
Material context : a person with BMI>35 needs to follow a less calorie diet ;
Menu
Restaurant of the Future environment : description of the room (table, color of Type : Sportive, BMI >, BMI <
sit...), of the disposition of the plat, staff, sound, etc. Needs : Energy (unit), Fat (unit),
17 18
3.6 About Person
3.6 About Person

Identity properties : first-name, last-name, sofinumber
Work properties : employer, address, telephone number, email, WUR-card num-
ber
Household properties : type : single, together without children... ;
Health properties : illness
Physical property gender, age/birth, weight (unit), length (unit), BMI (unit, label)
Choice behaviour : what could influence him (food, context...)
Genetic background
Habits
Activity
3.7 About TypeOfFeedback

Food information needed
Type
Communication means : email, web, iPhone
User-friendliness : text, numerical, color, traffic light, percent, graph
19
Annexe C
Facteurs essentiels du choix daliments
99
Essential factors that influence eating and drinking behaviour and food choice
FBR-CS MR FBR-CS FBR-CS MR LEI
Genetic factors Cognition Memory Time

Immuno system Emotion Motivation Previous experiences Personality traits Social context
HV? Habits Attitudes FBR-CS
Brain imaging Decision making Learning Physical context
2.1 3.1 3.2 3.3 4.1
Age/Gender Coping
FBR-CS Physical condition Assimilation FBR-CS
HV Sensory acuity Psychological Habituation
2.2 factors 4.2
3
Biological & Intentionality

Oro-gastro- Situational
Physiological Signification
HV intestinal physiology FBR-CS
factors factors Attribution
2.3 4 4.3
2
Modelling
Data-integration
&
Co-ordination
0
Appearance Intrinsic product Socio-cultural
Interaction Taste Smell characteristics factors Culture Religion
FBR-CS Texture Trigeminal Perception 5 MR LEI
Economics Climate
1.1 1 5.1
Extrinsic product
characteristics
Complexity Expectations
Adaptation Trust in Industry
FBR-CS 6 MR LEI
& Government
Dynamic contrast
1.2 5.2
Irritation Claims
Boredom Brand label Integrity Societal beliefs
FBR-CS Sustainability Risk perception MR LEI
Aversion Packaging norms values
1.3 6.1 6.2 6.3 5.3
FBR MR LEI LEI FBR MR
Copyright J. Mojet ATO 2001

Characteristics of product consumer situation
F IGURE C.1 Reprsentation de la masse dune part de tiramisu avec TopBraid
F IGURE C.2 Reprsentation de la masse dhydrate de carbone dune pomme avec

TopBraid
Annexe D
Mode de vie du consommateur
F IGURE D.1 Reprsentation du concept Household avec TopBraid
F IGURE D.2 Reprsentation du concept SportiveActivity avec TopBraid
103
Annexe E
Concept de MeasurementCharacteristic
Listing E.1 Dfinition de la proprit fonctionnelle measureOf en code Turtle

meas:measureOf
a owl:FunctionalProperty , owl:ObjectProperty ;
rdfs:domain
[ a owl:Class ;
owl:unionOf ( < h t t p : / / www. wurvoc . o r g / r o f / a d v i c e # TypeOfMeasurement >
meas:MeasurementCharacteristic )
] ;
rdfs:label " m e a s u r e o f "@en ;
rdfs:range oum:Metrological_concept .
Listing E.2 Dfinition de la proprit fonctionnelle hasUnitOfMeasure en code Turtle

meas:hasUnitOfMeasure
a owl:FunctionalProperty , owl:ObjectProperty ;
rdfs:domain meas:MeasurementCharacteristic ;
rdfs:label " h a s u n i t "@en ;
rdfs:range oum:Unit_of_measure .
105
Annexe F
Turtle code of Consumer
cons:Consumer
a owl:Class ;
rdfs:comment " P e r s o n who i s a c o n s u m e r 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:onProperty cons:hasWURCardNumber
] ;
rdfs:subClassOf
owl:onProperty cons:hasLastName
] ;
rdfs:subClassOf
owl:onProperty cons:hasFirstName
] ;
rdfs:subClassOf
owl:onProperty cons:hasGender
] ;
rdfs:subClassOf
owl:onProperty cons:hasHeight
] ;
rdfs:subClassOf
owl:allValuesFrom cons:Height ;
owl:onProperty cons:hasHeight
] ;
rdfs:subClassOf
owl:minCardinality " 1 " ^^xsd:nonNegativeInteger ;
owl:onProperty cons:hasWeight
] ;
rdfs:subClassOf
107
Turtle code of Consumer
owl:allValuesFrom cons:Weight ;
owl:onProperty cons:hasWeight
] .
108
Annexe G
Infrastructure des donnes
G.1 Infrastructure des produits
109
Productparameters
SCOMP0056\RvdT_DataModel
Data-
model
SCOMP0056\RvdT_RawData
Backup-protocol
- PersoonID - ProductID
- producten - nutrienten - Weeknummer
Data- - prijs - ingredienten - Menuitems
bronnen - tijdstip van - kcal (aanbod)
geborgd - ...
afrekenen
- ... Sync-protocol
Data-
bronnen Sodexo
Kassa DB Sodexo DB? menu-cyclus
DB?
111
Persoonsparameters
SCOMP0056\RvdT_DataModel
Data-
model
SCOMP0056\RvdT_RawData
Backup-protocol
Persoon: Persoon: Gewicht:
- naam Persoon: - tijdstip
- naam
- leeftijd - naam - gewicht
Data- - e-mail
- opgegeven - e-mail
bronnen - WUR-card
geborgd gewicht - pasnummer
nummer
- lengte Sync-pro
- geslacht
Data-
bronnen Acces DB met Wageningen
Internetenqute Weegschaal
persoon-pas- Basis
database
koppeling Administratie
G.3 Infrastructure des donnes intgre
G.3 Infrastructure des donnes intgre
113
Parameter RVDT Weather
- Lighting RVDT [string] - Outdoor [float] < C>
- RVDT doors open / close [boolean] - Sun [float] <%>
- RVDT curtains open / close [boolean] - Precipitation [string]
Assortment - Utilization [float] <%> - Weather forecast [string]
- Bestaat_uit: Menu items - Indoor temperature [float] < C>
- Menu-cycle [string] - Area smell [string]
- Sound [string]
- Cash position [string]
Staff
- Sex [list]
- Age [int] <jaar>
Menu item - Behavior [string]
- Ingredients [string]
- Nutritional value [string]
- Energy value [string]
- Weight [float] <kg> Choice behavior
- Price [float] <Eur> - Invloed_van: Environmental factors
- Category [string] - Selectie_van: Menu item Environment Factor
- Presentation [string] - Entry in electoral area RVDT [time] Buffet
- Operation: Staff
- Description [string] - Leaving select portion RVDT [time] - Classification: Menu item
- Preparation: Buffets
- Crockery size [string] - Gait [[float] [float]] - Position [string]
- Device: Furniture
- Portion size [string] - Viewing habits [string] - Lighting [string]
- Opportunity: Special occasion
- Water at lunch? [Boolean] - Actuele_weer: Weather
- Packed lunch from home [boolean] - Settings: Parameter RVDT
Waste
- Product: Menu items Special occasion
- Weggooier: Person - Days of the week [list]
- Volume [float] <kg> - Season [list]
Individual Eetgedrag - Description [string]
- GFT / rest [list] - Invloed_van: Environmental factors
- Order of consumption [string]
- Hapsnelheid [float] <hap/minuut>
- Chewing time [float] <kauwbeweging / minuut>
- Hapgrootte [string]
Person - Meal time [float] <sec>
- Sex [list] Furniture
- Seating [string]
- BMI [float] - Heeft_stoel: Chair
- Seat selection [string]
- Age [int] <jaar> - Heeft_tafel: Table
- Preferred feedback [string]
- Has travel behavior: choice behavior
- Does eating: Individual Eetgedra
Table
Groepseetgedrag - Description [string]
Group Chair
- Invloed_van: Environmental factors - Position [string]
- Groepseetgedrag: Groepseetgedrag - Description [string]
- Average meal duration [float] <sec>
- Bestaat_uit: Persons - Position [string]
- Imitation eating? [boolean]
- Group size [int]
- Animated nature [string]
Annexe H
Vocabulaire partag
115
Vocabulaire partag
F IGURE H.1 Paquetage vocabulary, diagramme de classes partiel

116

Rapport Stage PFE

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Stage PFE

Transféré par

Droits d'auteur :

Formats disponibles

Acadmie de Montpellier

MMOIRE DE STAGE DE MASTER 2

Une application Smartphone pour un systme

Soutenu le 13 Septembre 2010

Sous la direction de : Nicole Koenderinck

Devant le jury compos de :

Prsident : Rodolphe Giroudeau

Rapporteurs : Isabelle Mougenot

Je tiens remercier, dans un premier temps, toute lquipe pdagogique de luniver-

Je remercie galement Madame Nicole Koenderinck ma tutrice au sein du dpartement

Je tiens remercier tout particulirement et tmoigner toute ma reconnaissance

4 Mise en uvre au travers dune architecture logicielle 41

4.3.4 Gestion de la tentation . . . . . . . . . . . . . . . . . . . . . . 57

A Questionnaire pour les consommateurs du RoF 81

B Analyse : scnarios et domaines des ontologies 87

C Facteurs essentiels du choix daliments 99

D Mode de vie du consommateur 103

E Concept de MeasurementCharacteristic 105

F Turtle code of Consumer 107

G Infrastructure des donnes 109

H Vocabulaire partag 115

La dmarche gnrale sera teste et valide au travers de la ralisation dun pro-

1.1 Contexte du domaine applicatif

Le Restaurant du Futur est un restaurant dentreprise, en libre-service, situ sur

F IGURE 1.1 Restaurant du Futur : buffet de la salle principale, caisse enregistreuse,

La personnalisation des conseils va aussi dpendre des connaissances disponibles

ses objectifs dittiques (rgime vgtarien ou hypocalorique par exemple),

1.2 Objectifs informatiques

La personnalisation du message diffus peut influencer son efficacit. Elle va

Les ractions du systme au choix du consommateur sont aussi des fonction-

6. IHM : Interface Homme-Machine

F IGURE 1.2 Architecture gnrale du prototype

de valider la globalit de lapproche. Les profils dfinis apportent individuellement une

Recommandations dittiques pour John : dans le cadre dun projet pour le

Exemple simple de scnario dutilisation du Smartphone : John quitte son lab-

catgories daliments disponibles aujourdhui, il sait en regardant la liste quil pourra

Pour mettre en place le prototype de diffusion dinformations alimentaires person-

2.1 Ontologies et outils du Web Semantic

Dans le contexte de linformatique et des sciences de linformation, une ontologie

Nous pouvons distinguer plusieurs types dontologie, regroups et comments par

les ontologies gnriques ou mta-ontologies : moins gnriques que les prc-

F IGURE 2.1 Pyramide des technologies du Web Smantique

F IGURE 2.2 Reprsentation graphique dun triplet RDF

11. OWL-DL : Ontology Web Language Description Logics)

2.2 Web Service

2.3 La plateforme Smartphone

Le systme dexploitation Windows Phone 7 a t choisi pour notre prototype. Ce

Lmulateur Windows Phone 7 est une application 23 de type "ordinateur de bureau"

19. PDA : Personal digital assistant

Linfrastructure de liaison de donnes est importante pour cette technologie et

F IGURE 2.3 Concepts de base dune liaison de donnes

XAML XAML (eXtensible Application Markup Language) est un langage de bal-

Le patron de conception Modle-Vue-VueModle (MVVM), 27 est un patron de con-

F IGURE 2.4 Schma du modle Modle-Vue-VueModle

29. Complment disponible ladresse : http://msdn.microsoft.com/library/bb308960.asp

Les modles de connaissances, au sein du systme PEA (Personal Eating Advisor),

Deux champs principaux de connaissances sont impliqus dans le systme PEA et

Nous prsenterons, en premier lieu, le processus de conception et lorganisation

3.1 Processus de conception et interaction entre les com-

Le cas du modle de conseils alimentaires personnaliss

Stratgie de combinaison des composants ontologiques

F IGURE 3.1 Interaction entre le modle de conseils et les ontologies

F IGURE 3.2 Reprsentation des composants ontologiques majeurs, au travers dun

3.2 Ontologie des produits du Restaurant du Futur