Abstract Wikipedia/Architecture/tr

This is part of the development plan for a wiki of functions.

Continues from Requirements for the wiki of functions.

The main components of the project are the following three:

1. Constructors – definitions of Constructors and their slots, including what they mean and restrictions on the types for the slots and the return type of the Constructor (e.g. define a Constructor rank that takes in an item, an item type, the ranking as a number, what it is ranked by, and a local constraint)
2. Content – abstract calls to Constructors including fillers for the slots (e.g. rank(SanFrancisco, city, 4, population, California))
3. Renderers – functions that take Content and a language and return a text, resulting in the natural language representing the meaning of the Content (e.g. in the given example it results in “San Francisco is the fourth largest city by population in California.”)

There are four main possibilities on where to implement the three different main components:

1. Constructors, Content, and Renderers are all implemented in Wikidata.
2. Constructors and Renderers are implemented in Wikifunctions, and the Content in Wikidata, next to the corresponding Item.
3. Constructors, Content, and Renderers are all implemented in Wikifunctions.
4. Constructors and Content are implemented in Wikidata, and the Renderers in the local editions of Wikipedia.

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.

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