[Nepomuk] Akonadi-Nepomuk feeder port to SimpleResource api

[Christian Mollekopf]

Hey,

I just pushed the Nepomukfeederagent, so we can continue with merging the  
contactfeeder.

Cheers,

Christian

On Wed, 27 Jul 2011 08:06:42 +0200, Sebastian Trüg <trueg at kde.org> wrote:

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


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/