Common format for storing tasks in couchdb
Adi Roiban
Bellow is a suggestion for a task format that can be used by apps
using
desktopcouch or couchdb as backend.
I tried to used a common denominator for Evolution, Tasks, Tasque (eds
based), GTG and Tracks (a ruby on rails webapp).
In Evolution we have status and priority. Since they have arbitrary
value I found it hard to put them as standard fields, as first we need
to define some convention for these fields.
There is also percentage field. I was thinking we can replace "done"
with "percentage" and instead of true and false we can have 100 and 0.
What do you think?
For GTG I consider subtask (child/parent) and tags specific features.
For Tracks and Getting things done methodology we also have the notion
of "contexts". A task can be in the inbox, next action, or to be done
when on phone, at home or at office. This is somehow like a more
generic
status field, but I think this is a specific feature.
There is also a project field.
Maybe we can define them in the "gtd" field for
"application_annotations", but since they will store contexts and
projects id, we need also to define a way for storing contexts and
projects.
For a bit of backround, I'm working at something that started as a
desktop client for Tracks and now I'm switching to couchdb [1].
I know some users of various other task apps complains their tasks are
not displayed in the clock applet. Maybe with couchdb support for eds
we
can make this happens.
Here it is:
{
"_id": "id_of_this_document", # internal to CouchDB
"_rev": "revision_for_this_document", #internal to CouchDB
"record_type":
"http://www.freedesktop.org/wiki/Specifications/desktopcouch/task",
"record_type_version": "1.0",
"title": "<task's title>",
"content": "<task notes or aditional text>",
"create_date": "<creation date in UTC>",
"last_change_date": "<last modification date, in UTC>",
"start_date": "<start date, in UTC>",
"due_date": "<due date, in UTC>",
"done_date": "<date when this task was finalized, in UTC>",
"percentage": integer, #100 if this task is completed
"application_annotations": {
"Evolution": {
...stuff specific to applications, nobody should rely on
these...
}
}
}
Jonathan Lange
> Hi,
>
> Bellow is a suggestion for a task format that can be used by apps
> using
> desktopcouch or couchdb as backend.
>
> I tried to used a common denominator for Evolution, Tasks, Tasque (eds
> based), GTG and Tracks (a ruby on rails webapp).
>
I personally think that it's too early for standardization, since none
of these apps is using couchdb in anger.
> In Evolution we have status and priority. Since they have arbitrary
> value I found it hard to put them as standard fields, as first we need
> to define some convention for these fields.
>
This makes me want to know, what are you trying to achieve with this
standard? I don't have priorities for my personal tasks, but most
people consider it fairly essential to any task management system.
> There is also percentage field. I was thinking we can replace "done"
> with "percentage" and instead of true and false we can have 100 and 0.
> What do you think?
>
I think it's unnecessary. If you have a done_date column, you don't
need a percentage to determine completeness, nor do you need a
boolean.
> For GTG I consider subtask (child/parent) and tags specific features.
>
> For Tracks and Getting things done methodology we also have the notion
> of "contexts". A task can be in the inbox, next action, or to be done
> when on phone, at home or at office. This is somehow like a more
> generic
> status field, but I think this is a specific feature.
GTG implements contexts with tags, basically. A context feature is a
strict subset of a tags feature.
> There is also a project field.
How is it different from a parent task?
> Maybe we can define them in the "gtd" field for
> "application_annotations", but since they will store contexts and
> projects id, we need also to define a way for storing contexts and
> projects.
>
Given the number of bikeshed-style arguments on what GTD really is and
how best to implement it, I'd avoid storing information under the name
'gtd'.
> For a bit of backround, I'm working at something that started as a
> desktop client for Tracks and now I'm switching to couchdb [1].
>
Good luck.
> I know some users of various other task apps complains their tasks are
> not displayed in the clock applet. Maybe with couchdb support for eds
> we
> can make this happens.
>
>
> Here it is:
>
> {
> "_id": "id_of_this_document", # internal to CouchDB
> "_rev": "revision_for_this_document", #internal to CouchDB
> "record_type":
> "http://www.freedesktop.org/wiki/Specifications/desktopcouch/task",
> "record_type_version": "1.0",
> "title": "<task's title>",
> "content": "<task notes or aditional text>",
In what format? HTML? Plain text? Wiki markup?
> "create_date": "<creation date in UTC>",
> "last_change_date": "<last modification date, in UTC>",
> "start_date": "<start date, in UTC>",
> "due_date": "<due date, in UTC>",
> "done_date": "<date when this task was finalized, in UTC>",
UTC is good to define, but you haven't defined how the date is serialized.
> "percentage": integer, #100 if this task is completed
>
> "application_annotations": {
> "Evolution": {
> ...stuff specific to applications, nobody should rely on
> these...
> }
> }
> }
The model here is missing a way of saying "task cancelled" as opposed
to "task deleted". Maybe that doesn't matter.
Hope this helps,
jml
Adi Roiban
> On Tue, Jan 12, 2010 at 12:55 PM, Adi Roiban <adiroi...@gmail.com> wrote:
[snip]
> > In Evolution we have status and priority. Since they have arbitrary
> > value I found it hard to put them as standard fields, as first we need
> > to define some convention for these fields.
>
> This makes me want to know, what are you trying to achieve with this
> standard?
The main goal for defining a document format for tasks is to
facilitate collaboration between various task related applications.
For example manage tasks using GTG, have an overview in Gnome clock,
track some of them using hamster-applet, read them from a lightweight
phone app and have them somewhere on the web. Maybe this is a forced
example, but right now each app store it's data in a different format
and I would be happy to see some integration by default.
Maybe I'm trying to solve an inexistent problem.
>I don't have priorities for my personal tasks, but most
> people consider it fairly essential to any task management system.
Indeed.
priority : unsigned int # top priority = 0
> > There is also percentage field. I was thinking we can replace "done"
> > with "percentage" and instead of true and false we can have 100 and 0.
> > What do you think?
>
> I think it's unnecessary. If you have a done_date column, you don't
> need a percentage to determine completeness, nor do you need a
> boolean.
Agree.
> > For GTG I consider subtask (child/parent) and tags specific features.
>
> > For Tracks and Getting things done methodology we also have the notion
> > of "contexts". A task can be in the inbox, next action, or to be done
> > when on phone, at home or at office. This is somehow like a more
> > generic
> > status field, but I think this is a specific feature.
>
> GTG implements contexts with tags, basically. A context feature is a
> strict subset of a tags feature.
Thanks!
Now the question is : Are tags/context a common feature of task
management systems?
> > There is also a project field.
>
> How is it different from a parent task?
With project field the task tree will be only one level deep.
Using parent task as a way of grouping task would make sense.
parent_task : "string" # docid of the parent task
> > Maybe we can define them in the "gtd" field for
> > "application_annotations", but since they will store contexts and
> > projects id, we need also to define a way for storing contexts and
> > projects.
>
> Given the number of bikeshed-style arguments on what GTD really is and
> how best to implement it, I'd avoid storing information under the name
> 'gtd'.
Agree.
[snip]
> > Here it is:
>
> > {
> > "_id": "id_of_this_document", # internal to CouchDB
> > "_rev": "revision_for_this_document", #internal to CouchDB
> > "record_type":
> > "http://www.freedesktop.org/wiki/Specifications/desktopcouch/task",
> > "record_type_version": "1.0",
> > "title": "<task's title>",
> > "content": "<task notes or aditional text>",
>
> In what format? HTML? Plain text? Wiki markup?
I would say plain text.
But instead of wiki markup, I think a subset of HTML would be
preferred.
For complex rendering, each app can store it's format in the
application specific fields.
> > "create_date": "<creation date in UTC>",
> > "last_change_date": "<last modification date, in UTC>",
> > "start_date": "<start date, in UTC>",
> > "due_date": "<due date, in UTC>",
> > "done_date": "<date when this task was finalized, in UTC>",
>
> UTC is good to define, but you haven't defined how the date is serialized.
It should be the same date serialization of for the other date fields
in notes and contacts.
> > "percentage": integer, #100 if this task is completed
>
> > "application_annotations": {
> > "Evolution": {
> > ...stuff specific to applications, nobody should rely on
> > these...
> > }
> > }
> > }
>
> The model here is missing a way of saying "task cancelled" as opposed
> to "task deleted". Maybe that doesn't matter.
"task cancelled" can be put in a "status" field.
This is how it is done in Evolution:
status : "string" # [not started | in progress | cancelled | done]
> Hope this helps,
Many thanks for your feedback.
--
Adi Roiban
Roman Yepishev
> On 12 ian., 02:59, Jonathan Lange <jonathan.la...@gmail.com> wrote:
> > On Tue, Jan 12, 2010 at 12:55 PM, Adi Roiban <adiroi...@gmail.com> wrote:
> > > {
> > > "_id": "id_of_this_document", # internal to CouchDB
> > > "_rev": "revision_for_this_document", #internal to CouchDB
> > > "record_type":
> > > "http://www.freedesktop.org/wiki/Specifications/desktopcouch/task",
> > > "record_type_version": "1.0",
> > > "title": "<task's title>",
> > > "content": "<task notes or aditional text>",
> >
> > In what format? HTML? Plain text? Wiki markup?
> I would say plain text.
> But instead of wiki markup, I think a subset of HTML would be
> preferred.
> For complex rendering, each app can store it's format in the
> application specific fields.
Hm... In case every application that needs "extended" set of
tags/attributes starts writing to their own "private" copy of data, we
may get completely different task content depending on what application
we are using.
Additionally, if we need to edit task then what content variant should
be considered as the "correct" one?
I may be exaggerating, though :)
John Carr
For reference, here are some fields that Nepomuk/Tracker store for
Calendaring and Tasks (shared schema):
http://library.gnome.org/devel/ontology/0.7/ncal-properties.html
That documentation can be a bit awkward to read if you aren't used to
RDF, I can post something in pydoc format if that would be useful.
John
Jonathan Lange
> On 12 ian., 02:59, Jonathan Lange <jonathan.la...@gmail.com> wrote:
>> On Tue, Jan 12, 2010 at 12:55 PM, Adi Roiban <adiroi...@gmail.com> wrote:
> [snip]
>> > In Evolution we have status and priority. Since they have arbitrary
>> > value I found it hard to put them as standard fields, as first we need
>> > to define some convention for these fields.
>>
>> This makes me want to know, what are you trying to achieve with this
>> standard?
>
> The main goal for defining a document format for tasks is to
> facilitate collaboration between various task related applications.
> For example manage tasks using GTG, have an overview in Gnome clock,
> track some of them using hamster-applet, read them from a lightweight
> phone app and have them somewhere on the web. Maybe this is a forced
> example, but right now each app store it's data in a different format
> and I would be happy to see some integration by default.
> Maybe I'm trying to solve an inexistent problem.
>
Well, standardization should be driven by actual use. Rather than
writing a standard now & making all of this happen later, it's better
to do things the other way around. After all, you have no idea what
you _really_ need until you've tried it.
Or as a wiser man than I said:
We reject: kings, presidents and voting.
We believe in: rough consensus and running code.
>> > For GTG I consider subtask (child/parent) and tags specific features.
>>
>> > For Tracks and Getting things done methodology we also have the notion
>> > of "contexts". A task can be in the inbox, next action, or to be done
>> > when on phone, at home or at office. This is somehow like a more
>> > generic
>> > status field, but I think this is a specific feature.
>>
>> GTG implements contexts with tags, basically. A context feature is a
>> strict subset of a tags feature.
> Thanks!
>
> Now the question is : Are tags/context a common feature of task
> management systems?
>
I don't know how you'd go about answering this. I'd just say "yes".
>> > Here it is:
>>
>> > {
>> > "_id": "id_of_this_document", # internal to CouchDB
>> > "_rev": "revision_for_this_document", #internal to CouchDB
>> > "record_type":
>> > "http://www.freedesktop.org/wiki/Specifications/desktopcouch/task",
>> > "record_type_version": "1.0",
>> > "title": "<task's title>",
>> > "content": "<task notes or aditional text>",
>>
>> In what format? HTML? Plain text? Wiki markup?
> I would say plain text.
> But instead of wiki markup, I think a subset of HTML would be
> preferred.
> For complex rendering, each app can store it's format in the
> application specific fields.
>
What does notes do here?
>> > "percentage": integer, #100 if this task is completed
>>
>> > "application_annotations": {
>> > "Evolution": {
>> > ...stuff specific to applications, nobody should rely on
>> > these...
>> > }
>> > }
>> > }
>>
>> The model here is missing a way of saying "task cancelled" as opposed
>> to "task deleted". Maybe that doesn't matter.
>
> "task cancelled" can be put in a "status" field.
> This is how it is done in Evolution:
> status : "string" # [not started | in progress | cancelled | done]
>
not-started, in-progress & done are all redundant with the date fields
you've defined above. The only reason for having a status field like
this is if the source database doesn't track dates.
>> Hope this helps,
> Many thanks for your feedback.
>
My pleasure.
jml
Stuart Langridge
>> The main goal for defining a document format for tasks is to
>> facilitate collaboration between various task related applications.
>> For example manage tasks using GTG, have an overview in Gnome clock,
>> track some of them using hamster-applet, read them from a lightweight
>> phone app and have them somewhere on the web. Maybe this is a forced
>> example, but right now each app store it's data in a different format
>> and I would be happy to see some integration by default.
>> Maybe I'm trying to solve an inexistent problem.
>
> Well, standardization should be driven by actual use. Rather than
> to do things the other way around. After all, you have no idea what
> you _really_ need until you've tried it.
Agreed on the last point. However, one of the major points of this
mailing list is to help put together the "rough consensus" part of
"rough consensus and running code". "Go away and do your own thing and
see what you need" isn't RC&RC, it's "NO consensus and running code" ;)
The point of bringing something up on this list isn't to totally nail
down every single specific, it's for review so people can chip in with
suggestions about what *their* task app does, as opposed to what the
format designer's task app does.
sil
Rodrigo Moya
> Hi,
>
> Bellow is a suggestion for a task format that can be used by apps
> using
> desktopcouch or couchdb as backend.
>
> I tried to used a common denominator for Evolution, Tasks, Tasque (eds
> based), GTG and Tracks (a ruby on rails webapp).
>
> In Evolution we have status and priority. Since they have arbitrary
> value I found it hard to put them as standard fields, as first we need
> to define some convention for these fields.
>
> There is also percentage field. I was thinking we can replace "done"
> with "percentage" and instead of true and false we can have 100 and 0.
> What do you think?
>
have to check it. The same for status, iirc
> For GTG I consider subtask (child/parent) and tags specific features.
>
> For Tracks and Getting things done methodology we also have the notion
> of "contexts". A task can be in the inbox, next action, or to be done
> when on phone, at home or at office. This is somehow like a more
> generic
> status field, but I think this is a specific feature.
> There is also a project field.
> Maybe we can define them in the "gtd" field for
> "application_annotations", but since they will store contexts and
> projects id, we need also to define a way for storing contexts and
> projects.
>
> For a bit of backround, I'm working at something that started as a
> desktop client for Tracks and now I'm switching to couchdb [1].
>
> I know some users of various other task apps complains their tasks are
> not displayed in the clock applet. Maybe with couchdb support for eds
> we
> can make this happens.
>
yes, the clock applet would show all tasks available through e-d-s. So
we just need to implement a calendar backend in evolution-couchdb for
this to happen
>
> Here it is:
>
> {
> "_id": "id_of_this_document", # internal to CouchDB
> "_rev": "revision_for_this_document", #internal to CouchDB
> "record_type":
> "http://www.freedesktop.org/wiki/Specifications/desktopcouch/task",
> "record_type_version": "1.0",
> "title": "<task's title>",
> "content": "<task notes or aditional text>",
> "create_date": "<creation date in UTC>",
>
we use creation_date on Tomboy notes IIRC, so it would be good to stick
with that
> "last_change_date": "<last modification date, in UTC>",
> "start_date": "<start date, in UTC>",
> "due_date": "<due date, in UTC>",
> "done_date": "<date when this task was finalized, in UTC>",
> "percentage": integer, #100 if this task is completed
>
> "application_annotations": {
> "Evolution": {
> ...stuff specific to applications, nobody should rely on
> these...
> }
> }
> }
>
looks good, but I would also add 'categories', which is in the ical
standard also, and we are adding it to contacts soon for grouping.
Also, priority comes from the ical standard, iirc again :) so it would
be good to add it also
cheers
Rodrigo Moya
>
> > There is also percentage field. I was thinking we can replace "done"
> > with "percentage" and instead of true and false we can have 100 and 0.
> > What do you think?
> >
>
> I think it's unnecessary. If you have a done_date column, you don't
> need a percentage to determine completeness, nor do you need a
> boolean.
>
it's done, yeah, it's not that useful, but it is when in progress
Jonathan Lange
I apologize if I came across as hostile. I was aiming at "helpful
scepticism" and may well have undershot.
jml
Stuart Langridge
>>> Well, standardization should be driven by actual use. Rather than
>>> writing a standard now& making all of this happen later, it's better
>>> to do things the other way around. After all, you have no idea what
>>> you _really_ need until you've tried it.
>>
>> Agreed on the last point. However, one of the major points of this mailing
>> list is to help put together the "rough consensus" part of "rough consensus
>> and running code". "Go away and do your own thing and see what you need"
>> isn't RC&RC, it's "NO consensus and running code" ;) The point of bringing
>> something up on this list isn't to totally nail down every single specific,
>> it's for review so people can chip in with suggestions about what *their*
>> task app does, as opposed to what the format designer's task app does.
>
> I apologize if I came across as hostile. I was aiming at "helpful
> scepticism" and may well have undershot.
No, no, quite the opposite! What I'm trying to foster is an atmosphere
where stuff gets mentioned before implementation, just so people don't
end up going down app-specific alleys with their schemas, but not an
atmosphere where we become the W3C and everything needs speccing to the
last ridiculous detail :) You weren't hostile at all!
sil
Jonathan Lange
I guess I let my own biases on organization get through. I can't
recall seeing anyone track the percentage completeness of tasks in a
way that actually helped. Just because I haven't seen it doesn't mean
they don't exist though. :)
If I were writing an app, I'd only include something like percentage
completeness if I were sure there was someone who wanted it (YAGNI and
all that). I don't know how well the principle applies to interchange
formats on distributed databases though.
jml
Jonathan Lange
Glad to hear it. That's certainly at atmosphere worth fostering. :)
jml