[Nepomuk] Please review: Nepomuk Desktop Search API

[Volker Krause]

On Tuesday 03 November 2009 11:26:20 Sebastian Trüg wrote:
> 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?

for the use with Akonadi I would very much prefer that. Akonadi acts as an 
intermediate layer between the query service and the client, to cache and 
aggregate results and make them available through the same interface 
as "normal" data. That is greately simplified if the D-Bus interface works 
without special datatypes, as we don't need to do the conversion in the 
Akonadi server itself then (which does not depend on KDE, so it can't even 
use the query libraray directly). Same for receiving the results from the 
query service btw.

> 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.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091103/5fa37889/attachment.sig>