Remue-méninges

Au menu :

Repositionner le Contexte
Espace intelligent ouvert
Références
Historique des révisions

Ce qui se trouve ici tient à mes recherches et à celles de mes collègues de DOMUS sur la contextualisation, les agents autonomes et les espaces intelligents. à la suggestion de l'un de mes codirecteurs de recherche, le professeur Bessam Abdulrazak (l'autre étant le non-moins pertinent Yacine Belala), cette page contiendra des propositions sur un certain nombres de sujets sur lesquels il faudrait bien échanger.

Votre feedback sera le bienvenu (Patrice «.» Roy à Usherbrooke «.» ca). Plus encore : il est activement sollicité!

Remuons des idées...

Repositionner le Contexte

Globalement, je pense qu'il faut repositionner la vision généralement admise du Contexte pour permettre d'ouvrir la problématique des espaces intelligents à celle de l'espace intelligent ouvert. Ce que je m'appliquerai à faire dans cette section sera d'exposer les raisons de cette position, pour que la discussion soit plus riche et plus féconde.

La définition la plus citée présentement...

En 2010, la définition la plus citée du Contexte[1] semble être celle de [Dey99] :

« Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves »

[Dey99] propose aussi une définition de ce qu'on nomme Context-awareness, et que je suggère qu'on identifie en français par contextualisation :

« A system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user’s task »

Un complément pertinent à la définition de [Dey99] est celle de [Winograd01], selon qui :

« Context is an operational term: Something is context because of the way it is used in interpretation, not due to its inherent properties »

Ces définitions ont fait école car elles sont suffisamment ouvertes pour couvrir l'essentiel des travaux faits en contextualisation jusqu'à présent. Cependant, elles associent de près la pertinence du Contexte et de la contextualisation à l'usager (traditionnellement présenté au singulier) d'un système contextualisé, ce qui pose problème pour la vision qui sous-tend mes propres travaux et par laquelle j'espère contribuer à ouvrir la porte vers un espace intelligent ouvert, dépassant les frontières de nos laboratoires.

Les forces de la définition de [Dey99]

La définition de [Dey99] est en deux temps, positionnant :

le Contexte comme étant ce qui caractérise une entité, et
une entité (au sens de la définition du Contexte) comme ce qui est pertinent comme les interactions entre un usager et une application (incluant ceux-ci).

Pour alléger l'écriture, j'écrirai Entité (avec un « E » majuscule) pour spécifier une entité au sens des définitions du Contexte à partir de ce point.

Le Contexte caractérise la situation de ce qui est pertinent aux interactions entre l'humain et l'application. Ceci couvre bien, à mon avis, les besoins de la majorité des applications développées pour les espaces intelligents mis à notre disposition au moment d'écrire ceci (juillet 2010), c'est-à-dire les applications (programmes ou systèmes complexes) visant à interagir avec (assister, encadrer, étudier, ...) un humain dans un environnement contrôlé, que je nomme dans mes textes un controlled intelligent space, et dont DOMUS est un bon exemple.

Le lien fort que fait cette définition entre l'état d'Entité et sa pertinence envers les interactions entre l'usager et l'application pose problème, à mon sens (voir ceci pour les détails ce ce que je perçois comme problème, et cela pour le repositionnement que je préconise). L'espace intelligent ouvert a ses exigences, et pour les rencontrer, j'estime (j'espère aller plus loin et démontrer, éventuellement) qu'il faut se défaire de ce lien entre le Contexte et un usager.

Les problèmes avec la définition de [Dey99]

Tel que mentionné plus haut, [Dey99] lie l'état d'Entité à son importance envers les relations entre l'usager et l'application avec laquelle il interagit. Pourtant, dans une optique large comme celle de l'espace intelligent ouvert, ce lien est inapproprié, du moins selon mon acception. En effet :

la supposition de mobilité entière d'un usager laisse supposer l'intérêt de systèmes qui savent s'auto-organiser et s'auto-diagnostiquer. Pourquoi le Contexte ne pourrait-il pas leur permettre de se décrire eux-mêmes? Pourquoi ne permettrait-il pas aux composants de ces systèmes de se décrire eux-mêmes, qu'ils aient trait à la réalité d'un usager ou non?
la contextualisation a clairement pour champ d'application l'assistance et l'encadrement des humains, et je n'ai pas l'intention de le nier, mais définir le Contexte en termes de l'un de ses champs d'application me semble inutilement contraignant;
l'étude du réel et l'interaction avec le réel sont des champs pour lesquels des applications « sans humains » sont envisageables. La plus évidente est le diagnostic de composants par d'autres composants, ce qui est particulièrement utile dans l'espace intelligent ouvert, mais on pourrait penser à plusieurs autres applications, comme par exemple :
- un système de climatisation autorégulé, pour une chambre d'hôtel ou pour une salle de serveurs;
- un système de supervision d'animaux de compagnie;
- un système de sécurité informatique qui aurait un comportement analogue à celui d'un système immunitaire; etc.

Je lis la vision de [Weiser91] comme une volonté de jonction des réalités physique (le monde des humains) et logique (le logiciel et son substrat matériel). Je pense que le Contexte peut être libéré de sa dépendance envers l'interaction des humains et de l'application contextualisée en le positionnait comme descriptif du réel augmenté (j'y reviens plus bas). Je présenterai un argumentaire plus complet dans [Roy10*], mais à la lecture de plusieurs définitions du Contexte ayant été utilisées dans des projets concrets, il faut selon moi qu'une définition adéquate du Contexte rencontre les critères suivants :

Le principe « ouvert/ fermé », en anglais Open/ Closed Principle, selon lequel les entités logicielles doivent être ouvertes pour fins d'extension mais fermées pour fins de modification, est un principe de l'approche orientée objet attribué à [Meyer88].

cette définition doit admettre le Contexte inhérent[2], ou Contexte brut;
cette définition doit admettre le Contexte émergent[3], ou Contexte synthétique;
cette définition ne doit pas imposer de contraintes architecturales aux systèmes contextualisés. Par exemple, elle ne doit pas forcer l'association du Contexte à un usager précis, ou imposer une contrainte de pertinence en lien avec la relation entre l'humain et le système. Un système donné peut centrer ses efforts sur un humain, mais la définition du Contexte doit rester neutre en ce sens;
pour permettre sa pérennité, la définition du Contexte doit être ouverte pour fins d'extension, puisque l'ensemble des Contextes admissibles pour un système contextualisé est susceptible de croître, ou du moins d'évoluer, au fil du temps et des versions des divers composants contextualisés;
pour éviter qu'elle ne permette d'inclure des éléments qu'on ne souhaiterait pas voir considérés comme étant du Contexte, la définition du Contexte doit être fermée à la pollution. Au sens où je l'entends ici, ne peut être Contexte que ce qui est pertinent en ce sens pour au moins un Acteur[4];
la définition du Contexte doit être indépendante de ses implémentations. Elle ne doit pas prescrire de schémas de conception spécifiques, et encore moins imposer d'idiomes de programmation particuliers[5]. Plus précisément, elle doit demeurer indépendante du langage de programmation, de la plateforme, du système d'exploitation et des choix de formatage. La définition doit permettre de couvrir les besoins de l'ensemble des systèmes contextualisés, sans se limiter aux caractéristiques d'un seul système.

Enfin, puisqu'il existe déjà des systèmes contextualisés, il est important que notre définition couvre les besoins de ces systèmes. L'idée ici est d'ouvrir le champ des possibles sans négliger les travaux qui ont eu lieu avant les nôtres.

Le rôle de la définition de [Winograd01]

La définition de [Winograd01], citée plus haut, est instructive quant à la nature du Contexte mais d'une manière différente de celle de la définition de [Dey99]. En effet, [Winograd01] nous dit que le Contexte est un terme opératoire, pas une caractéristique intrinsèque du réel. Le Contexte devient Contexte de par ce qui en est fait. Une donnée qui n'est pas exploitée en tant que Contexte reste une donnée. Le Contexte est foncièrement utile; il sert à au moins un Acteur.

Un exemple de Contexte qui n'est pas pertinent de manière universelle est le pedigree particulier d'un patient souffrant d'une maladie très rare, par exemple une affliction de la peau qui provoque une hypersensibilité à la lumière. Le Contexte requis par un agent accompagnant un tel individu dans la conduite de ses activités quotidiennes est très spécialisé, et peut ne pas être pertinent pour la majorité des Acteurs avoisinants.

Ceci soulève une question qui, à mon avis, a des répercussions profondes : qui jugera de ce qui est Contexte ou de ce qui n'est pas Contexte? J'utilise le mot qui ici d'une manière qui peut offenser, je le sais, mais l'idée ici est que le Contexte est utilisé, donc utilisé par au moins Acteur. Ce constat guidera en partie le repositionnement proposé plus bas.

Le repositionnement proposé

Le souci de couvrir la problématique de l'espace intelligent ouvert, jointe à l'optique d'utilité pour au moins un Acteur vers laquelle nous mène la définition de [Winograd01], m'amène à suggérer que la définition du Contexte soit repositionnée à partir des paramètres suivants :

nous voulons couvrir les besoins de l'ensemble des définitions importantes qui ont été utilisées jusqu'ici, incluant bien sûr les plus populaires;
nous voulons permettre un Contexte dont la pertinence est liée à l'utilité pour un Acteur plutôt que pour un humain, puisque nous envisageons un espace où les Acteurs demeurent pertinents et continuent d'occuper la réalité augmentée même quand les humains n'y participent pas eux-mêmes;
nous voulons demeurer neutres quant aux implémentations (voir plus bas pour des détails), donc conserver une définition du Contexte qui encadre et guide, soit, mais qui n'indique pas directement comment elle doit être implémentée.

à partir de ces paramètres, beaucoup plus détaillés dans [Roy10*], j'en arrive à proposer ce qui suit :

« Context is any information that can use to characterize the situation of an entity. An entity is any object, physical or logical, relevant to the Actor’s task »

Dans un même élan, la contextualisation deviendrait quant à elle ceci :

« An Actor is Context-aware if it uses Context to perform its tasks »

Examinons plus en détail ce que ce repositionnement implique :

Objet	Dey99	Roy10*	Remarques
Contexte	Context is any information that can be used to characterize the situation of an entity	Context is any information that can use to characterize the situation of an entity.	Le Contexte comme ce qui caractérise le réel (pour moi, le réel augmenté), plus particulièrement la situation d'une Entité, est ce que je proposerais de conserver. Cette partie de la définition est suffisamment contraignante pour éviter que l'on ne s'éparpille trop, mais reste assez ouverte pour que nous puissions l'adapter aux besoins de l'espace intelligent ouvert.
Entité	An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves	An entity is any object, physical or logical, relevant to the Actor’s task	Dans le respect de la définition de [Winograd01] comme dans la perspective d'ouverture qui guide notre démarche, j'estime que la clé du repositionnement est un changement de focus. Le Contexte, pour jouer pleinement son rôle, doit être ce que je nommerai un Contexte-selon. Est Contexte ce que l'Acteur qui le nomme ainsi juge pertinent de considérer Contexte. Une Entité est pertinente quand elle l'est au sens des tâches accomplies par l'Acteur. Le risque ici est de tomber dans un capharnaüm de visions contradictoires. C'est ce que je compte éviter par l'approche qui permettra de passer de la philosophie à l'implémentation, que je décrirai plus bas.
Contextualisation	A system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user’s task	An Actor is Context-aware if it uses Context to perform its tasks	Je propose quelque chose de plus simple : est contextualisé l'Acteur qui utilise le Contexte pour réaliser ses tâches. La contextualisation devient l'acte de consommer, traiter et produire du Contexte, alors que le Contexte décrit le réel augmenté de manière utile pour l'Acteur dans la réalisation de ses tâches.

Objet

Dey99

Roy10*

Remarques

Contexte

Context is any information that can be used to characterize the situation of an entity

Context is any information that can use to characterize the situation of an entity.

Le Contexte comme ce qui caractérise le réel (pour moi, le réel augmenté), plus particulièrement la situation d'une Entité, est ce que je proposerais de conserver. Cette partie de la définition est suffisamment contraignante pour éviter que l'on ne s'éparpille trop, mais reste assez ouverte pour que nous puissions l'adapter aux besoins de l'espace intelligent ouvert.

Entité

An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves

An entity is any object, physical or logical, relevant to the Actor’s task

Dans le respect de la définition de [Winograd01] comme dans la perspective d'ouverture qui guide notre démarche, j'estime que la clé du repositionnement est un changement de focus. Le Contexte, pour jouer pleinement son rôle, doit être ce que je nommerai un Contexte-selon. Est Contexte ce que l'Acteur qui le nomme ainsi juge pertinent de considérer Contexte. Une Entité est pertinente quand elle l'est au sens des tâches accomplies par l'Acteur.

Le risque ici est de tomber dans un capharnaüm de visions contradictoires. C'est ce que je compte éviter par l'approche qui permettra de passer de la philosophie à l'implémentation, que je décrirai plus bas.

Contextualisation

A system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user’s task

An Actor is Context-aware if it uses Context to perform its tasks

Je propose quelque chose de plus simple : est contextualisé l'Acteur qui utilise le Contexte pour réaliser ses tâches. La contextualisation devient l'acte de consommer, traiter et produire du Contexte, alors que le Contexte décrit le réel augmenté de manière utile pour l'Acteur dans la réalisation de ses tâches.

Le schéma à droite (tiré de [Roy10*]) met en relief les liens entre les définitions les plus usitées du Contexte et celle que je propose ici. Certaines références doivent être retouchées (il manque un « i » à Fujii, entre autres), mais les citations sont telles quelles.

Ce schéma vise à mettre en relief que nous pouvons, avec la définition du Contexte mise de l'avant ici, couvrir les mêmes besoins que ceux déjà couverts par les diverses définitions qui ont été mises en application par le passé. Ceci ne montre évidemment pas en quoi les nouvelles définitions permettent d'aborder de nouveaux problèmes, mais nous saurons au moins que nous n'avons pas perdu de capacité opératoire en cours de route.

De la philosophie à l'implémentation

J'aimerais maintenant montrer en quoi les définitions du Contexte et de la contextualisation telles que je les propose ne sont pas circulaires, malgré les apparences, en expliquant le rôle de ces définitions comme guides d'implémentation.

Volet subjectif du Contexte et rôle des Acteurs

Si le Contexte est déterminé par les besoins des Acteurs, il convient de tenir ce qui suit pour acquis :

il est possible que ce qui est Contexte soit différent pour deux Acteurs en interaction. Par exemple, un Acteur peut ne se préoccuper que de localisation alors qu'un autre peut ne se préoccuper que de seuils d'humidité ambiante;
il est possible que ce qui est Contexte soit semblable pour deux Acteurs en interaction mais soit exprimé différemment pour l'un et pour l'autre. Ces différences peuvent aller du simple (p. ex. : unités de mesure différentes, ce qui permet de ramener l'une à l'autre par une transformation banale) au complexe (p. ex. : expression dans des langues différentes de la même idée);
les producteurs de Contexte doivent se faire comprendre par les consommateurs de Contexte, et l'inverse est aussi vrai;
localement, un Acteur peut raisonner selon ses propres termes. C'est dans ses interactions avec les autres Acteurs qu'il lui faut trouver une manière de comprendre l'autre et de se faire comprendre par l'autre.

Dans le respect du repositionnement proposé de la définition du Contexte, je propose que le format utilisé pour transiger le Contexte soit universel, au sens de commun à tous les Acteurs, mais que la sémantique et le vocabulaire utilisés dans la formulation du Contexte soient locaux à chaque Acteur.

Par format commun, j'entends une manière commune à tous les Acteurs d'exprimer le Contexte lorsque celui-ci se transige entre eux (les formats locaux peuvent varier selon les plateformes et les langages; ce qui comptera sera d'offrir une API uniforme pour manipuler et exprimer le Contexte sur une plateforme donnée, mais dans le respect des idiomes des divers langages utilisés – on ne programme pas de la même manière en Java, en C++ ou en Erlang, à titre d'exemple). Pour cette raison, je pense que la publication de Contexte et la demande de Contexte doivent faire partie des services de la plateforme, qui assurera l'homogénéité du format et facilitera la migration éventuelle d'une version à l'autre du format utilisé[6], alors que la responsabilité des Acteurs devrait s'exprimer en termes d'interaction avec la plateforme, dans le code.

Dans une interaction entre Acteurs, la mise en correspondance des Contextes, celui publié par un producteur et celui demandé par un consommateur, sera une tâche infrastructurelle et tombera sous l'égide de la plateforme (plus bas).

Cette approche respecte la philosophie préconisée plus haut :

si l'Acteur A est un consommateur de Contexte et ne considère Contexte que ce qui concerne la géolocalisation, alors il opérera sur du Contexte de cette nature. Si un producteur (Acteur B) de Contexte lui fait une offre, celle-ci pourra être filtrée (à la source ou sur réception, selon les modalités choisies) et passer outre ce qui, selon B, est Contexte mais ne concerne pas A;
le processus de filtrage peut mener à :
1. un ensemble vide, dans le cas où ce que propose B (le producteur) est sans intérêt pour A (le consommateur);
2. un ensemble contenant du Contexte correspondant directement et de manière sans équivoque aux demandes, si B et A ont des intérêts en commun et partagent une vision du Contexte (si l'intersection des Contextes de A et de B est non-vide mais sans redondance); et
3. un ensemble contenant une part de redondance et demandant à A (le consommateur) un effort supplémentaire pour en tirer ce qui lui convient (si l'intersection des Contextes de A et de B est non-vide mais contient de la redondance)
techniquement, l'espace contextuel d'un Acteur donné peut être représenté par une multimap (un conteneur associatif admettant plusieurs éléments pour une même clé);
techniquement toujours, tout Acteur doit être conçu pour gérer les cas a, b et c ci-dessus lorsqu'il consulte un producteur de Contexte (obtention d'un ensemble vide, d'un ensemble de Contextes sans redondance, et d'un ensemble de Contextes avec redondance);
en pratique, la gestion de l'espace contextuel d'un Acteur relèvera en partie de la plateforme et en partie de l'Acteur lui-même. Il sera possible à un Acteur de consulter cet espace et d'y écrire, en particulier d'en supprimer des éléments. Voir la section prévue à cet effet, plus bas, pour plus de détails.

Volet subjectif du Contexte et rôle de la plateforme

Certains services de la plateforme ont déjà été mentionnés plus haut, en particulier indiqués dans le tableau ci-dessous. La colonne Type indique si le service est offert par la plateforme aux Acteurs qui y résident (API) ou s'il s'agit d'un service entre plateformes (Réseau). Dans le tableau, le terme « sa plateforme », en rérérence à un Acteur, signifie la plateforme sur laquelle l'Acteur loge, sur laquelle il s'exécute. La plateforme est elle-même un composant logé sur un noeud, qui sert de conteneur pour d'autres composants (les Acteurs), et assure la présence d'une gamme minimale de services de base.

Service	Type	Remarques
Publication de l'offre de Contexte	API	L'Acteur invoque un service de publication de Contexte de sa plateforme. La plateforme devient responsable de publier ce Contexte aux autres Acteurs sur d'autres plateformes (ou d'autres instances de la plateforme).
Soumission d'une requête de Contexte	API	L'Acteur invoque un service de soumission d'une requéte de Contexte de sa plateforme. La plateforme devient responsable de quérir ce Contexte auprès d'autres plateformes (ou d'autres instances de la plateforme).
Mise en correspondance de l'offre et de la demande	Réseau	La plateforme demanderesse interroge les plateformes avoisinantes pour obtenir le Contexte demandé par les Acteurs qui se logent sur elle. Les plateformes (les instances de la plateforme) négocient entre elles pour un sain filtrage du Contexte. La plateforme demanderesse met à jour l'espace contextuel de chacun des Acteurs qui s'y logent en fonction du fruit de cet échange.

Si les Acteurs sont des spécialistes de domaines précis, il est préférable de demander d'eux qu'ils se concentrent sur leur tâche. Mettre en correspondance les requêtes des consommateurs et l'offre des producteurs n'est pas, à mon sens, un travail d'Acteur mais bien une tâche de la plateforme en tant que telle.

Si le format du Contexte est commun et si la sémantique du Contexte est locale à chaque Acteur, la mise en correspondance automatisée de l'offre et de la demande est soumise à certaines contraintes :

elle doit reposer en partie sur la syntaxe utilisée, qui est le point en commun des Acteurs;
elle peut reposer sur un vocabulaire partagé, mais il y a ici plusieurs pièges (voir ci-dessous) alors je ne souhaite pas aller dans cette direction;
elle peut passer par un tiers médiateur, mais ceci nous amènerait directement dans le piège de la dépendance envers les noeuds clés (voir espace intelligent ouvert, plus bas); et
elle peut adopter une approche hybride, ce que je propose dans cette section.

Tout d'abord, pourquoi éviter la question d'un vocabulaire partagé, ou à tout le moins d'une solution reposant sur cette seule tactique? Parce qu'il est impossible de tout prévoir d'avance. Conséquemment, la banque initiale de vocabulaire ne suffira pas, quelle que soit son étendue. Il serait par contre possible d'utiliser un vocabulaire minimaliste (unité de mesure, temps, lieu) et d'offrir des services de plateforme à fine granularité pour ceux-ci (par exemple, des services spécifiques pour manipuler le lieu, changer de référentiel, transformer une valeur d'une unité de mesure vers une autre pour les cas les plus typiques), mais je vois plusieurs irritants à cette approche :

cela facilite la rédaction du code des Acteurs pour les cas particuliers auxquels nous aurions pensé de prime abord, mais complique la rédaction de ce code pour les cas que nous aurions jugés atypiques;
cela intègre à la plateforme un catalogue de services d'une granularité qui, à mon avis, est trop fine (la plateforme se retrouve alors à faire plus que ce qu'elle ne devrait – du Platform Bloat, à mon humble avis);
cela complique les tâches qui sont véritablement du niveau de la plateforme, en imposant deux catégories de citoyens (les Contextes prospectifs que la plateforme connaît et supporte implicitement, et les autres). Par exemple, déterminer un mécanisme de mise en commun de l'offre et de la demande de Contexte me semble plus lourd s'il faut tenir compte des cas particuliers du code des divers Acteurs;
philosophiquement, une telle approche va à l'encontre de la définition proposée, selon laquelle c'est l'Acteur qui détermine ce qui est Contexte pour lui, en donnant à certains Contextes un statut particulier.

Notons que le vocabulaire commun décrit ici pourrait être une banque d'identifiants numériques, le problème demeurerait entier. La représentation des mots ou des identifiants n'est pas le noeud du problème; c'est la supposition d'un vocabulaire a priori qui irrite ici.

Il n'y a pas lieu, à mon avis, de définir de véritables Contextes primitifs, ou de créer une dichotomie entre les Contextes primitifs et les Contextes « maison » de chaque Acteur, comme il y aurait dans certains langages une distinction entre le support offert aux primitifs et aux classes. étant de ceux qui implémenteront l'infrastructure en bout de ligne, je préfère un modèle plus simple, à la fois du point de vue du code client (le code des Acteurs) et du point de vue de l'infrastructure elle-même.

L'alternative du tiers médiateur serait de transiger à travers une sorte de base de données centrale (ou d'équivalent, NoSQL ou autre), où les divers Acteurs pourraient découvrir le sens à accorder aux Contextes exprimés d'une manière qui leur échappe. Par exemple (un exemple simple, pour ne pas dire simpliste), un Acteur désireux d'obtenir une valeur de Température pourrait rencontrer un Acteur publiant du Temperature (sans accent). Ne connaissant pas cette nomenclature, il pourrait interroger le tiers médiateur et constater que ce sont deux écritures pour un même concept, et constater du même coup que les deux sont équivalents.

