Yes, I tried these commands and the graph still persists.
Tracy M. Safran
Programmer Analyst - EVS support
Frederick National Laboratory for Cancer Research
Leidos Biomedical Research, Inc.
Ph: 240-276-5172
tracy.saf...@fnlcr.nih.gov
On 9/23/16, 8:29 PM, "Hugh Williams" wrote:
Hi Tracy,
good evening;
> On 2016-09-28, at 14:44, Pantelis Natsiavas wrote:
>
>
are your filters
> FILTER (isLiteral(?variableJ) && ?variableG = ?variableJ) .
> FILTER (?variableE = ?variableH)
>
...
>FILTER (?variableE = ?variableN) .
on domains which require an “=“ comparison,
I've also been dealing with optimizing SPARQL queries lately, and have
gotten some impressive performance boosts out of subqueries. If there are
parts of your query that can be isolated in order to reduce the solution
space early on, there might be a benefit in putting those criteria in a sub
query
Hi Pantelis:
Do you really need to use the REGEX ignore case feature?
If not, you can substitute some of your FILTER expressions by BGPs.
For example, replacing:
GRAPH {
?variableI
?variableJ .
?variableI
?variableK .
FI
Another observation I note is that there is a common factor within each
UNION:
GRAPH {
?variableA a graphA:ClassA .
?variableA graphA:propertyA ?variableB .
?variableB dcterms:title ?variableC .
?variableA graphA:propertyB ?variableD .}
Could this be fact
Hi Pantelis,
One thing that struck me as an other virtuoso user is
the joins in the filters.
e.g.
FILTER (?variableE = ?variableH)
I think if you remove all instances of ?variableH with ?variableE
you should get better results.
Hope that helps.
Regards,
Jerven
On 28/09/16 14:44, Pantelis Nat
Hi everybody.
I have a rather complex SPARQL query, which is executed thousands of times
in parallel threads (400 threads). The query is here somewhat simplified
(namespaces, properties and variables have been reduced) for readability,
but the complexity is left untouched (unions, number of graphs
