Wikimedia Meta-Wiki

Abstrakte Wikipedia/Projektplan

< Abstract Wikipedia
This page is a translated version of the page Abstract Wikipedia/Plan and the translation is 100% complete.
Other languages:

Dies ist eine Zusammenfassung der Einzeldokumente auf einer Seite. Klicke auf die Überschriften, um zu den einzelnen Seiten zu gelangen.

Zusammenfassung

In der Abstrakten Wikipedia wird der "Abstrakte Inhalt" in einem sprachunabhängigen Format dargestellt, das von der Community direkt editierbar ist. Die lokalen Wikipedien können auf ihre eigenen lokal kontrollierten Inhalte zugreifen und diese mit "Abstrakten Inhalten" (aus der Abstrakten Wikipedia) anreichern. Auf diese Weise können die lokalisierten Ausgaben der Wikipedia mit viel weniger Aufwand ihren Lesern viel mehr Inhalte bereitstellen, Inhalte, die umfassender, aktueller und besser geprüft sind als das, was die meisten lokalen Wikipedien bieten können.

Angesichts der Forschungsergebnisse und Prototypen im Bereich der Erzeugung natürlicher Sprache ist es leider richtig, dass die Generierung natürlicher Sprache aus dem sprachunabhängigen "Abstrakten Inhalt" ein "Turing-vollständiges" System erfordert. Um aber die Anzahl der Sprachen anzubieten, die Wikipedia abdecken muss, muss dieses System crowdgesourced werden. Deshalb stellen wir Wikifunctions vor, ein Projekt zur Erstellung, Katalogisierung und Pflege einer offenen Bibliothek (oder eines Repositoriums) von "Funktionen", die viele mögliche Anwendungsfälle hat.

Der Hauptmotivation für Wikifunctions ist die Entwicklung von "Renderern" (das sind einige der Funktionen, die in Wikifunctions gehostet oder referenziert werden), die den sprachunabhängigen "Abstrakten Inhalt" in natürliche Sprache umwandeln, unter Verwendung des linguistischen und ontologischen Wissens, das in Wikidata verfügbar ist (oder Wissen aus anderen geeigneten offenen Datenquellen, einschließlich möglicherweise Daten aus anderen Wikimedia-Projekten wie Wiktionary oder Wikispecies).

Das Projekt wird mit der Erstellung des Projektes Wikifunctions beginnen und dieses dann nutzen, um die Erstellung der Abstrakten Wikipedia zu ermöglichen. Wikifunctions wird innerhalb des ersten Jahres starten, und wir werden die Entwicklung der Abstrakten Wikipedia im zweiten Jahr hinzufügen. Nach zwei Jahren werden wir ein Ökosystem geschaffen haben, das die Erstellung und Pflege von sprachunabhängigen "abstrakten Inhalten" und die Integration dieser Inhalte in die Wikipedien ermöglicht, was die Abdeckung, Aktualität und Genauigkeit vieler einzelner Wikipedien deutlich erhöht. Dies wird uns einer Welt, in der jeder an der Summe des gesamten Wissens teilhaben kann, dramatisch näher bringen.


Name

Alle Namen – Abstrakte Wikipedia und Wikilambda – sind vorläufig und hauptsächlich dafür gedacht, diesen Vorschlag zu schreiben und zu diskutieren.

Die aktuellen Namen fußen auf folgender Idee:

  • Abstrakte Wikipedia: der Inhalt der Abstrakten Wikipedia abstrahiert weg von einer konkreten Sprache.
  • Wikilambda: dies basiert auf der Vorstellung, dass alle Funktionen im Lambda-Kalkül begründet werden können. Außerdem sieht Wλ irgendwie technophil ("geeky") aus, mit dem Risiko, dass es nicht als seinem Zielpublikum entsprechend wahrgenommen und von Spezialisten nur voreingenommen benutzt wird, die bereits durch einen Zugang zum größten verfügbaren Wissen in ihrer eigenen Kultur im Vorteil sind.

Beachte, dass der Name "Abstrakte Wikipedia" in der Tat nicht bestehen bleiben wird. Wenn das Projekt fertig ist, wird "Abstrakte Wikipedia" nur ein Teil von Wikidata sein. Es ist nur ein Name für die Entwicklungsarbeit, und daher ist die Namensgebung nicht so entscheidend. Wikilambda hingegen wäre ein neues Wikimedia-Projekt, und daher wird der Name eine ziemlich hohe Sichtbarkeit haben. Es wäre gut, sich dafür einen guten Namen einfallen zu lassen.

Einwände

Bislang sind drei gute Gründe gegen den Namen Wikilambda vorgebracht worden:

  • Es ist für manche Leute wirklich schwer zu schreiben (sagt Effeietsanders).
  • Manche Leute lesen es hartnäckig als "Wikilambada" (sagt Jean-Frédéric).
  • Es wird auch leicht als WikiIambda / Wikiiambda falsch gelesen (also mit einem zweiten "i / I" anstelle des "l / L"), sodass man zumindest die Schreibweise "WikiLambda" mit einem großen "L" (vorgeschlagen von Fuzheado) wählen sollte.

Vorgeschlagene Alternativen

Alternative Namen, die betrachtet oder vorgeschlagen wurden:

Dies ist ein Archiv. Neue Vorschläge sollten im Namenswettbewerb für das Wiki der Funktionen gemacht werden.

Weitere Anregungen sind willkommen.

Tatsächlich wird die erste Aufgabe P1.1 des Projekts sein, sich mit der Community gemeinsam auf einen Namen und ein Logo zu einigen. Dies hatte bei früheren Projekten Vorrang (Logo von Wikidata, Name von Wikivoyage).


Ziele

Das Projekt hat anspruchsvolle primäre und eine ganze Reihe sekundärer Ziele.

Primäre Ziele

  • Es mehr Menschen ermöglichen, mehr Inhalte in der von ihnen gewünschten Sprache zu lesen.
  • Es mehr Menschen ermöglichen, Inhalte für mehr Leser beizutragen und so die Reichweite unterrepräsentierter Autoren zu vergrößern.

Sekundäre Ziele

