抽象ウィキペディア/プラン
 | このpageは歴史的な関心の対象として保持されています。文中では、既に廃止された方針が言及されていることがあります。 これについての議論を再開したい場合は、トークページまたはコミュニティのフォーラムをお使いください。 |
| 抽象的なウィキペディア |
|---|
| (議論) |
| 全般 |
| 開発計画 |
| 注記、草案、議論 |
|
| 例 & 模型 |
| データツール |
| 経過 |
- この単ページ版は節名ごとに参照読み込みしてあります。節名をクリックするとそれぞれの固有ページに飛びます。
 | この提案は草案であり、コミュニティや他のステークホルダーとの議論と決定に基づいて、大きな変更が予想されます。
これはまた、提案を形作り改善していくためにコメントや議論が歓迎されることを意味します。 |
抽象ウィキペディアでは、 “抽象的コンテンツ “が、コミュニティにより直接編集でき、言語に依存しない形式で表されます。 ローカルウィキペディアはアクセスして（抽象ウィキペディアからの） “抽象的コンテンツ “を使って、ローカルに独自管理されているコンテンツを充実させることができます。 このように、ウィキペディアのローカライズ版は、ほとんどのローカルウィキペディアが提供できるものよりもはるかに少ない労力で、はるかに多くのコンテンツを読者に提供できます。
自然言語生成の分野における研究結果とプロトタイプを考えると、残念ながら、言語に依存しない“抽象的コンテンツ“からの自然言語生成には“チューリング完全”システムが必要です。 しかし、ウィキペディアがカバーする必要のある言語の数をカバーするために、このシステムはクラウドソーシングされなければなりません。 したがって、私たちはWikifunctionsを導入します。これは、“関数“のオープンライブラリ（またはリポジトリ）を作成、カタログ化、および維持するためのプロジェクトであり、多くの使用事例が考えられます。
その主な使用例は、ウィキデータで利用可能な言語的およびオントロジー的知識（あるいはウィクショナリーやウィキスピーシーズなどの他のウィキメディアプロジェクトからのデータを含め、ウィキペディアで使用可能な適切なライセンス要件を持つ他のオープンデータソースからの知識）を使用して、言語に依存しない“抽象的なコンテンツ“を自然言語に変換する“レンダラー“（つまり、Wikifunctionsでホスト、あるいは参照される関数の一部）の開発です。
プロジェクトは、Wikifunctionsのプロジェクト作成から始まり、抽象ウィキペディアの作成を可能にするためにこれを使用します。 Wikifunctionsは1年以内に立ち上げられ、2年目に抽象ウィキペディアの開発が追加されます。 2年後、言語に依存しない“抽象的なコンテンツ“の作成と維持、そしてウィキペディア内でのこのコンテンツの統合を可能にするエコシステムを作成し、多くの個々のウィキペディアの網羅性、最新性、および精度を大幅に向上させます。 これは、誰もが全ての知識の総体を共有できる世界に劇的に近づけるでしょう。
| 新しいウィキの名前は、Wiki of functions naming contestで "Wikifunctions"(ウィキファンクションズ)に決定されました。 |
すべての名称(Abstract WikipediaとWikilambda)は予備的なもので、主にこの提案を書き、それを議論するためのものです。
現在の名称は下の様な考えからきています :
- Abstract Wikipedia: the content in Abstract Wikipedia abstracted away from a concrete language.
- Wikilambda: this is based on the notion that all functions can be grounded in lambda calculus. Also, Wλ looks kinda technophile (“geeky”), with the risk of being perceived as not meeting its intended public and being managed with a bias only by specialists, already advantaged by an access to the largest knowledge available in their own culture.
Note that the name "Abstract Wikipedia" will not, in fact, stick around. When the project is done, Abstract Wikipedia will be just a part of Wikidata. This is just a name for the development work, and therefore naming is not that crucial. Wikilambda on the other hand would be a new Wikimedia project, and thus the name will have rather high visibility. It would be good to come up with a good name for that.
目的
There have been three good reasons against the name Wikilambda brought up so far:
- It is really hard to spell for many people (says Effeietsanders).
- Some people keep misreading it as Wikilambada (says Jean-Frédéric).
- It also easily misreads as WikiIambda / Wikiiambda (that's, with yet another i / I instead of the l / L), so it should at least be WikiLambda with a capital L (suggested by Fuzheado).
推奨される代替案
Alternative names that have been considered or suggested:
| This is an archive. New names should be proposed in Wiki of functions naming contest. |
|---|
Other suggestions are welcome. |
In fact, the first task P1.1 for the project will be to decide with the community together on a name and on a logo. This had precedence for previous projects (Logo of Wikidata, Name of Wikivoyage).
プロジェクトには、野心的な第一目標と一連の第二目標があります。
第一目標
- より多くの人々が選択した言語でより多くのコンテンツを読むことができること。
- より多くの人々がより多くの読者のためにコンテンツを投稿できること、そして取り上げられることの少ない投稿者のリーチを拡大すること。
第二目標
第二目標には、以下が含まれますが、これらに限定されません。
- 再利用可能で十分にテストされた自然言語生成。
- 他のウィキメディア・コミュニティや外部の関係者がより多くの言語でコンテンツを作成できること。
- ウィキペディアのプロジェクトを超えて、コミュニケーションと知識のアクセシビリティを改善すること。
- 知識表現への新しい、より包括的なアプローチを開発します。
- 自然言語理解の結果を表すための新しいアプローチを開発します。
- 関数のライブラリ。
- 最初に英語を学ぶことを必要とせず、ユーザーの母国語で関数を開発、共有できること。
- 誰もが関数を共有して実行できること。
- ウィキメディアプロジェクトが管理する新しい知識資産の形を導入すること。
- ウィキペディアとその他ウィキメディア・プロジェクトに、インタラクティブな機能を可能にする新しいコンポーネントを導入すること。
- ウィキデータの知識ベース上で動作する関数を作成し、推論を追加してウィキデータのデータカバー率を大幅に拡大します。
- コーディングインターフェイスの大衆化のための研究開発の促進。
- 科学者とアナリストが共同でモデルを共有し、作業できること。
- 機能の仕様とテストを共有します。
- 明確に定義された識別子を通して、関数の語義(semantics)を参照することができます。
- より幅広い関数の標準ライブラリ（あるいはリポジトリ）に新しい専用ウィキでアクセスすることによる、新しいプログラミング言語の開発の迅速化。
- 標準および技術解説用のアルゴリズムやアプローチを定義すること。
- 新しい機械学習システムに統合する強力な機能へのアクセスを提供すること。
このリストは網羅的なものではありません。
単一のホスティング組織に雇用され、ウィキファンクションズと抽象ウィキペディアに専従するコアチームを想定しています。 人事、法務などは、ホスティング組織の他部門によってサポートされます。
チームは、外部からのコードベースへの貢献を歓迎しオープンであることがはっきり掲げられてます。 これらの人は、ボランティアの場合もあれば、有給の場合もあります（たとえば、運動団体助成金を通じて、あるいは他の組織や会社により）。 私たちは、このような野心的なプロジェクトに必要な健全なボランティアコミュニティを作成する機会を増やすために、ボランティアに好ましい待遇を提供することを目指しています。
プロジェクトはオープンで開発されます。チームのコミュニケーションチャネルは可能な限り公開されます。コミュニケーションガイドラインは公開されます。 これは、公開でやりとりしてコードベースへの外部貢献を一体化できる開発チームづくりに役立ちます。
以下の強力な必要事項は、ウィキメディア・ムーブメントの原則と実践に基づいています。
- 抽象ウィキペディアとウィキファンクションズは、ウィキメディアプロジェクトであり、ウィキメディア財団によって維持、運営されます。これは、抽象ウィキペディアとウィキファンクションズがウィキメディア・ムーブメントの創設原則とガイドラインに従うことを要求しています。
- 抽象ウィキペディアとウィキファンクションズを実行するソフトウェアは、オープンソースライセンスの下で開発され、オープンソースであるソフトウェアのみに依存します。
- 抽象ウィキペディアとウィキファンクションズの設定は、現在のウィキメディアの基盤にできるだけ簡単に溶け込むべきです。これは、できる限り同じ展開、保守、および基盤運用に合わせるべきであることを意味します。
- 抽象ウィキペディアとウィキファンクションズの全てのコンテンツは、無料ライセンスで利用できるようになります。
- 抽象ウィキペディアとウィキファンクションズの成功は、健全なコミュニティの作成、そしてこれまで知識にアクセスできなかった言語でどれだけの知識が利用可能になったかによって測られます。
- 抽象ウィキペディアは、個々のウィキペディアの多くで定義されている原則：特に、中立的観点、検証可能性、特筆性、非独自研究（コミュニティの能力開発と各ローカルウィキのコミュニティによってさらに開発されます）に従います。
- 抽象ウィキペディアとウィキファンクションズは完全に国際化され、ウィキメディアプロジェクトの全ての言語で利用でき、編集可能になります。完全にローカライズされるかどうかは、コミュニティ次第です。
- 第一の目標は、ローカルのウィキペディア、ウィキデータ、その他ウィキメディアプロジェクトの順にサポートすることです。第二の目標は、私たち自身のコミュニティを成長させることです。第三の目標は、世界の他の地域をサポートすることです。
- ローカルのウィキペディアコミュニティは、抽象ウィキペディアがどれだけ影響を与えるかを管理していなければなりません。影響を受けたくない場合、完全に無視することができ、何も変わりません。
メディアウィキの開発者がウィキペディアのコンテンツを決定しないのと同様に、抽象ウィキペディアの開発者は抽象ウィキペディアのコンテンツを決定しません。 他のウィキメディアプロジェクトとは異なり、開発者は、タイプと関数の初期セットの設定とキックスタート、抽象ウィキペディアのウィキファンクションズで必要な関数の作成、言語レンダラーコミュニティ開始支援に積極的に取り組みます。 他のプロジェクトとは異なり、抽象ウィキペディアと関数ウィキの開発チームは当初はプロジェクトにより深く関わりますが、それら全てを早急にコミュニティに引き渡すことを目指しています。
以下の必要事項は、抽象ウィキペディアの設計と開発に適用する強力な指針として使われます。
- 抽象ウィキペディアとウィキファンクションズは社会技術システムです。過度にインテリジェント化する代わりに、ウィキメディアコミュニティに依存しています。
- 抽象ウィキペディアとウィキファンクションズの第一目標は、ウィキペディアで実際の使用事例を提供することであり、知識表現で何らかの形の仮想的な完全性を実現したり、全ての人間の言語を表現したりすることではありません。
- 抽象ウィキペディアとウィキファンクションズは、使いやすさと表現力のバランスをとる必要があります。ユーザーインターフェイスは、いくつかの例外的な極端な事例を網羅するために複雑とすべきではありません。
- 何が例外的な事例と何がそうでない事例なのかは、ウィキペディアに出てくる頻度により定義されます。事例証拠や仮説的な事例の代わりに、ウィキペディアを分析して、特定の事例がどれだけの頻度かを調べます。
- 実用的にいきましょう。展開は完璧さよりもよいものです。
- 抽象ウィキペディアとウィキファンクションズは、外部の研究、開発、および使用事例をサポートできる多くの新しいデータを提供します。 使いやすいようにしたいと思います。
- ウィキファンクションズは、定義関数を呼び出すためのAPIインターフェースを提供します。しかし、提供される計算コストには限界があります。
- 抽象ウィキペディアとウィキファンクションズは、同様に人間とボットが編集できます。 しかし、ボットを運用者たちは、コミュニティを圧倒しないという高められた責任を認識している必要があります。
プロジェクトの主な構成要素は次の3つです。：
- コンストラクタ – 意味するもの、スロットの型の制限、コンストラクターの戻り値の型など、コンストラクターとそのスロットの定義 (例：アイテム、アイテムタイプ、数値としてのランク、何によるランク付けか、ローカル制約といったものを取込んだコンストラクタ
rankを定義します) - コンテンツ – スロットに対するフィラーを含むコンストラクターへの抽象呼出し(例：
rank(SanFrancisco, city, 4, population, California)) - レンダラー – コンテンツと言語を受け取り、テキストを返す関数で、コンテンツの意味を表す自然言語を生成します。（例：与えられた例では、“サンフランシスコはカリフォルニアの人口で4番目に大きい都市です”という結果になります。）
3つの異なる主要構成要素をどこに実装するか、主に4つの可能性があります。
- コンストラクタ、コンテンツ、レンダラーは全てウィキデータに実装する。
- コンストラクタとレンダラーは、ウィキファンクションズに実装し、コンテンツはウィキデータの対応する項目の隣に実装する。
- コンストラクタ、コンテンツ、レンダラーは全てウィキファンクションズに実装する。
- コンストラクタとコンテンツはウィキデータに実装し、レンダラーはウィキペディアのローカル版に実装する。
Solution 4 has the disadvantage that many functions can be shared between the different languages, and by moving the Renderers and functions to the local Wikipedias we forfeit that possibility. Also, by relegating the Renderers to the local Wikipedias, we miss out on the potential that an independent catalog of functions could achieve.
We think it is advantageous for communication and community building to introduce a new project, Wikifunctions, for a new form of knowledge assets, functions, which include Renderers. This would speak for Solution 2 and 3.
Solution 3 requires us to create a new place for every possible Wikipedia article in the wiki of functions. Given that a natural place for this already exists with the Items in Wikidata, it would be more convenient to use that and store the Content together with the Items in Wikidata.
Because of these reasons, we favor Solution 2 and assume it for the rest of the proposal. If we switch to another, the project plan can be easily accommodated (besides for Solution 4, which would need quite some rewriting). Note that solution 2 requires the agreement of the Wikidata community to proceed. If they disagree, Solution 3 is likely the next closest option.
The proposed architecture for the multilingual Wikipedia looks as follows. Wikipedia calls the Content which is stored in Wikidata next to the Items. We call this extension of Wikidata Abstract Wikipedia. Note that this is merely a name for the development project, and that this is not expected to be a name that sticks around - there won’t be a new Wikiproject of that name. With a call to the Renderers in Wikifunctions, the Content gets translated into natural language text. The Renderers rely on the other Functions, Types, and Constructors in Wikifunctions. Wikifunctions also can call out to the lexicographic knowledge in the Lexemes in Wikidata, to be used in translating the Content to text. Wikifunctions will be a new Wikimedia project on par with Commons, Wikidata, or Wikisource.
(イタリック体で指定されたコンポーネントは、この提案によって追加され、太字のコンポーネントはすでに存在します。最上位のボックスはウィキメディア プロジェクトであり、内側のボックスは特定のウィキメディア プロジェクトの一部です。) ("Wikilambda" was the working name for what is now known as "Wikifunctions".)
ウィキメディアのプロジェクト群を3つの場で発展させます。
- 新しい能力の提供先プロジェクトとして、ウィキペディアのローカル版およびその他のクライアント群。
- ウィキデータで、「コンテンツ」(抽象ウィキペディア) を作成。
- 新規プロジェクトで、ウィキファンクションズ、関数ライブラリの作成を目的とする。
ローカルのウィキペディア群向けの展開
個別のローカルのウィキペディアはコミュニティごとに以下の選択肢3件から決定します。
- 絶対的に抽象ウィキペディアと統合。
- 相対的に抽象ウィキペディアと統合。
- 抽象ウィキペディアとの統合はしない。
ローカルのウィキペディア群への展開には次の機能性を伴います。特別ページの新設1件、 新機能2件、マジックワードの追加3件。
F1: 特別ページの新設：Abstract
特別ページをローカルのウィキペディアに新設し、ウィキデータの項目接頭辞付きの Q-ID またはローカルの記事名を使い、オプションで言語指定をします（既定では当該のローカルのウィキペディアの言語）。その特別ページの URL の記述は以下の例を考えています。
https://en.wikipedia.org/wiki/Special:Abstract/Q62https://en.wikipedia.org/wiki/Special:Abstract/Q62/dehttps://en.wikipedia.org/wiki/Special:Abstract/San_Franciscohttps://en.wikipedia.org/wiki/Special:Abstract/San_Francisco/de
もし特別ページの呼び出しに属性を使わないとフォームが表示され、Q-ID と言語を選ばせます（既定の選択肢はでローカルの言語）。
特別ページは指定された Q-ID のコンテンツを表示するか、指定の言語で処理された記事とサイトリンクを張った Q-ID を返します。
F2: 記事の明示的な作成
記事の明示的な作成により、ローカルのウィキペディアが抽象ウィキペディアとの統合を望む場合の流れを紹介します。
投稿者はウィキデータを開き、ターゲットのウィキペディアにまだサイトリンクがない項目を選びます。まだ存在しないページに対してサイトリンクを作成すると、記事の題名が確定します。 一例として英語で Q62 の記事がまだないならサイトリンクもないため、en.wikipedia に対してサイトリンクの San_Francisco を作成するという手順です。
ローカルのウィキペディアではメイン名前空間に仮想の記事を生成します。その記事は上記の特別ページで配布するものと内容は同じでも、生成する場所は通常の URL を当てます。
つまりその記事へのリンクは、（生成により）新しく付いた名前が使えるため他のリンクと見た目は同じで（訳注：前述の例を使うなら）[[San Francisco]] と書くと、リンク先に仮想の記事があるため青リンクになるなどです。その仮想の記事も索引に拾い、当該のウィキペディア、あるいは外部の検索エンジンが使えるようにします。
仮想記事の編集ボタンを押すと（訳注：選択肢が複数あり）、ウィキデータへ進んで抽象的なコンテンツContentを編集する（推奨）、もしくはローカルの言語でゼロから新規記事を書き起こす、または現行の訳文をそのままテキスト化してから、ローカルで編集をするか選べます。
もしローカルにあるサイトリンクを含む記事を削除すると、仮想記事が自動生成されます（記事名は既知でありリンクもわかっているから）。
仮想記事を削除するには、ウィキデータからサイトリンクを除去する必要があります。
ローカルのウィキペディアの改変は明確に行うべきで、だからこそこれを絶対的な記事生成のオプションと名付けました。ローカルのウィキペディア群でこれを既定の方法にするつもりで、コミュニティが相対的な記事作成を選ぶか、もしくは統合を選ばない場合は除外します。
関連項目としてこちらの統合に関するトークページも参照してください。
F3: 記事の黙示的な作成
ウィキデータに基づく記事の黙示的な作成に同意する場合、ローカルのウィキペディアでは関数の特別ページからウィキデータの全項目を呼び出すと、指定のウィキデータとのサイトリンクが欠けたものを指定の言語でコンテンツに書き出し、メインの名前空間に存在すると仮想して索引化します。すると検索をかけたとき、メインの名前空間にあると仮想して対象になります。
通常の記事から仮想の記事へのリンクには、新しいマジックワードを導入し、例は F6 LINK_TO_Qを参照してください。ビジュアルなエディタには不可視的に統合が可能です。
これはコミュニティがほとんど手間をかけずに新規記事を増やす方法であり、小規模コミュニティにはよい選択肢かもしれません。
F4: リンクまたはタブ
ローカルのウィキペディアでは、ウイキデータ項目へのリンクが張ってある記事は全て新規にリンクが渡され、ページ上部のタブまたはページ横のサイドバーにリンクが表示されます。するとそのリンクは結ばれた先のウィキデータ項目のコンテンツをローカルの言語で表示します。仮想記事にはこのタブが表示されないものの、編集ボタンを押すと抽象ウィキペディアのコンテンツを直接、改変することになります。
F5: マジックワードの新設：ABSTRACT_WIKIPEDIA
このページとサイトリンクで結ばれた Wikidata 項目のコンテンツContent を処理 Rendering したとき、ウィキ文とマジックワードが置換されます。
マジックワードの使用には、さらに選択できる属性が2件あり、Q-ID と 言語を選べます。Q-ID を示さない場合は既定でサイトリンクを参照して項目Item を選び、Q-ID が決まります。言語を示さない場合は、既定で当該のウィキの言語版と同じになります。
呼び出しの例:
{{ABSTRACT_WIKIPEDIA}}{{ABSTRACT_WIKIPEDIA:Q62}}{{ABSTRACT_WIKIPEDIA:Q62/de}}
Q-ID が無指定もしくは既定の場合、エラーメッセージを表示。
のちにこれはコンテンツ Contents から名前付きの節を選択可能にします。
もし抽象ウィキペディアとの統合を選ばなかった場合でも、個別のウィキペディアからこの新しいマジックワードを利用できます。
ご留意点として、マジックワードの導入はまだ設計段階にあるという点です。それを導入しなくても同じ機能が実現できるかどうか、タスク 2.3 で精査する予定です。
F6: マジックワードの新設：LINK_TO_Q
このマジックワードは指定の Q-ID とサイトリンクのあるローカルの記事へ、あるいはサイトリンクがないときは指定の Q-ID に対する関数特別ページへリンクを返します。すると記事を書くときに仮想記事へのリンクか使えて、ローカルのコンテンツを新規保存すると自動的に置換されます。
呼び出しの例:
{{LINK_TO_Q:Q62}}
出力
[[San Francisco]]
既存の記事がある場合の出力
[[Special:Abstract/Q62|San Francisco]]
ご留意点として、マジックワードの導入はまだ設計段階にあるという点です。それを導入しなくても同じ機能が実現できるかどうか、タスク 2.3 で精査する予定です。
F7: マジックワードの新設：LAMBDA
これはウィキデータに規定される関数を引数ごと呼び出し、出力結果をページに表示します。
たとえば、次の呼び出し：
{{LAMBDA:capitalize("san francisco")}}
will result in “San Francisco” being outputted on the page (assuming that there is a function that has the local key and with the expected definition and implementation). It uses the language of the local wiki to parse the call.
Consider also the option to call a specific version of a function in order to reduce breakages downstream.
ご留意点として、マジックワードの導入はまだ設計段階にあるという点です。それを導入しなくても同じ機能が実現できるかどうか、タスク 2.3 で精査する予定です。
ウィキデータへの展開
ウィキデータのメイン名前空間には、新規に付属の名前空間を設け、www.wikidata.org/wiki/Q62 形式の項目ページごとにコンテンツ Content ページ www.wikidata.org/wiki/Content:Q62 が付与されます。そのページは抽象的な、言語に中立なコンテンツ Content を載せてあり、編集も管理もできます。
特別ページは他にも必要かもしれません。プロジェクトの第2段階で検討する予定です。ウィキデータのコミュニティから、抽象的なコンテンツの保存先として使う同意を得る必要があり、もし反対された場合には別のプロジェクトを選ぶことになります。
F8: 名前空間の新設：Content
新しい名前空間では、複雑に相互作用のある編集機能を多数用意します。コンテンツ作成と管理用のUXに加え、コンテンツの査読用機能（単言語での閲覧回数など）を提供。主にF11 Function 名前空間の機能のサブセットで構成します。
F9: 新しいデータタイプ：Content
新しいデータタイプには（簡略な）コンテンツがあります。主な使用事例は語彙素のSensesの用語集ならびに項目の説明です。
F10: Sensesの項目と用語集は索引と使用法の解説の対象
項目の解説フィールドと語義の注解に索引付をして線形構造を明示し、項目の解説フィールドではラベル／解説のペアに重複がないよう検知します。いずれも手動で上書きを認めます。
他のウィキメディアのプロジェクト群への展開
マジックワードのF7 LAMBDAとF5 ABSTRACT_WIKIPEDIA限定で配備し、他のウィキメディアのプロジェクト群では他の機能は無用と判断して導入対象外です。この原則は当該のコミュニティのご要望により変わることがあります。
新規の関数ウィキの展開
ウィキファンクションズはウィキメディアの新規プロジェクトとしてドメインを新設します。またウィキラムダ のメインの名前空間は新規に Function 名前空間とします。ウィキファンクションズのその他はウィキメディアのウィキの定型に従います。
F11: 名前空間の新設：Function
Allowing for the storage of functions, types, interfaces, values, tests, etc. There is a single namespace that contains constants (such as types or single values), function interfaces, function implementations, and thus also Constructors and Renderers. The entities in this namespace are named by Z-IDs, similar to Q-IDs of Wikidata items, but starting with a Z and followed by a number.
Z名前空間には多数の様々な種別のエンティティがあります。これらは、正数の引数を持つ旧来の関数と同様、種別と他の制約(基本的に引数の無い関数)を含みます。
貢献者は Function 名前空間内に関数の種別を新規作成して使うことができます。
関数は引数を持てます。引数を与えられた関数は実行して関数の定義により与えられた種別の値を結果で返します。
The Function namespace is complex, and will have very different views depending on the type of the function, i.e. for interfaces, implementations, tests, types, values, etc. there will be different UX on top of them, although they are internally all stored as Z-Objects. Eventually, the different views are all generated by functions in Wikifunctions.
It will be possible to freeze and thaw entities in the Function namespace. This is similar to a protected page, but only restricts the editing of the value part of the entity, not the label, description, etc.
F12: 特別ページの新設と API 新モジュール
New Special pages and API modules will be created to support the new Function namespace. This will include, in particular, a special page and an API module that allows to evaluate functions with function parameters given. Besides that it will include numerous special pages and APIs that will support the maintenance of the content (such as searches by number and types of parameters, pages with statistics of how often certain implementations are called, test pages, etc.). The goal is to implement as many as possible of these inside Wikifunctions.
開発は2段階に分かれます。P1 段階はウィキファンクションズを立ち上げて走らせ、P2 段階で必要なコンテンツ作成を支援できるレベルへ開発します。P2 段階はウィキデータ内でコンテンツ作成を実現する準備を扱い、そのコンテンツにウィキペディア群からアクセスできるようにします。 それが済むと継続的な開発により、ウィキファンクションズと抽象ウィキペディアの両方を改善します。ただし、継続開発はこの計画の範囲外です。留意点は、どの日程も私たちがどれだけの人数を集めるかに左右されることです。
In the first year, we will work exclusively on Part P1. Part P2 starts with the second year and adds additional headcount to the project. Parts P1 and P2 will then be developed in parallel for the next 18 months. Depending on the outcome and success of the project, the staffing of the further development has to be decided around month 24, and reassessed regularly from then on.
This plan covers the initial 30 months of development. The main deliverables after that time will be:
- Wikifunctions, a new WMF project and wiki, with its own community, and its own mission, aiming to provide a catalog of functions and allow everyone to share in that catalog, thus empowering people by democratizing access to computational knowledge.
- A cross-wiki repository to share templates and modules between the WMF projects, which is a long-standing wish by the communities. This will be part of Wikifunctions.
- Abstract Wikipedia, a cross-wiki project that allows to define Content in Wikidata, independently of a natural language, and that is integrated in several local Wikipedias, considerably increasing the amount of knowledge speakers of currently underserved languages can share in.
Part P1: Wikifunctions
Task P1.1: Project initialization
We will set up Wikipages on Meta, bug components, mailing lists, chat rooms, an advisory board, and other relevant means of discussion with the wider community. We will start the discussion on and decide on the names for Wikifunctions and Abstract Wikipedia, and hold contests for the logos, organize the creation of a code of conduct, and the necessary steps for a healthy community.
We also need to kick off the community process of defining the license choice for the different parts of the project: abstract Content in Wikidata, the functions and other entities in Wikifunctions, as well as the legal status of the generated text to be displayed in Wikipedia. This needs to be finished before Task P1.9. This decision will need input from legal counsel.
Task P1.2: Initial development
The first development step is to create the Wikifunctions wiki with a Function namespace that allows the storage and editing of Z-Objects (more constrained JSON objects - in fact we may start with the existing JSON extensions and build on that). The initial milestone aims to have:
- The initial types: unicode string, positive integer up to N, boolean, list, pair, language, monolingual text, multilingual text, type, function, builtin implementation, and error.
- An initial set of constants for the types.
- An initial set of functions: if, head, tail, is_zero, successor, predecessor, abstract, reify, equal_string, nand, constructors, probably a few more functions, each with a built-in implementation.
This allows to start developing the frontend UX for function calls, and create a first set of tools and interfaces to display the different types of Z Objects, but also generic Z Objects. This also includes a first evaluator that is running on Wikimedia servers.
Note that the initial implementations of the views, editing interfaces, and validators are likely to be thrown away gradually after P1.12 once all of these are becoming internalized. To internalize some code means to move it away from the core and move it into userland, i.e. to reimplement them in Wikifunctions and call them from there.
Task P1.3: Set up testing infrastructure
Wikifunctions will require several test systems. One to test the core, one to test the Web UI, one to test the Wikifunctions content itself. This is an ongoing task and needs to be integrated with version control.
Task P1.4: Launch public test system
We will set up a publicly visible and editable test system that runs the bleeding edge of the code (at least one deploy per working day). We will invite the community to come in and break stuff. We may also use this system for continuous integration tests.
Task P1.5: Server-based evaluator
Whereas the initial development has created a simple evaluator working only with the built-ins, and thus having very predictable behavior, the upcoming P1.6 function composition task will require us to rethink the evaluator. The first evaluator will run on Wikimedia infrastructure, and needs monitoring and throttling abilities, and potentially also the possibility to allocate users different amounts of compute resources depending on whether they are logged-in or not.
Task P1.6: Function composition
We allow for creating new function interfaces and a novel type of implementation, which are composed function calls. E.g. it allows to implement
add(x, y)
as
if(is_zero(y), x, add(successor(x), predecessor(y))
and the system can execute this. It also allows for multiple implementations.
Task P1.7: Freeze and thaw entities
A level of protection that allows to edit the metadata of an entity (name, description, etc.), but not the actual value. This functionality might also be useful for Wikidata. A more elaborate versioning proposal is suggested here.
Task P1.8: Launch beta Wikifunctions
The beta system runs the next iteration of the code that will go on Wikifunctions with the next deployment cycle, for testing purposes.
Task P1.9: Launch Wikifunctions
Pass security review. Set up a new Wikimedia project. Move some of the wikipages from Meta to Wikifunctions.
Task P1.10: Test type
Introduce a new type for writing tests for functions. This is done by specifying input values and a function that checks the output. Besides introducing the Test type, Functions and Implementations also have to use the Tests, and integrate them into Implementation development and Interface views.
Task P1.11: Special page to write function calls
We need a new Special page that allows and supports to write Function calls, with basic syntax checking, autocompletion, documentation, etc. A subset of this functionality will also be integrated on the pages of individual Functions and Implementations to run them with more complex values. This Special page relies on the initial simple API to evaluate Function calls.
Task P1.12: JavaScript-based implementations
We allow for a new type of Implementations, which are implementations written in JavaScript. This requires to translate values to JavaScript and back to Z-Objects. This also requires to think about security, through code analysis and sandboxing, initially enriched by manual reviews and P1.7 freezing. If the O1 lambda-calculus has not yet succeeded or was skipped, we can also reach the self-hosting for Wikifunctions through this task, which would allow to internalize most of the code.
Task P1.13: Access functions
Add F7 the Lambda magic word to the Wikimedia projects which can encode function calls to Wikifunctions and integrate the result in the output of the given Wikimedia project. This will, in fact, create a centralized templating system as people realize that they can now reimplement templates in Wikifunctions and then call them from their local Wikis. This will be preceded by an analysis of existing solutions such as TemplateData and the Lua calls.
This might lead to requests from the communities to enable the MediaWiki template language and Lua (see P1.15) as a programming language within Wikifunctions. This will likely lead to requests for an improved Watchlist solution, similar to what Wikidata did, and to MediaWiki Template-based implementations, and other requests from the community. In order to meet these tasks, an additional person might be helpful to answer the requests from the community. Otherwise P2 might start up to a quarter later. This person is already listed in the development team above.
Task P1.14: Create new types
We allow for the creation of new types. This means we should be able to edit and create new type definitions, and internalize all code to handle values of a type within Wikifunctions. I.e. we will need code for validating values, construct them, visualize them in several environments, etc.. We also should internalize these for all the existing types.
Task P1.15: Lua-based implementations
We add Lua as a programming language that is supported for implementations. The importance of Lua is due to its wide use in the MediaWiki projects. Also, if it has not already happened, the value transformation from Wikifunctions to a programming language should be internalized at this point (and also done for the JavaScript implementations, which likely will be using built-ins at this point).
Task P1.16: Non-functional interfaces
Whereas Wikifunctions is built on purely functional implementations, there are some interfaces that are naively not functional, for example random numbers, current time, autoincrements, or many REST calls. We will figure out how to integrate these with Wikifunctions.
Task P1.17: REST calls
We will provide builtins to call out to REST interfaces on the Web and ingest the result. This would preferably rely on P1.16. Note that calling arbitrary REST interfaces has security challenges. These need to be taken into account in a proper design.
Task P1.18: Accessing Wikidata and other WMF projects
We will provide Functions to access Wikidata Items and Lexemes, and also other content from Wikimedia projects. This will preferably rely on P1.17, but in case that didn’t succeed yet at this point, a builtin will unblock this capability.
Task P1.19: Monolingual generation
The development of these functions happens entirely on-wiki. This includes tables and records to represent grammatical entities such as nouns, verbs, noun phrases, etc., as well as Functions to work with them. This includes implementing context so that we can generate anaphors as needed. This allows for a concrete generation of natural language, i.e. not an abstract one yet.
Part P2: Abstract Wikipedia
The tasks in this part will start after one year of development. Not all tasks from Part P1 are expected to be finished before Part P2 can begin, as, in fact, Parts P1 and P2 will continue to be developed in parallel. Only some of the tasks in Part P1 are required for P2 to start.
Task P2.1: Constructors and Renderers
Here we introduce the abstract interfaces to the concrete generators developed in P1.19. This leads to the initial development of Constructors and the Render function. After this task, the community should be able to create new Constructors and extend Renderers to support them.
- Constructors are used for the notation of the abstract content. Constructors are language independent, and shouldn't hold conditional logic.
- Renderers should hold the actual conditional logic (which gets applied to the information in the Constructors). Renderers can be per language (but can also be shared across languages).
- The separation between the two is analogous to the separation in other NLG systems such as Grammatical Framework.
Task P2.2: Conditional rendering
It will rarely be the case that a Renderer will be able to render the Content fully. We will need to support graceful degradation: if some Content fails to render, but other still renders, we should show that part that rendered. But sometimes it is narratively necessary to render certain Content only if other Content will definitely be rendered. In this task we will implement the support for such conditional rendering, that will allow smaller communities to grow their Wikipedias safely.
Task P2.3: Abstract Wikipedia
Create a new namespace in Wikidata and allow Content to be created and maintained there. Reuse UI elements and adapt them for Content creation. The UI work will be preceded by Design research work which can start prior to the launch of Part P2. Some important thoughts on this design are here. This task will also decide whether we need new magic words (F5, F6, and F7) or can avoid their introduction.
Task P2.4: Mobile UI
The creation and editing of the Content will be the most frequent task in the creation of a multilingual Wikipedia. Therefore we want to ensure that this task has a pleasant and accessible user experience. We want to dedicate an explicit task to support the creation and maintenance of Content in a mobile interface. The assumption is that we can create an interface that allows for a better experience than editing wikitext.
Task P2.5: Integrate content into the Wikipedias
Enable the Abstract Wikipedia magic word. Then allow for the explicit article creation, and finally the implicit article creation (F1, F2, F3, F4, F5, F6).
Task P2.6: Regular inflection
Wikidata’s Lexemes contain the inflected Forms of a Lexeme. These Forms are often regular. We will create a solution that generates regular inflections through Wikifunctions and will discuss with the community how to integrate that with the existing Lexemes.
Task P2.7: Basic Renderer for English
We assume that the initial creation of Renderers will be difficult. Given the status of English as a widely used language in the community, we will use English as a first language to demonstrate the creation of a Renderer, and document it well. We will integrate the help from the community. This also includes functionality to show references.
Task P2.8: Basic Renderer for a second language
Based on the community feedback, interests, and expertise of the linguists working on the team, we will select a second large language for which we will create the basic Renderer together with the community. It would be interesting to choose a language where the community on the local Wikipedia has already confirmed their interest to integrate Abstract Wikipedia.
Task P2.9: Renderer for a language from another family
Since it is likely that the language in P2.8 will be an Indo-European language, we will also create a basic Renderer together with the community for a language from a different language family. The choice of this language will be done based on the expertise available to the team and the interests of the community. It would be interesting to choose a language where the community on the local Wikipedia has already confirmed their interest to integrate Abstract Wikipedia.
Task P2.10: Renderer for an underserved language
Since it is likely that the languages in P2.8 and P2.9 will be languages which are already well-served with active and large Wikipedia communities, we will also select an underserved language, a language that currently has a large number of potential readers but only a small community and little content. The choice of this language will be done based on the expertise available to the team and the interests of the community. Here it is crucial to select a language where the community on the local Wikipedia has already committed their support to integrate Abstract Wikipedia.
Task P2.11: Abstract Wikidata Descriptions
Wikidata Descriptions seem particularly amenable to be created through Wikifunctions. They are often just short noun phrases. In this task we support the storage and maintenance of Abstract Descriptions in Wikidata, and their generation for Wikidata. We also should ensure that the result of this leads to unique combinations of labels and descriptions.
See Abstract Wikipedia/Updates/2021-07-29 for further details and discussion.
Task P2.12: Abstract Glosses
Wikidata Lexemes have Senses. Senses are captured by Glosses. Glosses are available per language, which means that they are usually only available in a few languages. In order to support a truly multilingual dictionary, we are suggesting to create Abstract Glosses. Although this sounds like it should be much easier than creating full fledged Wikipedia articles, we think that this might be a much harder task due to the nature of Glosses.
Task P2.13: Support more natural languages
Support other language communities in the creation of Renderers, with a focus on underserved languages.
Task P2.14: Template-generated content
Some Wikipedias currently contain a lot of template-generated content. Identify this content and discuss with the local Wikipedias whether they want to replace it with a solution based on Wikifunctions, where the template is in Wikifunctions and the content given in the local Wikipedia or in Abstract Wikipedia. This will lead to more sustainable and maintainable solutions that do not require to rely on a single contributor. Note that this does not have to be multilingual, and might be much simpler than going through full abstraction.
Task P2.15: Casual comments
Allow casual contributors to make comments on the rendered text and create mechanisms to capture those comments and funnel them back to a triage mechanism that allows to direct them to either the content or the renderers. It is important to not lose comments by casual contributors. Ideally, we would allow them to explicitly overwrite a part of the rendered output and consider this a change request, and then we will have more involved contributors working on transforming the intent of the casual contributor to the corresponding changes in the system.
Task P2.16: Quick article name generation
The general public comes to Wikipedia mostly by typing the names of the things they are looking for in their language into common search engines. This means that Wikidata items will need labels translated into a language in order to be able to use implicit article creation. This can probably be achieved by translating millions of Wikidata labels. Sometimes it can be done by bots or AI, but this is not totally reliable and scalable, so it has to involve humans.
The current tools for massive crowd-sourced translation of Wikidata labels are not up to the task. There are two main ways to do it: editing labels in Wikidata itself, which is fine for adding maybe a dozen of labels, but quickly gets tiring, and using Tabernacle, which appears to be more oriented at massive batch translations, but is too complicated to actually use for most people.
This task is to develop a massive and integrated label-translation tool with an easy, modern frontend, that can be used by lots of people.
Non-core tasks
There is a whole set of further optional tasks. Ideally these would be picked up by external communities and developed as Open Source outside the initial development team, but some of these might need to be kickstarted and even fully developed by the core team.
Task O1: Lambda calculus
It is possible to entirely self-host Wikifunctions without relying on builtins or implementations in other programming languages, by implementing a Lambda calculus in Wikifunctions (this is where the name proposal comes from). This can be helpful to allow evaluation without any language support, and so easier start up the development of evaluators.
Task O2: CLI in a terminal
Many developers enjoy using a command line interface to access a system such as Wikifunctions. We should provide one, with the usual features such as autocompletion, history, shell integration, etc.
Task O3: UIs for creating, debugging and tracing functions
Wikifunctions’s goal is to allow the quick understanding and development of the functions in Wikifunctions. Given the functional approach, it should be possible to create a user experience that allows for partial evaluation, unfolding, debugging, and tracing of a function call.
Task O4: Improve evaluator efficiency
There are many ways to improve the efficiency of evaluators, and thus reduce usage of resources, particularly caching, or the proper selection of an evaluation strategy. We should spend some time on doing so for evaluators in general and note down the results, so that different evaluators can use this knowledge, but also make sure that the evaluators maintained by the core team use most of the best practises.
Task O5: Web of Trust for implementations
In order to relax the conditions for implementations in programming languages, we could introduce a Web of Trust based solution, that allows contributors to review existing implementations and mark their approval explicitly, and also to mark other contributors as trustworthy. Then these approvals could be taken into account when choosing or preparing an evaluation strategy.
Task O6: Python-based implementations
Python is a widely used programming language, particularly for learners and in some domains such as machine learning. Supporting Python can open a rich ecosystem to Wikifunctions.
Task O7: Implementations in other languages
We will make an effort to call out to other programming language communities to integrate them into Wikifunctions, and support them. Candidates for implementations are Web Assembler, PHP, Rust, C/C++, R, Swift, Go, and others, but it depends on the interest of the core team and the external communities to create and support these interfaces.
Task O8: Web-based REPL
A web-based REPL can bring the advantages of the O2 command line interface to the Web, without requiring to install a CLI in a local environment, which is sometimes not possible.
Task O9: Extend API with Parser and Linearizer
There might be different parsers and linearizers using Wikifunctions. The Wikifunctions API can be easier to use if the caller could explicitly select these, instead of wrapping them manually, which would allow the usage of Wikifunctions with different surface dialects.
Task O10: Support talk pages
In order to support discussions on talk pages of Wikifunctions, develop and integrate a mechanism that allows for (initially) simple discussions, and slowly raising their complexity based on the need of the communities.
Task O11: Legal text creation
An interesting application of Wikifunctions is for the creation of legal text in a modular manner and with different levels (legalese vs human-readable), similar to the different levels of description for the different Creative Commons licenses.
Task O12: Health related text creation
An interesting application of Wikifunctions is for the creation of health-related texts for different reading levels. This should be driven by WikiProject Medicine and their successful work, which could reach many more people through cooperation with Wikifunctions.
Task O13: NPM library
We will create a Wikidata library for NPM that allows the simple usage of Functions from Wikifunctions in a JavaScript program. The same syntax should be used to allow JavaScript implementations in Wikifunctions to access other Wikifunctions functions. Note that this can be done by virtue of calling to a Wikifunctions evaluator, or by compiling the required functions into the given code base.
Task O14: Python library
We will create a Python library that allows the simple usage of Functions from Wikifunctions in a Python script. The same syntax should be used to allow Python implementations in Wikifunctions to access other Wikifunctions functions. Note that this can be done by virtue of calling to a Wikifunctions evaluator, or by compiling the required functions into the given code base.
Task O15: Libraries for other programming languages
We will call out to the communities of several programming languages to help us with the creation of libraries that allow the simple call of Wikifunctions functions from programs in their language. Note that this can be done by virtue of calling to a Wikifunctions evaluator, or by compiling the required functions into the given code base.
Task O16: Browser-based evaluator
One of the advantages of Wikidata is that the actual evaluation of a function call can happen in different evaluators. The main evaluator for Abstract Wikipedia will be server-based and run by the Wikimedia Foundation, but in order to reduce the compute load, we should also provide evaluators running in the user’s client (probably in a Worker thread).
Task O17: Jupyter- and/or PAWS-based evaluator
One interesting evaluator is from a Jupyter or PAWS notebook, and thus allowing the usual advantages of such notebooks but integrating also the benefits from Wikifunctions.
Task O18: App-based evaluator
One evaluator should be running natively on Android or iOS devices, and thus allow the user to use the considerable computing power in their hand.
Task O19: P2P-based evaluator
Many of the evaluators could be linking together and allow each other to use dormant compute resources in their network. This may or may not require shields between the participating nodes that ensure the privacy of individual computes.
Task O20: Cloud-based evaluator
One obvious place to get compute resources is by allowing to use a cloud provider. Whereas it would be possible to simply run the server-based evaluator on a cloud-based infrastructure, it is likely to be beneficial for the cloud providers to provide a thinner interface to a more custom-tailored evaluator.
Task O21: Stream type
Add support for a type for streaming data, both as an input as well as an output. Stream types means for example the recent changes stream on a Wikimedia wiki.
Task O22: Binary type
Add support for binary files, both for input and output.
Task O23: Integration with Commons media files
Allow direct access to files on Commons. Enable workflows with Commons that require less deployment machinery than currently needed. Requires O22.
Task O24: Integrate with Machine Learning
Develop a few example integrations with Machine Learning solutions, e.g. for NLP tasks or for work on image or video e.g. using classifiers. This requires how and where to store models, possibly also how to train them, and how to access them.
Task O25: Integrate into IDEs
Reach out to communities developing IDEs and support them in integrating with Wikifunctions, using type hints, documentation, completion, and many of the other convenient and crucial features of modern IDEs.
Task O26: Create simple apps or Websites
Develop a system to allow the easy creation and deployment of apps or Websites relying on Wikifunctions.
Task O27: Display open tasks for contributors
Abstract Wikipedia will require one Renderer for every Constructor for every language. It will be helpful if contributors could get some guidance to which Renderer to implement next, as this is often not trivially visible. Just counting how often a Constructor appears could be a first approximation, but if some Constructors are used more often in the lead, or in parts of the text that block other text from appearing, or in articles that are more read than others, this approximation might be off. In this task we create a form of dashboard that allows users to choose a language (and maybe a domain, such as sports, geography, history, etc., and maybe a filter for the complexity of the renderer that is expected) and then provide them with a list of unrendered Constructors ranked by the impact an implementation would have.
We could also allow contributors to sign up for a regular message telling them how much impact (in terms of views and created content) they had, based on the same framework needed for the dashboard.
This is comparable to seeing the status of translations of different projects on TranslateWiki.Net (for a selectable language), or the views on topics, organizations or authors in Scholia. For each project, it shows what % of the strings in it were translated and what % need update, and a volunteer translator can choose: get something from 98% to 100%, get something from 40% to 60%, get something from 0% to 10%, etc.
Task O28: Active view
Whereas the default view of Rendered content would look much like static text, there should also be a more active view that invites contribution, based on existing Content that failed to render due to missing Renderers. In the simplest case this can be the creation of a Lexeme in Wikidata and connecting to the right Lexeme. In more complex cases that could be writing a Renderer, or offering example sentences as text, maybe using the Casual contribution path described in P2.15. This would provide an interesting funnel to turn more readers in contributors.
There are product and design decisions on how and where the active view should be used and whether it should be the default view, or whether it should be only switched on after an invitation, etc. There could also be mode where contributors can go from article to article and fill out missing pieces, similar to the more abstract way in O27.
It would probably be really useful that ensure that the active way and the contribution path it leads to work on mobile devices as well.
Task O29: Implementation compilation
The function composition used for implementations should allow to create highly performant compilations of rather high-level functions in many different target programming languages, particularly Web Assembler and JavaScript. This should speed up evaluation by several orders of magnitude.
Task O30: Integrate with Code examples on Wikipedia, Wikibooks, etc.
Allow Wikipedia, Wikibooks, and the other projects to integrate their code examples directly with the wiki of functions, so that these can be run live.
Development of Abstract Wikipedia will proceed in two major parts, each consisting of a large number of tasks. Part P1 is about developing the wiki of functions, and Part P2 is about abstract content and natural language generation. On this page, we further break down the tasks of Part P1 into phases that each cover some of the work under a given task. The below contains links to Phabricator, where tasks and phases are broken down even further.
This wiki page might be stale. The canonical place for information about the tasks is Phabricator. Find our current state on Phabricator.
We expect to take about ten phases before launching the wiki of functions.
All the below phases cover work under Task P1.2: Initial development, unless marked otherwise.
Part P1: Wiki of functions
Phase α (alpha): store, display and edit header — 
完了 2020-08-25
- Set up replicable development environment. — タスク「T258893」
- 完了 Start extension. — タスク「T258893」
- 完了 Config works, upload bootstrap content.
- 完了 Reuse existing JSON ContentHandler. — タスク「T258893」
- 完了 Allow for entering JSON objects through the raw editing interface. — タスク「T258893」
- 完了 Extend and hardcode checker for JSON objects to check for ZObject well-formedness. Nothing that is not well-formed will be further handled or stored. Well-formedness should probably be checked both in the PHP and the JS code (should be easy to write anyway).
- 完了 in PHP. — タスク「T258894」
- Well-formedness: key syntax, allowed keys, values are strings or proto-objects or lists of values. — タスク「T258894」
- 完了 Every stored top-level ZObject must be a Z2/Persistent object. — タスク「T258897」
- 完了 Create Z1/Object, offering one key, Z1K1/type.
- 完了 Extend hardcoded validator to check Z1K1/type.
- 完了 Create Z2/Persistent object. — タスク「T258897」
- 完了 Z2/Persistent object has the keys Z2K1/ID and Z2K2/value, and Z2K3/Proto-Label, the latter being counterfactually just a single string with no language information. — タスク「T258897」
- 完了 Extend hardcoded validator for Z2/Persistent object so far. — タスク「T258897」
- 完了 Provide hardcoded display for Z2/Persistent object (that is the header) (that is a pretty big task). — タスク「T258898」
- 完了 Provide generic view for the Z2K2/value object. — タスク「T258898」
- 完了 Turn Z2K3/proto-label into the proper Z2K3/label for multilingual text.
- 完了 Extend viewing for Z2K3/label with multilingual text.
Phase completion condition: As a user [of a site with the MediaWiki extension installed], I can create and store a string as a new ZObject, e.g. "Hello world!".
Phase β (beta): create types and instances — 完了 2021-02-04
- 完了 Hardcoded validators for Z4/proto-types and Z3/proto-keys. — タスク「T258900」
- A Z4 has a Z4K2/keys with a json List of Z3s.
- A proto-key has a Z3K1/ID and Z3K2/type and Z3K3/label (mirror the development of label for Z2K3?).
- 完了 Create Z4/Type and Z3/Key (Task P1.14).
- 完了 Search for ZObjects by label. — タスク「T260750」
- 完了 Use Z4 type data and key declarations for validating objects. — タスク「T260861」
- 完了 Use Z4 type data and key declarations for generic view of objects. — タスク「T258901」
- 完了 Use Z4 type data and key declarations for editing and creation of objects. — タスク「T258903」 & タスク「T258904」
- 完了 Provide hardcoded display and edit interface for Z12 type. — タスク「T258900」
Phase completion condition:
As a user, I can create and store an object implementing any on-wiki defined type, e.g. the positive integer one
Phase γ (gamma): functions, implementations, errors — 完了 2021-04-02
- 完了 Introduce a simple error object. — タスク「T261464」
- 完了 Introduce simple function. — タスク「T258957」
- 完了 Introduce simple implementation, for now only built-ins. — タスク「T258958」
- 完了 Create a few functions and built-ins. — タスク「T261474」
- 完了 Introduce a simple function call type. — タスク「T261467」
- 完了 Tester type (Task P1.10). — タスク「T261465」
Phase completion condition: As a user, I can store a function call, a function, and a tester (only the objects, no actual evaluation yet), e.g. if(true, false, true) (read "if true then false else true", i.e. negation)
Phase δ (delta): built ins — 完了 2021-05-11
- 完了 Evaluation system for built-ins. — タスク「T260321」
- 完了 Enable web users to call evaluation through an API module (Task P1.5). — タスク「T261475」
- 完了 Special page for calling evaluation (Task P1.11). — タスク「T261471」
Phase completion condition: As a user, I can use a special page to evaluate a built-in function with supplied inputs, e.g. to check whether the empty list is empty.
Phase ε (epsilon): native function calls — 完了 2021-06-30
- 完了 JavaScript implementations (Task P1.12). — タスク「T275944」
- 完了 Python implementations (Task O6). — タスク「T273517」
- 完了 Allow forms to be included for evaluation. — タスク「T261472」
Phase completion condition: As a user, I can use a special page to evaluate a user-written function in one of the supported languages, e.g. call a user-written function in Python to add up two numbers.
Phase ζ (zeta): composition — 完了 2021-08-27
- 完了 Allow for composition implementations (Task P1.6). — タスク「T261468」
Phase completion condition:
- As a user, I can implement a function using composition of other functions, rather than writing it myself, e.g.
negate(Boolean → Boolean). — 完了 - (Stretch condition) As a user, I can see the results of testers on the relevant function implementation's page. [This might need to be moved to a later phase as not all requirements may be met this point. Must be done by phase ι.] — 完了
Phase η (eta): generic types — 完了 2022-04-08
- 完了 Allow for generic types, particularly for Z10/List and Z8/Function, and replace Z10/List and Z8/Function. ― タスク「T275941」
- 完了 Errors can be processed like ZObjects.
- 完了 User-defined types work with validators.
Phase completion condition:
- Being able to implement
curryas a composition on the wiki, but without requiring strict static analysis — 完了 - Making it possible to create the following three 'user-defined' types on the wiki:
positive integer,sign, andinteger— 完了 - Being able to make a generic wrapper type through composition on the wiki — 完了
See also the newsletter posted about this phase.
Phase θ (theta): thawing and freezing — 完了 2023-06-19
- 完了 Freezing and thawing content (Task P1.7). ― タスク「T275942」
- 完了 Task P1.9: Pass security review. — タスク「T274682」, …
- 完了 Launch public test system (Task P1.4). — タスク「T261469」
Phase completion condition:
- As a sysop, I can freeze and unfreeze any user-written object (akin to, or maybe the same as, MediaWiki's protection system); all system-supplied objects are permanently frozen.
- As a user editing a frozen page, I can change the label, but not the implementation, whereas on an unfrozen page both are possible.
- ZObjects are stored using the new canonical form for typed lists, and all parts are still working
- View and edit function is implemented and tested successfully
- When several implementations are available, the "best" is chosen. (Fitness determination to potentially be changed later.)
- We measure the clock time & memory use of each function run, and display it on the execution result & in the implementation/test table.
- Edits to system-defined ZObjects are restricted to users with the correct rights. Understandable diffs are emitted. Results are cached.
- Text with fallback, references, strings, lists is implemented and tested successfully
- A shared understanding with the community of how the team will contribute to Wikifunctions, and why, is documented
- Designs for viewing and editing multi-lingual documentation on mobile and desktop are approved. UX is instrumented and data collected.
Phase ι (iota): documentation of objects
- This is a preliminary assignment, moving the documentation tasks here.
- Provide editing for the header (additionally to full raw editing) (that is a pretty big task) — this refers only to the labels, actually.
- Extend editing for Z2K3/label with multilingual text.
- Extend the header with Z2K4/documentation. — タスク「T260954」 & タスク「T260956」
- Extend editing to deal with Z2K4/documentation. — タスク「T260955」
Phase completion condition: As a user, I can document a ZObject in any and all supported languages, using a wikitext.
Phase κ (kappa): cleanup
- Tightening up and clean up tasks, to close all pre-launch tasks.
Phase completion condition: As the Abstract Wikipedia Team, we feel ready for launch, including sign-off from all relevant colleagues.
Phase λ (lambda): launch
- Phase λ (lambda) is meant for launch. If there are pre-launch tasks that prevent that, so be it, obviously.
- Set up a new Wikimedia project.
- Move some of the wiki pages about the project from Meta to Wikifunctions.
Phase completion condition: As a person on the Web, I can visit and use Wikifunctions.org to write and run functions directly on the site.
Unphased tasks
Pre-launch tasks that need to happen but are not phased in yet: