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

[Ignacio Serantes]

On Mon, Feb 28, 2011 at 8:32 AM, Sebastian Trüg <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.

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

Cheers,
> Sebastian
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>



-- 
Cheers,
Ignacio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20110301/539643ce/attachment.htm