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_service)
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#Presidents_.26_causes_of_death

)
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@wikimedia.org

_______________________________________________
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata