[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Re: KDE/kdepim/akonadi/agents
From:       Sebastian =?iso-8859-1?q?Tr=FCg?= <trueg () kde ! org>
Date:       2009-09-23 9:39:29
Message-ID: 200909231139.29445.trueg () kde ! org
[Download RAW message or body]

On Wednesday 23 September 2009 09:09:19 Volker Krause wrote:
> On Tuesday 22 September 2009 01:23:03 Tobias Koenig wrote:
> > On Tue, Sep 22, 2009 at 03:24:42PM +0200, Sebastian Tr?g wrote:
> > > On Tuesday 22 September 2009 14:00:17 Volker Krause wrote:
> >
> > Hej Sebastian,
> >
> > > > However, there is a much larger problem here, related to the usage of
> > > > the NepomukFast classes: They require a delete + add approach when
> > > > updating information in Nepomuk for changed Akonadi items. However,
> > > > this will lose additional information that have been added to the
> > > > corresponding Nepomuk resource in the meantime, such as tags.
> > >
> > > actually you don't. The idea is to delete only the graph that has been
> > > created for the fast classes instead of the whole resource.
> > > I just checked. That is exactly that is already being done in
> > > NepomukFeederAgent::removeItemFromNepomuk. Thus, if the resource URI
> > > stays the same (which I was told it did in Akonadi) there is no
> > > problem.
> >
> > Just for clarification, that's the case because the tags, that has been
> > added by an external application, do not have the graph as parent the
> > PersonContact has, and therefor they are not deleted, right?
>
> well, the tag itself is of course not deleted, but the association with it
> is, since that's a property of the PersonContact resource which is deleted.

no.
The feeder creates a single graph. Nothing else is stored in there. Tagging a 
resource will result in a new graph with new metadata such as creation date.

> If I understand the above correctly, the graph should only cover the
> properties of the PersonContact resource that were added by the feeder
> agent, not the entire resource? And thus, the PersonContact object itself
> would not be deleted, only the affected properties? If that's indeed what
> is supposed to happen, then I can try to debug it or at least come up with
> a smaller testcase.

that is what should happen, yes.

> While we are at it, the nie.rdfs file doesn't seem to define the
> dataGraphFor property that's apparently used for the graph assosication,
> which means I cannot replace that with code from the generated vocabulary
> class in the queries to avoid typos and I also cannot see it in
> nepomukshell, which might help with debugging.

sorry, that property is still under discussion and not part of the ontology 
yet. :(

Cheers,
Sebastian

[prev in list] [next in list] [prev in thread] [next in thread]