[08:44:20] I got a notification about this today. https://www.wikidata.org/w/index.php?title=Q465749&oldid=2478929946 [08:44:22] Someone used QS to connect abstractwiki articles on WD. [08:44:23] I think that should be automated. WDYT? [08:46:03] yes, for main namespace pages, yes it should be automated (like the Cognate extension does for Wiktionaries ?) (re @Npriskorn: I got a notification about this today. https://www.wikidata.org/w/index.php?title=Q465749&oldid=2478929946 [08:46:04] Someone used QS to co...) [08:47:11] ^ (re @wikilinksbot: T421151 – Abstract Wikipedia to automatically connect as a Sitelink in Wikidata [open]) [08:50:02] Another gift from the team 🤩🎁 (re @vrandecic: New type implemented from the Type proposals list: Complex numbers ( https://www.wikifunctions.org/wiki/Wikifunctions:Catalogue/...) [13:22:45] A question: how difficult is it to change an already defined and commonly used type? [13:24:27] It depends on the change. What did you have in mind? (re @dvd_ccc27919: A question: how difficult is it to change an already defined and commonly used type?) [13:31:48] It was for the proposal [[Wikifunctions:Type proposals/Abstract sentence]], since one of its main criticities would be that it would make type changes a lot more frequest (re @Al: It depends on the change. What did you have in mind?) [13:33:16] The most likely changes would be insertion of new keys and insertion of new elements in (both standard and lightweight Wikidata) enumerations (re @Al: It depends on the change. What did you have in mind?) [13:34:14] With a lot of objects of the modified type already present in Abstract Wikipedia [13:34:23] I see… it’s a bit like changing a function signature, only worse, don’t you think? (re @dvd_ccc27919: It was for the proposal [[Wikifunctions:Type proposals/Abstract sentence]], since one of its main criticities would be that it w...) [13:36:51] But I see that some objects (like Z6064) lack some keys without being invalid: is this possible with all the types? (re @Al: I see… it’s a bit like changing a function signature, only worse, don’t you think?) [13:40:23] In principle, yes, but the team has that as something to think about. Z6003 has changed more than once and I’m certainly hoping it won’t change again. (re @dvd_ccc27919: But I see that some objects (like Z6064) lack some keys without being invalid: is this possible with all the types?) [13:40:47] And could a validator insert missing keys? [13:43:52] Any function could, I suppose, but that suggests a performance hit 🤔 Why are they types rather than functions anyway? (re @dvd_ccc27919: And could a validator insert missing keys?) [14:11:51] Because they are meant to encode the structure of a sentence; usually the structure of the rendered sentence can be completely different from the abstract one, so it can be necessary to encode the entirety of a sentence to work with it (re @Al: Any function could, I suppose, but that suggests a performance hit 🤔 Why are they types rather than functions anyway?) [18:12:26] Has any progress been made on allowing the community to control the type creation process? I do not believe giving all functioneers the right is a good idea, but there is an existing "Maintainer" group that could perhaps be repurposed into a "Types Maintainer", which would have the rights to create and edit types, and would be granted based on the normal rights [18:12:26] request process? ( [18:12:28] re @vrandecic: New type implemented from the Type proposals list: Complex numbers ( https://www.wikifunctions.org/wiki/Wikifunctions:Catalogue/...) [18:15:06] Actually I suppose it would not be too problematic to allow all functioneers to make and edit lightweight enums but full types seems too dangerous to me. [20:17:07] The typical situation would be: [20:17:08] - A type is created [20:17:10] - The type is used a lot of times in Abstract Wikipedia [20:17:11] - The community realizes that a new key is needed (re @Al: It depends on the change. What did you have in mind?) [20:19:09] The problem with adding a new key is that you need to manually adjust every use of the type. This is why the type approval process often takes so long, to catch these problems early. Can you think of an actual instance of a case where a key might be added to an existing type? (re @dvd_ccc27919: The typical situation would be: [20:19:10] - A type is created [20:19:11] - The type is used a lot of times in Abstract Wikipedia [20:19:13] - The community real...) [20:19:38] The alternative would be [[Wikifunctions:Type proposals/Syntactic unit]], which is substantially the same concept, (re @Feeglgeef: The problem with adding a new key is that you need to manually adjust every use of the type. This is why the type approval proce...) [20:19:54] The alternative would be [[Wikifunctions:Type proposals/Syntactic unit]], which is substantially the same concept, [20:24:43] In particular every test that uses the type, and every implementation that returns the type. (re @Feeglgeef: The problem with adding a new key is that you need to manually adjust every use of the type. This is why the type approval proce...) [20:25:34] The main problem would arise if [[Wikifunctions:Type proposals/Abstract sentence]] is implemented; in this case, as much we can discuss before the type creation, it would still be very likely that not everything is thought in advance. [20:25:35] The alternative would be [[Wikifunctions:Type proposals/Syntactic unit]], which is substantially the same concept, except that it defines what basically is a meta-type (with the keys encoded in a Typed map) [20:27:44] I imagine, if we implement that proposal, then we would have to just be thorough in the proposal process. Any change to an existing type would have to be very-well justified. (re @dvd_ccc27919: The main problem would arise if [[Wikifunctions:Type proposals/Abstract sentence]] is implemented; in this case, as much we can ...) [20:29:31] True, but the type could be encapsulated up-front by a single function (a façade or view pattern). Then existing uses can continue with the old shape while the new shape gets a new encapsulation for cases where the extension is required. (re @Feeglgeef: The problem with adding a new key is that you need to manually adjust every use of the type. This is why the type [20:29:32] approval proce...) [20:41:09] Thanks Feeglgeef and Al, now I've officially ended my support to [[Wikifunctions:Type proposals/Abstract sentence]] in favour of [[Wikifunctions:Type proposals/Syntactic unit]] (with encapsulating constructor functions) [20:51:43] Instead, how difficult is it to add an element to a lightweight Wikidata enumeration? [21:01:14] In principle, it’s very simple indeed; you are just adding an element to the list in the persistent function call. I think that’s all there is to it, but I haven’t had the privilege yet 🤷‍♂️ (re @dvd_ccc27919: Instead, how difficult is it to add an element to a lightweight Wikidata enumeration?) [21:01:20] ... and another little follow-up: Thanks to poking around in a Wikifunctions XML dump file, I also found and reported two bugs in the dump creation process, and also fixed six little bugs in mwxml, the Python library that analyzes dumps (it's for all MediaWiki XML dumps, not just Wikifunctions). Like the doctor in Big Lebowski, I'm (sometimes) thorough. (re @amire80: [21:01:20] I've found a [21:01:20] few bugs and oddities in Wikifunctions thanks to running this tool, and reported them, so I guess that it already c...)