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 <[email protected]> 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 > >
