Wikifunctions:Status-Updates/2024-12-12

Wikifunctions Status-Updates

Skizzieren eines Pfads zur Abstrakten Wikipedia

Das Hauptziel von Wikifunctions besteht darin, die Abstrakte Wikipedia zu unterstützen: eine Quelle für mehrsprachige Wikipedia-Inhalte, bei der wir die Inhalte nur einmal erstellen und pflegen müssen, sie aber in vielen verschiedenen Sprachen verfügbar haben, um einige der Lücken zu schließen, die derzeit in einigen Wikipedias bestehen.

Heute möchte ich skizzieren, wie die Generierung natürlicher Sprache für die Abstrakte Wikipedia aussehen könnte. Als Beispielziel nehmen wir den folgenden Satz (basierend auf dem Artikel der englischen Wikipedia über Waakye):

Englisch: "Waakye is a Ghanaian dish of cooked rice and beans."
Französisch: "Le waakye est un mets ghanéen de riz et de haricots cuits."
Deutsch: "Waakye ist ein ghanaisches Gericht aus gekochten Reis und Bohnen."

Wir betrachten vier Phasen, um zu diesem Text zu gelangen.

Phase 1: Zeichenkettenbasierte Substitution

In Phase 1 verwenden wir eine einfache Substitution von Zeichenketten im Stil von Mad Libs. Dieser Ansatz erfordert vom Benutzer, die richtigen Zeichenketten sorgfältig auszuwählen, was auf Englisch recht einfach ist, auf Französisch oder Deutsch jedoch komplizierter wird.

Wir könnten also die folgenden Funktionsaufrufe haben:

Instanz mit Ursprung in einer Zeichenketten auf Englisch("Waakye", "dish", "Ghanaian")

→ "Waakye is a Ghanaian dish."

Instanz mit Ursprung in einer Zeichenketten auf Französisch("Le waakye", "un mets", "ghanéen")

→ "Le waakye est un mets ghanéen."

Instanz mit Ursprung in einer Zeichenketten auf Deutsch("Waakye", "ein Gericht", "ghanaisches")

→ "Waakye ist ein ghanaisches Gericht."

Dies ist derzeit möglich. Es erfordert jedoch recht detaillierte Grammatikkenntnisse des Funktionsaufrufers, da er die richtige Form manuell eingeben muss. Der Nutzen dieser Methode ist in diesem Beispiel schwer zu erkennen.

Phase 2: Lexembasierte Generierung

In Phase 2 verwenden wir anstelle von Zeichenketten Wikidata-Lexeme, was seit den letzten Monaten möglich ist. Dies ermöglicht eine Version der Funktion, bei der sich der Funktionsaufrufer nicht um die Übereinstimmung und die manuelle Eingabe der richtigen Form kümmern muss, sondern der Funktionsimplementierer stattdessen die richtige Form aus dem Lexem auswählen muss. Dadurch wird ein Teil der Last vom Funktionsbenutzer auf den Funktionsautor verlagert.

Dies macht den Aufruf viel einfacher: Wir müssen nicht wissen, ob "waakye" auf Französisch "Le waakye" oder "La waakye" ist, wir müssen nicht das entsprechende Adjektiv im Deutschen auswählen ("ghanaisches Gericht" oder "ghanaischer Gericht"), etc. Die richtige Form wird von der Funktion ausgewählt.

Wir hätten also nun die folgenden Funktionsaufrufe:

Instanz mit Ursprung in einem Lexem auf Englisch(Lxxx/Waakye, L3964/dish, Lxxx/Ghanaian)

→ "Waakye is a Ghanaian dish."

Instanz mit Ursprung in einem Lexem auf Französisch(Lxxx/waakye, L24812/mets, Lxxx/ghanéen)

→ "Le waakye est un mets ghanéen."

Instanz mit Ursprung in einem Lexem auf Deutsch(Lxxx/Waakye, L500931/Gericht, Lxxx/ghanaisch)

→ "Waakye ist ein ghanaisches Gericht."

Du wirst auch feststellen, dass für dieses spezielle Beispiel viele Lexeme fehlen, wie zum Beispiel das französische Lexem für etwas aus Ghana. Wir in der Wikimedia-Bewegung müssen darüber nachdenken, wie wir diese Lücke in den Lexemen von Wikidata schließen können.

Wir hatten gehofft, dass dies jetzt möglich sein würde, und haben während unseres Offsite-Treffens eine Reihe von Funktionen erstellt, um diese Fähigkeiten zu testen. Leider mussten wir feststellen, dass das System derzeit die meisten dieser Funktionsaufrufe nicht auswerten kann. Aus diesem Grund haben wir beschlossen, im kommenden Quartal einen großen Schwerpunkt darauf zu legen, diese Funktionen zum Laufen zu bringen.

Phase 3: Datenobjektbasierte Generierung

