Good morning :-)
On 09.09.2015 00:45, Stas Malyshev wrote:
Hi!
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
You don't have to use variables in SELECT, it's just a shortcut.
What I meant with my comment is that the SPARQL semantics does not allow for extensions that modify the query semantics based on the selected variables. Even if this is optional, it changes some fundamental assumptions about how SPARQL works.
...
Nothing prevents us from creating such UI, but for many purposes having to do extra step to see labels does not seem optimal for me, especially if data is intended for human consumption.
I agree that creating such a UI should not be left to WMF or WMDE developers. The SPARQL web api is there for everybody to use. One could also start from general SPARQL tools such as YASGUI (about.yasgui.org) as a basis for SPARQL editor.
An extra step should not be needed. Users would just use a query page like the one we have now. Only the display of the result table would be modified so that there is a language selector above the table: if a language is selected, all URIs that refer to Wikidata entities will get a suitable label as their anchor text. One could also have a the option to select "no language" where only the item ids are shown.
results), one could as well have some JavaScript there to beautify the resulting item URIs based on client-side requests. Maybe some consumers
I'm not sure what you mean by "beautify". If you mean to fetch labels, querying labels separately would slow things down significantly.
There should be no slowdown in the SPARQL service, since the labels would be fetched client-side. There would be a short delay between the arrival of the results and the fetching of the labels. We already have similar delays when opening a Wikidata page (site names, for example, take a moment to fetch). Wikidata Query/Autolist also uses this method to fetch labels client-side, and the delay is not too big (it is possible to fetch up to 50 labels in one request).
With beautify I mean that one could do further things, such as having a tooltip when hovering over entities in results that shows more information (or maybe fetches an additional description). That's where people can be creative. I think these kinds of features are best placed in the hands of community members. We can easily have several SPARQL UIs.
really need to get labels from SPARQL, but at least the users who want to see results right away would not need this.
Then why wouldn't these users just ignore the label service altogether?
Because all examples are using it, and many users are learning SPARQL now from the examples. This is the main reason why I care at all. After all, every SPARQL processor has some built-in extensions that deviate from the standard.
Markus