Wikifunctions:Status-Updates/2024-11-27

◀

Wikifunctions Status-Updates

▶

WordGraph: (fast) eine Millionen Formen zur Beschreibung von Personen

Ein verspätetes Geschenk zum 12. Geburtstag von Wikidata: Ein Team bei Google Zürich hat den WordGraph-Datensatz veröffentlicht, fast eine Millionen Wortformen in einer strukturierten Darstellung, die sich leicht auf Wikidata hochladen lässt. Laut seiner Selbstbeschreibung “enthält der WordGraph-Datensatz mehrsprachige Lexikoneinträge, die mit Wikipedia-Entitäten verknüpft sind und sich auf menschenbezeichnende Nomen und demonyme Adjektive konzentrieren. Jeder Lexikoneintrag enthält flektierte Wortformen und morphologische Informationen für alle Ortsangaben.”

Der Datensatz enthält 968.153 Formen in 39 Sprachen. Der Datensatz ist auf GitHub verfügbar und unter CC0 veröffentlicht, was ihn mit Wikidata kompatibel macht. Wir haben eine Übersicht mit einigen Statistiken zum Datensatz erstellt, verglichen mit Wikidata. Die Sinne sind bereits Wikidata-QIDs zugeordnet, ebenso wie die grammatikalischen Funktionen, was das Hinzufügen zu Wikidata besonders einfach macht.

Mit der Auswahl an menschenbezeichnenden Nomen und Demonymen ist dieser Datensatz besonders nützlich für abstrakte Beschreibungen von Personen in Wikidata – und Personen sind schließlich der größte Typ von Datenobjekten, zu dem es Wikipedia-Artikel gibt. Diese Lexeme helfen uns dabei, Beschreibungen wie “irischer Rugbyspieler”, “ghanaischer Sänger” oder “indischer Mathematiker” in vielen Sprachen zu erstellen.

Wir möchten Bruno Cartoni, Saran Lertpradit, Seungmin Back, Daniel Calvelo Aros, Kuang-Yu Samuel Chang und Abdelrahman Nabil von Google für dieses wunderbare Geschenk danken. Wir laden alle ein, an der Anreicherung von Wikidata mit diesen lexikografischen Daten mitzuarbeiten.

Neue Spezialseite: Liste der Funktionen gefiltert nach ihren Tests

Diese Woche freuen wir uns, eine neue Spezialseite: Liste der Funktionen gefiltert nach ihren Tests einzuführen. Auf der Seite kannst du alle Funktionen auflisten, die weniger als eine bestimmte Anzahl von Tests haben (z. B. weniger als zwei Tests) oder sie kann helfen, Funktionen zu finden, die erfolgreiche Tests haben, die noch nicht verbunden sind. Oder auf der anderen Seite Funktionen mit fehlgeschlagenen Tests, die noch verbunden sind. Wir können nach Funktionen, die überhaupt keine Tests haben, suchen oder nach denen, die keine verbundenen Tests haben oder nach Funktionen mit mehr als einem Dutzend Tests.

Diese Spezialseite dürfte besonders für Funktionsbearbeiter nützlich sein, die nach Tests und Implementierungen zum Verbinden suchen.

Auf der Seite kannst du:

• einen Zahlenbereich angeben, der als Untergrenze und Obergrenze (beide inklusive) angegeben wird, um die Anzahl der Tests zu begrenzen, die den unten angegebenen Testmerkmalen entsprechen sollen;
• angeben, ob wir verbundene Tests oder noch nicht verbundene Tests zählen möchten (oder beides, in diesem Fall lässt du beide Kontrollkästchen leer); und
• angeben, ob wir nur Tests zählen möchten, die alle verbundenen Implementierungen bestehen, oder Tests, die für einige der verbundenen Implementierungen fehlschlagen (oder beides, in diesem Fall lässt du beide Kontrollkästchen leer)

Deine resultierende Seite kann über ihre URL geteilt werden.

Wir hoffen, dass diese neue Seite bei der Pflege von Wikifunctions hilfreich sein wird!

Mehr Aussagen!

Die Abschnitte zu Aussagen von Wikidata-Lexemen, Lexemformen und Lexemsinnen wurden letzte Woche umfassend aktualisiert. Jeder Abschnitt zu Aussagen enthält eine Liste von Wikidata-Aussagen. Bisher waren nur Aussagen mit Zeichenketten-Werten enthalten. Dies wurde erweitert und umfasst nun Aussagen mit allen folgenden Wertetypen:

