This section is to track the discussions on the implementation of "User Context" in KDE. For a more general understanding of context in Nepomuk, check out here for the basics and here for the details.
Though there are numerous definitions of Context out there, we would like to refine the important aspects of context to the aspects of "user context":
In general, the meaning of the word "context" is not defined and talking about the word "context" in discussions is unfruitful. We are Understanding Context Before Using It and use the term "user context" deliberately, understanding it as "activity, location, contacts, and resources relevant to the work the user is doing at the moment".
Typically, Desktop applications and widgets have been available just like normal tools which are in no way more "intelligent" than their physical counterparts (ok, apart from their ability to undo things ;) in that they just do exactly what the users tell them to (of course, bugs don't count here!). Nothing less, nothing more!
They have been heaped with loads of functionality which just adds to the clutter the user is already facing with the growing information-overload. They do nothing more that will help the user to reduce his overload, apart from what he tells them to do. So, something has to be done to tackle this now, when information overload is increasing and things are becoming more mobile!!
Continuing the passion for desktop innovation with KDE, we want to induce in our apps the "intelligence" to adjust themselves to the work the user is currently doing. Hence ....
Dikku is a new user context framework that exposes the current user activity and location to both plasma widgets as well as other applications, thus enabling them to adjust themselves to the user's needs.
Dikku means direction in Tamil; when we get lost we generally establish context of where we are based on direction. Currently when we are lost in information, we could look forward to Dikku for assisting us ;) So, I think the name fits. Any suggestions ?
Activities are a "more casual" term for things that range from organized content like projects (which have deadlines, tasks and resources) to adhoc grouping of apps and widgets for a purpose (like in virtual desktops). Perhaps a little history can help here : Activities in KDE have their existence based on 'virtual desktops', where user forms adhoc grouping of apps and widgets. We are currently planning to extend the concept to cover projects also, where user can just add deadlines, tasks and resources to an existing 'virtual desktop' (visually) and can use it as a project with associated apps, etc
Currently we plan to track the following information in Dikku:
and allow for:
The context framework could be implemented in three phases:
The Architecture of Dikku can be split into three major parts:
1. Data Model - how the information is actually stored. We plan to use existing Nepomuk ontologies here
2. Learning Model - how the system observes the user, understands what he is doing and learns to suggest things to the user and other interested agents (apps and widgets)
3. Interaction Model - how the interested agents adjusts themselves according to the system suggestion; and how the user deals the system and possibly corrects its assumptions to start getting results!
The main component where all three architecture parts come together will be a Dikku-usercontext daemon.
The design decisions taken in this framework are listed in a separate page.
As Nepomuk project has already handled the bulk of work by doing a lot of research in this area, we can just reuse whatever is possible from them (the beauty of open source !)... Check out related Nepomuk links
The PIMO (Personal Information Model) of the user contains the relations between items (resources, things) on the desktop. There we store the relations between a task and related documents, people, topics, etc. Dikku will use these relations to suggest relevant things once a resource is touched by the user.
User interfaces that show "current related things" taken from Dikku should then allow the user to "save" these relations when shown. For example when I look at a mail "bug in dikku", Dikku suggest the mail is related to "Work on KDE" and has the Topic "Dikku project", I can "save" the relation between the task "Work on KDE" and "Dikku project". Saving the relations is not part of Dikku but of nepomuk-kde libs and stored in soprano using the PIMO vocab.
While PIMO cares for relations and topics of things, Dikku knows which things are relevant at the moment and can give suggestions.
Unclear (for LeoSauermann) is the relation between Plasma::Context and Dikku, Aaron Seigo suggested: plasma defines which is the current activity and publishes that information. the rest of the activity nodes remain in Nepomuk. Could we get more on this?
Though we are not aware of any other context framework that ships with the desktop, there are a few projects which give a fair attempt at context-awareness. Some of them (with downloadable code) are listed below:
Application that can be configured to trigger actions based on context, which is detected by hardware observation (usb activity, network)
The "location" and "activity" concept of Marcopolo maps to PIMO's classes pimo:Location and pimo:Topic and pimo:Task / pimo:Project, we use them to represent important locations.
What we learn from Marcopolo:
* We should try to detect if thing (location, task) is in current context * we should allow the user to trigger actions if a certain thing is in context
The group around Mary Czerwinski from Microsoft Research (she is famous in HCI research) did several things in task and context management. Scalable Fabris is one of the older, simple appraoches:
What we can learn (her abbridged conclusions)
"Windows in a central focus area behave as usual, while windows in the display periphery are scaled down minimized windows. Periphery windows can remain open and live. Task switching is accomplished by a single mouse click. Users prefer this approach to the standard TaskBar. Problem: it should replace the existing task bar."
There is later work by others, LeoSauermann has no time on 29.8.2008 to find it