There’s no information about this problem on internet, and I think I’m not the only one trying to do a binding of that type…
Do you have any ideas to counter this problem ?
Clément
There’s no information about this problem on internet, and I think I’m not the only one trying to do a binding of that type…
Do you have any ideas to counter this problem ?
Clément
Try to send
?thing rdf:type dbo:Automobile;
rdfs:label ?marqueSerie .
VALUES ?marqueSerie { <<some marque series here>> }
to their endpoint and see if you get results or again 409.
Cheers,
Pavel
Just to be clear: I mean do it outside of Stardog, using cUrl or anything.
It works indeed.
select ?thing where {
?thing rdf:type dbo:Automobile ;
rdfs:label ?marqueSerie .
VALUES ?marqueSerie { "Peugeot 206"@fr }
}
It seems like it’s doing that with the other endpoints I tried to (I’m able to reproduce this error with other endpoints).
On Google, they only give example of federated queries like this :
SELECT * WHERE {
?s ?p ?o
SERVICE <myUri> {
?s ?pp ?oo
}
}
It means that ?s is the subject on both local & remote queries. Not in my case (indeed in the remote query, this is the object I’m referencing to)
That’s why I tried with the Inverse Property tool ( ?s rdf:type ?t == ?t ^rdf:type ?s) but it’s still buggy, with the error 409…
Can you run stardog query explain
on this query?
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
}
}
Here we go :
Your original query was much more selective on the local side. The issue here may be that we’re sending a larger query than DBPedia can handle. Can you try this?
PREFIX vco:<http://www.myOntology.eu/VCO#>
PREFIX dbo:<http://dbpedia.org/ontology/>
SELECT ?client ?marque ?serie ?modele ?taille WHERE {
?infoGlobaleVehicule a vco:InfoGlobaleVehicule ;
vco:aPourDistanceTotale ?distanceTotale;
vco:aPourVehicule ?vehicule.
?infoMarqueVehicule a vco:InfoMarqueVehicule ;
vco:aPourMarque ?marque ;
vco:aPourSerie ?serie ;
vco:aPourModele ?modele ;
vco:aPourVehicule ?vehicule .
?vehicule a vco:Vehicule;
vco:aPourClient ?client.
?client a vco:ClientCible ;
vco:aPourAge ?age;
vco:aPourEtatCivil ?etatCivil;
vco:aPourNombreEnfants ?nombreEnfants.
BIND (CONCAT(?marque," ",?serie) as ?marqueSerie)
SERVICE <https://dbpedia.org/sparql> {
?auto rdf:type dbo:Automobile ;
rdfs:label ?label ;
dbo:width ?taille .
# changed your FILTER to a BIND
BIND (ucase(?label) AS ?marqueSerie)
}
}
And can you run stardog query explain
on this query?
Jess
Yes, I made it to make things clearer.
Anyway, it doesn't work either.
Here's the log file associated to this "Internal Server Error" : stardog.log (14.1 KB)
Moreover, on DBPedia's website, it's written : 120seconds of execution before timeout. This request should be done, I think (because this request (on the service) works on their SPARQL endpoint)
Here's the query plan :
How many results do you get from the local query if you remove the entire service block?
Ok, one more for you. It looks like reasoning might be de-duplicating results at a higher level than we need:
PREFIX vco:<http://www.myOntology.eu/VCO#>
PREFIX dbo:<http://dbpedia.org/ontology/>
SELECT ?client ?marque ?serie ?modele ?taille WHERE {
# select distinct results here
{ select distinct ?client ?marque ?serie ?modele ?taille ?marqueSerie {
?infoGlobaleVehicule a vco:InfoGlobaleVehicule ;
vco:aPourDistanceTotale ?distanceTotale;
vco:aPourVehicule ?vehicule.
?infoMarqueVehicule a vco:InfoMarqueVehicule ;
vco:aPourMarque ?marque ;
vco:aPourSerie ?serie ;
vco:aPourModele ?modele ;
vco:aPourVehicule ?vehicule .
?vehicule a vco:Vehicule;
vco:aPourClient ?client.
?client a vco:ClientCible ;
vco:aPourAge ?age;
vco:aPourEtatCivil ?etatCivil;
vco:aPourNombreEnfants ?nombreEnfants.
BIND (CONCAT(?marque," ",?serie) as ?marqueSerie)
} }
SERVICE <https://dbpedia.org/sparql> {
?auto rdf:type dbo:Automobile ;
rdfs:label ?label ;
dbo:width ?taille .
# changed your FILTER to a BIND
BIND (ucase(?label) AS ?marqueSerie)
}
}
IT.WORKS.
Can you explain me “why” you had to encapsulate the first select ?
Thanks,
Clément
The local part of the query is returning (many) more than four results with reasoning. The larger result set is causing a query to be generated which is too large for DBpedia. I have created issue #5015 to address this.
Jess
What do you mean by “query is returning many more than four results” ? It can be quite important for me…
Indeed, my local select returns only four lines, not more…
Results are reduced to distinct solutions with reasoning queries. This is not done until the final stage of query evaluation. The intermediate results may have duplicates.
Jess
I get it. I did not had that knowledge when I wrote that query. Anyway, I see how reasoning works now . It can be usefull seeing how it works when debugging comes…
Clément
Thanks for your patience. We’re working to make this new approach a bit more mature.
Jess
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.