Wikidata Query Service is still beta and maybe not reliable enough + perhaps limited capacity currentlyWe would like to discuss various caching approaches for the Wikidata Query Service.
Stuff like http===== Direct Wikipedia Usage
* Graph extension allows direct querying of the service to produce [[ http://en.wikipedia.beta.wmflabs.org/wiki/Sparql | these examples ]]. In this case, queries are ran from the #Graphoid service, or directly from browsers if the graph is interacted with.
* Graph design - when graph is being designed in the [[ https://en.wikipedia.beta.wmflabs.org/wiki/Sparql is definitely nice,ecial:GraphSandbox | graph sandbox ]], a query will be made on each keystroke.
===== Wikidata tools & bots
* https://github.com/inventaire/inventaire/tree/master/server/data/wikidata/queries/
* https://github.com/smalyshev/pywikibot-core/blob/prefer3/prefer.py
===== External sites
* http://conceptmap.cfapps.io/
* https://inventaire.io/
= Proposals and Ideas
* Invalidate cache on relevant item change - this is an ideal scenario, but it is highly unlikely, as we would have to track all items that participated in the query, plus evaluate all new items if they would match the original query.
* Cache all responses in Varnish for a reasonable duration depending on the server load - e.g. but maybe we need some form of caching of the query results.1 hour or 1 day
* Invalidate cache by doing the same request but with an extra URL parameter or an extra header, (I'm not yet sure where?)
I realize the static images would be cachede.g. `&refresh=1` or `Refresh: 1`.
** To prevent DOS, but think the json query result should also be.
Think we should figure this out before we enable this beyond beta.ignore refresh parameter/header if the cached response is less than a minute old
** VCL will ignore the extra parameter when constructing cache key
* Do not cache unless some request specifies that it is ok to cache
** We need to be clear why non-caching should be the default behavior