[04:43:09] I think we need a lexeme form parser. I can't make a test at Z19271 : https://tools-static.wmflabs.org/bridgebot/54fd30b4/file_65787.jpg [05:23:37] Senses are not coming across from WD in part of the lexeme, resulting in Key Not Found when running Z19282 . Jsamwrites has been trying hard at Z19265, but I think he is fundamentally blocked by this. [06:58:15] It’s finally implemented?! (re @vrandecic: Newsletter 176: [06:58:17] * What could abstract content look like? - Guest contribution by @mahir256 [06:58:18] * Recent Changes in the software [06:58:19] * ...) [07:04:16] How can I query a property in a certain lexeme [07:07:44] Or query a declaration (re @cvictorovich: How can I query a property in a certain lexeme) [07:28:14] Looking forward to see what you do. The thing with the cases is pretty much exactly what we would like to be able to support by the end of the quarter, so everything still missing would be interesting. (re @hogue_456: At the moment there are many topics for what I dont know how to represent the data in Wikidata and so it is difficult to write a...) [07:28:44] Did I make myself clear (re @cvictorovich: Or query a declaration) [07:32:35] That looks weird, I think that's a bug. The fetch should be implicit, it shouldn't be displayed. Thanks for raising this, will file a task. (re @Toby: I think we need a lexeme form parser. I can't make a test at Z19271) [07:35:55] Toby I think if you switch the argument type to a Wikidata lexeme form reference, it should work for now, but then you need to call the fect explicitly in the composition. [07:40:07] Filed T377545 [07:43:27] That's correct, senses are still missing. I filed T377547 (re @Toby: Senses are not coming across from WD in part of the lexeme, resulting in Key Not Found when running Z19282 . Jsamwrites has been...) [07:44:18] Sorry, no. What do you mean with query a property or a declaration? Can you give me an example function call and result? (re @cvictorovich: Did I make myself clear) [07:44:32] Example: I query value of P5186 for L715268 (re @cvictorovich: Or query a declaration) [07:44:56] How can I implement this action inside a function [07:45:06] Ok, I understand that question [07:49:41] I made some functions need this action before but halted until Wikidata querying became available. Now I can update those functions [07:54:00] So it currently fails with L715268 because it fails for large Lexemes, filed as T377338 [07:54:46] But you can go to Z6825 and try it with a smaller Lexeme, such as L42243 [07:55:48] There you see the structure of how the Lexeme is represented in Wikifunctions, and you can see the claims [07:56:07] Does this get you on the right way? If not, I can try to implement it when I have some time [07:56:29] (I am not promising it will work, but I think it should) [08:08:22] Smaller means having less forms? [08:08:58] I would try to implement my previous functions [08:11:07] @vrandecic Tested with L20643 but P5186 didn’t return [11:29:46] Okay, Denny isn’t here, but my problem is yet to be solved… [11:30:16] I need some instructions very very much [11:32:19] Some functions doesn't return things I need (re @cvictorovich: Example: I query value of P5186 for L715268) [11:34:59] This is what I need (re @cvictorovich: @vrandecic Tested with L20643 but P5186 didn’t return) [11:35:11] I might be able to help. Let me read what you've already written. [11:37:03] See my things above [11:39:22] Yes, still reading and trying it out sorry. [11:40:42] If I didn't make something clear I may put more details [11:42:16] I agree that P5186 does not seem to be returned as a statement when I run Z6825 with an argument of L20643. I'm trying to see what is returned and whether it is obvious why that one is different. [11:43:34] I need P5186 returned and as an intermediate variable for later actions [11:44:10] My example: Z12440 [11:48:06] Only when the function gan get value of P5186 can it know "does this French verb belong to group x" [11:48:39] Ok. I think all of the statements returned in the Z6005K5 key are claims where the value is a string, not where the value is a different Wikidata item QID. So I don't think you are able to do what you need yet. [11:49:41] If QID is returned by a string then it's okay [11:51:06] I expect Qitems will be returned as a different type of object: Z6091. But I agree with you that they are not currently returned. [11:54:31] The only exceptions are that QIDs are returned for the lexical category for the lexeme and grammatical features of the forms. Otherwise there are no QIDs from the other claims. [11:56:23] So overall, I think you are waiting for a feature which is still not implemented. I'm not sure if the development team know that this is still not fully implemented, or if it is a bug. It looks similar to the fact that senses are also not returned yet. [12:11:52] Hopefully Denny would see it [12:17:37] Looks like a bug to me. We are getting a list of “Identifiers”(as Wikidata statements) rather than a list of “Statements”. Z6005K5 should be a list of “claims” (which might be supposed to include both Statements and Identifiers). [12:27:19] My hypothesis is that it's according to what type the value is. I think claims with string values are supported, but claims with other types of value are not. (re @Al: Looks like a bug to me. We are getting a list of “Identifiers”(as Wikidata statements) rather than a list of “Statements”. Z6005...) [12:33:43] You could be right, but Lexical category specifically returns a QID as a string “Wikidata item reference”, which is what I would expect for the P5185 of L11620 (to use the example in the Type proposal) 🤷‍♂️ (re @Toby: My hypothesis is that it's according to what type the value is. I think claims with string values are supported, but claims with...) [12:38:18] Toby is correct. Sorry, I thought this was already available, but I was mistaken. So we need to extend to cover statements that are pointing to items. [12:38:47] It is not possible currently, we need to extend that. That's definitely part of the work in this quarter, because it is needed for our driving use case. [12:46:07] In other news, I've finally understood how "Value by Key" works and what it's for. I realise how slow this demonstrates I am! [12:46:35] I think it demonstrates how lacking our documentation is [12:47:31] I don't always read documentation... (re @vrandecic: I think it demonstrates how lacking our documentation is) [12:50:55] Given that a lexeme type has 7 keys, I feel that a priority with each new type should be 7 functions to extract each of its keys, so they can then be dealt with separately. [12:52:32] I disconnected current implements for my functions (re @vrandecic: It is not possible currently, we need to extend that. That's definitely part of the work in this quarter, because it is needed f...) [12:52:50] They don't function well without querying from Wikidata [12:53:53] French verb has 3 groups, whilst group 2 has too many exceptions! [12:54:08] so far I have made two fairly useless ones: Z19283 and Z19286, so 5 to go (re @Toby: Given that a lexeme type has 7 keys, I feel that a priority with each new type should be 7 functions to extract each of its keys...) [12:54:10] I cannot cover them all [12:55:36] Most verbs ending in -er are in group 1; many to most verbs ending in -ir are in group 2; everything else falls in group 3! (re @cvictorovich: French verb has 3 groups, whilst group 2 has too many exceptions!) [12:56:09] Why "many to most"? For too many exceptions! (re @cvictorovich: Most verbs ending in -er are in group 1; many to most verbs ending in -ir are in group 2; everything else falls in group 3!) [12:56:17] I’ll see what’s outstanding later 😎👍 (re @Toby: so far I have made two fairly useless ones: Z19283 and Z19286, so 5 to go) [12:57:32] Group 3 verbs are shockingly irregular (re @cvictorovich: Most verbs ending in -er are in group 1; many to most verbs ending in -ir are in group 2; everything else falls in group 3!) [13:14:59] FYI the lexeme selector doesn't seem to work unless you always want to choose the very first item on the list: T377540 [13:21:25] yes, thanks for the report 🙁 [13:21:53] How long would it take before fix [13:22:50] there's a workaround, you can use the LID [13:38:17] I've now made all 7 and listed them on the catalogue. Obviously senses isn't working, but I think the rest are. I haven't put proper tests on them yet. Z19285 Z19293 Z19295 Z19298 Z19300 Z19282 Z19302 (re @Toby: Given that a lexeme type has 7 keys, I feel that a priority with each new type should be 7 functions to extract each of its keys...) [13:39:38] I'm off to bed now. You can split all the other new Types if you want 😊 (re @Al: I’ll see what’s outstanding later 😎👍) [13:43:39] @vrandecic speaking of equality functions. Once we write them, would it make sense to add them to the type itself? e.g. Z19267 could be added to Z6092.