Paul,
A few questions:
1/ Do you have some readable versions of those queries?
2/ What size is the data?
3/ Why is it written with los of FILTERs? Grounded patterns
The presence of the OPTIONAL stops FILTER optimization - whether that's
because the optimizer is too dumb to know it can optimize though the
leftjoin (OPTIONAL) or it's the structure of the query, I can't tell.
FILTER (?predicate3 = oboe-core:hasCode || ?predicate3 = rdf:type)
?object2 ?predicate3 ?object3 .
OPTIONAL{ ?object3 rdf:type ?object4.
?object3 ?predicate3 ?object4 .}
Restricting on ?predicate3 outside and then
There look like places where property paths might help.
oboe-core:hasCode and rdf:type being equivalent seems odd modelling.
Andy
On 10/07/12 18:35, Jewell, Paul wrote:
Hello,
I seem to be having a problem utilizing certain functions inside of a
SPARQL query (specifically, OPTIONAL, BIND, and UNION). FILTER still seems
to be efficient enough, but isn't sufficient for the conditional logic that
needs to be done. The addition of any of these functions, even in very
simple contexts, reduces the speed to a standstill. I am not sure if I am
ordering the triples in an inefficient manner, or whether there is a better
way to use these functions, but they are currently too slow to be
practical.
First of all, this section of code does not use any OPTIONAL:
CONSTRUCT { ?ooo ?predicate1 ?object1 . ?object1 ?predicate2 ?object2 .
?object2 ?predicate3 ?object3}
WHERE{
FILTER (
?ooo = ?temporaryObservationVariable0)
FILTER( ?predicate1 = oboe-core:ofEntity || ?predicate1 =
oboe-core:hasMeasurement || ?predicate1 = oboe-core:hasContext ||
?predicate1 = rdf:type)
?ooo ?predicate1 ?object1.
?ooo oboe-core:hasMeasurement ?mmm .
FILTER( ?predicate2 = oboe-core:hasValue || ?predicate2 =
oboe-core:usesStandard || ?predicate2 = oboe-core:usesProtocol ||
?predicate2 = rdf:type )
?object1 ?predicate2 ?object2.
FILTER (?predicate3 = oboe-core:hasCode || ?predicate3 = rdf:type)
?object2 ?predicate3 ?object3 .
?temporaryObservationVariable0 oboe-core:ofEntity ?temporaryVariable0 .
?temporaryVariable0 rdf:type testing:Fir .
?temporaryObservationVariable0 oboe-core:hasMeasurement
?temporaryMeasurementVariable0 .
?temporaryMeasurementVariable0 oboe-core:ofCharacteristic
?temporaryPlaceholder0 .
?temporaryPlaceholder0 rdf:type testing:Height .
?temporaryMeasurementVariable0 oboe-core:hasValue
?temporaryPlaceholder1 .
?temporaryPlaceholder1 oboe-core:hasCode ?hCode .
?temporaryMeasurementVariable0 oboe-core:usesStandard
?temporaryStandardVariable2 .
?temporaryStandardVariable2 rdf:type ?temporaryStandardType2 .
}
The preceding code executes in just over a second, and returns the proper
results.
This following code, however, does use an OPTIONAL statement (and
constructs the related triple):
CONSTRUCT { ?ooo ?predicate1 ?object1 . ?object1 ?predicate2 ?object2 .
?object2 ?predicate3 ?object3. *?object3 ?predicate4 ?object4*}
WHERE{
FILTER (
?ooo = ?temporaryObservationVariable0)
FILTER( ?predicate1 = oboe-core:ofEntity || ?predicate1 =
oboe-core:hasMeasurement || ?predicate1 = oboe-core:hasContext ||
?predicate1 = rdf:type)
?ooo ?predicate1 ?object1.
?ooo oboe-core:hasMeasurement ?mmm .
FILTER( ?predicate2 = oboe-core:hasValue || ?predicate2 =
oboe-core:usesStandard || ?predicate2 = oboe-core:usesProtocol ||
?predicate2 = rdf:type )
?object1 ?predicate2 ?object2.
FILTER (?predicate3 = oboe-core:hasCode || ?predicate3 = rdf:type)
?object2 ?predicate3 ?object3 .
*OPTIONAL{ ?object3 rdf:type ?object4. ?object3 ?predicate3 ?object4 .}*
?temporaryObservationVariable0 oboe-core:ofEntity ?temporaryVariable0 .
?temporaryVariable0 rdf:type testing:Fir .
?temporaryObservationVariable0 oboe-core:hasMeasurement
?temporaryMeasurementVariable0 .
?temporaryMeasurementVariable0 oboe-core:ofCharacteristic
?temporaryPlaceholder0 .
?temporaryPlaceholder0 rdf:type testing:Height .
?temporaryMeasurementVariable0 oboe-core:hasValue ?temporaryPlaceholder1
.
?temporaryPlaceholder1 oboe-core:hasCode ?hCode .
?temporaryMeasurementVariable0 oboe-core:usesStandard
?temporaryStandardVariable2 .
?temporaryStandardVariable2 rdf:type ?temporaryStandardType2 .
}
The preceding graph (with differences in bold) is unusably slow, with the
only change being the OPTIONAL and the additional triple in CONSTRUCT. I am
not sure why this would be the case, but any help would be greatly
appreciated. Thanks again.