• Zeichenkette
• Lexem-Referenz
• Lexemform-Referenz
• Lexemsinn-Referenz
• Datenobjekt-Referenz
• Einsprachiger Text

Darüber hinaus enthalten alle Aussagen jetzt zusätzlich zu ihrem Subjekt, Prädikat und Wert einen Rang. Weitere Einzelheiten finden sich unter Wikifunctions:Unterstützung für Wikidata-Inhalte.

Zu diesem Zweck haben wir letzte Woche einen neuen Schlüssel zu Wikidata-Aussage hinzugefügt, der den Rang darstellt. Ein großes Dankeschön an die Community für die großartige und sorgfältige Aufräumarbeit!

Neuer Typ: Tag des Römischen Jahres

Diese Woche führen wir einen neuen Typ ein: Der Tag des Römischen Jahres ermöglicht es uns, einen bestimmten Tag in einem Jahr anzugeben, z. B. den 27. November, den Tag, an dem dieser Newsletter erscheint. Ein Tag wird durch eine natürliche Zahl für den Tag des Monats und einen Gregorianischen Monat dargestellt.

Wir hatten auch vor, den Gregorianischen Datumstyp zu veröffentlichen. Aber während wir die Umwandler für den Typ implementierten und die erste Funktion ausführten, die den neuen Typ zurückgab, stellten wir fest, dass die Arbeit mit dem Typ ziemlich schwierig war und durch Rückmeldungen aus der Community wurden Bedenken geäußert. Aus diesem Grund haben wir den Typ erneut mit “nicht verwenden” markiert und bitten um mehr Rückmeldungen und Diskussionen auf der Seite des Typvorschlags.

Das Datum im Gregorianischen Kalender wird durch einen Tag des Jahres und ein Gregorianisches Jahr dargestellt. Dies ermöglicht es uns schließlich, einen Tag gemäß dem proleptischen Gregorianischen Kalender zu identifizieren, z. B. den 15. Januar 2001, den Tag, an dem Wikipedia gegründet wurde, oder den 15. Oktober 1582, den Tag, an dem der Gregorianische Kalender eingeführt wurde.

Beachte, dass der Gregorianische Datumstyp noch nicht mit dem Datentyp Zeitpunkt auf Wikidata identisch ist, er ist jedoch ein notwendiger Schritt auf dem Weg dorthin.

Letzte Änderungen an der Software

Letzte Woche haben wir die neue Spezialseite Special:ListMissingLabels vorgestellt, um Funktionen und andere Objekte zu finden, denen in einer Sprache eine Bezeichnung fehlt. Heute haben wir die geplante Arbeit in diesem Bereich mit Special:ListFunctionsByTests abgeschlossen, wie oben angekündigt. Wir hoffen, dass diese Seite der Wikifunctions-Community dabei hilft, Arbeiten, die erledigt werden müssen, leichter aufzuspüren (T377909 und T377910). Wir haben auch Special:ListObjectsByType geändert, um ein ausklappbares Menü zur Auswahl des Zieltyps zu verwenden, um den anderen Spezialseiten zu entsprechen (T296315), und um dir die Sortierung der Ergebnisse nicht nur alphabetisch, sondern auch nach Neuheit, entweder aufsteigend oder absteigend, zu ermöglichen (T343633).

Wir haben einen großen Teil des von uns erstellten Validierungscodes, der innerhalb der MediaWiki-Seite des Wikifunctions-Ökosystems läuft, verworfen, da er komplex, fehlerhaft — was mindestens einen teilweisen Ausfall der Seite verursachte (T374241) — und langsam war. Die Validierung gespeicherter und nicht gespeicherter Objekte wird größtenteils weiterhin stattfinden, aber in weniger Codeteilen. Dies sollte die Seite bei der Nutzung etwas schneller machen, aber auch, noch wichtiger, das Risiko von Abstürzen (zumindest in diesem Bereich) vermeiden.

