[08:44:04] Change on 12www.mediawiki.org a page Extension:Wikibase Client was modified, changed by Thiemo Mättig (WMDE) link https://www.mediawiki.org/w/index.php?diff=2476543 edit summary: [+17] Fixed broken link [14:05:18] any Wikidata sysop here? PM please! thnx [14:09:15] MisterSynergy: hi! [14:09:19] hey [14:18:13] done; thanks to sjoerddebruin [14:36:24] sjoerddebruin : showoff ! :-p [14:45:59] Alphos: what? :D [14:46:24] "any sysop ?" [16:11:59] * ChanServ gives channel operator status to sjoerddebruin /// :D [14:47:22] Wrong chat [14:47:36] ^^ [18:20:18] Yes [19:10:34] sjoerddebruin: Mind having a look at https://www.wikidata.org/wiki/Wikidata:Requests_for_deletions#Q29975888_.26_Q29975869 ? [19:10:55] I've already read his response. I don't understand him. [19:15:08] the response doesn't make any sense to me, they've linked the same item as one we can delete and one we can't [19:15:36] https://www.wikidata.org/wiki/User_talk:PokestarFan is not good [19:15:47] Using all sorts of automated tools and causing a mess [19:16:14] Things like https://www.wikidata.org/w/index.php?title=Q11813&type=revision&diff=491473140&oldid=489212835 (corrected) [19:17:26] I wonder why I even bother to list it there if nobody responds anyway [19:24:51] multichil: i'm reading [19:25:04] I think it's time for a block. [19:29:06] * nikki is replying to the rfd thing [19:35:54] multichil: I replied [19:36:13] sjoerddebruin: (s)he should get a clear warning first I think [19:36:24] Hm, ok. [19:37:17] Thank you nikki [19:40:07] nikki: Do you have any idea how complete the set of years is from say 10 to 2100? [19:42:02] http://tinyurl.com/y8rxtkfs suggests it's complete, plus one extra [19:42:04] err [19:42:05] up to now [19:42:57] seems to be complete up to 2100 too [19:45:37] bah, https://www.wikidata.org/wiki/Q16131968 shows up in there... seems like the only way to filter out the ones I don't want is to mess about with qualifiers x_x [19:46:41] Oh fun [19:47:13] times like that I would argue that a new item would be useful, since it would make queries a lot easier :P [19:47:31] (like "year of the hebrew calendar" as a subclass of year) [19:47:57] 'cause I imagine most of the time people are looking for years of a specific calendar, not just anything that happens to be a year in some calendar [19:50:02] that “point in time” seems weird, shouldn’t it be start time + end time? [19:51:34] I guess that would technically be more accurate, I wouldn't want to change it without checking nobody's using the existing data though [19:51:44] Both are correct [19:51:59] 2016 is a point of time with the precision of 1 year [19:53:11] multichil: but it only works out for Gregorian years because that’s also the calendar that the “point in time” datatype uses [19:53:16] we don't distinguish between cases where it applies to the whole year and cases where it's something more specific but we don't/can't say more precisely [19:56:04] like 2016 as the point in time of a population statement most likely refers to some particular point during the year, not the entire year... but for a year we do mean the entire year [19:56:40] (if it's not clear, I'm explaining why I think what WikidataFacts suggested would be more accurate) [19:57:53] I agree with the “year of the Hebrew calendar” item btw [19:58:15] but I’m not sure what the corresponding item for “““normal””” should be [19:58:33] is it a gregorian year? a proleptic gregorian year? a julian year? all of them? [19:59:29] afaik it’ll take tens of thousands of years for the two to diverge by over one full year, so it doesn’t really make a difference [19:59:39] but it needs to be something distinct from the general “year” class [20:07:14] hm... start/end dates would also be a bit weird for the ones where julian/gregorian overlap [20:08:30] hm, good point [20:13:22] anyway whether people want to add multiple p31s or a new item with an awkward name that joins them together, I wouldn't really mind, as long as it's clear what it is [20:13:27] not sure I want to try changing it though... [20:26:38] Hello