[01:32:50] <wbob4>	 hi! I'm a heavy user of the coordinates map helper icon in the upper right of wikipedia articles. Having my first look at wikidata - which field will be used for the cmap? both (breweries) have headquarters location Property:P625 set, but only the latter shows the icon on wikip https://www.wikidata.org/wiki/Q1796123
[01:32:50] <wbob4>	 https://www.wikidata.org/wiki/Q3508302
[01:34:05] <wbob>	 hi! I'm a heavy user of the coordinates map helper icon in the upper right of wikipedia articles. Having my first look at wikidata - which field will be used for the cmap? both (breweries) have headquarters location Property:P625 set, but only the latter shows the icon on wikip https://www.wikidata.org/wiki/Q1796123
[01:34:06] <wbob>	 https://www.wikidata.org/wiki/Q3508302
[01:39:03] <wbob>	 ah I'm mistaken, it's not uniform across the language wikips
[14:17:34] <Algoak>	 What is this IRC about?
[14:20:43] <Blablubbs>	 wikidata
[14:41:40] <icinga-wm>	 PROBLEM - WDQS SPARQL on wdqs1004 is CRITICAL: CRITICAL - Socket timeout after 10 seconds https://wikitech.wikimedia.org/wiki/Wikidata_query_service/Runbook
[14:44:06] <icinga-wm>	 PROBLEM - WDQS SPARQL on wdqs1005 is CRITICAL: CRITICAL - Socket timeout after 10 seconds https://wikitech.wikimedia.org/wiki/Wikidata_query_service/Runbook
[14:48:40] <icinga-wm>	 RECOVERY - WDQS SPARQL on wdqs1004 is OK: HTTP OK: HTTP/1.1 200 OK - 689 bytes in 1.065 second response time https://wikitech.wikimedia.org/wiki/Wikidata_query_service/Runbook
[14:48:44] <icinga-wm>	 RECOVERY - WDQS SPARQL on wdqs1005 is OK: HTTP OK: HTTP/1.1 200 OK - 689 bytes in 1.067 second response time https://wikitech.wikimedia.org/wiki/Wikidata_query_service/Runbook
[15:58:21] <Majavah>	 can a sysop change Q16503 mediawikiwiki sitelink point to Project:Village Pump as the page was renamed? thanks!
[15:59:08] <Hasley>	 done
[15:59:33] <Majavah>	 ty
[15:59:38] <Hasley>	 wlc
[16:28:07] <Fade>	 I'm in the very early stage of writing a common lisp interface to the wikidata sparql endpoint.
[16:28:24] <Fade>	 but I'm seeing something that is confusing me.
[16:28:40] <Fade>	 if I run a query in python, I get the expected JSON result.
[16:29:18] <Fade>	 but if I run the same query from anywhere else, lisp, emacs, curl, I get what appears to be a JSON encoding of a raw RDF dump.
[16:29:44] <wmchat-bridge_>	 [mattermost] <Lucas> how are you running the query in Python? some SPARQL library or direct HTTP?
[16:29:53] <Fade>	 direct HTTP
[16:30:04] <wmchat-bridge_>	 [mattermost] <Lucas> strange
[16:30:19] <Fade>	 same with the other clients I've tried
[16:30:49] <Fade>	 the output for the other clients is pretty large, irrespective of the limits in the query. around 30 megabytes.
[16:30:58] <wmchat-bridge_>	 [mattermost] <Lucas> are you sending an `Accept` header with your lisp/emacs/curl? (or a `format` parameter)
[16:31:15] <wmchat-bridge_>	 [mattermost] <Lucas> hm, that almost sounds like you might be seeing an LDF response…
[16:31:16] <Fade>	 yes
[16:31:38] <Fade>	 I've tried Accept: application/json
[16:31:48] <Fade>	 and application/sparql-results+json
[16:32:10] <Fade>	 as well as sending "format":"json" in the query.
[16:33:08] <wmchat-bridge_>	 [mattermost] <Lucas> if I run `curl -d 'query=SELECT (1 AS ?x) {}' -d format=json https://query.wikidata.org/sparql` I get normal-looking JSON back
[16:33:41] <Fade>	 I have a curl line that for me replicates the problem.
[16:33:46] <Fade>	 but it's pretty large.
[16:34:04] <wmchat-bridge_>	 [mattermost] <Lucas> maybe you can put it somewhere on https://etherpad.wikimedia.org/ ?
[16:35:29] <Fade>	 https://etherpad.wikimedia.org/p/wikidata_query
[16:36:39] <wmchat-bridge_>	 [mattermost] <Lucas> hmm
[16:38:54] <wmchat-bridge_>	 [mattermost] <Lucas> why are you sending a whole JSON object as request parameter? I don’t think that’s how the endpoint is meant to be accessed
[16:39:10] <wmchat-bridge_>	 [mattermost] <Lucas> (which doesn’t really explain the weird response, but maybe fixing that will get you a better response)
[16:39:30] <wmchat-bridge_>	 [mattermost] <Lucas> the URL should be something like `?query=SELECT%20...`, not `?{"query":"SELECT%20..."}`
[16:40:35] <Fade>	 does the endpoint not expect form encoded data?
[16:43:05] <Fade>	 etherpad is cool.
[16:43:33] <wmchat-bridge_>	 [mattermost] <Lucas> maybe that’s a form of form-encoded data I’m not familiar with
[16:43:48] <wmchat-bridge_>	 [mattermost] <Lucas> but then I would expect to see some header that declares what form of data it is, I guess
[16:44:19] <Fade>	 your curl query works as expected.
[16:45:03] <wmchat-bridge_>	 [mattermost] <Lucas> yay
[16:45:06] <Fade>	 I'm glad to know this is on my end. Thanks for your assistance!
[16:45:10] <wmchat-bridge_>	 [mattermost] <Lucas> hopefully you can make common lisp make a similar request :)
[16:45:39] <Fade>	 indeed. I don't think it'll be a huge problem, now that I know what's happening.
[16:52:27] <Fade>	 which chat platform does wmchat-bridge, bridge to?
[16:55:07] <wmchat-bridge_>	 [mattermost] <Lucas> chat.wmcloud.org
[16:55:17] <wmchat-bridge_>	 [mattermost] <Lucas> https://meta.wikimedia.org/wiki/Wikimedia_Chat
[16:56:44] <Fade>	 ahh. I'm glad it isn't discord. :)
[18:12:08] <icinga-wm>	 PROBLEM - WDQS SPARQL on wdqs1005 is CRITICAL: CRITICAL - Socket timeout after 10 seconds https://wikitech.wikimedia.org/wiki/Wikidata_query_service/Runbook
[18:16:36] <icinga-wm>	 RECOVERY - WDQS SPARQL on wdqs1005 is OK: HTTP OK: HTTP/1.1 200 OK - 688 bytes in 1.050 second response time https://wikitech.wikimedia.org/wiki/Wikidata_query_service/Runbook
[20:21:31] <Fade>	 Lucas .. I've added a curl query exhibiting the same behaviour, which is formatted the same way as your example to the etherpad.
[20:34:24] <Fade>	 is it possible that wikidata's query endpoint is dumping the entire wikidata ontology/schema on a query error?
[21:39:42] <wmchat-bridge_>	 [mattermost] <Lucas> I don’t think so
[21:40:29] <wmchat-bridge_>	 [mattermost] <Lucas> it looks like it’s dumping some blazegraph stats?
[21:41:18] <wmchat-bridge_>	 [mattermost] <Lucas> the results seem to start with `_:service a sparql:Service; sparql:endpoint <http://query.wikidata.org/bigdata/namespace/wdq/sparql>; sparql:supportedLanguage sparql:SPARQL10Query, sparql:SPARQL11Query` etc.
[21:41:28] <wmchat-bridge_>	 [mattermost] <Lucas> also listing a bunch of input formats
[21:41:42] <wmchat-bridge_>	 [mattermost] <Lucas> and then, apparently, all known classes/predicates with cardinality, or something like that
[21:42:12] <wmchat-bridge_>	 [mattermost] <Lucas> hell if I know _why_ it does that, though
[21:43:17] <wmchat-bridge_>	 [mattermost] <Lucas> oh wait, that curl is missing `query=` at the start of the `--data-urlencode`
[21:43:32] <wmchat-bridge_>	 [mattermost] <Lucas> so I guess that’s its general behavior for “weird” query parameters
[21:46:16] <wmchat-bridge_>	 [mattermost] <Lucas> yeah, just opening https://query.wikidata.org/sparql?x in the browser gives me roughly the same information (but as RDF+XML)
[21:49:38] <wmchat-bridge_>	 [mattermost] <Lucas> ah, I see: “SPARQL services made available via the SPARQL Protocol SHOULD return a service description document at the service endpoint when dereferenced using the HTTP GET operation without any query parameter strings provided.”
[21:49:41] <wmchat-bridge_>	 [mattermost] <Lucas> per https://www.w3.org/TR/2013/REC-sparql11-service-description-20130321/
[21:55:29] <wmchat-bridge_>	 [mattermost] <Lucas> I guess this is all according to standard then :/
[21:55:41] <wmchat-bridge_>	 [mattermost] <Lucas> Fade: ^ (if you’re still online, sorry I only saw this late)
[22:49:13] <perry>	 (They're still online)