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
>
>
--
Rob Walpole
Email [email protected]
Tel. +44 (0)7969 869881
Skype: RobertWalpolehttp://www.linkedin.com/in/robwalpole
