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