Le problème, dans l'espace intelligent ouvert, est qu'il n'est pas possible, en général, de garantir la présence d'un tiers médiateur (à jour!) en tout temps; si un tiers médiateur est disponible, rien ne l'empêche d'offrir un service de comparaison de Contextes, mais les Acteurs ne doivent pas dépendre d'un tel noeud pour leurs propres opérations (ils seraient alors paralysés en son absence).

Je penche pour une approche comme la suivante :

des Acteurs (probablement fixes) offrant des services par lesquels il est possible d'obtenir des équivalents de descriptifs de Contexte;
un Acteur croisant le voisinage d'un fournisseur de descriptifs équivalents peut y piger ceux qui lui semblent pertinents (tous, pourquoi pas, s'ils sont en nombre raisonnable) et les inscrire dans son espace contextuel personnel;
un Acteur consommant du Contexte peut construire ses requêtes en fonction des équivalents qu'il connaît, tout comme un producteur de Contexte peut accepter les requêtes en fonction des équivalents dont il est « conscient »;
si ni le producteur, ni le consommateur ne parviennent à faire une correspondance entre le Contexte exprimé et le Contexte demandé, alors la mise en correspondance n'a tout simplement pas lieu, et la vie continue.

Une vision schématique de l'espace contextuel tel que je l'envisage peut sans doute aider à ce stade-ci.

