[Nepomuk] Re: Advances in my alternative query system and several questions

[Sebastian Trüg]

On 03/01/2011 04:49 AM, Ignacio Serantes wrote:
> On Mon, Feb 28, 2011 at 8:32 AM, Sebastian Trüg <trueg at kde.org
> <mailto:trueg at kde.org>> wrote:
> 
>     On 02/27/2011 02:32 PM, Ignacio Serantes wrote:
>     > Hi!
>     >
> 
>     That is why I wrote the query API. It handles all that for you and is
>     optimized. There is no need for you to try to solve all the SPARQL
>     problems again.
> 
> 
> I will add support to API in my query system so all this questions will
> be solved analyzing sparql queries created with the API.
> 
>     > But the really big problem is with relation ontologies like
>     nao:hasTag.
>     > In this particular case query is "?x nao:hasTag ?y . ?y nao:identifier
>     > ?z . FILTER(?z)", so you need a inner join and you do the real
>     filter in
>     > nao:identifier but this is not applicable to all relations. Some light
>     > about this stuff are welcome.
> 
>     Actually the query should look like this:
>     ?r nao:hasTag ?t . ?t nao:prefLabel ?l . ?l bif:contains "foobar" .
>     And that is why I can only stress: use the query API. This is why I
>     wrote it. :)
> 
> 
> Yes, this was my first approach but when I found how to obtain
> identifier and I prefer to use it for unicode security and because
> identifier looks like a more generic property than prefLabel. In my test
> results sets are the same so I continue to use identifier.

identifier is not necessarily always set. preflabel is the preferred
property.

> About bif:contains, I do some test with filter() and bif:contains and I
> found that the second has penalty costs. I wrote the same query with
> both versions and found that results are always fast using filter() so I
> stop using bif:contains. Probably this was casual but, for precaution I
> write my builder using Filter().

filter is indeed faster if the number of possible results is small. So
for querying tags it might indeed be better.
As soon as you query a lot of resources filter becomes very very slow.

Cheers,
Sebastian