On 29/01/13 18:21, Alexander Dutton wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Rob,
On 29/01/13 18:11, Rob Walpole wrote:
Am I doing something wrong here?
The short answer is that the inner SELECT is evaluated first, leading to
the results being calculated in the second case in a rather inefficient way.
In the first inner SELECT ?deselected is bound, so it's quite quick to
find all its ancestors.
In the second, all possible ?deselected and ?ancestor pairs are returned
by the inner query, which are then (effectively) filtered to remove all
the pairs where ?deselected isn't whatever it was BINDed to.
Here's more from the spec:
<http://www.w3.org/TR/sparql11-query/#subqueries>.
I /think/ ARQ is able to perform some optimisations along these lines,
but obviously not for your query.
Spot on.
If you remove the inner SELECT it should do better.
{ BIND(...) AS ?readyStatus)
BIND(...) AS ?deselected)
?export rdfs:member ?member .
?export dri:username "rwalpole"^^xsd:string .
?export dri:exportStatus ?readyStatus
OPTIONAL
{ ?deselected (dri:parent)+ ?ancestor
FILTER EXISTS {?export rdfs:member ?ancestor }
}
}
but technically this is a different query so it'll depend on your data
as to whether it is right.
http://www.sparql.org/query-validator.html
Andy
Best regards,
Alex
PS. You don't need to do URI("http://?";); you can do a straight IRI
literal: <http://?>
- --
Alexander Dutton
Developer, Office of the CIO; data.ox.ac.uk, OxPoints
IT Services, University of Oxford
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJRCBMZAAoJEPotabD1ANF7Fb0H/jeCedjfCIuhI2KTNETOcrVR
Gvl8N4k9ty4AN4F0xFKA3kcGCTR2CIpgz/hez6BM5s8mDqLc7ViNPXWxbUhb4kHh
fxVuuoYBr13VhGnyufvWFliFeT3xSVLO3eDUilzoja2pvH/Cx/sNQvcHbi2Ee+EX
MoWLyfSvtSGY2rXDmMAXvBz49wgk42mC2Bsr5ptNUfXWQjzz6BXp5SxTKADySBXG
Tm/DmqGRclHxw233I6EcB9lKfDytTosVugH1Yl0BGEHiFPL2/wkkB+AZiLIwCmb/
cy+Y8/I9PlD4onvYlDMRmP169HQVYt849Skx5/TnTyjMBBNIgQiE8+cj0a/oDc8=
=ZQec
-----END PGP SIGNATURE-----
