|◀||Abstract Wikipedia Updates||▶|
- Development has been active. We are deep into Phase γ, working on supporting the core types for Wikifunctions, including functions, implementations, testers, errors, and so on. We are removing some major blockers for further development.
At the same time, we have already begun our work on the larger architecture of the system, in particular our evaluation engine with support for one native programming language. The evaluation engine is the part of Wikifunctions responsible for evaluating function calls. That is, it is the part that gets asked, “Hey, what’s the sum of 3 and 5?” and answers, “8”.
Our evaluation engine is principally separated into two main parts: the function orchestrator, which receives the calls and collates the functions and any data needed to process and evaluate the calls; and then the function evaluator (or executor), which runs the contributor-written code, as instructed by the orchestrator. As the executor can run uncontrolled native code, it lives in a tightly controlled environment and has only minimal permissions, beyond the limited use of computing and memory resources.
The orchestrator will also rely heavily on caching: if we have just calculated the sum of 3 and 5, and someone else asks for that too, we’ll just take it from the cache instead of re-running the computation. We'll also cache function definitions and inputs within the orchestrator, so that if someone asks for the sum of 3 and 6 we can answer more swiftly.
But this is just our production evaluation engine. We are hoping that several other evaluation engines will be built, like the GraalVM-based engine on which Lucas Werkmeister is already working.
In order to support the development of evaluation engines, we are working on a test suite that other evaluation engines can use for conformance testing. If you’re interested in joining that effort, drop a note on this task. The test suite, as well as the common code used by several parts of our system to handle ZObjects, will live in a new library repository, function-schemata.
This development has been a bit out of order from the original plan we conceived last August.
In fact, we are thinking of changing the order of some of the developments, and we expect to do significant parts of it in parallel. Having the evaluation engine available earlier makes it possible to start the security and performance reviews in a timely manner, and to validate our architectural plans.
In other news
The deadline for submissions to the Wikifunctions logo concept is coming closer: submissions are accepted until Tuesday, 23 February, followed by a two-day discussion before the voting on which concept to develop starts on Thursday, 25 February. Currently, we have 17 submissions (and some additional variants).
There have been a number of talks and external articles which may be of interest:
We gave a presentation at the Graph Technologies in the Humanities: 2021 Virtual Symposium. You can watch our pre-recorded presentation for the symposium. It was followed by ample time to discuss the project; unfortunately, the discussion itself will not be published.
We also presented at the NSF Convergence Accelerator Series. The talk is very similar to the previous talk, but this recording includes the discussion following the talk.
The issue 322 of the Tool Box Journal: A Computer Journal For Translation Professionals reports on Abstract Wikipedia, Wikifunctions, and Wikidata. I found it very interesting to see how the projects are perceived by professional translators, and their comparison of Wikidata to a termbase.
The German magazine Der Spiegel published an interview with Denny about Abstract Wikipedia. They also published a more comprehensive article in their 16 January print issue, which is available in their archive for subscribers. Both the interview and the article are in German.