[05:08:00] Thanks for raising this. A while back we made a conscious decision not to include the statement IDs, for good reasons I think. And including claims with qualifiers are deliberately not imported at present; for future work. (re @u99of9: David it seems like claims with qualifiers are not coming through the fetch. Or at least that's my guess at why running Z6821 wi...) [05:13:19] Thanks for raising this. A while back we made a conscious decision not to include the statement IDs, for good reasons I think. it's end of day for me, so I will say more tomorrow. (re @u99of9: This page: [[Wikifunctions:Support_for_Wikidata_content]] says that "Because Statements in Wikidata do not have public identifie...) [05:17:12] Claims with qualifiers are deliberately not imported at present; left for future work when there's more time to figure out & implement the best representation. I'd be interested to hear perspectives on the priority of adding claims with qualifiers. (re @u99of9: David it seems like claims with qualifiers are not coming through the fetch. Or at least that's my guess at [05:17:13] why running Z6821 wi...) [05:18:01] An early (hopefully easy) intermediate would be to bring in the bare claim and leave off the qualifier. (re @David: Claims with qualifiers are deliberately not imported at present; left for future work when there's more time to figure out & imp...) [08:54:46] I think this applies more generally: the silent omission of statements should be avoided, so incomplete (degenerate) statement representations should be returned when their representation in full is not currently possible. That said, the ability to specify that certain property types should be excluded from retrieval (if supported) could be extended to support the [08:54:46] exclusion of de [08:54:47] generate statements, irrespective of property type. (re @u99of9: An early (hopefully easy) intermediate would be to bring in the bare claim and leave off the qualifier. Qualifiers can be added ...) [09:17:14] I agree, although I am only aware of two classes of silent omission. One due to qualifiers. The other due to unsupported value types (for which there is no degenerate representation possible, so we just need to wait until the types are supported). Are there other classes I'm unaware of? (re @Al: I think this applies more generally: the silent omission of statements [09:17:14] should be avoi [09:17:15] ded, so incomplete (degenerate) statement r...) [09:30:57] I’m not aware of any… but a degenerate representation of an unsupported value is simple enough: it just doesn’t give you the value. If a person’s date of birth is present on Wikidata, its Wikifunctions representation could be just a P569 statement (perhaps with a string placeholder like “”). (re @u99of9: I agree, although I am only aware of two classes [09:30:57] [09:30:57] of silent omission. One due to qualifiers. The other due to unsupported value t...) [09:48:53] Okay I understand. Yes this might sometimes be beneficial. (re @Al: I’m not aware of any… but a degenerate representation of an unsupported value is simple enough: it just doesn’t give you the val...) [09:57:40] Forwarded from AaronPaynebot: Good works deserves good recommendation, I appreciate the effort of @Trader_Rice for helping me work from home despite being quarantined. Profits been made daily as he promised, i invested $100 and now making $1,500 after 24hours, All thanks to him. wouldn’t have been easy during this lock down he made me and my Family smile, Send [09:57:41] him a DM and thank me later [09:57:41] 💌💌💌❤️ [10:40:15] The new typeahead search in the Search widget is a welcome enhancement. Unfortunately, it doesn’t ignore an initial colon, so I’ve had to amend my search default to restrict searches to the Main namespace. Should we special case an initial colon somehow? [14:19:14] https://www.wikifunctions.org/wiki/Wikifunctions:Project_chat#Numeric_type_:_Real_number_? [14:20:19] Looking at this discussion (https://www.wikifunctions.org/wiki/Wikifunctions:Project_chat#Numeric_type_:_Real_number_?), I'm wondering—is wikifunctions.org not connected to Restbase? That's usually the thing that causes failures to render Math formulas. [14:21:31] It typically happens when a Wikipedia is created in a new language: the domain is created first, and some other services, like Content Translation, Wikidata, and Restbase, are enabled a few days later, and during these days, those things don't work. [14:23:39] AFAIK, Restbase is not used for many things except rendering Math formulas, and in some time in the future it is going to be completely disabled, and rendering Math will be moved to something else. But since it hasn't happened yet, perhaps Wikifunctions should be connected to Restbase so that people can use Math formulas? [14:25:05] Or maybe it is connected, and the rendering errors are caused by something else? [17:36:28] Right; those are the only two classes of silent omission of statements. We are currently working on plans to create and support Wikifunctions types for Quantity, Point-in time, and Geographical region. As folks probably know, there is an (outdated) type proposal for these. [17:36:29] https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/Wikidata_value (re @u99of9: I agree, although I am only aware of two classes of silent omission. One due to qualifiers. The other due to unsupported value t...) [17:42:42] agreed that it's higher priority to get the other value types in place. But there's a concern about importing qualified statements and omitting the qualifiers. Qualifiers can be important for understanding the truth-conditions of a statement, so these statements could become a source of misinformation. (re @u99of9: An early (hopefully easy) intermediate would be to [17:42:42] bring in [17:42:42] the bare claim and leave off the qualifier. Qualifiers can be added ...) [18:41:49] Regarding statement identifiers, I originally thought they would be useful for providing a simple way to determine equality of 2 statements, but it's simple enough to compare statements based on subject/property/value. If there is a function that takes a statement as input, e.g. for comparison to statements retrieved from Wikidata, one can easily and intuitively [18:41:49] specify the subj [18:41:50] ect/property/value, and it would be an unnecessary overhead to figure out the ID. Absent any other use cases, then, it has seemed like these IDs would just be clutter, and sometimes would cause confusion regarding what to do with them. [18:42:04] If there are other use cases, let's consider whether they outweigh the concerns expressed above. If so, it would still be possible to add the ID to Z6003 as Z6003K5, without causing any disruption to existing functions. [18:42:19] Regarding wbgetclaims, calling it with an ID seems to have little utility: the result doesn't specify the subject of the statement, so for the retrieved claim to be useful you would need to already know the subject's ID, and if you know that you already have ways to retrieve its claims. [18:47:11] It’s a valid concern, but silently omitting a claim is also a source of misinformation. We can’t judge each case on its merits but we can at least flag there is some incomplete information. (re @David: agreed that it's higher priority to get the other value types in place. But there's a concern about importing qualified stateme...) [19:31:10] Hmm… I’m getting an odd error with Z18130. A new implementation in Python with just “return True”produces an enormous error and the browser hangs. [19:34:46] JavaScript is similarly afflicted. [23:08:27] It seems to be a new/different manifestation of the typed/untyped lists problems. It just times out in compositions (but succeeds if the lists are Z1-typed) (re @Al: Hmm… I’m getting an odd error with Z18130. A new implementation in Python with just “return True”produces an enormous error and ...) [23:22:32] Do you also see these blank month-dropdowns when you go to edit at https://www.wikifunctions.org/wiki/Z16710?uselang=en&action=edit : https://tools-static.wmflabs.org/bridgebot/d1a102b7/file_69464.jpg [23:23:49] Yes. (re @u99of9: Do you also see these blank month-dropdowns when you go to edit at https://www.wikifunctions.org/wiki/Z16710?uselang=en&action=e...) [23:24:43] and now no. (re @u99of9: Do you also see these blank month-dropdowns when you go to edit at https://www.wikifunctions.org/wiki/Z16710?uselang=en&action=e...) [23:28:47] Looks like they populate on the second expand action 🤔 (re @u99of9: Do you also see these blank month-dropdowns when you go to edit at https://www.wikifunctions.org/wiki/Z16710?uselang=en&action=e...) [23:29:39] Oh, that's like when you want to put a reference in value by reference. (re @Al: Looks like they populate on the second expand action 🤔) [23:30:29] Not a whole lot like that 😏 (re @u99of9: Oh, that's like when you want to put a reference in value by reference.) [23:40:28] Seems to be localised… I’ll file a ticket tomorrow. (re @Al: It seems to be a new/different manifestation of the typed/untyped lists problems. It just times out in compositions (but succeed...)