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
Associating resources with Context
Each MediumTermContextThread has probability values (between 0..1) for all possible elements in the user's life. For most of them, the value is of course 0. The user is in the mediumtermcontexthread "Working on my CID project", when Dirk calls me (he is related to CID and has a probability > 0 on this contexthtread)
Dirk gets "boosted" because he seems to be relevant, his probabilty (in this contexthrread) increases.
I get a second NOP (native operation) message saying that a chat comes with contact "Charlie the unicorn", which is not related to CID. Charly talks about going to Candy Mountain.
Now comes the tricky part we didn't solve really:
- either we switch to a new mediumtermcontext thread "Going to Candy Mountain with Charlie" and booost Charlie there or
- we ignore this switch and just add Charlie to the CID context, with a low probability
The tricky part is tricky. It will probably involve some visible feedback to the user such as "is charlie and this message in your currenty activity "CID Prject"?. From Sven Schwarz work, we would like to be able to set explicit changes.