Espace contextuel

Je nomme espace contextuel d'un Acteur le lieu où sont logés les Contextes connus de cet Acteur.

Puisque les Acteurs opèrent à partir du Contexte (ils consomment, traitent et produisent du Contexte), l'espace contextuel d'un Acteur est l'espace de ses états. Son monde, en quelque sorte, du moins selon la vision architecturale que je mets de l'avant ici. Un Contexte qui n'est pas situé dans l'espace contextuel d'un Acteur donné lui est inconnu. Le schéma à droite montre une version possible de ce cycle pour un Acteur sur une plateforme donnée.

La mise à jour de l'espace contextuel est un cycle. Un Acteur donné publie ses besoins, qui sont mis en correspondance avec ce que d'autres Acteurs publient puis filtrés, côté requérant ou côté producteur (j'aimerais qu'on en vienne à filtrer sur le noeud le plus à propos, mais c'est un projet à moyen terme) de manière à offrir au demandeur ce qui peut l'intéresser. L'espace contextuel se remplit donc, et peut être géré par le demandeur comme bon lui semble (c'est « son monde » après tout).

Certains comportements par défaut sont envisageables de facto. Par exemple, pour un même Contexte et à résolution égale, la version la plus récente provenant d'une source donnée devrait primer sur la version la moins récente et remplacer celle-ci (pour éviter la pollution de l'espace contextuel).

