Sadly I cannot give this bug a better title. It is caused by using a IN filter. To expose the bug one simply has to create one resource and try to query it with a query as follows:
select distinct ?r ?v4 where {
?r nao:prefLabel ?v4 .
FILTER(bif:contains(?v4, "'shared' AND 'desktop'")) .
?r a ?t . filter(?t in (pimo:Project, pimo:Task)) .
FILTER(!bif:exists((select (1) where {
<nepomuk:/res/2598d3b7-ae9f-40ca-9044-067e466ba936> ?p ?r .
}
))) .
}
The result set will be empty. However, removing the bif:exists filter OR just using a single type in the IN filter "solves" the issue:
select distinct ?r ?v4 where {
?r nao:prefLabel ?v4 .
FILTER(bif:contains(?v4, "'shared' AND 'desktop'")) .
?r a ?t . filter(?t in (pimo:Project)) .
FILTER(!bif:exists((select (1) where {
<nepomuk:/res/2598d3b7-ae9f-40ca-9044-067e466ba936> ?p ?r .
}
))) .
}
or
select distinct ?r ?v4 where {
?r nao:prefLabel ?v4 .
FILTER(bif:contains(?v4, "'shared' AND 'desktop'")) .
?r a ?t . filter(?t in (pimo:Project, pimo:Task)) .
))) .
}
IMHO this is an obvious bug as the two filters should not interfere with one another.
Used Virtuoso version: 6.1.3.3127-pthreads
The bug Is fixed in upcoming 6.1.4 release
I can still reproduce this in 6.1.4-rc1.3127 from 15.09.2011.