Sure thing.
1.)
I reduced the queries down so that they should (hopefully) be a bit more
readable.
The query with the OPTIONAL, which is sluggish, is as follows:
CONSTRUCT {?tempObservation0 oboe-core:ofEntity ?temp0 }
WHERE{
OPTIONAL {?xyz oboe-core:hasMeasurement ?object. }
?tempObservation oboe-core:ofEntity ?temp .
?temp rdf:type testing:Fir .
?tempObservation oboe-core:hasMeasurement ?tempMeasurement .
?tempMeasurement oboe-core:ofCharacteristic ?tempPlaceholder0 .
?tempPlaceholder0 rdf:type testing:Height .
?tempMeasurement oboe-core:hasValue ?tempPlaceholder1 .
?tempPlaceholder1 oboe-core:hasCode ?hCode .
?tempMeasurement oboe-core:usesStandard ?tempStandard .
?tempStandard rdf:type ?tempStandardType .
}
This query takes a very long time, but by simply removing the
OPTIONAL clause, it completes in less than a second. Also,
inside a SELECT query, the same WHERE statement, with the optional,
is nearly instant as well.
2.) The database is just over 100 MB, containing about 250,000 triples.
3.) Also, the FILTERS were a hacked-together workaround to avoid the
use of OPTIONALS, but the query above presents the same problem.
> 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.
>
