De retour à l'école...

Plus récente modification : mardi, 8 juin 2008. Je prends parfois des pauses d'écriture et de lecture pour m'occuper de mes étudiant(e)s et de ma famille mais la réflexion se poursuit en arrière-plan...

Voir aussi la page sur la question du contexte, qui mérite un regard à part entière.

Contextualisation (Context-Awareness)

Mandat : produire ma compréhension du Context-Awareness : ce que c'est, qui y travaille dans le monde, ce que ces gens font, et comment ces gens travaillent.

Ce qui suit se rapporte à ma présentation du 28 février 2008 à l'université de Sherbrooke.

Termes-clés

Semantic Web, including (but not restricted to) the RDF and OWL standards. The Semantic Grid might also be interesting to a lesser extent.

Définitions

« The notion of context awareness for devices itself can be split up into three components: activity, environment and self. The activity describes the task the user is performing at the moment, or more generally what his or her behaviour is. This aspect of context is focused on the user of the device, and his or her habits. The environment describes what the status is of the physical and social surroundings of the user. The current location, the activities in the environment and other extern properties like for instance temperature or humidity belong to this axis. Finally, the self component contains the status of the device itself. This third point of view on context awareness has not been researched as much as the other two, but is a very interesting one in the scope of cognitive sciences. »

Cette vision focalise sur les périphériques et trahit un intérêt pour le matériel accompagnant les humains et participant à leur contextualisation, plus qu'un intérêt envers les humains eux-mêmes. L'effort de cette entreprise cible en fait surtouit la contextualisation des machines, donc une compréhension par les composants de leur environnement, plutôt qu'un environnement conscient des besoins de ses occupants.

« ... a system obtains information from numerous sensors arranged in the home, workplace, cities, and other spaces where people engage in everyday activities. This is used to determine the details of the user’s actions and the constantly-changing condition of the environment, that is, "context." ... »