Sekundärziele umfassen, sind aber nicht beschränkt auf:

  • Wiederverwendbare und gut getestete Generierung natürlicher Sprache.
  • Es anderen Wikimedia-Communities und externen Dritten ermöglichen, Inhalte in mehr Sprachen zu erstellen.
  • Kommunikation und Zugänglichkeit von Wissen weit über die Wikipedia-Projekte hinaus verbessern.
  • Einen neuartigen, viel umfassenderen Ansatz zur Wissensrepräsentation entwickeln.
  • Einen neuartigen Ansatz zur Darstellung des Ergebnisses des Verstehens natürlicher Sprache entwickeln.
  • Eine Bibliothek mit Funktionen.
  • Entwicklung und Freigabe von Funktionen in den Muttersprachen der Benutzer ermöglichen, anstatt von ihnen zu verlangen, zuerst Englisch zu lernen.
  • Es jedem ermöglichen, sich an Funktionen zu beteiligen und diese auszuführen.
  • Eine neue Form von Wissensbeständen einführen, die ein Wikimedia-Projekt verwalten kann.
  • Neuartige Komponenten in Wikipedia und anderen Wikimedia-Projekten einführen, die interaktive Funktionen ermöglichen.
  • Funktionen erstellen, die oberhalb der Wissensbasis von Wikidata wirken und so den Abdeckungsgrad der Wikidata-Daten mittels Schlussfolgerungen erheblich erhöhen.
  • Katalysator für Forschung und Entwicklung bei der Demokratisierung von Kodierschnittstellen.
  • Wissenschaftler und Analysten in die Lage versetzen, Modelle gemeinsam zu nutzen und daran zu arbeiten.
  • Spezifikationen und Tests für Funktionen gemeinsam nutzen.
  • Die Möglichkeit, durch wohldefinierte Bezeichner auf die Semantik von Funktionen zu verweisen.
  • Neue Programmiersprachen durch Zugriff auf eine breitere Standardbibliothek (oder ein Repositorium) von Funktionen in einem neuen, diesem Thema gewidmeten Wiki schneller entwickeln.
  • Algorithmen und Ansätze für Standards und Verfahrensbeschreibungen definieren.
  • Zugang zu leistungsstarken Funktionen eröffnen, die in neuartige Machine-Learning-Systeme integriert werden können.

Die Liste ist nicht abschließend.


Organisation

Wir gehen von einem Kernteam aus, das bei einer einzigen Hosting-Organisation angestellt ist und ausschließlich an Wikifunctions und an der Abstrakten Wikipedia arbeiten wird. Es wird von anderen Abteilungen der Hosting-Organisation unterstützt werden, wie z. B. Personalwesen, Recht, etc.

Das Team wird ausdrücklich so eingerichtet, dass es offen und einladend für externe Beiträge zur Codebasis ist. Teammitglieder können ehrenamtliche oder bezahlte Kräfte sein (z.B. durch Zuschüsse an Movement Bodies, oder Anstellung bei anderen Organisationen oder Firmen). Wir sind bestrebt, Freiwillige bevorzugt zu behandeln, um die Chancen zu erhöhen, gesunde Freiwilligengemeinschaften zu schaffen, die wir für ein Projekt mit solchen Ambitionen brauchen.

Das Projekt wird in der Öffentlichkeit entwickelt werden. Die Kommunikationskanäle des Teams werden so weit wie möglich öffentlich sein. Die Kommunikationsrichtlinien werden öffentlich sein. Dies wird dabei helfen, ein Entwicklungsteam zu schaffen, das öffentlich kommuniziert und die Integration externer Beiträge in die Codebasis ermöglicht.


Anforderungen

Die folgenden starken Anforderungen fußen auf den Grundsätzen und Praktiken der Wikimedia-Bewegung:

  1. Abstrakte Wikipedia und Wikifunctions werden Wikimedia-Projekte sein, die von der Wikimedia Foundation gepflegt und betrieben werden. Dies setzt voraus, dass Abstrakte Wikipedia und Wikifunctions den Gründungsprinzipien und Richtlinien der Wikimedia-Bewegung folgen.
  2. Die Software zum Betrieb der abstrakten Wikipedia und von Wikifunctions wird unter einer Open-Source-Lizenz entwickelt und hängt nur von Software ab, die Open Source ist.
  3. Der Aufbau der abstrakten Wikipedia und von Wikifunctions sollte sich so einfach wie möglich in die aktuelle Wikimedia-Infrastruktur einfügen. Das bedeutet, dass wir so weit wie möglich in dieselbe Infrastruktur für Bereitstellung, Wartung und Betrieb passen sollten.
  4. Alle Inhalte der abstrakten Wikipedia und von Wikifunctions werden unter freien Lizenzen zur Verfügung gestellt.
  5. Der Erfolg der abstrakten Wikipedia und von Wikifunctions wird an der Schaffung gesunder Gemeinschaften gemessen und daran, wie viel Wissen in Sprachen verfügbar gemacht wird, die zuvor keinen Zugang zu diesem Wissen hatten.
  6. Die abstrakte Wikipedia wird den Prinzipien folgen, die von vielen der einzelnen Wikipedien definiert wurden: insbesondere neutraler Standpunkt, Verifizierbarkeit und Zitierbarkeit sowie Verzicht auf originäre Forschung (weiterentwickelt von Community Capacity Development und von den Communities für jedes lokale Wiki).
  7. Abstrakte Wikipedia und Wikifunctions werden vollständig internationalisiert und in allen Sprachen der Wikimedia-Projekte verfügbar und editierbar sein. Ob sie vollständig lokalisiert sind, hängt von den Communities ab.
  8. Das primäre Ziel ist die Unterstützung lokaler Wikipedien, Wikidata und anderer Wikimedia-Projekte, in dieser Reihenfolge. Das sekundäre Ziel ist es, unsere eigenen Communities zu vergrößern. Das tertiäre Ziel ist die Unterstützung des Rests der Welt.
  9. Die lokalen Communities der Wikipedia müssen die Kontrolle darüber haben, wie sehr die abstrakte Wikipedia sie tangiert. Wenn sie nicht davon betroffen sein wollen, können sie sie komplett ignorieren und es ändert sich nichts für sie.

Die Entwickler der Abstrakten Wikipedia entscheiden nicht über den Inhalt der Abstrakten Wikipedia, so wie die Entwickler von MediaWiki nicht über den Inhalt der Wikipedia entscheiden. Anders als bei den anderen Wikimedia-Projekten werden sich die Entwickler aktiv an der Einrichtung und dem Start des anfänglichen Satzes von Typen und Funktionen beteiligen, die notwendigen Funktionen in Wikifunctions für die Abstrakte Wikipedia erstellen, und beim Start der Sprach-Renderer-Communities helfen. Anders als bei anderen Projekten wird das Entwicklungsteam der Abstrakten Wikipedia und des Wikis der Funktionen anfangs mehr in das Projekt involviert sein, will aber all das eher früher als später an die Communities übergeben.