On peut déjà voir comment la mise en place d'équivalents pour un Contexte donné peut se faire : un Acteur passe près d'une source, obtient des équivalents possibles pour ce qui l'intéresse, puis utilise ces équivalents dans ses requêtes (un processus analogue se fait pour les fournisseurs mobiles de Contexte, d'ailleurs). Il y a beaucoup d'avantages à cette stratégie, en comparaison avec les alternatives :

elle ne dépend pas d'un noeud clé. Elle utilise les fournisseurs d'équivalences sur une base occasionnelle, mais fonctionne sans eux dans le cadre de ses opérations habituelles;
elle est ouverte à la multiplicité des descriptifs pour un Contexte donné, et est par conséquent ouverte pour extension. Si de nouveaux descriptifs apparaissent au fil du temps, ils seront intégrés à l'espace contextuel d'un Acteur si celui-ci est en mesure de le faire, et ne le seront pas dans le cas contraire – ce qui n'est pas un problème en soi, puisque l'Acteur en question n'aurait alors pas pu faire mieux; ainsi
elle est détachée d'un vocabulaire commun qui serait connu a priori. Outre les éléments qui seraient connus au préalable d'un Acteur lors de son démarrage (par choix, par design, ou dû à des mécanismes de persistance), l'espace contextuel d'un Acteur est strictement construit.

