I’m trying to use the ‘SERVICE’ keyword to access remote RDF databases.
My goal is to merge my current database with another one database.
Below is a request - using the service keyword - to access a remote database
select *
where
{
SERVICE <http://dbpedia.org/sparql>
{
?mun owl:sameAs ?dbp .
?dbp rdfs:label ?name
}
}
When I’m requesting, Stardog says "Internal Server Error" (on the webpage)
And on the command-line query tool :"Not a valid (absolute) IRI : #cohabitant"
The problem is probably coming from dbpedia. Dbpedia is known to have some badly formed data. You can set strictParsing to false to deal with bad literals but here you have a bad IRI. I believe that there are some dbpedia dumps out there that have cleaned up data that you might be able to use. Other than you you might be able to munge around with the dbpedia sparql endpoint to try and exclude the offending IRI in your query or possibly cast it to a string. It won’t fix the problem but might make it easier to identify.
I’m a little confused about which queries you executed where and what the results where and what you were expecting. I’m not familiar with the Insee sparql endpoint and it isn’t immediately apparent what data they have loaded in there.
I wasn’t able to find the string “cohabitant” in any of the results from querying dbpedia with the query you gave so I’m not sure what’s going on there.
This request gave me the “cohabitant” error : stardog query test "select * where {SERVICE <http://dbpedia.org/sparql> {?s ?p ?o } } LIMIT 10"
or in formatted request :
select *
where
{
SERVICE <http://dbpedia.org/sparql>
{
?s ?p ?o
}
}
My request on the Insee database works, there’s no problem.
But the same request for dbpedia doesn’t work (I only changed the Insee service for dbpedia).
My last post shown the query I do on dbpedia : there’s no error but there’s no result !
Your query is going to try and pull the entire contents of dbpedia to your local machine and then throw it away. You’d be much better off simply loading the database locally.
I see. And if we speak about this example : stardog query test "PREFIX dbo: <http://dbpedia.org/ontology> SELECT ?city ?label WHERE { SERVICE <https://dbpedia.org/sparql> {?city rdf:type dbo:Location ; rdfs:label ?label .}} LIMIT 10"
which is my example two posts above : it’s not downloading the whole data, it’s working but it returns nothing, but it’s supposed to (I think).
My pleasure. Sometimes it's the little things that get you.
Something that would be nice to have might be a warning if a prefix ended in something other than '/', or '#'. I don't think I've ever seen a prefix that didn't end in either one of these two characters. I guess you could write it PREFIX ex: http://example.com and make the terms ex:#myterm but that would be strange and I think it would blow up rdf/xml although I think turtle might be ok with it.
Along those same lines, trying to detect and warn about silly mistakes, I always thought it would be nice to have something where you're writing a query that you expect to return results and you get zero results and it flags single triple patterns that themselves return zero results. There would obviously be queries that return results where no single pattern returns zero results but it would be a fairly obvious indication that, duh I've got a typo in there somewhere and it's probably not my query construction.
There's a twitter thread out there where someone is suggesting, "query relaxation" on queries that return no results, which is interesting, but I'd be more interested in something that saved me from that 20min search for a typo.