[Nepomuk] Re: Akonadi-Nepomuk feeder port to SimpleResource api

[Sebastian Trüg]

On 07/27/2011 12:53 AM, Christian Mollekopf wrote:
> On Tue, 26 Jul 2011 13:42:51 +0200, Sebastian Trüg <trueg at kde.org> wrote:
> 
>> On 07/26/2011 01:18 AM, Christian Mollekopf wrote:
>>> I forgot to add:
>>>
>>> I extended the aneo ontology as discussed:
>>>
>>> aneo: {
>>>
>>>      aneo:AkonadiDataObject a rdfs:Class ;
>>>            rdfs:subClassOf nie:DataObject ;
>>>            rdfs:label "AkonadiDataObject" ;
>>
>> this is the ugly label type as used throughout NIE and friends. Those
>> labels have been waiting to be fixed for a long time. Its just that
>> there are so damn many....
>> Anyway, please give it a proper label, one that can be displayed to a
>> user. Something like "Akonadi item".
> 
> Alright, I actually changed it back from "Akonadi Entity" after having a  
> look at the NIE onto =P
> 
>>
>>>            rdfs:comment "used to identify akonadi entities (items and
>>> collections) created by the akonadi-nepomuk feeders" ;
>>>            nao:userVisible false .
>>
>> Hm, I am not sure if this is wise. This would mean that all akonadi data
>> objects are not visible to the user. I doubt you want that. ;)
>>
> 
> Well, the DataObject side should indeed not be visible, it's the  
> InformationElement side which is for the user
> and also where the userdata is.
> Not sure what the implications are for double typed resources.

You are right. A double-typed resource will be visible if the IE type is
visible.

Cheers,
Sebastian

>>>
>>>      aneo:akonadiItemId a rdf:Property ;
>>>          rdfs:label "Akonadi Item ID" ;
>>>          rdfs:comment "used to identify items created by the
>>> akonadi-nepomuk feeders (depreceated usage, use the AkonadiDataObject  
>>> type
>>> instead)" ;
>>>          rdfs:range xsd:string ;
>>>          rdfs:domain aneo:AkonadiDataObject ;
>>>          rdfs:subPropertyOf nao:identifier ;
>>>          nrl:maxCardinality 1 ;
>>>          nao:userVisible false .
>>> }
>>>
>>> This means that we can now limit queries with:
>>>
>>>      ResourceTypeTerm(Class(Vocabulary::ANEO::AkonadiDataObject()))
>>>
>>> which is nicer and has better performance(afaik) than the old:
>>>
>>>      query.addRequestProperty(Query::RequestProperty(Akonadi::ItemSearchJob::akonadiItemIdUri(),
>>> false));
>>
>> Exactly. This is starting to look really nice IMHO. :)
>>
> 
> Much better indeed =)
> 
>> Just a small side remark: It's so refreshing to have you working on the
>> Akonadi integration, you give the kind of feedback and ask the kind of
>> questions that push a project like Nepomuk. Thanks for that. :)
>>
> 
> Glad to hear that =)
> It's a pleasure working with you guys too.
> 
> 
>> Cheers,
>> Sebastian
>>
>>> Cheers,
>>> Christian
>>>
>>>
>>>
>>> On Sat, 23 Jul 2011 15:39:56 +0200, Sebastian Trüg <trueg at kde.org>  
>>> wrote:
>>>
>>>> without looking at the code yet:
>>>>
>>>> thanks a lot for doing this. And:
>>>>
>>>> On 07/22/2011 01:31 AM, Christian Mollekopf wrote:
>>>>> -replaced any usage of NepomukFast and with SimpleResource api
>>>>> -Removed the nepomukFeeder class, which was only needed because of the
>>>>> template stuff
>>>>> -added NepomukFeederUtils namespace which contains some helper  
>>>>> functions
>>>>> which don't belong into NepomukFeederAgentBase
>>>>> -removed everything else from NepomukFeederAgentBase which doesn't
>>>>> belong there and moved to the correct location (actually only
>>>>> findOrCreateContact that is)
>>>>
>>>> AFAICS there is no need for findOrCreateContact anymore. You simply
>>>> throw the contact at DMS multiple times and it will be merged properly.
>>>>
>>>>> -updated the documentation of NepomukFeederAgentBase
>>>>> -added the aneo ontology which is currently only used for the
>>>>> akonadiItemId (to mark the nepomuk resources as akonadi item)
>>>>> -added a copy of the nepomuk-dms to avoid a dependency on kde-runtime
>>>>> -added the SimpleResource convenience classes (In the future they  
>>>>> could
>>>>> be generated during the build, but that's not working at the moment)
>>>>
>>>> Actually we already have a review request for that. It is only a matter
>>>> of cleaning up some issues. Then the cmake macro is done.
>>>>
>>>>> -ported the calendar feeder to the SimpleResource api
>>>>>
>>>>> I did not touch the contact feeder so far as Martin Klapetek is  
>>>>> working
>>>>> on that.
>>>>>
>>>>> Also I noticed an occasional problem that the dms complains about
>>>>> cardinality of random parameters (i.e. the akonadiItemId),
>>>>> anyhow thats not critical for the moment as the feeders seem to work
>>>>> fine otherwise.
>>>>
>>>> Could you give an actual example, please?
>>>>
>>>>> Since there did not change a lot from the akonadi side I don't really
>>>>> expect much reviewing from this side (although all comments are
>>>>> welcome),
>>>>> but I'd be nice if Vishesh or Sebastian could have a look on how I  
>>>>> used
>>>>> the SimpleResource api.
>>>>> That would be specifically the Calendarfeeder and the
>>>>> NepomukFeederAgentBase::addItemToGraph,
>>>>> NepomukFeederAgentBase::addGraphToNepomuk functions.
>>>>>
>>>>> If it looks more or less ok, I'll commit so we can work from there.
>>>>
>>>> I will try to have a look these days.
>>>>
>>>> Cheers,
>>>> Sebastian
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk