[Kde-pim] Proposal for a new pim application

[Stephen Kelly]

Christian Mollekopf wrote:
>> >
>> > According to what you said above, it should go the other way round,
>> > right?
>> >
>> > application <= akonadi <= nepomuk
>> 
>> Yes that's how I would envision it, but I think SemNotes works on data
>> stored in Nepomuk, not just metadata. I'm not certain though, and I
>> haven't had time to investigate more of that myself.
> 
> Yes, as far as i understand it, SemNotes stores the entire data in the
> Nepomuk database. Since the notes are usually rather small this is not a
> problem (laura checked once with the nepomuk people if the data should be
> stored in files better).
> 
> However, after thinking about it, i don't agree fully with you how the
> databases should work together (maybe because my lack of understanding...)
> 
> As I understand it akonadi is a PIM data storage/cache. It is therefore
> clear for me, that notes have to be stored in akonadi (where the notes
> finally are, on a central server or on the filesystem, is up to akonadi).
> 
> 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"?

> 
> Since akonadi has nothing to do with data relations (but only with data
> retrieval), i don't understand how notes, stored in akonadi, could be
> related to data outside of akonadi, if we access the data via akonadi.

Items from akonadi can be annotated with nepomuk data. We can run an Akonadi 
search job for items tagged with a particular nepomuk annotation for 
example. akonadi items can be associated with data outside of akonadi by 
associating with their nepomuk uri. As is my understanding anyway.

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

> 
> To say it in another way, i see akonadi and nepomuk as two layers:
> -akonadi as low level data storage
> -nepomuk as next higher level, containing all meta/relational data of the
> lower level data

The way I see it is applications will be interfacing on some level with both 
Akonadi and Nepomuk.

For example

Akonadi::Item item = getItemFromAkonadi();
NepomukAttribute *attr = item.attribute<NepomukAttribute>();
kDebug() << attr->tags();
kDebug() << attr->associatedObjects();

But there may be simpler ways for applications to do these things.

To keep things simple I'll respond to the other new emails in this thread 
here too:

> How is importing / exporting / sharing between several computers handled? 
> How can I access the data without an application? How transparently for 
> me it is stored?

The storage of stuff in Akonadi is as transparent as before akonadi. It 
depends on the resource, but in the case of local notes, they will be stored 
in a human readable way on the filesystem. In akonadi they are stored in a 
database, but that is only a cache or copy of the data, so you don't really 
care about that. The content of your notes will not be scattered around, but 
possibly some metadata about them will be stored separately (in nepomuk).

> It would be nice to have a developer's meeting (even just on IRC) some 
> time to talk about a common "notes" format that would allow KNotes, 
> basKet, and any other note application to share data.  I think there was 
> some discussion here about doing that (a month or two ago?) but I'm unsure 
> if anything came of that.  BasKet supports a lot of weird stuff (like 
> custom tags, hierarchical notes, embedded sound and video, internal 
> hyperlinks...) that other applications probably don't use or need.  It 
> would be nice if the "common message" mimetype could support some (or all) 
> of those features.  

Yes, that would be cool. How about we do that when trunk reopens for 4.5? 
We'll probably have less important stuff to do then.


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/