Cette définition par énumération propose le contexte (sous-entendu : d'un humain) comme les conditions de son environnement et les actions qui y prennent place.

« 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 »

Ceci place le contexte sous une forme s'apparentant à des métadonnées sur des objets et des relations ou à propos d'objets ou de relations.

« 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 »

L'adaptation aux besoins et à la situation semble faire partie des caractéristiques maîtresses des systèmes contextualisants (ou contextualisés). Les idées d'actions provoquées par le contexte (Context-Triggerred Actions), de découverte dynamique de l'information disponible (Contextual Sensing, Proximate Selection), de découverte dynamique des ressources (Contextual Resource Discovery) permettent toutes d'envisager une augmentation contextuelle des possibilités humaines ou de commandes contextuelles. L'incapacité de tout traiter, tout le temps implique une forme d'étiquetage contextuel minimal, dans le but d'un traitement ultérieur.

Le groupe de recherche CARG lie le Ubiquitous Computing et la contextualisation dans ce que ce groupe qualifie de Calm Technology (http://cse.uom.ac.mu/node/124). On y explique que « The ability of computing devices to detect, sense, interpret and respond to aspects of a user’s local environment and the computing devices themselves is known as context-aware computing », donc que la contextualisation est ce qui permet aux périphériques mobiles et intégrés à l'environnement de comprendre la situation dans laquelle se trouve un humain de manière à agir (ou à réagir) de manière plus appropriée. Le groupe CARG met aussi en relief, avec raison, l'importance de petits capteurs peu coûteux dans l'avènement d'une contextualisation commerciale. Sans le dire ouvertement, ce groupe semble favoriser la réalisation de la contxtualisation par de petis composants en interaction plutôt que par des applications monolithiques, que son site qualifie de difficiles à adapter.

Il existe un sous-entendu discret dans le monde de la contextualisation selon lequel la technologie devrait, littéralement, se fondre dans le décor. Dans les situations où aucune ambiguïté ne transparaît, la technologie devrait pratiquement être proactive. Évidemment, cela soulève des questions importantes quant à la responsabilité des outils (et de celles ou ceux qui les conçoivent) s'il advient qu'une mauvaise décision est prise de manière proactive et que des conséquences néfastes s'ensuivent. La prudence est de mise.

Principaux laboratoires (il m'en manque)

Context-Awareness Research Group (CARG) : http://cse.uom.ac.mu/node/119 qui semble être un groupe de recherche axé sur la contextualisation et qui est situé dans la République de Maurice (aux Îles Maurice). Sécuirité en milieu médical, contextualisation en milieu hôtellier (une meilleure expérience de tourisme par un hôtel s'adaptant aux préférences des humains qui y logent).

Le Intelligent Room, au MIT, est un projet ambitieux (mais la page Web qui nous y accueille est truffée de fautes). Les buts (et défis techniques) y sont clairs : on y vise un système Pervasive (présent partout), mais avec accès à une banque de données puissante en tout temps (je comprends, sans que ce soit explicite sur le site, que le système repose sur une centralisation des données); Embedded (intégré aux objets de la vie courante); Nomadic (les humains sont mobiles... mais il faudra voir comment ce but concordera avec la philosophie reposant sur une source centrale de données); Adaptable (s'adapte aux changements dans l'environnement et dans les ressources disponibles); Powerful (malgré des ressources matérielles finies); Intentional (intuitif, capable de comprendre des termes généraux et relatifs, des intentions); et Eternal (les composants peuvent être remplacés, nais le système demeure actif sans interruption).

Le groupe Adaptive Systems & Interaction, chez Microsoft, étudie les systèmnes diffus entre plusieurs autres sujets touchant aux relations entre les humains et leur environnement, intégrant des composants informatiques.

Le Institute for Infocomm Research de Singapour est fréquemment cité sur les sujets gravitant autour de la contextualisation.

Le Gator Tech Smart House est intéressant, constituant une maison intelligente à part entière.

Autres laboratoires peut-être connexes

Le projet http://architecture.mit.edu/house_n/ a peut-être un lien avec la contextualisation mais semble surtout être un projet d'architecture.

Principaux acteurs (il m'en manque beaucoup!)

Au City University de Londres, le professeur Eduardo Alonso semble prolifique pour ce qui est des systèmes d'agents répartis.

Chez Microsoft, John Krumm et Eric Horvitz semblent être des maillons importants du groupe Adaptive Systems & Interaction. Horvitz semble avoir écrit beaucoup sur le raisonnement malgré des ressources limitées (le Continual Computing).

Thématiques connexes

Le Global Computing (http://cordis.europa.eu/ist/fet/gc.htm) implique certains groupes de contextualisation. Je n'avais pas fait le lien spontanément, mais c'est pourtant un partenariat raisonnable au sens où les problèmes se ressemblent : répartir des tâches de calcul sur un ensemble de noeuds interconnectés dans le but de faire plus que ce que chaque noeud pourrait offrir a priori sur une base individuelle. Cousin du Grid Computing.

Lectures récentes

Mes lectures récentes, en lien avec mon récent retour aux études, apparaissent ci-dessous. En anglais, pour faciliter la transférabilité dans des documents décrivant l'état de l'art.

An Ontology based Context aware modelling and reasoning to enhance Human environment Interaction (sic for the entire title)

Remarks

Distinction between Assistive Environment (AE), a DOMUS-like center, and Assistive Technology (AT), involving diffuse tools in pervasive space. An AE is a physical space where people needing AT gather. AT tends to be heterogeneous and to involve many user interfaces (always tricky with the elderly and computer-unfriendly people in general).

One target of the thesis and of the lab in which it has been developed and tested is to develop more homogeneous interfaces in a controlled environment.

The vision of context-awareness outside of a controlled AE proposed by this thesis is to bring along intelligence on a kind of PDA.

Every empowering technology acting on an environment involves potential conflict, between apparatus with different constraints or "intentions" as well as between different users' needs. What's good for one might be bad for another; a mediating process will always be required.

The presentation of Dey's taxonomy on p. 20 deals with presenting services to users, automatically executing services and tagging information context, but avoids (sadly) the issuer of conflict management.

The thesis suggests AE as an application domain for pervasive computing. The author mentions that a good design for an AE involves zero explicit user manipulation (p. 9). He also suggests building a Framework to facilitate building context-aware applications (the author's mastery of English is… ordinary, which precludes understanding precisely what is intended from the opening declarations. But it involves prototyping and interfacing with sensors).

There seems to be a strong link between semantic Web technology, notation included, and the thesis, but the reasons are not clear from the onset. Maybe this is due to difficulties with the English language.

The authors suggest (p. 24) moving most of the computation to service-oriented middleware. It's a classical centralized viewpoint of what distributed computing (or, at least, computing from distributed data) could (or should) be, but there's no clear demonstration that this would indeed be the best way to do things. It's a way that could do the job, but the author seems already convinced.

Some existing context-awareness-related projects are presented. One in particular, SOLAR (p. 26) avoid centralization on data and reasoning. Most are prominently location-awareness oriented.

On p. 33, the author suggests that infrastructures should be preferred to standalone computing units because of scarce resources on most mobile units. There are other options, of course, but the text does not discuss them.

On p. 34, the author stresses the importance of semantic Web standards to represent contextual data. I agree, if only for commercial acceptability and to ensure integration with existing automated reasoning tools. On p. 35, he adds that the context framework should be distributed and reasoning should occur at higher levels. I agree to a point : it's clear to me that the basic context-awareness building services (data acquisition among them) must be distributed. I'm not convinced about delegating reasoning to higher levels or centralizing it but I do agree that it must be possible to do so.

What the author envisions as service architecture might end up being similar to Nicolai M. Josuttis' Enterprise Service Bus (ESB).

On p. 37, the author mentions Context Toolkit's contextual history of individuals. A very interesting topic in its own right, but one which suggests security concerns. Maybe for some eventual back-end analysis process, comparing predicted behaviour or results and actual events, for decision process refining. To be considered if we envision an automatically refining system.

While we're at it, ATLAS-like systems, where humans ca reason about hermeneutic components gathered from raw data, could be used to merge (maybe even in an automated fashion) semantic data from different sources.

Chapter 3 begins by a discussion of semantic Web standards that make for a brief description of what can be found elsewhere on the subject. As mentioned previously, I agree with the use of RDF, OWL and other existing standards to represent context data and reason about it (at the very least, any context-aware system today should be able to import data of that form and export data to that format). Some interesting strategies to organize distributed semantic data and reason about it are presented.

Studying behaviour to predict future actions using « Markovian » tactics is something I had thought about too, if only in general terms. It seems reasonable. So does working from Fuzzy Sets. I went fast through that section to get the basic idea and might go back there should the need arise.

Chapter 4 discusses a Framework. These structures are always interesting to look at since they tell a lot about both the technical strategies involved and the aims (and philosophical leanings) of the Framework designers. In this case (the Context-Aware Explorer, or CAE, which is quite funny from the point of view of an ex-CAE Electronics Ltd software engineer like me), the author does not clarify up front whether we're examining a prototypal framework or a prototypal layered application that would guide the design of such a Framework; this ambiguous writing stance complicates analysis.

Reasoning is semantic Web-based (OWL inference on RDF descriptors). The result allows some form of data mining on dynamically built semantic data, which makes Context-Aware Explorer an appropriate name for the tool described there. CAE would be a nice prototype application but, should it turn into a Framework, I would want to know more about extensibility and the ability to plug my own objects in it. After an interesting discussion of CAE, the conclusion makes it clearer that it is indeed a Framework, akin to a context-aware database, upon which applications that want to infer semantic relations can be built. I find particularly interesting the integration of existing technologies in the overall package. The flexibility of the Framework for builders who would like to work within isn't clear, though (which does not mean the Framework is not flexible, just that the text's focus does not make that flexibility apparent) and the issue of reacting to input is absent from the presentation, presumably because it is deemed to belong in the application domain, not in the Framework's set of responsibilities.

Pages 109-112 present the interesting problem of ubiquitous system evaluation and testing. This tells me that a real Context-Aware Framework, like a real SOA, must include its own (pluggable, ideally) evaluation and testing mechanisms. Obtaining user feedback remains necessary (through other, more humane means, most probably) but ensuring prediction matches outcome (and to what degree of certainty) would be better served through organically integrated mechanisms, acting from within.

Not surprisingly, Plug and Play characteristics of remote devices play a role in their integration to test systems and are briefly described. I doubt we can discuss ubiquitous computing without entering automated detection and integration protocols like UPnP...

The comparison of distributed reasoning response time and centralized reasoning response time is too brief for my tastes. The same holds for the mention that response time is not sufficient without data related to the accuracy of the inference process, for which we sadly have no data.

I have applicability questions when I look at the entire thesis. The target applications for the Framework have not been clearly defined (there is no use-case to test against, for example) yet CAE is a context exploration Framework, not a universal Context-Awareness application Framework. It might be an issue of focus, or simply a lack of familiarity with the English language that led to this strange situation. Still, there are some very good ideas and directions in there, food for thought.

DEVELOPMENT OF APPLICATION SOFTWARE FOR A WIRELESS POSITION TRACKING SYSTEM

Problem domains : position tracking software, using Ekahau SDK and positioning system through RFID tags.

Like what happens with all such devices, their main problems have been device autonomy (battery life) and calibration to ensure physical objects/ logical representation correspondence. One of the things we might want in a mobile Framework, where location is more diverse (the user is not constrained by a single physical space or by a small set of such spaces) is either a good tolerance towards errors, probabilistic inference (to avoid thinking the object is there and prefer thinking the object is probably or usually there, so nothing really bad needs to happen if it is not) or physical location discovery (should the devices or the network allow it).

A SUBSCRIPTION BASED GENERIC MEDICAL EVENT MANAGEMENT SYSTEM FOR TELEMEDICINE APPLICATIONS

The article describes a telemedicine framework involving biomedical devices. These devices report subject status and device status. Uses SIP as part of the underlying protocol set, which suggests integration with VoIP technology and orchestration. A brief discussion pertaining to reaction to priority events is given

AN AGENT-BASED SELF RISK ASSESSMENT AND MONITORING SYSTEM FOR CARDIOVASCULAR DISEASE PATIENTS

Problem domains : Foundation for Intelligent Physical Agents (FIPA)-compliant software, intelligent monitoring agents.

The article discusses risk assessment and monitoring for a specific kind of physical ailment (coronary diseases or failures). If risk assessment could be made automatic, there might be some inspiration there.

A SMART VISION-BASED HUMAN FALL DETECTION SYSTEM FOR TELEHEALTH APPLICATIONS

The article discusses fall detection from image analysis. Their technique involves RFID for initial discovery of the human subject, but relies on a fixed 360° camera for image capture and real-time analysis, which limits its short term usefulness for mobile systems.

CONSIDERATION OF SECURITY IN TELEHEALTH WIRELESS SENSOR NETWORK MONITORING SYSTEMS

Authors : Jocelyn Adams, Tanya Roosta, J. Mikael Eklund, Ruzena Bajcsy and Shankar Sastry

The article provides a (very) short study of a specific, potential data corruption problem that could arise between wireless devices.

REAL-TIME COACHING USING ROBOT-BASED SEMI-TELEOPERATED CAMERAS

Authors : R. Lemieux, M. Martin, C. Bellemare, P. Masson, F. Michaud, M.-E. Bernard, P. Fauteux, C. Julien, M. Lalonde-Filion, C. Morier, A. Morin-Guimond, M.-A. Patry, A. Saint-Pierre (some from UdeS)

Discusses medical specialists training others remotely, but the ideas could be applied in other contexts (though probably not with dedicated such hardware if the trainee is moving freely in space).

REALISING MULTIPLAYERS (sic) SCENARIOS FOR REMOTE BIOMONITORING

Problem domains : biomonitoring, moving subjects, scenario-based development.

The article discusses making role-playing scenarios before building a biomonitoring system. In itself, the idea of adapting game metaphors to human activities, even medical assessment and subject follow-up, has many interesting implications. I particularly liked the idea that a patient, thinking he or she has been hurt, could take a digitize picture that would be analyzed remotely by a human (or automated) expert to infer whether one should take action. The scenarios don't play that much of a role in the article but represent a sufficiently interesting idea to be studied in their own right.

AN INFORMATION DELIVERY AND DISPLAY SYSTEM FOR DEAF PEOPLE IN TIMES OF DISASTER

Authors : Atsushi Ito, Hitomi Murakami, Yu Watanabe, Masahiro Fujii, Takao Yabe, Yoshikura Haraguchi, Yozo Tomoyasu, Yoshiaki Kakuda, Tomoyuki Ohta, Yuko Hiramatsu

Mobile ad-hoc Networks for ubiquitous computing through Bluetooth and cellular phone technologies, both for availability reasons (there are lots of cell phones around) and for technological advantages (Bluetooth range, among other things). The paper focuses on assisting deaf people remotely, but also describes what cell phones can do when used as MANET nodes : they are bidirectional, multimedia-enabled, can vibrate (useful reminder for the deaf, of course)... The paper also describes a clustering Hi AODV, a dynamic node clustering algorithm based on node movement and distance that builds dynamic routing tables along the way.

Trends and Issues in Research on Context Awareness Technologies for a Ubiquitous Network Society (AJOUTER AU DOCUMENT WORD)

Describes the nuances between mimamori (Look over and Protect) and Surveillance (observing a subject without said subject's awareness of it). Details a vision of what contest-awareness implies at the moment when the article was written.

SPECTER: a User-Centered View on Ubiquitous Computing (AJOUTER AU DOCUMENT WORD)

Discusses the important problem of capturing information from a user's environment (gathering data, making inferences, learning, avoiding privacy leaks). Lists several existing projects that try to gather information and make inferences from environmental data. This project gathers data from, among other things, credit card logs, which puts forward the importance of privacy. Among the interesting ideas here, we find a journal of past deeds and events, to allow retrospective inferences; clustering of information into scenes and scenarios, to produce metadata or coarse-grained information, and the idea of learning from the affects of the users upon system involvement (at what point does the user consider system involvement to be invasive and when is the same involvement considered acceptable).

Ubiquitous Computing Technology for Just-in-Time Motivation of Behavior Change (AJOUTER AU DOCUMENT WORD)

Discusses not only the detection of unhealthy behavior in a controlled, ubiquitous environment, but also the issue of motivating behavior change. Not an easy task : stimulating healhty behaviour without annoying the user to the point where she or he will react badly. Some approaches seem to work (stimulating people to use the stairs by displaying just-in-time messages).

Building Ambient Intelligence into a Ubiquitous Computing Management System (AJOUTER AU DOCUMENT WORD)

Discusses an ubiquitous system built like a nervous system, that performs continuous self-diagnosis and adaptation. The self-regulation and routing features of this system have the added benefit of providing an implicit form of both fault-tolerance and load-balancing. The article gives an interesting example where a sensor can compensate for a faulty device elsewhere in a controlled envioinment in order to compensate for said difficulty. This project aims to achieve some quality of service (QoS) guarantees.

Spontaneous and Context-aware Media Recommendation in Heterogeneous Spaces (AJOUTER AU DOCUMENT WORD)

Discusses the question of accessing the appropriate media content in an heterogeneous environment where data abounds. The term Spontaneous Access is used to describe the automated interaction between ubiquitous devices and heterogeneous data sources, as well as to indicate the selection of relevant material from the mass of available data. The article distinguishes between selection based on known user preferences, based on situation (time and location among other factors) and based on available resources. The article strves to define a minimal set of requirements for context-aware media acquisition or delivery. A system is suggested, but it is shown to be distributed in a two-tier fashion (for what these delineations are worth) in the sense that a Web browser in handhled devices plays the client's role and a centralized content aggregator plays the role of the server. Both UPnP and OSGi play a role in this article's offering.

An OSGi-Based Infrastructure for Context-Aware Multimedia Services (AJOUTER AU DOCUMENT WORD)

Authors : Zhiwen Yu, Xingshe Zhou, Zhiyong Yu, Daqing Zhang and Chung-Yau Chin

Describes an architecture named CMM, for Context-aware Multimedia Middleware. Key elements are an aggregator, a reasoner, a learner, a filter, a recommender and an adapter. Note that simplification through summarization is presented as being part of the adapter module, not the filter module. These modules interact and communicate. It's not clear whether they are expected to be networks in their own rights (my personal reading is that they are viewed as standalone applications trading data., but one could conceivably view them as networks).

Harnessing Location-Context for Content-based Services in Vehicular Systems (AJOUTER AU DOCUMENT WORD)

Authors : Vasudha Ramnath, Joo-Hwee Lim, Jean-Pierre Chevallet and Daqing Zhang

An Ontology-based Context Model in Monitoring and Handling Agitation Behaviour for Persons with Dementia (AJOUTER AU DOCUMENT WORD)

Authors : Victor Foo Siang Fook, Siew Choo Tay, Maniyeri Jayachandran, Jit Biswas and Daqing Zhang

Presents a Semantic Web-based Middleware to help monitor and assist people suffering from dementiae. The approach suggested by the article involves a solid loss of privacy on the part of the subject, warning friends, familiy and selected medical specialists of the subject's ongoing behavior under suspicious circumstances. The proposed system is distributed in a classical CS sense, with centralized data and reasoning nodes.

Supporting Context-Aware Mobile Service Adaptation with Scalable Context Discovery Platform (AJOUTER AU DOCUMENT WORD)

Discusses the impact of 3G mobile devices and the set of enriched services they enable. Defines a context provider as a source of context data (raw or inferred) and a context requester as a consumer of said data. The term context discovery is used for the process where a context requester tries to locate available and useful (for its purposes) context providers, and is described (rightly) as a fundamental process in a distributed, decentralized system.

The reality is that, for ubiquitous computing, we strive towards an arbitrarily large (but finite) set of context providers to choose from at any time. The article describes context advertisement as a way for a provider to signal its availability and nature (which does not solve the « problem set size problem », mind you) and context availability requests as a way for the context requester to filter out the noise from the signals, trying to reduce the problem set to a RT-Manageable size.

I use RT-Manageable here in the sense of a problem for which there is a solution in a worst-case guaranteed (Wall-Clock) time, suitable for real-time problem solving such as assisting humans through ubiquitous computing-related situations.

The article presents an architecture for context provider advertisement and discovery. Along the way, it posits that UPnP, among other protocols, might not scale well enough in wide-area discovery situations (which might not preclude its use in a local-area situations). The remainder of the description gravitates around the Orion framework, which the article sets out to describe; while interesting in its own right, it's mostly a framework made from layers, a conventional approach to software systems.

OSGi Based Service Infrastructure for Context Aware Automotive Telematics (AJOUTER AU DOCUMENT WORD)

Describes, as the name implies, an infrastructure (targeted towards assisted vehicle driving) based on OSGi. Quoted from the article :

« The Open Service Gateway Initiative (OSGi) was established in 1999 to define open specifications for the delivery and provisioning of multuple services over wide area network to local networks and devices in homes, cars and other environments. The OSGi specifications try to standardise the way for secure and reliable service delivety and provisioning, for remote life cycle mangement of services, for reusing the services as well as for bridging between different networking standards. »

As is often the case in Context Awareness-oriented systems, the context is modeled through ontologies, which suggests using semantic Web standards and technology at some point. The article posits context interpreters as a conceptual (and probably technical, in most cases) layer between context providers and context requesters; the role of a context interpreter is to infer information from base data.

The article also introduces context managers as a repository of organized context from which structured queries can be built. A context manager is akin to an active database (the article describes it as a potential source of events based on a classical publish/ subscribe—observer—pattern), but represents a centralized node in the model.

Then, context-aware services enter the picture and behave like small expert systems that would rely on context obtained from a context manager.

Context-Aware Content Filtering & Presentation for Pervasive & Mobile Information Systems (AJOUTER AU DOCUMENT WORD)

Problem domains : Ubiquitous Computing, Context-Awareness, implicit and explicit decision making, context evolution

These slides posit relevancy as being dependent on context. On of the main objectives (supporting a large array of data types) is suspicious from a distributed point of view, where data being moved around is kept to a minimal set of simple data types in order to enhance interoperability; still, the encapsulation of context in widgets based on granularity and quantity might avoid a multiplication of data types.

The stated aim of using a presentation format independent of types is interesting in its own right, even outside of the realm on Context Awareness. The approach suggested here, once again, relies on a centralized data source. A small note on one of the slides towards the middle : use weights, explicit > implicit, is worthy of note, in the sense that assisting the user often involves making autonomous decisions from a (potentially large, yet hopefully not too large) set of candidates. When explicit orders are given, they should in general (this is a maxim, not a rule—if the subject might get hurt or if he/ she might hurt others, there might be implicit provisions that are considered more important than explicit orders from said subject) be given more consideration than implicit rules-based decisions are. The weighing process must evolve with time. We could say that context is an evolving, stateful entity, an objet more than a process. One of the slides adds that context is latent and can be inferred, not necessarily defined by explicit human decisions

The example of relevancy given in the slides presents data from a set of sources in a way that adapts itself to the presentation context. It is an interesting example in the sense that, if it is being made from a flexible description of context and application domain, it is both visual, simple and general.

Towards an extensible context ontology for Ambient Intelligence (AJOUTER AU DOCUMENT WORD)

Authors : Davy Preuveneers, Jan Van den Bergh, Dennis Wagelaar, Andy Georges, Peter Rigole, Tim Clerckx, Yolande Berbers, Karin Coninx, Viviane Jonckers, and Koen De Bosschere

Problem domains : Ubiquitous Computing, Context-Awareness, Ambient Intelligence, Ontology

Like 01543869.pdf, this article posits enhanced resources and computing power in widespread mobile devices, leading to real AmI environments. The key elements of AmI are said to be :

The article distinguishes preferences (changing over time and with context) and profile (information that tends to be static, like gender or date of birth). It also defiens tasks as high-level user operations and activities as pieces of a task. Since ubiquitous systems in general strive towards mobility, systems must be able to handle changing conditions with respect to factors like time, location and some environmental factors like temperature and luminosity. The level of accuracy required depends on what is being measured or acted upon (it tends not to be systemic).

Middleware for Distributed Context-Aware Systems (AJOUTER AU DOCUMENT WORD)

Authors : Karen Henricksen, Jadwiga Indulska, Ted McFadden and Sasitharan Balasubramaniam

The article provides an analysis of existing middleware for ubiquitous systems and tries to describe what would be required in order to build a middleware better suited than those that have been built so far for such systems. As with 01543869.pdf and eusai04.pdf, this article posits enhanced resources and computing power in widespread mobile devices.

The de facto standard context-aware framework is described as a five layer system, involving from bottom to top :

The middleware part of this layered description is said to be everything sandwiched between the topmost layer and the bottom layer. It is subjected to both the requirements for traditional middleware (scalability, fault tolerance, deployment facilities, heterogeneity support, etc.) and those for ubiquitous systems (privacy, recording of user preferences, implicit and autonomous action, etc.).

A Distributed Ontology Framework in the Semantic Grid Environment (AJOUTER AU DOCUMENT WORD)

Problem domains : Ubiquitous Computing, Context-Awareness, Ontology, Semantic Grid

The article presents Web services as a way for nodes in the Semantic Grid (a conceptual merger of the Semantic Web and Grid Computing systems, where services trade semantic data) to interact. Ontologies tend to be huge, and the Ontology Tailoring Program Resource, or OTPR, is presented as a resource on the Semantic Grid that can take an ontology and a set of tailoring algorithms to adapt said ontology to the needs of another process. Most of the article is devoted to describing efficient ways of using OTPR.

Some documents read but not retained from IASTED2007

They have not been retained (although I have read them) for one of the following reasons :

Mobile Agents: Can They Assist with Context Awareness ? (01263080.pdf)

The article posits that mobile agent will be useful and important in developing a pervasive intelligent space (note that the author talks about computing systems, not intelligent spaces). Mobile agents in interaction are presented as similar to humans interacting to solve problems, and are said to be an « efficient solution to complexity challenge[s] ». From the article : « A pervasive system needs to be context aware. It must handle different situations in different ways. Context-awareness implies intelligence that enables an application to discover, reason and predict a situation and adapt to it in a dynamically changing environment. In order to produce real awareness in pervasive systems, intelligent embedded programs must become mobile and retrieve context related information in different locations. In other words, by moving to different locations and retrieving relevant information, the program’s informed decision becomes better » (my emphasis). The word autonomic is used to identify agents that are both mobile and intelligent. Then, the author presents challenges for such systems.

Integration of Ad hoc Network and IP Network Capabilities for Mobile Hosts (01191288.pdf)

This article discusses Internet connectivity in mobile hosts. A difference is made between reactive routing (find routes in the ad hoc network only when packets must be sent) and proactive routing (agressively and continuously trying to find routes that would let packets reach the Internet), with the indication that reactive routing seems to work better with ad hoc networking. A gateway between ad hoc and wired networks is proposed. A distinction is made between single and multi hop access. Establishing a special sub-network with its own IP numbering for the ad hoc hosts is suggested in order to reduce the amount of routing information sent between such resource-limited hosts. Likewise, Non-Broadcast Multiple Access (NBMA) strategies are preferred to broadcasting because of the difficulty of sending packets to all neighboring nodes in one hoop. Foreign agents are used. to facilitate the registration of mobile hosts. A discussion of the intergration of Ad Hoc On-demand Distance Vector (AODV) and IP follows, and the problem of routing in mobile space is addressed. Without optimal routes available, delay-based strategies are used. An interesting twist is that the algorithm presented to pick ad hoc routes favors known foreign agents that are still available over the best foreign agents (according to dynamic route optimization computations) if possible and as long as some quality thresholds are respected, in order to avoid changing the routing tables all the time.

A Simulation Model of Adaptive Protocols in Distributed Computing Systems with Mobile Hosts (00393577.pdf)

The article discusses the possibility of Adaptive Queuing Protocols for Mobile Computing based on simulation results and inspired by existing Distributed Database protocols. The simulation takes into account resource management problems that naturally follow along the use of mobile devices, and also discusses the differences between mobile computing and fixed location, wired computing in terms of goals and constraints. Among the goals for a useful mobile computing protocol, we find correctness (a strict a priori), low power consumption and low operating costs (because sending packets over a cellular network costs much more than doing so over a LAN). Among other characteristincs of the Adaptive Queuing protocol presented, we find the frequent clustering of related-priority packets in one big chunk in order to reduce operating costs. One simulation is based on UNIX multitasking and relies on a shared Virtual Clock (Note : should a mobile protocol do so? I doubt it), without success in the eyes of the authors; a « cooperative multitasking » approach is then preferred (alhouthg the authors state their preference for a Real-Time Operating System should one be available).

Towards a Mobile Enterprise Framework (00843299.pdf)

Awareness and Agility for Autonomic Distributed Systems: Platform- Independent Publish-Subscribe Event-Based Communication for Mobile Agents (01232098.pdf)

Problem domains : Publish/ Subscribe, Observer, Events, Mobile Computing, Agents, Reliability

I've played with this idea in the past, of course, in distributed systems courses. The problem is one of boundless resource consumption : if quality of service must be enforced by the publisher and no event can be lost, then the potential of each subscriber to disappear from and reappear into the network implies an information caching on the publisher's side. Any proxy that must account for its stub's potential, temporary unavailability faces this situation. There is no way to both enforce quality of service and reasonable resource consumption; something must give.

The article discusses publish/ subscribe (the Observer pattern) in a mobile environment, including the decoupling of name and location resulting from the registration the subscriber (decoupling location is particularly nice in mobile computing). Their framework (Elvin) is built to enable subscribers to modify the way they are notified depending on the availability of resources and the quality of the networking environment. Some problems arise : a mobile agent sometimes « disappears from the radar », losing event notifications along the way; the technology chosen (Elvin) uses non serialisable client representations, which means that it is not natural to move these representations around when mobile clients move physically; and even though information sent to an Elvin server is sent to all subscribers without the original emitter habiong to know their location, the fact remains that the Elvin server itself must know the location of all its clients, so when they move around, Elvin will send packets to the wrogn locations. The authors address these issues with a MobileConsumer serializable class that has an ephemeral existence (it comes into begin to unregister from the prior location and dies after establisghing the connection to the new location). They use server-side proxies for the disconnected-from-the-nework period. Two centralized and one decentralized strategies are presented to avoid lost messages.

Mission Impossible? Automatically Assembling Agents from High-Level Task Descriptions (01241063.pdf)

The article addresses the question of constructing an agent, with a mission, from a high-level description and task decomposition. Automatically assembling agents at run-time is a desired capability. One basic claim of the article is that agents consume resources, so they should be created as needed. Having a subset of complex, « hard-wired » (my words) agents on mobile devices does not cut it for the range of problems that might arise in distributed, mobile systems. A key idea is the Mission, « [...] defined as a purpose or goal an agent has to accomplish to satisfy its owner's request ». Missions formalize user requests, and can be represented as an organized set of tasks—completing the whole set of tasks implies reaching mission completion. A mission is dynamic in the sense that its set of tasks can change with time, due to internal events (individual task completion results in removing the completed node from the graph) or to external intervention. Missions are representend as Directed Acyclic Graphs with a single root node (the mission itself) and compound (intermediate) tasks as well as primitive (leaf nodes) tasks, so missions are in fact compound tasks.

Run-Time Mission Evolution in Mobile Multiagent Systems (01342927.pdf)

This article refines the Mission concept to define it as a stateful, dynamic construct that can be updated, suspended and resumed. On-demand agent construction from smaller tasks in order to succeed in a mission is presented as a cost-effective strategy since agents are cumbersome to build and deploy. Formal definitions for Mission, Task, Task Decomposition, Relationships between tasks, Mission Planning and Mission Completion are given. Adjustments are made to allow mission modification should the completion of a task prove difficult to achieve. The Mission Data Space is presented in termes of cost and security. Missions are constructed by a Mission Planner module that relies on an Agent Generator service.

On Development and Evaluation of Prototype Mobile Decision Support for Hospital Triage (01385554.pdf)

Authors : San Pedro, J., Burstein, F., Wassertheil, J., Arora, N., Churilov, L. and Zaslavsky, A.

The article discusses a PDA-based decision assistant, but without giving enough cues as to what is precisely PDA-relevant for it to be relevant to my work.

Loosely Coupling (sic.) Ontological Reasoning with an Efficient Middleware for Context-awareness (01540998.pdf)

Problem domains : Context-Awareness, Ubiquitous Computing, Middleware, Ontological Reasoning

The article discusses the design of ontological data to facilitate conmtex-awareness through availability, interoperability, context dynamics (local decisions as to how context affects decision making), efficiency (the user is not aware of the processing) and reasoning with socio-cultural context (something richer than name/ value pairs). The term Shallow Data is used for raw context seized from sensors, and the article posits that non-shallow data can often be computed in advance. the article uses «use [...] the term profile to indicate a subset of context information collected and managed by a certain entity », and « [...] divide[s] profile data in two classes: shallow profile data and ontology-based profile data ». The schema they use (p. 3) relies on centralized computing nodes. In fact, in this architecture, ontological reasoning is kept away from mobile devices (p. 4) due to a lack of resources.

A Distributed Middleware Solution for Context Awareness in Ubiquitous Systems (01541123.pdf)

Authors : Saad Liaquat Kiani, Maria Riaz, Yonil Zhung, Sungyoung Lee, Young-Koo Lee

The article discusses issues related to middleware deployment in contex-aware, distributed environments. Some constraints are interesting : sensors tend to have limited range, which makes a case for a number of raw context aggregators. Context synthesis tends to be computing intensive, which makes a case for a network of powerful computers close by. «Thinking distributed» from the beginning looks like a wise choice. The authors claim their service is « [...] independent of the discovery, registration and coordination scheme » and say they have found Jini to be closer to their needs that UPnP is.

Improving Operational Efficiency of Web Services with Mobile Agent Technology (01565631.pdf)

Authors : I Made (Dennis) Pratistha, Arkady Zaslavsky, Simon Cuce and Martin Dick

The article describes Fluid, a Web Services infrastructure suited for mobile computing. « Fluid monitors the runtime distributed web services environment. When certain problems arise within the environment, Fluid autonomously reacts by evaluating each hosted WS Fluid application. This evaluation may result in the following three decisions: (1) Resume existing operations (RE) – event does not affect application; (2) Reconfigure application (RA) – event is likely to have negative impact, though not critically; and (3) Relocate application (RLA) – event is likely to have critical impact ». The Relocate Application part is intersting as it fits in with my views on computation sharing features in Open Intelligent Space and takes into account potential host discovery, dynamic configuration according to available resources on a given host, management of singular resources (such as local databses), and deactivation/ reactivation for individual applications. For efficiency reasons, the authors sugest using a Coordinator Host that keeps copies of necessary components to allow application survival even when selected hosts disappear. Connected p2p relations are said to be risky among unreliable, mobile hosts; Mobile Agents aare said to facilitate asynchronous responsibility transfer. I will need to investigate more what the authors mean (it's not clear from the article). WS Fluid applications invove at least one WS interface, a set of Supporting Components (those things the application cannot do without), Components Details (metadata for Supporting Components), as Strategy Components that dictate how the WS Fluid application should behave under certain circumstances. Each WS Fluid application involves three main control components : a reactivity component that makes decisions, an adaptability component that dictates Web service reconfiguration, and a transportability component that packages the essentials of connectivy needs into Mobile Agents. For persistent data, and to provide a known, stable area, a Central Registry also exists. Most of the remainder of the article discusses a relocation example for an existing Web service (the well known Stock Quote service). Small question left : what plays the role of a Web Server on mible devices? I'm sure there's some lightweight solution, but this is a world I don't know that much about.

Merging Context Perspectives: An Approach to Adaptive Agent Reasoning in Pervasive Computing Systems (01599059.pdf)

This article puts forward the fact that centralized reasoning does not cut it in some environments, and that autonomous, distribued reasoning sometimes is the way to go. It discuesses the issues of incomplete knowledge, confilicting knowledge, distinct reasoning models, merging context perspectives and such. An approch named Context Spaces is proposed to represent knowledge as geometrical entitites in multi-dimensional space. Dimensions are given by context attributes. There is also Situation Spaces and Acceptable Regions, both used to define a form of algebra over acceptable context mergers. Raw Data is named Context State. Confidence in a given situation space is obtained by a reasoning function that weighs context attributes and context sources. An arithmetic defining context mergers and partitions is provided.

Context Awareness in Future Life Scenarios: Impact on Service Provisioning Platforms (01619998.pdf)

This article suggests putting in mobile devices a permanent, situation-aware filtering process that would favor services suitable for the user's actual physical location. It distinguishes context (local data : local temperature, local weather, user movement speed and so on) and situation (actual location), albeit in a strange english that leaves one wondering...

ConEx: Context Exchange in MANETs for Real time multimedia (01628316.pdf)

This article describes Mobile Ad Hoc Networks and their inherently unstable and ureliable structure, and then presents a real-time multimedia exchange framework for such environments. The authors suggest a vertical relaying publish/ subscribe system where adaptivity can be provided at different layers to facilitate real-time throughput.

A Formal Model of Context-Awareness and Context-Dependency (01698735.pdf)

The article defines Context-Dependency as the property of a system in which parts depend on a context provider to supply the metrics for fulfilling its declared service—a system where some services can only be offered and executed properly if context is made available. The authors' formalism follows Djikstra's Guarded Commands formalism. Guards are taken as available content notices and the dependence on guards becomes context-dependency. This allows a definition of a context-aware system as a data propagation network (a graph, not a tree) of context-dependencies. Both context-awareness and context-dependency are said to be required. The interactions between context providers and context-utilizers is said to bring about context-aware and context-dependent systems. All nodes of a systems are presumed to be potential context-providers and context-utilizers, which influences overall design considerations.

On the definition and relevance of context-awareness in Personal Networks (04141780.pdf)

This article describes context-awareness in the context of Personal Neworks, where users are connected to their devices anywhere, anytime. The opening (idealized) example is very enticing. We can infer that Personal Networks (or Personalized Networks) are made of interacting, User-Centered agents that strive to help the user to feel more confortable about himself through context-awareness. In that sense, Personal(ized) Networks can be seen as an application of Context-Awareness.

Sensor Data Collection Using Heterogeneous Mobile Devices (04283908.pdf)

This article suggests using mobile devices to carry data obtained from various disseminated sensors. Mobile phones and PDA devices are said to have spare capacity for communicating and processing, which makes them interesting data acquisition, transportation and transmission devices. Taking data from an acquisition location (some place where the actual sensors are) to a destination point, hopping around on a MANET, is presented as a cost-effective alternative to wired solutions. A Bluetooth implementation is presented.

Evaluating Cross-layer Context Exchange in Mobile Ad-hoc Networks with Colored Petri Nets (04283911.pdf)

Problem domains : MANET, Real-Time, Publish/ Subscribe, Context-Awareness, Petri Nets

This article is a companion to ConEx: Context Exchange in MANETs for Real time multimedia (01628316.pdf), mentioned above, and discusses Colored Petri Nets (Wiki) as a strategy to simulate and validate the vertical relays described therein. This might be an interesting avenue to validate the behavior of emergent processing networks in Open Intelligent Space.

Port-based Multihomed Mobile IPv6: Load-balancing in Mobile Ad hoc Networks (04367852.pdf)

This article suggests an approach to achieve a form of load-balancing when a mobile device can connect to the Internet through multiple gateways. From the article : « Ad hoc networks are seen as a "none broadcast multiple access technology" which requires new functionalities at the network layer to allow IGW advertisements to reach all MNs in the MANET ». Simulation results are presented to support the authors' claims.

CONTEXT-DRIVEN PROGRAMMING MODEL FOR PERVASIVE SPACES (jansen_dissertation.pdf)

Problem domains : software development for pervasive space, middleware, self-describing devices

Remarks

Close to my preoccupations: offering a programming model that would be useful pour developers targeting pervasive spaces.

Explicit relationships between sensors/ actuators/ s/w + goal-oriented programming.

Reasoning on the effect of service invocation, detection of services targeting same goals (similar to type checking), avoiding undesirable contexts.

§1)

Smart space is said to be ambient, bounded (analog to what I call Controlled intelligent space).

Sensors give precise values, but s/w is easier to write from high-level state description

§1.1)

§1.2)

Middleware must be open (to other technologies), extensible (adding components as needed), adaptive (to environmental changes), self-integrative (zero-config for joining processes)

§1.3)

§1.4)

The author categorizes pervasive spaces wrt the way it changes state and the safety levels involved

§1.5)

§1.6)