Im dritten Schritt würden wir Wikidata-Datenobjekte verwenden, um Lexeme mit vergleichbaren Bedeutungen aus einer bestimmten Sprache auszuwählen. Der Funktionsaufrufer muss das richtige Lexem nicht in allen Sprachen kennen oder nachschlagen, in denen er den Text generieren möchte. Er kann einfach die relevanten Wikidata-Datenobjekte eingeben und der Funktionsentwickler kann die entsprechenden Nachschlagevorgänge implementieren.

Dies bedeutet, dass der Funktionsaufrufer unabhängig davon, ob er weiß, dass das Konzept "Gericht" auf Französisch "mets" bzw. auf Deutsch "Gericht" heißt, dennoch in der Lage sein wird, vollkommen flüssige und korrekte Sätze in diesen Sprachen zu bilden.

Dies ermöglicht uns, die folgenden Aufrufe zu tätigen (beachte, dass alle drei Aufrufe hier dieselbe Funktion verwenden und der Anrufer die Sprachen überhaupt nicht kennen muss):

Instanz mit Ursprung(Q14783691/Waakye, Q746549/Gericht, Q117/Ghana, Z1002/Englisch)

→ "Waakye is a Ghanaian dish."

Instanz mit Ursprung(Q14783691/Waakye, Q746549/Gericht, Q117/Ghana, Z1004/Französisch)

→ "Le waakye est un mets ghanéen."

Instanz mit Ursprung(Q14783691/Waakye, Q746549/Gericht, Q117/Ghana, Z1430/Deutsch)

→ "Waakye ist ein ghanaisches Gericht."

Beachte, dass die Funktion in den meisten Fällen nur zu den sprachspezifischen Funktionen weiterleitet, die für die vorherige Phase entwickelt wurden. Dies geschieht jedoch im Hintergrund und ist für den Funktionsaufrufer transparent.

Dies lässt sich derzeit nicht mit Wikifunctions implementieren — wir müssen noch eine Funktion hinzufügen, mit der wir die mit einem bestimmten Datenobjekt verknüpften Lexeme finden können. Daran werden wir im kommenden Quartal arbeiten und sind den Teams Suche und Wikidata für die notwendige Vorarbeit dankbar, die sie kürzlich geleistet haben, um diese Möglichkeit zu schaffen.

Phase 4: Datenobjektbasierter Inhalt

Die letzte Phase, die wir heute besprechen möchten, basiert auf der Verwendung des Wissens in Wikidata zur Texterstellung. Wir können aus Wikidata entnehmen, dass Q14783691/Waakye ein Gericht aus Q117/Ghana ist, wir können die Zutaten und ihre Lexeme nachschlagen, etc. Angesichts des aktuellen Wissens über Waakye in Wikidata könnten dann die folgenden Sätze generiert werden:

Nahrung mit Ursprung und Zutaten(Q14783691/Waakye, Z1002/Englisch)

→ "Waakye is a Ghanaian dish with bean, rice, water, and salt."

Nahrung mit Ursprung und Zutaten(Q14783691/Waakye, Z1004/Französisch)

→ "Le waakye est un plat ghanéen composé de haricots, de riz, d'eau et de sel."

Nahrung mit Ursprung und Zutaten(Q14783691/Waakye, Z1430/Deutsch)

→ "Waakye ist ein ghanaisches Gericht aus Bohnen, Reis, Wasser und Salz."

Dies vereinfacht das Schreiben der Funktionsaufrufe weiter: Wir müssen nur das Gericht und die Sprache auswählen und erhalten einen ganzen Satz, der in vielen Fällen als Einleitungssatz für den Wikipedia-Artikel über das jeweilige Gericht oder als Eintrag oder Kurzbeschreibung an verschiedenen Stellen dienen kann.

Ich hoffe, dass dies einen guten Überblick über unsere nächsten geplanten Schritte im Hinblick auf die Generierung natürlicher Sprache gibt und wie Wikifunctions dabei helfen kann, unsere unterschiedlichen Sprachgemeinschaften zusammenzubringen.

Offsite des Teams in Lissabon

Letzte Woche traf sich das Team zu seinem Jahrestreffen in Lissabon, Portugal. Was für eine schöne Stadt! Wir genossen es, durch die Stadt zu spazieren und hatten sehr produktive Treffen, bei denen wir unsere Pläne und Teamabläufe besprachen und die Zeit für Bindung und sozialen Zusammenhalt nutzten – was in einem Team, das komplett remote arbeitet, sehr schwierig und wichtig ist.

Das greifbarste Ergebnis ist die Planung für das nächste Quartal. Wir haben sehr lebhaft diskutiert, um einen Konsens zu finden, den wir noch schriftlich festhalten müssen. Wir werden in einem der nächsten beiden Updates über den Plan berichten.

Neues Werkzeug zur Abfrage von Wikifunctions

Feeglgeef hat ein neues Werkzeug erstellt, mit dem du Wikifunctions auf sehr flexible Weise abfragen kannst. Du kannst nach Funktionen mit Implementierungen in Python suchen, nach Typen, die Zahlen als Schlüssel verwenden, nach Funktionen, die drei Argumente annehmen oder boolesche Werte zurückgeben. Das Werkzeug ist auf Replit verfügbar (beachte, dass dies außerhalb der Wikimedia-Server liegt) und Beispiele und Dokumentation der Abfragesprache sind auf der Startseite des Werkzeugs verlinkt: wf-query.replit.app

