[Nepomuk] Re: Akonadi <-> Nepomuk interaction

Sebastian Trüg trueg at kde.org
Tue Feb 22 14:31:10 CET 2011


Hi Chris,

On 02/22/2011 02:23 PM, Christian Mollekopf wrote:
> On Tuesday 22 February 2011 11:41:27 Sebastian Trüg wrote:
>> Hi Chris,
>>
>> I always figured that there would be only two resources:
>> 1. The main indexed resource created by the feeder
>> 2. The pimo:Thing that contains all the annotations and relations.
>>
>> IMHO there is no need for a third resource which is maintained by your
>> app. The only problem I see here is the update by the feeder since that
>> should maintain the relation to the pimo:Thing.
>> But I think that could be handled by the feeder. It simply needs to
>> handle updates differently than a simple delete+add. Instead it should
>> make sure the resource URI is reused and the relation to the pimo:Thing
>> is kept.
> 
> The problem with using the Resource created by the feeder is that it is not 
> clear if my app or the feeder is first to create it, so I would have to make 
> sure that also if I create the Resource first, the feeder reuses it.
> But I guess that should be possible.

AFAIK Akonadi uses a dedicated property to identify their resources. You
could reuse that.
I suppose it would be best to put that into shared code somehow. That
way it can be assured that the resources are reused.

> Further I also have to see when to delete the Thing, as sometimes I wan't to 
> reuse it (when converting the item).
> 
> What I don't really get: for one specific note there should only be one Thing, 
> right? So If I create the Thing and assign it to the Resource created by the 
> Feeder, will the feeeder delete the Thing, when he deletes the Resource or 
> will I have to do that?
> 
> The ownership of Resources/Things is not yet really clear to me....

The feeder does not delete the things. This is something that is not
defined yet. It could of course be very easy to add thing deletion to
the feeder.

Cheers,
Sebastian

>>
>> Once that works you might only have to update the pimo:Thing type. I am
>> not sure if this should also be done in the feeder or if your app should
>> do that.
>>
>> Cheers,
>> Sebastian
>>
>> On 02/19/2011 02:33 PM, Christian Mollekopf wrote:
>>> Hi,
>>>
>>> As I don't feel that there is a real solution how to handle notes and
>>> kcal items in akonadi and nepomuk.  I'm going to explain here how I plan
>>> to implement the interaction between aknoadi::items and
>>> nepomuk::resources in my application.
>>>
>>> I know there is some work going on in Baske/Semnotes/Kjots and the issue
>>> has been discussed before focusing on notes. But as I couldn't find a
>>> real conclusion on the ml, and since I have some more
>>> requirements/usecases, I think it is time to continue this discussion =)
>>>
>>> Usecase:
>>> My application manages Incidences (todos/events) and Notes using the KCal
>>> and Akonotes resource in akonadi. (I do believe that storing those in
>>> akonadi is the right way, and storing them in nepomuk is not a valid
>>> option for various reasons).
>>>
>>> I organize all items using PIMO::Topics (instead of collections inside
>>> akonadi). Further I plan to add functionality to associate random data
>>> (files, websites, mails, ...) with the topics and/or a certain
>>> Akonadi::Item using Nepomuk.
>>>
>>> One functionality which showed some further requirements, is converting
>>> i.e. a note to an incidence. This made me realize that I'm normally
>>> actually tagging the Content of the note/event/todo and not i.e. todo
>>> itself.
>>>
>>>
>>> All of this lead me to the following conclusion how to handle those items
>>> in Nepomuk:
>>>
>>> For each Akonadi::Item I create a Nepomuk::Resource (Content Resource) of
>>> the type NFO:HtmlDocument (since it is only the content, not the task
>>> itself) with an identifier consisting of an application-specific prefix
>>> + akonadi::item url (to avoid conflicts with the items generated in the
>>> nepomukfeeder agents). For all annotations I use the pimoThing (Content
>>> Thing), on which I set the type PIMO:Document. (See the attached diagram
>>> for reference)
>>>
>>> So if I convert the item i.e. from note to todo, which means deleting the
>>> old Akonadi::Item and creating a new one, I simply set the new
>>> Nepomuk::Resource (created with the new akonadi::item url) as a
>>> groundingOccurence of the existing Pimo:Document. This way all
>>> annotations remain untouched.
>>>
>>> The obvious downside of this is, that other applications do not profit
>>> from annotations made in my application, and I am not yet sure how to
>>> overcome this. Maybe I can annotate the Nepomuk::Resource which has been
>>> created by the feederagent with the Pimo:Document of the same item, and
>>> therefore implicitly share the annotations?
>>>
>>> Also I am not storing any real content in those Resources, I use the
>>> Content Resource and the Content Thing only to annotate the content of
>>> the item. For fulltext search or similar things I expect to use the
>>> items created by the FeederAgent (meaning I will have to create a
>>> feederagent for notes as well).
>>>
>>>
>>> Anyhow, this solution doesn't seem ideal, so I'd be interested how you
>>> guys intend to solve the issues. Especially what Resources you create
>>> and how you tell them apart from the ones created by the Feederagents.
>>>
>>> Also are you using Nepomuk purely internal, or do you actually create
>>> content which could be reused by other applications?
>>>
>>> Cheers,
>>>
>>> Chris
>>>
>>> PS: Some background info on my app in case youre interested
>>> http://gitorious.org/notetaker/pages/Home
>>>
>>>
>>>
>>> _______________________________________________
>>> Nepomuk mailing list
>>> Nepomuk at kde.org
>>> https://mail.kde.org/mailman/listinfo/nepomuk
>>
>> _______________________________________________
>> Nepomuk mailing list
>> Nepomuk at kde.org
>> https://mail.kde.org/mailman/listinfo/nepomuk
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
> 


More information about the Nepomuk mailing list