[10:13:22] Hey, I'm part of this research project https://meta.wikimedia.org/wiki/Research:Understanding_Wikidata_Queries Basically we're analysing wikidata query server logs. We need some help from someone with a better understanding of how https://query.wikidata.org/ works than we have. [10:13:48] We noticed that some prefixes like f.e. PREFIX wd: are automatically being added to each query which is being executed. [10:14:02] Can someone please tell us which prefixes are being automatically added, or where else to ask about it? [10:15:48] jgonsior_: I think that all "standard prefixes" are automatically added [10:16:06] the ones under the list "standard prefixes" on https://query.wikidata.org/ [10:16:20] hmm [10:16:25] no, more than that [10:16:34] schema isn't in the list of standard [10:16:44] but is declared automatically also [10:17:31] jgonsior_: maybe all prefix in the list "prefix" are declared actually [10:17:39] that would make sense [10:17:59] Auregann_WMDE: is always the person to question, otherwise [10:18:46] jgonsior_: she'll now who to ask :) [10:19:21] Thanks so far! I already suspected it would be everything from this list. [10:19:57] Auregann_WMDE: can you confirm this? [10:21:59] (i'm not sure she is here, she doesn't answer even on other channels) [10:22:11] (but she'll see it when she come back) [10:22:29] jgonsior_: how can we join you, if needed? [10:27:56] You mean by joining how to contact me? [10:28:00] Either you can send me an e-mail at julius.gonsior@tu-dresden.de or otherwise I'll just take a look into the log for this IRC channel to see her response. [10:28:09] :) [10:30:46] Hello jgonsior_ thanks for your question, I will ask my colleague who takes care of the Query Service [10:37:59] jgonsior_: only 8 prefixes are automatically added, you can see which ones by clicking on "prefixes" then "add standard prefixes" [10:38:39] Harmonia_Boulot: "PREFIX rdfs: " isn't that schema? [10:39:27] multichill: I meant PREFIX schema: [10:39:51] which isn't in the standard list but is still automatically declared [10:40:29] uh [10:41:44] Auregann_WMDE: no [10:42:41] Auregann_WMDE: the standard list is only wd: wdt: wikibase: p: pq: rdfs: and bd: [10:43:01] but schema: xsd:, etc. are also declared [10:43:48] Auregann_WMDE: look : the query about recent deaths http://tinyurl.com/h6vt2ca [10:44:03] Auregann_WMDE: whe use xsd: and didn't declare the PREFIX [10:44:12] Auregann_WMDE: so it must be added automatically [10:44:25] it wouldn't work without that [10:45:08] Auregann_WMDE: I think all prefix listed on top are automaitcally declared [10:45:16] much more than the "standard" 8 [10:47:36] Some will be build in. SMalyshev probably knows, but it's the middle of the night in SF [10:48:15] Harmonia_Boulot https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format#Full_list_of_prefixes [10:48:38] Just see help -> List of prefixes on query.wikidata.org [10:49:19] Jonas_WMDE: do you confirm that all these prefixes are automatically declared by the endpoint? [10:49:26] that was jgonsior_ question [10:50:19] Harmonia_Boulot this is what the documentation says [10:50:56] * nikki wonders what "standard" refers to in "standard prefixes" [10:51:11] I guess often used [10:52:08] nikki: the one listed under "stander prefix" on query.wikidata.org [10:52:36] yeah, I'm wondering what *it* means by that :) [10:52:37] nikki: which is why i use " because there are only standard on this specific endpoint... [10:52:52] also bd: is a standard prefix but not in the full list o_O [10:54:55] seems that this documentation page is out of date [10:55:29] anyway I find it confusing... if you need to explicitly include the prefixes in your query it seems more useful to either add all prefixes that are available or all prefixes used in the current query, not a subset which might or might not include the ones you're using [13:33:24] Loha. on a custom Wikibase installation, how do I stop it pointing files at commons, and use/prefer the local wiki? [14:41:53] usually by setting the user-config.py [16:21:21] https://www.wikidata.org/w/index.php?title=Q950780&type=revision&diff=293892176&oldid=282019103 hm… does that make sense? [16:36:24] I wouldn't have done it, at least [16:41:39] it would be like picking a random american person to be the image for the american people item... it doesn't represent the whole item [17:17:56] om.bigdata.rdf.internal.NotMaterializedException: Vocab(2):XSDUnsignedInt(6032289) [17:17:59] meh :/ [17:18:05] SMalyshev: Is that interesting? [17:36:16] hoo: I was about to run out. Question to think about: How to trigger a (fake) read-only warning so I can test code? Bbl [17:36:32] hoo: please submit it to phab. May be known issue but need details [17:38:12] SMalyshev: Ok, will do [17:49:42] Oh crap… I found a query where blazegraph doesn't return anything, unless I select additional fields [17:52:08] That's pretty bad [17:57:19] o_O [18:17:28] https://twitter.com/mariushoch/status/809462223781306368 This took way to long :P [18:37:23] that is taking forever... [18:38:05] i'm pleased to see that the distribution is pretty even. [19:26:06] Repost from earlier [19:26:06] [13:33:24] Loha. on a custom Wikibase installation, how do I stop it pointing files at commons, and use/prefer the local wiki? [19:30:15] Reedy: you don't [19:30:17] sorry [19:30:24] not supported atm unless you hack the code [19:30:31] That seems daft [19:30:36] If I'm running my own repo/client [19:30:37] heh well... [19:30:49] i'm not saying it shouldn't be possible ;-) [19:30:56] Do you know if there's a task? [19:31:02] it just isn't atm until someone adds a config option for it [19:31:06] yes [19:31:09] let me find it [19:31:47] well, I'm very much used to the "canhaspatch?" [19:31:47] :) [19:32:16] https://phabricator.wikimedia.org/T90492 [19:34:25] Reedy: what crazy things are you doing with wikibase if i may ask? [19:34:34] <- always looking for cool 3rd party installs [19:34:35] Lydia_WMDE: Personally? I'm not [19:34:39] ah [19:34:47] I'm doing some upgrade work for rhizome.org [19:34:59] gotcha [19:34:59] Dragan has been in contact with Jens (at least) at WMDE [19:35:10] yeah [19:35:12] I'm in hte midst of "unfucking" his install :D [19:35:21] lol [19:35:22] ok [19:35:31] He was using some random alpha version of REL1_25... [19:35:33] But on 1.28 [19:35:38] Just upgrading fixed 90% of the issues [19:35:47] sounds fun [19:36:25] Lydia_WMDE: lol. I see he created that task [19:37:03] ;-) [19:37:24] I wonder if he forgot about it [19:37:41] happens to the best of us! :D [19:46:49] https://phabricator.wikimedia.org/T153353 that one is awry [19:47:26] SMalyshev: ^ [19:48:32] hoo: that looks like one of the known issues by vague recollection, but I'll look in more detail after done with today's meeting. Thanks for reporting anyways :) [19:52:16] I see… and wow [22:29:57] Can someone help me reproduce https://phabricator.wikimedia.org/T147798 ? [22:30:18] Didn't you asked this before? [22:30:26] I did. [22:30:46] I've made it throughu the backlog and back at this one [22:30:59] Yeah, I know that feeling. [22:31:24] I don't use Firefox though. But I think multichill does and he has Javascript problems at weird times. [22:31:39] I've got the same in Safari. Still can't figure out. [22:32:52] I'm not sure to what extent ResourceLoader knowledge is required here though [22:33:11] it just means one of the modules throw an exception of sorts while first executing one of the files in that module [22:33:22] whatever exception it shows is the underlying issue. [22:34:22] If the exception is consistently 'Exception: TypeError: wikibase.parsers is undefined' then that means the wikibase js code in that module has a race condition. Some part of it defines this some other part of it uses it, but it is not logically associated in a way that one happens after the other (maybe another module that isn't marked as dependency, or it [22:34:22] is set asynchronously from the same module without waiting for its callback etc.) [22:35:12] I've wrote some stuff down back then, but I'm terrible in that https://phabricator.wikimedia.org/T146069 [22:36:34] hm... I got rid of most of my errors involving that mw.util.addPortletLink by changing something in one of the bits of js I had, I think there's some gadgets which don't correctly depend on mw.util [22:37:11] sjoerddebruin: https://phabricator.wikimedia.org/T146069 is most likely unrelated. The error is not wb related, but mw.util. Most likely the code that calls mw.util.addPortletLink from the relevant site script or default gadget is lacking a dependency on 'mediawiki.util'. [22:37:27] ah, I had to wrap the code inside mw.loader.using('mediawiki.util').done(function () { ... }); [22:37:33] Should be solveable by editing the code on wikidata.org itself [22:37:44] or add [dependencies=mediawiki.util] to Gadgets-definition [22:37:45] I think it was the reasonator script [22:37:48] that performs better [22:37:55] That works too. [22:38:09] ReasonatorTools[ResourceLoader|dependencies=mediawiki.util]|ReasonatorTools.js [22:38:13] mw.loader.using() is more convenient indeed if the source code is maintained elsewhere [22:38:14] already there.... [22:38:24] In that case mw.util.addPortletLink cannot be undefined. [22:38:47] I should check the javascript console again if it happens [22:39:53] nikki: sjoerddebruin: Do you know which gadget? [22:39:56] I can try enabling it in safari [22:40:04] no :/ [22:40:33] sjoerddebruin: do you have a link to that screenshot of which gadgets you have enabled? [22:42:00] wait, there are two reasonator scripts [22:42:19] can someone do the stuff in https://www.wikidata.org/wiki/User:Underlying_lk/reasonator.js [22:43:26] i think i'm going to remove that script from my js anyway [22:45:16] nikki: https://www.dropbox.com/s/hdx3fob5l5nofse/Schermafdruk%202016-12-15%2023.44.56.png?dl=0 [22:57:19] ok, doesn't seem to be any of the official gadgets [22:57:29] but nameguzzler is using mw.util [22:58:07] datadrainer too [23:04:24] sjoerddebruin: looks like all four of the scripts you're loading in your wikidata common.js (not the autodesc one) use mw.util.addPortletLink but don't seem to say they need mw.util [23:14:47] oh dear [23:25:16] it's not all bad, it's hard to fix something if you don't even know where the problem is :)