Les illustrations de cette section utilisaient la question d'un vocabulaire commun pour désigner un Contexte pour décrire les enjeux et les forces (selon moi) de la solution proposée, mais la problématique est plus subtile. Il est probable que, concrètement, les Acteurs doivent naviguer à travers les questions d'offre et de demande de Contexte sur une base probabiliste. Si deux Contextes synthétiques complexes sont comparés, il est possible (pour ne pas dire probable) que les deux conviennent en partie aux besoins d'un même demandeur, et que la question devienne alors lequel d'entre les fournisseurs est le plus près de ce que souhaite le demandeur. Tout de même, les arguments énoncés ici demeurent valides.

Réaliser la mise en commun de l'offre et de la demande

Je n'ai pas une implémentation prête ce la mise en commun de l'offre et de la demande de Contexte, et je suis conscient que le format du Contexte et l'implémentation des mécanismes qui s'y raccordent se développeront de manière concurrente. J'aimerais toutefois mettre en relief la faisabilité de la démarche, en prenant un exemple du monde des systèmes embarqués, soit la mécanique d'envoi et de réception de messages du langage Erlang.

Un bref sur le langage : il n'est pas fortement typé, et l'arité (le nombre de paramètres) d'une fonction fait partie de sa signature (donc f/1 est une fonction différente de f/4 puisque f/1 prend un paramètre alors que f/4 en prend quatre). Pour le reste, les mots débutant par une minuscule sont des atomes (des entités du langage sans valeur autre que leur propre existence), ceux commençant par une majuscule sont des variables, et les littéraux placés entre [ et ] sont des listes et ceux placés entre { et } sont des tuples (en français : des uplets). Ceci suffira pour le descriptif qui suit.

Examinez d'abord la fonction go/0 :

