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