As you can see, i'm using ?marqueSerie on the "global" request and once again with the filter on the "Service". If I replace FILTER (regex(ucase(?label),?marqueSerie)) by FILTER (regex(ucase(?label),"anythingElse")) it works... And I don't know why
I would encourage you to first consider what you’re doing in this query. According to the bottom up evaluation semantics of SPARQL, the service query result will be joined with the local query result. How do you expect the ?marqueSerie variable to be bound in the remote query?
The query plan ? If you mean “what I want to do” (I don’t have a perfect english…) :
SELECT ?vehicle WHERE {
?info a vco:InfoMarqueVehicule ;
vco:aPourMarque ?brand;
vco:aPourSerie ?serie ;
vco:aPourVehicule ?vehicle .
BIND (CONCAT(?brand," ",?serie) as ?brandSerie)
}
and then, I have all the vehicles of my database, with their ?brandSerie names. Then, I want to match those ?brandSeries names with DBPedia, to match something else (like their width, related cars, …)
The problem is that there are no bindings for ?marqueSerie in the body of your service query. The remote query must return results in order to join with the local query results. One option is to move the filter outside of the service block.
With Stardog 5.2.2 you might wish to try joining with a shared binding and not a filter. You would replace the FILTER in your query with bind(ucase(?label) as ?marqueSerie). The ?marqueSerie variable should take the same values locally and remotely and join properly. Stardog 5.2.2 has a new optimization to make this efficient with service queries.
That’s awesome. So is that what “Optimize execution of SERVICE clauses ” in the release notes is? Any hints on what it’s doing? That could change a lot about how you employ service queries.
Yes, I’m referring specifically to that entry. We use local statistics to determine if the local query is likely more selective than the service query. In this case we evaluate the local part of the query and perform the join by binding the variables before calling the remote service. The simplest example would be a query like this:
Without the optimization we would have to retrieve all results from the service query and join to the local query which is a set two values. The optimization allows us to pass the bindings to the service query and only retrieve the triples associated with the two IRIs. This optimization covers arbitrary local queries which are joined with services (ie it’s not limited to VALUES). Feel free to let us know how it works or if you have some further questions.
Thanks for the information. It’s actually very helpful to know when deciding if service queries are an option. It might be a small change to it’s a big change in the viability of service queries. Since you can’t get reliable statistics on the remote endpoint am I correct in guessing that you just make a sensible guess and send bindings if they’re less than say 1k?
It’s a bit more vague, but that’s the general idea. We assume the service query returns a fairly large number of results. This should maintain the correct balance of using the optimization when it significantly reduces the size of the service query result. The other situation is that the local query returns many results and evaluating the service query first is more efficient. We’re planning on collecting some remote statistics as we already do for virtual graph as well as adding some hints to selectively enable/disable this optimization as needed.
The last one should work and looks like a bug. Do you have access to the Stardog home directory on the server? If so, can you send us stardog.log file to help reproduce the issue?
OK, thanks. This shows that the DBpedia endpoint returns 409 for your service query. I’m not exactly sure why but it might have something to do with how it handles BIND patterns.
Could you try this:
SELECT ?thing WHERE {
?infoMarqueVehicule a vco:InfoMarqueVehicule ;
vco:aPourMarque ?marque ;
vco:aPourSerie ?serie ;
BIND (UCASE(CONCAT(?marque,' ',?serie)) as ?marqueSerie)
SERVICE <http://dbpedia.org/sparql> {
?thing rdf:type dbo:Automobile;
rdfs:label ?marqueSerie
}
}
I understand it probably won’t produce all results you want (because upper casing now happens outside of DBPedia, but let’s see if it at least executes.
It does not work either. As mentioned by Jess (but it's not the exactly same case),
The problem is that there are no bindings for ?marqueSerie in the body of your service query. The remote query must return results in order to join with the local query results. One option is to move the filter outside of the service block.
So here again, it's sending me an Internal Server Error. The log file : stardog.log (14.1 KB)
Moreover and as you said, it's not doing what I really want, but I think you made me done that to test something
No, ?marqueSerie is perfectly bound in this case and Stardog pushes bindings for that variable from outside of SERVICE. I don’t know why DBPedia refuses to serve this query, maybe you can find out under what circumstances their endpoint returns 409?
