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:
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.