The on-wiki version of this week's newsletter is available here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-06-30
--
When we started the development effort towards the Wikifunctions site, we
subdivided the work leading up to the launch of Wikifunctions into eleven
phases
<https://meta.wikimedia.org/wiki/Special:MyLanguage/Abstract_Wikipedia/Phases>,
named after the first eleven letters of the Greek alphabet.
- With Phase α (alpha) completed, it became possible to create instances
of the system-provided Types in the wiki.
- With Phase β (beta), it became possible to create new Types on-wiki
and to create instances of these Types.
- With Phase γ (gamma), all the main Types of the pre-generic function
model
<https://meta.wikimedia.org/wiki/Special:MyLanguage/Abstract_Wikipedia/Pre-g…>
were
available.
- With Phase δ (delta). It became possible to evaluate built-in
implementations
<https://meta.wikimedia.org/wiki/Special:MyLanguage/Abstract_Wikipedia/Updat…>
.
- This week, we completed Phase ε (epsilon).
The goal of Phase ε has been to provide the capability to evaluate
contributor-written implementations in a programming language.
What does this mean? Every function in Wikifunctions can have several
implementations. There are three different ways to express an
implementation:
1. As a *built-in* function, written by the development team: this means
that the implementation is handled by the evaluator as a black box.
2. As *code* in a programming language, created by the contributors of
Wikifunctions: the implementation of a function can be given in any
programming language that Wikifunctions supports. Eventually we aim to
support a large number of programming languages, but we will start small.
3. As a *composition* of other functions: this means that contributors
can use existing functions as building blocks in order to implement new
capabilities.
In Phase ε, we extended the infrastructure for evaluating functions to
allow for the running of contributed code in addition to the built-ins from
Phase δ. For now, we support two programming languages: JavaScript
<https://en.wikipedia.org/wiki/JavaScript> and Python
<https://en.wikipedia.org/wiki/Python_(programming_language)>. We plan to
add more programming languages (most familiar to the Wikimedia community,
Lua <https://en.wikipedia.org/wiki/Lua_(programming_language)>) and we will
document a process for requesting the support of additional programming
languages. We implemented the planned architecture
<https://www.mediawiki.org/wiki/Extension:WikiLambda#Architectural_concept>:
<https://meta.wikimedia.org/wiki/File:Wikifunctions_-_Top-level_architectura…>
<https://meta.wikimedia.org/wiki/File:Wikifunctions_-_Top-level_architectura…>
Wikifunctions top-level architectural model
We have now a system where the orchestrator receives the function call to
be evaluated, gathers all necessary data from Wikifunctions and potential
other resources, and then chooses the corresponding evaluators that can run
the given programming language. Since this is contributor-created code, we
are very careful about where and how to run the code, and which
capabilities to give to the virtual machine that runs the code. For
example, no network access and no persistence layer is allowed, in order to
reduce the potential for security issues.
A security review and a separate performance review of our architecture and
implementation are currently ongoing. Once we have dealt with the most
pressing issues that are uncovered by the reviews, we plan to provide a
demonstration system. This will probably be in the next Phase.
The next screenshot shows us an implementation of the Function
“Concatenate”. A concatenate
<https://en.wikipedia.org/wiki/Concatenation> function
takes two strings as its arguments and returns a single string consisting
of the two input strings joined end-to-end. Our implementation uses
JavaScript’s native concat method, which is provided by JavaScript’s string
object.
<https://meta.wikimedia.org/wiki/File:Wikilambda_Phase_%CE%B5_Code.png>
<https://meta.wikimedia.org/wiki/File:Wikilambda_Phase_%CE%B5_Code.png>
Screenshot of an implementation in JavaScript
The next screenshot shows the function being called using the arguments
“Wiki“ and “functions”, resulting in the string “Wikifunctions”.
<https://meta.wikimedia.org/wiki/File:Wikilambda_Phase_%CE%B5_Function_Call.…>
<https://meta.wikimedia.org/wiki/File:Wikilambda_Phase_%CE%B5_Function_Call.…>
Screenshot of a function call
We are now moving on to Phase ζ (zeta). The goal of this Phase will be to
allow for the third type of implementations: the composition of functions
in order to build new capabilities. This will also be the first Phase to
really highlight the advantages of our system for contributing
implementations in non-English languages. We have published a few examples
of composed implementations
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Examples/Function_compos…>.
The example implementation of common Boolean functions might be
particularly instructive. Phase ζ is the last of the trilogy of Phases
dealing with the different ways to create an implementation.
During this Phase and subsequent ones, we will also spend some time to
reduce technical debt that we accumulated in rushed development during the
last two phases in order to be ready for the security and performance
reviews. We also expect to begin early changes based on our user research
and design development, replacing the current bare-bones user experience.
Structurally, Phase ζ aims to be the turning point of the development
towards Wikifunctions. It will set us up with a system that is powerful
enough to allow for its own refactoring in order to support generic types
and functions in Phase η (eta), and then to implement monitoring, UX,
security, and documentation. All the core technical capabilities should be
in place by then, and then we will need to add the necessary supporting
systems that will allow us to launch Wikifunctions.
------------------------------
Last week saw the Arctic Knot conference
<https://meta.wikimedia.org/wiki/Arctic_Knot_Conference_2021>, which was
about the future of indigenous and underrepresented languages and their
presence and use on the Wikimedia projects. I want to point to a few talks
that are potentially particularly interesting to the Abstract Wikipedia and
Wikifunctions community:
- Mahir talked on preparing languages for natural language generation
using Wikidata lexicographical data
<https://www.youtube.com/watch?v=f13c3lCghtE&t=27291s>
- Denny gave an introductory presentation on Abstract Wikipedia
<https://www.youtube.com/watch?v=f13c3lCghtE&t=30581s> and suggestions
on what tasks we want to tackle first
- Sadik and Mohammed talked in Dagbani Wikipedia Bachinima
<https://www.youtube.com/watch?v=ee1TaLK3dJE> about challenges and
successes of growing the project, including the Spell4Wiki app
Thanks everyone for attending, presenting at, and organizing the event!
We close with a reminder that there is an invitation to attend for free
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-06-24>
the Grammatical
Framework Summer School <http://school.grammaticalframework.org/2021//> from
26 July to 6 August 2021.
The language committee has approved the creation of the Dagbani language
Wikipedia <https://phabricator.wikimedia.org/T284450>. Dagbani is one of
our focus languages, and has been the only one of the five that has been in
Incubator. Congratulations to the Dagbani community!
Next week there will be no newsletter.
The on-wiki version of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-06-24
--
*Summary*: The Grammatical Framework community is inviting Wikimedians to
participate for free in the GF Summer School 2021. Participation for
Wikimedians will be sponsored by Digital Grammars.
------------------------------
“Grammatical Framework” (GF <https://www.grammaticalframework.org/>) is an
Open Source functional programming language and suite of tools which is
aimed at multilingual natural language generation and parsing of natural
language input. GF was first created in 1998 at Xerox Research in order to
support multilingual document authoring. GF is capable of parsing and
generating texts in several languages simultaneously while working from a
language-independent representation of meaning. GF has an active and lively
community, and offers more than 40 languages.
Here is an example of how GF works (note the syntax has been changed from a
Haskell-like syntax to a functional syntax). Given an abstract
representation such as:
mkUtt(mkS(mkCl(mkNP(aPl_Det, horse_N), mkNP(aPl_Det, animal_N))))
In order to make it a bit easier to understand, here's the terminology
unabbreviated:
make Utterance (make Sentence (make Clause (make Noun Phrase (a Plural
Determiner, horse Noun), make Noun Phrase (a Plural Determiner, animal
Noun))))
Note that this structure in turn could also be abstracted away behind a
function call with a simpler structure:
subsumes(horse_N, animal_N)
One can linearize that abstract representation in several languages. Here
are the results as created by the cloud-based implementation of GF
<https://cloud.grammaticalframework.org/syntax-editor/editor.html> (which
is dated as of 2012 - by now, GF has added support to dozens more
languages):
- Bulgarian: коне са животни
- Chinese: 些 马 是 些 动 物
- Dutch: paarden zijn dieren
- English: horses are animals
- Spanish: caballos son animales
- Swedish: hästar är djur
Let’s make two small changes to the abstract representation: add a negative
polarity to the sentence (negativePol) and switch horse_N with tree_N, and
we get the following representation:
mkUtt(mkS(negativePol, mkCl(mkNP(aPl_Det, tree_N), mkNP(aPl_Det,
animal_N))))
Just as above, this could be hidden behind a function call:
subsumesNot(tree_N, animal_N)
This leads to the following linearizations:
- Bulgarian: дърва не са животни
- Chinese: 些 树 不 是 些 动 物
- Dutch: bomen zijn niet dieren
- English: trees aren't animals
- Spanish: árboles no son animales
- Swedish: träd är inte djur
While the idea for Abstract Wikipedia was developed, GF served as an
important inspiration. It was part of AceWiki
<http://attempto.ifi.uzh.ch/acewiki/>, an extension of MediaWiki that was
integrating tightly with GF and Attempto Controlled English
<https://en.wikipedia.org/wiki/Attempto_Controlled_English> (ACE) in order
to create text in several languages and also to capture the formal
semantics of the text. Whereas in AceWiki one of the main goals was to
express all sentences also in a formal logical language (in that case OWL
<https://www.w3.org/OWL/>), we are less interested in the formal semantics
of the abstract content (in fact, this is one major difference between
Abstract Wikipedia and the many predecessor projects). Other than that you
can see how GF and AceWiki have influenced the development of Abstract
Wikipedia.
Since the announcement of Abstract Wikipedia, the GF developers and
communities have reached out to the Abstract Wikipedia developers, and we
have been discussing
<https://groups.google.com/g/gf-dev/c/A6lNwZ813b0/m/dK8G8pyLAQAJ> our plans
and ideas. In order to further the relationship between the communities and
to transfer experiences and ideas between them, we are very happy to extend
an invitation to the Abstract Wikipedia community: this year’s Grammatical
Framework Summer School will be open and free for all Wikimedians.
At this stage, it is too early to commit ourselves to using GF as the only
approach towards natural language generation in Abstract Wikipedia. There
are alternatives, and Wikifunctions will be malleable enough to support
different approaches. One example for such an alternative is HPSG
<https://en.wikipedia.org/wiki/Head-driven_phrase_structure_grammar>
(Head-driven
phrase structure grammar), which will be presented in the second week of
the summer school. But we plan to learn from the decades of work and
research into GF and the hundreds of person-years that went into its
development, and we also plan to explore whether we can reuse some of the
software or parts of the comprehensive grammar libraries that are part of
GF. In order to facilitate such reuse, it will be crucial to have more
knowledge about each other and better mutual understanding.
The GF Summer School 2021 <https://school.grammaticalframework.org/2021/> will
be held from 26 July to 6 August in Singapore, and it will be possible to
attend online. Registration will be required. *In order to register as a
Wikimedian*, please email inari[image: (_AT_)]digitalgrammars.com, state
your Wikimedia account and your name, your country of residence, the
languages you read and write, and whether you would like to participate for
one or two weeks. This step is required in order to have you avoid the
participation fee—if you sign up yourself, you will need to pay the fee. We
are very thankful to Digital Grammars for covering the fee for Wikimedians.
We are very excited about this collaboration and are looking forward to the
two communities working together and to mutually benefit from each other's
goals, experiences, and skills.
------------------------------
This week also saw our first office hour. We answered a lot of questions,
and you can catch up on the logs
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/Office_hours_202…>.
We plan the next office hour to be in four to six weeks, and will announce
dates also in this newsletter.
Quick reminder: our first office hour is upcoming *in 20 minutes*. It will
be held on the Telegram channel <https://t.me/Wikifunctions> and on
Libera.Chat IRC Channel #wikipedia-abstractconnect
<https://web.libera.chat/?channel=#wikipedia-abstract> (bridged together)
The development team will discuss what they have been working on recently,
and the community is welcome to ask questions and discuss important related
issues.
We hope to see you there! Chat-logs will be available afterwards.
-- Quiddity (WMF)
The on-wiki version of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-06-17
--
Apologies for missing the update last week. Times are even busier than
usual.
Before we dive into today’s topic, two quick reminders: our first office
hour is upcoming on *Tuesday, 22 June 2021, at 16:00 UTC*. It will be held
on the *Telegram* channel and on Libera.Chat IRC Channel #wikipedia-abstract
connect <https://web.libera.chat/?channel=#wikipedia-abstract>.
On *Thursday, 24 June 2021*, we will be presenting at the Arctic Knot
conference <https://meta.wikimedia.org/wiki/Arctic_Knot_Conference_2021>.
Community member Mahir Morshed
<https://meta.wikimedia.org/wiki/User:Mahir256> will present on how to get
the lexicographic data ready to be used in Abstract Wikipedia at *15:00 UTC*,
and Denny <https://meta.wikimedia.org/wiki/User:Denny> will present on
Abstract Wikipedia and Wikifunctions in general at *16:00 UTC*.
------------------------------
Wikifunctions’s core model is centered around functions. Every function can
have several implementations. All implementations of a function should
return the same results given the same inputs.
One may ask: Why? What’s the point of having several implementations that
all do the same?
There are several answers to that. For example, for many functions,
different algorithms exist which could be used by different
implementations. The traditional example in computer science classes is the
sorting function: a sorting function takes two arguments, a list of
elements to be sorted (i.e. to be brought into a specific, linear order),
and a comparator operator that, given two elements, tells us which element
should go first. There are many different sorting algorithms
<https://en.wikipedia.org/wiki/Sorting_algorithm>, any of which could be
used to implement the sorting function. A particularly interesting
visualization of the different sorting algorithms can be found in the form
of traditional folk dances
<https://www.i-programmer.info/programming/theory/3531-sorting-algorithms-as…>
.
The person calling the sorting function will often not care much about
which algorithm is being used, as long as it works, is correct, and returns
sufficiently quickly. But having different algorithms implemented allows
the service to run the different algorithms and compare their runtime
behaviors against each other. Different algorithms will often require
different amounts of memory or computation cycles. Keeping track of the
runtime behavior of the different implementations will eventually allow the
function orchestrator to predict and select the most efficient
implementation for a given input and at a given instant. When spare compute
cycles are available, it can also run some implementations with different
inputs, in order to learn more about the differing behavior of these
implementations.
One benefit of allowing for multiple implementations is that it reduces the
potential for conflicts when editing Wikifunctions. If a contributor wants
to try a different implementation, thinking it might be more efficient,
they are welcome to do so and submit their implementation to the system.
There is no need for the well-known arguments around different programming
languages and their relative merits and qualities to spill over to
Wikifunctions: everyone will be welcome to provide implementations of their
favorite algorithms in their favorite programming languages, and the system
will take care of validating, testing, and selecting the right
implementation automatically.
Another benefit of having multiple implementations is that we can test them
against each other rigorously. Sure, we will have the user-written suite of
testers for an initial correctness check (and also to start collecting
runtime metadata). But when you have several independent implementations of
a function, you can either synthetically create more inputs, or you can run
actual user-submitted function executions against different implementations
to gather more metadata about the executions. Since we have several
implementations, we can use these to cross-validate the different
implementations, compare the results from the different implementations,
and bubble up inconsistencies that arise to the community.
Besides having implementations of different algorithms, we also expect to
have implementations in different programming languages. Implementations in
different programming languages will be useful for the same reasons that
different algorithms are useful, i.e. being able to cross-validate each
other, and to allow for the selection of the most efficient implementation
for a given function call. But they will have the additional advantage of
being able to run on different configurations of the Wikidata function
evaluator. What do I mean by that?
Whereas we plan to support numerous different programming languages for
adding implementations in Wikifunctions, we do not plan to actually run
evaluators for all of them in production. This is due to several reasons:
the maintenance cost of keeping all these evaluators up and running and up
to date will likely be severe. The more programming languages we support,
the more likely it is that the Foundation or the community will be exposed
to bugs or security concerns in the run-times of these languages. And it is
likely that, beyond five or six programming languages, the return on
investment will greatly diminish. So what’s the point of having
implementations in programming that we do not plan to run in production?
Remember that we are planning for an ecosystem around Wikifunctions where
there are many function evaluators independent of the one run by the
Wikimedia Foundation. We are hoping for evaluators to be available as apps
on your smartphone, to have evaluators available on your own machine at
home, or in your browser, or in the cloud, to have third parties embed
evaluators for certain functions within their systems, or even to have a
peer to peer network of evaluators exchanging resources and results. Within
these contexts, the backends may choose to support a different set of
programming languages from those supported by Wikifunctions, either because
it is favorable to their use cases, or because they are constrained to or
passionate about a specific programming language. Particularly for running
Wikifunctions functions that are embedded within the system of a third
party app, it can easily provide quite a performance boost to run these
functions in the same language as the embedding app.
Another advantage of having implementations in different programming
languages is that in case an evaluator has to be suddenly taken down, e.g.
because a security issue has been reported and not fixed yet, or because
the resource costs of that particular evaluator have developed in a
problematic way, we can take that evaluator down, and change our
configuration to run a different set of programming languages. This gives
us a lot of flexibility in how to support the operation of Wikifunctions
without disrupting people using the service.
An implementation of a function can also be given as a function
composition: instead of contributed code in a programming language, a
composition takes existing functions from Wikifunctions and nests them
together in order to implement a given function. Here’s an example: let’s
say we want to implement a function second, which returns the second letter
of a word. Assume that we already have a function first which returns the
first letter of a word, and a function tail which chops off the first
letter of a word and returns the rest, then second(w) can be implemented as
first(tail(w)), i.e. the first letter of the result after chopping off the
first letter. We will talk about function composition in more detail at
another time.
Composition has the advantage that we don’t require implementations of
every function in code or as a built-in, and yet we can evaluate these
functions. The backend will properly chain the function calls and pipe the
results from one function to the next until it arrives at the requested
result. This might be particularly useful for third-party evaluators who
offer a different set of programming languages, or even focus on one
specific programming language; they still might be able to use a large set
of the functions, even without local implementations.
We expect composition to usually offer a less competitive performance
compared to running code. Our meta-data will be able to pinpoint especially
resource intensive function calls. We plan to surface these results on the
wiki, highlighting to the community where more efficient implementations
would have the most impact. I am hoping for a feature that, e.g., will
allow a contributor to see how many CPU cycles have been saved thanks to
their porting a function into WebAssembly.
One interesting approach to function composition could be that, if we have
code in a specific programming language for all functions participating in
a composition, it might sometimes be possible to synthesize and compile the
code for the composed function in that programming language. This might
lead to a situation where, say, two different programming languages offer
the most efficient implementation for some of the participating functions,
but the actual function call will run yet more efficiently in the new
synthesized result.
And finally, there’s also caching. Any of the function calls, including
nested calls in composed functions, might be cached and re-used. This cache
would be shared across all our projects, and provide significant speed-up:
after all, it is likely that certain calculations are going to be much more
popular than others, similar to how some articles are much more popular
than others at a given time. And just as Wikipedia saves tremendous amounts
of CPU cycles by keeping pages in the cache instead of re-rendering them
every time someone wants to read them, we can reap similar benefits by
keeping a cache of function calls and their results.
In summary: having multiple implementations for a function gives us not
only more flexibility in how to plan and run a function, and thus to
potentially save resources, but it also gives us a higher confidence in the
correctness of the system as a whole due to the cross-validation of the
different implementations and reduces the potential for conflicts when
editing Wikifunctions.
We are very curious to see how this will play out in practice. The few
paragraphs above describe ideas that require a lot of smart development
work on the back-end, and for which we don’t really know how well each of
them will perform. We sure expect to come across even more ideas (Maybe
from you? Maybe from a research lab?), and to discover that some of the
ideas sketched out here don’t work. We do not promise to implement
everything described above. The good thing is that many of those ideas are
ultimately optimizations: even simple versions of all of this should
provide correct results. But smarter approaches will likely save us huge
amounts of resources, and enable us to scale to the full potential of the
project. As with our other projects, we plan to publish our data and
metadata, and we invite external organizations, in academia and in industry
as well as hobbyists and independent developers and researchers, to help us
tackle these interesting and difficult challenges.
------------------------------
Again, reminder: our first office hour is upcoming *Tuesday, June 22, 2021,
at 16:00 UTC* on the Telegram channel and IRC Channel #wikipedia-abstract
connect <https://web.libera.chat/?channel=#wikipedia-abstract>.
The on-wiki version of this newsletter is available here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-06-04
--
We are planning for our first office hour! The Wikifunctions and Abstract
Wikipedia office hours will be online events where the development team
presents what they have been working on recently, and the community is
welcome to ask questions and discuss important related issues. They will be
announced on the mailing list and in the newsletter, and are planned to
take place every four to six weeks.
Our first office hour will be at 16:00 UTC on June 22, 2021, and will be in
the Telegram channel and IRC Channel #wikipedia-abstractconnect
<https://web.libera.chat/?channel=#wikipedia-abstract> (bridged together).
--
Shani Evenstein Sigalov <https://meta.wikimedia.org/wiki/User:Esh77> is
teaching a course “From Web 2.0 to Web 3.0, from Wikipedia to Wikidata” at Tel
Aviv University <https://en.wikipedia.org/wiki/Tel_Aviv_University>. Shani
prepared a video with Denny Vrandečić
<https://meta.wikimedia.org/wiki/User:Denny> where they discuss Abstract
Wikipedia and Wikifunctions. The video is available on YouTube
<https://www.youtube.com/watch?v=0GjNkrvT7Yc>.
In the interview Shani and Denny discussed some of the challenges in
Wikipedia and Wikidata, and how they brought about the idea of Abstract
Wikipedia. What the differences are between "Abstract Wikipedia",
"Wikifunctions" and "WikiLambda"; What the current state of the project is;
and how it all ties to the current Internet Ecosystem and things like AI
and Machine Learning.
Next Monday, June 7th, at 15:00 Israel time (12:00 UTC), Shani will be
hosting Denny in her course for a 45 mins Q & A session with her students
via Zoom. This part of the class will be open to anyone interested in this
topic, and you are welcome to either join them live and ask questions to
Denny (after watching the pre-recorded interview), or watch it all later.
If you are interested in joining, please write Shani an email (shani dot
even at gmail dot com) with the title "Joining the Q & A session with
Denny", by Sunday June 6th at 20:00 UTC, and she will send you the Zoom
link. This is to avoid Zoombombing.
If you are unable to participate live, but still want to engage, feel free
to send in questions via email or leave them on Shani’s Facebook post
<https://m.facebook.com/story.php?story_fbid=1932697493549355&id=10000427369…>.
The session will also be recorded, so if you cannot make it to the live
session, you will be able to watch it later on YouTube.
--
Lucas Werkmeister <https://meta.wikimedia.org/wiki/User:Lucas_Werkmeister>,
our esteemed colleague at Wikimedia Deutschland, who runs the Notwikilambda
site <https://notwikilambda.toolforge.org/> as a volunteer, has set up the
function evaluator and function orchestrator on Notwikilambda. He also
created instructive videos of him doing so on Twitch:
- Lucas setting up the function orchestrator
<https://www.twitch.tv/videos/1039150002>
- Lucas setting up the function evaluator
<https://www.twitch.tv/videos/1042511078>
These videos get automatically deleted after two weeks, i.e. in another
week after publishing this newsletter.
The function orchestrator is the service that receives a function call,
validates it, brings all necessary information together, calls the function
evaluator as needed, and eventually will resolve function compositions. The
function evaluator, on the other hand, takes code provided by Wikifunctions
contributors and runs it in order to produce results for the orchestrator.
Both of them are now set up on Notwikilambda, thanks to Lucas' work. Thank
you!
--
Boris Shalumov <https://2020-eu.semantics.cc/users/boris-shalumov>, host of
the podcast “Chaos Orchestra” on the topic of Knowledge Graphs, has also
interviewed Denny (among other guests, such as Sören Auer, a co-founder of
DBpedia, Jans Aasman, CEO of Franz Inc, or Daniel Schwabe, Professor at the
Catholic University of Rio de Janeiro, and a few others), and they discuss
Wikidata, Wikifunctions, and many other topics.
The podcast episode is available on YouTube
<https://www.youtube.com/watch?v=jcEdlxXlJS8>, Spotify
<https://open.spotify.com/show/3CMVAHbd7lNb2yObyl8ERe?si=FnTIGlj7SaKBwJ7a3zP…>,
and Google Podcasts
<https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5idXp6c3Byb3V0LmNvbS8xNz…>
.
--
We'll also participate in the Arctic Knot conference
<https://diff.wikimedia.org/2021/06/02/arctic-knot-envision-the-future-of-yo…>
this
year. Community member Mahir Morshed
<https://meta.wikimedia.org/wiki/User:Mahir256> will present on how to get
the lexicographic data ready to be used in Abstract Wikipedia, and Denny
will present on Abstract Wikipedia and Wikifunctions in general.
The conference will be free, fully online, and registration is open
<https://meta.wikimedia.org/wiki/Arctic_Knot_Conference_2021> right now.
--
On the development side, this week saw the start of the performance and
security reviews, to make sure the architecture and implementation are on
solid ground to take us to the launch later this year. They are both
scheduled to go for two weeks. We are cooperating with the respective teams
at the Wikimedia Foundation and are thankful for their support regarding
these critical aspects of the new project.
The on-wiki version of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-05-28
We have talked a lot in the past about what Wikifunctions aims to become: a
Wikimedia project for everyone to collaboratively create and maintain a
library of code functions to support the Wikimedia projects and beyond, for
everyone to call and re-use in the world's natural and programming
languages.
Today, in the tradition of the influential WP:NOT policy on English
Wikipedia <https://en.wikipedia.org/wiki/Wikipedia:What_Wikipedia_is_not>,
we publish an essay on what Wikifunctions aims not to be. WP:NOT was
started back in 2001, and was an important influence on the early
development of the English Wikipedia - evidenced by the fact that more than
2 million links to that page exist within the English Wikipedia.
So, without further ado — what Wikifunctions is not:
*Wikifunctions is not an encyclopædia of algorithms* in the sense that we
will have pages for famous and not-so famous algorithms such as Euclid’s
<https://en.wikipedia.org/wiki/Euclidean_algorithm>, Newton’s
<https://en.wikipedia.org/wiki/Newton%27s_method>, or Dijkstra’s algorithm
<https://en.wikipedia.org/wiki/Dijkstra%27s_algorithm>, aiming to represent
all existing algorithms faithfully and in their historical context. Yes, we
expect to have a function for the greatest common divisor
<https://en.wikipedia.org/wiki/Greatest_common_divisor> (GCD) of two
integers. And there might or might not be one or more implementations which
are based on Euclid’s algorithm to calculate the GCD. But Wikifunctions
would not be incomplete if it didn’t, and if, instead, we had alternative
algorithms to calculate the GCD. If you are looking for that, many
Wikipedias are actually great resources
<https://en.wikipedia.org/wiki/List_of_algorithms>.
Unlike an encyclopedic overview of existing algorithms, Wikifunctions will
also invite original work. We will not be restricted to functions that have
been published elsewhere first, and we do not require for every function
and implementation to be based on previously published work. Wikifunctions,
much like Wikibooks and very unlike Wikipedia, will be open to novel
contributions. The main criteria for implementations will be: under which
conditions can we run a given implementation, and what resources is it
expected to take?
*Wikifunctions is not an app development site*. We do not expect to make it
possible to create full-fledged, stand-alone apps within Wikifunctions -
there will be no place to store state, we don’t aim to allow calling
external APIs or directly cause changes to other sites, and we don’t aim to
package up apps with icons and UX, etc.. We absolutely expect Wikifunctions
to be a very useful resource for app developers, and I can very much
imagine apps that are basically wrappers around one or more functions from
Wikifunctions, but these would still need code and other assets which
wouldn’t be part of Wikifunctions. We are not competing in the area of
no-code or low-code development sites.
*Wikifunctions is not a code hosting service*. Yes, sure, Wikifunctions
will host code, but not for whole projects, merely for individual
functions. There won’t be libraries, apps, or services developed on
Wikifunctions with bug-trackers, forums, etc.. There won’t be a Web-based
version control system such as mercurial or git running against
Wikifunctions. Again, we hope that there will be libraries, apps, and
services that will rely on functions available in Wikifunctions, but they
would be developed on a different site, such as Gerrit, GitHub, or GitLab.
*Wikifunctions is not a programming language*, nor trying to evangelise a
particular language. In fact, Wikifunctions will allow for functions to be
implemented in a multitude of programming languages. The possibility to
compose functions together to create higher level functions may look a
little bit like a new programming language, but it will be extremely
limited compared to most other programming languages, since we only allow
for nested function calls and that’s it.
*Wikifunctions is not an Integrated Development Environment*. We won't
provide you with an interface for creating and developing software
projects, interfacing with build, testing, and source control systems.
*Wikifunctions is not a question-and-answer Website*. We are not competing
with StackOverflow and similar Websites, where a developer would ask how to
achieve a certain task and have community members discuss and answer the
question. We won’t contain code snippets to help answer the question, but
we will organize code within our Website to enable the evaluation of
functions within a library of functions.
*Wikifunctions is not a cloud computing platform*. We do not provide
computing resources and access to services and APIs so that you can run
your computational needs on our platform, either for money or for free. Use
of Wikifunctions's evaluation platform is to improve access to knowledge
for everyone.
*Wikifunctions is not a code snippet Website*. We are not competing with
sites such as gist, or sites such as rosettacode.org, esolangs.org, or
helloworldcollection.de, where code snippets are collected either to share
them quickly with others or around a specific theme in different
programming languages. The reason for having functions be implemented in
multiple programming languages is not to contrast them and compare them for
the education of the users of Wikifunctions, but in order to be able to
efficiently and effectively evaluate functions in different environments
and to improve the reliability of Wikifunctions as a whole.
*Wikifunctions is not a code education platform*. We are not in the
business of teaching people how to code, the material in Wikifunctions will
not be laid out in a pedagogical order, and we also won’t make sure to
comprehensively cover all topics important for coding. In fact, we aim for
Wikifunctions to be usable for people who don’t know how to code and who
don’t need to learn how to code to use most of Wikifunctions effectively.
Though the Wikifunctions community may well help each other in sharing best
practices, style guides, and tips on how to use the site in different
languages, these will be aimed at the purpose of serving the world's
knowledge.
Wikifunctions is, as far as we can tell, a new kind of Website, aiming for
a new community. We very much hope to work together with many of the tools,
sites, communities, and kind of systems we have mentioned above: we want to
play together with IDEs, with cloud computing platforms, with app
development sites, and many more of the systems and tools we mentioned —
but we aim to be a novel thing and we hope to shape a new unique space out
for us: A Wikimedia project for everyone to collaboratively create and
maintain a library of code functions to support the Wikimedia projects and
beyond, for everyone to call and re-use in the world's natural and
programming languages.
--
In related news, the recording of the keynote about Abstract Wikipedia and
Wikifunctions at this year’s Web Conference is now available online:
http://videolectures.net/www2021_vrandecic_knowledge_equity/
The on-wiki version of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-05-06
In 2018, Wikidata launched a project to collect lexicographical knowledge
<https://www.wikidata.org/wiki/Wikidata:Lexicographical_data>. Several
hundred thousand Lexemes have been created since then, and this year the
tools will be further developed by Wikimedia Deutschland to make the
creation and maintenance of the lexicographic knowledge in Wikidata easier.
The lexicographic extension to Wikidata was developed with the goal that
became Abstract Wikipedia in mind, but a recent discussion within the
community showed me that I have not made the possible connection between
these two parts clear yet. Today, I would like to sketch out a few ideas on
how Abstract Wikipedia and the lexicographic data in Wikidata could work
together.
There are two principal ways to organize a dictionary: either you organize
the entries by ‘lexemes’ or ‘words’ and describe their senses (this is
called the semasiological <https://en.wikipedia.org/wiki/Semasiology>
approach), or you organize the entries by their ‘senses’ or ‘meanings’
(this is called the onomasiological
<https://en.wikipedia.org/wiki/Onomasiology> approach). Wikidata has
intentionally chosen the semasiological approach: the entries in Wikidata
are called Lexemes, and contributors can add Senses and Forms to the
Lexemes. Senses stand for the different meanings that a Lexeme may
regularly invoke, and the Forms are the different ways the Lexeme may be
expressed in a natural language text, e.g. in order to be in agreement with
the right grammatical number, case, tense, etc. The Lexeme “mouse” (L1119
<https://www.wikidata.org/wiki/Lexeme:L1119>) thus has two senses, one for
the small rodent, one for the computer input device, and two forms, “mouse”
and “mice”. For an example of a multilingual onomasiological collaborative
dictionary, one can take a look at the OmegaWiki <http://www.omegawiki.org/>
project, which is primarily organized around (currently 51,000+) Defined
Meanings <http://www.omegawiki.org/Help:DefinedMeaning> and how these are
expressed in different languages.
The reason why Wikidata chose the semasiological approach is based on the
observation that it is much simpler for a crowd-sourced collaborative
project, and has much less potential to be contentious. It is much easier
to gather a list of words used in a corpus than to gather a list of all the
meanings referred to in the same corpus. And whereas it is 'simpler', it is
still not trivial. We still want to collect a list of Senses for each
Lexeme, and we want to describe the connections between these Senses:
whether two Lexemes in a language have the same Sense, how the Senses
relate to the large catalog of items in Wikidata, and how Senses of
different languages relate to each other. These are all very difficult
questions that the Wikidata community is still grappling with (see also the
essay on Making Sense <https://www.wikidata.org/wiki/Wikidata:Making_sense>
).
Let’s look at an example.
“Stubbs was probably one of the youngest mayors in the history of the
world. He became mayor of Talkeetna, Alaska, at the age of three months and
six days, and retained that position until his death almost four years ago.
Also, Stubbs <https://en.wikipedia.org/wiki/Stubbs_(cat)> was a cat."
If we want to express that last sentence - “Stubbs was a cat” - we will
have to be able to express the meaning “cat” (here, we will focus entirely
on the lexical level, and will not discuss grammatical and idiomatic
issues; we will leave those for another day). How do we refer to the idea
for cat in the abstract content? How do we end up, in English, eventually
with the word form “cat” (L7-F4 <https://www.wikidata.org/wiki/Lexeme:L7#F4>)?
In French with the word form “chat” (L511-F4
<https://www.wikidata.org/wiki/Lexeme:L511#F4>)? And in German with the
form “Kater” (L303326-F1 <https://www.wikidata.org/wiki/Lexeme:L303326#F1>)?
Note that these three words commonly do not have the same meaning. The
English word cat refers to both male or female cats equally; and whereas
the French word could refer to a cat generically, for example if we
wouldn’t know Stubbs’ gender, the word is male, but a female cat would
usually be referred to using the word “chatte”. The German word, on the
other hand, may only refer to a male cat. If we wouldn’t know whether
Stubbs is male or female, we would need to use the word “Katze” in German
instead, whereas in French, as said, we still could use “chat”. And English
also has words for male cats, e.g. “tom” or “tomcat”, but these are much
less frequently used. Searching the Web for “Stubbs is a cat” returns more
than 10,000 hits, but not a single one for “Stubbs is a tom” nor “Stubbs is
a tomcat”.
In comparison, for Félicette <https://en.wikipedia.org/wiki/F%C3%A9licette>,
the first and so far only cat in space, the articles indeed use the words
“chatte” in French and “Katze” in German.
Here we are talking about three rather closely related languages, we are
talking about a rather simple noun. This should have been a very simple
case, and yet it is not. When we talk about verbs, adjectives, or nouns
about more complex concepts (for example different kinds of human
settlements or the different ways human body parts are conceptualized in
different languages, e.g. arms and hands <https://wals.info/chapter/129>,
terms for colors), it gets much more complicated very quickly. If we were
to require that all words we want to use in Abstract Wikipedia first must
align their meanings, then that would put a very difficult task in our
critical path. So whereas it would indeed have been helpful to Abstract
Wikipedia to have followed an onomasiological approach (how wonderful would
it be to have a comprehensive catalog of meanings!), that approach was
deemed too difficult and a semasiological approach was chosen instead.
Fortunately, a catalog of meanings is not necessary. The way we can avoid
that is because Abstract Wikipedia only needs to generate text, and neither
parse nor understand it. This allows us to get by using a Constructor that,
for each language, uses a Renderer to select the correct word (or other
lexical representation). For example, we could have a Constructor that may
take several optional further pieces of information: the kind of animal,
the breed, the color, whether it is an adult, whether it is neutered, the
gender, the number of them, etc. For each of these pieces of information,
we could mark whether that information must be expressed in the Rendering,
or whether this information is optional and can be ignored, and thus what
is available for those Renderers to choose the most appropriate word. Note,
this is not telling the community how to do it, merely sketching out one
possible approach that would avoid to rely on a catalog of meanings.
Each language Renderer could then use the information it needs to select
the right word. If a language has a preference to express the gender (such
as German) it can do so, whereas a language that prefers not to (such as
English) can do so. If for a language the age of the cat matters for the
selection of the word, it can look it up. If the color of the animal
matters (as it does for horses in German
<https://de.wikipedia.org/wiki/Fellfarben_der_Pferde#Die_einzelnen_Fellfarben>),
the respective Renderer can use the information. If a required information
is missing, we could add this to a maintenance queue so that contributors
can fill it out. If a language should happen not to have a word, a
different noun phrase can be chosen, e.g. a less specific word such as
”animal” or “pet”, or a phrase such as “male kitten”, or “black horse” for
the German word “Rappen”.
But the important design feature here is that we do not need to ensure and
agree on the alignment of meanings of words across different languages. We
do not need a catalog of meanings to achieve what we want.
Now, there are plenty of other use cases for having such a catalog of
meanings. It would be a tremendously valuable resource. And even without
such a catalog, the statements connecting Senses and Items in Wikidata can
be very helpful for the creation and maintenance of Renderers, but these do
not need to be used when the natural text for Wikipedia is created.
This suggestion is not meant to be prescriptive, as said. It will be up to
the community to decide on how to implement the Renderers and what
information to use. In this, I am sketching out an architecture that allows
us to avoid blocking on the availability of a (valuable but very difficult
to create) resource, a comprehensive catalog of meanings aligning words
across many different languages.
Had some fun today with an often used international hero (I never knew he
was so popular worldwide!) who seems to rise up in solving sticky
situations with creative solutions.
https://www.wikidata.org/wiki/Lexeme:L488777
Thanks to Jan Ainali and Jon Harald Søby for assistance on Telegram chat.
https://t.me/c/1325756915/8982
I guess the learning here is:
that any word or phrase, even a person or org name, could potentially be
used as a Verb, and that's fine and we should capture that as a Lexeme when
there is usage and understanding of it in a language. It's also helpful to
give as much context as possible with additional statements to those
namesake Lexeme so that folks 10,000 years from now might know what we were
talking about. :-)
Thad
https://www.linkedin.com/in/thadguidry/https://calendly.com/thadguidry/
The on-wiki version of this newsletter can be found at
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-05-11
When we started the development effort towards the Wikifunctions site, we
subdivided the work leading up to the launch of Wikifunctions into eleven
phases, named after the first eleven letters of the Greek alphabet.
-
With Phase α (alpha) completed, it became possible to create instances
of the system-provided Types in the wiki.
-
With Phase β (beta), it became possible to create Types on-wiki and to
create instances of these Types.
-
With Phase γ (gamma), all the main Types of the pre-generic function
model were available.
-
This week, we completed Phase δ (delta).
The goal of Phase δ was to provide the capability to evaluate built-in
implementations.
What does this mean? Every function in Wikifunctions can have several
implementations. There are three different ways to express an
implementation:
1.
As some code in a programming language, written by the users of
Wikifunctions: the implementation of a function can be given in any
programming language that Wikifunctions supports. Eventually we aim to
support a large number of programming languages, but we will start small.
2.
As a built-in function, written by the development team: this means that
the implementation is handled by the evaluator as a black box. We hope to
rely on only a very small number of required built-in functions, since each
evaluator needs to implement all built-in functions to be usable, and we
want to make adding new evaluators (and so new programming languages) as
easy as possible. A list of built-in functions currently available is given
below. This list is likely not final, but we hope it won't grow.
3.
As a composition of other functions: this means that we use existing
functions as building blocks in order to implement new capabilities. We
have published a few examples of composed implementations
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Examples/Function_compos…>.
The example implementation of the Boolean functions might be particularly
instructive.
In Phase δ, we created the infrastructure and interfaces to evaluate
function calls at all, and allowed for built-in implementations. The built-in
functions
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Reserved_ZIDs#Core_funct…>
that are currently available are the following:
-
If : Boolean, Any, Any ➝ Any — returns second argument if the first is
true, else the third; if has two letters
-
Value by key : Key reference, Any ➝ Any — returns the value of the given
key of the given object
-
Reify : Any ➝ List(Pair(Key reference, Any)) — transforms any object
into a list of key-value pairs; it deconstructs the object
-
Abstract : List(Pair(Key reference, Any)) ➝ Any — transform a list of
key-value pairs into an object; it constructs an object
-
Cons : Any, List ➝ List — insert an object to the front of an ordered
list of objects
-
Head : List ➝ Any — get the first item of a list
-
Tail : List ➝ List — get the list with the first item removed
-
Empty : List ➝ Boolean — return if a list does not contain any item
-
First : Pair ➝ Any — extract the first value of a pair
-
Second : Pair ➝ Any — extract the second value of a pair
-
Convert : String ➝ List(Character) — convert a string into a list of
Characters
-
Convert : List(Character) ➝ String — convert a list of Characters into a
string
-
Same : Character, Character ➝ Boolean — compare two characters and
return if they are equal
-
Unquote : Quote ➝ Any — unquotes a Quote
All of the implementations of these built-ins, though simple, are first
drafts, and currently only lightly tested. If you test them and find
issues, please report them on Phabricator or send an email to
abstract-wikipedia(a)lists.wikimedia.org. We will improve these over the
following weeks.
The two screenshots show a new special page that lets you evaluate a
function call. Here we offer two screenshots with examples. The first one
shows the call to the If function. The condition is set to true, and thus
the function call should return the consequent (given as the String “this”)
and not the alternative (given as the String “that”). And indeed - the
Orchestration result below the function call shows a normalized result
representing the String “this”:
The second example is taken straight from the phase completion condition on
the Phases planning. Here we check whether an empty list is indeed empty
(we are calling the Z813/Empty function, and the argument, Z813K1/list is
an empty list). The result is true (i.e. the Z40/Boolean with the
Z40K1/identity Z41/true):
We promise to improve the UX before launch! This raw JSON output is mostly
for debugging and internal development purposes as we work on a design
language for the user experience.
We are now moving on to Phase ε (epsilon). In this phase we aim to support
user-written implementations in a programming language. Our initial plan is
to support code written in JavaScript and Python.
Since running arbitrary code written by anyone on the Internet has major
security and performance risks, we will follow up the work in this phase
with thorough security and performance reviews working with colleagues
across the Foundation.
We currently do not have an official public test instance of the WikiLambda
system running. Lucas Werkmeister has, in his volunteer capacity, so far
provided us with a regularly updated public test instance, notwikilambda,
for which we are deeply grateful, but that instance has not yet been
updated to support the orchestrator backend (as we still need to document
how to do so). We will continue to not run an instance of our own until
after the security and performance reviews have concluded (but we certainly
won’t stop anyone else from doing so, and can provide some support on the
usual channels if someone wants to set it up).
Following the conclusion of the current Phase, we will move on to Phase ζ
(zeta), which will allow for the third type of implementations,
compositions.
Thanks to the team, thanks to the volunteers, for their great effort in
bringing us so far, and I am excited for the next steps of the project!
(Note: there will not be a newsletter next week.)
The on-wiki version of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-04-29
This week, I want to start with a shoutout to our phenomenal volunteers.
Lexicographical coverage
My thanks to Nikki <https://www.wikidata.org/wiki/User:Nikki> and their
updates on the dashboards about lexicographical coverage
<https://www.wikidata.org/wiki/Wikidata:Lexicographical_coverage>. Since
the first publication of the dashboard, Nikki has kept the dashboards up to
date, re-running them from time to time and updating the page on Wikidata.
They and others have also fixed numerous issues, created more actionable
lists, and added more languages based on other corpora than Wikipedia (most
notably from the Leipzig Corpora Collection
<https://wortschatz.uni-leipzig.de/en>). Thanks also to Mahir
<https://www.wikidata.org/wiki/User:Mahir256>, who also contributed to the
dashboard, particularly covering Bengali, one of our focus languages.
In fact, thanks to Nikki and Mahir, the four main focus languages are now
all covered: we have numbers for Bengali, Malayalam, Hausa, and Igbo. We
are still missing our stretch focus language, Dagbani, because we could not
find yet a corpus. We have reached out to a researcher who has compiled a
Dagbani corpus
<https://www.aflat.org/content/corpus-building-predominantly-oral-culture-no…>,
and we also are exploring how we could use the Dagbani Wikipedia
<https://incubator.wikimedia.org/wiki/Wp/dag> on Incubator
<https://incubator.wikimedia.org/wiki/Incubator:Main_Page>. In the
meantime, we are pleased to see that the Dagbani community has put in a request
for a new Wikipedia edition
<https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Dagbani>
and that they feel that they are ready to graduate from incubator!
Congratulations!
Some of the results of highlighting the dashboard, and particularly the
list of most frequent missing lexemes, were very promising: coverage in a
number of languages has increased considerably. To just list a few
examples: Polish went from 16% to 32% coverage, German from 53% to 67%,
Czech from 44% to 57% — and Hindi went from a mere 1% to 15%, and Malay
from 15% to an astonishing 53%! Congratulations to those communities and
others for such visible progress.
With an eye on our focus languages, Bengali went from 18% to 28%, Malayalam
is at 21%, whereas Hausa and Igbo both have coverages of below 1%.
Another great tool to see the progress in lexicographical knowledge
coverage in Wikidata is Ordia <https://ordia.toolforge.org/>, developed by Finn
Årup Nielsen <https://meta.wikimedia.org/wiki/User:Fnielsen>. Ordia is a
holistic user experience that allows users to browse and slice and dice the
lexicographic data in Wikidata in real time. We can take a look at the 11,400
Malayalam Lexemes <https://ordia.toolforge.org/language/Q36236>, the 8,724
Bengali Lexemes <https://ordia.toolforge.org/language/Q9610>, 53 Dagbani
Lexemes <https://ordia.toolforge.org/language/Q32238>, 15 Hausa Lexemes
<https://ordia.toolforge.org/language/Q56475>, and the single Lexeme in Igbo
<https://ordia.toolforge.org/language/Q33578>, mmiri, the Igbo word for
water. Thanks to Finn for Ordia!
Making the state of the lexicographical coverage visible shows us that
there is still a lot to do — but also that we are already achieving
noticeable progress! Thanks to everyone contributing.
By the way, the annotation wiki <https://annotation.wmcloud.org/> is
currently having issues. If you would like to help us with running it and
have experience with Vagrant and Cloud VPS based wikis, please drop me a
line on my talk page <https://meta.wikimedia.org/wiki/User_talk:Denny>.
A first running function call!
Lucas Werkmeister <https://meta.wikimedia.org/wiki/User:Lucas_Werkmeister>
consistently keeps being amazing. He is working on GraalEneyj
<https://github.com/lucaswerkmeister/graaleneyj>, a GraalVM
<https://www.graalvm.org/>-based evaluation engine for Wikifunctions,
written in Java. Lucas re-wrote GraalEneyj to be able to call a function
all directly from the notwikilambda test-wiki — the very first time that
one of our functions is being evaluated! You can watch that moment in a
Twitch video <https://www.twitch.tv/videos/975239172>.
We are still working on replicating that feat in what will be our
production codebase, and hope to soon connect our backend evaluating
functions with the wiki — this is our goal for the ongoing Phase δ
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Phases#Phase_%CE%B4_(del…>
(delta). Congratulations to Lucas for achieving this step!
Delay on logo
There will be a delay on the logo finalization. Please expect another month
or two before we will have news to share about the logo. Due to the legal
nature of some of the involved issues, we have decided to not share details
in public. Sorry for the delay, and I am looking forward to sharing the
next steps in this process.
New documents
We have been working for a while with the Wikimedia Architecture Team on a
number of artefacts around Abstract Wikipedia and Wikifunctions. We have
now published and shared these documents in the Architecture repository
<https://www.mediawiki.org/wiki/Architecture_Repository/Strategy/Goals_and_i…>.
We are aiming to keep publishing our design documents and related
development artefacts, and are happy to invite you to this set of documents.
Based on requests from the community, we also worked on a new example of an
article in abstract content
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Examples/Jupiter>. The
example is not complete, and is open to being edited and discussed. Note
that this is not meant to be prescriptive of how abstract content should
look like, but merely a more concrete hypothetical example of what it could
look like. I am confident that the community as a whole will come up with
better abstractions than I did. Please do edit or fork that page.
There will be three approaches towards creating an implementation for a
function in Wikifunctions, and the current and following two phases of
development are each dedicated to one of those approaches: (1) allow to
call a built-in implementation in the evaluator engine, (2) allow to call
native code in a programming language, and (3) compose other functions to
implement a new function. In preparation for the upcoming Phase ζ
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Phases#Phase_%CE%B6_(zet…>
(zeta), we have created a few examples of function composition
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Examples/Function_compos…>
.
