Fwd: [Kde-pim] Organizing calendaring items and notes
Christian Mollekopf
mollekopf at kolabsys.com
Wed Apr 4 10:53:50 CEST 2012
Hey,
I'd like to point you to a "discussion" (didn't get much input so far) on kde-
pim at kde.org, where I try to establish a more powerful way of organizing PIM
items.
Currently the possibilities are very limited and we need more powerful ways to
organize the items. As xCal doesn't provide those means and I need a way to
relate notes to todos, I came up with the below lined out x-related property.
I'd like to get this into the kolab-format as well.
Note that I already made the following changes to the below lined out
proposal:
"One flaw with the first proposal was that although we knew that there is a
parent Context by it's UID, we didn't know the name of the category if there
wasn't some other todo in the parent-category (therefore supplying it's name).
Therefore I added the "tree" element, so the whole tree up to the root (the
relevant part of it), can be embedded.
I also removed the last-modified date, as the one that iCal provides is enough
and we don't need one per Category."
The attached file is an example of the fixed proposal.
With my best regards,
Christian
---------- Forwarded Message ----------
Subject: [Kde-pim] Organizing calendaring items and notes
Date: Monday 19 March 2012, 10.31:03
From: Christian Mollekopf <chrigi_1 at fastmail.fm>
To: kde-pim at kde.org
Hey,
I'd like to get a discussion started on how we organize calendaring items and
notes. For Zanshin and Kolab we have already been thinking about new concepts
for quite some time, this is basically what we have come up with. I'm now
trying to get these concepts in a sensible way to the storage layer (for iCal
and notes).
== Zanshin Concepts ==
Because we felt that existing ways to organize todos and notes are not
sufficient/useful we have been thinking about new ways of structuring those.
They idea is to have some workflow concepts attached to the grouping, so we can
build a UI supporting that workflow, where i.e. a iCal category hardly has any
workflow in mind and therefore also is of little use (in my experience).
For Zanshin we have come up with three means to group/organize tasks and
notes.
* Projects:
A Project is really any todo which contains several actions. So
Projects are not always big tasks, but can be also very small. This is
important as projects are replacing subtodos. Any todo with subtodos becomes a
project. This way todos can be structured into a tree. A project can also
contain notes.
* Contexts:
A context is completely unrelated to projects and can be thought
of as a tag. The idea is that you can have contexts such as:
* office: you can do stuff for which you need your office
* traveling: easy todos you can do in a plane
* John Doe: All todos/notes you need when you are on the phone with John
A todo can belong to several contexts.
* Topics:
For notes there also exists "Topics". The idea here is that you can have
traditional notetaking in a tree-like structure. I.e. for a personal wiki.
Important is that a note can belong to several topics at the same time and
belong at the same time to a project and a context.
Projects and Contexs are GTD (Getting Things Done) Jargon and activity related
concepts. I.e. they express that you want to accomplish something (a project),
or that you want to do something within a certain context.
A Topic on the other hand is much closer to a simple tag, and simply provides
the means to build a knowledge base (like a personal wiki)
So far that has been zanshin specific, but I'd like to see if we can get that
to a level where it can be adopted by other kde projects. One reason for this
is also that Kolab would like to use a similar workflow to zanshin in the
webclient, and some consistency with Kontact would be nice =)
As these concepts are fairly unrelated to existing grouping possibilities, I
don't think there is a need right now to adopt these concepts. I'd like to
have the Terminology and modeling (how we store the information) fixed, so
other Kontact applications can adopt them.
== Current State in Zanshin ==
What we're doing right now in Zanshin is the following:
* Projects are parent relationships for todos, meaning any todo with subtodos
becomes a project. What's missing is the notes integration. Referencing by uid
should be easy enough, one problem is though that you need a todo to have a
topic with a project.
* Contexts are currently just another word for iCal categories. That breaks
already with renaming, so I don't think that's a good solution.
* Topics are nepomuk pimo-topics, currently only existing in nepomuk and not
yet written back to notes.
== The ideal solution ==
IMO a pretty ideal solution is the following:
We have Relations, each consisting of UID, ParentRelation, Name, last-modified
Date and Type.
Types are Projects/Contexts/Topics (for now).
The UID provides the means to match Relations, independent from the name, and
the name itself is just a label. The ParentRelation allows to build tree
structures. Finally the last-modified date helps to resolve simple conflicts,
such as when a Relation has been renamed.
These relations can then be indexed by the feeders and be made available
systemwide with nepomuk. Ideally we'd have a writeback service as well.
So this solution could integrate nicely with the desktop, while making it
possible to synchronize the structure directly through iCal or a notes format
to other computers.
== How to embed that information into existing formats ==
Projects being modeled as parent/child relationships of todos is IMO fine.
The notes format can be extended in order to allow links to projects.
Note how the iCal related-to property together with the referenced todos
summary and lastModified date is basically an implementation of such a above
lined out "Relation."
For Contexts I think we need to find an alternative to iCal categories. Using
plaintext tags to build structures, which then break as soon as you try to
rename one doesn't seem very sustainable to me. As I don't know of any tools
iCal provides us with to model such a relation, the only way I see is an x-
property:
<x-related>
<uid/>
<parent/>
<name>
<lastModified/>
<type/>
</x-related>
You get the idea. The same would be needed for the notes format.
Topics could be modeled using the same "related" property.
I know this proposed solution is not ideal, but the best I can think of. While
x-properties are certainly not overly interoperable, the proposed one is IMO
not adding any redundancy to existing stuff, doesn't clash with any existing
concepts, and gives us the means to have all the necessary information
synchronized through iCal and the notes format.
If we can settle for something like that, I would:
* Extend the akonotes format accordingly
* Extend KCalCore if required
* Add the indexing code to the feeders
* Make Zanshin use it
* Define the x-related property in the Kolab Format Specification 3.0
I'd be very interested if you
* find the concepts useful
* don't want to see these new concepts being used in Kontact
* think this is going in the right/wrong direction
* know a better way how to store the required information
* have any other comments =)
Cheers,
Christian
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
-----------------------------------------
Christian Mollekopf
Software Engineer
Kolab Systems AG
Zürich, Switzerland
e: mollekopf at kolabsys.com
w: http://kolabsys.com
pgp: EA657400 Christian Mollekopf--
-------------- next part --------------
<vcalendar>
<components>
<vevent>
<properties>
<uid>
<text>ProjectUID</text>
</uid>
<summary>
<text>My Project</text>
</summary>
<x-related>
<tree>
<uid>
<text>ParentCategoryUID</text>
</uid>
<name>
<text>My ParentCategory</text>
</name>
<tree>
<uid>
<text>CategoryUID</text>
</uid>
<name>
<text>My Category</text>
</name>
</tree>
</tree>
<type>
<text>Category</text>
</type>
</x-related>
</properties>
</vevent>
<vevent>
<properties>
<uid>
<text>SubtodoUID</text>
</uid>
<summary>
<text>My Todo</text>
</summary>
<related-to>
<text>ProjectUID</text>
</related-to>
<x-related>
<tree>
<uid>
<text>ParentCategoryUID</text>
</uid>
<name>
<text>My ParentCategory</text>
</name>
<tree>
<uid>
<text>CategoryUID</text>
</uid>
<name>
<text>My Category</text>
</name>
</tree>
</tree>
<type>
<text>Category</text>
</type>
</x-related>
</properties>
</vevent>
<components>
<vcalendar>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20120404/16ca778c/attachment.sig>
More information about the format
mailing list