Wir haben außerdem den PHP-seitigen Akzeptanzcode so optimiert, dass nur Zeichenketten als Z2K1-Werte zugelassen werden, wo wir zuvor hauptsächlich zu Testzwecken nachlässig waren (T296724). Wir glauben nicht, dass diese Änderung für den Benutzer sichtbare Auswirkungen haben sollte. Und schließlich haben wir im Bereich der Validierung diese Woche den PHP-Code korrigiert, damit nicht versucht wird, die Gültigkeit von Objekten in Z99/Zitat-Objekten zu prüfen, da diese ungültig sein können, beispielsweise bei der Verarbeitung eines Fehlers, der bemängelt, dass die Eingabe ungültig war (T380386).

Schließlich haben wir im Rahmen der Hinzufügung zu MediaWiki Unterstützung für die Sprachen Z1952/bax-bamu (T379870), Z1953/xon (T380246) sowie Z1954/cdo-hant und Z1955/cdo-latn (T139010, T379829 und T380046) zu Wikifunctions hinzugefügt.

Nächstes Freiwilligentreffen am 9. Dezember

Aufgrund eines Offsite-Treffens in der nächsten Woche müssen wir das nächste Freiwilligentreffen (und das letzte des Jahres) um eine Woche auf den 9. Dezember um 16:30 MEZ am üblichen Ort verschieben. Das Freiwilligentreffen im Januar wird ebenfalls um eine Woche auf den 13. Januar verschoben.

Kein Update in der nächsten Woche

Da desselben Offsite-Treffens in der nächsten Woche werden wir auch das Update der nächsten Woche ausfallen lassen. Wir sehen uns in zwei Wochen wieder!

Funktion der Woche: ist Schaltjahr

Da in Nordamerika diese Woche Thanksgiving ist, möchte ich mich bei unserer großartigen Community von Mitwirkenden bei Wikifunctions bedanken! Anfang des Jahres habe ich in diesem Newsletter die Rubrik “Funktion der Woche” ins Leben gerufen. Ich wollte einige der großartigen Arbeiten der Community hervorheben und sie als Mittel nutzen, um einige der Konzepte zu erklären, an denen Wikifunctions arbeitet.

Als das Jahr begann, war ich wirklich besorgt, ob wir jede Woche eine Funktion präsentieren könnten. Aber ihr habt meine Erwartungen bei weitem übertroffen und meine Sorgen auf wunderbare Weise widerlegt. Es gab nicht nur mehr als genug Material, um eine Funktion der Woche zu präsentieren, sondern ihr habt auch mehr als genug Funktionen erstellt, um eine Funktion des Tages zu präsentieren. Das ist absolut erstaunlich und ich möchte euch allen dafür danken!

Diese Woche kommen wir zu einer Funktion, auf die ich schon eine Weile gewartet habe, und nachdem wir letzte Woche den Typ Gregorianisches Jahr eingeführt haben, konnte sie endlich implementiert werden: ist Schaltjahr (Z20181).

Ist Schaltjahr verwendet ein einzelnes Argument, ein Gregorianisches Jahr, und gibt einen einfachen booleschen Wert zurück: Sie gibt wahr zurück, wenn das angegebene Jahr ein Schaltjahr ist, andernfalls falsch.

Schaltjahre wurden vor vielen Jahren eingeführt, als die Leute bemerkten, dass ihre Kalenderjahre, Jahreszeiten und der Himmel nicht perfekt übereinstimmten. Im alten Rom wurde eine Rolle eingeführt, der Pontifex maximus, der oberste Brückenbauer zwischen unserer Welt und der Welt im Himmel, und seine Aufgabe bestand unter anderem darin, dafür zu sorgen, dass die menschliche Kalenderzählung mit den tatsächlichen Jahreszeiten und anderen himmlischen Ereignissen übereinstimmte. Ursprünglich entschied der Pontifex maximus einfach Jahr für Jahr, wie lang das Jahr sein sollte. Julius Caesar wurde 63 v. Chr. zum Pontifex maximus, aber anstatt Jahr für Jahr zu entscheiden, reformierte er den Kalender und stellte vorhersehbare Regeln auf: Jedes Jahr sollte 365 Tage haben, aber jedes vierte Jahr sollte ein Schaltjahr sein und das ist 366 Tage lang. Diese Regel galt einige Jahrhunderte lang.

