Il 09/09/2015 00:13, Markus Krötzsch ha scritto:
On 09.09.2015 00:07, Markus Krötzsch wrote:
On 08.09.2015 23:56, Denny Vrandečić wrote:
Anyone an idea why this query has a trouble when I add the OPTIONAL keyword?
Doesn't look much harder than the queries in the examples.
Looking at the bottom of the exceptions, you can see that the system simply refuses to run the query. The problem seems to be with the labelling service. If you don't select the label for ?head, it works fine:
It seems the implementation of the label service needs some improvement to support unbound variables (which should then return unbound labels, rather than throw a runtime exception ;-).
P.S. I am not convinced yet of this non-standard extension of SPARQL to fetch labels. Its behaviour based on the variables given in SELECT seems to contradict SPARQL (where SELECT is applied to the results of a query *after* they are computed, without having any direct influence on the meaning of the WHERE part).
A simple UI that would query the Web API on demand might be better, and not put any load on the query service. Considering that the main query service is not the W3C conforming SPARQL endpoint (which gives you raw results), one could as well have some JavaScript there to beautify the resulting item URIs based on client-side requests. Maybe some consumers really need to get labels from SPARQL, but at least the users who want to see results right away would not need this.
Markus
I agree with Markus here. Also, this solution would make the selection of the "overall" language easier. (I was myself experimenting with this kind of approach, but unfortunately my server is down right now and it will take some time to be brought up again to show it.)
What was the rationale behind this choice?
Nicola