You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Sarven Capadisli <in...@csarven.ca> on 2013/05/08 14:37:11 UTC
Federated query optimization for independent queries (with join)
Hi all,
This is originally entered as a JENA issue (marked as minor) [1], but I
wanted to reach out to Jena users to get an insight:
At this point I'm lead to believe that ARQ is not making an optimization
before making a federated query. Or, well, hopefully the issue has to do
with my SPARQL knowledge
When trying to make two federated queries (may or may not be to same
endpoint), the solution of the first graph pattern in SERVICE is
projected onto the second SERVICE. e.g.,
SELECT DISTINCT ?a ?c ?x ?y
WHERE {
{ SERVICE <http://example.org/sparql> {
?a :p ?x .
?a skos:exactMatch ?b .
} }
{ SERVICE <http://example.info/sparql> {
?c :p ?y .
?c skos:exactMatch ?d .
} }
FILTER (?b = ?c || ?d = ?a || ?a = ?c)
}
As there are no overlapping variable names in use, shouldn't each
SERVICE do its own thing independently from one another, and then the
results get joined?
What I'm experiencing is that, if the first query comes back with n
number of triples, the second query is called n times. Expectation is
that, each query is called once.
See also:
http://answers.semanticweb.com/questions/22550/joining-and-filtering-federated-sparql-queries-with-a-single-request-per-service
Thanks,
[1] https://issues.apache.org/jira/browse/JENA-449
-Sarven
http://csarven.ca/#i
Re: Federated query optimization for independent queries (with join)
Posted by Sarven Capadisli <in...@csarven.ca>.
Hi Diogo,
I couldn't grok VALUES for my particular use (two federated queries)
even though Andy explained VALUES.
Andy's recommendation [1] to turn off the optimizer, worked! I've tested
with --engine=ref. Looking for a way to do it via TDB assembler.
[1] https://issues.apache.org/jira/browse/JENA-449#comment-13651857
-Sarven
On 05/08/2013 03:06 PM, Diogo FC Patrao wrote:
> Hi Sarven
>
> My experience with federated queries is exactly the same as yours. I
> believe Andy confirmed earlier on the list that there is no optimization on
> this type of queries.
>
> I don't remember, but I think I saw somewhere that if you specify the
> VALUES keyword (1) on the second federated query, it would optimize the
> number of calls.
>
> [1] http://www.w3.org/TR/sparql11-query/#inline-data
>
> --
> diogo patrão
>
>
>
>
> On Wed, May 8, 2013 at 9:37 AM, Sarven Capadisli <in...@csarven.ca> wrote:
>
>> Hi all,
>>
>> This is originally entered as a JENA issue (marked as minor) [1], but I
>> wanted to reach out to Jena users to get an insight:
>>
>>
>> At this point I'm lead to believe that ARQ is not making an optimization
>> before making a federated query. Or, well, hopefully the issue has to do
>> with my SPARQL knowledge
>>
>> When trying to make two federated queries (may or may not be to same
>> endpoint), the solution of the first graph pattern in SERVICE is projected
>> onto the second SERVICE. e.g.,
>>
>> SELECT DISTINCT ?a ?c ?x ?y
>> WHERE {
>> { SERVICE <http://example.org/sparql> {
>> ?a :p ?x .
>> ?a skos:exactMatch ?b .
>> } }
>>
>> { SERVICE <http://example.info/sparql> {
>> ?c :p ?y .
>> ?c skos:exactMatch ?d .
>> } }
>>
>> FILTER (?b = ?c || ?d = ?a || ?a = ?c)
>> }
>>
>> As there are no overlapping variable names in use, shouldn't each SERVICE
>> do its own thing independently from one another, and then the results get
>> joined?
>>
>> What I'm experiencing is that, if the first query comes back with n number
>> of triples, the second query is called n times. Expectation is that, each
>> query is called once.
>>
>> See also:
>>
>> http://answers.semanticweb.**com/questions/22550/joining-**
>> and-filtering-federated-**sparql-queries-with-a-single-**
>> request-per-service<http://answers.semanticweb.com/questions/22550/joining-and-filtering-federated-sparql-queries-with-a-single-request-per-service>
>>
>> Thanks,
>>
>>
>> [1] https://issues.apache.org/**jira/browse/JENA-449<https://issues.apache.org/jira/browse/JENA-449>
>>
>> -Sarven
>> http://csarven.ca/#i
>>
>>
>
Re: Federated query optimization for independent queries (with join)
Posted by Diogo FC Patrao <dj...@gmail.com>.
Hi Sarven
My experience with federated queries is exactly the same as yours. I
believe Andy confirmed earlier on the list that there is no optimization on
this type of queries.
I don't remember, but I think I saw somewhere that if you specify the
VALUES keyword (1) on the second federated query, it would optimize the
number of calls.
[1] http://www.w3.org/TR/sparql11-query/#inline-data
--
diogo patrão
On Wed, May 8, 2013 at 9:37 AM, Sarven Capadisli <in...@csarven.ca> wrote:
> Hi all,
>
> This is originally entered as a JENA issue (marked as minor) [1], but I
> wanted to reach out to Jena users to get an insight:
>
>
> At this point I'm lead to believe that ARQ is not making an optimization
> before making a federated query. Or, well, hopefully the issue has to do
> with my SPARQL knowledge
>
> When trying to make two federated queries (may or may not be to same
> endpoint), the solution of the first graph pattern in SERVICE is projected
> onto the second SERVICE. e.g.,
>
> SELECT DISTINCT ?a ?c ?x ?y
> WHERE {
> { SERVICE <http://example.org/sparql> {
> ?a :p ?x .
> ?a skos:exactMatch ?b .
> } }
>
> { SERVICE <http://example.info/sparql> {
> ?c :p ?y .
> ?c skos:exactMatch ?d .
> } }
>
> FILTER (?b = ?c || ?d = ?a || ?a = ?c)
> }
>
> As there are no overlapping variable names in use, shouldn't each SERVICE
> do its own thing independently from one another, and then the results get
> joined?
>
> What I'm experiencing is that, if the first query comes back with n number
> of triples, the second query is called n times. Expectation is that, each
> query is called once.
>
> See also:
>
> http://answers.semanticweb.**com/questions/22550/joining-**
> and-filtering-federated-**sparql-queries-with-a-single-**
> request-per-service<http://answers.semanticweb.com/questions/22550/joining-and-filtering-federated-sparql-queries-with-a-single-request-per-service>
>
> Thanks,
>
>
> [1] https://issues.apache.org/**jira/browse/JENA-449<https://issues.apache.org/jira/browse/JENA-449>
>
> -Sarven
> http://csarven.ca/#i
>
>