Abstrakte Wikipedia/Aufgaben

This page is a translated version of the page Abstract Wikipedia/Tasks and the translation is 100% complete.

Bestandteil von Abstrakte Wikipedia: Projektplan.

Fortsetzung von Abstrakte Wikipedia: Komponenten.

Die Entwicklung erfolgt in zwei Hauptteilen. Projektteil P1 wird Wikifunctions entwickeln und in Betrieb nehmen, wobei dieses in der Lage sein wird, die Inhaltserzeugung zu unterstützen, die für Projektteil P2 benötigt wird. Projektteil P2 enthält dann die Inhaltserzeugung innerhalb von Wikidata und ermöglicht den Wikipedien den Zugang zu diesem Inhalt. Anschließend wird laufend weiterentwickelt, um Wikifunctions und Abstrakte Wikipedia zu verbessern. Diese laufende Entwicklung ist nicht Bestandteil dieses Projektplans. Man beachte, dass die Zeitplanung von den verfügbaren Mitwirkendenkapazitäten abhängt.

Im ersten Jahr werden wir ausschließlich Projektteil P1 bearbeiten. Projektteil P2 beginnt mit dem zweiten Jahr. Dann wird zusätzliche Personalkapazität hinzukommen. Teile P1 und P2 werden dann für 18 Monate parallel laufen. Abhängig von Ergebnis und Erfolg des Projekts muss die Personalausstattung für die weitere Entwicklung etwa in Monat 24 beschlossen und anschließend regelmäßig überprüft werden.

Dieser Plan umfasst die ersten 30 Monate der Entwicklung. Die wesentlichen Ergebnisse werden sein:

Wikifunctions, ein neues Projekt und Wiki der WMF, mit einer eigenen Community und einem eigenen Auftrag. Das Ziel ist es, einen Katalog an Funktionen bereitzustellen. Der Katalog soll jedermann frei zugänglich sein, sodass alle Projektteilnehmenden zur Mitarbeit befähigt werden, indem der Zugang zu computergestütztem Wissen demokratisiert wird.
Ein wikiübergreifendes Repositorium, um Vorlagen und Module zwischen den WMF-Projekten zu teilen, was sich die Communities schon lange wünschen. Dies wird Bestandteil von Wikifunctions werden.
Die Abstrakte Wikipedia ist ein wikiübergreifendes Projekt, das es ermöglicht, Inhalte in Wikidata unabhängig von einer natürlichen Sprache zu definieren. Sie wird in mehrere lokale Wikipedien integriert, sodass die Menge an Wissen beträchtlich vergrößert wird, an dem Sprecher bislang unterrepräsentierter Sprachen teilhaben können.

Projektteil P1: Wikifunctions

Aufgabe P1.1: Projektinitialisierung

Wir werden Wikiseiten erstellen für Meta, Fehlerkomponenten, Mailinglisten, Chaträume und für einen Beirat. Für die Diskussion mit der breiteren Community werden wir weitere wesentliche Werkzeuge bereitstellen. Für die Namensgebung für Wikifunctions und Abstrakte Wikipedia werden wir die Diskussion eröffnen und die Namen beschließen. Wir werden Wettbewerbe für die Logos ausschreiben und die Schaffung eines Verhaltenskodex organisieren. Wir werden die für eine gesunde Community notwendigen Schritte tun.

Wir müssen auch den Community-Prozess zur Festlegung der Lizenzwahl für die verschiedenen Teile des Projekts anstoßen: abstrakter Inhalt in Wikidata, Funktionen und andere Entitäten in Wikifunctions und auch den rechtlichen Status des erzeugten Textes, der in Wikipedia angezeigt wird. Dies muss vor Aufgabe P1.9 geschehen. Für diese Entscheidung wird rechtliche Beratung unerlässlich sein.

Aufgabe P1.2: Entwicklungseinstieg

Der erste Entwicklungsschritt ist die Erzeugung eines Wikifunctions-Wikis mit einem Funktions-Namensraum. Dieser ermöglicht die Speicherung und Bearbeitung von Z-Objekten (stärker eingeschränkte JSON-Objekte - tatsächlich können wir mit den bestehenden JSON-Erweiterungen beginnen und darauf aufbauen). Der erste Meilenstein hat folgende Ziele:

Die initialen Typen: unicode string, positive integer up to N, boolean, list, pair, language, monolingual text, multilingual text, type, function, builtin implementation, und error.
Einen ersten Satz an Konstanten für die Typen.
Einen ersten Satz an Funktionen: if, head, tail, is_zero, successor, predecessor, abstract, reify, equal_string, nand, constructors, sowie wahrscheinlich einige weitere Funktionen mit jeweils eingebauter Implementierung.

Dies ermöglicht es, das Frontend UX für Funktionsaufrufe zu entwickeln und einen ersten Satz Werkzeuge und Schnittstellen zu schaffen, um die verschiedenen Typen von Z-Objekten sowie generische Z-Objekte darzustellen. Dies umfasst auch eine erste Auswertefunktion, die auf Wikimedia-Servern läuft.

