User talk:Harikrishna/Architecture/Learning Model

Two threads

According to the current state of the art in context research, this can be divided into two threads:

1. "Perception" (or "user observation")
---> Goal: Gather contextual evidences
---> Realization: User observation modules/components that observe the user's behaviour (desktop actions), track his current location, emotion, whatever more... That's what is what is done with [User Observation Hub]

2. "Context Awareness" (or "context elicitation")
---> Goal: Estimate and model the user's context(s)
---> Realization: The best way of doing this is not yet settled. But by picking and harvesting low-hanging fruits you can already achieve a lot. The most important thing here is to clarify WHAT IS THAT "CONTEXT" ANYWAY? So: Let's start with defining WHAT the context is USED FOR. Your ideas (in previous emails) went in the right direction. Then go over to define, HOW can we MODEL this in an efficient way. At last, we implement some algorithms that fill and update this context model. As I said, the latter part is not yet settled, but don't worry about that now. It will live!

Overall Process

1. applications observe the activities of the user and communicate them, to other applications and to a central "user work context" daemon that gathers activities.
also, all activities may be logged for later use for example: the user opened file "My Plan to get famous" in KWrite and starts editing

2. daemons report background context
for example: a GPS daemon connected to a GPS mouse sends the position of the user as context information

3. the "user work context" daemon receives these messages and computes what the user is probably doing, this is important to have a daemon for this, as user often press alt-tab and you need something clever to keep track of what the user is really doing