§2) and §2.1)

§2.1.1)

Describes context-awareness-related utilities and a composer programming metaphor

§2.1.2)

§2.2)

Briefly describes the Semantic Web. (§2.2.1) Briefly describes RDF (three-part subject/ object/ predicate statements), including the inherent limitations due to its lack of constraints. Said to be useful (a good start) but not sufficient. (§2.2.2) Describing domain knowledge using description logics (Tarski-style) madde of concepts, roles and individuals (another kind of three-part statement). Concepts are predicates that define sets of individuals. Roles are binary relationships between individuals. The idea is to reason about semantic information. (§2.2.3) States that OWL (at least OWL DL) is a description logic and that OWL Full is too rich to be RT-manageable (my reading).

§2.3)

Describes temporal logic, where truth of statements varies with time. Variants are (§2.3.1) Interval Temporal Logic (allows sequential and parellel reasoning), (§2.3.2) Linear Temporal Logic (extension to propositional logic using operators; deals with one future path, and can be translated to a DFA, although it is a NP-Complete algorithm) and (§2.3.3) Computational Tree Logic (extends LTL with branches to deal with multiple pathways in time).

§3)

Describes the problem of integrating new h/w and s/w components in an existing pervasive space (detecting the component, discovering its capabilities, integrating it properly, and testing the system).

§3.1)

Integrating components in pervasive space does not scale (requires re-testing everything, every time).

§3.2)

Pervasive spaces tend to be closed for extensions and updates (it is difficult to integrate new technologies in existing spaces).

§3.3)

Pervasive spaces tend to be built for the technology available at a given point in time, and are very costly to modify (in practice, a pervasive space cannot be replaced the way we would replace a single obsolete appliance). Most pervasive spaces will outlast the components therein.

§3.4)

The author offers a prototype IDE / Middleware to assist in building pervasive space s/w and integrating h/w to pervasive spaces. (Would the idea be suitable for an Open Intelligent Space? Not convinced...). This would (§3.4.1) facilitate the task of a programmer wishing to deal with the pervasive space using high-level descriptions, (§3.4.2) facilitate integration and removal of components, and (§3.4.3) simplify conflict management and exception handling.

§3.5)

States that just naming a component is not sufficient to help manage (integrate, configure, remove) it in pervasive space. The author claims that enriching component description with context data will make the component's role explicit and unambiguous (I'm sure it will help and might make simple sensors and actuators unambiguous, but I'm not convinced by the unambiguousness claim in general). The author is convinced that describing more clearly what each device does and depends is the key for pervasive spaces that are more likely to survive the passage of time.

§3.5.1)

