Geo SPARQL query over Wikidata Query service

[MatsGej]

Hi
I am new to this. I have this SPARQL query that works on the Wikidata Query Service but it does not work on the qEndpoint. What can I do about it? It throws this exception:
org.eclipse.rdf4j.query.QueryEvaluationException: Server responded with an unsupported file format: application/rdf+xml

This is the query. It find a number of places within a bounding box and returns their names and locations
PREFIX wd: http://www.wikidata.org/entity/
PREFIX wdt: http://www.wikidata.org/prop/direct/
PREFIX rdfs: http://www.w3.org/2000/01/rdf-schema#
PREFIX geo: http://www.opengis.net/ont/geosparql#
PREFIX wikibase: http://wikiba.se/ontology#
PREFIX bd: http://www.bigdata.com/rdf#

SELECT ?place ?placeLabel ?location
WHERE {
SERVICE wikibase:box {
?place wdt:P625 ?location.
bd:serviceParam wikibase:cornerWest "Point(14.808774623316117 56.877338602443515)"^^geo:wktLiteral.
bd:serviceParam wikibase:cornerEast "Point(14.813474019683593 56.8800030629281)"^^geo:wktLiteral.
}
?place wdt:P31/wdt:P279* wd:Q2221906.
SERVICE wikibase:label { bd:serviceParam wikibase:language "sv". }}

[D063520]

Hi Mats,

thank you for using qendpoint! About your issue.

One can split it into 2 problems:

1. the current index of Wikidata that we provide does not provide geoSPARQL. We might change this if this is a request from your side for example. We never tried though and we might run into performance issues. I'm not sure.

2. The Wikidata SPARQL endpoint is using standard SPARQL + some syntax that is only available in Blazegraph, the implementation that is behind the SPARQL endpoint of Wikidata. This not nice in terms of interoperability. This is the case for the above SPARQL query. We support this syntax https://rdf4j.org/documentation/programming/geosparql/ which is respecting the standard. One can rewrite the query above into this syntax. The question is would you be willing to do that? At some point we could make this transformation on our end, but this would require some more engagement from Wikimedia Deutschland side who is maintaining this service. We have done this for example for the SERVICE wikibase:label clause.

Let us know about point 2) : )

Cordially
D063520

[D063520]

Apparently Wikimedia added just a few SPARQL syntax:

https://en.wikibooks.org/wiki/SPARQL

namely:

SERVICE Labels and Descriptions
SERVICE around and box
SERVICE Mediawiki Api (Wikipedia, commons etc.)

We already implemented part of SERVICE Labels.

[MatsGej]

It tried rewriting according to point 2. And got some help by chat GPT.

This is the rewritten query using rdf4j. It does not give any errors in the query service, but it times out instead.
PREFIX wd: http://www.wikidata.org/entity/
PREFIX wdt: http://www.wikidata.org/prop/direct/
PREFIX rdfs: http://www.w3.org/2000/01/rdf-schema#
PREFIX geo: http://www.opengis.net/ont/geosparql#
PREFIX wikibase: http://wikiba.se/ontology#
PREFIX bd: http://www.bigdata.com/rdf#
PREFIX geof: http://www.opengis.net/def/function/geosparql/

SELECT ?place ?placeLabel ?location
WHERE {
?place wdt:P625 ?location.
?place wdt:P31/wdt:P279* wd:Q2221906.

FILTER(geof:sfContains("POLYGON((14.808774623316117 56.877338602443515, 14.808774623316117 56.8800030629281, 14.813474019683593 56.8800030629281, 14.813474019683593 56.877338602443515, 14.808774623316117 56.877338602443515))"^^geo:wktLiteral, ?location)).

SERVICE wikibase:label { bd:serviceParam wikibase:language "sv". }
}
I also tried with sfWithin but it also timed out. Timer was set to 1600 seconds

Then I tried at at the Wikidata Query Service and it does not work there, does not recognize sfWithin or sfContains

What am I doing wrong?
Thanks
Mats

[D063520]

Hi Mats,

sorry I think I did not explain well. I was asking if you are willing to translate your original query to a standard geoSPARQL query. Which apparently you are : )

This query will not work on the public wikidata SPARQL endpoint since it is not following the standard on this.

We follow the standard, but on the original docker that we provide we do not deliver the geoSPARQL index that allows this type of request. So this is on us. I opened an issue for this:

#366

we will check internally how much bandwith we have for this currently. Please check the issue : )