[00:39:14] I just read this page https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Early_function_examples and looked up kleenean (https://en.wikipedia.org/wiki/Three-valued_logic), which has a vague correspondence with our new "sign" type (both have three enumerated values). Should we start writing functions representing Kleene and Priest logic using the sign type (and give [00:39:14] additional al [00:39:15] iases to positive/negative/neutral), or should we wait and make a separate type with values more explicitly enumerated (true, false, unknown/unknowable/undecidable/irrelevant/both)? [03:23:14] I would prefer to make a Kleenean type, one not overload Sign with that, unless other people disagree. Just to be able to keep the nomenclature as close as possible to the standard nomenclature. [03:24:12] #1 with UTF32 is the same as #2 x 4 (re @Toby: So is the python function giving us #1 with UTF32, or #2? Or are they always the same?) [03:28:45] I'm comfortable with that. The only advantages of overloading I can think of would be if we were deliberately minimising the number of types, or if a sign output from one function could reasonably be understood as a kleenean input to another. (re @vrandecic: I would prefer to make a Kleenean type, one not overload Sign with that, unless other people disagree. Just to be [03:28:45] able to keep t...) [08:49:52] Hmmm… 🤔 I agree that Kleenean and Sign are probably best kept separate, but I suspect they might be better considered as “systems” over an abstract trivalent type. The standard nomenclatures are then a series of ultra-thin functional wrappers. It may be that such an approach generally allows the similarities and differences to be more clearly seen. (I feel a Project Chat [08:49:52] [08:49:52] topic coming on.) (re @vrandecic: I would prefer to make a Kleenean type, one not overload Sign with that, unless other people disagree. Just to be able to keep t...) [12:54:47] Another question I had is whether True and False would still map to the same ZIDs as the existing ones (I assume not, because they are already typed Boolean). And then I guess we won't be able to map two different True's to the same Wikidata item. So maybe it was good that we kept identity away from Wikidata? [14:26:45] I think Boolean and Kleenean True are the same concept, although its negation is interpreted differently in the different systems. But you are right that, in practice, Kleenean true could not be "Z41". Both “true” identities could point to the same Wikidata item (by function or by additional key) just as many lexical item senses may have the same P5137 Item. (re @Toby: [14:26:45] Anothe [14:26:46] r question I had is whether True and False would still map to the same ZIDs as the existing ones (I assume not, because th...) [14:28:21] I guess I should have written it the other way around: Wikidata can't point from the same Q-item to two different ZIDs. [14:44:05] I guess we could just make a "Kleenean True" QID, which would include "said to be the same as" the regular "True" QID. Then they could link to their respective ZIDs. [14:45:15] Someone did 😏 Z17057 [19:24:51] [I’ve copied this to https://www.wikifunctions.org/wiki/Wikifunctions:Project_chat#Overloading_types (without further comment)]