Em… So sorry. As you might have guessed, I had a late-night brain glitch in
anonymizing the code. I can simplify this by eliminating the distracting
separate namespaces. With that simplification, it should have read:
SELECT DISTINCT ?O ?T ?E
WHERE{
?E a :E.
{ SELECT ?O ?T
WHERE {
?O :oE ?E;
:oT ?T .
} ORDER BY DESC(?T)
LIMIT 3
}
}
In this way I had planned for each ?E to be paired with the much more limited
case where ?E is linked to ?O. So, in the worst case, the result would be 3 O’s
per E, or 3 * 7273 = 21819. I expect much less, although there are other
issues with the numbers that I have to look at.
Perhaps I don’t have a proper understanding of the connectivity. Is it the case
that for the nested query I need to have ?E in the Select in order to have the
embedded ?E bound to (and constraining/constrained by) the outer ?E ? I’ll try
that, as it is what I had intended (and not unconnected cross products).
In my looking I could not find much that explains some of these somewhat subtle
nuances regarding nested SPARQL queries. Is there a definitive and informative
set of examples and explanations for me to wrap my head around?
Thanks again,
Mark
On Jun 4, 2014, at 4:10 AM, Andy Seaborne <[email protected]> wrote:
> Mark,
>
> If this is with the latest version (if not, which?), could you try:
>
> SELECT DISTINCT ?O ?T ?E
> WHERE{
> { SELECT ?O ?T
> WHERE {
> ?O :oE ?x; ## <<< correction
> :oT ?T .
> } ORDER BY DESC(?T)
> LIMIT 3
> }
> ?E a x:E. ## <<< Moved
> }
>
> It might be the optimizer is not generating a particular sensible plan.
>
> There look to be 2337 answers (3*779) because it is an unconstranded cross
> product.
>
> Ask for the results in an efficient format like
> application/sparql-results+json.
>
> It's hard to say anything really concrete without a complete, runnable
> example though.
>
> I would note that your queries have a number of unconnected parts.
> Unconnected parts simply lead to a cross product and often fairly useless
> answers for the application compared to asking the parts separately.
>
> Here
>
> ?E a x:E.
>
> shares no variables with
>
> SELECT ?O ?T
>
> and in the larger query and the results are every combination of ?E with (?O
> ?T). (779 * 3)
>
> ?E a prov:E.
>
> SELECT ?O ?T ... OPTIONAL {?O :op ?P.}
>
> SELECT ?SH ... ?SH :shS ?S.
>
> are three separate groups of patterns which leads to a 3-way cross product
> which can get very large.
>
> Andy
>
>
> On 04/06/14 04:53, Mark Feblowitz wrote:
>> This is a fragment of an even larger query that might never complete in our
>> lifetimes:
>>
>> SELECT DISTINCT ?O ?T ?E
>> WHERE{
>> ?E a x:E.
>> { SELECT ?O ?T
>> WHERE {
>> ?O :oE ?;
>> :oT ?T .
>> } ORDER BY DESC(?T)
>> LIMIT 3
>> }
>> }
>>
>> Here’s what I want:
>>
>> For every E, the top 3 O’s as sorted by T.
>>
>> My TDB store contains 779 O’s, 7273 E’s, and a T for every O.
>>
>> The full query is this:
>>
>> SELECT DISTINCT ?O ?T ?S ?E ?P
>> WHERE{
>> ?E a prov:E.
>> { SELECT ?O ?T
>> WHERE {
>> ?O :otE ?E;
>> :oT ?T .
>> } ORDER BY DESC(?T)
>> LIMIT 3
>> }{ SELECT ?SH
>> WHERE {
>> ?EHS :ehsO ?O.
>> ?EH :ehEHSf ?EHS.
>> ?SHS :shsEHS ?EHS;
>> :shsSH ?SH .
>> ?SH :rank ?SHRank.
>> } ORDER BY ASC(?SHRank)
>> LIMIT 1
>> }
>> ?SH :shS ?S.
>> OPTIONAL {?O :op ?P.}
>> }
>>
>> A pretty complex query, and one that *certainly* won’t complete if the
>> simpler one won’t.
>>
>> Thanks,
>>
>> Mark
>>
>
