User talk:Harikrishna/Architecture/Learning Model: Difference between revisions

From KDE TechBase
No edit summary
No edit summary
Line 2: Line 2:
According to the current state of the art in context research, this can be divided into 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")
1. "Perception"  (or "user observation")<br/>
---> Goal: Gather contextual evidences
---> Goal: Gather contextual evidences<br/>
---> 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 [[http://usercontext.opendfki.de/wiki/UserObservationHub User Observation Hub]]
---> 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 [[http://usercontext.opendfki.de/wiki/UserObservationHub User Observation Hub]]


2. "Context Awareness"  (or "context elicitation")
2. "Context Awareness"  (or "context elicitation")<br/>
---> Goal: Estimate and model the user's context(s)
---> Goal: Estimate and model the user's context(s)<br/>
---> 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!
---> 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 ===
=== Overall Process ===
* applications observe the activities of the user and communicate them,
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. <br/>
to other applications and to a central "user work context" daemon that gathers activities
also, all activities may be logged for later use
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
for example: the user opened file "My Plan to get famous" in KWrite and starts editing


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


* the "user work context" daemon receives these messages and computes what
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
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

Revision as of 12:52, 27 August 2008

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

Retrieved from "https://techbase.kde.org/index.php?title=User_talk:Harikrishna/Architecture/Learning_Model&oldid=32292"