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

[Christian Mollekopf]

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.

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