The on-wiki version of this newsletter can be found here: https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2025-02-13 -- Restricting the World, redux https://www.wikifunctions.org/wiki/File:Hot_air_balloon_and_moon.jpg

Twelve years ago, I wrote an essay describing one of the fundamental design choices for Wikidata: Restricting the World https://blog.wikimedia.de/2013/02/22/restricting-the-world/.

In that essay I was arguing that the Wikidata software should not restrict the knowledge represented in Wikidata: instead of having fixed fields for each type of entry, Wikidata was designed to allow for any kind of structures. This would allow us to capture as much of the complexities of the world as possible.

It makes reuse more difficult. Because we can never be sure about the structure of an item: will that country item have a capital? A population? How will the family of a person be represented, if at all?

Over the years, numerous features and systems grew in order to support Wikidata with better structuring of its content. A constraint system surrounding properties https://www.wikidata.org/wiki/Help:Property_constraints_portal grew. Schema definitions https://www.wikidata.org/wiki/Wikidata:Schemas were introduced. Recommender systems https://www.wikidata.org/wiki/Wikidata:Recoin were suggesting missing properties based on the existing structure. All of these, and much more, allowed for the data in Wikidata to grow towards a more cohesive and consistent place.

Now, with Wikifunctions, we are on the other side: instead of a flexible knowledge base, we prefer predictable, strict structures. When writing a Function implementation to get the right form of a verb, we need to know what structures verbs in the given language use. What are the grammatical features that are being used for the forms? Which forms will be given in Wikidata? Which grammatical features will they have?

The flexibility, which I still think is a necessary design decision for a knowledge base such as Wikidata, becomes a minor burden for a system such as Wikifunctions that aims to use that knowledge. But we have unique advantages: both projects can work together, towards a compromise between the flexibility that we need to represent the world in Wikidata, and the requirements for the knowledge representation to become processable in Wikifunctions. Wikifunctions can deal with a certain amount of flexibility, and Wikidata can benefit from a certain amount of unification. Wikifunctions will be like a forcing function for some parts of Wikidata.

One way to resolve some of the tension is to decouple Wikidata from Wikifunctions in certain ways, as we have already been doing. The truth values in Wikifunctions are not Wikidata's Q16751793 https://www.wikidata.org/wiki/Q16751793 and Q5432619 https://www.wikidata.org/wiki/Q5432619, they are true (Z41) https://www.wikifunctions.org/view/en/Z41 and false (Z42) https://www.wikifunctions.org/view/en/Z42. The current month of February is Q109 https://www.wikidata.org/wiki/Q109 in Wikidata and February ( Z16102) https://www.wikifunctions.org/view/en/Z16102 in Wikifunctions. Dagbani is the first language edition of Wikipedia on which Wikifunctions will be enabled; the language is Q32238 https://www.wikidata.org/wiki/Q32238 in Wikidata and Dagbani (Z1015) https://www.wikifunctions.org/view/en/Z1015 in Wikifunctions. Did we get the decoupling right? Probably not. Why do we need labels for February both in Wikifunctions and Wikidata? Do we want to have several different values for the feminine and masculine grammatical genders for several different systems? This is something we want to look very soon at.

But in other cases, decoupling can be very beneficial. By decoupling from Wikidata we can have somewhat more control about the representation as we need it. If the knowledge base changes, we can retain our functionality and move at our own speed, because the representation of Dagbani in Wikifunctions is not meant to represent the language in the sense of an encyclopedia-supporting knowledge base, but merely in a way that is pragmatically useful for Wikifunctions.

All of this is particularly true and relevant for representing lexemes in Wikifunctions, a discussion that is currently ongoing on the project chat and other channels. More about this next week, also in the NLG SIG next week! Invitation to the NLG SIG meeting on February 18

On February 18, 2025, at 16:00 UTC https://zonestamp.toolforge.org/1739894400, we will have our first public Natural Language Generation Special Interest Group meeting on Google Meet https://meet.google.com/xzn-kqer-mah. The meeting is planned to be recorded. A wiki page for the NLG SIG https://www.wikifunctions.org/wiki/Wikifunctions:NLG_SIG has been created, and an agenda is being collected there. Recent Changes in the software

Only one bug fix will be released this week; most of our efforts have gone towards priority, longer-term work.

