[Kde-pim] Nepomuk feeder queuing problem

[Christian Mollekopf]

> > > This requested property never makes it to the server however. I suspect that 
> > > it is because the dbus interface changed, because there is yet another copy of 
> > > that nepomuk code in the akonadi server.
> > 
> > true, request properties are transferred in a different way. They are
> > essentially ComparisonTerm variableNames with a dedicated prefix. It is
> > a bit hacky.
> > 
> 
> I suppose you're referring to the "reqProp1" names which are required in
> the sparql query for the results bindings?
> That wouldn't be a problem if we could use the same codebase everywhere
> (nepomuk-core).
> 
> Meanwhile I found part of the problem in the queryserviceclient.cpp copy
> in the akonadi-server. It passed an always empty QHash<QString,QString>
> as requestedPropertyMap.
> Now that I corrected this I get back one result, with the correct
> property url, but the supplied Soprano::Node is still invalid (so I
> can't get the value of the property).
> The dbusoperators look ok so I'm a bit lost. Note that QUrl's are used
> in the akonadi-server copy instead of Nepomuk::Types::Property, but
> since that seems to be for the serialization of the property uri, which
> is transported okay, that shouldn't be the problem, right? Somehow the
> Soprano::Node marshaling fails as far as I understand.
> 

I finally found the problem and could work around it by adding a hack
(hardcoding the "reqProp1" parameter). Now the actual query is the
remaining problem:

select distinct ?r ?reqProp1
(bif:concat(bif:search_excerpt(bif:vector('akonadi/server/src/search/nepomuksearchengine.cpp'),
?v8),bif:search_excerpt(bif:vector('akonadi/server/src/search/nepomuksearchengine.cpp'),
?v4))) as ?_n_f_t_m_ex_ where { { ?r
<http://akonadi-project.org/ontologies/aneo#akonadiItemId> ?reqProp1 . {
?r
<http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#plainTextMessageContent>
?v2 . ?v2 ?v3 ?v4 . ?v3
<http://www.w3.org/2000/01/rdf-schema#subPropertyOf>
<http://www.w3.org/2000/01/rdf-schema#label> . FILTER(bif:contains(?v4,
"'akonadi/server/src/search/nepomuksearchengine.cpp'")) . } UNION { ?r
<http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> ?v5
. ?v5
<http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#plainTextMessageContent>
?v6 . ?v6 ?v7 ?v8 . ?v7
<http://www.w3.org/2000/01/rdf-schema#subPropertyOf>
<http://www.w3.org/2000/01/rdf-schema#label> . FILTER(bif:contains(?v8,
"'akonadi/server/src/search/nepomuksearchengine.cpp'")) . } . ?r a
<http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#Email> . } .
?r
<http://www.semanticdesktop.org/ontologies/2007/08/15/nao#userVisible>
?v1 . FILTER(?v1>0) . }

The above is the query I get when searching with kmail in the body of
the message.

I can find the said email by querying for:
select ?r where { ?r nmo:plainTextMessageContent ?label . ?label
bif:contains "'akonadi/server/src/search/nepomuksearchengine.cpp'" . }

So it is available.

If you can spot the problem, tell me.

Since today is final tagging, can these fixes still be committed for 4.8
or is it already too late (if not , until when do I have time)?
The query might need an adjustment in kmail, the rest of the code is in
akonadi-server.

Cheers,
Christian



> > > The actual query is built in kdepim/mailcommon/searchpattern.cpp (in 
> > > asSparqlQuery()), but I don't think it's a problem of the query.
> > > 
> > > Any help with fixing the dbus interface is greatly appreciated as I failed so 
> > > far to fix it. Simply updating the interface didn't work because I'd have to 
> > > copy almost complete libnepomukcore. We really need that separate nepomuk 
> > > repository....
> > 
> > Actually I implemented backwards-compatibility a long while ago but
> > never got any feedback on it from the kde-pim team. Thus, it just
> > gathers dust in branch nepomuk/legacy-result. I am not sure about the
> > state of it.
> > 
> 
> Where is it? Coldn't find it in runitem/kdelibs/nepomuk-core...
> And what exactly does it implement? Support for the query mechanism used
> in the akonadi server?
> 
> If it's not possible to get rid of the kdelibs/kde-runtime copies of
> nepomuk for 4.9 then I suggest that we start using nepomuk-core anyways
> for projects like kdepim.
> Copying those interfaces and parts of nepomuk around is just a huge
> waste of time, and having two copies of nepomuk is still better than not
> knowing how many there are at all...
> 
> Cheers,
> Christian
> 
> > Cheers,
> > Sebastian
> > 
> > 
> _______________________________________________
> KDE PIM mailing list kde-pim at kde.org
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/
> 
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/