Federated query with inline data returns empty result

Support
1

I’m not sure whether this is the intended behavior cause I’m not that familiar with federated queries, but let me explain my problem.

I have a SPARQL query that has some inline data for testing purposes, i.e. I make use of the VALUES keyword. In addition, that variable is used in a federated query to the DBpedia endpoint:

PREFIX dbr: <http://dbpedia.org/resource/>

SELECT distinct ?s ?type WHERE {
  
    VALUES ?s {dbr:Leipzig}    

    SERVICE <http://dbpedia.org/sparql> {
            ?s rdf:type ?type  
    } 
}

This query returns an empty resultset.

If I bind the value to the variable ?s directly in the SERVICE clause, it works as expected:

PREFIX dbr: <http://dbpedia.org/resource/>

SELECT ?type WHERE {
 
    SERVICE <http://dbpedia.org/sparql> {
            dbr:Leipzig rdf:type ?type  
    } 
}

So my question is, when is the VALUES data computed? I’d assume it first binds values to the variable ?s which is then propagated to the federated query.

2

Hi Lorenz,

Right now SERVICE is evaluated according to the standard bottom-up semantics of SPARQL: SERVICE returns some solutions (with bindings for ?s), VALUES returns a single solution (with ?s bound to dbr:Leipzig), and then the results are joined.

What you describe would a semantically equivalent and an optimized way of doing it (this is what, roughly, we do for other similar cases, e.g. virtual graphs, but not yet for SERVICE, for which we have an open ticket).

It’s hard to say why the results aren’t the same. My guess would be that the DBPedia endpoint returns some truncated results for ?s rdf:type ?type since the full set of solutions would be too large. If that’s true, then solutions with ?s bound to dbr:Leipzig may not be returned and the join fails. You can probably test that theory.

We’re working on improving our federation support.

Cheers,
Pavel

1 Like
3

Ah, I see.

Well, you’re right. I didn’t know or better said forgot that SPARQL works always bottom up - like it also does for subqueries.

Hm, indeed an unoptimized version makes the whole concept a bit inefficient especially when you consider the technical limitations for public services that usually limit the number of returned results in a single request - for good reasons indeed given that it’s a shared service.

I know that this is still a research topic, but I’m pretty sure that you’ll push it into the right direction. Also, I’m not sure how popular this feature is in general. I rarely heard about people using federated SPARQL queries, but let’s see what the future brings to us … Big Data, Data Warehouses, Data Lakes, etc.

Thank you for the fast support!

Regards,
Lorenz

4

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.