Could you send complete, unbroken queries please? I fixed up the last ones.
What's the data? How much etc?
Andy
On 31/01/13 10:09, Rob Walpole wrote:
Ok, just looking at this problem again. It seems that even without the
nested select the binding still causes a problem in the main body of the
query. So...
DESCRIBE ?ancestor
WHERE
{
BIND(<
http://nationalarchives.gov.uk/dri/catalogue/exportStatus/ReadyToProcess>
AS ?readyStatus)
?export rdfs:member ?member ;
dri:username "dfreeman"^^xsd:string ;
dri:exportStatus ?readyStatus .
OPTIONAL
{
BIND(<
http://nationalarchives.gov.uk/dri/catalogue/item/c2433752-b1e5-44e4-a271-c36d29aa6a3b>
AS ?deselected)
# get the ancestors of the deselected item
?deselected (dri:parent)+ ?ancestor .
# get the ancestor that is a member of the export list
FILTER EXISTS { ?export rdfs:member ?ancestor } .
}
}
...returns is seconds whereas...
DESCRIBE ?ancestor
WHERE
{
BIND(<
http://nationalarchives.gov.uk/dri/catalogue/exportStatus/ReadyToProcess>
AS ?readyStatus)
BIND(<
http://nationalarchives.gov.uk/dri/catalogue/item/c2433752-b1e5-44e4-a271-c36d29aa6a3b>
AS ?deselected)
?export rdfs:member ?member ;
dri:username "dfreeman"^^xsd:string ;
dri:exportStatus ?readyStatus .
OPTIONAL
{
# get the ancestors of the deselected item
?deselected (dri:parent)+ ?ancestor .
# get the ancestor that is a member of the export list
FILTER EXISTS { ?export rdfs:member ?ancestor } .
}
}
...just hangs. Any more thoughts?
Thanks
Rob
On Tue, Jan 29, 2013 at 7:46 PM, Rob Walpole <[email protected]> wrote:
Cool, thanks guys, will give this a try tomorrow :-)
Rob
On Tue, Jan 29, 2013 at 7:36 PM, Andy Seaborne <[email protected]> wrote:
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<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<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/
iQEcBAEBAgAGBQJRCBMZAAoJEPotab**D1ANF7Fb0H/**jeCedjfCIuhI2KTNETOcrVR
Gvl8N4k9ty4AN4F0xFKA3kcGCTR2CI**pgz/**hez6BM5s8mDqLc7ViNPXWxbUhb4kHh
fxVuuoYBr13VhGnyufvWFliFeT3xSV**LO3eDUilzoja2pvH/Cx/**sNQvcHbi2Ee+EX
MoWLyfSvtSGY2rXDmMAXvBz49wgk42**mC2Bsr5ptNUfXWQjzz6BXp5SxTKADy**SBXG
Tm/**DmqGRclHxw233I6EcB9lKfDytTosVu**gH1Yl0BGEHiFPL2/wkkB+**AZiLIwCmb/
cy+Y8/**I9PlD4onvYlDMRmP169HQVYt849Skx**5/TnTyjMBBNIgQiE8+cj0a/oDc8=
=ZQec
-----END PGP SIGNATURE-----
--
Rob Walpole
Email [email protected]
Tel. +44 (0)7969 869881
Skype: RobertWalpolehttp://www.linkedin.com/in/robwalpole