Knowledge Engineering is said to describe relations between context and actuators (thus, behavior), and how context is derived from sensors. Involves taxonomy, validity rules, risk detection and management.

§3.5.2)

S/w Engineering is said to describe relationships between agents and context, between agents and actuators, and among agents. Agents do not affect directly the world, but actuators do. The application coordinates (!) agents and performs conflict management (We have a silent Orchestrator here). The author then describes his programming model for knowledge (conceptually describing space -- a problem for Open Intelligent Space; describing users' needs and wants; defining handlers for problem cases -- isn't there a real risk of state explosion here?; and defining relations between sensors and actuators -- I have a feelign this should be presented as going through a list of agents, potentially empty, to avoid making a special case). Then, behavior must be defined and associated with context (more classical s/w development).

§3.6)

The author lists the advantages of his approach: explicit relations, better interoprability/ extensibility, easier conflict management, what the author calls Capturing Environmental Effect (better reactive management due to better relationship data in the first place), better chances of machine learning (not clear, but the author does not say much either) and better scalability.

§4)

Describes what sensors are (including h/w and s/w components) and suggests that a URL would be a nice way to access such a device.

§4.1)

Shows that sensors can be viewed as context-producing functions (Q: functor? Are there stateful sensors?). The author defines a notation for a snapshot of all sensors in time; this presumes a global time and a correct global view, which does not hold for me but is a fair approximation in controlled spaces.

