[Nepomuk] relationship between pimo:project and pimo:task

swair shah swairshah at gmail.com
Thu Aug 25 13:49:17 UTC 2011


Hey Christian,


> Hey swair,
>
> > Does having Pimo:Tasks as optional subsets of Pimo:project make sense?
> This
> > is is reference to a 'project management tool'.
> > Treating Tasks in a similar way websites, persons, files and notes with
> > respect to a Pimo:Project does not make sense.
> >
> Why doesn't that make sense?
> The only difference I can see is that the pimo:partOf relation seems a
> little
> stronger than the pimo:isRelated relation.
> I think it depends on each case which one is more correct, so either option
> seems valid.
>

Yes both option seem valid. Still I think we should not use the same
property for tasks and say, notes or persons.
In my view while the Project Integrator (or MindMirror) is listing things
related to a particular project, tasks should be treated differently than
say, a note. Since task represents a part of the project itself. To be more
clear, you can sometimes exhaustively divide a project into different tasks,
and at the completion of all the tasks you are done with the project, or
something like that. I know it does not hold true for every case.

I was thinking of showing task in a different list view than other 'things'
related to a project. May be showing tasks and projects  both in the same
tree view and listing tasks related to a project as the children of the
project node. Since, that way if i have some things related to only one task
of the project and not to other tasks, i can list them with clicking that
task.


> Currently I'm using pimo:isRelated in MindMirror to relate the tasks to
> either
> Topics or Projects ,but that could be changed. The only requirement is that
> I
> can relate a Task with multiple Projects/Topics at the same time, but that
> seems to work for both properties too.
>
> So for consistency's sake I would just use the same property as used to
> relate
> files, notes, etc.
>

It is important that everyone uses a consistent property for tasks,
(whichever property we decide in the end). So we should decide what to use.
I'm inclined towards using pimo:partOf for tasks and pimo:isRelatedTo for
other things.


> > This is what i propose: To have a pimo:project has:part pimo:Tasks,
> instead
> > of isRelatedTo. Make a pimoProjectModel, which has projects as nodes and
> > tasks as children. With Tasks having TMO:States but keeping the states
> > limited to just 3 for better usability: states, Completed, Running, Not
> > Completed (New).
> >
>
> I'd suggest using 4:
> tmo:TMO_Instance_TaskState_New : New Items, not yet specified
> tmo:TMO_Instance_TaskState_Running : Something you're working on right now.
> tmo:TMO_Instance_TaskState_Suspended : Something you want to keep for later
> tmo:TMO_Instance_TaskState_Completed : Completed tasks/Aborted tasks
>

Ah yes i remember you telling me about these, this makes sense.


>
> > Of course a project can exist without having no task as a part of it. And
> > task can exist without being a part of a project and These tasks won't be
> > handled by project manager.
> >
> > When a task is chosen as a working context, if it is pimo:partOf a
> project
> > then that project is also a working context, meaning, 'things' which are
> > related to the task also get associated with the project. I don't really
> see
> > a use case for the last one, but having task as a part of a project would
> > certainly help.
>
> Cheers,
>
> Christian
>
>
cheers,

Swair.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20110825/b8910a07/attachment.html>


More information about the Nepomuk mailing list