ups, forgot the references: [1] http://ontologies.opendfki.de/repos/ontologies/userobs/nop.rdfs [2] http://usercontext.opendfki.de/wiki/UserContextOntology
On Monday 25 August 2008 12:33:14 Sebastian Trüg wrote: > I fully aggree that phase 1 should not deal with automated context > "guessing" just yet. We first need a proper framework to manage and > activate contexts. Also, the used ontology needs to be set in stone, as > well as its usage. > > I just took a look at the existing ontologies: NOP [1] and Workcontext [2]. > To me it seems that for phase 1 we don't need NOP at all (as it mostly > deals with user actions/activities that need to be modelled) and only need > a very small portion of Workcontext, if at all. > > Like I mentioned in a previous mail IMHO we basically need a Context class > and maybe two specializations: ActivityContext and TaskContext. TaskContext > would add start and end time to the concept. > We could then easily model different contexts. For example a project I am > working on would be modelled as a TaskContext which is also a pimo:Project > or maybe a subclass the user created himself like > pimo:KDEDevelopmentProject. Using this approach we could even stick to one > simple Context class and link tasks or projects or whatever to it as > something like > > "Context definingResource Resource" > > this would allow to model stuff like: > we have a context "Plasma Context Support" resource which is of type > Context. In addition a development project is defined which might have a > similar name and a bunch of files and emails and what not related. The > project is then related to the context and thus, becomes available for > dashboard switches. This would allow to use arbitrary things as contexts > without much additional syntax. > > I would need input from Sven and Leo here: would the > workcontext:UserWorkContext class be a choice here? Or should we create a > new, way simpler, ontology. > > Cheers, > Sebastian > > On Sunday 24 August 2008 12:58:32 Hari krishna Anandhan wrote: > > Phase 1 : Focus on global context and user productivity > > > > -- Activity Context > > 1). I think "Activity" should be the central context of interest. All > > other contexts exist just to help the user be more productive and > > focus on his "Activity" > > 2). User manually creates activities, and can possibly associate > > semantics to it by special "template tags" (which can be templates for > > settings, file attributes, apps used in activity, etc), instead of > > current passive tags used just for linking data. > > 3). when the user switches activities, the whole environment changes > > to focus the attention of the user on the related things and auto-tags > > the resources used (like files created, etc) with the activity. > > > > -- Other Sub Contexts > > 1). We can just listen to system-wide events (location, resources ) > > via listeners, send them to User Observation Hub which just broadcasts > > it > > 2). System adjusts the focus or auto-tagging according to the > > subcontexts, if needed > > > > Realisation : > > 1). We need to finalise the exact model of the concerned contexts, > > 2). need to come up with how the system adjusts itself to focus on > > activity depending on subcontexts and > > 3). possibly come with guidelines on how the applications would > > auto-tag associated resources (keeping in mind the corner cases) > > > > Phase 2: Focus on app-specific observers and knowledge reuse > > 1). Implement observers (via plugins to applications) to observe the > > user NOPs and send it to UOH > > 2). Provide mechanisms to facilitate knowledge reuse among different > > contexts. This can be used by the user himself to see how his previous > > actions had effect or by a newbie seeking help to see how others have > > done things in a particular context ) > > > > Phase 3 : Possibly introduce semi-AI things > > 1). Like, using "Attention Evidence" for more precise Information > > delivery (one of myMory's goals) > > > > If we agree to the above baseline, then we can start with Phase 1 > > discussions by brainstorming possible usecases so that we can define > > what properties the concerned contexts will be having... > > > > Waiting for inputs …. ;) > > _______________________________________________ > nepomuk-kde mailing list > nepomuk-kde@semanticdesktop.org > http://lists.semanticdesktop.org/mailman/listinfo/nepomuk-kde _______________________________________________ nepomuk-kde mailing list nepomuk-kde@semanticdesktop.org http://lists.semanticdesktop.org/mailman/listinfo/nepomuk-kde
