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.
>
Yes, that's fine.
It is definitely a good idea to FIRST define how to represent context,
as well as, how to activate/switch (between) these contexts.
After this, "guessing" contexts, switching proposals, etc. can be done
in a THIRD step - definitely.
I would suggest, that a SECOND step would be to look the user over the
shoulder and _automatically_ track the (contextually relevant!)
resources he uses for the currently activated context.
[Please note the semantic web talking here: "resources" means documents,
web pages, but also: contacts, locations, and even up to more abstract
things like: topics, projects, etc.]
Sebastian Trüg wrote:
> 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.
As Leo already stated the class MediumTermContextThread (subclass of
UserWorkContext) would actually be the right class to represent the
context we all talk about here. The ShortTermContext can be compared to
the short-term memory of a human being and is hence very
"fluctuational", and the LongTermContext is more or less what could also
be called a "user model" containing all the user's PIMO concepts and
their frequency and so on.
So, in our opinion, the context could be represented best using an
instance of the class UserWorkContext. Class MediumTermContextThread
would be better because it is more precise, but that's really not the
most important question here.
More important is the "containsElement" property pointing from a context
to a ContextualElement.
So, why ContextualElement now? Why don't we reference the resources used
in a context directly?
The answer is easy: On the one hand we did not want to use meta-classes,
but on the other hand we need more meta-information on the contextual
relevance of such resources. So: We want to capture information about
- WHY is that resource relevant for the context? Has it been read by the
user or proposed by some magic algorithm?
- HOW relevant is that resource for the context? Not all resources are
equally relevant for some context. In particular, this holds for
resources that were estimated to be relevant (context magics).
So, one ContextualElement just wraps one relevant resources for a
context leading to this picture
MediumTermContextThread --containsElement--> ContextualElement
--resource--> Resource
instead of this one:
> "Context definingResource Resource"
As Leo said, this modeling can be taken as a start and, of course, be
enhanced.
The MediumTermContextThread could sould a bit strange and crazy at a
start, but it describes quite well what a context in our (and in your!)
sense really is, doesn't it? We talk about medium-term tasks,
medium-term activity, ... well... it is a medium-term context, right?
The postfix "Thread" is used to indicate that we talk about multiple
threads here between which the user is actually switching - like in
multi-threading!
So, there is definitely more than one such MediumTermContextThread,
namely one for each thread the user is really aware of, so one for each
task, or one for each desktop if you wish...
> as for the ontology figuring, i'm just going to lurk a bit while the experts
> figure that out =)
:-D
Keep it simple, but keep it shared! That's the important thing here.
Rebuilding yet another "ontology" from scratch is not really an
"ontology" because it misses the chance of a shared understanding once
again. We do already have thousands of "ontologies" that are rather
"schemas", in particular, scheamas nobody knows and uses...
Our ontology is not a great schema, but it is at least shared by some
Nepomukians. That's one step towards really building a semantic web...
So, Leo's proposal is good: Start with our schema and extend or enhance
it. If it is really to complicated, then let's discuss on making it
simpler, however, I think our ontology is already quite simple.
Aaron J. Seigo wrote:
> On Monday 25 August 2008, Sebastian Trüg wrote:
>
>> 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.
>>
>
> personally i'd like at least a start time with ActivityContext as well so
> they
> can be put onto a timeline.
>
A "start time" is fine, but an "end time" will be seldomly used and if
it is used then what does it tell us?
What I do myself, and what I suggest to do here, too, is to have a set
of ACTIVATION INTERVALS.
I know, that this will yield scalability problems, but these could and
should be overcome. Don't we want to see and search(!) really ALL the
activations of a context (on a timeline for instance)? I do think so!
The mathematics done in the nepomuk is not really intended to be
patented or something ;-) -- it is not quite the "Quicksort of context
research" ;-) -- but Leo is right, I have not yet published it. So, it
is merely a problem of "stealing" a part of my dissertation than
stealing magic know-how and great technology. Use it if you like it - no
problem here!
Thanks for the interesting discussion already!
Have a nice day,
Sven
_______________________________________________
nepomuk-kde mailing list
nepomuk-kde@semanticdesktop.org
http://lists.semanticdesktop.org/mailman/listinfo/nepomuk-kde
