June 2021 - Abstract-Wikipedia - lists.wikimedia.org

Word Sense Disambiguation
by Andy 03 Sep '21

03 Sep '21

Is very hard to make large or even medium size corpus of sentences, in which each word would be manually annotated with sense. Abstract Wikipedia not only allows generate text in many languages from one source but can be WSD corpus. Moreover: in many languages. This allows understanding natural text and operations like: 1) translation from any natural language to disambig form 2) translate from this form to other natural language and after step 1 this form will very useful not only for translation I was interested in this Abstract Wikipedia project one year ago.Now I'm not up to date on the topic On Arctic Knot conference will be look on project as database of disambiguated knowledge?

2 1

Synonyms and word senses
by Andy 02 Jul '21

02 Jul '21

In WikiData is very large amount of Qnnnn entities and much smaller set of Lnnnn lexems. One lexem can have many senses and many different words can be synonyms (problem: sometimes very close meaning but not the same) For example in multilingual Wordnet : Polish->English word "kot" has: 02121808-n kot, kot domowy domestic cat, house cat, Felis domesticus, Felis catus any domesticated member of the genus Felis 10149241-n kot grunt an unskilled or low-ranking soldier or other worker 10508379-n kot raw recruit an inexperienced and untrained recruit 02121620-n (18) kot cat, true cat feline mammal usually having thick soft fur and no ability to roar: domestic cats; wildcats 10641301-n kot sprog a new military recruit # of them: 10149241-n 10508379-n and 10641301-n are English synonyms, very close meanings, differ lexem. In Polish is one lexem "kot", In Polish shouldn't distinguish this 3 senses, instead of should be one general definition. Problem: in Abstract Wikipedia source text should be language independent, sense-centered We need common sense for 3 differ English lexems? Senses are distinguishable in differ degree in differ language, for example "snow" in African languages vs Siberian languages. - how Abstract Wikipedia will do with senses? - how view senses in Wikidata?

6 16

Newsletter #36: Phase ε completed
by Denny Vrandečić 30 Jun '21

30 Jun '21

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.

1 0

Newsletter #35: Invitation to the Grammatical Framework Summer School
by Denny Vrandečić 25 Jun '21

25 Jun '21

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.

1 0

Office Hour - in 20 min
by Nick Wilson (Quiddity) 22 Jun '21

22 Jun '21

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)

1 0

Newsletter #34: Why allow several implementations of a function?
by Denny Vrandečić 18 Jun '21

18 Jun '21

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

1 0

Newsletter #33: Office hour, videos, meeting opportunities, and a podcast
by Denny Vrandečić 05 Jun '21

05 Jun '21

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.

1 0

2024

2023

2022

2021

2020

Abstract-Wikipedia June 2021