[08:02:36] https://www.wikidata.org/w/index.php?title=Q854972&action=history hm... [08:05:13] Alphos: ? [08:05:30] ah [08:05:38] des badges Wikisource sur Wikipédia [08:05:41] Ash_Crow : lots of "not proofread" badges, lots of data removed, some of which legit [08:05:59] just nuke that bot [08:06:07] Q854972 is indeed in serbia, for instance [08:06:30] or user [08:07:05] checking on guc [08:08:09] glwiki user, also uploads files on commons [08:08:09] 432 edits in three years [08:08:42] I'd guess sandbox-type edits by someone who doesn't know Wikidata [08:08:59] btw, what about commonswiki sitelink being a category ? [08:09:11] shouldn't it only be for pages, not categories ? [08:09:17] it should [08:09:40] but Commons users want to put pages here so there are interwikis on the left on Commonss [08:10:16] well, that's something which should be dealed with a lua module [08:10:21] in my opinion [08:10:25] I agree. [08:10:36] (dealt) [08:10:50] (if I may) [08:10:57] yes you may :p [08:12:14] ^^ [08:14:18] (so *do* deal with it and make a lua module ! :p ) [08:16:43] Alphos: my lua isn't good enough [08:16:51] and i'm working on names [08:16:58] that was aimed at Ash_Crow, of course ! [09:55:16] harmonia, Alphos: https://phabricator.wikimedia.org/T145279#2631509 [09:55:45] (Ash_Crow as well) [09:56:35] does the endpoint have a problem? why is http://tinyurl.com/gtpultl saying "no matching records found"? [09:57:49] nope, ignore this [09:57:55] i made an error [09:58:14] missed a step :) [09:58:57] harmonia http://tinyurl.com/j4qehtu [09:59:17] well, i deleted a line in correcting a Qid but same result [09:59:51] harmonia : but you didn't even look at my wdt:P734/wdt:P31 trick :-( [10:00:04] Alphos: I know it [10:00:17] I used it in my Sunday Query! [10:00:43] but I don't really like it because I find it less clear when I'm tired [10:01:40] heh [10:47:05] question regarding page translation: what do I need to do to create a translated version of a page such as [[Help:P641]]? [10:47:06] 10[8] 10https://www.wikidata.org/wiki/Help:P641 [11:41:39] Jonas_WMDE: I've made new tasks for the new issues with your code, I've subscribed you to them/ [11:42:06] thanks I saw them! [11:42:17] sorry that it is still broken [11:42:51] No problem, it is hard to understand the usage of the gadget based on the code itself. :) [14:46:07] My watchlist is useless today. :) [16:19:19] Amir1: hey! I'm sorry I didn't get back to you yet. I'm completely swamped today. If you have nothing else urgent to do, maybe have a poke at . You can try to do it based on the current version of Site and ignore T135147 for now. [16:19:19] T135147: Make the domain model implemented by Site/SiteLookup/SiteStore more flexible - https://phabricator.wikimedia.org/T135147 [16:20:00] Amir1: that would be a code experiment. the idea is to see what the potential problems are, and to gather experience with the code base in question. [17:32:28] DanielK_WMDE: Hey, I was afk [17:32:37] I jut got home, I do it son [17:50:15] Amir1: i found the issue with jenkins, i think. check my comment on https://gerrit.wikimedia.org/r/#/c/311483/12 [17:50:38] yeah, thanks. I will take care of it ASAP [17:53:43] afk for dinner [17:58:06] Hello, using sparql I am trying to get all items linked to a Town in wikidata and, for each one, the label of the property. I have not been able to get the name of the property label for the moment, any idea ? http://tinyurl.com/h9l9trr [17:59:02] https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/queries#Adding_labels_for_properties? [18:00:09] yup, so: http://tinyurl.com/zoftt6z [18:06:26] sjoerddebruin, WikidataFacts: thanks works like a charm. For my information, why is the ^ before wikibase:directClaim needed ? I can't see it in the documentation sjoerddebruin linked to. [18:06:36] ^ means to invert the order of the triple [18:06:55] ?prop ^wikibase:directClaim ?property [18:06:56] means the same as [18:06:56] ?property wikibase:directClaim ?prop [18:07:15] because the property is linked to the wdt: version, not the other way around [18:17:42] WikidataFacts, thanks for the explanation, still a lot to lear beyond the basic queries :) [18:32:42] addshore: You're filling my watchlist with instances of https://www.wikidata.org/w/index.php?title=Q19345928&curid=20952746&diff=378257064&oldid=255184701 . How did the dates end up in the wrong calendar in the first place ? [18:33:39] And do you plan to fix stuff like https://www.wikidata.org/w/index.php?title=Q19685912&type=revision&diff=378251885&oldid=312157111 ? [18:34:46] addshore: If the resolution is year, decade, century or higher it would make more sense to just fix it [18:35:37] multichill: https://github.com/DataValues/Time#080-2015-06-26, seems like before that date every added date was always Gregorian, unless specified [18:44:10] addshore: You should probably stop the bot and only mark dates that are not years or higher [18:49:22] sjoerddebruin: The bot isn't following https://upload.wikimedia.org/wikipedia/commons/c/ca/Wikidata_Calendar_Model_Decision_Tree.svg [18:49:45] The bot should either not touch records which are precision of year and less precise or fix them [18:50:08] Marking is just causing a shitton or redundant edits [18:50:25] "stop the bot once there are objections" https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/Addbot_5 [18:51:28] Seems to have stopped a couple of minutes ago [18:52:09] precision 9, what is that again? [18:53:03] const PRECISION_YEAR = 9; [18:53:56] So how did https://www.wikidata.org/w/index.php?title=Q19685737&curid=21286565&diff=378261089&oldid=207793112 get in the list? [18:54:33] It probably ignores the precision. [18:54:50] https://phabricator.wikimedia.org/T105100 talks about it [18:55:43] if(timeValue.getPreferredCalendarModel().equals( this.gregorianCalendar ) [18:55:43] + && timeValue.getYear() < 1584) { [19:14:11] sjoerddebruin: Had ik je https://www.wikidata.org/wiki/Wikidata:Database_reports/Complex_constraint_violations/P650#Biografisch_Portaal_artists_without_RKDartists laten zien? [19:14:12] DanielK_WMDE: I'm fixing the test but EntityNamespaceLookup is a final class and it doesn't inherit any parent class. Is that intentional? [19:14:26] multichill: nee [19:14:32] Dat is mooi prijsschieten [19:15:20] https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/master/lib/includes/Store/EntityNamespaceLookup.php#L19 [19:15:49] sjoerddebruin: Net ff te weinig om met een bot te doen [19:16:16] Ik zat wel weer na te denken over botruns, die van de NTA is ook al maanden geleden. [19:16:44] Maar heel veel staan ook in de VIAF, hoewel ze het niet doen... [19:17:56] Ik heb de afgelopen dagen weer eens contact gehad met RKD. Naar aanleiding daar van maar weer eens RKDimages opgeschoond en wat meer rapportjes aangezet [19:18:19] Ze gaan elke maandag dicht, zag ik vanmorgen in mijn inbox. [19:18:33] Goede doelen voor 2017. :) [19:18:40] Maandag dicht? [19:20:15] "Wij digitaliseren de komende maanden onze gehele beeldcollectie! Vanaf eind 2017 is deze volledig doorzoekbaar op onze website, een unicum! Om dit mogelijke te maken is het RKD vanaf 3 oktober ELKE MAANDAG gesloten. Wij hopen op uw begrip." [19:20:21] Het fysieke RKD dan. :) [19:23:49] Jane is er vandaag. Ik ga er binnenkort een keertje langs [19:23:57] Wellicht om maandag, dan is het lekker rustig ;-) [19:24:07] Hm, lijkt mij ook wel een keer leuk. [19:30:30] Ben trouwens met jouw achtertuin bezig sjoerddebruin, zie https://www.wikidata.org/wiki/User:Multichill/Paintings_in_the_Groninger_Museum [19:30:40] Dat zie ik allemaal wel hoor. :) [19:32:15] does anyone know the url of the import interface of Mix N'Match ? [19:32:33] It's very well hidden, one moment. [19:33:18] https://tools.wmflabs.org/mix-n-match/import.php :) [19:33:33] I wonder why he puts NOINDEX on so much useful pages. [19:33:46] Haha, mooi. Dan zie je ook dat ik een hoop stadgenoten aan het aanmaken ben [19:34:37] Amir1: no, there is no good reason for EntityNamespaceLookup to be final. On the other hand, you don't really need to mock it. You can just construct a new instance from an array. it's trivial. [19:35:12] Amir1: new EntityNamespaceLookup( [ Item::TYPE => NS_MAIN ] ) [19:35:13] thanks a lot [19:35:14] Amir1: done [19:35:24] the resulting import will be nice [19:35:35] DanielK_WMDE: I see it now [19:35:36] thanks [19:35:41] I also fixed the other patch too [19:35:42] Amir1: i didn't check earlier, sorry ;) [19:35:57] going home now [19:36:37] Amir1: $label = $label === null ? $entityId : $entityId; [19:36:43] Amir1: that doesn't look right :) [19:36:58] oops [19:36:59] :D [19:37:39] I don't know the compact system in php [19:37:40] sorry [19:37:43] Amir1: soooo... apparently there is no test case covering this. otherwise you would have noticed. could you add one? [19:37:49] let me double check [19:38:26] hmm, Let me give it a try [19:43:43] ttfn [19:54:15] https://tools.wmflabs.org/mix-n-match/?mode=catalog_details&catalog=243 [19:54:23] Eu transparency registry [19:55:03] all EU lobbying organisations [19:55:34] only tiny problem, EN is the matching language, while the catalog is broadly multilingual [19:57:22] most automatches look great though [20:36:00] Hello. I need help on a query timeout ... I try to find a human (wdt:P31 wd:Q5) by a part of it's name (rdfs:label) but the query throw a timeout. Shure my query is not good. Here it is : http://tinyurl.com/hlpcu4u [20:38:30] Cyrille37: the label service is slow and you don’t need it in this case: http://tinyurl.com/j5ufqjp [20:40:44] WikidataFacts: Thanks ! I thought on the contrary that it was an optimization ;-) [20:40:56] also, STRENDS might be slightly faster than REGEX: http://tinyurl.com/zkswa3s [20:41:24] no, it’s just more convenient to use, and usually the performance penalty isn’t too bad [20:55:41] WikidataFacts depends on the complexity of the regular expression used, i guess [20:56:06] yeah, I expected more of a difference here, but it’s barely noticeable [20:56:07] with anchored, non-wildcard regex, it's obviously a lot faster ;-) [20:56:26] good to know the regex engine is optimized :) [20:56:42] (is it just Java regexes? are they identical to XML Schema / SPARQL regexes?) [20:57:08] i assume it's just an implementation of sparql regex that happens to be in java [20:58:04] there could be a fallback to strends/strstarts if the regex is anchored and non-wildcarded, not sure, really haven't looked all that much into blazegraph ;) [20:58:57] (or perhaps even to = if anchored on both sides) [20:59:38] WikidataFacts on another note, have you looked at my post on death rates ? ^^ [20:59:45] no, where is it? [21:00:27] http://wordpress.alphos.fr/2016/09/16/944/sparquickl-2-risque-de-deces/ text is in french, but there isn't much of it, and queries themselves (including comments) are in english [21:01:54] and it will work for the year before current, whatever the current year is too ! :) [21:02:05] 148 Results in 24204 ms [21:02:56] imagine my surprise when i found out that ethiopia was safer than liechtenstein ^^ [21:03:18] wow, that is some expression in étape 4 [21:03:23] I’m surprised that doesn’t time out [21:03:50] wait till you see step 6 :p [21:04:54] and actually, i trust that blazegraph optimizes the xsd:dateTime() calls instead of performing them every time they're needed [21:05:12] (actually, i trust it now that i saw it doesn't timeout) [21:06:11] The mismatches of VIAF still make me sad. https://www.wikidata.org/w/index.php?title=Q3934757&action=history [21:06:29] you can also do the last step without a subquery, actually: http://tinyurl.com/jxrk9ck [21:06:37] but surprisingly that doesn’t make it any faster [21:06:47] usually subqueries are expensive… in this case not, apparently [21:06:59] they're not expensive per se [21:07:10] This one is really weird though. http://viaf.org/viaf/24751797/ [21:07:28] they can be, but they can also make things faster, or even possible [21:08:00] they're particularly useful with aggregating functions over unnatural sets [21:08:42] it's faster to first get a nice set by "cheating" with the data, then aggregate it ; than to do it all in a single step, i found [21:09:00] I’ve found that whenever I reach for them *thinking* that they’ll optimize a query, they just make it much worse :D [21:09:15] you gotta play with them ^^ [21:09:26] if you hit the limit and weren't using one, try one [21:09:57] I originally used them for https://twitter.com/WikidataFacts/status/770701163402555392 and it was horrendously slow [21:10:41] tbh, they're particularly useful to speed up aggregation with SERVICE [21:10:45] I did all kind of ugly workarounds, using wdt:P171/wdt:P171/… chains twelve elements long instead of wdt:P171* to keep it within the time limiit [21:10:59] and then I removed the subquery and it ran in, like, half a second [21:11:29] SERVICE will try to work with every line in your set, before aggregation takes place [21:12:24] so if you have a major aggregation like mine, instead of performing it thousands of times, just aggregate first, then call SERVICE in a metaquery ^^ [21:13:05] good point, I didn’t use the service in that query [21:13:24] WikidataFacts: Sorry, need your help again. I replaced the regex by a value, but no result found => http://tinyurl.com/hdgqjsk [21:14:16] Cyrille37: you need to add the value directly to the ?item rdfs:label triple, and add a language tag: http://tinyurl.com/hal6hoc [21:15:02] WikidataFacts and i prove it : http://tinyurl.com/z5w7fxu 148 Results in 2397 ms [21:15:52] Alphos: very nice [21:16:34] WikidataFacts : experimentation always carries interesting results when you don't know much about a system ^^ [21:38:47] WikidataFacts : post edited to reflect that result, and i pointed to your twitter feed as well ^^ [21:42:16] great [21:43:31] but I don’t know if your explanation is correct, I don’t think that’s how subqueries work [21:43:39] see for example: http://tinyurl.com/z2v23qp [21:43:46] the outer variable isn’t visible in the subquery [21:44:15] in your query, I think the subquery populates ?country, and the first line (?country wdt:P31 wd:Q6256) only runs afterwards and limits the subquery’s results [21:44:26] bind works differently than your regular assignment [21:44:40] I've missed you guys <3 [21:44:48] sjoerddebruin awww [21:44:53] :3 [21:44:59] I was all alone ;_; [21:45:52] WikidataFacts regardless of whether or not the inner knows about the outer ?country, at least it doesn't need to care anymore about ?population or ?countryLabel [21:46:15] yes, that’s probably what makes the difference, it does much less work [21:46:43] in short, the least data you have to aggregate, the better ^^ [21:46:45] but if google translate is accurate, you said that the subquery is run less times [21:46:55] or was that referring to the outer query? [21:46:56] no, i said the entire query takes less time :) [21:47:32] This time saving is that the métarequête is performed once a country, instead of once a death, so, so, obviously, it's faster. [21:47:32] hm, I guess it actually didn’t translate the important part :D [21:47:44] it is made faster by extracting the assignment of ?population and ?*label variables out of the inner query [21:48:00] (which is exactly what's observed ^^ ) [21:48:57] i took the OPTIONAL, BIND(COALESCE()), wdt:P1082 out of the subquery, let them in the metaquery (outer one), and tadaaa, an order of magnitude less time ^^ [22:04:34] WikidataFacts just saw your \p{Lu} query, nice thought :) [22:07:43] yeah, I didn’t want to exclude people like Lech WAŁĘSA by using [A-Z] :) [22:09:04] WikidataFacts quite frankly i didn't even think of [A-Z], i'm a little slow since yesterday [22:09:29] Fucking hell. https://www.wikidata.org/w/index.php?title=Special:Contributions&offset=&limit=500&contribs=user&target=Florentyna&namespace=&tagfilter=&newOnly=1 [22:09:38] A lot of them lack a P31... [22:10:29] forgot to take a dose of "don't-get-the-painful-feeling-of-a-finger-shoved-in-your-eye"-ol two days ago, and i'm paying for it, dearly >_> [22:34:58] SMalyshev: how can I select a precision in sparql? :O [22:35:38] addshore: you mean date precision? [22:35:57] wikibase:timePrecision [22:36:06] https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format#Time [22:41:39] I was trying to work out how to shove it in a query but now I have got it with [ stuff ]! [22:46:11] SMalyshev: one more :/ how about adding the item label to http://tinyurl.com/jojf69f ? [22:47:32] it's possible but I'm afraid it'd be not fast with 88k results [22:48:52] https://www.wikidata.org/wiki/Q19265 is funny. there are probably about 1500 of those :) [23:15:11] addshore http://tinyurl.com/hqtxyq8 will that do ? [23:15:51] (adds item, item label, and property of the claim) [23:16:32] Alphos: thanks! :) I'll take a look in the morning!!! [23:16:51] addshore http://tinyurl.com/htsjdt4 better yet, with optional label [23:17:01] Alphos: does the FILTER(BOUND(?timeValue)) have an effect? [23:17:28] hm, come to think of it, kinda doubt it [23:17:47] it might be blank, perhaps, but I don’t think it can be unbound in this query [23:18:05] just checked, it doesn't [23:18:20] logically, it's obviously bound if it's required by the blank node [23:18:46] (brain is making a bit of a comeback, but not there yet) [23:19:08] 88402 with the BOUND(), 88402 without it [23:19:16] oh, but the datatype does filter out 55 results, that’s interesting [23:19:52] they have xsd:string for whatever reason [23:20:01] even though they look like proper time strings [23:20:03] bug in the database? [23:20:07] oddly enough, the BOUND makes the query marginally faster (15s instead of 18s) [23:20:15] (http://tinyurl.com/gnrwna8) [23:20:40] WikidataFacts m'afraid they're strings [23:20:49] case in point : the leading sign [23:21:10] looks like a proper date in the wikidata.org interface… [23:21:27] http://tinyurl.com/goaxo8p [23:21:36] oh, gregorian calendar has no year 0, that’s why [23:22:13] heh [23:22:43] then again, using the greg cal for "0(B)CE" is kind of odd anyway :p [23:23:17] here’s all those statements, a nice and even 100: http://tinyurl.com/gvmkakk – really surprised that query is as fast as it is [23:26:14] https://www.wikidata.org/wiki/Q6270698#P570 that reference seems kind of odd [23:26:27] i didn't know they had the web back then :D [23:27:06] and they even knew the future, when that guy would die two millennia later! [23:28:09] ikr ! [23:29:03] but then i'm not surprised. one of our most, uh, weirdo politicians announced the death of one of our former presidents after he was hospitalized - turns out, widely overexaggerated [23:30:33] There could be wrong dates due to a bug that saved the date before it was calculated. So if the last calculated date was 20 and I add "00" and hitted the save too quickly, it will add "20". This is fixed though.