Hogü-456 hat eine Übersicht über vorhandene Werkzeuge erstellt. Wenn du weitere Werkzeuge kennst, kannst du sie gerne hinzufügen: Wikifunctions:Tools

Letzte Änderungen an der Software

Aufgrund der vom Release Engineering Team angeordneten Veröffentlichungspause gibt es diese Woche keine Veröffentlichung der MediaWiki-Software, daher gibt es keine Neuigkeiten. Wie immer benachrichtige uns bitte, wenn du auf Probleme stößt.

Neuigkeiten zu Typen: Datum des Gregorianischen Kalenders, Byte, Unicode-Codepunkt

Endlich haben wir einen Typ für Datumsangaben im Gregorianischen Kalender. Wir haben eine ganze Weile daran gearbeitet und einen Typ für die relevanten Monate, für Jahre, etc. erstellt. Die Diskussion war langwierig und führte nicht zu einem vollständigen Konsens. Eine Begründung für die Entscheidungen zum Design des Typs wird bereitgestellt. Wir laden dich ein, Funktionen mit dem Typ zu erstellen!

Dies ist bei weitem der komplexeste Typ, den wir bisher anbieten.

Wir möchten Typen für andere, nicht-gregorianische Kalender erstellen, wie den chinesischen, äthiopischen, japanischen, hebräischen und andere Kalender. Wenn du einen dieser Kalender gut kennst, wende dich bitte an uns, damit wir die entsprechenden Kalender erstellen können.

Zu anderen Arbeiten mit Bezug zu Typen zählen Vorschläge zur Reparatur des Byte-Typs und des Unicode-Codepunkt-Typs (früher Zeichentyp), die gemacht wurden. Beiträge und Diskussionen sind sehr willkommen.

Aufzeichnung des Freiwilligentreffens im Dezember

Freiwilligentreffen im Dezember 2024

Am Montag, dem 9. Dezember, hatten wir ein Freiwilligentreffen. Es war lebhaft und es gab viele gute Fragen. Eine Aufzeichnung des Treffens ist auf Commons verfügbar.

Die Funktion, die wir gemeinsam erstellt haben, wird unten als Funktion der Woche vorgestellt.

Aufzeichnung von Dennys Vortrag bei der SWIB24

Denny Vrandečić hielt auf der Konferenz Semantic Web in Libraries 2024 einen Vortrag. Das Thema war die Rolle von Wissensrepräsentationen in einer Welt großer Sprachmodelle. Die Aufzeichnung ist auf YouTube verfügbar.

Funktion der Woche: Anzahl der Tage zwischen zwei Tagen im Römischen Jahr

Im letzten Newsletter wurden die Tage des Römischen Jahres als neuer Typ vorgestellt. Bis jetzt haben wir 18 neue Funktionen, die diesen Typ verwenden. Auch beim Freiwilligentreffen in dieser Woche wurde eine solche Funktion erstellt, daher werden wir uns diese Funktion ansehen.

Wie viele Tage liegen zwischen zwei Tagen? Diese Frage kann die Funktion Z20733 beantworten. Die Funktion hat drei Argumente: die beiden Tage und einen booleschen Wert, der angibt, ob die Tage in einem Schaltjahr liegen oder nicht. Sie gibt eine natürliche Zahl zurück, die angibt, wie viele Tage zwischen den beiden angegebenen Tagen liegen.

Was die Funktion macht, lässt sich wahrscheinlich am einfachsten anhand der Tests verdeutlichen:

Vom 1. Januar bis 15. Januar sind es 14 Tage
Vom 1. Januar bis 31. Dezember sind es 364 Tage in einem normalen Jahr
Vom 28. Februar bis 1. März ist es ein Tag in einem normalen Jahr
Aber zwei Tage in einem Schaltjahr

Die Tests sind unvollständig. Besonders auffällig ist das Fehlen von Tests, bei denen der erste Tag nach dem zweiten liegt und was das genau für das Verständnis des Schaltjahres bedeutet.

Aktuell gibt es für diese Funktion bisher nur eine Implementierung, was unter anderem daran liegt, dass wir beim Freiwilligentreffen nicht mehr viel Zeit hatten und daher nur eine als Komposition gemacht haben, da wir fanden, dass sich die Funktion so am einfachsten implementieren lässt.

Der Kern der Komposition besteht darin, beide Tage in eine Zahl umzuwandeln, indem man zählt, welcher Tag im Jahr es ist (d. h. der 1. Januar ist der erste Tag, der 2. Januar der zweite, der 1. Februar der 32., etc.) und dann die erste Zahl von der zweiten abzuziehen. Das Ergebnis wird dann von einer Ganzzahl in eine natürliche Zahl umgewandelt, um negative Zahlen zu vermeiden.