Please review: Nepomuk Desktop Search API

[Sebastian Trüg]

Hi everyone,

in kdebase/runtime and also in kdebase/workspace/libs we have had 
libnepomukquery for quite some time now. Before Virtuoso I was never satisfied 
with the API. Now that Virtuoso allows us to do all queries with one big 
SPARQL expression while being fast I had another look and the result can be 
seen in *playground/base/nepomuk-kde/nepomukquery*.

I would like to get this API into kdelibs for 4.4 so now is the time to have a 
look.
The API will consist of 2 parts:

1. The Query and Term classes which are already done and need review now. 
These can be used to construct queries. But be aware that they are not 
modelled around SPARQL. This is intended to be the Nepomuk user query thing. 
However, since nesting is possible most queries we do on the desktop should be 
handled by that API.

2. The interface to the query service. This currently resides in 
kdebase/workspace/libs/nepomukqueryclient. I would like to port that to the 
new query API and clean it up a bit. The idea is to have one class that is a 
direct frontend to the query service providing persistent query folders. And 
one class that is a fire-and-forget query job. Comments?

One thing I am unsure about: previously the query service would receive Query 
objects via DBus. Since queries are nested I had to flatten a recursive design 
which makes for a weird signature and encoding code. Now I think that it might 
make more sense to simply use SPARQL queries only. After all Query can convert 
itself into SPARQL. Comments?

Another issue is that Query has the method resolveProperties which performs 
some queries itself to convert string fields as produced by the query parser 
into actual properties. Is Query the right place for this? Should this go into 
the query service or even the parser? I am unsure...

Please give feedback so app developers can finally query data easily in KDE 
4.4.

Cheers,
Sebastian