Die folgenden Anforderungen dienen als starke Leitplanken, die wir bei der Gestaltung und Entwicklung der Abstrakten Wikipedia anwenden:

  1. Abstrakte Wikipedia und Wikifunctions sind ein sozio-technisches System. Anstatt zu versuchen, übermäßig intelligent zu sein, verlassen wir uns auf die Wikimedia-Communities.
  2. Das erste Ziel der abstrakten Wikipedia und von Wikifunctions ist es, tatsächliche Anwendungsfälle in der Wikipedia zu bedienen, und nicht irgendeine Form von hypothetischer Perfektion in der Wissensdarstellung zu ermöglichen oder die gesamte menschliche Sprache zu vertreten.
  3. Abstrakte Wikipedia und Wikifunctions müssen eine Ausgewogenheit zwischen Benutzerfreundlichkeit und Aussagekraft herstellen. Die Benutzeroberfläche sollte nicht kompliziert werden, nur um ein paar seltene Randfälle abzudecken.
  4. Was ein Ausnahmefall ist und was nicht, wird dadurch definiert, wie oft er in Wikipedia auftaucht. Anstelle von Einzelbeispielen oder hypothetischen Fällen werden wir Wikipedia analysieren und sehen, wie häufig bestimmte Fälle sind.
  5. Lass uns pragmatisch sein. Implementiert ist besser als perfekt.
  6. Abstrakte Wikipedia und Wikifunctions werden eine Menge neuer Daten liefern, die externe Forschung, Entwicklung und Anwendungsfälle unterstützen können. Wir wollen sicherstellen, dass sie leicht nutzbar sind.
  7. Wikifunctions wird eine API-Schnittstelle bereitstellen, um jede der darin definierten Funktionen aufzurufen. Aber es wird eine Begrenzung des Rechenaufwands geben, den sie zur Verfügung stellen wird.
  8. Abstrakte Wikipedia und Wikifunctions werden gleichermaßen von Menschen und von Bots editierbar sein. Aber die Menschen, die die Bots betreiben, müssen sich ihrer gesteigerten Verantwortung bewusst sein, die Community nicht zu erdrücken.


Architektur

Die Hauptkomponenten des Projekts sind die folgenden drei:

  1. Konstruktoren - Definitionen von Konstruktoren und ihren Slots, einschließlich ihrer Bedeutung, der Einschränkungen bezüglich der Typen der Slots und des Rückgabetyps des Konstruktors (z. B. definiere einen Konstruktor Rang, der ein Element, einen Elementtyp, die Rangfolge als Zahl, die Rangfolge und eine lokale Einschränkung entgegennimmt).

Software

  1. Inhalt - abstrakte Aufrufe von Konstruktoren inklusive Füllungen für die Slots (z. B. rank(SanFrancisco, city, 4, population, California))
  2. Renderer - Funktionen, die als Argumente einen Inhalt und eine Sprache nehmen und einen Text zurückgeben, der die Bedeutung des Inhalts in natürlicher Sprache wiedergibt (z. B. ergibt sich im angegebenen Beispiel "San Francisco ist die viertgrößte Stadt in Kalifornien, gemessen an der Einwohnerzahl.")

 

Es gibt vier prinzipielle Möglichkeiten, wo die drei verschiedenen Hauptkomponenten implementiert werden können:

  1. Konstruktoren, Inhalte und Renderer sind alle in Wikidata implementiert.
  2. Konstruktoren und Renderer sind in Wikifunctions implementiert, der Inhalt in Wikidata beim jeweiligen Objekt.
  3. Konstruktoren, Inhalte und Renderer sind alle in Wikifunctions implementiert.
  4. Konstruktoren und Inhalt sind in Wikidata implementiert, die Renderer in den lokalen Ausgaben von Wikipedia.

Lösung 4 hat den Nachteil, dass wir durch das Verschieben der Renderer und Funktionen in die lokalen Wikipedias die Möglichkeit verlieren, dass viele Funktionen von den verschiedenen Sprachen gemeinsam genutzt werden können. Außerdem wird durch die Verlagerung der Renderer in die lokalen Wikipedien das Potenzial verschenkt, das ein unabhängiger Funktionenkatalog hätte.

Wir denken, dass es für die Kommunikation und den Aufbau der Gemeinschaft vorteilhaft ist, ein neues Projekt, Wikifunctions, einzuführen, mit dem Ziel einer neuen Form von Wissensbeständen und Funktionen, die Renderer beinhalten. Dies würde für Lösung 2 und 3 sprechen.

Lösung 3 erfordert, dass wir für jeden möglichen Wikipedia-Artikel einen neuen Platz im Wiki der Funktionen anlegen. Da mit den Objekten in Wikidata bereits ein natürlicher Platz dafür existiert, wäre es bequemer, diesen zu nutzen und den Inhalt zusammen mit den Objekten in Wikidata zu speichern.

Aus diesen Gründen bevorzugen wir Lösung 2 und unterstellen sie für den Rest des Vorschlags. Wenn wir zu einer anderen wechseln, kann der Projektplan leicht angepasst werden (abgesehen von Lösung 4, die ziemlich umgeschrieben werden müsste). Beachte, dass Lösung 2 die Zustimmung der Wikidata-Community benötigt, um fortzufahren. Wenn diese nicht zustimmt, ist Lösung 3 wahrscheinlich die nächstliegende Option.

Die vorgeschlagene Architektur für die mehrsprachige Wikipedia sieht wie folgt aus. Wikipedia ruft die Inhalte ab, die in Wikidata bei den Objekten gespeichert sind. Wir nennen diese Erweiterung von Wikidata Abstrakte Wikipedia. Beachte, dass dies nur ein Name für das Entwicklungsprojekt ist, und dass es nicht zu erwarten ist, dass dieser Name bestehen bleibt - es wird kein neues Wikiprojekt mit diesem Namen geben. Mit einem Aufruf der in Wikifunctions enthaltenen Renderer wird der Inhalt in natürlichen Text übersetzt. Die Renderer greifen auf die anderen Funktionen, Typen und Konstruktoren in Wikifunctions zurück. Wikifunctions kann auch auf das lexikografische Wissen in den Lexemen in Wikidata zurückgreifen, um es bei der Übersetzung des Inhalts in Text zu verwenden. Wikifunctions wird ein neues Wikimedia-Projekt auf Augenhöhe mit Commons, Wikidata oder Wikisource sein.

 

(Die kursiv gedruckten Komponenten sollen durch diesen Vorschlag hinzugefügt werden, die fett gedruckten Komponenten existieren bereits. Kästchen auf oberster Ebene sind Wikimedia-Projekte, innere Kästchen sind Teile der angegebenen Wikimedia-Projekte.) ("Wikilambda" war der Arbeitstitel für "Wikifunctions".)


Komponenten

