[02:53:03] @vrandecic how does one get the Lexemes that represent a Wikidata item? [02:54:05] e.g. for Q62 I'd want to get L414196. This is basically necessary for the current Abstract Wikipedia plan. [02:54:49] The reverse seems to be possible, but I can't see Item -> Lexeme on Wikidata [03:30:04] You'd at least have to specify which language. But I agree, I don't think it is currently possible. [03:48:10] @vrandecic I'd like to propose that RGBA be created next. Originally I was thinking floats would be important, but I don't think they are even of high priority anymore. The color type would allow for some really cool functions. [03:51:10] Actually, I'd support CIELAB being used, since we have been going more for correctness instead of what is standard [03:55:20] Or, if we are being even more bold, CIE CAMO2 [03:57:34] this I believe is what T378097 is an attempt to address (re @Feeglgeef: The reverse seems to be possible, but I can't see Item -> Lexeme on Wikidata) [03:59:07] That would allow Lexeme -> Item, which is much less useful for Abstract Wikipedia than Item -> Lexeme (re @mahir256: this I believe is what T378097 is an attempt to address) [04:28:17] you may wish to look at that task again to see what haswbstatement does (re @Feeglgeef: That would allow Lexeme -> Item, which is much less useful for Abstract Wikipedia than Item -> Lexeme) [06:45:33] @mahir256 is right. That's our current hope on how to impleemnt the Item -> Sense -> Lexeme direction. Currently it is indeed not possible, and yes, such a functionality is very much necessary for Abstract Wikipedia. [12:03:33] Z18683 has just started to cause some test cases to time out in result evaluation, for no apparent reason… 🤔 [12:45:38] I’ve left Z19000 as an example but this could easily be converted to Z19084. [13:40:02] Al GrounderUK I skimmed through your response and it seems like you think I'm proposing things for the actual object [13:40:32] I mean half of it looks like you are and have of it looks like you're not so I'm a bit confused [13:42:15] For point 2, date conversion is problematic in general, but especially in python because of the range [13:42:32] The testing we did with it showed really really really scary results [13:45:45] Ex. Because of the offset system Dec 31, 1 BC + 1 is Jan 1, 0 BC [13:46:18] Then +365 it's Jan 1, -1 BC [13:47:58] I was looking at the problem holistically. I would rather compromise on the object structure than give up on simple and direct representations in code. (re @Feeglgeef: Al GrounderUK I skimmed through your response and it seems like you think I'm proposing things for the actual object) [13:49:57] The main issue I take with creating a date is that it slows it down for people who don't want to do it [13:50:10] And makes it complex for people who don't want to use it [13:50:24] And doing the reverse would not make it hard for the people who do. [13:53:30] In converting to Python, we would be better using a smaller range of AD years and a simple integer offset of some number of 400-year cycles, which is just an adjustment to the year in conversion. (re @Feeglgeef: For point 2, date conversion is problematic in general, but especially in python because of the range) [13:54:18] We tried that (re @Al: In converting to Python, we would be better using a smaller range of AD years and a simple integer offset of some number of 400-...) [13:54:23] It didn't work well [13:54:39] And I don't see this as an improvement in any way [13:54:54] A lot of the functions won't require a date object [13:55:27] So we shouldn't enforce it and the really annoying conversion that comes with it [13:55:53] Let's take an example, subtract N days from date [13:58:21] If we take subtract N days [13:58:28] Perhaps someone could explain the problem on-wiki? (re @Feeglgeef: We tried that) [13:58:39] From 1/1 1 AD [13:58:49] We will get an error if we subtract 1 [13:58:57] So we have to work in the offset anyway [13:59:10] Not using a date object is more convenient here [14:07:04] Anyone who can handle the complexities of date arithmetic without using a date object would have no problem converting such an object into numbers, but the converse is not the case. (re @Feeglgeef: So we have to work in the offset anyway) [14:11:05] date(Z0K1.K1, Z0K1.K2, Z0K1.K3) is not hard (re @Al: Anyone who can handle the complexities of date arithmetic without using a date object would have no problem converting such an o...) [14:12:44] {K1: Z0K1.K1.year + Z0K1.K2, K2: Z0K1.K1.month, K3: Z0K1.K1.day} is [14:18:27] In what context is this? [14:19:16] Top line of some date-related function (re @Al: In what context is this?) [14:19:43] Let's say, add N years [14:28:30] Something like K1`.setMonth(K1.getMonth() + K2)`? [14:29:04] That doesn't have infinite range (re @Al: Something like K1.setMonth(K1.getMonth() + K2)?) [14:29:37] Only 1-9999 [14:30:32] We can have a date in the current era with your conversion later [14:32:48] That’s what the offset is for. But, yeah, for a large K2 you need to know your limits or convert it with %12 [14:33:10] So, it wouldn't work (re @Al: That’s what the offset is for. But, yeah, for a large K2 you need to know your limits or convert it with %12) [14:33:33] The implementation would not be correct if it didn't handle all cases [14:34:02] You'd have to make a %12 and then just not using a date object would have been more simple in the first place [14:34:56] Well, we can’t just convert N because we don’t know whether it’s months, years or bananas. [14:35:33] N would have the name months and the type Integer (re @Al: Well, we can’t just convert N because we don’t know whether it’s months, years or bananas.) [14:35:46] It's literally labeled? Tf you mean we don't know? [14:36:49] I mean the type converter doesn’t know, so converting extreme values to a manageable number of months must remain the coder’s problem. [14:37:26] I'm not sure what you are trying to say (re @Al: I mean the type converter doesn’t know, so converting extreme values to a manageable number of months must remain the coder’s pr...) [14:37:42] Yes, it's the coders problem to deal with any N number of months [14:37:50] wasn't that just an indication that the conversion is wrong? (re @Feeglgeef: The testing we did with it showed really really really scary results) [14:37:55] Otherwise the implementation is objectively wrong [14:38:02] Yes (re @vrandecic: wasn't that just an indication that the conversion is wrong?) [14:38:12] Really really scary results with date + offset [14:38:40] I got Dec 31, 1 BC +1 is in 0 BC [14:39:05] I’m just saying that %12 will apply in any case. (re @Feeglgeef: I'm not sure what you are trying to say) [14:40:01] Yes, so, the date object is actively counterproductive here (re @Al: I’m just saying that %12 will apply in any case.) [14:40:34] @vrandecic any thoughts on this (re @Feeglgeef: Or, if we are being even more bold, CIE CAMO2) [14:41:39] didn't think about colors yet. I don't mind to have a representation for color soonish, why not? A pity we currently can't actually show a color and add a color picker. [14:41:56] No, it just doesn’t avoid the unavoidable. (re @Feeglgeef: Yes, so, the date object is actively counterproductive here) [14:42:27] How would you make the mod12 thing (re @Al: No, it just doesn’t avoid the unavoidable.) [14:42:35] Show me some Pseudocode [14:43:47] { [14:43:48] K1: K1 + Z0K2 // 12, [14:43:49] K2: K2 + Z0K2 % 12, [14:43:51] K3: K3 [14:43:52] } [14:43:56] That should handle any value [14:44:04] How would that be done with dates? [14:45:40] I'm just curious as to what color system we'd want to use [14:45:40] Very standard: RGB [14:45:42] Quite standard, a bit human: HSL [14:45:43] Quite human, not very standard: CIELAB [14:45:45] Very human: CIE CAM02 (re @vrandecic: didn't think about colors yet. I don't mind to have a representation for color soonish, why not? A pity we currently can't actua...) [14:46:32] I don't have an opinion on that and I am happy to read a discussion. Having more than one is always an option. [14:52:37] I personally think CIELAB is best, HSL/HSV would not be horrible. [14:56:30] [[File:SRGB gamut within CIELAB color space mesh.webm]] [14:57:37] Here's why. The shape on the inside is what RGB can cover, the transparent Cube on the outside that the RGB shape is inside of is what CIELAB can cover [14:58:14] I think that's better to be covered on-wiki [14:58:29] Sure [15:03:15] should we add a subpage for "colour operation" on [[Wikifunctions:Catalogue]] ? so far we only have a few but we could easily have a lot more [15:03:16] ping Galder [15:03:40] I'd wait for a type (re @Nicolas: should we add a subpage for "colour operation" on [[Wikifunctions:Catalogue]] ? so far we only have a few but we could easily ha...) [15:03:49] Most of the ones on there are type related [15:05:08] ?? (re @Feeglgeef: I'd wait for a type) [15:05:30] A type for colors (re @Nicolas: ??) [15:06:13] do we really need a type? [15:06:13] and more important: why not catalog properly the *existing* functions? (re @Feeglgeef: A type for colors) [15:06:40] We don't need one (re @Nicolas: do we really need a type? [15:06:40] and more important: why not catalog properly the *existing* functions?) [15:06:49] Just saying, we don't have many [15:07:05] We likely will have more if a type is created [15:09:31] of course a type would be useful *for the functions themeselves* [15:09:31] but do we need a type *for cataloguing*? [15:09:33] right now there is a dozen of function around colours, how to find them without a proper cataloguing? [15:10:10] I just said no, tf? (re @Nicolas: of course a type would be useful *for the functions themeselves* [15:10:11] but do we need a type *for cataloguing*? [15:10:12] right now there is a d...) [15:10:14] quite busy in the next... 3 weeks? (re @Nicolas: should we add a subpage for "colour operation" on [[Wikifunctions:Catalogue]] ? so far we only have a few but we could easily ha...) [15:12:13] I could do it myself, I'm just wondering if anyone has any objection (re @Galder: quite busy in the next... 3 weeks?) [15:12:47] language, please (re @Feeglgeef: I just said no, tf?) [15:12:56] none from me (re @Nicolas: I could do it myself, I'm just wondering if anyone has any objection) [15:13:30] a (re @lucaswerkmeister: what the hell) [15:13:33] you are not clear [15:13:34] you think we don't need a type for cataloguing but you'd still wait for some unexplicited reasons? (re @Feeglgeef: I just said no, tf?) [15:15:03] a (re @mahir256: since it's only a stepping stone away from "making shit up") [15:15:14] please stop spamming me with pointless notifications like this (re @Feeglgeef: a) [15:15:27] I saw a notification “a” in a channel with dozens of unread messages, what do you expect me to do with that [15:15:46] I'm trying to quote it (re @lucaswerkmeister: please stop spamming me with pointless notifications like this) [15:16:07] This seems to only apply to me? (re @vrandecic: language, please) [15:17:31] no, but you're the one swearing the most and for no apparent reasons (re @Feeglgeef: This seems to only apply to me?) [15:17:45] it applies to everyone and it's about 'density' as well. I realize I could also have sent that privately, without the public effect. [15:21:39] I'd also argue that "tf" is enough of an amelioration to be appropriate, but ok (re @vrandecic: language, please) [15:23:56] it's absolutely not, especially in this context (where you seems angry at me that you already said no when you actually didn't clearly said no...) (re @Feeglgeef: I'd also argue that "tf" is enough of an amelioration to be appropriate, but ok) [15:25:03] It was intended as an expression of confusion (re @Nicolas: it's absolutely not, especially in this context (where you seems angry at me that you already said no when you actually didn't c...) [15:25:34] This also backs up my amelioration point (re @Nicolas: no, but you're the one swearing the most and for no apparent reasons) [15:30:04] I apologize if this was phrased too harshly (re @lucaswerkmeister: what the hell) [15:30:11] maybe I should just go back to not writing anything in this channel instead [15:31:51] I would prefer this channel to be a place where you want to contribute, and I am sorry that it currently is questionable whether it is [15:32:09] I'll do that for a bit (re @lucaswerkmeister: maybe I should just go back to not writing anything in this channel instead) [15:33:17] I've turned off notifications on Telegram for a week, ping me on-wiki if you do need anything. [19:54:30] If anyone is interested in the keynote from @vrandecic at SWIB24: https://youtu.be/NmCbTOZ4Yos?si=AWxaIdVBLiAIJnYI [20:13:05] I hope you enjoy it! [20:13:30] I wrote up the proposals for the conversion of the Gregorian calendar date: https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/Gregorian_calendar_date [20:42:26] A really good presentation, a joy to watch! (re @vrandecic: I hope you enjoy it!) [21:15:53] Thank you! It was a very friendly community [21:49:06] Thanks, Denny. I’m not too bothered about JavaScript but I’m really struggling to feel comfortable with a three-key solution for Python. How soon do you want comments? (re @vrandecic: I wrote up the proposals for the conversion of the Gregorian calendar date: https://www.wikifunctions.org/wiki/Wikifunctions:Typ...) [22:54:57] How long did it take? (re @vrandecic: but you may need to bring patience, as Mahir can attest 😛) [22:57:24] I wrote the newsletter alluded to in January, and had shown it to the team that month, but it was forgotten afterwards (re @Feeglgeef: How long did it take?)