Später übernahm der katholische Papst die Rolle des Pontifex maximus. Der Kalender geriet wieder aus dem Takt mit der Realität, und so erließ Papst Gregor XIII. als Pontifex maximus 1582 eine Bulle zur Einführung des Gregorianischen Kalenders. Die Bulle hatte zwei Haupteffekte: Erstens wurden zehn Tage aus dem Kalender gestrichen, um ihn wieder mit den Jahreszeiten in Einklang zu bringen, und zweitens wurden die Regeln geändert, um ein weiteres Auseinanderdriften der beiden Kalender zu verhindern. Jedes vierte Jahr war immer noch ein Schaltjahr, aber es gab eine Ausnahme: Jedes hundertste Jahr wurde das Schaltjahr übersprungen. Aber es gibt auch eine Ausnahme von dieser Ausnahme: Alle 400 Jahre überspringen wir das Schaltjahr nicht. 1900 hatte also 365 Tage und 2100 wird 365 Tage haben, aber 2000 hatte 366 Tage.

Während die meisten Menschen die Vierjahresregel des Julianischen Kalenders kennen, kennen weniger Menschen die Regeln des Gregorianischen Kalenders (angesichts der Seltenheit ihres Auftretens ist das nicht gerade überraschend). Daher ist es nicht überraschend, dass es viele falsche Implementierungen dieser Funktion gibt. Wenn man auf GitHub nach Implementierungen der Schaltjahrregel sucht, findet man leicht Dutzende von Implementierungen, die die Schaltjahrregel nur teilweise oder falsch anwenden. Ein weiteres Beispiel dafür, warum es im Allgemeinen eine gute Idee ist, eine große Funktionsbibliothek zu haben!

Die Funktion hat eine solide Reihe von Tests:

• dieses Jahr, 2024, ist ein Schaltjahr
• nächstes Jahr, 2025, ist es nicht
• 2000 war ein Schaltjahr, das letzte Vorkommen der Regel zum Überspringen des Auslassens des Schaltjahrs
• 1900 war kein Schaltjahr, das letzte Vorkommen des Überspringens des Schaltjahrs
• 1582 war ebenfalls kein Schaltjahr
• 1 v. Chr. war ein Schaltjahr
• 5 v. Chr. war ein Schaltjahr, da es vier Jahre vor 1 v. Chr. war
• 2025 v. Chr. war ebenfalls ein Schaltjahr
• 1300 war ein Julianisches Schaltjahr, aber keines im proleptischen Gregorianischen Kalender
• 4000 n. Chr. wird ein Schaltjahr im Gregorianischen Kalender sein, allerdings nicht in der von Herschel vorgeschlagenen Modifikation

Beachte, dass die Menschen, die im Jahr 2025 v. Chr. lebten, offensichtlich weder wussten, dass sie im Jahr 2025 v. Chr. lebten, noch dass sie in einem Schaltjahr lebten. Das ist die Bedeutung von proleptisch: Es wird anachronistisch in der Vergangenheit angewendet.

Die Funktion hat derzeit die folgenden Implementierungen:

• eine in Python, die in gewisser Weise die üblichen Regeln darstellt: Wenn die Jahreszahl durch 4 geteilt werden kann, aber nicht durch 100, sondern dann durch 400, dann ist es ein Schaltjahr.
• eine in JavaScript, die laut einer ausführlichen StackOverflow-Antwort die schnellstmögliche Prüfung ist (aber wahrscheinlich nicht in unserer Implementierung, da wir BigInt verwenden)
• eine Komposition, die die Jahreszahl in das Jahr nach ISO 8601 umwandelt (und so 1 v. Chr. in 0, 2 v. Chr. in -1 etc. umwandelt) und dann eine Reihe von wenns verwendet: wenn es durch 400 teilbar ist, dann wahr, sonst wenn es durch 100 teilbar ist, dann falsch, sonst ob es durch 4 teilbar ist.
• und eine recht reizvolle Komposition, die überprüft, ob der Wochentag des letzten Tages des Jahres der gleiche Wochentag ist, wie der darauffolgende Wochentag des ersten Tages des Jahres.

Die Codeimplementierungen profitieren von der Darstellung negativer Jahre durch eine implizite ISO-8601-Umwandlung, sodass die üblichen Regeln direkt angewendet werden können.

Ich finde es überhaupt nicht offensichtlich, dass die gegebenen Implementierungen immer das gleiche Ergebnis liefern würden. Aber angesichts der bestandenen Tests bin ich ziemlich zuversichtlich, dass sie tatsächlich austauschbar sind.