Wir müssen die Wikimedia-Projekte an drei Stellen erweitern:

  1. in den lokalen Ausgaben der Wikipedia und anderen Anwenderprojekten, die die neuen Möglichkeiten nutzen,
  2. in Wikidata, zur Erzeugung von Inhalt (Abstrakte Wikipedia), und
  3. in einem neuen Projekt, Wikifunctions, mit dem Ziel, eine Funktionenbibliothek zu schaffen.

Erweiterungen der lokalen Wikipedien

Jede lokale Wikipedia kann, je nach lokaler Community, zwischen einer der folgenden drei Optionen wählen:

  1. implizite Integration mit der Abstrakten Wikipedia;
  2. explizite Integration mit der Abstrakten Wikipedia;
  3. keine Integration mit der Abstrakten Wikipedia.

Die Erweiterung für lokale Wikipedien hat folgende Funktionalitäten: eine neue Spezialseite, zwei neue Funktionen und drei neue magische Wörter.

F1: Neue Spezialseite Abstract

Auf jeder lokalen Wikipedia wird eine neue Spezialseite verfügbar sein, die mit einer Q-ID oder dem lokalen Artikelnamen und einer optionalen Sprache (die standardmäßig die Sprache der lokalen Wikipedia ist) verwendet wird. Beispiel-URLs für Spezialseiten sehen wie folgt aus:

https://en.wikipedia.org/wiki/Special:Abstract/Q62
https://en.wikipedia.org/wiki/Special:Abstract/Q62/de
https://en.wikipedia.org/wiki/Special:Abstract/San_Francisco
https://en.wikipedia.org/wiki/Special:Abstract/San_Francisco/de

Wenn die Spezialseite ohne Parameter aufgerufen wird, dann wird ein Formular angezeigt, das die Auswahl einer Q-ID und einer Sprache (vorausgefüllt für die lokale Sprache) ermöglicht.

Die Spezialseite zeigt den Inhalt aus der gewählten Q-ID oder die Q-ID an, die mit dem jeweiligen Artikel verlinkt ist, der in der gewählten Sprache vom Renderer wiedergegeben wird.

F2: Explizite Artikel-Erstellung

Wenn sich die lokale Wikipedia für die Option der Integration mit der abstrakten Wikipedia durch explizite Artikelerstellung entscheidet, wird dies so gemacht.

Der Bearbeiter geht zu einem Datenobjekt auf Wikidata, das noch keinen Seitenlink in der lokalen Ziel-Wikipedia hat. Er fügt einen Seitenlink zu einer Seite hinzu, die noch nicht existiert. Auf diese Weise gibt er den Namen des Artikels an. Wenn z.B. Q62 in Englisch noch keinen Artikel und damit auch keinen Seitenlink hätte, könnte er den Seitenlink San_Francisco für en.wikipedia hinzufügen.

In der lokalen Wikipedia wird dadurch ein virtueller Artikel im Hauptnamensraum angelegt. Dieser Artikel hat denselben Inhalt wie die oben beschriebene Spezialseite, ist aber unter der üblichen URL zu finden, d. h.

https://en.wikipedia.org/wiki/San_Francisco

Links auf diesen Artikel, die den neu festgelegten Namen verwenden, sehen genauso aus wie alle anderen Links, d.h. ein Link auf [[San Francisco]] zeigt auf den virtuellen Artikel, ist blau, usw. Solche Artikel werden für die Suche in der jeweiligen Wikipedia und auch für die externe Suche indiziert.

Wenn ein Benutzer auf "Artikel bearbeiten" klickt, kann er entweder zu Wikidata gehen und den abstrakten Inhalt bearbeiten (vorzugsweise), oder einen neuen Artikel in der lokalen Sprache von Grund auf neu beginnen, oder die aktuelle Übersetzung als Text aufbereiten und diesen lokal bearbeiten.

Wenn ein bestehender lokaler Artikel mit einem Seitenlink gelöscht wird, wird automatisch ein virtueller Artikel angelegt (da wir den Namen kennen und die Links beibehalten können).

Um einen virtuellen Artikel zu löschen, muss der Seitenlink in Wikidata gelöscht werden.

Alle Änderungen an der lokalen Wikipedia müssen explizit vorgenommen werden, weshalb wir dies die explizite Artikelerstellungsoption nennen. Wir gehen davon aus, dass dies die Voreinstellung für die lokalen Wikipedias sein wird, es sei denn, sie wählen entweder die implizite Artikelerstellung oder keine Integration.

Siehe auch die Diskussion zur Integration hier.

F3: Implizite Artikel-Erstellung

Wenn eine lokale Wikipedia sich für die implizite Artikelerstellung aus Wikidata entscheidet, dann wird das Ergebnis des Aufrufs der Spezialseite Abstrakt für alle Wikidata-Datenobjekte, die keinen Seitenlink zu der gegebenen Wikipedia haben, aber den Inhalt in der jeweiligen Sprache wiedergeben würden, so indiziert und in der Suche verfügbar gemacht, als ob es im Hauptnamensraum läge.

Es wird ein neues magisches Wort eingeführt, um von normalen Artikeln auf virtuelle Artikel zu verlinken, siehe F6 LINK_TO_Q. Dieses kann unsichtbar in den visuellen Editor integriert werden.

Dies ist bei weitem der geringste Aufwand für die Community, um viele Artikel zu bekommen. Es könnte eine gute Option für kleine Communities sein.

F4: Links oder Reiter

Jeder Artikel in einer lokalen Wikipedia, der mit einem Wikidata-Datenobjekt verbunden ist, erhält einen neuen Link, entweder als Reiter am oberen Rand oder als Link in der Seitenleiste. Dieser Link zeigt den Inhalt für das verbundene Wikidata-Datenobjekt in der lokalen Sprache an. Virtuelle Artikel haben diesen Reiter nicht, aber ihre Schaltfläche Bearbeiten verlinkt direkt zum Bearbeiten des Inhalts in der Abstrakten Wikipedia.

F5: Neues magisches Wort: ABSTRACT_WIKIPEDIA

Das magische Wort wird durch den Wikitext ersetzt, der sich aus dem Rendering des Inhalts des Wikidata-Datenobjekts ergibt, das mit dieser Seite über Seitenlinks verbunden ist.

Das magische Wort kann mit zwei optionalen Parametern verwendet werden, der eine ist eine Q-ID, der andere eine Sprache. Wenn keine Q-ID angegeben wird, wird die Q-ID standardmäßig auf das Element gesetzt, mit dem diese Seite per Seitenlink verknüpft ist. Wenn keine Sprache angegeben wird, wird die Sprache standardmäßig auf die Sprache des jeweiligen Wikis gesetzt.

Aufrufbeispiele:

{{ABSTRACT_WIKIPEDIA}}
{{ABSTRACT_WIKIPEDIA:Q62}}
{{ABSTRACT_WIKIPEDIA:Q62/de}}

