Abstract-Wikipedia November 2024

abstract-wikipedia@lists.wikimedia.org

1 participants
5 discussions

Newsletter #182: WordGraph released; New Special page: list functions by tests; new type for day of the year, and much more
by Denny Vrandečić 27 Nov '24

27 Nov '24

The on-wiki version of this newsletter can be found here: https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-11-27 -- WordGraph: (almost) a million forms for describing people <https://www.wikifunctions.org/wiki/File:Dicti_indent.jpg> A belated present for Wikidata’s 12th birthday: a team at Google Zurich released the WordGraph dataset, almost a million word-forms in a structured representation that is easy to upload to Wikidata. According to its self-description, *“[t]he WordGraph dataset contains multilingual lexicon entries linked to Wikipedia entities, focusing on human-denoting nouns and demonym adjectives. Each lexicon entry contains inflected word-forms and morphological information for all locales.”* The dataset contains 968,153 forms in 39 languages. The dataset is available on GitHub <https://github.com/google-research-datasets/WordGraph> and published under CC0, making it compatible with Wikidata. We created an overview with some statistics about the dataset <https://www.wikidata.org/wiki/Wikidata:WordGraph>, compared with Wikidata. The senses are already mapped to Wikidata QIDs, and so are the grammatical features, which makes adding them to Wikidata particularly easy. With the selection of human-denoting nouns and demonyms, this dataset is particularly useful for abstract descriptions for people in Wikidata – and people are, after all, the largest type of items that have Wikipedia articles. These lexemes will help us with creating such descriptions as “Irish rugby player”, “Ghanaian singer,” or “Indian mathematician” in many languages. We want to thank Bruno Cartoni, Saran Lertpradit, Seungmin Back, Daniel Calvelo Aros, Kuang-Yu Samuel Chang and Abdelrahman Nabil at Google for this beautiful gift. We invite everyone to work on enriching Wikidata with this lexicographic data. New special page: list of functions filtered by their tests This week we are happy to introduce a new special page: list of functions filtered by their tests <https://www.wikifunctions.org/wiki/Special:ListFunctionsByTests>. The page allows you to list all functions that have fewer than a certain number of tests (e.g., fewer than two tests <https://wikifunctions.org/wiki/Special:ListFunctionsByTests?min=&max=1&stat…>), or it can help to find functions that have passing tests that are not connected yet <https://wikifunctions.org/wiki/Special:ListFunctionsByTests?min=1&max=&stat…>. Or, on the other side, functions with failing tests that are still connected <https://wikifunctions.org/wiki/Special:ListFunctionsByTests?min=1&max=&stat…>. We can look for functions that have no tests at all <https://wikifunctions.org/wiki/Special:ListFunctionsByTests?min=&max=0&wpFo…>, or that have no connected tests <https://wikifunctions.org/wiki/Special:ListFunctionsByTests?min=&max=0&stat…>, or for functions with more than a dozen tests <https://wikifunctions.org/wiki/Special:ListFunctionsByTests?min=13&max=&wpF…> . This special page is expected to be particularly useful for functioneers looking for tests and implementations to connect. On the page, you can enter: - a range of numbers, given as a lower limit and an upper limit (both inclusive) to limit the number of tests that should match the test characteristics specified below; - whether we want to count connected tests or tests not connected yet (or both, in which case you leave both checkboxes empty); and - whether we want to count only tests that pass all connected implementations, or tests that fail for some of the connected implementations (or both, in which case you leave both checkboxes empty) Your resulting page can be shared by its URL. We hope that this new page will be helpful for you to maintain Wikifunctions! More statements! The claims sections of Wikidata lexemes, lexeme forms, and lexeme senses have received a major upgrade last week. Each claims section contains a list of Wikidata statements. Previously only statements with String values were included. This has been expanded to include statements with all the following types of values: - String - Lexeme reference - Lexeme form reference - Lexeme sense reference - Item reference - Monolingual text In addition, all statements now include a rank, in addition to their subject, predicate, and value. Additional details may be found in Wikifunctions: Support for Wikidata content <https://www.wikifunctions.org/wiki/Wikifunctions:Support_for_Wikidata_conte…> . In order to do so, we added a new key to the Wikidata statement <https://www.wikifunctions.org/view/en/Z6003> last week, representing the rank <https://www.wikifunctions.org/view/en/Z6040>. Big thanks to the community for organizing a marvelous and diligent clean-up job <https://www.wikifunctions.org/wiki/Talk:Z6003>! New type: day of Roman year This week we introduce a new type: the day of Roman year <https://www.wikifunctions.org/view/en/Z20342> allows us to specify a specific day in a year, e.g. November 27, the day when this newsletter is coming out. A day is represented by a natural number for the day of the month and a Gregorian month. We were also planning to release the Gregorian date type <https://www.wikifunctions.org/view/en/Z20420>. But while implementing the converters for the type and doing the first function <https://www.wikifunctions.org/view/en/Z20440> returning the new type, we noticed that the type felt rather difficult to work with, and community feedback came up raising concerns. Because of that we marked the type as “do not use” again and are asking for more feedback and discussion on the type proposal page <https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/Gregorian_c…> . Gregorian calendar date is represented by a day of the year and a Gregorian year. This eventually allows us to identify a day according to the proleptic Gregorian calendar, e.g. 15 January 2001, the day Wikipedia was founded, or 15 October 1582, the day the Gregorian calendar was introduced. Note that the Gregorian date type is not yet the same as the point in time data type in Wikidata <https://www.wikidata.org/wiki/Help:Data_type#time>, but it is a necessary step on the path to it. Recent Changes in the software Last week, we unveiled the new special page, Special:ListMissingLabels <https://www.wikifunctions.org/wiki/Special:ListMissingLabels>, to find Functions and other Objects that were missing a label in a language. Today, we have completed the planned work in this area with Special:ListFunctionsByTests <https://www.wikifunctions.org/wiki/Special:ListFunctionsByTests>, announced above. We hope this page will help the Wikifunctions community hunt down work that needs to be done more easily (T377909 <https://phabricator.wikimedia.org/T377909> and T377910 <https://phabricator.wikimedia.org/T377910>). We have also changed Special:ListObjectsByType <https://www.wikifunctions.org/wiki/Special:ListObjectsByType> to use a drop-down to select the target Type, to be like the other special pages ( T296315 <https://phabricator.wikimedia.org/T296315>), and to let you sort the results not just alphabetically but newness, either ascending or descending (T343633 <https://phabricator.wikimedia.org/T343633>). We have dropped a large part of the validation code we built that runs inside the MediaWiki side of the Wikifunctions ecosystem, as it was complex, buggy — causing at least one partial site outage (T374241 <https://phabricator.wikimedia.org/T374241>) – and slow. The validation of saved and unsaved Objects will mostly still take place, but in fewer bits of the code. This should make the site a little faster when you use it, but more importantly, avoid the risk of crashes (at least, from this area). We have also tweaked the PHP-side acceptance code to only allow strings as Z2K1 values, where we were previously lax mostly for testing purposes ( T296724 <https://phabricator.wikimedia.org/T296724>). We don't think this change should have any user-visible impacts. Finally on the validation side for this week, we've corrected the PHP code to not try to inspect the validity of items inside Z99/Quote objects, as they can be invalid, such as when processing an error complaining that input was invalid (T380386 <https://phabricator.wikimedia.org/T380386>). Finally, we have added support for the Z1952/bax-bamu <https://www.wikifunctions.org/view/en/Z1952> (T379870 <https://phabricator.wikimedia.org/T379870>), Z1953/xon <https://www.wikifunctions.org/view/en/Z1953> (T380246 <https://phabricator.wikimedia.org/T380246>), and Z1954/cdo-hant <https://www.wikifunctions.org/view/en/Z1954> & Z1955/cdo-latn <https://www.wikifunctions.org/view/en/Z1955> (T139010 <https://phabricator.wikimedia.org/T139010>, T379829 <https://phabricator.wikimedia.org/T379829>, and T380046 <https://phabricator.wikimedia.org/T380046>) languages to Wikifunctions, as part of them being added to MediaWiki. Next volunteers’ corner on December 9 Due to our team offsite next week, we have to move the next volunteers’ corner (and the last one of the year) one week later, to December 9 at 15:30 UTC <https://zonestamp.toolforge.org/1733758200> at the usual place <https://meet.google.com/xuy-njxh-rkw>. The January volunteers’ corner will also be moved by a week to January 13. No update next week Due to the same team offsite next week, we will also skip next week’s update. See you again in two weeks! Function of the week: is leap year Since it’s Thanksgiving this week in North America, I wanted to give a thank you to the awesome contributor community we have at Wikifunctions! In the beginning of this year, I started the “Function of the week” rubric in this newsletter, and I wanted to highlight some of the great work done by the community and use it as a vehicle to explain some of the concepts that Wikifunctions works on. When the year started, I was genuinely worried whether we would have a function to present every week. But you exceeded my expectations entirely and proved my worries wonderfully wrong. Not only was there more than enough material to present a function of the week, but you have created more than enough functions to have a function of a day a few times over. This is utterly amazing, and I want to say thank you, thank you all! This week we’re coming to a function I have been waiting for a while, and now that we introduced the Gregorian year <https://www.wikifunctions.org/view/en/Z20159> type last week, it could finally be implemented: is leap year <https://www.wikifunctions.org/view/en/Z20181> (Z20181). Is leap year takes a single argument, a Gregorian year <https://www.wikifunctions.org/view/en/Z20159>, and returns a simple Boolean <https://www.wikifunctions.org/view/en/Z40>: it returns true if the given year is a leap year, and false otherwise. Leap years <https://en.wikipedia.org/wiki/Leap_year> were introduced many years ago, when folks noticed that their calendar years and the seasons and the skies were not aligning perfectly. In old Rome, a role was introduced, the *pontifex maximus* <https://en.wikipedia.org/wiki/Pontifex_maximus>, the chief bridge builder between our world and the world in the heavens, and, among other things, their job was to keep the human calendar counting aligned with the actual seasons and other heavenly events. Originally, the *pontifex maximus* simply decided, year by year, how long the year should be. Julius Caesar <https://en.wikipedia.org/wiki/Julius_Caesar> became *pontifex maximus* in 63 BC, but instead of deciding year by year, he reformed the calendar and set up predictable rules: every year would have 365 days, but every fourth year would be a leap year, and that’s 366 days long. This rule kept going for a few centuries. Later the role of the *pontifex maximus* was picked up by the Catholic pope. The calendar was starting to again become out of sync with reality, and so pope Gregory XIII <https://en.wikipedia.org/wiki/Pope_Gregory_XIII>, as *pontifex maximus*, issued a bull <https://en.wikipedia.org/wiki/Inter_gravissimas> introducing the Gregorian calendar in 1582. The bull had two main effects: first, it dropped ten days off the calendar, to bring the calendar back in alignment with the seasons, and second, it modified the rules in order to further reduce the two from getting out of sync. Every fourth year would still be a leap year, but there was an exception: every hundredth year, the leap year would be skipped. But there’s also an exception to that exception: every 400 years we skip skipping the leap year. So, 1900 had and 2100 will have 365 days, but 2000 had 366. Whereas most people are aware of the four-year rule of the Julian calendar, fewer people know the rules of the Gregorian calendar (given how rarely it occurs, that’s not exactly a surprise). And so it is unsurprising that there are many wrong implementations of this function. When searching for implementations of the leap year rule on GitHub, it is easy to find dozens of implementations that apply the leap year rule partially or incorrectly. One more example of why having a large library of functions is a good idea in general! The function has a solid set of tests: - this year, 2024 is a <https://www.wikifunctions.org/view/en/Z20183> leap year - next year, 2025, is not <https://www.wikifunctions.org/view/en/Z20254> - 2000 was a <https://www.wikifunctions.org/view/en/Z20184> leap year, the last occurrence of the skipping the skipping the leap year rule - 1900 was not a <https://www.wikifunctions.org/view/en/Z20248> leap year, the last occurrence of skipping the leap year rule - 1582 was not <https://www.wikifunctions.org/view/en/Z20256> a leap year either - 1 BC was a <https://www.wikifunctions.org/view/en/Z20252> leap year - 5 BC was a <https://www.wikifunctions.org/view/en/Z20249> leap year, because it was four years before 1 BC - 2025 BC was a <https://www.wikifunctions.org/view/en/Z20255> leap year, too - 1300 was a Julian leap year, but not one <https://www.wikifunctions.org/view/en/Z20381> in the proleptic Gregorian calendar - 4000 AD will not be <https://www.wikifunctions.org/view/en/Z20382> a leap year in the Gregorian calendar, but would be in Herschel's proposed modification Note that the people living in 2025 BC obviously neither knew that they are living in 2025 BC nor that they are living in a leap year. That’s the meaning of proleptic: it is anachronistically applied back in time. The function has currently the following implementations: - one in Python <https://www.wikifunctions.org/view/en/Z20182>, representing the usual rules in a way: if the year number can be divided by 4, but not by 100 but then by 400, then it is a leap year. - one in JavaScript <https://www.wikifunctions.org/view/en/Z20251>, which, according to a detailed StackOverflow answer <https://stackoverflow.com/questions/3220163/how-to-find-leap-year-programma…>, is the fastest possible check (but probably not in our implementation, given that we are using BigInt) - a composition <https://www.wikifunctions.org/view/en/Z20275> which converts the year number to the ISO 8601 year <https://www.wikifunctions.org/view/en/Z20257> (thus turning 1 BC to 0, 2 BC to -1, etc.), and then uses a series of ifs <https://www.wikifunctions.org/view/en/Z802>: if it is divisible by <https://www.wikifunctions.org/view/en/Z20266> 400, then true, else if it is divisible by <https://www.wikifunctions.org/view/en/Z20266> 100, then false, else whether it is divisible by <https://www.wikifunctions.org/view/en/Z20266> 4. - and a quite charming composition <https://www.wikifunctions.org/view/en/Z20304>, that checks that the day of the week of the last day of the year <https://www.wikifunctions.org/view/en/Z20302> is the same as <https://www.wikifunctions.org/view/en/Z17414> the day of the week following <https://www.wikifunctions.org/view/en/Z17420> the day of the week of the first day of the year <https://www.wikifunctions.org/view/en/Z20290>. The code implementations benefit from negative years being represented through an implicit ISO 8601 conversion, and so the usual rules can be directly applied. I don’t find it obvious at all that the given implementations would always have the same result. But given the passing tests, I am quite confident that they are indeed interchangeable.

