Thanks! The explanations helped a lot.
I am thrilled to see the Query service coming into production! Wohoo!
On Tue, Sep 8, 2015 at 3:46 PM Stas Malyshev smalyshev@wikimedia.org 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. 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_serv... ) or ignore it completely and fetch the labels manually. Main goals of the service is twofold:
- 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#Presi...
) 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