Wenn keine Q-ID angegeben oder voreingestellt ist, erscheint eine Fehlermeldung.

Später wird dies es ermöglichen, bestimmte Abschnitte aus dem Inhalt auszuwählen.

Wikipedien, die sich gegen eine Integration in die Abstrakte Wikipedia entscheiden, können dieses neue magische Wort trotzdem verwenden.

Beachte, dass die Einführung eines neuen magischen Worts ein vorläufiger Ansatz ist. Aufgabe 2.3 wird untersuchen, ob wir seine Funktionalitäten auch ohne dies erreichen können.

F6: Neues magisches Wort: LINK_TO_Q

Dieses magische Wort verwandelt sich in einen Link entweder auf den lokalen Artikel, der mit der angegebenen Q-ID verknüpft ist, oder, falls keiner existiert, auf die Abstrakt-Special-Seite mit der betreffenden Q-ID. Dies ermöglicht es, Artikel mit Links zu virtuellen Artikeln zu schreiben, die automatisch ersetzt werden, sobald lokale Inhalte erstellt werden.

Aufrufbeispiel:

{{LINK_TO_Q:Q62}}

ergibt

[[San Francisco]]

falls der Artikel besteht, andernfalls

[[Special:Abstract/Q62|San Francisco]]

Beachte, dass die Einführung eines neuen magischen Worts ein vorläufiger Ansatz ist. Aufgabe 2.3 wird untersuchen, ob wir seine Funktionalitäten auch ohne es erreichen können.

F7: Neues magisches Wort: LAMBDA

Dieses ruft eine in Wikidata spezifizierte Funktion zusammen mit ihren Parametern auf und gibt die Ausgabe auf der Seite aus.

Zum Beispiel wird folgender Aufruf:

{{LAMBDA:capitalize("san francisco")}}

dazu führen, dass „San Francisco‟ auf der Seite ausgegeben wird (vorausgesetzt, es gibt eine Funktion, die den lokalen Schlüssel mit der erwarteten Definition und Implementierung hat). Es wird die Sprache des lokalen Wikis verwendet, um den Aufruf zu parsen.

Denke auch an die Möglichkeit, eine bestimmte Version einer Funktion aufzurufen, um nachgelagerte Fehler zu reduzieren.

Beachte, dass die Einführung eines neuen magischen Worts ein vorläufiger Ansatz ist. Aufgabe 2.3 wird untersuchen, ob wir dessen Funktionalitäten auch ohne dies erreichen können.

Erweiterungen von Wikidata

Wir fügen dem Hauptnamensraum von Wikidata einen neuen Hilfsnamensraum hinzu. D.h. jede Artikelseite der Form www.wikidata.org/wiki/Q62 erhält auch eine zugehörige Inhaltsseite www.wikidata.org/wiki/Content:Q62. Diese Seite enthält den abstrakten, sprachunabhängigen Inhalt und ermöglicht dessen Bearbeitung und Pflege.

Möglicherweise werden zusätzliche Spezialseiten benötigt. Dies wird im zweiten Teil des Projekts erweitert. Es erfordert die Zustimmung der Wikidata-Community, dass das Projekt für die Speicherung der abstrakten Inhalte verwendet wird, und es wird ein anderes Projekt gewählt, wenn sie nicht einverstanden ist.

F8: Neuer Namensraum: Content

Neuer Namensraum mit einer Menge komplexer interaktiver Bearbeitungsfunktionen. Bietet UX zum Erstellen und Pflegen von Inhalten sowie Funktionen zum Auswerten der Inhalte (z. B. Anzeige, wie viel davon pro Sprache angezeigt wird, usw.) Dies ist größtenteils eine Teilmenge der Funktionalität des F11 Function Namensraums.

F9: Neuer Datentyp: Content

Ein neuer Datentyp, der einen (kurzen) Inhalt enthält. Der Hauptanwendungsfall sind die Beschreibungen in Datenobjekten und Glossen in Senses von Lexemen.

F10: Beschreibungen in Datenobjekten und Glossen in Senses indizieren und benutzen

Indizieren und überlagern der Linearisierungen von Beschreibungsfeldern für Datenobjekte und Glossen in Senses, und sicherstellen, dass für Beschreibungsfelder in Datenobjekten keine doppelten Bezeichnung / Beschreibung-Paare vorhanden sind. Ein Überschreiben dieser beiden durch manuelle Bearbeitungen ermöglichen.

Erweiterungen anderer Wikimedia-Projekte

Andere Wikimedia-Projekte werden auch die magischen Wörter F7 LAMBDA und F5 ABSTRACT_WIKIPEDIA erhalten, aber keine der anderen Funktionalitäten, da diese für sie nicht besonders nützlich erscheinen. Dies kann sich aufgrund von Anfragen aus den jeweiligen Communities ändern.

Erweiterungen des neuen Wikis der Funktionen

Wikifunctions wird ein neues Wikimedia-Projekt auf einer neuen Domain sein. Der Hauptnamensraum von Wikifunctions wird der ganz neue Function Namensraum sein. Der Rest von Wikifunctions wird ein traditionelles Wikimedia-Wiki sein.

F11: Neuer Namensraum: Function

Die Speicherung von Funktionen, Typen, Schnittstellen, Werten, Tests, etc. ermöglichen. Es gibt einen einzigen Namensraum, der Konstanten (wie Typen oder Einzelwerte), Funktionsschnittstellen, Funktionsimplementierungen und damit auch Konstruktoren und Renderer enthält. Die Entitäten in diesem Namensraum werden durch Z-IDs benannt, ähnlich den Q-IDs der Wikidata-Datenobjekte, aber beginnend mit einem Z und gefolgt von einer Zahl.

Es gibt viele verschiedene Arten von Entitäten im Z-Namensraum. Dazu gehören Typen und andere Konstanten (die im Grunde nullstellige Funktionen sind), sowie klassische ein- oder mehrstellige Funktionen.

Bearbeiter können neue Funktionstypen innerhalb des Function Namensraums erstellen und diese dann verwenden.

Funktionen können Argumente haben. Funktionen können mit ihren jweiligen Argumenten ausgeführt werden und ergeben einen Wert, dessen Typ durch die Funktionsdefinition vorgegeben ist.

Der Function Namensraum ist komplex und wird je nach Typ der Funktion sehr unterschiedliche Sichten haben, d.h. für Oberflächen, Implementierungen, Tests, Typen, Werte usw. wird es unterschiedliche UX darauf geben, obwohl sie intern alle als Z-Objekte gespeichert sind. Letztendlich werden die verschiedenen Sichten alle durch Funktionen in Wikifunctions erzeugt.

Es wird möglich sein, Entitäten im Function Namensraum einzufrieren und aufzutauen. Dies ist ähnlich wie eine geschützte Seite, schränkt aber nur die Bearbeitung des Wertteils der Entität ein, nicht die Bezeichnung, die Beschreibung, usw.

F12: Neue Spezialseiten und API-Module

Es werden neue Spezialseiten und API-Module zur Unterstützung des neuen Function Namensraums erstellt. Dieser wird insbesondere eine Spezialseite und ein API-Modul enthalten, die es erlauben, Funktionen mit übergebenen Funktionsparametern auszuwerten. Daneben wird es zahlreiche Spezialseiten und APIs geben, die die Pflege der Inhalte unterstützen (z. B. Suche nach Anzahl und Typen von Parametern, Seiten mit Statistiken, wie oft bestimmte Implementierungen aufgerufen werden, Testseiten usw.). Ziel ist es, so viele wie möglich davon innerhalb von Wikifunctions zu implementieren.


Aufgaben

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:

  1. 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.
  2. 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.
  3. 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.

<span id="_Part_P1:_Wikifunctions">

Projektteil P1: Wikifunctions

<span id="_Task_P1.1:_Project_initialization">

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.

<span id="_Task_P1.2:_Initial_development">

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.

<span id="_Task_P1.3:_Set_up_testing_infrastructure">

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.

<span id="_Task_P1.4:_Launch_public_test_system">

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.

<span id="_Task_P1.5:_Server-based_evaluator">

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.

<span id="_Task_P1.6:_Function_composition">

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.

<span id="_Task_P1.7:_Freeze_and_thaw_entities">

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.

<span id="_Task_P1.8:_Launch_beta_Wikifunctions">

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.

<span id="_Task_P1.9:_Launch_Wikifunctions">

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.

<span id="_Task_P1.10:_Test_type">

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.

<span id="_Task_P1.11:_Special_page_to_write_function_calls">

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.

<span id="_Task_P1.12:_JavaScript-based_implementations">

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.

<span id="_Task_P1.13:_Access_functions">

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.

<span id="_Task_P1.14:_Create_new_types">

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.

<span id="_Task_P1.15:_Lua-based_implementations">

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).

<span id="_Task_P1.16:_Non-functional_interfaces">

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.

<span id="_Task_P1.17:_REST_calls">

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.

<span id="_Task_P1.18:_Accessing_Wikidata_and_other_WMF_projects">

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.

<span id="_Task_P1.19:_Monolingual_generation">

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.

<span id="_Part_P2:_Abstract_Wikipedia">

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.

<span id="_Task_P2.1:_Constructors_and_Renderers">

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.

<span id="_Task_P2.2:_Conditional_rendering">

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.

<span id="_Task_P2.3:_Abstract_Wikipedia">

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.

<span id="_Task_P2.4:_Mobile_UI">

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.

<span id="_Task_P2.5:_Integrate_content_into_the_Wikipedias">

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).

<span id="_Task_P2.6:_Regular_inflection">

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.

<span id="_Task_P2.7:_Basic_Renderer_for_English">

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.

<span id="_Task_P2.8:_Basic_Renderer_for_a_second_language">

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.

<span id="_Task_P2.9:_Renderer_for_a_language_from_another_family">

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.

<span id="_Task_P2.10:_Renderer_for_an_underserved_language">

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.

<span id="_Task_P2.11:_Abstract_Wikidata_Descriptions">

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.

<span id="_Task_P2.12:_Abstract_Glosses">

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.

<span id="_Task_P2.13:_Support_more_natural_languages">

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.

<span id="_Task_P2.14:_Template-generated_content">

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.

<span id="_Task_P2.15:_Casual_comments">

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.

<span id="_Task_P2.16:_Quick_article_name_generation">

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.

<span id="_Non-core_tasks">

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.

<span id="_Task_O1:_Lambda_calculus">

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.

<span id="_Task_O2:_CLI_in_a_terminal">

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.

<span id="_Task_O3:_UIs_for_creating,_debugging_and_tracing_functions">

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.

<span id="_Task_O4:_Improve_evaluator_efficiency">

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.

<span id="_Task_O5:_Web_of_Trust_for_implementations">

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.

<span id="_Task_O6:_Python-based_implementations">

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.

<span id="_Task_O7:_Implementations_in_other_languages">

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.

<span id="_Task_O8:_Web-based_REPL">

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.

<span id="_Task_O9:_Extend_API_with_Parser_and_Linearizer">

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.

<span id="_Task_O10:_Support_talk_pages">

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.

<span id="_Task_O11:_Legal_text_creation">

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.

<span id="_Task_O12:_Health_related_text_creation">

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.

<span id="_Task_O13:_NPM_library">

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.

<span id="_Task_O14:_Python_library">

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.

<span id="_Task_O15:_Libraries_for_other_programming_languages">

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.

<span id="_Task_O16:_Browser-based_evaluator">

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).

<span id="_Task_O17:_Jupyter-_and/or_PAWS-based_evaluator">

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.

<span id="_Task_O18:_App-based_evaluator">

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.

<span id="_Task_O19:_P2P-based_evaluator">

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.

<span id="_Task_O20:_Cloud-based_evaluator">

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.

<span id="_Task_O21:_Stream_type">

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.

<span id="_Task_O22:_Binary_type">

Aufgabe O22: Binär-Typ

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

<span id="_Task_O23:_Integration_with_Commons_media_files">

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.

<span id="_Task_O24:_Integrate_with_Machine_Learning">

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.

<span id="_Task_O25:_Integrate_into_IDEs">

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.

<span id="_Task_O26:_Create_simple_apps_or_Websites">

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.

<span id="_Task_O27:_Display_open_tasks_for_contributors">

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.

<span id="_Task_O28:_Active_view">

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.

<span id="_Task_O29:_Implementation_compilation">

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.

<span id="_Task_O30:_Integrate_with_Code_examples_on_Wikipedia,_Wikibooks,_etc.">

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.


Implementierungsphasen

Die Entwicklung der abstrakten Wikipedia wird in zwei Hauptteilen ablaufen, die eine große Anzahl von Aufgaben enthalten. Im ersten Teil geht es um die Entwicklung des Wikis der Funktionen, im zweiten um abstrakte Inhalte und um die Generierung natürlicher Sprache. Auf dieser Seite gliedern wir den Beginn des ersten Teils weiter in Phasen auf. Die Phasen werden in Phabricator abgebildet und von hier aus verlinkt, ebenso wie Aufgaben und weitere Untergliederungen von Aufgaben.

Der kanonische Ort für Informationen über die Phasen und Aufgaben ist auf Phabricator zu finden. Diese Seite könnte veraltet sein. Schaue den aktuellen Stand auf Phabricator nach.

Wir gehen davon aus, dass es etwa ~10 Phasen geben wird, bevor das Wiki der Funktionen gestartet wird.

Alle folgenden Aufgaben gehören zu Aufgabe P1.2, wenn nicht anders gekennzeichnet.


Projektteil P1: Wiki der Funktionen

Hauptartikel: Abstrakte Wikipedia/Aufgaben — § Projektteil P1: Wikifunctions

Phase α (alpha): Header speichern, anzeigen und editieren —   Fertig 2020-08-25

  1. Replizierbare Entwicklungsumgebung einrichten. — Aufgabe T258893
    •   Fertig Start Erweiterung. — Aufgabe T258893
    •   Fertig Aufgaben konfigurieren, Bootstrap-Inhalt hochladen.
    •   Fertig Bestehende JSON ContentHandler wiederverwenden. — Aufgabe T258893
    •   Fertig Eingabe von JSON-Objekten über die Rohschnittstelle ermöglichen. — Aufgabe T258893
  2.   Fertig Ausbau und Hardcode-Prüfer für JSON-Objekte, um die formale Richtigkeit von ZObjekten zu prüfen. Nichts, was nicht formal richtig ist, wird weiter verarbeitet oder gespeichert. Die formale Richtigkeit sollte wahrscheinlich sowohl im PHP- als auch im JS-Code geprüft werden (sollte sowieso einfach zu schreiben sein).
    •   Fertig in PHP — Aufgabe T258894
    • Formale Richtigkeit: Schlüsselsyntax, erlaubte Schlüssel, Werte sind Strings oder Proto-Objekte oder Listen von Werten. — Aufgabe T258894
  3.   Fertig Jedes gespeicherte ZObjekt der obersten Ebene muss ein Z2/Persistentes Objekt sein. — Aufgabe T258897
  4.   Fertig Z1/Objekt erzeugen, das einen Schlüssel vom Z1K1/Type anbietet.
  5.   Fertig Den hartkodierten Validator um Z1K1/Type-Prüfung erweitern.
  6.   Fertig Z2/Persistentes Objekt erzeugen. — Aufgabe T258897
  7.   Fertig Z2/Persistentes Objekt hat die Schlüssel Z2K1/ID und Z2K2/Wert und Z2K3/Proto-Label, wobei letzteres kontrafaktisch nur eine einzelne Zeichenkette ohne Sprachinformation ist. — Aufgabe T258897
  8.   Fertig Den hartkodierten Validator um Z2/Persistentes Objekt-Prüfung wie bisher erweitern. — Aufgabe T258897
  9.   Fertig Hardkodierte Anzeige für Z2/Persistentes Objekt (das ist der Header) bereitstellen (das ist eine ziemlich heftige Aufgabe). — Aufgabe T258898
  10.   Fertig Eine allgemeine Ansicht für das Z2K2/Wert Objekt bereitstellen. — Aufgabe T258898
  11.   Fertig Das Z2K3/Proto-Label in das eigentliche Z2K3/Label für mehrsprachigen Text umwandeln.
  12.   Fertig Z2K3/Label-Anzeige um mehrsprachigen Text erweitern.

Phasenabschlussbedingung: Als Benutzer [einer Seite mit installierter MediaWiki-Erweiterung] kann ich einen String als neues ZObjekt erstellen und speichern, z.B. "Hallo Welt!".

Phase β (beta): Typen und Instanzen erzeugen —   Fertig 2021-02-04

  1.   Fertig Hartkodierte Prüfer (Validatoren) für Z4/Proto-Typen und Z3/Proto-Schlüssel. — Aufgabe T258900
    • Ein Z4 hat einen Z4K2/Schlüssel mit einer JSON-Liste mit Z3s.
    • Ein Proto-Schlüssel hat eine Z3K1/ID und Z3K2/Type und Z3K3/Label (spiegele die Entwicklung der Bezeichnung für Z2K3?).
  2.   Fertig Z4/Typ und Z3/Schlüssel erzeugen (Aufgabe P1.14).
  3.   Fertig Z-Objekte mittels Bezeichnung suchen. — Aufgabe T260750
  4.   Fertig für diese Phase. Z4-Typdaten und Schlüssel-Deklarationen zur Objektvalidierung verwenden. — Aufgabe T260861
  5.   Fertig Z4-Typdaten und Schlüssel-Deklarationen zur generischen Darstellung von Objekten verwenden. — Aufgabe T258901
  6.   Fertig Z4-Typdaten und Schlüssel-Deklarationen zur Bearbeitung und Erzeugung von Objekten verwenden. — Aufgabe T258903 & Aufgabe T258904
  7.   Fertig Eine hartkodierte Anzeige- und Editierschnittstelle für Typ Z12 bereitstellen. — Aufgabe T258900

Phasenabschlussbedingung: Als Benutzer kann ich ein Objekt erstellen und speichern, das einen beliebigen im Wiki definierten Typ implementiert, z.B. die positive ganze Zahl eins

Phase γ (gamma): Funktionen, Implementierungen, Fehler —   Fertig 2021-04-02

  1.   Fertig Ein einfaches Fehlerobjekt einführen. — Aufgabe T261464
  2.   Fertig Einfache Funktion einführen. — Aufgabe T258957
  3.   Fertig Einfache Implementierung einführen, vorerst nur Built-ins. — Aufgabe T258958
  4.   Fertig Neue Funktionen und Built-ins entwickeln. — Aufgabe T261474
  5.   Fertig Einen einfachen Funktionsaufruftyp einführen. — Aufgabe T261467
  6.   Fertig Den Typ (Aufgabe P1.10) erproben. — Aufgabe T261465

Phasenabschlussbedingung: Als Benutzer kann ich einen Funktionsaufruf, eine Funktion und einen Tester speichern (nur die Objekte, noch keine eigentliche Auswertung), z.B. if(true, false, true) (gelesen "if true then false else true", d.h. Negation)

Phase δ (delta): Built-ins —   Fertig 2021-05-11

  1.   Fertig Evaluierungssystem für Built-ins. — Aufgabe T260321
  2.   Fertig Es Web-Usern ermöglichen, die Evaluierung mittels eines API-Moduls aufzurufen (Aufgabe P1.5). — Aufgabe T261475
  3.   Fertig Spezialseite für den Evaluierungsafruf (Aufgabe P1.11). — Aufgabe T261471

Phasenabschlussbedingung: Als Benutzer kann ich über eine spezielle Seite eine eingebaute Funktion mit bereitgestellten Eingaben auswerten, z.B. um zu prüfen, ob die leere Liste leer ist.

Phase ε (epsilon): Funktionsaufruf —   Fertig 2021-06-30

  1.   Fertig JavaScript-Implementierungen (Aufgabe P1.12). — Aufgabe T275944
  2.   Fertig Python-Implementierungen (Aufgabe O6). — Aufgabe T273517
  3.   Fertig Es ermöglichen, Formulare zur Evaluierung einzubinden. — Aufgabe T261472

Phasenabschlussbedingung: Als Benutzer kann ich eine spezielle Seite verwenden, um eine benutzergeschriebene Funktion in einer der unterstützten Sprachen auszuwerten, z. B. eine benutzergeschriebene Funktion in Python aufrufen, um zwei Zahlen zu addieren.

Phase ζ (zeta): Komposition —   Fertig 2021-08-27

  1.   Fertig Kompositionsimplementierungen ermöglichen (Aufgabe P1.6). — Aufgabe T261468

Phasenabschlussbedingung:

  • Als Benutzer kann ich eine Funktion durch Komposition anderer Funktionen implementieren, anstatt sie selbst zu schreiben, z. B. negate(Boolean → Boolean). —   Fertig
  • Dehnungsbedingung: Als Benutzer kann ich die Ergebnisse von Testern auf der Seite der jeweiligen Funktionsimplementierung sehen. [Dies muss möglicherweise in eine spätere Phase verschoben werden, da möglicherweise nicht alle Anforderungen erfüllt werden. Muss in Phase ι erfolgen.] —   Fertig

Phase η (eta): generische Typen —   Fertig 2022-04-08

  1.   Fertig Generische Typen ermöglichen, insbesondere für Z10/Liste und Z8/Funktion, und Z10/Liste und Z8/Funktion ersetzen. ― Aufgabe T275941
  2.   Fertig Fehler können wie ZObjekte verarbeitet werden.
  3.   Fertig Benutzerdefinierte Typen arbeiten mit Validatoren.

Phasenabschlussbedingung:

  • In der Lage sein, curry als ein Komposition im Wiki zu implementieren, ohne jedoch eine strenge statische Analyse zu erfordern. —   Fertig
  • Ermöglicht das Erstellen der folgenden drei „benutzerdefinierten‟ Typen im Wiki: positive ganze Zahl, numerisches Zeichen und ganze Zahl. —   Fertig
  • In der Lage sein, einen generischen Wrapper-Typ durch Komposition im Wiki zu erstellen. —   Fertig

Siehe auch den Newsletter, der zu dieser Phase veröffentlicht wurde.

Phase θ (theta): Auftauen und Einfrieren —   Fertig 2023-06-19

  1.   Fertig Inhalte einfrieren und auftauen (Aufgabe P1.7). ― Aufgabe T275942
  2.   Fertig Aufgabe P1.9: Review der Sicherheit bestehen. — Aufgabe T274682, …
  3.   Fertig Öffentliches Testsystem freigeben (Aufgabe P1.4). — Aufgabe T261469

Phasenabschlussbedingung:

  • Als Administrator kann ich jedes vom Benutzer geschriebene Objekt einfrieren und wieder freigeben (ähnlich oder vielleicht gleich wie das Schutzsystem von MediaWiki); alle vom System bereitgestellten Objekte werden dauerhaft eingefroren.
  • Als Benutzer, der eine eingefrorene Seite bearbeitet, kann ich die Beschriftung ändern, aber nicht die Implementierung, während auf einer nicht eingefrorenen Seite beides möglich ist.
  • ZObjekte werden in der neuen kanonischen Form für Typenlisten gespeichert und alle Teile funktionieren weiterhin
  • Das Betrachten und Bearbeiten von Funktionen ist implementiert und erfolgreich getestet
  • Wenn mehrere Implementierungen verfügbar sind, wird die "beste" ausgewählt. (Eignungsbestimmung, die später möglicherweise geändert wird.)
  • Wir messen die Dauer & Speichernutzung für jede Funktionsausführung und zeigen sie beim Ergebnis der Ausführung & in der Tabelle der Implementierungen/Tests an.
  • Bearbeitungen an systemdefinierten ZObjekten sind auf Benutzer mit den zugehörigen Rechten beschränkt. Verständliche Versionsunterschiede werden angezeigt. Ergebnisse werden gespeichert.
  • Text mit Rückfall, Referenzen, Zeichenketten und Listen ist implementiert und erfolgreich getestet
  • Ein gemeinsames Verständnis mit der Gemeinschaft, wie und warum das Team zu Wikifunctions beiträgt, ist dokumentiert
  • Designs für das Betrachten und Bearbeiten mehrsprachiger Dokumentation in der mobilen Ansicht und auf dem Desktop sind genehmigt. UX ist instrumentiert und Daten gesammelt.

Phase ι (iota): Dokumentation von Objekten

  1. Dies ist eine vorläufige Zuordnung, die die Dokumentationsaufgaben hierher verschiebt.
  2. Editieren der Kopfzeile (zusätzlich zur vollständigen Rohbearbeitung) bereitstellen (das ist eine ziemlich große Aufgabe) - das bezieht sich eigentlich nur auf die Bezeichnungen.
  3. Die Editierung für Z2K3/Label um mehrsprachigen Text erweitern.
  4. Die Kopfzeile um Z2K4/Documentation erweitern. — Aufgabe T260954 & Aufgabe T260956
  5. Die Editierung um die Bearbeitung von Z2K4/Documentation erweitern. — Aufgabe T260955

Phasenabschlussbedingung: Als Benutzer kann ich ein ZObjekt in allen unterstützten Sprachen dokumentieren, indem ich einen Wikitext verwende.

Phase κ (kappa): Aufräumen

  1. Bereinigung und Aufräumen von Aufgaben, um alle Pre-Launch-Aufgaben abzuschließen.

Phasenabschlussbedingung: Als Abstract-Wikipedia-Team fühlen wir uns bereit für den Start, einschließlich der Freigabe durch alle relevanten Kollegen.

Phase λ (lambda): Freigeben

  1. Phase λ (Lambda) ist für die Freigabe gedacht. Wenn es Pre-Launch-Aufgaben gibt, die das verhindern, dann ist das natürlich so.
  2. Ein neues Wikimedia-Projekt aufsetzen.
  3. Einige der Wiki-Seiten über das Projekt von Meta nach Wikifunctions verschieben.

Phasenabschlussbedingung: Als Person im Web kann ich Wikifunctions.org besuchen und nutzen um Funktionen direkt auf der Seite zu schreiben und auszuführen.

Aufgaben außerhalb der Phasen

Aufgaben vor der Freigabe, die erledigt werden müssen, aber noch nicht eingephast sind:

Aufgaben nach Freigabe von Projektteil 1

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Abstract_Wikipedia/Plan/de&oldid=21266372"