1 0

Newsletter #181: New special page for missing labels, new type for Gregorian years, and much more
by Denny Vrandečić 21 Nov '24

21 Nov '24

The on-wiki version of this newsletter can be found here: https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-11-21 -- New special page: missing labels <https://www.wikifunctions.org/wiki/File:Wikifunctions_special_page_listing_…> A new special page has arrived on Wikifunctions, which lists objects with a missing label <https://www.wikifunctions.org/wiki/Special:ListMissingLabels>. You can choose the type of the object to filter for, and the language you want to look for. This should make it much easier for you to find objects that need translation work. The highest priorities for translations are probably types <https://www.wikifunctions.org/wiki/Special:ListMissingLabels?type=Z4> and functions <https://www.wikifunctions.org/wiki/Special:ListMissingLabels?type=Z8>. But also enumerations such as Boolean <https://www.wikifunctions.org/wiki/Special:ListMissingLabels?type=Z40>, day of the week <https://www.wikifunctions.org/wiki/Special:ListMissingLabels?type=Z17402>, Gregorian month <https://www.wikifunctions.org/wiki/Special:ListMissingLabels?type=Z16098> and Igbo month <https://www.wikifunctions.org/wiki/Special:ListMissingLabels?type=Z16927>, era <https://www.wikifunctions.org/wiki/Special:ListMissingLabels?type=Z17813>, or sign <https://www.wikifunctions.org/wiki/Special:ListMissingLabels?type=Z16659> are great targets for a translation effort, since they often enable a whole domain of functions to work for a given language for an effort that can be easily estimated. We hope that through this page we will enable the work to see more of Wikifunctions become available for more people in the world! Thank you all for your help, support, and contributions. Since we are talking about special pages, last week the special page for listing types <https://www.wikifunctions.org/wiki/Special:ListObjectsByType> by object was refreshed. It now uses paging (i.e. displaying only a certain number of results per page, and then allowing to go through further results), which speeds the page up considerably, and provides a more user-friendly interface. I want to use the opportunity to thank Arthur P. Smith <https://www.wikifunctions.org/wiki/User:ArthurPSmith> for the original volunteer work on this special page. New types: Gregorian year and Wikidata statement rank We have introduced a new type, Gregorian year <https://www.wikifunctions.org/view/en/Z20159>. It represents a year in the proleptic Gregorian calendar, which is the calendar most Western countries and many others use. “Proleptic” means that it is being extended into a past where it wasn’t actually used. Gregorian year combines the Gregorian era <https://www.wikifunctions.org/view/en/Z17813> (whether AD <https://www.wikifunctions.org/view/en/Z17814> or BC <https://www.wikifunctions.org/view/en/Z17815>) with a natural number <https://www.wikifunctions.org/view/en/Z13518> in order to count the years in each era. Converters to Python and JavaScript are available, using the ISO 8601 <https://en.wikipedia.org/wiki/ISO_8601#Years> standard in which the year 1 BC is represented by the number 0, the year 2 BC by the number -1 etc. This does, in many cases, simplify the math – but may confuse the display. Hopefully, the converters will take care of the respective translation. Have fun with the new type! We also created the Wikidata statement rank <https://www.wikifunctions.org/view/en/Z6040> type, an enumeration with three values (preferred <https://www.wikifunctions.org/view/en/Z6041>, normal <https://www.wikifunctions.org/view/en/Z6042>, and deprecated <https://www.wikifunctions.org/view/en/Z6043>), which is used to represent the rank of a Wikidata statement <https://www.wikifunctions.org/view/en/Z6003>. The ranks are described on Wikidata <https://www.wikidata.org/wiki/Help:Ranking#Usage>. Next week we plan to work on days in a year <https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/Day_of_Roma…>, leading to Gregorian calendar dates <https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/Gregorian_c…>. Please join the discussion on the type proposals! Lexeme form tools now using Wikifunctions by default For Wikidata’s 12th birthday <https://www.wikidata.org/wiki/Wikidata:Twelfth_Birthday>, Lucas Werkmeister <https://www.wikifunctions.org/wiki/User:Lucas_Werkmeister> has updated the Wikidata Lexeme Tools <https://www.wikidata.org/wiki/Wikidata:Wikidata_Lexeme_Forms>. You can now use settings to enable Wikifunctions to automatically create regular forms when creating a new Lexeme. Thanks to Lucas for this update, and we hope that it will help with the creation of many new Lexemes! Recent Changes in the software A part of our main Quarterly work is that we are improving on-wiki tools to help the Wikifunctions community maintain Functions more easily (T376671 <https://phabricator.wikimedia.org/T376671>). The first new page from this work lets you find all the Objects of a particular kind that are missing a label in a given language: Special:ListMissingLabels <https://www.wikifunctions.org/wiki/Special:ListMissingLabels> (T378008 <https://phabricator.wikimedia.org/T378008>). By default, it lists Functions missing a label in your view language, but *e.g.* you can find all the Types without a Dagbani label <https://wikifunctions.org/wiki/Special:ListMissingLabels?type=Z4&language=Z…>. The page is available within this week's release, though we'll need to re-run an update script to make sure all labels are up-to-date. A community member, SomeRandomDeveloper <https://phabricator.wikimedia.org/p/SomeRandomDeveloper/>, made a change that gives a more specific "not found" message for Objects (T342965 <https://phabricator.wikimedia.org/T342965>). Thanks! The slightly-broken display on empty discussion pages, which showed code like `(<span dir="ltr">Z10599</span>)` in the introduction section, has been fixed by wider changes to the MediaWiki messages system (T344491 <https://phabricator.wikimedia.org/T344491>); thank you, Bartosz Dziewoński! We have included an additional layer of database tracking for which Functions are connected to which Implementations and Test cases (T378008 <https://phabricator.wikimedia.org/T378008>), which will allow us to soon provide a page finding unconnected Implementations and Tests (rather than people finding them by chance, or newbies knowing to ask on Wikifunctions:Community portal <https://www.wikifunctions.org/wiki/Wikifunctions:Community_portal> or Wikifunctions:Project chat <https://www.wikifunctions.org/wiki/Wikifunctions:Project_chat>). We have tweaked the maintenance script we use to update Objects in production after development changes; we can now run it for all Objects in one go (T379602 <https://phabricator.wikimedia.org/T379602>). We have added support for the Z1951/kip language <https://www.wikifunctions.org/view/en/Z1951> to Wikifunctions, as part of it being added to MediaWiki. We, along with all Wikimedia-deployed code, are now using the latest version of the Codex UX library, v1.16.0, as of this week. We believe that there should be no user-visible changes on Wikifunctions, so please comment on the Project chat or file a Phabricator task if you spot an issue. Which function is used by which function? Feeglgeef <https://www.wikifunctions.org/wiki/User:Feeglgeef>, a new contributor with a lot of energy, has created an app that allows to check for each function in which implementations of other functions it is being used, and other helpful ways to check the graph structure of Wikifunctions: wf-usage <https://wf-usage-feeglgeef.replit.app/> Blog post on Wikifunctions Long-time Wikimedian Gerard Meijssen <https://meta.wikimedia.org/wiki/User:GerardM> has written a blog post about some of the possibilities that Wikifunctions and Abstract Wikipedia are aiming for, around the theme of awards. Thank you for your kind words, Gerard! The post is here: *The story of African award winning* <https://ultimategerardm.blogspot.com/2024/11/the-story-of-african-award-win…> Next volunteers’ corner on December 9 Due to a team offsite during the first week of December, we have to move the next volunteers’ corner (and the last one of the year) one week later, to December 9. The January volunteers’ corner will also be moved by a week to January 13. We are considering moving the volunteers’ corner to an earlier time slot for this time, December 9 at 15:30 UTC <https://zonestamp.toolforge.org/1733758200>. Feedback is appreciated! Wikifunctions-related talk at SWIB24 Coming Monday, November 25, at 14:00 UTC <https://zonestamp.toolforge.org/1732543200>, Denny <https://www.wikifunctions.org/wiki/User:DVrandecic_(WMF)> will be holding a keynote at SWIB24 <https://swib.org/swib24>, the Semantic Web in Libraries conference. SWIB is completely online and registration is free of charge. The topic of Denny’s talk will be *”How knowledge representation is changing in a world of large language models”* , and it will talk about the impact that Wikidata, Wikifunctions and Abstract Wikipedia can have on knowledge representation, particularly given the novel capabilities that large language models are making available. Function of the Week: Bayes' theorem conditional probability P(A|B) Following the introduction of a new type, we traditionally pick one of the functions using the new type in the following week. Last week <https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-11-13>, we introduced rational numbers <https://www.wikifunctions.org/view/en/Z19677>, and you have been generously contributing new functions for the type: we already have 50 functions that either return or accept rational numbers as an argument. That’s great work, thank you all! This week we also crossed ZID *Z20000*. ZIDs are being consecutively created for every new object, and we started with Z10000, keeping the ZIDs with fewer than digits for built-in objects. This means that since its launch, the Wikifunctions community has created about 10,000 objects! Wikifunctions currently has 1778 functions as of writing, with more than 3,000 implementations and more than 5,300 tests. For me as a trained software engineer, it is particularly heart-warming to see how many tests we have, and how much the Wikifunctions community values a good test coverage. Thank you! And since we just crossed Z20000, let’s use Z20000 as our Function of the Week: Bayes' theorem conditional probability <https://www.wikifunctions.org/view/en/Z20000>, often written as P(A|B). Bayes’ theorem <https://en.wikipedia.org/wiki/Bayes%27_theorem> is an important rule in the mathematics of probabilities. I started writing examples, but the Wikipedia article already offers a good list of examples. The function has three implementations: - The composition <https://www.wikifunctions.org/view/en/Z20001> is a straightforward implementation of the theorem: we multiply <https://www.wikifunctions.org/view/en/Z19706> P(B|A) with P(A) and divide <https://www.wikifunctions.org/view/en/Z19708> by P(B). - The Python implementation <https://www.wikifunctions.org/view/en/Z20002> does the same. - The JavaScript implementation <https://www.wikifunctions.org/view/en/Z20040> is a bit more complex: since, unlike in Python, JavaScript offers no native type for rational numbers, the numerator and denominator are being deconstructed. And since for a rational number a division is the same as multiplying with its reciprocal, we see in the JavaScript implementation the denominator being the product of the denominator of the first two and the numerator of the last argument, and vice versa for the numerator. As usual, we can either think through the logic of these implementations in order to understand that they are indeed equivalent – or we can rely on our test suite. The function has six tests: - A rare, B usually co-occurs but more common <https://www.wikifunctions.org/view/en/Z20003> - A and B are both rare, but correlated <https://www.wikifunctions.org/view/en/Z20004> - A and B are both common but never co-occur <https://www.wikifunctions.org/view/en/Z20005> - A test based on one of the examples <https://www.wikifunctions.org/view/en/Z20105> in a Wikipedia article <https://en.wikipedia.org/wiki/Bayesian_inference#Probability_of_a_hypothesis> - A is already known impossible <https://www.wikifunctions.org/view/en/Z20111>, the first edge case - And B is known to be impossible <https://www.wikifunctions.org/view/en/Z20106>, another edge case (although this one is undefined, and we currently don’t have good support for that) This function is also a great example of a function that, while likely not frequently useful for creating text for Wikipedia, could be very useful on the Wikipedia article for Bayes' theorem itself, in order to directly allow to use this function, deepening the educational mission of Wikipedia. Off to many more functions!

