[10:27:09] *** Joins: michmech (~Thunderbi@235.221.broadband10.iol.cz) [10:27:17] *** Parts: michmech (~Thunderbi@235.221.broadband10.iol.cz) () [10:32:59] reading this from the perspective of GF, some of the things don't feel like fundamental problems at all https://meta.wikimedia.org/wiki/Talk:Abstract_Wikipedia#Some_questions_and_concerns [11:12:42] inariksit: cool, it seems there is someone at google who knows about GF. but he doesn't seem to completely understand it [11:24:03] I think the person who wrote the questions and concerns is a different person from the one who knows about GF [11:24:18] but anyway, that person doesn't seem to understand how abstract an abstract syntax can be [11:32:43] yes, i am only refering to the first mention of GF where the person doubts that lossless translation is possible [12:00:41] the person with the original idea has written on the gf list between 2014-2017, and I think he has an accurate idea what gf can do https://groups.google.com/g/gf-dev/search?q=denny [12:40:59] But denny made a statement kind of contradicting this: "@GrounderUK: Grammatical Framework has grammars that are indeed bi-directional, and some of the other solutions have that too. To be honest, I don't buy it - it seems that all renderings are always lossy. Just go from a language such as German that uses gendered professions to a language such as Turkish or English that does not. There is a necessary loss [12:41:05] of information in the English and Turkish translation. --DVrandecic (WMF) (talk) 00:47, 5 August 2020 (UTC)" [12:41:22] ah, I see [12:44:02] in some way denny is right, but only if you throw away the abstract syntax after translating to english [12:44:30] if you start from plain english you would e.g. get both genders for doctor in a gendered language [12:45:04] yep [12:45:44] the abstract description of the wiki article needs to include doctorFem_N instead of doctor_N for an article that talks about a female doctor [12:46:04] I may have misunderstood, but I imagine they're only targeting linearisation, not parsing [13:05:49] I interpreted it as wanting to parse as well, so people can write the articles in natural language, or at least edit existing text in linearized form. Requiring that every editor learns to write in the abstract syntax seems like a way too high barrier of entry for this kind of project. [13:07:09] But maybe they can make the editor for the abstract syntax nice and convenient so it suits the purpose better. [13:15:28] "Suppose we didn’t know about the Uzbek uncle situation and we add Uzbek. Suddenly, we have to code maternal/paternal lineage on every instance of uncle everywhere. Finding volunteers to do the new uncle encoding seems like it could be difficult. " [13:15:43] I think that sounds like there is an editable abstract representation somewhere [13:15:55] but of course it could be on top of a parsing-based approach [13:18:09] as for fundamental issues, I'm more cautious about this [13:18:11] 12:35:07 < spectie> > Incompatible cultural "facts" [13:18:11] 12:35:56 < spectie> depending on the area, this is quite a minefield, and could end up being basically colonialism through information [13:18:11] 12:36:09 < spectie> e.g. in maths/programming probably this is fine [13:18:11] 12:36:28 < Nemo_bis> that's the entire reason we have completely separate Wikipedia subdomains [13:18:11] 12:36:29 < spectie> but i would want to think very carefully before introducing this stuff for e.g. history or culture [13:18:12] 12:41:28 < spectie> (it's hard enough to combat systemic bias with existing articles *plugs {{indigenous}} template*, let alone trying to do it when articles are generated using "culture-neutral" "facts") [14:41:16] inariksit: where are these quotes coming from? [14:50:18] the irc quotes? [14:50:20] from the #hfst channel (helsinki finite state technology) [16:06:35] ah, okay