What is the context-Awareness?

"You cannot not communicate!" (common saying)
"60% of our communication is misunderstanding" (I have read this one somewhere)

Often, the term "Context-Aware Computing" is used in a sense synonymously to ubiquitous computing. This is because almost every Ubicomp application makes use of some kind of Context. Therefore, Context-Awareness is a concept which is orthogonal or immanent to all the other research topics presented in the research section. But let us start at the beginning and try to find a definition of what Context and Context-Aware Computing is.

The Human Point of View

Humans have anquite intuitive understanding of Context. Here, Context is often referred to as "implicit situational understanding." In social interactions Context is of great importance: A gesture, a laugh, or the intonation of sentences is building up the implicit "picture" of what is meant or what my communication partner is thinking. The same words can have a  completely different meaning in different contexts. We all have already experienced this ambivalence of communication. The context-defining element here is background knowledge and the "where, who, and what". As soon as you can make some assumptions about whom you are communicating with or you have some "historical" knowledge about him or her, you can understand a completely different importance or meaning of a sentence or a word. Communication takes place (also) on a different level than the spoken word.

Context and Computer Science

"What context is is context dependant" (One of my favorites when giving a talk)

In Computer Science Context is quite familiar. Be it within the discipline of Artificial Intelligence ("Thinking machines"), in Robotics ("Adaptive Systems"), in User Interface Design (like adaptive UIs or (IMHO ill-designed) office assistants like the Microsoft Office assistant called "Clippy"), or basically any other discipline (to some extent). Especially, every discipline dealing with human users tries to take into account human behaviour one way or the other. Figure 1 tries to characterize this basic behaviour: Generated output loops back as part of the vector of input values.
Now remember what ubicomp is mainly about: Building systems which are useful to users, that "...weave themselves into the fabric of everyday life until they are indistinguishable from it."  Well, this is what I would call "user-related business". For Ubicomp systems Context is essential: "How can a system be helpful for a user?" User tend to move around often, doing new things, visiting new places, changing their mind suddenly, and changing their mood, too. Therefore, a helpful system seems to need some notion of Context.
On the other hand a common definition of Context in the Ubicomp community is "everything is (potentially) context" or "what context is depends on the context". These are definitions which is hard to build a system on top of ;-)
But let us have a closer look at some of the definitions which are commonly used by ubicomp researchers:
(The following paragraphs are taken from the diploma thesis of a former student of mine - Meik Reimer)

In [insert DA, understanding of context] some definitions of context are listed. From the variety of definitions one can imagine how difficult it is to find a common ground. Context definitions are far away from mathematical precision  and a particular definition often strongly depends on an authors' subjectiveness:

• Schilit and Theimer: "Location, identities of nearby people and objects, and changes to those objects."
• Brown et al.: "Location, identities of the people around the user, the time of day, season, temperature, etc."
• Ryan et al.: "User's location, environment, identity and time."
• Dey: "User's emotional state, focus of attention, location and orientation, date and time, objects, and people in the user's environment."

Further definitions, which are more or less synonyms for context, are the following ones:

• Commonly used are often "environment", "situation", "user's environment" and "application's environment."
• Brown: "Elements of the user's environment that the user's computer knows about."
• Franklin & Flaschbart: "Situation of the user."
• Ward et al.: "State of the application's surroundings."
• Rodden et al.: "Application's setting."
• Hull et al.: "Aspects of the current situation."

Some definitions are closer to an "operational definition" Dey and Abowd desire in the same article (see above). For example:

• Dey et al.: "Context is the user's physical, social, emotional or informational state."
• Pascoe: "Context is the subset of physical and conceptual states of interest to a particular entity."

The authors consider all these definitions as to be too specific. They state:

"Context is all about the whole situation relevant to an application and its set of users. We cannot enumerate which aspects of all situations are important, as this will change from situation to situation. In some cases, the physical environment may be important, while in others it may be completely immaterial."

Hence, Dey and Abowd have their own definition of context:

"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."

(end of citations from the diploma thesis)

So what is this leading to? Are those definitions helpful or misleading? I cannot say! In the sense of a functional definition they are only helpful as a general description of what to do. As an application designer they are only stating what I am doing anyway: Trying to figure out what input is needed to produce the desired output. Note that here again is a "catch": In Ubicomp often you cannot even make an educated guess what input and/or output might be useful.

Hence, IMHO, it is of topmost importance to have some common ground or a common "vocabulary" when talking about what context is. We need some sort of formal approach towards handling and describing Context. Furthermore, in a software engineering sense, we need building-blocks for building context-aware applications in a structured way. It is not so much of importance to have a formal definition of what Context is (and what is not Context), as to have tools and frameworks at hand for building an application which can make use of Context by using acquisition and handling mechanisms already installed in the "real-world" context. The ContextToolkit by A. Day is a step into this direction and a good example for this principle. What is missing is the strong link between this level of context acquisition and the application itself (see Fig. 2). Figure 2 depicts the "gap" between acquiring Context and building applications in a structured way: The mechanisms for building applications are at best limited to building blocks like the ContextToolkit, where you habe so called "Widgets", wrapper classes for Sensors which serve as a hardware-abstraction layer, "Aggregators", which concentrate multiple input values to a single output value, and "Interpretors", implementing some application logic and generating application dependant "higher-level" output based on the input given. They interpret the incoming data according to a pre-programmed scheme.

So, what is the problem with this approach?             

Nothing in general. But, we believe that there is more tool-support necessary for software engineering and the design of Context-Aware applications than provided today. Today development of context-aware apps consists of three steps (ref. also Fig. 3):

• Real-world is sensed

• By sensors delivering "hard-data" (temp., humidity, etc)

• By sensors delivering "soft-data" (cameras, network traffic)

• Context is detected, aggregated, "interpreted"
• Applications are custom-build to match the "context-detection" technology (e.g., ContextToolkit (Anind Dey))

We want to emphasize that the way applications are developed is very dependant on the underlying technology used, which we consider as bad practice in the long run. Research in the direction of decoupling applications from data acqusition seems to be important. This is detailed in the section Middleware for Ubicomp.    

转载于:https://www.cnblogs.com/gentlewolf/archive/2007/07/04/805973.html