1 0

Newsletter #180: New type: Rational numbers; Documentation on Wikidata-based types
by Denny Vrandečić 13 Nov '24

13 Nov '24

The on-wiki version of the newsletter can be found here: https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-11-13 -- New type: Rational numbers <https://www.wikifunctions.org/wiki/File:Cake_fractions.svg>A cake representing fractions. Wikifunctions now has a new Type: rational numbers <https://www.wikifunctions.org/view/en/Z19677>. They expand the ability to deal with numbers considerably, allowing us to work with fractions and decimals, and not just whole numbers anymore. Rational numbers are represented by two natural numbers <https://www.wikifunctions.org/view/en/Z13518> and a sign <https://www.wikifunctions.org/view/en/Z16659>. They always represent precise fractions. This also allows us to represent arbitrary decimal numbers precisely, as these are always representable as fractions. This is a very different approach from how most programming languages implement mathematical values: they often use floating point numbers, which approximate the results. That is sufficient for many use cases, but leads to precision errors in some cases. For example, if you evaluate the following line in JavaScript: > 0.3-0.1 the result you get is not 0.2, as you might expect, but 0.19999999999999998 (at least in the implementations we tried). There has been a lively discussion on the type proposal <https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/Rational_nu…> and in the chat around how to exactly represent rational numbers, particularly around the question whether we should allow both 1/2 and 2/4 as values (since they both represent the same number), or whether the latter should be an invalid rational number and only simplified fractions should be allowed. We decided on simplified values, but I hope that in practice we will follow Postel’s law, by being liberal in what values we accept and strict in the values we output. Rational numbers are currently still missing a renderer and a parser, and we invite the community to make suggestions. That will make the type much easier to use (see also below). As mentioned, floating points are a related Type. A discussion with several options <https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/float64> is still ongoing about how to represent floating points, and we want to find consensus before implementing it. We invite you to join the discussion around how to represent floating points. Next week, we are planning to go for the Gregorian year type <https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/Gregorian_y…>, if all goes well. Comments on the type proposal are very welcome. Recent Changes in the software As part of our work to expand what you can do with Wikidata things, we have added front-end support for using more kinds of entity (T377825 <https://phabricator.wikimedia.org/T377825>). The back-end work is still underway, and will be coming soon! We have improved our database tables for how we store and search for labels. Firstly, we've corrected the Type of Functions' returns when it's generic (T375972 <https://phabricator.wikimedia.org/T375972>). Second, we're adding entries for Objects' ZIDs, so they're still findable even if they don't have a label (T358737 <https://phabricator.wikimedia.org/T358737> & T373038 <https://phabricator.wikimedia.org/T373038>). These will both require us to run a script to refresh the databases, so won't be immediately available after the new code rolls out on Wednesday, but should be available soon. We've reduced the number of items shown visibly in the menu when searching for Objects and Wikidata items, from 10 down to 5, which should improve the UX when the field is near the top or bottom of the screen, and still let you scroll to further results as before (T377337 <https://phabricator.wikimedia.org/T377337>). We've improved the Special:ListObjectsByType page to have a "pager", so instead of trying to show all matching Objects at once (and making the servers unhappy), we're now showing you 50 at a time, like other MediaWiki pages, and sorting them alphabetically in your view language (T342912 <https://phabricator.wikimedia.org/T342912>). Natural numbers have a renderer and parser again <https://www.wikifunctions.org/wiki/File:Multiplication-en.png>Running a multiplication on Wikifunctions in English <https://www.wikifunctions.org/wiki/File:Multiplication-fr.png>Running a multiplication on Wikifunctions in French <https://www.wikifunctions.org/wiki/File:Multiplication-de.png>Running a multiplication on Wikifunctions in German Back in March, we had to remove the renderer and parser from natural numbers <https://www.wikifunctions.org/view/en/Z13518>. This was necessary due to issues in the system. As a result of the removal, functions using natural numbers had a less useful interface. The system issues have been fixed, and so we switched renderers and parsers back on for natural numbers again. In the future, we hope for Wikifunctions to provide even more localization. The screenshot displays different views when one uses French <https://wikifunctions.org/view/fr/Z13539>, German <https://wikifunctions.org/view/de/Z13539>, and English <https://wikifunctions.org/view/en/Z13539>, making large numbers more readable by using spaces, dots, or commas, respectively. But we are particularly curious about using this mechanism for languages that display numbers differently, for example in Arabic and Hindi. And we are curious which display each language community prefers. If you want to help out with that for your language, please let us know – or just go ahead! Documentation on Wikidata-based types We have written some documentation on the Wikidata-based types, which gives an overview of how they work and how they are structured. I hope that, eventually, we will have a number of intuitively useable functions, but in order to build these, the documentation about the support for Wikidata content <https://www.wikifunctions.org/wiki/Wikifunctions:Support_for_Wikidata_conte…> can be very useful to get such functions started. Function of the Week: minimum of a list of natural numbers[edit source <https://www.wikifunctions.org/w/index.php?title=Wikifunctions%3AStatus_upda…> ] In last week’s volunteers’ corner <https://commons.wikimedia.org/wiki/File:Abstract_Wikipedia_Volunteer_Corner…>, we worked on two functions. We discussed one of the functions last week <https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-11-07>, and this week we are discussing the other: minimum of a list of natural numbers <https://www.wikifunctions.org/view/en/Z19509>. The function takes one input, a list <https://www.wikifunctions.org/view/en/Z881> of natural numbers <https://www.wikifunctions.org/view/en/Z13518>, and returns a single natural number <https://www.wikifunctions.org/view/en/Z13518>, that is the smallest one in the list. The list can be as arbitrarily long. If the list is empty, it is defined to return 0. During the volunteers’ hour, six tests were created: - An empty list returns 0 <https://www.wikifunctions.org/view/en/Z19518> - In a list with one element <https://www.wikifunctions.org/view/en/Z19519>, that element is the smallest. - If a list consists of the same element <https://www.wikifunctions.org/view/en/Z19520> repeated, that element is the smallest. - In a list with two elements, the smaller after the larger <https://www.wikifunctions.org/view/en/Z19521>, the smaller is the minimum. - If we switch the order of the two elements <https://www.wikifunctions.org/view/en/Z19522>, the result does not change. - In a list with several elements <https://www.wikifunctions.org/view/en/Z19523>, the smallest is still chosen. During the hour, three implementations were created, and two more have been added since: - One implementation in JavaScript <https://www.wikifunctions.org/view/en/Z19526>. It first checks whether the list has no elements, in which case it returns 0. Then it sets the minimum value to the first element, and checks for each value whether the minimum is larger than the given value. If so, the minimum is updated to the new value. Once that is done for all values of the list, the minimum will be returned. JavaScript surprisingly comes with no function to get the minimum of a list of BigInts, so we have to implement it. - The first implementation in Python was a direct translation <https://www.wikifunctions.org/view/en/Z19528> of the JavaScript implementation. - Later, a second implementation in Python <https://www.wikifunctions.org/view/en/Z19617> was added, using Python’s builtin min function, which does exactly what we need – with the difference that an empty list causes an error in Python, whereas we want it to return 0. Thus we code in a check for emptiness and return 0 in that case, as expected. - One implementation <https://www.wikifunctions.org/view/en/Z19529> was attempted during the volunteers’ corner, but had to be abandoned because one function could not be selected. This was later fixed by 99of9 <https://www.wikifunctions.org/wiki/User:99of9> adding a seemingly superfluous echo <https://www.wikifunctions.org/view/en/Z801> call. The composition checks whether the list has a length <https://www.wikifunctions.org/view/en/Z12681> of 1 or less. If so, it checks if <https://www.wikifunctions.org/view/en/Z13846> the list is empty <https://www.wikifunctions.org/view/en/Z813>, and returns 0, otherwise it returns the first <https://www.wikifunctions.org/view/en/Z811> (and only value). But if the list has 2 elements or more, we use the lesser of two natural numbers <https://www.wikifunctions.org/view/en/Z13633> function on the first element <https://www.wikifunctions.org/view/en/Z811> of the list comparing it to the minimum of natural number list <https://www.wikifunctions.org/view/en/Z19509> of the rest of the list <https://www.wikifunctions.org/view/en/Z812>. The rest of the list is being embedded in a seemingly unnecessary echo <https://www.wikifunctions.org/view/en/Z801>, which avoids bug T375972 <https://phabricator.wikimedia.org/T375972>. This function is another example of a recursive call, i.e. the function calls itself during composition. - The other composition <https://www.wikifunctions.org/view/en/Z19547> is using a reduce function <https://www.wikifunctions.org/view/en/Z876>, which we already met briefly discussing the Function of the Week product of list of natural numbers <https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-10-02#…>. There, one of the implementations was also done with reduce, product of Natural number list <https://www.wikifunctions.org/view/en/Z17400>, and it looks very similar to the implementation here – and yet the result is very different. After guarding for the case of having no elements with an if <https://www.wikifunctions.org/view/en/Z802> empty list <https://www.wikifunctions.org/view/en/Z813> (and returning 0 if so), we reduce the list using the lesser of two natural numbers <https://www.wikifunctions.org/view/en/Z13633> function, starting with the first element <https://www.wikifunctions.org/view/en/Z811> of the list. This function is a great example function, with numerous implementations and testers.

