[Nepomuk] Re: Akonadi <-> Nepomuk interaction

Christian Mollekopf chrigi_1 at fastmail.fm
Wed Feb 23 18:11:23 CET 2011 

On Wednesday 23 February 2011 17:23:19 Sebastian Trüg wrote:
> 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.

Right, pimo:Document is really not needed in this case.

> 
> > 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.
> 
Ok, but every application is free to add any relation which might only apply 
to one special Thing type. So I agree that it is not a problem atm. but this 
might strike back later on, when nepomuk gets used by more application and the 
database is already filled with data.

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

You mean a usecase for the conversion of items?

Thats just the workflow i'd like to have. I collect some random information and 
store it to a note. At some point I decide that I want to do something based 
on this information so I create a todo containing all that information.
Since I don't need  the note and the todo containing the same information, I 
just convert the note into a todo.

The other usecases come along with this one. If I can create a todo from a 
note, I need to be able to convert it back (we can't just lock the data in 
that todo, can we?). Same goes for events, and converting todos <-> events is 
really just convenience instead of todo <-> note <-> event.

> 
> > 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.
> 
That would be perfect. So once that is working, i think this would be a much 
better solution.

Just one last question. Are properties resources themselfs, and can they be 
annotated?

Cheers,

Chris

> > 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
> 
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk

More information about the Nepomuk mailing list