Request for Input: Storing Searches

[Volker Krause]

On Tuesday 06 September 2011 14:08:35 Jeroen van Meeuwen wrote:
> Georg C. F. Greve wrote:
> > Hi Volker,
> > 
> > Thanks a lot for your perspective and input.
> > 
> > There is one question which your mail did not answer for me: Which kind of
> > query language do you propose we use? 

well, I did not propose anything yet since I tried to figure out what the 
requirements for the query language would be, therefore all those questions in 
the first section

> > I understand Akonadi supports two
> > languages, SPARQL and something else, according to what Till once told me?

SPARQL is the primary one, but we just pass that through to Nepomuk (which 
itself just passes it through Soprano to Virtuoso), you do not want to 
implement a SPARQL query engine (probably not even the language parser) 
yourself, just like you don't write an SQL engine from scratch.

The other one is XESAM, mostly for historic reasons and due to the fact that 
we use that (passed through to Strigi) on WinCE (where Virtuoso is not 
available).

> > Would you advocate usage of SPARQL?

Only if you really need the extra power compared to Boolean logic and if you 
can rely on an existing SPARQL implementation everywhere. See also below.

> I think what Volker is referring to is the need for a query language that
> all clients can be or become compatible with.
> 
> This query language though must also facilitate the concept of different
> Kolab resources (LDAP, IMAP, Folders, messages with attachments, XML
> objects, it's contents, etc., etc.)
> 
> In other words, I suppose even a;
> 
>   "SELECT * FROM $x WHERE $y LIKE '%$z%';"
> 
> poses a number of problems in terms of what $x, $y and $z may/must be to
> cover all use-cases, let alone translate said "uniform" query language back
> into the actual search operation (against LDAP? IMAP?).

parsing and translating SPARQL is a nightmare, since it is more expressive 
than the Boolean logic based query languages you have in LDAP and IMAP, that's 
one of the unsolved problems in Akonadi. The idea there is rather to have a 
"translatable" intermediate language which covers the sub-set that actually 
can be translated and is used whenever you don't need the full expressive 
power of SPARQL. So far only a concept, no existing code yet.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110912/fe91d1c6/attachment.sig>