Andy,

I was expecting you'd ask for the query .... ;-)

It is a union of correlated and non-correlated instances of a given type. We 
also need to be bale to do paging hence the ofset/limit clauses.
Note that as it is now it is not correct because it may bring 200 versus 100 
combined correlated /non-correlated objects.
Also bear in mind that I am showing a text match but other filters may be 
applied dynamically by the user.

Here it is in all its ugly,twisted "glory":

SELECT DISTINCT  ?corr ?px ?ox
WHERE
  {   { { SELECT  ?s
          WHERE
            { ?s rdf:type proj-core:SomeOntType
              OPTIONAL
                { ?s myproj:correlatedRecord ?correlated }
              FILTER ( ! bound(?correlated) )
            }
        }
        { SELECT DISTINCT  ?corr
          WHERE
            { ?s pf:textMatch "1*" .
              ?s myproj:hasCorrelation ?corr
            }
          ORDER BY ?corr
          OFFSET  0
          LIMIT   100
        }
        { SELECT  *
          WHERE
            { ?corr proj:isCorrelationOf ?sx .
              ?sx ?px ?ox
            }
        }
      }
    UNION
      { { SELECT  *
          WHERE
            { ?corr rdf:type myproj:SomeOntType .
              ?corr pf:textMatch "1*"
              OPTIONAL
                { ?corr idsp-core:correlatedRecord ?correlated }
              OPTIONAL
                { ?corr myproj:hasCorrelation ?hasCorrelation }
              FILTER ( ( ! bound(?correlated) ) && ( ! bound(?hasCorrelation) ) 
)
            }
          ORDER BY ?corr
          OFFSET  0
          LIMIT   100
        }
        ?corr ?px ?ox
      }
  }
ORDER BY ?corr


Please do not hesitate to contact me if you need additional information. Thank 
you.

Regards,

Nikolaos Abatzis
New River Systems Corporation
1890 Preston White Drive, Suite 240
Reston, VA 20191
________________________________________
From: Andy Seaborne [[email protected]]
Sent: Tuesday, May 17, 2011 11:45 AM
To: [email protected]
Subject: Re: In-depth documentation regarding SPARQL execution in Jena

On 17/05/11 16:09, Nikolaos Abatzis wrote:
> Good morning all,
>
> In-depth: meaning far more than the manuals from W3C detailed about SPARQL 
> and in specific how bgp and groups get combined as well as how Jena/ARQ 
> internally handle query execution.
> I understand that "ultimately" in-depth means going to the code but something 
> short of doing that?
>
> I want to focus on memory demands and intermediate caching in memory of 
> partial results, if any. We are having OutOfMemory issues with some types of 
> queries, not all of them and I am trying to troubleshoot it
> instead of "just throwing" more H/W at it, i.e. memory.
>
> BTW, we are using Oracle at the back end ... Any Oracle query hints that you 
> may have found helpful and can share would be greatly appreciated ...
>
>
> Please do not hesitate to contact me if you need additional information. 
> Thank you.

Is this SDB?

What's the query?

        Andy

>
> Regards,
>
> Nikolaos Abatzis
> New River Systems Corporation
> 1890 Preston White Drive, Suite 240
> Reston, VA 20191

Reply via email to