User talk:Harikrishna/Architecture/Data Model

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

Discussions for actual modeling are given below :

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.