si elle sert de point d'entrée au module echo présenté à droite, elle lance immédiatement un autre processus (commande spawn/3). Ce nouveau processus exécutera la fonction loop/0 du module echo, en lui passant en paramètre une liste vide ([]) puisque loop/0 a une arité de 0;
la fonction spawn/3 retourne un identifiant de processus, déposé dans ce cas-ci dans la variable Pid2. Ces identifiants sont à la base du modèle de communication mis de l'avant par le langage;
une fois le nouveau processus (Pid2) lancé, go/0 lui envoie un message. La syntaxe générale pour ce faire est Pid ! {msg} où :
- Pid est le processus à qui l'on souhaite écrire;
- ! signifie envoi de message; et
- {msg} est le message, exprimé sous la forme d'un tuple. Ici, ce tuple comprend l'identifiant de processus de l'émetteur (donné par la fonction self/0) et un atome (hello).

Injecter son propre identifiant de processus dans un message est un classique puisque cela permet aisément au destinataire de savoir à qui répondre (notez que l'identifiant de processus est à la base même de la syntaxe d'envoi de messages).

Ensuite :

la fonction go/0 exécute l'instruction receive. Cette instruction est syntaxiquement simple mais conceptuellement sophistiquée. C'est elle qui nous intéresse particulièrement ici. En effet, elle permet de recevoir divers messages sur la base de leur structure, et de réagir d'une manière appropriée. Vous comprendrez sans doute les liens avec ce que je propose, même si la correspondance n'est pas pleine et entière;
ici, receive réagira sur réception d'un message constitué d'un tuple dont le premier élément aura la même valeur que Pid2 et dont le second élément sera une variable quelconque, nommé localement Msg, puis affichera le contenu de cette variable;
la fonction se termine par l'envoi de l'atome stop à Pid2, ce qui entraînera la mort de ce processus (voir loop/0, ci-dessous).

La fonction loop/0, quant à elle, tente de recevoir un message. Ce message peut prendre deux formes :

la forme d'un tuple à deux éléments, dont le premier doit être un identifiant de processus (ici, la variable From) et le second est un message (ici, la variable Msg). Das ce cas, deux opérations sont faites, soit l'envoi d'un message d'écho au processus émetteur, puis un appel récursif à loop/0 (pas de boucle, mais de la récursion terminale, en anglais Tail Recursion; Erlang, rappelons-le, est un langage fonctionnel); ou encore
la forme de l'atome stop, qui mène à l'arrêt de loop/0.

La fin propre de l'exécution d'une fonction en Erlang est l'évaluation de l'atome true, tout simplement.

-module(echo).
-export([go/0, loop/0]).
 
go() ->
	Pid2 = spawn(echo, loop, []),
	Pid2 ! {self(), hello},
	receive 
		{Pid2, Msg} ->
			io:format("P1 ~w~n",[Msg])
	end,
	Pid2 ! stop.

loop() ->
	receive
		{From, Msg} ->
			From ! {self(), Msg},
			loop();
		stop ->
			true
	end.

Examinez la structure du code de réception de messages. Elle est basée principalement sur la structure du message : dans le cas de loop/0, elle est strictement basée sur la structure du message, alors que dans le cas de go/0, elle est basée en partie sur la valeur du 1^er élément du tuple reçu, et en partie sur la structure du message. Erlang est un langage utilisé en grande partie dans les tél*éphones cellulaires et dans les systèmes embarqués; il est possible d'opérer sur le Contexte sur une base structurelle ou semi-sémantique.

Je suis conscient que nous allons plus loin ici que ce qui existe, mais je pense que c'est possible.

Espace intelligent ouvert

à venir...

Vision à la base proche de celle de [Weiser91], où l'informatique se fond dans le décor. L'espace intelligent ouvert est un espace englobant dans lequel la continuité de service prime, alors que les espaces intelligents contrôlés sont des espaces sont ceux où l'équipement disponible permet d'offrir une plus grande qualité de service. La réalité augmentée (ou réalité enrichie) émerge de la jonction entre le réel physique et le réel logique.

Les espaces contrôlés sont riches. Pourquoi passer à un espace ouvert? Pour englober les espaces contrôlés, tout en offrant une continuité de service, mais en étant conscients qu'il y aura une fluctuation dans la qualité de service.

Contraintes :

indépendance envers les noeuds clés;
autonomie sans nécessairement aller jusqu'à l'autarcie;

Acteur

Les raisons de mon choix de graphie, par lequel j'écris Acteur avec un « A » majuscule, sont exprimées ici.

Entité logicielle autonome.

Réside sur un noeud.

Opère sur du Contexte (consomme, traite, publie).

Spécialiste du domaine.

Références

[CARG] [ version électronique : http://cse.uom.ac.mu/node/119 ]

[Chen00] Chen, G. and Kotz, D., A Survey of Context-aware Mobile Computing Research, Dartmouth Computer Science Technical Report TR2000-381, [ version électronique : http://liris.cnrs.fr/frederique.laforest/master/biblioMaster/TR2000-381.pdf ]

[Dey99] Dey, K. A., et Abowd, Gregory D., Towards a Better Understanding of Context and Context-awareness, Lecture Notes In Computer Science; vol. 1707, Proceedings of the 1^st international symposium on Handheld and Ubiquitous Computing, pp. 304-307, 1999, ISBN : 3-540-66550-1 [ version électronique : ftp://ftp.cc.gatech.edu/pub/gvu/tr/1999/99-22.pdf ]

[Fujii08] Fujii, A., Trends and Issues in Research on Context Awareness Technologies for a Ubiquitous Network Society, Science & Technology Trends, Quarterly Review, issue 26, pp. 26-35, 2008 (publication originale japonaise en 2007), [ version électronique : http://www.nistep.go.jp/achiev/ftx/eng/stfc/stt026e/qr26pdf/STTqr2602.pdf ]

[Kephart03] Kephart, J. O et Chess, D. M., The vision of autonomic computing, Computer, vol. 36, pp. 41-50, Jan. 2003, [ version électronique : http://www.research.ibm.com/autonomic/research/papers/AC_Vision_Computer_Jan_2003.pdf ]

[Lieberman00] H. Lieberman, H. and Selker, T., Out of context: computer systems that adapt to, and learn from, context, IBM Systems Journal archive, vol. 39, issue 3-4, 2000, pp. 617-632

[Meyer88] Meyer, B., Object Oriented Software Construction, Prentice Hall, 1988, p. 23.

[Neovius06] Neovius, M., Sere, K., Yan, L. et Satpathy, M., A Formal Model of Context-awareness and Context-Dependency, Proceedings of the Fourth IEEE International Conference on Software Engineering and Formal Methods, pp. 177-185, 2006, ISBN : 0-7695-2678-0

[Roy10*] Roy, P., Abdulrazak, B. et Belala, Y., Context Awareness for Intelligent Space (presque complet; sera soumis pour fins de publication plus tard en 2010)

[Ryan97] Ryan, N., Pascoe, J., et Morse, D., Enhanced Reality Fieldwork: the Context-aware Archaeological Assistant. Gaffney,V., van Leusen, M., Exxon, S. (eds.) Computer Applications in Archaeology, 1997, [ version électronique : http://www.cs.kent.ac.uk/projects/mobicomp/Fieldwork/Papers/CAA97/ERFldwk.html ]

[TEA] [ version électronique : http://www.teco.edu/tea/tea_vis.html ]

[Weiser91] Weiser, M. The computer for the 21st century, Scientific American, pp. 94-104, 1991, [ version électronique : http://www.ubiq.com/hypertext/weiser/SciAmDraft3.html ].

[Winograd01] Winograd, T., Architectures for Context, Human-Computer Interaction, vol. 16, issue 2, 2001, pp. 401-419, ISSN : 0737-0024 [ version électronique : http://hci.stanford.edu/winograd/papers/context/context.pdf ]

Notes

[1] J'utilise Contexte avec un « C » majuscule pour dénoter le terme technique qui nous intéresse particulièrement, alors que j'utilise contexte avec un « c » minuscule pour le sens usuel de ce terme (comme dans les locutions mise en contexte ou dans le contexte de). Ce choix de graphie est de moi; la littérature utilise typiquement contexte (« c » minuscule), ce qui mène parfois à des phrases quelque peu ambiguës.

[2] Le Contexte inhérent, ou Contexte brut, est ce qui provient « presque directement » des capteurs. Par « presque directement », on entend ici « à travers de très petites transformations » (par exemple la transformation d'une donnée analogique dans un intervalle donné en une valeur exprimée en degrés Celsius). Le Contexte brut décrit, au sens où je l'entends, une donnée de l'espace physique ou de l'espace logique (espace disque disponible, durée de vie restante d'une pile).

[3] Le Contexte émergent, ou Contexte synthétique, est ce qui résulte de raisonnement sur du Contexte, que celui-ci soit brut ou déjà synthétique, peu importe la quantité de Contexte impliquée. La production d'une mesure synthétique de confort ambiant à partir de plusieurs Contextes décrivant des éléments clés de l'environnement est un exemple d'un tel Contexte.

[4] J'utilise Acteur (avec un « A » majuscule), mais j'aurais pu utiliser agent.. Quand j'ai commencé mes travaux, des indications m'ont été données à l'effet que le mot agent serait contesté dans le sens d'entité autonome agissant de son propre chef, pas nécessairement en mission pour un tiers. Le mot Acteur dans l'une de ses acceptions les plus courantes, a aussi ses racines dans un modèle de communication par messages, sans partage direct entre les participants (un modèle Share Nothing), alors ce n'est sans doute pas le meilleur terme non plus. Je cherche quelque chose de mieux...

[5] Un idiome de programmation est une bonne pratique pour certains langages de programmation; chaque langage est porteur de certains idiomes. Les schémas de conception sont des pratiques à portée plus large, applicables de manière générale à de vastes classes de langages (typiquement, l'ensemble des langages orientés objets). Une définition du Contexte qui reposerait sur des idiomes précis se limiterait à certains langages seulement.

[6] Oui, il faut penser en fonction du futur et prévoir à même le modèle des mécanismes qui permettront de gérer les versions des formats par lesquels s'exprimeront les données transigées par les services, de même que les services eux-mêmes. C'est un problème de fond, structurel, qu'il faut aborder d'office et ne pas remettre à plus tard.

Historique des révisions

Jeudi 22 juillet 2010 : ajout de la section De la philosophie à l'implémentation (Patrice Roy).

Mercredi 21 juillet 2010 : première publication (Patrice Roy).