Абстрактна Вікіпедія/Архітектура

Це — частина плану розробки для вікі функцій.

Продовження Вимог до wiki функцій.

Основними компонентами проєкту є такі три:

1. Конструктори (Constructors) — означення Конструкторів та їх слотів, включаючи те, що вони означають, і обмеження на типи для слотів та тип, що повертається конструктором (приклад — означення конструктора rank, який отримує елемент, тип елемента, ранг як число, те, за чим він класифікується, та локальне обмеження)
2. Контент (Content) — абстрактні виклики Конструкторів, включаючи наповнення слотів (наприклад, rank(SanFrancisco, city, 4, population, California))
3. Візуалізатори (Renderers) — функції, які отримують Контент і мову та повертають текст, який відображає заданою природною мовою значення Контенту (наприклад, у наведеному прикладі повертає для англійської мови “San Francisco is the fourth largest city by population in California.”)

Є чотири основні можливості для реалізації трьох різних основних компонентів:

1. Конструктори, Контент і Візуалізатори повністю реалізовані у Вікіданих.
2. Конструктори і Візуалізатори реалізовані у Вікіфункціях, а Контент — у Вікіданих разом із відповідним Елементом.
3. Конструктори, Контент і Візуалізатори повністю реалізовані у Вікіфункціях.
4. Конструктори та Контент реалізовані у Вікіданих, а Візуалізатори — у локальних версіях Вікіпедії.

Рішення 4 має той недолік, що багато функцій можна використовувати для різних мов, але переміщуючи Візуалізатори та функції до локальних Вікіпедій, ми втрачаємо таку можливість. Крім того, переміщаючи Візуалізатори до локальних Вікіпедій, ми втрачаємо потенціал, який може досягти незалежний каталог функцій.

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.

(The components named in italics are to be added by this proposal, the components in bold already exist. Top level boxes are Wikimedia projects, inner boxes are parts of the given Wikimedia projects.) ("Wikilambda" was the working name for what is now known as "Wikifunctions".)

Continued in Components of the wiki of functions.