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. You can
use it either manually by specifying the clauses in the body of SERVICE
(see
https://www.mediawiki.org/wiki/Wikidata_query_service/User_Manual#Label_ser…)
or ignore it completely and fetch the labels manually. Main goals of the
service is twofold:
1. Allow people to quickly write queries without having to spell out how
to get labels (it can be a bit verbose, see e.g.:
https://www.mediawiki.org/wiki/Wikibase/Indexing/SPARQL_Query_Examples#Pres…
)
2. Provide language fallback when asking for labels in languages that
may not have labels ready.
If you're just fetching data, you can safely ignore the service and the
labels altogether.
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
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.
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.
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?
--
Stas Malyshev
smalyshev(a)wikimedia.org