[Nepomuk] Status report of the Nepomk query parser

[Denis Steckelmacher]

On 06/18/2013 03:57 PM, Ignacio Serantes wrote:
> Hi
>
> Ok, I will show the results because those are the important in this case
> but natural language is not particularly accurate for querying data and,
> considering there is no natural language alternative to SQL in more than
> 3 decades and personal assistants like SIRI sometime are not very smart,
> I not sure as you about your assertion relative to natural language :).
>
> On the other side I have a warning about Nepomuk::Query. I tried to use
> when I started developing Nepoogle and I discovered severe performance
> flaws with several terms (more than 4 or 5) causing virtuoso-t consuming
> 100% because long SPARQL queries without subqueries.
>
> I did not test it in last two years but considering
> Nepomuk2::Query:QueryParser() has the same problem probably this was not
> be solved. If you don't test it I think you must only to confirm it's
> working as expected.
>

Hi,

Thanks for the advice, the parser is now able to produce actual 
Nepomuk2::Query::Query objects and I will have a look at the SPARQL 
queries it produces.

I don't know much of SPARQL, but if the performance really is too poor, 
maybe I can try to optimize the queries produced by Query. The parser 
may have information that the Query class doesn't know, and that could 
be used to speed up the query. For instance, the parser will have a 
cached list of the existing tags, so the SPARQL query does not have to 
make a joint on the tags, it can match a constant URI.

But, as far as I know, even SQL is slow when there are many filters 
spanning multiple tables. I don't know if speeding-up these queries is 
even possible.

Denis Steckelmacher.