[Kde-pim] Proposal for a new pim application

[Christian Mollekopf]

On Friday 11 December 2009 16:09:14 Stephen Kelly wrote:
> 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"?

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

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

Thats kind of the other way round as i understand it.
I don't know if my understanding, that these two databases can be seen as two 
layers (with akonadi on the lower level), is correct, so I will have to 
investigate more.

If it works with this two layers, ideally the application should basically 
only interact with nepomuk (it would just have to tell nepomuk to store the 
data in akonadi).

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

Also possible, i feel I don't yet fully grasp the concepts of the two 
databases =/
But anyway, an interesting area for some research =)

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