On 07/27/2011 12:53 AM, Christian Mollekopf wrote: > On Tue, 26 Jul 2011 13:42:51 +0200, Sebastian Trüg <[email protected]> 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 <[email protected]> >>> 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 > [email protected] > https://mail.kde.org/mailman/listinfo/nepomuk _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