§4.2)

Ontologies let developers work at a higher level and avoid dealing directly with sensors. A general interpretation function follows that works on context made of semantic data. Interpretations are not unique (good thing!). There is stuff here for my own context arithmetic. The possibility of conflicting interpretations is shown, although it is more critical if one is trying to use context to model the world as it is than if one is trying to let agents reason as they can on context known to be (at least potentially) out of date.

§4.3)

Temporal context deals with the evolution of the interpretation functions. ADLs involve a time component. (§4.3.1) describes the addition of a temporal component to the taxonomy model of (§4.2). A «before» relationship is proposed. (§4.3.2) deals with time and ontology: context descriptions (rules of sorts) stay the same (the author's example is that COLD remains COLD) but set membership changes (what belongs to the COLD set changes with time). (§4.3.3) describes events using temporal context. A refinement of the «before» relationship is given since it is easier to reason about past events than it is to reason about future events (something that differs from what we do when we usually program). (§4.3.4) warns us that reasoning over this sort of data is known to be P-Space complete (and ExpTime) but that it remains manageable over «reasonable» sets of data (I have no idea what «reasonable» means here). If we move this as is to Open Intelligent Space, we have a problem.

§5)

Actuators affect the world and their effect can be viewed as intentional (thus, they can be ascribed intentions). This can be used to perform a priori validity reasoning for conflicting behaviors (the author mentions heating and A/C being turned on at the same time as such «confused intentions» -- my words) and shows a formal way of doing so (at least for limited cases).

§6)

With sensors and actuators, the missing piece is the user (the author takes a UCCA approach if one takes my vocabulary, but this works well in a controlled space). The author suggests a belief (as given by the interpretation function, although the author also talks about belief stemming from the user, so this lacks clarity)/ desire (preferences about the state of the world)/ intention (actuators acting to ensure the desire is met) model (we could do that even in Open Space, I think). The way the author describes his take one s/w that would deal with such a model, I think he has a relatively classical state machine in mind.

§6.1)

The user is described as a triple {taxonomy, interpretation, mapping from context to statements}, and actions (made by actuators) and statements are analoguous (sp?). Programmable Pervasive Space is a tuple { user, sensors-observed state, currently processing statements, currently active actuators }. The author applies his temporal logic to show how the activation/ passivation of actuators should be formalized.

§6.2)

§6.3)

The author aims to make an example of how his formalism would allow smart space programming, using a lighting control case (reduce lighting levels when the TV is on, for example). He first identifies relevant states, described in terms of available sensor values (this is raw context), and adds synthetic (derived, in his vocabulary) context. Interpretation functions are written to help identify these states. Behavior (binary, for simplicity) is associated with the results of interpretations and change the actuators' states. Interestingly enough, the issue of sensors used and configured to produce raw context come after all this. An OO state machine is generated.

§7) and §7.1 to §7.4)

The author describes the context-driven programming model he has in mind. The programmer builds a semantic web of interesting states (some atomic states, or raw context in my vocabulary, and some derived states, or synthetic context). The resulting graph (a context graph) is portable and disconnected from actual, physical pervasive spaces (cool!), opening the door for context graph templates that could be adapted to various settings. Sensor nodes would have properties (type of signal and value range, for example) which could allow programming through the graph independently of physical devices. Qualifying synthetic context (cold-hot range from raw sensor values) dissociates programming from h/w and opens the door for reasoning of high-level ideas. Transitions from group of states to group of states are associated with behavior.

§7.5 to §7.6)

The author describes the suggested IDE, based on OSGi for service discovery but made of plug-ins to an existing editor (Protégé, and eventually Eclipse) for performance reasons (Java-made IDE are a slowwwwww pain). These sections detail the resulting tool.

Context-Awareness in MobiLife (5.c_MOBILIFE.pdf)

Authors : R.Kernchen, David Bonnefoy, A. Battestini, B. Mrohs, M. Wagner, and M. Klemettinen

Problem domains : Context-Awareness, Distributed systems, Open Intelligent Space, Framework, Mobile

This article presents MOBILIFE, an actual Context-Aware project (a Framework that supports different applications—the article presents two such applications) that claims to use distributed, mobile components and claims to convey semantic data along with context. Extending the Framework with new context providers is done by using a generic representation of these providers. The Framework considers individual context (data pertaining to a person, but on a historical perspective) and group awareness (interesting but not clear from the presentation: are we trying to optimize or localize service delivery when individiuals with common needs share an immediate vincinity?). Their Context Management Framework builds and transfers high-level data made of sets of raw context through a pipe-and-filter metaphor. An interesting analogy is made between trying to store all context data on a given topic and trying to cache the whole Internet: it's senseless. Scalability, privacy and heterogeneity are fundamental issues, as are the limited validity in time and potential incompleteness or invalidity of context data. The main elements of their Framework are context providers, context consumers, context sources (raw sensors, say; considered a context provider only when wrapped in the proper classes or interfaces), context brokers (registration and lookup components that relay context from providers to consumers), a context representation framework (descriptive rules for context and services), context ontology (a standard service, where ontology can be distributed) and context interpretation (extraction, selection, classification, etc.). Context providers can extract and aggregate data from context sources as well as from other context providers. Reasoning on context is rule-based. Typical context providers can provide location context, (physical/ geographical) environment context, (individual/ group) preference context, wellness (health) context and presence (things like mood) context. From the article, it seems like records are somewhat perordained, which begs the question of extensibility; that being said, dealing with statically known record structures is a pragmatic short-term approach that lends faster returns than general, XML data.

FIGHTING THE VARIATIONS - Context Awareness, User Modeling and Adaptation in Dialogue Systems (fighting-the-variations-context.pdf)

Problem domains : Context-Awareness, User Modeling (akin to User Profile), Adaptation, Survey Paper

This article is a relatively short (15 pages) survey paper on adaptation to external conditions, a close parent of Context-Awareness, with respect to vocal dialogue systems. The general format used is: defining what is meant by Adaptation, explaining why it is done, citing sources along the way, and describing the topic based on the existing literature and focusing on dialogue systems (systems that discuss with humans using natural language and spoken phrases). Same thing is then done for User Modeling (something very close to User Profile) and for Context-Awareness (the idea being to use context data to enrich the possibilities of dialogue systems).

Open Issues in Nomadic Pervasive Computing (UbiSys2006-heni.pdf)

Problem domains : Context-Awareness, Open Intelligent Space, Nomadic Pervasive Computing

This article aims to present (the) open issues in nomadic pervasive computing, a concept akin to what I call Open Intelligent Space. At the forefront, the authors insist on the importance of delivering emergency services at all times (I do not know if this is possible in practice, though it is a valid [asymptotic] goal) and ensuring (reasonable) quality of service for the others. The authors name islands of smart spaces what I name Stable Areas. The nomadic pervasive computing envisioned by the authors is tied to users moving between such islands; I am also concerned with what I guess they would call the Wilderness. Still, the authors use the Grocery Store example for an elderly afflicted with Alzheimer's disease, so they are preoccupied with really ubiquitous basic emergency services. Among the open questions, the authors mention Binding Services (those that are usually there in the user's smart space and that we want to bind temporarily in other, visited smart spaces... The authors take into account the fact that the visitor of a smart space might have preferences that differ from those of this space's owner, and thus define a concept of smart space ownership); Quality of Service (including conflict management, service priority and user mobility, which ties into the Binding question above); Scalability (many users, many devices, many needs, lots of data, and so on... The authors raise the question of a layered architecture: it seems good to many and looks/ feels like a Framework or a Middleware, which is a comfortable approach for most, but is it the right one?); and Security and Privacy (of course).

