Request for Input: Storing Searches
vkrause at kde.org
Mon Sep 12 17:26:54 CEST 2011
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
> > 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the format