We fixed a bug that meant that on Function pages' tables, the pagination control never showed up on the Implementations table and on the Test cases one only when there were four or more Implementations (T385776 https://phabricator.wikimedia.org/T385776).

We, along with all Wikimedia-deployed code, are now using the latest version of the Codex UX library, v1.20.1, 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.

We also wanted to use this weekly update to highlight that we will be removing the functionality that currently replaces the shown version of a link to an Object with its name. This feature from the early days of the project has suffered from issues related to pages showing in the wrong language, and isn't compatible with our switch to the Parsoid rendering engine anyway (T343483 https://phabricator.wikimedia.org/T343483). We will keep the feature for special pages (which don't suffer from this bug), like Special:RecentChanges https://www.wikifunctions.org/wiki/Special:RecentChanges and Special:WhatLinksHere https://www.wikifunctions.org/wiki/Special:WhatLinksHere. In lieu of the Function of the Week: Schrödinger Model sub shell configuration

*The Function of the Week is a column written by the community. Planning the column and submissions can be made here https://www.wikifunctions.org/wiki/Special:MyLanguage/Wikifunctions:Function_of_the_Week/submissions.*

Last week I noticed a contributor, MolecularPilot https://www.wikifunctions.org/wiki/User:MolecularPilot, telling us in the chat how they were doing an assignment while learning chemistry. So they started a function to automate it, calculating Schrödinger’s Model for sub shell configuration https://www.wikifunctions.org/view/en/Z22155.

I really enjoyed the insight they described after they created the Function:

*Ironically making the function actually helped me understand the underlying concepts a lot better than just repeating it over and over!! I think making Wikifunctions makes you have to think about something in a kind of computational and logical kind of way using a problem solving mindset.*

I hope you enjoy this quote too! News in Types: Byte

This week we implemented the proposal to fix up the Byte type https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/Byte. We removed the markers from the type so it can be used, and more functions can be created for the Byte type. We are looking forward to having a display and read function for this type available, too. Fresh Functions weekly

Here is a list of new functions that have been created since last week, with connected implementations and passing tests. This week we had a good number of new functions to celebrate.

- Kleenean inequality (Z22231) https://www.wikifunctions.org/view/en/Z22231 - remainder of float64 division (Z22236) https://www.wikifunctions.org/view/en/Z22236 - Gregorian calendar month to Wikidata reference (Z22240) https://www.wikifunctions.org/view/en/Z22240 - Wikidata item reference from QID string (Z22246) https://www.wikifunctions.org/view/en/Z22246 - Wikidata lexeme reference from LID string (Z22249) https://www.wikifunctions.org/view/en/Z22249 - equality of Kleenean and Boolean (Z22257) https://www.wikifunctions.org/view/en/Z22257 - Malayalam numerals to Arabic numerals (Z22267) https://www.wikifunctions.org/view/en/Z22267 - read Malayam natural numbers leniently (Z22271) https://www.wikifunctions.org/view/en/Z22271 - Khmer numerals to Arabic numerals (Z22279) https://www.wikifunctions.org/view/en/Z22279 - Thai numerals to Arabic numerals (Z22285) https://www.wikifunctions.org/view/en/Z22285 - Burmese numerals to Arabic numerals (Z22288) https://www.wikifunctions.org/view/en/Z22288 - Bengali numerals to Arabic numerals (Z22291) https://www.wikifunctions.org/view/en/Z22291 - Devanagari numerals to Arabic numerals (Z22294) https://www.wikifunctions.org/view/en/Z22294 - Gujarati numerals to Arabic numerals (Z22297) https://www.wikifunctions.org/view/en/Z22297 - string of numeral digits in order from language (Z22302) https://www.wikifunctions.org/view/en/Z22302 - square root of float64 (Z22318) https://www.wikifunctions.org/view/en/Z22318 - Population density (Z22322) https://www.wikifunctions.org/view/en/Z22322 - Annual Population growth rate (Z22327) https://www.wikifunctions.org/view/en/Z22327 - str left (Z22344) https://www.wikifunctions.org/view/en/Z22344

We can see a rich variety of functions – and there were even more who didn’t make it to the list because they didn’t have tests or implementations. A comprehensive list of all functions sorted by creation date https://www.wikifunctions.org/wiki/Special:ListObjectsByType?type=Z8&orderby=latest can be found on-wiki.