User talk:Harikrishna/Architecture/Data Model
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 nepomuk ontology is at least shared by some Nepomukians. That's one step towards really building a semantic web...
So, We plan to use PIMO and User Context ontologies for modeling how the data would be stored in Nepomuk.
We need to discuss further on resources ontology to define how resource are stored...
To Remember : All data in Nepomuk should be modelled along an ontology
which should also be installed along with the application (in this case context lib/service )
Discussions for actual modeling
Sebastian Trüg says:
I still think Context is a good name for the generic base class. An Activity
is already specialized. A context could also be "night mode" where you get no
work files or something. That is not an Activity.
So in Nepomuk (the RDF, ie. data level) you would have something like a Context RDF class and for each context create an instance of it. Then assign all resources created in this context to it. Whenever a context is loaded, only resource related to the context are considered. This could be represented via Nepomuk::Resource subclasses. But can also be handled manually through Soprano. This is a very basic and simple summary
Sebastian Trüg says:
I just took a look at the existing ontologies: NOP and Workcontext. 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.
Sebastian Trüg says:
> i think we will have to
> really think about how we expose this to the user as something like a task
> probably does not in itself provide enough information to *be* a context
> (it makes sense for a task to belong to one, even be the "primary" or
> defining piece of information related to one), and for Plasma we certainly
> do not want contexts being removed while they are being referenced by a
> Containment.
A finished task is not removed. It is just finished. I think it
could still be a subclass of Context. I don't see any conceptual problems...
but we could also create a TaskContext and link an actual Task as the
defining resource. Also a valid concept I think.
Sven Schwarz says:
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...