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 <[email protected]> wrote:
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
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
Nepomuk mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/nepomuk