A Context-Driven Programming Model for Pervasive Spaces (pervasive07-heni.pdf)

Problem domains : Context-Awareness, Pervasive Computing, IDE, Programming Model

This article essentially describes, in a compact and concise manner, what jansen_dissertation.pdf covered in detail. One nice thing about the suggested programming model is that, while the context inference engine must be dealt with by programmers, the context webs could (perhaps) be produced by scientifically-minded, rigorous individuals with less computer science knowledge.

Safety Enhancing Mechanisms for Pervasive Computing Systems in Intelligent Environments (perware08.pdf)

This article claims that users come to rely on pervasive systems for basic or essential tasks, and that correctly functioning pervasive systems are a safety issue. Pervasive systems are described as «semi-sentient» and associated with laws reminding us of Asimov's laws. The article posits pervasive systems as user-centric; I have to think more on that one. This article also deals with service integration into pervasive space...

A Programming Model for Pervasive Spaces (progmodel-report.pdf)

Authors : Erwin Jansen, Bessam Abdulrazak, Hen-I Yang, Jeff King, and Sumi Helal

Problem domains : Pervasive Computing, Programming Model, Calm Computing, Semantic Web, Ontology, Intentional Logic

This article describes a programming model for pervasive systems bound to a location (the introduction explicitly marks pervasive spaces as being bounded). It is directly related to jansen_dissertation.pdf, UbiSys2006-heni.pdf, pervasive07-heni.pdf and perware08.pdf, and formalizes the issues discussed therein.

Context Awareness Systems Design and Reasoning (ISoLA.2006.335-340.pdf)

This article explains how Timed Communicating Object Z (TCOZ) can be used to model sensor constraints in a context aware setting. Their test setting involves room lighting control, for energy saving purposes, and remote mobile phone control to avoid cell phones ringing during meetings. The formal model used is interesting but dry for one not versed in Object Z notation.

The Gator Tech Smart House: A Programmable Pervasive Space (helal_GTSH_IEEE_Computer_March_2005.pdf)

Authors : Sumi Helal, William Mann, Hicham El-Zabadani, Jeffrey King, Youssef Kaddoura and Erwin Jansen

Problem domains : Context Awareness, Pervasive Space, Smart Home, Intentional Logic

This article describes the Gator Tech smart space, claiming it to be scalable and extensible. It describes the rationale behind this specific house and the problems (perceived in other smart spaces) it is trying to address. The various sensors and actuators un the house are presented (some interesting ones indeed: smart mirror displaying messages, toilet paper sensors, a driving simulator to test the elderly's capabilities, smart closets that suggest clothing, social-distant dining to have lunch with friends at a distance, etc.). The s/w architecture, based on OSGi, is described, in which services are (conceptually) lower than (underlying) context management and knowledge management. An interestin aspect of their s/w architecture is that it does not use a specific context-aware programming model (although the authors have indeed worked on this topic, as shown i nsome articles above). As is often the case in context-aware programming models or structures, dealing with context tends to result in programming models that are closely related to state machines.

Gestion et déploiement d’applications en milieux ubiquistes à l’aide d’OSGi (memoireCharles.pdf)

Problem domains : Service Discovery, Context-Awareness, Service Deployment, Pervasive Space Managements

Remarks

Charles, tu abuses de « par exemple », mon snorro! Aussi, prudence avec les mots « altérer » et « versatile » qui n'ont pas, en français, le même sens qu'en anglais. Idem pour « mettre l'emphase »...

Chapitre 1. « Ubiquitous Computing » devient Informatique omniprésente, un bon choix. J'aime ça. Idem pour AVQ (Activités de la vie quotidienne) pour ADL. Le travail est situé comme suit : quand il y aura plusieurs habitats intelligents, il ne sera pas rentable d'envoyer des techniciens régler les problèmes de l'un ou de l'autre.

Le mémoire contient des prises de position personnelles dès la §1.1, ce qui m'étonne. Le texte distingue « informatique omniprésente », « intelligence ambiante » et « informatique multi-agents ». D'où viennent les infos du tableau 1?

La contextualisation permet à l'informatique omniprésente d'anticiper les besoins d'un usager. Ce problème est analogue à celui de précharger les données en antémémoire sur la base d'algorithmes prédictifs : pas facile!

Chapitre 2. Le problème du déploiement et de la gestion des applications/ composants/ services est décrit : les composants reposent sur des systèmes d'exploitation et sur des technologies hétérogènes, mais il faut les arrêter, les démarrer, les intégrer et les remplacer de manière homogène. Un lien (intéressant) est fait avec les cycles courts des microprojets préconisés par plusieurs méthodologies agiles, cycles qui intègrent la réalité des correctifs dans le cycle de développement et qui perçoivent ce développement comme organique. Il faut pouvoir gérer le cycle de vie des applications, peu importe la situation.

Le caractère humain de résistance au changement est utilisé pour exprimer l'importance d'automatiser les tâches ayant trait à la gestion des mises à jour logicielles dans un espace intelligent (évidemment, les mises à jour matérielles demanderont des manipulations physiques). L'utilité de pouvoir mettre à jour, à distance, le logiciel de plusieurs composants semblables d'un seul coup est mise en relief.

Une partie de la solution préconisée par le mémoire est le recours à Java. Cela restreint toutefois la capacité d'intégrer des entités COTS (à moins de les enrober dans des classes Java conçues à la pièce); choisir la technologie de développement est intéressant quand le cycle de développement tout entier est contrôlé. Ça ressemble plus à un choix esthétique qu'à une contrainte sine qua non, mais les choix esthétiques, c'est pas un mal non plus.

Une approche orientée services et dont les modalités de gestion du cycle de vie sont dynamiques est préconisée.

Chapitre 3. Une approche par traction (pull) à la Windows Update (ou autre) est peu adaptée à la réalité hétérogène des environnements d'informatique omniprésente. Une approche par poussée (push) est préférable. Plutôt que d'être habilités à s'enquérir périodiquement de mises à jour, les composants doivent être habilités à accepter des (ordres? suggestions?) de mises à jour. Question pour moi : est-ce vrai dans un espace intelligent ouvert? À réfléchir. Même dans les environnements fermés, je vois l'argumentaire mais je ne suis pas (pas encore, du moins) pleinement convaincu, mis à part le caractère plus immédiat d'une approche par poussée (la mise à jour se fait rapidement quand elle est exigée, sans coûter trop cher de bande passante).

L'essentiel du chapitre présente l'architecture de déploiement choisie, en commençant par la classique approche de deux stratégies inadéquates (un peu des faire-valoir, mais je pense que c'est une approche universelle) et en terminant, de manière plus détaillée et très constructive, par l'approche OSGi, effectivement choisie. À sa décharge, le modèle est très sympathique. Symptôme de ce genre de démarche, où la technologie avait en fait été choisie a priori, le tableau de la page 49, qui résume les pour et les contre des diverses technologies envisagées, n'appuie pas clairement le choix OSGi, qui a pourtant été fait (à l'oeil, en se basant sur le tableau, j'aurais hésité entre OSGi et OCAP).

Il y a des idées à récupérer dans ce chapitre pour mon propre travail, mais il faudra être sélectif (à quel point peut-on penser administrer l'espace ouvert d'un point de vue aérien? Des négociations entre pairs ne seraient-elles pas plus appropriées?). L'approche de Charles profite du vase clos et l'exploite, de manière très compréhensible.

Prudence : à la page 62, il est faux d'affirmer que SOAP repose sur HTTP (c'est une option—sage, mais pas la seule).

Chapitre 4. Un intergiciel a été développé pour combler certaines lacunes des versions de OSGi disponibles à code ouvert (administration du déploiement à distance, récupération des journaux). Est-ce un complément à OSGi (ajout aux sources) ou un outil distinct?

Une approche pyramidale (trois niveaux : gestion, environnement, appareil) pour diffuser les consignes de déploiement a été utilisée. Ceci est présenté comme une approche par laquelle des gains de sécurité sont réalisables (moins de points d'accès au réseau omniprésent).

Les services Web sont présentés comme étant destinés aux multitudes. Ce n'est qu'une possibilité, pourtant; rien n'empêche de définir des services Web à clientèle restreinte. Le recours à SOAP est une approche saine dans la mesure où l'interopérabilité et l'extensibilité sont des vertus vers lesquelles on souhaite tendre.

La page 61 mentionne l'importance de déployer les bundles dans le bon ordre, faute d'être capables de détecter et de gérer les dépendances transitives. Pourtant, il existe des approches pour y arriver... Quelle est la justification de cette contrainte? Si c'est un aspect manquant à OSGi (c'est, je pense, le cas), n'aurait-il pas été important de le couvrir?

Il y a des restrictions à l'utilisation de UPnP pour découvrir des appareils (ils doivent faire partie du même réseau local; c'est un irritant sérieux avec des cellulaires par exemple).

Insérer un nouveau composant implique l'envoi d'un message à un registre centralisé. La durée de présence dans un environnement intelligent est gérée par baux. Des demandes récurrentes sont faites par chaque appareil pour renouveler son bail (pas de renouvellement de bail : disparition de l'environnement intelligent).

Chapitre 5. Ce chapitre discute des extensions à OSGi mentionnées au début du chapitre précédent. La combinaison JVM/ OSGi/ Intergiciel/ applications est lourde pour les ressources des appareils mobiles.

La journalisation répartie se fait avec le soutien d'un serveur présent dans l'environnement (un problème dans un espace ouvert). La localisation des appareils (de manière plus riche que par leur nom) est un travail en cours.

Chapitre 6. Tel quel, l'intergiciel est utilisable mais déficient du point de vue de la prise en compte du contexte, de la résilience face aux pannes set du point de vue de la sécurité (aucune authentification).

L'absence de support LDAP chez les outils choisis revient fréquemment dans l'argumentaire, mais de simple services SSH (HTTPS, étant donné le recours à SOAP) n'amélioreraient-ils pas intrinsèquement la situation?

L'intelligence ambiante telle que présentée (déployer un composant ou un service destiné à afficher sur un périphérique capable d'afficher, par exemple) semble exiger une représentation pertinente des lieux (les travaux de Margaux?)

Mettre en place la résilience face aux pannes demande un travail d'identification de la nature du problème qui n'est pas banal.

A Comparison of Two Programming Models for Pervasive Computing (http://www.icta.ufl.edu/projects/publications/heni-saint06ws.pdf)

Problem domains : Pervasive Computing, Programming Model, Calm Computing, Semantic Web, Ontology, Intentional Logic

This article compares context-driven and service oriented programming models and examines the pros and cons of each in Pervasive Computing. Smart spaces are defined as bounded and context (taken in sets constituting a snapshot in time of the entire space) as something that can be examined for a given Smart space using description logic. Actions are taken (through actuators) to ensure the state of a given Smart space congerges towards desirable contexts, and emergency measures are taken if the state converges towards a very impermissible context (something that would put the Smart space and its inhabitants in danger). Such a programming model accepts solidly grounded reasoning approaches. The description given on service orientation is much more terse (services are stackable and lend themselves to something akin to procedural programming).

The section describing the advantages of context-driven programming models fares well in describing the nice things about this model but sorely weaker in describing the service oriented competition, making many unwarranted assumptions (the scalability aspect is particularly weak). The quality of the comparison suffers (what makes it worse is that the 1st element of the service-oriented advantages tells us that context graphs would get messy for complex systems and that service-oriented approaches would fare better in this case!).

The nice thing about this article is its conclusion: merge both approaches! There's no reason not to, since service-based transition behaviours is a very natural implementation and suits a context graph nicely: discover and associate services to suit your needs when building the context graph, why not? Both of the hybrid approaches proposed by the authors are interesting. The bounded nature of their perception of Smart spaces requires thought on my part if I'm to use their results, though.

Enabling a Plug-and-play integration of smart environments (01684479.pdf)

This article describes a Framework built to allow Smart Homes in a Box : Smart spaces that are easier to deploy and program and where many specialists could contribute to the programming task. Like many recent articles on the topic, it puts forward the fact that building individual smart homes is a costly, ad hoc task that must be automated and simplified if we are to be able to make smart homes for the needy a reality.

De retour à l'école...

Contextualisation (Context-Awareness)

Termes-clés

Définitions

Principaux laboratoires (il m'en manque)

Autres laboratoires peut-être connexes

Principaux acteurs (il m'en manque beaucoup!)

Thématiques connexes

Lectures récentes

An Ontology based Context aware modelling and reasoning to enhance Human environment Interaction (sic for the entire title)

Remarks

DEVELOPMENT OF APPLICATION SOFTWARE FOR A WIRELESS POSITION TRACKING SYSTEM

A SUBSCRIPTION BASED GENERIC MEDICAL EVENT MANAGEMENT SYSTEM FOR TELEMEDICINE APPLICATIONS

AN AGENT-BASED SELF RISK ASSESSMENT AND MONITORING SYSTEM FOR CARDIOVASCULAR DISEASE PATIENTS

A SMART VISION-BASED HUMAN FALL DETECTION SYSTEM FOR TELEHEALTH APPLICATIONS

CONSIDERATION OF SECURITY IN TELEHEALTH WIRELESS SENSOR NETWORK MONITORING SYSTEMS

REAL-TIME COACHING USING ROBOT-BASED SEMI-TELEOPERATED CAMERAS

REALISING MULTIPLAYERS (sic) SCENARIOS FOR REMOTE BIOMONITORING

AN INFORMATION DELIVERY AND DISPLAY SYSTEM FOR DEAF PEOPLE IN TIMES OF DISASTER

Trends and Issues in Research on Context Awareness Technologies for a Ubiquitous Network Society (AJOUTER AU DOCUMENT WORD)

SPECTER: a User-Centered View on Ubiquitous Computing (AJOUTER AU DOCUMENT WORD)

Ubiquitous Computing Technology for Just-in-Time Motivation of Behavior Change (AJOUTER AU DOCUMENT WORD)

Building Ambient Intelligence into a Ubiquitous Computing Management System (AJOUTER AU DOCUMENT WORD)

Spontaneous and Context-aware Media Recommendation in Heterogeneous Spaces (AJOUTER AU DOCUMENT WORD)

An OSGi-Based Infrastructure for Context-Aware Multimedia Services (AJOUTER AU DOCUMENT WORD)

Harnessing Location-Context for Content-based Services in Vehicular Systems (AJOUTER AU DOCUMENT WORD)

An Ontology-based Context Model in Monitoring and Handling Agitation Behaviour for Persons with Dementia (AJOUTER AU DOCUMENT WORD)

Supporting Context-Aware Mobile Service Adaptation with Scalable Context Discovery Platform (AJOUTER AU DOCUMENT WORD)

OSGi Based Service Infrastructure for Context Aware Automotive Telematics (AJOUTER AU DOCUMENT WORD)

Context-Aware Content Filtering & Presentation for Pervasive & Mobile Information Systems (AJOUTER AU DOCUMENT WORD)

Towards an extensible context ontology for Ambient Intelligence (AJOUTER AU DOCUMENT WORD)

Middleware for Distributed Context-Aware Systems (AJOUTER AU DOCUMENT WORD)

A Distributed Ontology Framework in the Semantic Grid Environment (AJOUTER AU DOCUMENT WORD)

Some documents read but not retained from IASTED2007

Mobile Agents: Can They Assist with Context Awareness ? (01263080.pdf)

Integration of Ad hoc Network and IP Network Capabilities for Mobile Hosts (01191288.pdf)

A Simulation Model of Adaptive Protocols in Distributed Computing Systems with Mobile Hosts (00393577.pdf)

Towards a Mobile Enterprise Framework (00843299.pdf)

Awareness and Agility for Autonomic Distributed Systems: Platform- Independent Publish-Subscribe Event-Based Communication for Mobile Agents (01232098.pdf)

Mission Impossible? Automatically Assembling Agents from High-Level Task Descriptions (01241063.pdf)

Run-Time Mission Evolution in Mobile Multiagent Systems (01342927.pdf)

On Development and Evaluation of Prototype Mobile Decision Support for Hospital Triage (01385554.pdf)

Loosely Coupling (sic.) Ontological Reasoning with an Efficient Middleware for Context-awareness (01540998.pdf)

A Distributed Middleware Solution for Context Awareness in Ubiquitous Systems (01541123.pdf)

Improving Operational Efficiency of Web Services with Mobile Agent Technology (01565631.pdf)

Merging Context Perspectives: An Approach to Adaptive Agent Reasoning in Pervasive Computing Systems (01599059.pdf)

Context Awareness in Future Life Scenarios: Impact on Service Provisioning Platforms (01619998.pdf)

ConEx: Context Exchange in MANETs for Real time multimedia (01628316.pdf)

A Formal Model of Context-Awareness and Context-Dependency (01698735.pdf)

On the definition and relevance of context-awareness in Personal Networks (04141780.pdf)

Sensor Data Collection Using Heterogeneous Mobile Devices (04283908.pdf)

Evaluating Cross-layer Context Exchange in Mobile Ad-hoc Networks with Colored Petri Nets (04283911.pdf)

Port-based Multihomed Mobile IPv6: Load-balancing in Mobile Ad hoc Networks (04367852.pdf)

CONTEXT-DRIVEN PROGRAMMING MODEL FOR PERVASIVE SPACES (jansen_dissertation.pdf)

Remarks

§1)

§1.1)

§1.2)

§1.3)

§1.4)

§1.5)

§1.6)

§2) and §2.1)

§2.1.1)

§2.1.2)

§2.2)

§2.3)

§3)

§3.1)

§3.2)

§3.3)

§3.4)

§3.5)

§3.5.1)

§3.5.2)

§3.6)

§4)

§4.1)

§4.2)

§4.3)