Man beachte, dass die ersten Implementierungen von Ansichten, Editierschnittstellen und Validierungstools wahrscheinlich nach P1.12 sukzessive ersetzt werden, sobald sie komplett internalisiert wurden. Einen Code zu internalisieren heißt, ihn aus dem Kern zu entfernen und ihn in die Benutzerumgebung zu verschieben, d.h. ihn in Wikifunctions neu zu implementieren und ihn dort aufzurufen.

Aufgabe P1.3: Testinfrastruktur einrichten

Wikifunctions wird mehrere Testsysteme benötigen. Eines zum Testen des Kerns, eines zum Testen des Web-UI, eines zum Testen von Wikifunctions-Inhalten selbst. Dies ist eine laufende Aufgabe und muss in die Versionskontrolle integriert werden.

Aufgabe P1.4: Öffentliches Testsystem freigeben

Wir werden ein öffentlich sichtbares, editierbares Testsytem einrichten, auf dem der jeweils aktuellste Entwicklungsstand des Codes läuft (täglich mindestens ein Deployment). Wir werden die Community einladen, sich einzubringen und es zu zerlegen. Wir können dieses System auch für die laufenden Integrationstests verwenden.

Aufgabe P1.5: Server-gestützte Auswertefunktion

Während beim Entwicklungseinstieg eine einfache Auswertefunktion geschaffen wurde, die nur auf Basis der Built-Ins funktioniert und somit ein vorhersagbares Verhalten liefert, wird die folgende Funktionskompositionsaufgabe P1.6 ein Neudesign der Auswertefunktion erfordern. Die erste Auswertefunktion wird auf der Wikimediainfrastruktur laufen. Sie benötigt Überwachungs- und Skalierungsfähigkeiten und potentiell auch die Möglichkeit, Nutzern unterschiedliche Rechnerressourcen zuzuordnen, abhängig davon, ob sie eingeloggt oder offline sind.

Aufgabe P1.6: Funktionskomposition

Wir ermöglichen neue Funktionsschnittstellen und eine neuartige Art der Implementierung, nämlich zusammengesetzte Funktionsaufrufe. Das heißt, sie ermöglicht die Implementierung von

add(x, y)

als

