[Kde-pim] Proposal for a new pim application

[Stephen Kelly]

Christian Mollekopf wrote:
>> > Nepomuk is responsible to figure out relations between data, and does
>> > not care at all where the data is stored (but it is also not a storage
>> > container itself).
>> >
>> > Therefore the only proper way to handle notes with akonadi and nepomuk
>> > would be (as i understand it), that notes are always stored directly in
>> > akonadi, but the retrieval goes always via nepomuk (which gets the data
>> > from akonadi).
>> 
>> I don't follow the connection I'm afraid. You're saying "nepomuk stores
>> relations between data, therefore all access should be through nepomuk"?
> 
> What i wanted to say is:
> The "core data", which would be the text in the case of a note, is kept by
> akonadi. I see nepomuk as a second layer (above akonadi), providing some
> additional data to the pure text (tags, associated data, etc.). This way
> akonadi wouldn't have to know about nepomuk.

I think in reality applications will know about both Akonadi and Nepomuk. 
They are more like pillars than layers. I don't think one can abstract away 
the other.

> I assume that the containers in akonadi are not really suitable for
> providing also the data from nepomuk, while afaik nepomuk has containers
> which can hold the "core data" (from akonadi) plus the additional
> information from nepomuk (i.e. PIMO:Note).
> This way we wouldn't have to have a custom container in our own software
> which can hold both data, but we could use directly the ones provided by
> nepomuk.

Currently in akonadi solutions being created, the containers of the "core 
data" are the ones most suitable to the applications, like KMime::Message 
for emails and KABC::Addressee for contacts. We have so far had successes 
with using Attributes as I wrote below and the SPARQL search interface to 
tie data between nepomuk and akonadi, and retrieve it through akonadi via 
search jobs. If you can direct me to the docs of the nepomuk containers I 
would be interested in seeing them though. Is it concrete c++ classes you 
are referring to or the PIMO ontologies?
 
>> > Therefore i don't think that a virtual collection with the nepomuk
>> > results in akonadi can be a solution, since it excludes the akonadi
>> > data from the relational stuff.
>> >
>> > Of course notes could be also handled purely within akonadi, without
>> > using nepomuk at all, this would just remove all the advantages from
>> > nepmuk, and make the notes completely stupid about any relations.
>> 
>> I don't think this is the case. There is already a nepomuk tag resource
>> for example which can show any akonadi items organized by tag.
> Ok but then we have this situation:
> akonadi => nepomuk => akonadi => application
> 
> instead of:
> akonadi => nepomuk => application

Akonadi 
   ||     > application
Nepomuk

Akonadi is designed for retrieval of PIM data, so it's not something that it 
would make sense to abstract away. 

All the best,

Steve


_______________________________________________
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/