1 0

Newsletter #179: The dream of a Universal Language
by Denny Vrandečić 07 Nov '24

07 Nov '24

The on-wiki version of this newsletter can be found here: https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-11-07 -- The Dream of a Universal Language <https://www.wikifunctions.org/wiki/File:Katowice_-_Wikimania_2024_-_Abstrac…>Session "Abstract Wikipedia and the dream of a Universal Language" by Galder Gonzalez during Wikimania 2024 This year at Wikimania 2024 <https://wikimania.wikimedia.org/wiki/2024:Wikimania>, Galder Gonzales <https://www.wikifunctions.org/wiki/User:Theklan> gave a talk on “Abstract Wikipedia and the dream of a Universal Language” <https://app.eventyay.com/talk/Wikimania/talk/NUXQAC/>. The talk is now available to watch on YouTube <https://www.youtube.com/watch?v=OyyYA4iWkyA&list=PLhV3K_DS5YfL7A2HXrpt8ZgnW…> . Galder is working on his PhD thesis, and in this talk he is presenting his current results on discussing the relationship between Abstract Wikipedia and the long-held philosophical dream of a universal language. He discusses what a language is, and then organizes and presents previous approaches towards a universal language, such as Llull <https://en.wikipedia.org/wiki/Ramon_Llull>, Descartes <https://en.wikipedia.org/wiki/Ren%C3%A9_Descartes>, Leibniz <https://en.wikipedia.org/wiki/Gottfried_Wilhelm_Leibniz>, and many others. The talk is a wonderful introduction to some of the historical roots that are leading us to Abstract Wikipedia. Enjoy the talk! Catalogue has been refactored The catalogue of functions on Wikifunctions <https://www.wikifunctions.org/wiki/Wikifunctions:Catalogue> has been a great resource to list and find functions in Wikifunctions. So far, it has been a single page on the wiki. Now, with Wikifunctions having more than 1600 functions, the page has become increasingly wieldy, and User:Theklan <https://www.wikifunctions.org/wiki/User:Theklan> (yes, that’s the same who gave the talk above!) has reworked it and broken it into several smaller pages. Everyone is welcome to work on improving the catalogue <https://www.wikifunctions.org/wiki/Wikifunctions:Catalogue> and make the functions in Wikifunctions easy to find and list! Recent Changes in the software Lately we've mostly been working on the bigger, Quarterly goals work, especially the Wikidata loading (T376662 <https://phabricator.wikimedia.org/T376662>), Wikipedia integration (T376521 <https://phabricator.wikimedia.org/T376521>), and re-building the back-end platform (T376668 <https://phabricator.wikimedia.org/T376668>), but there are a few improvements that we released last week and this: We have changed the display of the "about" box to show long inputs' labels and types more clearly (T373978 <https://phabricator.wikimedia.org/T373978>). We've fixed the Lexeme selector to not use the fallback mechanism when you click, but as selected; in practice, this lets you select one of the different lexemes that have the same label (T377332 <https://phabricator.wikimedia.org/T377332>). When creating or editing a type converter, we now show a message that 'Z0' will get auto-replaced as needed (T368087 <https://phabricator.wikimedia.org/T368087>). We've changed the Wikidata searching widget to pass your view language along in the request, so the explanatory labels like "noun" or "verb" will now be shown in your language, if available (T378499 <https://phabricator.wikimedia.org/T378499>). We've landed some front-end performance improvements, which have become more noticeable since we enabled Wikidata fetching and you end up seeing large objects like Lexemes (T378169 <https://phabricator.wikimedia.org/T378169>). Unfortunately this means that the custom dialog based on "error" parsing has been temporarily disabled; we hope to bring this back soon, in a performant fashion. We've fixed the display of the "toast" success/failure message on publication to not appear as a thin vertical strip (T377461 <https://phabricator.wikimedia.org/T377461>). We've corrected a bug that meant that you would sometimes be asked if you wanted to leave the site and abandon changes even after publishing (T377412 <https://phabricator.wikimedia.org/T377412>). The developer tool to load pre-defined Objects into Wikifunctions.org production now also lets you interactively merge upstream changes without over-writing on-wiki community changes, like labels or aliases (T335418 <https://phabricator.wikimedia.org/T335418>). We now have a set of developer tools to create a copy of the live Wikifunctions.org content, and load it into a local developer machine, to be able to better debug issues you encounter in production. We've re-written the developer instructions in the README to be easier to follow and more specific around running and configuring local services. Finally, we've landed an improvement to our PHP code to support the forthcoming PHP 8.4 (T376276 <https://phabricator.wikimedia.org/T376276>); thanks to Andre Klapper for their first commit to WikiLambda. Over the last three weeks, we have added support for eleven new languages to Wikifunctions, as part of them being added to MediaWiki: Z1940/laj <https://www.wikifunctions.org/view/en/Z1940> (T376060 <https://phabricator.wikimedia.org/T376060>), Z1941/mns <https://www.wikifunctions.org/view/en/Z1941> (T375944 <https://phabricator.wikimedia.org/T375944>), the set of Z1942/akb <https://www.wikifunctions.org/view/en/Z1942>, Z1943/btd <https://www.wikifunctions.org/view/en/Z1943>, Z1944/bts <https://www.wikifunctions.org/view/en/Z1944>, Z1945/btx <https://www.wikifunctions.org/view/en/Z1945>, & Z1946/btz <https://www.wikifunctions.org/view/en/Z1946> (T376826 <https://phabricator.wikimedia.org/T376826>), Z1947/mdh <https://www.wikifunctions.org/view/en/Z1947> (T377851 <https://phabricator.wikimedia.org/T377851>), Z1948/maw <https://www.wikifunctions.org/view/en/Z1948> (T377797 <https://phabricator.wikimedia.org/T377797>), Z1948/knc <https://www.wikifunctions.org/view/en/Z1949> (T356144 <https://phabricator.wikimedia.org/T356144>), and finally Z1950/cko <https://www.wikifunctions.org/view/en/Z1950> (T377380 <https://phabricator.wikimedia.org/T377380>). Presentation series on lexicographic data and its usage A series of presentations <https://www.wikidata.org/wiki/Wikidata:WikiProject_LD4_Wikidata_Affinity_Gr…> started this Tuesday, presented by Mahir Morshed <https://www.wikifunctions.org/wiki/User:Mahir256>. The slides of this week <https://elemwala.toolforge.org/static/ld4pres-5nov.html> are available, and a recording is expected, too. Every two weeks until the end of the year you can join interactive working sessions on how to edit lexemes, modeling complex lexemes, and using lexemes to build sentences. An |overview of all sessions <https://www.wikidata.org/wiki/Wikidata:WikiProject_LD4_Wikidata_Affinity_Gr…> is available on Wikidata. Recording of November Volunteers’ Corner A recording of this month's Volunteers’ Corner <https://commons.wikimedia.org/wiki/File:Abstract_Wikipedia_Volunteer_Corner…> is now available on Wikimedia Commons. We gave the month’s updates, worked on not one but two functions together (simple tense of verb <https://www.wikifunctions.org/view/en/Z19514> and minimum of natural number list <https://www.wikifunctions.org/view/en/Z19509>), and had a number of questions at the end. Enjoy the video! Lighting talk at Wikiconvention francophone Nicolas Vigneron <https://www.wikifunctions.org/wiki/User:VIGNERON> was presenting a lightning talk about Wikifunctions this week at Wikiconvention francophone in Québec The presentation was well received, and there was particular interest about the ability to create functions by composition and without coding. Upcoming types We are renewing our focus on working towards adding more types, and are looking through the type proposals <https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals>. A lively discussion around some further numeric types has ensued on the Abstract Wikipedia / Wikifunctions chat. Work on the types and your thoughts in the chat are both welcome and would be timely now. Function of the Week: simple tense of verb In many languages, a verb –the part of a sentence that refers to the action in the sentence– will have a different form depending on whether the action described in the sentence happens while the sentence is being spoken, before it, or will happen after. Often, languages can also speak about more complex relationships of the sentence with the timing of the described event, but these are the three basic times, or tenses. In this week’s Volunteer’s Corner <https://commons.wikimedia.org/wiki/File:Abstract_Wikipedia_Volunteer_Corner…>, we looked at the function simple tense of verb <https://www.wikifunctions.org/view/en/Z19514> (Z19514) that takes two arguments, a lexeme <https://www.wikifunctions.org/view/en/Z6005> and a natural number <https://www.wikifunctions.org/view/en/Z13518> representing the tense: 0 for the past, 1 for the present, and 2 for the future. The function returns a monolingual text <https://www.wikifunctions.org/view/en/Z11> with the representation of the first relevant form. The function has two tests: the first test ensures that the future of the Malayalam verb പോകുക is the Malayalam text പോകും <https://www.wikifunctions.org/view/en/Z19516>, and the second test checks that the past tense of the English verb scrutinize is the English text scrutinized <https://www.wikifunctions.org/view/en/Z19517>. The function has three implementations: - The JavaScript implementation <https://www.wikifunctions.org/view/en/Z19515> and [[Z19527|Python implementation\\ are straightforward translations of each other - First, we have an array of QIDs representing the tenses (past <https://www.wikidata.org/wiki/Q1392475>, present <https://www.wikidata.org/wiki/Q3910936> and future <https://www.wikidata.org/wiki/Q1475560>). In line 7, we are turning the second argument into the relevant QID, by accessing them by number - Then we iterate through all the forms of the given lexeme, checking if any of the features of the form we are looking at matches with the relevant QID as selected before - If yes, we stop iterating through the list, and return the first representation of that form - The composition <https://www.wikifunctions.org/view/en/Z19524> works slightly differently, as we have higher-level functions available, most notably return monolingual text from grammatical features <https://www.wikifunctions.org/view/en/Z19530>. That function was created after the Volunteer’s corner with the explicit goal of helping with this function: it takes the lexeme and a QID, and gets the first monolingual text based on the grammatical feature. The call is wrapped in two layers of nested if <https://www.wikifunctions.org/view/en/Z802> functions, which, depending on the second argument, uses the appropriate QID as a parameter in that inner call to return monolingual text from grammatical features <https://www.wikifunctions.org/view/en/Z19530>. The coverage with tests and implementations are decent, but there are a number of issues with the function itself: - We have a rather unnatural mapping of natural numbers to tenses. A different way to approach this could be to introduce a type for tenses, and allow to select from the instances of that type. This also avoids the issue of having to deal with numbers larger than 2, which currently just raises an unspecified error. - In many languages, there are no forms for all three tenses. The function handles that by simply failing if a certain tense cannot be found. - In some languages, the future (or the past) is not represented by a specific form, but by a verb phrase. In English, that could be, e.g. *“I am going to read”*. We could compose these for the given language, but that would be language specific. - In many languages, there are more forms than one for a given tense. The function handles that by simply grabbing the first one, no matter what that is. - Nothing ensures that the lexeme is indeed a verb. It makes sense to start with a simpler implementation of the goal expressed in this function, and eventually have a function that is easier to use and more robust towards edge cases.

