[Nepomuk] Re: Akonadi <-> Nepomuk interaction

Sebastian Trüg trueg at kde.org
Wed Feb 23 17:23:19 CET 2011


On 02/23/2011 01:45 PM, Christian Mollekopf wrote:
> On Tuesday 22 February 2011 17:22:17 Sebastian Trüg wrote:
>> On 02/22/2011 04:04 PM, Christian Mollekopf wrote:
>>> I agree that for a note I cannot give a real example since a note has
>>> only the text content as property.
>>>
>>> I think the issue only exists for things like Todos or Events where we
>>> have additional properties which are not applicable to all Items.
>>>
>>> I'm still not completely clear for myself if it makes sense to i.e.
>>> convert a note to a todo, since we could also add the note to the todo
>>> as property. The problem is that this is not how todos/events work in
>>> akonadi, and also not how they are modeled in the ncal ontology.
>>
>> Well, that is why you have pimo. You relate the pimo things together
>> while the NCAL entities stay unchanged. At least that is the general
>> idea. Of course it is not entirely implemented like that since Akonadi
>> for example tags NCAL resources directly. But still...
>>
> 
> Then we probably should change that =) I'm going to the akonadi meeting on 
> friday, so if you already know in which parts of akonadi this is done I could 
> have a talk with some of the guys (If they are there as well =), or just fix it 
> myself.
> 
>>> So if we decide that it should be possible to convert i.e. a todo to an
>>> event, there are some annotations which apply to the content in general
>>> and some which apply only to the todo/event.
>>
>> Converting a TODO into an Event sounds like a really strange use case to
>> me. But maybe I am being close-minded here.
> 
> Well, it IS a strange usecase. But creating an event from a note is a valid 
> one. And creating by accident a todo instead of an event is a valid usecase to 
> convert a todo to an event ;-)
> 
>>
>>> If i create a todo and collect files and websites to the topic of todo,
>>> but then decide that i need actually an event or a note with this
>>> information and not a todo, I will have to convert the item to a note or
>>> event. In this case I would of course want to keep all the files which I
>>> related to the todo, as they are basically part of the content. But I
>>> wouldn't want to keep a location which is associated to the todo if I
>>> convert it to a note.
>>
>> Ideally the location would be part of the NCAL resource while the rest
>> of the relations (the ones manually generated on top of what was
>> extracted from Akonadi) would be part of the related pimo thing.
>> If you want to keep it on the pimo level it is perfectly valid to have a
>> pimo thing that is both an event and a todo or a topic. With some
>> combinations this might feel weird but conceptually it is perfectly
>> correct.
> 
> I'm going to refer to some chapters of "PIMO Nepomuk Recommandation v1.1"  in 
> this section.
> 
> While possible to have several types for the same thing, it is at least not 
> recommended according to  "6.11 Setting the Class of a Thing", no?
> Maybe I'm also confusing type and class...

No, you are right. Having a thing that is both a task and an event is a
bit weird.

> So what youre saying is: 
> I would have a pimo:Thing which has the type pimo:document and 
> pimo:task for a todo. When I convert it to a note, I have to removed the 
> pimo:task type and add the pimo:note type instead.

I don't see the need for the pimo:Document type. Other than that: yes.
Or you simply leave the type as pimo:Thing for now and search for the
ncal resources instead.

> Further I also have to figure out which relations applied to the thing are only 
> relevant for the pimo:task and remove those.
> Correct? 

correct. But there are none at the moment unless you use TMO. But that
is basically copying stuff over from the indexed Akonadi resource and I
think that should be avoided.

> I really think it would be just very diffcult to figure out if relations are 
> part of the content or the item itself.
> Therefore I still think it would be good to separate the Things of the item 
> itself and the content.

I still do not see a real use case here. You mention a location and an
accidental creation of a task when an event was required. Could you
provide an actual use case?

> Also as described in "11.2 Changing the Type of a Thing" we must avoid having 
> invalid statements when changing a type of an item, which would be exactly 
> what could happen here.
> 
> Another possible solution:
> 
> For example a Thing of the type pimo:Document for the content with a 
> pimo:isPart relation to the Thing of the todo itself. 
> I do not know however if there is something like an implicit relation, meaning 
> that if you are searching for documents related to the todo Thing you still 
> find the relations of the content Thing which pimo:isPart of the todo Thing.
> 
> Do you know if that could work?

That could work. Sadly we do not have generic support for that relation
yet. I would very much like to have that in the query framework but am
not entirely sure yet on how to integrate it.
Basically it would be nice to automatically handle pimo:isPartOf and
nie:isPartOf.

> Sorry for being so tenacious. I just think it is important model the things 
> right, in order to be useful across applications.

No need for being sorry. I am very happy that you want to create proper
data which is not easy at all - sadly. I have similar problems from time
to time.
And as you can see I have no final answer for you on the Akonadi matter.
Thus, a discussion like this is the only way.

Cheers,
Sebastian

> And thanks for all the input, it's great having some guidance here =)
> 
> Cheers,
> 
> Chris
> 
> 
>>
>> Cheers,
>> Sebastian
>>
>>> Hope that makes it a bit clearer what I mean.
>>>
>>> Cheers,
>>>
>>> Chris
>>>
>>> On Tuesday 22 February 2011 15:26:11 Sebastian Trüg wrote:
>>>> I am confused - you want to annotate the text and not the note? But what
>>>> is a note if not its text? I think I see the issue for something like an
>>>> event though...
>>>> Could you give a real example please.
>>>>
>>>> Cheers,
>>>> Sebastian
>>>>
>>>> On 02/22/2011 02:53 PM, Christian Mollekopf wrote:
>>>>> Just one thing which I forgot.
>>>>>
>>>>> The point is that I need to annotate the content (text) of the
>>>>> Todo/Note not the Todo/Note itself.
>>>>>
>>>>> I annotate the content with pimo:Topics and random items like files,
>>>>> other akonadi items, etc.
>>>>> If I would simple set the Thing which I annotated with those items as
>>>>> the Thing of the Todo/Note directly, another application could add
>>>>> annotation to the Thing i.e. a location for a Todo.
>>>>> Now that annotation is really only valid for the Todo not the content
>>>>> in general. So if that item is converted to a Note, the location
>>>>> annotation should not be kept, while all the associated files, etc and
>>>>> pimo:Topics are still valid as they are actually annotations of the
>>>>> content (text).
>>>>>
>>>>> That was also why I used the separate resource (for annotating the
>>>>> content of the todo/note).
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Chris
>>>>>
>>>>> On Tuesday 22 February 2011 14:31:10 Sebastian Trüg wrote:
>>>>>> 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.
>>>>>
>>>>> In this case
>>>>>
>>>>>> 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
> 


More information about the Nepomuk mailing list