if(is_zero(y), x, add(successor(x), predecessor(y))

und das System kann diese ausführen. Sie lässt auch Mehrfachimplementierungen zu.

Aufgabe P1.7: Einfrier- und Auftau-Entitäten

Wir schaffen ein Schutzniveau, mit dem Metadaten einer Entität (Name, Beschreibung etc.) bearbeitet werden können, ohne die aktuellen Werte zu verändern. Diese Funktionalität könnte auch für Wikidata nützlich sein. Hier ein detaillierterer Versionierungsvorschlag.

Aufgabe P1.8: Beta Wikifunctions freigeben

Das Beta-System führt zu Testzwecken die nächste Iteration des Codes aus, der mit dem nächsten Bereitstellungszyklus auf Wikifunctions gehen wird.

Aufgabe P1.9: Wikifunctions freigeben

Wir führen die Sicherheitsüberprüfung durch. Wir richten ein neues Wikimedia-Projekt ein. Wir verschieben einige der Wikiseiten von Meta nach Wikifunctions.

Aufgabe P1.10: Neuer Testtyp

Wir führen einen neuen Typ zum Schreiben von Funktionstests ein. Dies geschieht durch die Spezifizierung von Eingabewerten und einer Funktion, die die Ausgabe prüft. Neben der Einführung des Testtyps müssen Funktionen und Implementierungen die Tests auch verwenden und sie in die Implementierungsentwicklung und die Schnittstellensicht integrieren.

Aufgabe P1.11: Spezialseite zum Schreiben von Funktionsaufrufen

Wir benötigen eine neue Spezialseite, die das Schreiben von Funktionsaufrufen ermöglicht und unterstützt. Die Seite enthält eine grundlegende Syntaxprüfung, Autovervollständigung, Dokumentation usw. Eine Teilmenge dieser Funktionalität wird auch auf den Seiten der einzelnen Funktionen und Implementierungen integriert, um sie mit komplexeren Werten auszuführen. Diese Spezialseite stützt sich auf die einfache Einstiegs-API, um Funktionsaufrufe auszuwerten.

Aufgabe P1.12: JavaScript-basierte Implementierungen

Wir lassen einen neuen Typ von Implementierungen zu, nämlich in JavaScript geschriebene Implementierungen. Dies erfordert die Übersetzung von Werten in JavaScript und zurück in Z-Objekte. Dies erfordert auch, über Sicherheit nachzudenken, durch Code-Analyse und Sandboxing, zunächst ergänzt um manuelle Überprüfungen und P1.7-Einfrieren. Wenn die O1-Lambda-Berechnung noch nicht gelungen ist oder übersprungen wurde, können wir durch diese Aufgabe auch das Self-Hosting für Wikifunctions erreichen, was es erlauben würde, den größten Teil des Codes zu internalisieren.

Aufgabe P1.13: Zugriffsfunktionen

Wir fügen den Wikimedia-Projekten das magische Lambda-Wort F7 hinzu, das Funktionsaufrufe in Wikifunctions kodieren und das Ergebnis in die Ausgabe des jeweiligen Wikimedia-Projekts integrieren kann. Dies wird in der Tat ein zentralisiertes Vorlagen-System schaffen, denn Entwickler werden erkennen, dass sie nun Vorlagen in Wikifunctions reimplementieren und diese dann von ihren lokalen Wikis aus aufrufen können. Dem wird eine Analyse der bestehenden Lösungen wie TemplateData und der Lua-Aufrufe vorausgehen.

Dies könnte zu Anforderungen aus den Communities führen, die MediaWiki-Vorlagen-Sprache und Lua (siehe P1.15) als Programmiersprache innerhalb von Wikifunctions zu ermöglichen. Dies wird wahrscheinlich zu Wünschen nach einer verbesserten Lösung für die Beobachtungsliste führen, ähnlich wie bei Wikidata, ebenso zu Implementierungen basierend auf MediaWiki-Vorlagen und zu anderen Anfragen aus der Community. Um diese Aufgaben zu erfüllen, könnte eine zusätzliche Person hilfreich sein, um die Anfragen aus der Community zu beantworten. Ansonsten könnte P2 erst bis zu einem Vierteljahr später starten. Diese Person ist bereits oben im Entwicklungsteam aufgeführt.

Aufgabe P1.14: Neue Typen schaffen

Wir lassen die Schaffung neuer Typen zu. Das bedeutet, wir sollten neue Typdefinitionen bearbeiten und erzeugen können, und allen Code zur Behandlung der Werte von Typen in Wikifunctions internalisieren, d.h. wir werden Codes zur Validierung von Werten benötigen, sie bauen und in verschiedenen Umgebungen visualisieren etc. Wir sollten sie für alle bestehenden Typen internalisieren.

Aufgabe P1.15: Lua-basierte Implementierungen

Wir fügen Lua als eine Programmiersprache hinzu, die für Implementierungen unterstützt wird. Die Bedeutung von Lua ergibt sich aus der breiten Verwendung in den MediaWiki-Projekten. Außerdem sollte, falls noch nicht geschehen, die Wertetransformation von Wikifunctions in eine Programmiersprache an dieser Stelle internalisiert werden (und auch für die JavaScript-Implementierungen erfolgen, die an dieser Stelle wahrscheinlich Built-Ins verwenden werden).

Aufgabe P1.16: Nicht-funktionelle Schnittstellen

Während Wikifunctions auf rein funktionalen Implementierungen aufbaut, gibt es einige Schnittstellen, die nativ nicht funktional sind, zum Beispiel Zufallszahlen, aktuelle Uhrzeit, Autoincrements oder viele REST-Aufrufe. Wir werden herausfinden, wie wir diese mit Wikifunctions zusammenführen können.

Aufgabe P1.17: REST-Aufrufe

Wir werden Built-Ins bereitstellen, um REST-Schnittstellen im Web aufzurufen und das Ergebnis aufzunehmen. Dies würde vorzugsweise auf P1.16 beruhen. Man beachte, dass der Aufruf beliebiger REST-Schnittstellen Sicherheitsherausforderungen mit sich bringt. Diese müssen bei einem ordentlichen Entwurf berücksichtigt werden.

Aufgabe P1.18: Zugriff auf Wikidata und andere WMF-Projekte

Wir werden Funktionen bereitstellen, um auf Wikidata-Elemente und -Lexeme, aber auch auf andere Inhalte aus Wikimedia-Projekten zuzugreifen. Dies wird vorzugsweise auf P1.17 aufbauen, aber falls das zu diesem Zeitpunkt noch nicht gelungen ist, wird ein Built-In diese Fähigkeit freischalten.

Aufgabe P1.19: Einsprachige Erzeugung

Die Entwicklung dieser Funktionen erfolgt vollständig on-wiki. Dazu gehören Tabellen und Datensätze, um grammatikalische Einheiten wie Substantive, Verben, Nominalphrasen usw. darzustellen, sowie Funktionen, um damit zu arbeiten. Dazu gehört auch die Implementierung von Kontext, so dass wir bei Bedarf Anaphorik erzeugen können. Dies ermöglicht eine konkrete Generierung von natürlicher, d.h. noch nicht abstrakter Sprache.

Projektteil P2: Abstrakte Wikipedia

Die Aufgaben in diesem Projektteil beginnen nach einem Jahr Entwicklung. Wir erwarten nicht, dass alle Aufgaben aus Projektteil P1 vor Beginn von Projektteil 2 fertiggestellt sind, da die Projektteile P1 und P2 in der Tat parallel weiter entwickelt werden. Nur ein paar der Aufgaben aus Projektteil P1 werden für den Start von Projektteil P2 benötigt.

Aufgabe P2.1: Konstruktoren und Renderer

Hier führen wir die abstrakten Schnittstellen zu den in P1.19 entwickelten konkreten Generatoren ein. Dies führt zur ersten Entwicklung von Konstructoren und der Render-Funktion. Nach dieser Aufgabe sollte die Community in der Lage sein, neue Konstructoren zu erstellen und Renderer zu erweitern, um diese zu unterstützen.

Konstruktoren werden für die Notation des abstrakten Inhalts verwendet. Konstruktoren sind sprachenunabhängig und sollten keine bedingte Logik enthalten.
Renderer sollten die eigentliche bedingte Logik enthalten (die auf die Informationen in den Konstruktoren angewendet wird). Renderer können sprachspezifisch sein (können aber auch sprachenübergreifend genutzt werden).
Die Trennung zwischen den beiden ist analog zu der Trennung in anderen NLG-Systemen wie z.B. Grammatical Framework.

Aufgabe P2.2: Bedingtes Rendering

Es wird selten der Fall sein, dass ein Renderer den Inhalt vollständig wiedergeben kann. Wir müssen eine elegante Erniedrigung unterstützen: Wenn ein Teil des Inhalts nicht wiedergegeben werden kann, ein anderer aber noch wiedergegeben wird, sollten wir den wiedergegebenen Teil anzeigen. Aber manchmal ist es aus narrativen Gründen notwendig, bestimmte Inhalte nur dann zu wiederzugeben, wenn andere Inhalte definitiv wiedergegeben werden. In dieser Aufgabe werden wir die Unterstützung für ein solches bedingtes Rendering implementieren, das es kleineren Communities erlaubt, ihre Wikipedien sicher wachsen zu lassen.

Aufgabe P2.3: Abstrakte Wikipedia

Wir werden einen neuen Namensraum in Wikidata erzeugen und es ermöglichen, hier Inhalte zu erzeugen und zu pflegen. Wir werden UI-Elemente wiederverwenden und zur Inhaltserzeugung anpassen. Der UI-Arbeit geht Design-Research-Arbeit voraus, die vor dem Start von Projektteil P2 beginnen kann. Hier einige wichtige Ideen zu diesem Design. Diese Aufgabe wird entscheiden, ob wir neue magische Wörter (F5, F6 und F7) benötigen oder deren Einführung vermeiden können.

Aufgabe P2.4: Mobiles UI

Das Erstellen und Bearbeiten von Inhalten wird die häufigste Aufgabe bei der Schaffung einer mehrsprachigen Wikipedia sein. Daher wollen wir sicherstellen, dass diese Aufgabe eine angenehme und zugängliche Benutzererfahrung hat. Wir wollen eine explizite Aufgabe der Unterstützung von Erstellung und Pflege von Inhalten an einer mobilen Schnittstelle widmen. Wir erwarten, dass wir eine Schnittstelle schaffen können, die eine bessere Erfahrung als das Editieren von Wikitext ermöglicht.

Aufgabe P2.5: Inhalte in Wikipedien integrieren

Wir werden das magische Wort für die Abstrakte Wikipedia aktivieren. Wir werden dann die explizite und schließlich die implizite Artikelerstellung ermöglichen (F1, F2, F3, F4, F5, F6).

Aufgabe P2.6: Regelmäßige Beugung

Wikidata-Lexeme enthalten die gebeugten Formen eines Lexems. Diese Formen werden oft regelmäßig gebeugt. Wir werden eine Lösung schaffen, die regelmäßige Beugungen mittels Wikifunctions erzeugen, und werden mit der Community erörtern, wie dies mit den bestehenden Lexemen zusammengeführt werden kann.

Aufgabe P2.7: Basis-Renderer für Englisch

Wir gehen davon aus, dass die erstmalige Entwicklung von Renderern schwierig wird. Da Englisch in der Community weitverbreitet ist, werden wir es als erste Sprache verwenden, um die Schaffung eines Renderers zu demonstrieren, und dies gut dokumentieren. Wir werden die Unterstützung aus der Community integrieren. Dies enthält auch Funktionalität zum Aufzeigen von Referenzen.

Aufgabe P2.8: Basis-Renderer für eine zweite Sprache

Auf der Grundlage des Feedbacks aus der Community und der Interessen und Fachkenntnisse der Linguisten, die im Team mitarbeiten, werden wir eine zweite große Sprache auswählen, für die wir zusammen mit der Community einen Basis-Renderer schaffen wollen. Es wäre interessant, eine Sprache auszuwählen, bei der die Community der lokalen Wikipedia bereits ihr Interesse an der Integration von Abstrakte Wikipedia bekundet hat.

Aufgabe P2.9: Renderer für eine Sprache einer anderen Sprachfamilie

Da die Sprache in P8 wahrscheinlich nicht zur indo-europäischen Sprachfamilie gehört, werden wir zusammen mit der Community auch einen Basisrenderer für eine Sprache einer anderen Sprachfamilie schaffen. Die Wahl dieser Sprache erfolgt auf der Grundlage der Fachkompetenzen innerhalb des Teams und der Interessen der Community. Es wäre interessant, eine Sprache zu wählen, für die die Community der lokalen Wikipedia bereits ihr Interesse an der Integration der Abstrakten Wikipedia bekundet hat.

Aufgabe P2.10: Renderer für eine unterrepräsentierte Sprache

Da die Sprachen in P8 und P9 wahrscheinlich schon von aktiven und großen Wikipedia-Communities gut betreut werden, werden wir eine unterrepräsentierte Sprache auswählen, eine Sprache mit gegenwärtig einer großen Zahl potentieller Leser, aber nur eine kleinen Community und wenig Inhalt. Die Wahl dieser Sprache erfolgt auf der Grundlage der Fachkompetenzen innerhalb des Teams und der Interessen der Community. Hierbei ist es wesentlich, eine Sprache zu wählen, für die die Community der lokalen Wikipedia bereits ihr Interesse an der Integration der Abstrakten Wikipedia bekundet hat.

Aufgabe P2.11: Abstrakte Wikidata-Beschreibungen

Wikidata-Beschreibungen scheinen besonders geeignet für die Erzeugung mittels Wikifunctions zu sein. Es sind oft kurze Nominalphrasen. In dieser Aufgabe unterstützen wir die Speicherung und Pflege abstrakter Beschreibungen in Wikidata sowie ihre Erzeugung für Wikidata. Wir sollten auch sicherstellen, dass das Ergebnis zu eindeutigen Kombinationen von Bezeichnungen und Beschreibungen führt.

Siehe Abstrakte Wikipedia/Neuigkeiten/2021-07-29 für weitere Details und Diskussionen.

Aufgabe P2.12: Abstrakte Glossen

Wikidata-Lexeme haben Bedeutungen. Bedeutungen werden durch Glossen erfasst. Glossen sind erhältlich pro Sprache, was zur Folge hat, dass sie oft nur für wenige Sprachen verfügbar sind. Um ein wirklich vielsprachiges Verzeichnis zu bekommen, schlagen wir die Schaffung von abstakten Glossen vor. Obwohl dies so klingt, als ob es viel leichter wäre als voll ausgereifte Wikipedia-Artikel zu erzeugen, glauben wir aufgrund der Natur von Glossen, dass dies eine viel schwierigere Aufgabe ist.

Aufgabe P2.13: Zusätzliche natürliche Sprachen unterstützen

Wir unterstützen andere Sprach-Communities bei der Schaffung von Renderern, mit einem Schwerpunkt auf unterrepräsentierten Sprachen.

Aufgabe P2.14: Vorlagengenerierter Inhalt

Einige Wikipedien enthalten gegenwärtig eine Menge vorlagengenerierter Inhalte. Wir werden diese Inhalte identifizieren und mit den lokalen Wikipedien erörtern, ob sie diese durch eine Lösung auf Basis von Wikifunctions ersetzen wollen. Dabei befindet sich das Template in Wikifunctions und der Inhalt in der lokalen Wikipedia oder der Abstrakten Wikipedia. Dies wird zu nachhaltigeren und besser wartbaren Lösungen führen, die es nicht erfordern, sich auf einen einzelnen Beitragsleister zu verlassen. Man beachte, dass dies nicht mehrsprachig sein muss, und es könnte viel leichter sein, als wenn es eine vollständige Abstraktion durchlaufen müsste.

Aufgabe P2.15: Gelegentliche Kommentare

Wir wollen gelegentlichen Beitragsleistern Kommentierungen zu wiedergegebenem Text ermöglichen. Wir werden Verfahren schaffen zur Erfassung solcher Kommentare und zu einem Auswahlmechanismus, der die Kommentare entweder dem Inhalt oder dem Renderer zuordnet. Es ist wichtig, dass keine Kommentare gelegentlicher Beitragsleister verloren gehen. Ideal wäre es, wenn wir den Beitragsleistern ermöglichen würden, Teile des wiedergegebenen Ergebnisses explizit zu überschreiben und dies als Change Request zu betrachten. Dann werden wir mehr Mitwirkende beteiligen, die die Absichten der gelegentlichen Beitragsleister im System in die entsprechenden Änderungen umsetzen.

Aufgabe P2.16: Schnellerzeugung von Artikelnamen

Die allgemeine Benutzerschaft nutzt Wikipedia meistens, indem sie die Namen der gesuchten Dinge in ihrer Sprache in übliche Suchmaschinen eingeben. Das bedeutet, das Wikipedia-Artikel in die jeweilige Sprache übersetzte Bezeichnungen brauchen, um Artikel implizit schreiben zu können. Dies kann wahrscheinlich erreicht werden, indem Millionen Wikidata-Bezeichnungen übersetzt werden. Das kann manchmal durch Bots oder KI erledigt werden, es ist aber weder zuverlässig noch skalierbar, so dass Menschen beteiligt werden müssen.

Die aktuellen Werkzeuge für massive Crowd-Source-Übersetzung von Wikidata-Bezeichnungen gehören nicht zu dieser Aufgabe. Dafür gibt es zwei Hauptwege: die Bearbeitung der Bezeichnung in Wikidata selbst, was vielleicht für ein paar Dutzend Bezeichnungen gut sein mag, aber schnell langweilig wird, und die Nutzung von Tabernacle, was stärker an der massiven Stapelübersetzung orientiert zu sein scheint, aber den meisten Leuten für eine konkrete Verwendung zu kompliziert ist.

Die Aufgabe ist es, ein Werkzeug zur massiven und integrierten Übersetzung von Bezeichnungen mit einer einfachen, modernen Oberfläche zu entwickeln, das von vielen Menschen genutzt werden kann.

Nicht-Kern-Aufgaben

Es gibt eine ganzen Satz an weiteren, optionalen Aufgaben. Idealerweise würden diese von externen Communities aufgegriffen und als Open Source außerhalb des ursprünglichen Entwicklungsteams entwickelt. Möglicherweise müsste das Kernteam einige davon initiieren oder sogar vollständig entwickeln.

Aufgabe O1: Lambda-Berechnung

Man kann Wikifunctions gänzlich selbst hosten, ohne sich auf Built-Ins oder Implementierungen in anderen Programmiersprachen zu verlassen, indem man eine Lambda-Berechnung in Wikifunctions implementiert (von hier kommt der Namensvorschlag). Dies kann hilfreich sein, um eine Auswertung ohne jeglichen Sprachsupport zu ermöglichen, und somit die Entwicklung von Auswertefunktionen leichter in Angriff zu nehmen.

Aufgabe O2: CLI für Entwickler-Terminal

Viele Entwickler genießen die Nutzung eines Kommandozeilen-Oberfläche für den Zugang zu Systemen wie Wikifunctions. Wir sollten ein CLI mit den üblichen Funktionen wie Autocomplete, Historie, Shell-Integration etc. bereitstellen.

Aufgabe O3: UIs für Creating-, Debugging- und Tracing-Funktionen

Das Ziel von Wikifunctions ist es, schnelles Verstehen und schnelle Entwicklung von Funktionen in Wikifunctions zu ermöglichen. Mit dem funktionalen Ansatz sollte es gelingen, eine Benutzererfahrung zu schaffen, die eine teilweise Auswertung, Entfaltung, Fehlersuche und Tracing eines Funktionsaufrufs ermöglicht.

Aufgabe O4: Effizienz der Auswertefunktionen verbessern

Es gibt viele Wege, die Leistungsfähigkeit von Auswertefunktion zu verbessern, um so den Ressourcenverbrauch zu senken, insbesondere durch Caching oder eine ordentliche Wahl einer Auswertestrategie. Wir sollten einige Zeit für Auswertefunktionen im allgemeinen verwenden und die Ergebnisse dokumentieren, sodass verschiedene Auswertefunktionen dieses Wissen verwenden können. Wir sollten aber auch sicherstellen, dass die vom Kernteam gepflegten Auswertefunktionen die meisten der besten Vorgehensweisen anwenden.

Aufgabe O5: Web of Trust für Implementierungen

Um die Bedingungen für Implementierungen in Programmiersprachen zu entspannen, könnten wir eine Web-of-Trust-basierte Lösung einführen, die es Mitwirkenden ermöglicht, bestehende Implementierungen zu überprüfen und ihre Freigabe explizit zu vermerken, und auch andere Mitwirkende als vertrauenswürdig zu kennzeichnen. Dann könnten diese Freigaben bei der Wahl oder Vorbereitung einer Auswertestrategie berücksichtigt werden.

Aufgabe O6: Python-basierte Implementierungen

Python ist eine weit verbreitete Programmiersprache, besonders für Anfänger und in manchen Bereichen wie zum Beispiel Machine Learning. Die Unterstützung von Python kann ein reichhaltiges Ökosystem für Wikifunctions eröffnen.

Aufgabe O7: Implementierungen in anderen Sprachen

Wir werden uns bemühen, Communities anderer Programmiersprachen aufzurufen, sie in Wikifunctions zu integrieren und zu unterstützen. Kandidaten für Implementierungen sind Web Assembler, PHP, Rust, C/C++, R, Swift, Go und andere. Es ist aber abhängig vom Interesse des Kernteams und der externen Communities, diese Schnittstellen zu entwickeln und bereitzustellen.

Aufgabe O8: Web-basierte REPL

Ein Web-basiertes REPL kann die Vorteile des O2-CLI ins Netz bringen, ohne ein CLI in einer lokalen Umgebung einrichten zu müssen, was manchmal gar nicht möglich ist.

Aufgabe O9: API um Parser und Linearisierer erweitern

Es könnte verschiedene Parser und Linearisierer geben, die Wikifunctions benutzen. Die Wikifunctions-API kann einfacher zu nutzen sein, wenn der Aufrufer explizit auswählen kann, anstatt sie manuell einzubinden. Dies würde die Nutzung von Wikifunctions mit verschiedenen Oberflächendialekten zulassen.

Aufgabe O10: Diskussionsseiten unterstützen

Um Diskussionen auf Wikifunctions-Diskussionsseiten zu unterstützen, werden wir ein Verfahren entwickeln und integrieren, das (anfangs) einfache Diskussionen erlaubt. Abhängig von den Bedürfnissen der Communities werden wir die Kompexität des Verfahrens langsam erhöhen.

Aufgabe O11: Rechtliche Informationen erzeugen

Eine Interessante Anwendung von Wikifunctions ist die modulare Erzeugung von Rechtstexten unterschiedlicher Niveaus (Juristen- oder normalverständliche Sprache) ähnlich den verschiedenen Beschreibungsniveaus für die verschiedenen Creative-Commons-Lizenzen.

Aufgabe O12: Gesundheitsbezogene Texte erzeugen

Eine interessante Anwendung von Wikifunctions ist die Texterzeugung für verschiedene Leseverständnisniveaus. Dies sollte vom WikiProjekt Medizin und dessen erfolgreicher Arbeit vorangetrieben werden, das viele Leute über die Zusammenarbeit mit Wikifunctions erreichen könnte.

Aufgabe O13: NPM-Bibliothek

Wir erzeugen eine Wikidata-Bibliothek für NPM, die eine einfache Verwendung von Wikifunctions-Funktionen in einem JavaScript-Programm ermöglicht. Dieselbe Syntax sollte verwendet werden, um es JavaScript-Implementierungen in Wikifunctions zu ermöglichen, auf andere Wikifunctions-Funktionen zuzugreifen. Man beachte, dass dies durch den Aufruf einer Wikifunctions-Auswertefunktion oder durch Kompilierung der geforderten Funktionen in eine gegebene Code-Basis gemacht werden kann.

Aufgabe O14: Python-Bibliothek

Wir erzeugen eine Python-Bibliothek, die eine einfache Verwendung von Wikifunctions-Funktionen in einem Python-Skript ermöglicht. Dieselbe Syntax sollte verwendet werden, um es Python-Implementierungen in Wikifunctions zu ermöglichen, auf andere Wikifunctions-Funktionen zuzugreifen. Man beachte, dass dies durch den Aufruf einer Wikifunctions-Auswertefunktion oder durch Kompilierung der geforderten Funktionen in eine gegebene Code-Basis gemacht werden kann.

Aufgabe O15: Bibliotheken für andere Programmiersprachen

Wir werden die Communities verschiedener Programmiersprachen aufrufen, uns bei der Schaffung von Bibliotheken zu helfen, die den einfachen Aufruf von Wikifunctions-Funktionen aus Programmen in ihrer Sprache ermöglichen. Man beachte, dass dies durch den Aufruf einer Wikifunctions-Auswertefunktion oder durch Kompilierung der geforderten Funktionen in eine gegebene Code-Basis gemacht werden kann.

Aufgabe O16: Browser-gestützte Auswertefunktion

Einer der Vorteile von Wikidata ist es, dass die tatsächliche Auswertung eines Funktionsaufrufs in verschiedenen Auswertefunktionen erfolgen kann. Die Hauptauswertefunktion für die Abstrakte Wikipedia wird Server-basiert sein und von der Wikimedia Foundation betrieben werden. Um aber die Rechenlast zu senken, sollten wir auch Auswertefunktionen bereitstellen, die auf dem Benutzer-Client laufen (wahrscheinlich in einem Worker-Thread).

Aufgabe O17: Jupyter- und/oder PAWS-basierte Auswertefunktion

Eine interssante Auswertefunktion kommt von einem Jupyter- oder PAWS-Notebook. So wird die Nutzung der Vorteile solcher Notebooks ermöglicht, wobei die Leistungen von Wikifunctions integriert werden.

Aufgabe O18: App-gestützte Auswertefunktion

Eine Auswertefunktion sollte nativ auf Android- oder iOS-Geräten laufen. Das ermöglicht es Nutzern, die erhebliche Rechenleistung in ihrer Hand zu verwenden.

Aufgabe O19: P2P-gestützte Auswertefunktion

Viele der Auswertefunktionen könnten verknüpft werden und sie könnten einander erlauben, ungenutzte Rechenkapazitäten in ihrem Netzwerk zu verwenden. Dies kann oder kann nicht Abschirmungen zwischen den teilnehmenden Knoten erfordern, die den Datenschutz der individuellen Rechner sicherstellen.

Aufgabe O20: Cloud-gestützte Auswertefunktion

Ein offensichtlicher Ort, an dem Rechenleistungen erhältlich sind, ist die Ermöglichung der Nutzung von Cloud-Dienstleistern. Während es möglich wäre, die Server-basierte Auswertefunktion einfach in einer Cloud-Infrastruktur laufen zu lassen, wird es wahrscheinlich für die Cloud-Dienstleister vorteilhaft sein, eine schmalere Schnittstelle für eine stärker maßgeschneiderte Auswertefunktion bereitzustellen.

Aufgabe O21: Streaming-Typ

Wir unterstützen einen Typ Streaming Data, sowohl als Eingabe als auch als Ausgabe. Mit Streaming-Typen ist zum Beispiel der Stream der neuesten Änderungen auf einem Wikimedia-Wiki gemeint.

Aufgabe O22: Binär-Typ

Wir fügen Unterstützung von Binärdateien für Eingabe wie für Ausgabe hinzu.

Aufgabe O23: Integration mit Commons-Mediadateien

Wir ermöglichen den direkten Zugriff auf Dateien in Commons. Wir aktivieren Arbeitsabläufe mit Commons, die weniger Entwicklungsarbeit benötigen als bislang.

Aufgabe O24: Maschinelles Lernen integrieren

Wir entwickeln einige Musterintegrationen mit Lösungen für maschinelles Lernen, beispielsweise für NLP-Tasks oder für die Bearbeitung von Bild oder Bewegtbild, zum Beispiel indem wir Klassifizierer verwenden.

Aufgabe O25: In IDEs integrieren

Wir stellen den Communities integrierte Entwicklungsumgebungen (IDE) bereit und unterstützen sie bei der Integration mit Wikifunctions, indem wir Typhinweise (Python), Dokumentation, Vervollständigung und viele andere passende und wesentliche Bestandteile moderner Entwicklungsumgebungen benutzen.

Aufgabe O26: Einfache Apps oder Websites erzeugen

Wir entwickeln ein System, das eine leichte Erzeugung und Bereitstellung von Apps und Websites auf der Basis von Wikifunctions ermöglicht.

Aufgabe O27: Offene Aufgaben für Mitwirkende anzeigen

Die Abstrakte Wikipedia wird für jeden Konstruktor einer jeden Sprache einen Renderer erfordern. Es wird hilfreich sein, wenn Mitwirkende Leitplanken für die Reihenfolge der zu entwickelnden Renderer bekommen, da diese oft nicht offensichtlich erkennbar ist. Einfach die Häufigkeit der Konstruktoren zu zählen kann ein erster Ansatz sein. Wenn aber Konstruktoren öfter in Einleitungen benutzt werden oder in Textteilen, die andere Texte von der Oberfläche verdrängen, oder in Artikeln, die häufiger als andere gelesen werden, könnte dieser Ansatz wegfallen. In dieser Aufgabe schaffen wir eine Art Dashboard, das dem Nutzer die Wahl einer Sprache (und vielleicht eines Bereichs wie zum Beispiel Sport, Geographie, Geschichte usw. oder auch einen Filter für die Komplexität des erwarteten Renderers) ermöglicht und dann eine Liste nicht-wiedergegebener Konstruktoren bereitstellt, die nach nach der Wirkung ihrer Implementierungen sortiert sind.

Wir könnten es Mitwirkenden ermöglichen, sich für regelmäßige Benachrichtigungen einzutragen, die ihnen berichten, wieviel Wirkung (in Form von Aufrufen und erzeugtem Inhalt) sie erzielt haben. Dies könnte auf der Grundlage des gleichen Rahmens erfolgen, der für das Dashboard benötigt wird.

Dies ist vergleichbar zur Anzeige von Übersetzungen unterschiedlicher Projekte auf TranslateWiki.Net (für eine auswählbare Sprache) oder zu den Aufrufen von Themen, Organisationen oder Autoren in Scholia. Für jedes Projekt wird angezeigt, wieviel Prozent der Strings übersetzt wurden und wieviel Prozent aktualisiert werden müssen, und ein ehrenamtlicher Übersetzer kann wählen: bekomme etwas zwischen 98% und 100%, bekomme etwas zwischen 40% und 60%, bekomme etwas zwischen 0% und 10%, etc.

Aufgabe O28: Aktive Ansicht

Während die voreingestellte Anzeige wiedergegebenen Inhalts wie statischer Text aussähe, sollte es auch aktivere Ansichten geben, die zu Beiträgen auf der Grundlage bestehenden Inhalts einlädt, der wegen fehlendem Renderer nicht wiedergegeben werden konnte. Im einfachsten Fall kann dies die Erzeugung eines Lexems in Wikidata und die Verknüpfung zum richtigen Lexem sein. Für komplexere Fälle könnte ein Renderer geschrieben werden, oder es könnten Mustersätze als Text angeboten werden, möglicherweise indem der in P2.15 beschriebene Weg für gelegentliche Beitragsleister benutzt wird. Dies würde einen interessanten Kanal bereitstellen, um mehr Leser zu Beitragsleistern zu machen.

Es gibt Produkt- und Design-Entscheidungen darüber, wie und wo die aktive Ansicht verwendet werden soll und ob sie die voreingestellte Ansicht sein soll, oder ob sie nur nach einer Einladung eingeschaltet werden soll, usw. Es könnte auch einen Modus geben, in dem Beitragsleister von Artikel zu Artikel gehen und fehlende Teile ausfüllen können, ähnlich wie bei der abstrakteren Vorgehensweise von O27.

Es wäre wahrscheinlich sehr nützlich, wenn sichergestellt würde, dass der aktive Weg und der Beitragspfad, zu dem er führt, auch auf mobilen Endgeräten funktioniert.

Aufgabe O29: Kompilierung implementieren

Die Funktionskomposition, die zur Implementierung benutzt wird, sollte es ermöglichen, sehr leistungsfähige Kompilierungen von High-Level-Funktionen in vielen verschiedenen Zielprogrammiersprachen zu erzeugen, insbesondere Web Assembler und JavaScrypt. Das sollte die Auswertung um mehrere Größenordnungen beschleunigen.

Aufgabe O30: Codebeispiele aus Wikipedia, Wikibooks, etc. integrieren

Wikipedia, Wikibooks und den anderen Projekten ermöglichen, ihre Code-Beispiele direkt in das Funktionenwiki zu integrieren, sodass sie im Echtbetrieb laufen können.

Bestandteil von Abstrakte Wikipedia: Projektplan.