1 0

Newsletter 178: Rewriting the backend
by Denny Vrandečić 01 Nov '24

01 Nov '24

The on-wiki version of this newsletter can be found here: https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-11-01 -- Rewriting the backend <https://www.wikifunctions.org/wiki/File:Rust_programming_language_black_log…> The Abstract Wikipedia team is working toward a rewrite of our backend services in a different programming language, likely Rust. Node/JS has served us well, but we have run up against some limits that would be best dealt with by switching to a different ecosystem. The immediate work surrounds how we might better interact with WebAssembly (WASM). Almost precisely one year ago, we announced <https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-10-25> that we would begin running Python and JS code in WASM for its sandboxing characteristics. Since then, we have been interacting with WASM via the WebAssembly System Interface (WASI), which allows WASM commands selective access to the underlying operating system. While WASI has made our code executors more secure, the use of this tool has caused some bumps. The Node tooling around WASI is not particularly rich. At the time of adoption, we found that our best option was to use WASI command-line interfaces. We decided to run these interfaces in subprocesses. The use of subprocesses has resulted in system stability issues, mainly related to the impossibility of cleaning up subprocesses under certain conditions. The WASI ecosystem in Rust is much more advanced. Several WASI runtimes provide tools which offer fine levels of control over the binding of WASM commands to syscalls. With these tools, we can streamline our use of WASI. We can run our code executors directly inside of the host Rust program, eliminate subprocesses, and thereby avoid several sources of system instability. As an added bonus, this level of control means that we can also improve our sandboxing–a security win–and, in the far (or not so far?) future, co-opt certain system calls to implement new features for our code executors. Upcoming Volunteer’s Corner on November 4 Next week, on Monday, 4 November 2024, at 18:30 UTC <https://zonestamp.toolforge.org/1730745000>, we will have our monthly Volunteers’ Corner. Unless you have many questions, we will follow our usual agenda, of giving updates on the upcoming plans and recent activities, having plenty of time and space for your questions, and building a Function together. Looking forward to seeing you on Monday! Function of the Week: language of lexeme Function Z19295 is <https://www.wikifunctions.org/view/en/Z19295> a simple function: it takes a single argument, a lexeme <https://www.wikifunctions.org/view/en/Z6005>, and returns the (natural) language <https://www.wikifunctions.org/view/en/Z60> of the lexeme. Each Lexeme in Wikidata belongs to exactly one language, e.g. if we take a look at the lexeme L610505 <https://www.wikidata.org/wiki/L610505>, *“mkpụrụokwu”*, it tells us that it is a word in the Igbo language <https://en.wikipedia.org/wiki/Igbo_language>. Accordingly, if we choose the Lexeme *“mkpụrụokwu”* on the function page for language of lexeme <https://www.wikifunctions.org/view/en/Z19295>, it returns us the language object, displaying the language code ig (which stands for Igbo). The function has one tester <https://www.wikifunctions.org/view/en/Z19297>, which takes the Lexeme for the English noun dog <https://www.wikidata.org/wiki/Q1122> and returns the object representing the English language <https://www.wikifunctions.org/view/en/Z1002>. There is one implementation <https://www.wikifunctions.org/view/en/Z19296>, a composition: it uses the value by key function <https://www.wikifunctions.org/view/en/Z803>, a foundational function to work with objects in Wikifunctions. Every lexeme <https://www.wikifunctions.org/view/en/Z6005> consists of seven keys, as defined on the type page for lexemes <https://www.wikifunctions.org/view/en/Z6005>. In order to get the value of a specific key, we can use the value by key function <https://www.wikifunctions.org/view/en/Z803> with two arguments: the key <https://www.wikifunctions.org/view/en/Z39> we want to look up, and the object itself on which we perform the key lookup. It makes sense for most types to have a function for each key to decompose objects of that type. Language of Lexeme is such a function: it simply picks one of the keys of the Lexeme object and returns that.

1 0

2025

2024

2023

2022

2021

2020

Abstract-Wikipedia November 2024