On Mon, Feb 28, 2011 at 8:32 AM, Sebastian Trüg <[email protected]> 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 > [email protected] > https://mail.kde.org/mailman/listinfo/nepomuk > -- Cheers, Ignacio
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
