Chaque intention I est définie par un verbe v, qui caractérise son action, une cible tg, sur laquelle l’action agit, et un ensemble optionnel de paramètres par.
I = { < v , tg , par > }
Définition 2. Formalisation d'une intention qu'un service permet de satisfaire
Une telle définition, basée sur une ontologie préétablie, n’est envisageable que dans le cadre fermé d’un Système d’Information. En effet, ces systèmes n’autorisent pas un comportement ouvert sur des intentions et des cibles non-autorisées ou inconnues. D’autre
part, dans un environnement pervasif ouvert, l’expression de l’intention à l’aide d’un ensemble prédéfini de termes est difficilement imaginable, laissant une part trop importante à l’ambigüité. Cette ambigüité vient, en réalité, des utilisateurs : dans un environnement pervasif ouvert, le profil des utilisateurs n’est pas forcément connu à l’avance et le mode d’expression de ces utilisateurs peut être très différent.
Le contexte du service 5 . 2 . 3 .
Une intention n’est pas le fruit du hasard. Elle représente le besoin d’un utilisateur. Or ce besoin émerge dans un contexte donné. En d’autres termes, la notion d’intention est directement liée à la notion de contexte. Nous pensons qu’une intention n’a de sens que lorsqu’on la considère dans un contexte donné. Selon nous, et comme l’illustre la partie A de la Figure 26, un utilisateur invoque un service parce que celui-ci lui permettra de satisfaire une intention. Cependant, le contexte dans lequel émerge cette intention est lui-aussi significatif. Il peut influencer considérablement la manière dont cette intention peut être satisfaite, et donc influencer l’exécution même du service (par exemple, par le choix d’une implémentation qui s’adapte au contexte courant de l’utilisateur). Inversement, un utilisateur n’invoque pas un service uniquement parce qu’il est dans un contexte donné. Il le fait parce que ce service lui permettra d’atteindre ses objectifs dans ce contexte précis. La partie A Figure 26 schématise cette vision, selon laquelle un service est proposé afin de satisfaire une intention de l’utilisateur émergeant dans un contexte précis.
Cette vision commence à se développer dans la littérature, comme nous l’avons discuté dans la section 3.5.2.4. Quelques auteurs, dont Santos et al. (Santos et al., 2009), proposent déjà d’associer ces deux notions. Cependant, pour beaucoup d’entre eux, cette association reste assez floue. Par exemple, Santos et al. (Santos et al., 2009) ne considèrent le contexte que comme un filtre pour la découverte de services, le contexte étant vu comme une partie des entrées nécessaires aux services, et les intentions comme de simples étiquettes permettant de relier les demandes des utilisateurs aux services. Nous croyons, au contraire, que ces deux notions sont complémentaires et indissociables. Le contexte ne peut être réduit à de simples paramètres d’entrées ou de sorties. Non seulement il influence l’exécution du service, mais il caractérise aussi le service lui-même et les intentions ciblées par le service.
A partir de la partie B de la Figure 26, on observe que l’impact de la notion de contexte sur le service est double : il influence son exécution et caractérise le service. Nous considérons qu’un service svi se trouve lui aussi immergé dans l’espace de services. Par conséquent, il se place lui-même dans un contexte Cxsvi donné. Ainsi, à l’instar de (Vanrompay et al., 2011), nous considérons qu’un service peut être associé à deux contextes complémentaires. Tout d’abord, un service s’exécute lui-même dans un contexte Cxsvi donné. Celui-ci représente un ensemble non vide d’observations contextuelles qui sert non seulement à indiquer les observations de contexte dans lesquelles le service est exécuté par son fournisseur, mais également à caractériser le positionnement de ce service dans l’espace de services. Le service est un objet dynamique qui bouge dans le temps et qui doit être observé. Ensuite, nous considérons également qu’un service sv i peut avoir un contexte requis CxRsvi représentant un ensemble non vide de conditions contextuelles dans lesquelles le service est le plus apte à atteindre ses objectifs, i.e. les conditions de contexte auxquelles il peut s’adapter. En d’autres termes, le contexte requis CxRsvi représente un ensemble de conditions de contexte permettant au service une meilleure possibilité de satisfaction des intentions qui lui sont associées. Il s’agit d’un filtre défini sur les observations de contexte de l’utilisateur : plus le contexte courant observé pour l’utilisateur correspond au contexte requis, plus le service aura de chance de s’adapter à cette situation et de satisfaire au mieux l’utilisateur.
Ainsi, dans le cadre des mécanismes de découverte (cf. Chapitre 7) et de prédiction (cf. Chapitre 8) de services, le contexte requis est exploité dans le cadre de la sélection des services les plus appropriés au contexte courant de l’utilisateur (cf. section 7.2.2.4). Il faut mettre en correspondance le contexte requis du service (CxRsvi) avec le contexte courant l’utilisateur (CxU), afin de sélectionner les services qui peuvent s’adapter au mieux à la situation courante de l’utilisateur.
Dans le cadre de notre espace de services, la notion de contexte doit être modélisée d’une manière générique afin de permettre à n’importe quel modèle de contexte (cf. section 2.3.2) de fonctionner avec notre cadre conceptuel des SIP. Pour ce faire, nous avons besoin d’une modélisation de contexte de plus haut niveau qui peut être instanciée par n’importe quelle approche de contexte. Ainsi, afin de formaliser la notion de contexte nous proposons de définir avant un méta-modèle de contexte qui va être utilisé dans notre cadre conceptuel des SIP. Ce méta-modèle de contexte représente une modélisation générique de contexte Cx. Il permet à toute approche orientée contexte d’utiliser notre méta-modèle pour représenter ses informations contextuelles, quelque soit le modèle de contexte qu’elle va utiliser au niveau implémentation. Quant au contexte requis CxRsvi, il aura une structure similaire à Cxsvi, mais il doit exprimer des conditions contextuelles, lesquelles nécessitent un langage sémantique pour pouvoir les représenter sous la forme la plus adéquate. Ce langage sémantique va essentiellement dépendre du modèle de contexte choisi et mis en place au niveau implémentation. Ainsi, il est plus approprié de garder le choix de la modélisation de contexte CxRsvi au niveau implémentation et de spécifier ses conditions contextuelles en langage naturel au niveau conceptuel. En conséquence, au niveau conceptuel, il faut spécifier en langage naturel les conditions contextuelles qui vont être attachées à chaque service. Par la suite, en
choisissant le langage adéquat au niveau implémentation qui correspond au modèle de contexte choisi, il faudra traduire ces conditions pour pouvoir les traiter.
Nous présenterons le méta-modèle de contexte dans la section 5.3.1. Nous formalisons, dans la section 5.3.2, la notion de contexte à travers la notion d’observation et de capteur.
Ainsi, à partir de ce qu’on vient de présenter, il nous paraît évident qu’un service ne peut être défini sans tenir compte de ces éléments qui lui permettent de mieux se situer dans son environnement et de réagir à celui-ci. A ces éléments, on ajoute les notions préalablement mises en évidence : les intentions (Définition 2) et les fonctionnalités (Définition 1) offertes par le service. Nous formalisons ainsi la notion de service comme l’illustre la Définition 3