 Hello, and welcome to Wikimedia. Thank you for your interest in us at Wikipedia and Wikifunctions. Our goal is a world where everyone can. But today, the knowledge from Wikipedia is very unevenly distributed. English has millions of articles, but Hauser, the 60 million native speakers, 30 million second language speakers, has about 10,000 articles. The fundamental issue is that Wikipedia's cost is basically the number of topics times the number of languages. All articles about a topic in each language are created to maintain completely independently. Can we change that? Can we turn this multiplication into an addition? And does it use the cost of Wikipedia by two orders of magnitude anymore? Yes, we can. Wikidata demonstrates a step in this direction. This is the article about Marie Curie in the book of Wikipedia. The blue parts, the top part, the side part, they are already familiar with it. That's taken care of. The red parts, the info box, the references, the language links, your foreign control files, the button. They already are not maintained locally anymore, but in Wikidata. And a growing number of Wikipedia language additions choose to share from Wikidata's common knowledge base to work together on maintaining knowledge in one single place to keep it up to date, to keep it correct, and to use it to display knowledge on their Wikipedia's. So all we have to do is to move everything from Wikipedia to Wikidata and done. Unfortunately, no. The major problem is that Wikipedia has a very limited expressivity. It cannot do narration. And narration is fundamental for humans to learn. Wikidata can't do reference description and it's bad at redundancy. Let's illustrate the last thing about redundancy. Here's one fact about Marie Curie, which is mentioned in the lead of basically every language addition of her article, even the short Oro article we saw. She's the only person to ever have won the Nobel Prize in two different scientific fields. A fact that Wikidata cannot express also it is clearly important, as you can see, because all these Wikipedia's had contributors who went through the effort of writing it down in the lead of the article. Absent Wikipedia will extend the expressivity Wikidata provides considerably. And then we will have functions to generate national language text from this new abstract representation and allow the Wikipedia's to filter gaps with baseline knowledge content created, generated from Wikidata. All we need to do is to switch this function using the same content and we get text in a different language. This leads to an architecture where we have only one content per topic and a set of renderers per language. This indeed fulfilling the goal of having the cost of Wikipedia being topics plus languages, not topics time languages. So, who's going to write all these functions to generate text in hundreds of languages? Well, even though there are plenty of people in our panel, there's not enough people to create renderers for hundreds of languages. Instead, we will create a platform, a new Wiki where community will be able to create functions, Wiki functions. A Wiki where you can use functions to answer your questions, where you can create more functions to answer more types of questions. We will be the first Wikimedia project for launch since 2012. Wiki functions aims to be fully multilingual like Wikidata, both in terms of natural as well as programming languages. And we won't be focusing just on national language functions, but we'll do all kinds of functions. So, what is a function? Take some input and then we have some algorithm and some recipe that allows us to calculate the output of the function. That's the technical definition. But more importantly, functions are a type of knowledge. Functions are a type of knowledge and therefore it's our job to allow everyone to share in this knowledge. But currently, we are not that good at letting anyone share in this kind of knowledge. The big tech companies graciously allow you to access some functions. Ask Siri how many teaspoons are in two tablespoons and it will answer. That's a function running right there on the phone for you. Go to Bing and ask, when was Wikipedia founded? It will not check the web index, even though Bing is a search engine, but it will run a function against its knowledge graph, Satori, which is like our Wikidata. Take that date, go to DuckDuckGo and ask how many days have passed since then. Again, the result is not a search result but a function evaluation. Ask Google about the volume of the pyramid and it will give you this beautiful handcrafted experience and the answer will be calculated by a function. But if you move out of this, select few handcrafted experiences that the tech companies have chosen to deploy, you are out of luck. Even though we have enough computing power in our hands, most of us cannot use this computing power to calculate the functions we need. Functions are a type of knowledge. Knowledge is power. And functions really are a superpower because functions are not just knowledge. No, they can have confidence, answer questions no one has ever asked before. Functions create knowledge and what's more superpower than creating knowledge. We want to democratize the superpower. We want to give it to everyone with access to the web. For this, we will introduce wiki functions as a new wiki project where a community can create functions and where people can use functions to answer their questions. This in the next few slides shows some old mock-up designs that just give a rough idea of how it might work. That this wiki will have a function such as converting tablespoons to teaspoons like Siri did earlier or calculating how many days have passed between two days, like in Dr. Go. Taking a geo shape, upload it to comments and calculate how many square miles the shape covers. We're taking a string and reversing it. So here's a short demo of how the reverse function looks like in our current prototype. You see that the function takes a string. Here's the argument, takes a string and returns a string. And there's one implementation in JavaScript which looks like this. It's actually from a different page but it's been transcluded in this page. So this is the reverse function and if you want to run it we can go to the other function called special page that we can call the reverse function on a value like Wikipedia and we call it and you see the result back here. I said the interface is still very early and very rough. We're working right now on a full design of our interface and here is a very first thing you can see now. But back to the mock-ups. This is a simple function for multiplying positive numbers. As I said earlier, we support several programming languages. So far we have implemented JavaScript and Python. You want to support many more. Some multiplication is implemented in JavaScript using the native multiplication. His Python, Python basically it's the same. And this implementation though is different. Here we implement multiplication in something called composition. We take functions that already exist in wiki functions and compose them together in order to get more powerful functions implemented. Now, the really interesting part here is since these functions used in composition are functions in wiki functions itself and just like items in wiki data have security each function also has its own page, its own setting. The functions down here add a zero and so on. The functions down here are set IDs with labels in different languages and that allows us to switch languages and you can see the same composition in German or in Bengali and not just read implementation in Bengali but also write it in Bengali. We are aiming to allow people to create implementations without having to know basic English which is a major block of many people in the world to create functions. As research has repeatedly shown including research by frequent wiki mania at indeed Benjamin Marlborough. For many, many people, this will be the first time that they will be able to write implementations with a native language. For hundreds of million of people we will unlock that superpower of using, reading and writing functions. For wiki functions, we will have a new community with people from the existing projects and mixing new people who have never contributed to our projects before. We want to make functions accessible in many different ways, for many different gateways. Wherever you need them, whenever you need them, on the web, on your phone, through an assistant with a spreadsheet and in the wiki media projects. And we want to generate multilingual content from expressive, abstract representations in free hand languages. Which is why we need to make it available to as many people as possible to aim at people who don't speak English and people who are not already coders. We call this aiming high, aiming wide, instead of narrowing or just English-speaking coders. We have a lot of discussion about this because it is very ambitious. It is difficult. We are doing and digging out user users to understand how difficult this is. Just one surprising example. Most people think that coding correlates with STEM abilities, with mathematical abilities. And many people who don't think of themselves as being strong at STEM, are misparticipating in coding before even taking a closer look. Even though research published last year in Nature shows no correlation between STEM and programming, but a clear and strong correlation between language aptitude and learning programming languages. Language aptitude, exactly. So the very same people who are contributing to Wikipedia and to dictionary are by all indicators exactly the people that would have the capabilities and the motivation to contribute. And we need our contributions in order to cover free-handed languages. We need to solve the challenge of how to frame the project and reach them because in our user users, so far, they are the ones who say, oh, I don't need to understand this and go away. That's why it is so important to get framing right, to make it inviting. Here are two early milestones we want to pass next year. Paradigms for inflection and abstract description. The first is the great functions that can generate regular inflections for all kinds of words and languages. These can be used for the lexicographic content in Wikidata or for the inflection tables in the dictionaries. But instead of having the inflections implemented in 160 or so dictionaries independently and templates or modules or manually, we implement it in Wikifunctions and make it available for all dictionaries and also for Wikidata and for abstract Wikipedia. Absurd descriptions. In Wikidata, every item has a description in every language. Before we can generate whole articles for Absurd Wikipedia, we will be able to generate noun phrases and descriptions, they are usually noun phrases. So we aim to make a set of descriptions for Wikidata and not an early milestone. This year, we are focusing on developing Wikifunctions and getting it out. In 2022, we will start adding a focus on Absurd Wikipedia, working on the early milestones of paradigms and abstract descriptions. In 2023, we would finally get to the place where we can create abstract content and where we will be able to read and contribute to the content across many different languages. Where we have a truly multilingual Wikipedia getting so much closer to a world that everyone can share into some of our knowledge. Thank you for your attention. Hello and welcome to Wikimedia. Okay, hello and welcome. Thank you for watching the video. I'm not going to watch it a second time. I think one time is enough. If you want to see it a second time, it's on YouTube. The link will be provided. So first hello to everyone. It's great to have you here. Unfortunately, I can't see almost any of you. I can see the panelists, but I have no idea who is out there. And just relate everything. We will start after this video now with a short introduction of the people on the panel. And then we will go to the questions. And I encourage you all to ask a lot of questions and that we have a lively discussion. Oh, and not just questions, we have also one discussion. I have no idea how to actually enable that, like to make sure that we can have discussions, but we'll go to it. I would suggest let's start with the introduction as said and let's start from the top to bottom left to right. So James, will you head up? Hey there. So I'm James Forrester. I work for the Wikimedia Foundation since 2012. I joined the Wikimedia movement as a volunteer back in 2002. And I've been around a little bit and to a few events. So some of you may know me from that. So I'm the lead engineer. So it's my job to try to turn Denny's product dreams into a software reality, along with the team of other engineers. And I will hand over, I guess, to Lucas. Okay, hi, I'm Lucas. I've been a Wikidata enthusiast for a while, and then eventually started looking into this abstract Wikipedia thing as well, because it sounded pretty interesting. Worked on an alternative implementation that can actually run these functions. If you want to do that outside of a Wiki context, that's fallen a bit by the wayside at the moment. Maybe I'll pick it up again. But I also run a test Wiki called NotWiki Lambda, where you can try out the software if you want. And there's just a big disclaimer on the front page. Please don't take this as the final thing or anything. I didn't even ask the development team if I could start the Wiki. I just put it out there and so far it's been okay. But if you want to see the software as it currently is, then you can use that Wiki. And I think it works more or less at the moment. Over to Geno, I think now. Hello, welcome. I'm Geno. I'm calling from Spain and I am part of the Wikimedia Foundation. Been there for eight months and yeah, all that time part of the abstract Wikipedia team. I'm a software engineer and yeah, working with the team to make this a software reality. So I'll pass it over to Arthur Smith. Sorry, the unmute button is having a little trouble there. Yes, I'm Arthur. So I'm not with Wikimedia Foundation or Wikimedia Deutschland or anything else. Just a outside volunteer, but I have a day job that means I don't get to do much with this, but I've been like Lucas, excited by Wiki data for the past five years or so and have done a lot there. And then I was paying attention when I heard Denny talking about abstract Wikipedia and I actually kind of got into looking at his code that he'd put together as a precursor to this whole Wiki Functions project. And so I've kind of been involved from the start as an outside volunteer doing a little bit here and there, but it's been fun. I guess Nick is next here, right? Hello, user Quiddity, also known as Nick Wilson. Worked with the abstract Wikipedia team as community relations. I live in Canada. I've been a volunteer since 2005. And over to Lindsay. Hello, I'm Lindsay Wardell, pronouncing her. I'm a consultant from the STOT Labs. I started working on this project earlier this year, primarily focused on building the front end so that the functions are createable and executable in a browser. Been lots of fun working on this project, very excited about it. I'll pass to Arthur Lorenzi. Oh, hello. I'm Arthur and I'm from Brazil. And like the other Arthur, I'm a volunteer in this project and I'm doing my PhD and it's on natural language generation. So I'm interested in this project from this point of view and from its community point of view. So anything related to energy, construction grammar or frame that, I'm in. And I'll pass to Adam. Hi, I'm Adam Basso and I'm based from Minneapolis. I am the engineering director at the Wikimedia Foundation, supporting abstract Wikipedia and Wiki functions. I remember when I first learned about Wikidata thinking like, it'd be so cool if we could create a system to write functions to operate on Wikidata. Well, it turned out there were some people thinking about that already. So I'm so happy to be working with this group. Corey? Hello, I'm Ben Basso, apologies. Is this a better volume? This is, this okay. Maybe this okay. We can verbally introduce Corey Masro, software engineer working with the abstract media team. Thank you very much for being here, Corey. Sorry for the technology problems. That's right. It helps us get on to the Q and A a little bit faster. So our first question that came in from the chat was what about cultural differences? Broad abstract problem. Do anybody like to take this? Actually, Corey is looking into this in depth. I just have no idea if he can take the answer. We can try one more time. Am I audible at all? Yes. Okay, sorry. I have been having a lot of trouble with my mic lately as everyone on the team can attest. Yes, so I am also extremely interested in exactly this problem. So I think one of the things that, one of the tensions is always, right now what we have on Wikipedia is the plurality of perspectives. And it would be a shame to lose that. So there are a couple of different ways to look at this. There is some pre-existing work on disinformation, which is basically the problem of, when is information on Wikipedia wrong? But we can also turn a lot of those same techniques around to ask questions like, where is information on Wikipedia different in one language versus a different language? And from there, we can start taking a targeted approach to saying, okay, how do we decide where there is a significant difference between languages? But we actually wanna represent that difference and we actually wanna augment our data set. So it is, and there are also other questions associated with this. So for example, different languages might prefer different narrative structures. They might prefer different article topologies. One language might have a whole bunch of articles on a topic that are linked, another language might not. One article might put, for example, controversies associated with a political candidate under a heading related to their political candidacy, another might make it a top level kind of thing. So there are all these differences. Some of them might be narratively significant in different languages, some of them might not. But what is most exciting to me personally is that this looks like a problem, you know? Okay, if we put all this information in Wikidata and then we start generating articles, we lose diversity. But I think it's also an opportunity because we could say, all right, there's information that might be on one relatively small Wikipedia, but it's actually very accurate about the concerns of that community. And then we can actually use that information to generate articles in other languages, right? So this can actually be not a form of digital colonization, but kind of a megaphone for smaller Wikipedia's. So I'm on it. These are problems that we're trying to think of. And yeah, so yes, cultural differences, we wanna treat them in a respectful manner. And just to add to that, so I agree with everything that Corey says, but also just to add, remember that I've said Wikipedia is not here to replace the current Wikipedia's. It's here to augment it where we have knowledge gaps in the community of Wikipedia. So I totally expect that most articles that are particularly relevant to our culture will have a local override over what's coming from I've said Wikipedia and will have actually a local article anyway. So I have no expectations of very culturally important articles being actually written in I've said Wikipedia for its own culture, but I expect this to be then used in the languages where the content doesn't exist yet. So you can always actually go in and just override this with local content. And to jump even further in. Right now when we think about Wikipedia's, they're agglomerated culturally at a particular level that we call a language version of Wikipedia, but those are pretty arbitrary, right? That we have one English Wikipedia rather than seven. No one has an Indic English Wikipedia, but maybe we should. And content coming out of abstract Wikipedia would have the ability to be localized more specifically than a particular kind of macro language. It might be very specific. You might have something that is West Coast slang, North American English. You might have something that covers all versions and flavors of Chinese. And that would be not for us as coders or system designers to decide. That would be very much for the community to decide what's an appropriate thing idiomatically in terms of coming up with content that works and it balances the work for the community to create it versus the value for the readers of getting something that feels right to them and their cultural context. I was just to finish it. I really, really like this question and want to make sure that it's understood that we are thinking very hard about this. But we're really giving a lot of weight to the question like is that what we're building? Something that can lead to more knowledge equity, to no more knowledge diversity. Overall, is it something that would be used to reduce it? And we are aware that the system that we're building might end up quite powerful and therefore has to be combined with the current ecosystem of care in order not to reduce diversity and reduce the voices in the world. Nick, will you take us to the next question? The next question from chat is can we write functions that produce functions? Not yet, but yes, we will be able to do that. We are pretty close to it actually. Actually, by and in the next phase, we will plan to have to say to give, we separated the development work in the 11 phases. We are currently in, we finished five of those if I'm counting right, are currently in six waves. And so the ability to create functions for a function will be in the next phase. And this will be actually useful for a number of the things that we do, particularly for generics and others. So yes, we plan to have the capability. Next question coming in from chat. How will the new software protect against DDoS? Are Wikimedia servers able to run such amounts of computation in real time? So I guess this is gonna be a question for me. So the quick answer to that question is, we don't know. We have some plans and we hope that they will be sufficient, but we will find out in the reality of production. So to take that in two separate parts. So the code, when you write the code, there'll be a test suite that you'll be able to run it and check that it comes up with those answers. And once it's all gone through and the community has approved it as a function that people can call, those function calls will then be something that anyone on the web can make a request to and also we'll be able to be embedded within Wikimedia articles. And but the results of those functions, we're going to cache those results. So even if it takes five seconds to generate the request response, you only need to do that once or twice for us to have that available. And now that's great for the second time you ask that question, but the first time you ask that question, waiting around five seconds is gonna be a real pain. And so we've got a separate bit of work, which is such fun, which is about rethinking how MediaWiki itself works to allow us to have asynchronous content injection into articles. So you'll press save and the article will show and there'll be a little box that says not available yet. And then after a few seconds, it will then pop in with the actual value. So you can keep editing as normal. You don't have to wait five seconds or five minutes for the page to be ready to save, but it will not take down the site. In terms of how can we prevent against denial of service attacks? So obviously there's gonna be rate limits within that system. And those rate limits gonna apply on a per user, on a per request, on a per function. Lots of different limitations to stop the thing totally exploding, hopefully. And then finally, on the question of, do we have the servers to run that amount of computation? So it's hopefully not going to be in real time all the time or most of the time you're going to get cash results. But also we are not, we are very much able to buy more servers if more servers are needed for the community, right? We're here to support the community. And if more servers is the right answer, then we can do that either by buying them or renting service space in some kind of cloud, whatever is the right approach for what we need to do. And there are also going to be different evaluation engines and different versions of the same function. So it'd be very easy to write a really silly addition function that has a sleep command in it for five seconds and then returns two plus two. And it's up to the community to decide what implementations are going to be approved. But the software will kind of cleverly note, hey, I've got a Python version that returns in a thousandth of a second and a JavaScript version that takes three minutes. So I'll always actually call the Python version and never bother with the JavaScript version, something like that. And I'm sure others might have some thoughts as well. Lucas? Yeah, I can add a bit here that not all of the computations have to happen on Wikimedia servers at all. There are hopefully going to be other programs that can also evaluate these wiki functions functions and some of them might run on your phone, some of them might run on Apple servers running, not Alexa, Siri, that one. And that's also I think part of why these functions can all be written or have many different implementations in many different programming languages, right? Because maybe the thing I'm building rather than age will not be able to support Lua implementations or whatever. But then I will just have to pick other programming languages, but someone else can then run, can then use the Lua implementation, which is maybe more efficient or something, yeah. Anyone further thoughts on this question? Okay, Nick, let's go to the next one. Fourth question is, will it be possible to translate code from a programming language to another? For example, will it be possible to enter a function composition and get the JavaScript implementation? I'm always happy to take the things, but does anyone else want to go for this one? Okay, so, from function composition to get to JavaScript, so starting from function composition is a special case. In general, we do not plan to write translators from one programming language into the other. Having said that, but function composition is not a programming language, it's just composing existing functions. So you could actually look at it as if you have the functions which are used in a composition in a specific language, you could actually compile the composed function from those together. So this is one special case where we could imagine actually creating synthesizing programming code for a specific function based on your composition, which is kind of simple for most programming languages. So we're not promising it for every programming language, but for most programming languages it's quite a straightforward way to do it. But if you, for example, enter the Python implementation, I do not expect us to have a feature that translates that automatically to JavaScript or something like that. So not from one programming language to another, but from composition to a programming language, this can happen in certain circumstances, which I would rather look at as like a compiling installation. So in a very limited yes to this question. I guess in theory someone could write a function that turns Python into JavaScript and put that function on wiki functions. I'm just not sure what it would be useful for. Yes, I see me cry mostly. One thing, Danny, that I found interesting you were talking about is the function composition. If you want, when you're creating a function composition, you can combine different programming languages essentially together into a single composition. So if you have some functions written in Python, some functions written in Lua, some functions written in JavaScript, these can all be brought together in a function composition and executed. So specifically within wiki function, the need to translate between one language and another is minimized in that all of these languages can work together in harmony through the execution of these function compositions. Absolutely right, yes. All right, on to the next question. Once you have function generated labels at wiki data, would it still be possible to change them by hand? You will always be able to overwrite generated description or label in wiki data by hand, yes. So I don't think the idea is the abstract function label would be in a particular language code, a special language code designed to allow. So to be a general thing that could be queried, if there's no fallback or nothing in your language, then it can look at that. But if there is something in your language, it would just use that as wiki data does now. You couldn't say it's going to make it much easier to override automatic descriptions because we have plenty of those in wiki data already. And right now you have to look at the history tab to see, uh-huh. A to the robots edit this such description in 2015. And no real user is going to get upset if I edit it. And I guess that's going to create more of a distinction between the automatic and manual ones. Next question is to Arthur Lorenzi or others who are enthusiastic about the natural language generation aspect, what are your thoughts on the current state of wiki data, lexicographical data and its potential use as building blocks for generated text given statements from the team that it will be used for building blocks? So I would just first clarify that I'm, my research is on constructions, but of course lexical items fill this lots of the constructions. And of course they're essential to build all of the texts. But on the other hand, I think that for, to kick off the project, we actually need like a small set of lexical items. I'm saying that because I'm thinking specifically of very like descriptive sentences. So when we think about the content that Danny, we had on the video, for example, if we're talking like about an entity and giving it an attribute, we don't need a lot of lexical items for that. But of course, in my opinion, what I expect to happen is like abstract wikipedia will develop and we'll need more lexical graphical data and that would cause the community to work more on that. But I think others on the team may have something to add on that. Danny, do you want to talk about the target languages? Sure. So what we did is that together with Wikimedia Deutschland we asked the community to come up with a list of target or focus languages and basically to find communities that would volunteer to work with us, to work with Wikimedia Deutschland on the improvement of the lexical graphical data and wiki data and on the first set of linguistic functions that we will be creating in wiki functions and then to introduce this to the given Wikipedia's. The languages that we have together selected two Hindi languages, Malayalam and Migali and three languages from Western Africa which Hausa, Iqpo and Dagbani. Sorry, I should have, I need a second. Hausa, Iqpo and Dagbani. Dagbani is here particularly interesting because it has a very small language community. But they're also very enthusiastic which is super helpful for us. But it's in general a small number of speakers and which is why we got it a little bit of a stretch language and the idea is if you can make it in Dagbani you can probably make it for many, many languages out here. And we are super happy with the selection of the focus languages and with the work here. So we hope that for those languages we will definitely have very visible progress in the following months. The next question is, when are you planning to start work on functions for natural language generation? I think Corey would love to start like right now or rather a few months ago. We are planning to start this actually very, very soon. So once wiki function is launched we were thinking about like in which domain should we direct our first effort? And my early thoughts were like logic and mathematics are obvious domains and so on. But having now dive a little bit into the user research around wiki functions and into our plans there actually I think that it is much smarter to simply start with the linguistic functions. So basically we will go for the linguistic functions right from the start. Starting with simple morphological functions and then heading up towards temperature generation and others but linguistic functions will be our first focus immediately right after launch. And this is also why paradigms are such an interesting very early milestone because this will be carpeted and it will create more content for us to work with in the next stages. Does anyone want to add something to it after Corey particularly or? All right, I'll jump in with the next question. When will wiki functions be publicly launched? The question asks on incubator but James notes in the etherpad that we won't initially be on incubator. Danny could you give some details about the rough timeline? So yes, as James said, we will not launch on incubator because incubator is for new Wikipedia's and this is a new wiki media project. So incubator wouldn't be the right place for us to launch. We will launch on beta with a demo system and we're planning to do that. So right now the security and performance reviews are still ongoing and depending on the outcome of that and a few other steps we want to launch there. So expect this kind of in the fall. I'm not making any promises but you know roughly around fall maybe. I hope not one of the team. Okay, no one is looking too angry when I say that. And then the project itself will launch when we're ready. I don't want to make any promises about when this will happen. I'm not expecting it this calendar year but also not too much later than that. So yeah, I don't want to make any promises let's see when we're ready but you can actually watch the progress on not wiki lambda and you know weeklies with making really good progress. So I'm confident that we will launch in a reasonable timeframe. If I would make a promise about anyone here hitting me immediately, I do my fingers very much. Before my next wiki mania we will have launched. So I have, I'm pretty confident about that one. The next question is will contributions to the test wiki be visible in the final version or will we need to start from scratch? If by test wiki you mean not wiki lambda and nothing that is on wiki lambda will likely survive to the wiki functions. Sorry Lucas. And this Lucas here disagrees. If you mean the beta wiki, also we don't have any plans of moving any content from the beta wiki to the wiki functions. Obviously the community can override it and just do it because it's your project, not ours. So don't ask us about this but we don't have any plans of copying anything from the beta to wiki function to talk. Yeah, it's open license, you know, you're the community. It's your project. So if you want to, you can do it, we're not planning it. I'd like to point out where we do have a collection of a large number of built in things that are gonna be on the test wiki and they'll be in the live wiki and they'll have the same, the same IDs and all that. But yeah, so at least that part will be the same. The next question and they're coming in faster now. Thank you all for submitting good questions. Will it be possible to import library slash code from GitHub? I'll try to take that. So some of this is gonna depend upon like the licensing details. There'll be things that may be compatible and some things that will be incompatible. We do foresee libraries of functions inside of wiki functions being made available in other platforms potentially. So people might take a set of functions, package them up and put them on some other third party code repository. They add a addendum very briefly or quickly into the etherpad asking how will licenses be handled? Yeah, that's a topic that we're discussing with the legal team here and we'll probably need to have a bit more discussion on that. Next question. How will third party users be able to interact with wiki functions? In many, many, many different ways. So just, I just thought of a few and I hope that the team can add more ideas. So on the one side, all the functions and wiki functions will be under some open source license so that the third party can actually just take that and use it. Also as Lukas pointed out, sorry, Lukas is this way. So it's mirroring different. So as Lukas pointed out, we hope that there will be more different evaluation engines and this means you can just evaluate functions in those different evaluation engines. He already pointed to having an evaluation engine on your phone where you can run functions and so on. One of my dreams is that a spreadsheet, for example, can simply call the wiki function function and use it and show the results there. And many others, anyone wants to add a few more ideas? So there's kind of, it's easily able to separate wiki functions, the media wiki concept from wiki functions, the kind of public API. So there's likely to be something a bit like instant commons that allows you to on your own media wiki installation, pull in wiki functions function calls transparently and simply. I would very strongly discourage people from trying to run their own wiki functions site. The software is all designed much less like wiki data. The function software is designed specifically for our use case and isn't going to be generalizable. But then yeah, there's going to be a public API and people can request through that. And it may be that if people want to make a large number of requests through the API, then it'd be more appropriate to go through wiki media enterprise and whatever that ends up being. But that's not really what we're thinking of right now. And then as Denny said, off-board calculations, if a classified agency, the CIA thinks the code in wiki functions is great and they want to run it on their own data in their own private data center, then that's great as well. The point about the commons is to produce more for more people, not to lock it up at an ivory tower. I very much though, hope that there will be especially hobbyists, smaller organizations and so on using this because to be fair, the big organizations like the CIA or the big tech companies already have access to either a big function library or simply they have enough software engineers to actually do all of these things. It's really, we are enabling now everyone to do the same thing. And we are enabling many, many more people to access this kind of capabilities. One thing that James mentioned is that wiki, the decoded we are writing is particularly good to be run for wiki functions. And this is a situation that is similar to how wiki base was for wiki data a few years ago. Lukas has been, had a very, has been watching this and helping with changing this over the last few years. Maybe you want to add a few words on that. I guess, yeah. So wiki base, the software behind wiki data used to be mainly targeting wiki data and I guess targeting being able to run on the developers local wiki, but not much else. And then this strategy kind of evolved over a few years of encouraging institutions to use wiki base, especially also for data that we don't want in wiki data, maybe for licensed reasons, maybe because it's just too much and too specialized. It wouldn't be valuable there, but then other institutions can start to run wiki base. Now we have a wiki base product manager at wiki media Germany. And so the strategy just shifted in that direction and then the software followed suit kind of and became easier to use in third party installations as well. And I don't currently see where that would happen in wiki functions. I don't see a strong use case for running your own wiki functions, but who knows? Next up is a easy yes question. Strenu asks, so we can all contribute regardless of background? Hopefully. Yes, definitely. And our colleague Aishwarya Vardana is not available today, but Aishwarya is thinking a lot about how we can make wiki functions in abstract wikipedia a more inclusive place for everybody to be able to participate. We welcome technical contributors who wanna help us build the software that will power wiki functions in abstract wikipedia. We wanna have a large community that supports the world, from the world on wiki functions in abstract wikipedia as well. And that really starts with design. Kind of touching on what Denny was talking about in the initial video is we want this platform to be available to non-coders, people who don't have a programming background. And like Adam was saying, Aishwarya and I are working on what that experience looks like for creating new functions and for utilizing the functions for somebody who is not a programmer, who does not have that technical background. So very much we're focused on making sure everyone has access to this technology that we're building. Next question is, other than function composition, what mechanisms of code composition and reuse do you envision? Do you envision supporting things like contracts, interfaces, inheritance, generics? So composition is a very powerful mechanism for reuse. So this is, and as Aishwarya points out, this is one of the main things that we will use. Other than that, we have a separation of functions and implementations which are a lot like contracts, not entirely, because we don't have really like policy and conditions and pre-conditions and invariance, but the interface implementation separation is one way to enable reuse. But so far, I'm trying to shy away from inheritance from inheritance and other things. Generics will support, that's definitely, because this is going to be in the next phase. And yeah, I think those are, this is regarding the soap. Yeah, so it's mostly based on reuse as we know it from functional programming languages plus generics, which are also actually available in functional programming languages. But we currently don't have plans for inheritance or prototype semantics or something like that. Also because those have often far reaching consequences which make, which require you to understand the system as a whole in order to make small changes. We're trying to avoid it. We're trying to make changes as atomic as possible and that you only need to understand as little as possible in order to make change. The next question is would Wikipedia articles be merged to abstract Wikipedia, meaning they would be translated to abstract then deleted from the local language editions which would maximize the amount of information? I assume that's going to be possible, but ultimately the decision lies with the language community for both of these steps. They can decide to contribute whatever they have in the article to the abstract content so that everyone else benefits it, even if they then want to keep their local article. And I'm pretty sure I heard someone mention also that it will be possible to have content not just at the whole article level, but at least on a section or paragraph level as well that you can use just some sections of the abstract content. Yeah, I'll try to dig out the link in a second. We've definitely put a lot of thought into the desire to have local overrides in both directions as much as feasible, ideally making it so that communities can benefit from the baseline content from abstract and then overwrite it when someone appears who wants to write a more detailed version in their local language. I think it's also worth pointing out that most articles that exist in the Wikipedia's various languages do not exist in any one given language. Even English Wikipedia only has about one third of the topics that are covered overall. So there will be thousands, hundreds of thousands of articles that do have a lot of overlap but there'll be millions that only exist in one language and so if there's an abstract Wikipedia article that's written for it, suddenly it will be available in every other language too. Next question is, will you choose one Python version or expect it to work for all, e.g. if Python version two versus Python version three happens again in the future? So I'm delighted to grab this one to say the answer is no and no. So one of the things that was really fun early on was to declare on my own authority that we're not gonna support Python two ever, sorry, Python two is end of life already. So we're gonna start with Python three, probably 3.5 depending on exactly when we launch but we will support and the whole thing is built into the system to support multiple levels of a programming language. So there'll be the concept of Python and then below that the concept of Python three and then below that the concept of Python 3.7. And so if you write some code that runs in Python 3.6 it will not automatically try to run it as Python 3.7 but you as a community member might be prompted to say, hey, we did a test run and all the tests passed in Python 3.7 do you want to declare this as also Python 3.7 or something like that? But there won't be a single Python version or JavaScript version or whatever and we won't just expect people's code to magically work but then that's what the test suites are for and the community control. Hope that answers the question. I think with Lua that would be fairly interesting because correctly we can use already not on the latest Lua version but also the Lua project says something like just consider them different languages and it's okay to stay on the older one and we'll still provide security fixes. So I guess you would also have different levels there eventually. And there's a distinction between what languages you can write stuff in and what languages we will execute things in. So you might well be allowed to write Python 3.5 for the next 10 years but it goes end of life next week. So we never run it, something like that. And that would then be a community concern about whether you want to write an abuse filter to say, hey, don't bother writing in this language because it will never get used, something like that. I think also it's important to add that one of the future efforts that we'll be thinking of would be to make the creation of different evaluators and different versions of languages to be something also taken over by community and to make that as likely as possible so that we don't get stuck on different versions and stuff like that. And that creation of evaluators to be the most dynamic as possible based on definitions and be able to have that supported by the same testers and stuff. So I think that would be also very interesting. Next question is, what fixed points do you envision in function self-composition? This is, we don't know yet in short. We hope to be able to capture it on like there is a fixed point at all and we will report on that and I'll lead back and stuff like that. But we're still working on the code that is doing the composition and how are we? In fact, only last week we managed to have if the if function lazy enough that it doesn't run on both branches simultaneously. So we don't know yet where the fixed points will be and we hope that we will be able to and this is something also where we hope that over time we will be able to push it further and further out. Obviously, thanks to Girdel it will never really get a perfect system but I hope that we can start with something that works decently well for most use cases and then we can push it further and further out in order to see how far we can get. And at some point, I really hope that people from the PR research community will come in and help us trying to figure out how to do even more funny things and how to get to even more powerful systems. The next question is, so can we replace Lua with wiki functions? I'm presuming this question is in relation to Lua as used on Wikipedia's and our other Wikipedia projects as modules. Anyone else wants to take it? I'll take it. So the quick answer is yes. The longer answer is probably yes. The idea is that we'll have a single wiki of functions, not 20 of them. So if you're on German Wikipedia and you have a local Lua script that does something useful and someone on English has the same Lua script or equivalent Lua scripts, then ideally you'd only end up with one function but you might end up with more than one because something needed on German is more complex than the use case on English or vice versa or they don't align and that's also fine. So it's not like everything currently written in Lua is gonna get replaced. Another point is that the output of wiki functions is raw text, it's not wiki text. So at least for now, security issues. And so if you're using Lua to generate an info box, outputting bits of a table, for instance, which I know happens alarmingly frequently, then that isn't something that we will support and you'll need local Lua for that still. Long-term, we may fit that use case as well. Yeah, hello, do you want to? Yeah, so I was mentioning, we had some months ago, I don't remember when was this, it was maybe half a year ago, we had an internship called Orychi where a couple of interns work with us to analyze the Lua modules and to figure out which ones were approachable to bring into wiki functions. We do have, well, their work was published in GitHub, in a repo. I don't know how to share that with the community that is listening right now, but it was really interesting. And yeah, they gave us a really, really good insight on what all things we can do. The next question, for context, I put a link in the, the remote chat for the Orychi work. The next question is, are there existing function catalogs that can be imported or referenced as anchors? Is there a way of indicating equivalents when implemented in X environment? So I was asked if I was, I want to take this question. I'm not quite sure what the second part means. For the first part, I guess not wiki lambda right now. I said everything there is CC zero. So if you want, and if anyone has put useful functions on there, which I'm not sure right now, you can take those. Otherwise, I guess this also comes down to the license question again. What licenses are these other function catalogs under? There's also, I think, Denny, you mentioned in one of the wiki newsletters that the goal of wiki functions is something different than something like Rosetta Stone, I think it's called, which is to have the same functionality in as many languages as, as many programming languages as possible. That's not really wiki functions goal. So that would not be something you would directly want to import, I guess. What we will have though is a function definition is actually independent from the implementation. Implementations can be in different languages. So if you want to say that these two functions are the same and so these two implementations are actually the same function, they would actually implement the same function definition and then it's just say, okay, and these are possible alternative implementations. And then the evaluator can decide which one of those to run. And this is how you would indicate that two implementations are equivalent but just implemented in different languages. If that is what the question is about. Regarding function catalogs, I don't think this idea is really widespread outside of it but you have a lot of APIs that basically provide functions and I think that we will take a lot of those as inspiration. We don't plan to import any of these also because who knows how our legal situation will look like but I hope that many of those can be easily re-implemented with wiki functions. So we can take as an inspiration what should actually be in such an API function catalog and so forth. And about those having different implementations, I assume it's also going to be possible to actually run multiple implementations side by side and then check did they actually return the same result because all these functions are supposed to have to be deterministic and have no side effects anyways. So you can actually check, are they behaving correctly? And if they return different things than you say, oops, someone declared this as the implementation of the wrong function or something. Yeah, as to linking with external implementations of our function definitions, that's theoretically possible but in practice what we're doing is pretty bespoke and unlike what other people do. And so it may not in practice be something we can meaningfully do. Next question. Since most cloud platforms charge for working with lambdas, AKA functions, if this is going to be a free service, how will you ensure it does not suffer the tragedy of the comments, i.e. being used for mining Bitcoin, smart contracts, et cetera. And there was a related question from another user or editor, what protection will there be against exploits, e.g. client-side exploits and crypto mining? Yeah, so I'll grab this one. So the first answer is, this is going to be a bit of a challenge. We think there is potential actual real world use case for an actual coin miner example code on wiki functions to illustrate the article about coin mining. And so we can't just have a blanket ban on anything that does stuff with prime numbers is bad. But in practice, coin mining uses a lot of CPU and those requests all have to get agglomerated together and we're going to have very strict limits in terms of how long your function can take to respond and how many times a given user can actually call the same function with different inputs. So hopefully that's going to be sufficient along with all the other remediation issues we've got to prevent too much abuse. But in practice, I'm sure people will try in much the same way that people try to announce that people are dead when they're alive or alive when they're dead, falsely editing Wikipedia, right? And so we need to provide a good, robust system to the community to automatically ideally detect those and stop people from abusing the system, but also to flag in recent changes in places like that so that the community sees issues. And I don't expect that the things we come up with are going to be a perfect list. There's always a clever person looking to abuse things in the future and stopping them is going to be fun. In terms of client side exploits, so all the code's going to run in isolated containers on the backend which don't have any network access at all except for outputting their response which is going to be plain text as displayed to the user. Obviously, because third parties can use us, nothing stops them from interpreting the raw text as HTML and letting themselves get rooted, but they're going to be great big warnings over the API saying the response is not safe and should always be treated as raw text that is, you know, should be escaped or things like that. Have that answers the questions. Sorry for the pause. Next question. Will users need special rights to create functions and will it be required to reach a community consensus to create them as in the case with properties on wiki data? So there will be, we will decide certain rights and the community will ultimately decide how exactly those rights will be given and to whom, like if you need to be, have specific roles and so on. So I hope for creating functions, it will never be in this situation that you actually need more than just being a user of wiki functions. This might be different for approving implementations and so on to make sure that some of the, basically some of the exploit, megatation patterns that James was just describing rely on the fact that not every implementation can be run by everyone immediately, but it's maybe some step of improvement. Just still designing those, we will need to figure out exactly and work together with the community in order to figure that out how exactly the rights will work. Next question. Code requires maintenance. How will this be maintained once things change if the original developers are gone or if the linguistic experts are gone? Interesting that we actually have this, this is two questions, right? There's the platform software and linguistic experts and then there's the community software and linguistic experts which both have, I think, normal answers. The community has to handle the stuff in the community. If a function goes stale, if a function on wiki functions goes stale, that sort of means the community isn't interested in it anymore. But otherwise, I mean, we have a team who's working here and we have normal practices. I don't know if there's much more I can say about that, but yeah, there are processes on software teams for doing this kind of rollover, but it is interesting how we have two questions here and I wasn't sure which one to answer. Also, it's basically similar to Wikipedia and Wikipedia articles. We expect that once the original authors and maintainers of Wikipedia article are gone, hopefully other people will take in this role and continue it. And otherwise someone will come around and see, oh man, this is getting stale. We need to do something about it like remove it or whatever. So wiki functions will not be different than any other wiki media approaches in this regard. I think also the same way that we were talking before about the work that is going on with UX, one important part of that work is gonna be to be aware that these functions need maintenance and to make it more easy for finding people that maintain those functions and having the current highlights of the things that are getting stale, as Corey said. Yeah, I think there's a lot of UX work there also. Next up, I'm gonna jump around a little bit to split up who's asking the questions. We got a number from individuals. Will it be possible to write tests for functions? And will it be possible to use the same tests for different implementations of the same function? Talk a bit about this one. So this is actually what I've been working on right now is getting test runners situation set up for implementations. So when a function is created, there are multiple implementations for it like we've been saying. Could be multiple programming languages, could be the same programming language done in different ways. With that, each function has a series of testers to validate that the function is working as expected. Each of those testers is run against each individual implementation. So if I have a function that's written in Python, JavaScript and Lua and I have a tester to validate that function, that tester will be run against JavaScript, Python and Lua and the test result will be displayed in the UI for the user. This test running is handled on the server. The idea is for that to be cached unless something in the function or the implementation changes or the tester itself. But yes, short answer, yes. Every implementation, every function could have a series of testers and each of those testers will be run against each individual implementation. Next question. If you take a typical average Wikipedia, how long would he or she need to learn making the use of Wiki functions? There's a multi-level way to answer that one. So I will take the most nicest interpretation of this question for us, which is, how long will it take to use Wiki functions, for example, in a Wikimedia project? And we hope actually this will be super easy. So in the end, you will hope that you can basically drop a function call into, so you're in visual editor, you'll click insert here a function call and then you choose the functions, you enter your arguments and click save and it will be used. And this should be basically a no learning, almost this should be an experience that comes like out of the box and you don't need to. So for the average Wikipedia, I expect this experience to be completely seamless and super easy. There's not completely different interpretation of the whole thing, which is like, okay, how long will the average Wikipedia take to actually code up new functions, great implementations and testers and so on. This will be a bit more complicated in previous use case, but Aishwarya and others in the teams, we didn't say I'm working very hard on making this as inclusive as possible and to make it as easy as possible to get into this without long training and so on. And we hope to be easier accessible than most programming languages are by far. I think I missed this one on the key earlier. Next question. How will the functions apply to articles on topics that are subject to cross wiki conflicts? I think it's very quickly. Topics that are subject to cross wiki conflict probably already have local articles in their given languages. So they would just overwrite the content from Upset Wikipedia and would not have to be resolved on the Upset Wikipedia level. And so how do they get to agreement on Upset Wikipedia? I could give a very long answer detailing my background with the creation Wikipedia, serving Wikipedia and how did it work to get on English Wikipedia? You know, people actually get to agreement if they have to, even if it doesn't always propagate into the local Wikipedia. So yeah, we'll be using the same mechanisms that we currently have for people to come to agreements on their respective Wikipedias. I'm happy to answer this later in detail. I joined the post-discussion room if you want. Next up is a two-parter or two people have asked similar questions. Well, I will combine them. Some design patterns and functional programming techniques do not return a simple type. Your demo shows that the functions are typed, but many languages do not enforce this. Won't this force the Python slash JavaScript developer to work like they are using Java or C++? And then a similar question. Will Wikifunctions be strongly typed? What data types will Wikifunctions support? Will there be functions for reversing a linked list, balancing a binary? Did Dejikstra's algorithm? I can take a stab at this one. So one thing to note here is there's a really good design principle in programming, which is to be generous with your inputs, but stringent with your outputs. And I think there are a couple of ways that our execution model could support greater levels of generosity on output, but in general, it's very easy right now to take in any kind of input. I can write a function that accepts basically any kind of object and translate it into the appropriate Python or JavaScript type. Returning an output that can be of any type at all is a little bit trickier. And we, that's still, I think, correct me if I'm wrong, but it's still a bit of an open question. We have one way of doing it right now that is subject to change depending on how our function model evolves. But also, again, I would note that if you are returning things of any old type from Python or JavaScript, that is maybe not the best thing to do. So it's not necessarily, I think, that important to support that. But yeah, so it's a bit of an open question, but I would say that the output is the part that's more strongly typed. But of course, you can internally work with Python and JavaScript as freely as you like if you wanna have multiple functions in the same execution environment. As far as the built-in convenience functions for things like reversing lists, balancing binary trees, I don't, or Dijkstra's algorithm, I don't think we intend to build those as a team, but the community will almost certainly make those a very high priority. So I would expect that we'll see those functions relatively quickly. I think also considering we're working with very small functions that are supposed to interoperate, it's important to have a very strong and clear API between each of those functions. So if you write a function that returns a string and you're wanting to return an alternative object in case something goes wrong, that might not be the best case for working inside of a multi-language paradigm that like we're setting up. Next question, which I'll profess with, or before I will mention that we have only eight minutes left, so we will answer as many as we can and then continuing answering either in the etherpad or in our mailing list or whilst wandering around Wikipedia and talking to you all. The question is for language like Hebrew, morphology is highly irregular. External to Wikipedia, morphology is used 100 plus tables just for verbs and nouns are more complex. So will there be database support for such cases? Well, I think that's necessary in the long run, I think from the, to start of the project, we can rely on some functions to do it. And of course, they're gonna make mistakes, but yeah, in the long run, I see no other alternative than having databases for irregular inflections, for example. This is what lexographical data and wiki data is for, we hope to have the regular forms in there, definitely. Next up, how will this relate to all from alpha website? Well, wiki functions will be an editable website, a resource that everyone can share and everyone can create new functions, call functions, and where the implementations of the functions is openly available and can be reused in many other different circumstances. So this is, so there's a many big differences to what well from alpha is doing. The other main difference is that our main driving use case for wiki functions is really the natural language generation case, and that we want to build a community that will support this case, whereas well from alpha is much more geared towards scientific questions and higher mathematics. But if, yeah, we both run functions, that's the similarity. Next question, can functions return images like SVGs, graphs, maps? Not yet, but eventually I very much hope so. Yeah, and binary encoding of data and so on and so forth. Just because we're limited to text right now doesn't mean we will long-term, but let's not build like augmented reality functions first. Let's work on the things that support our existing text projects. Next question, a better framing of an earlier question that was asked. If a community was eager to adopt abstract Wikipedia content, to what extent would the abstract Wikipedia slash wiki functions software help them, perhaps via one click or bots? That's still a little bit far away in the future. There's something that we need to decide in basically 2023. And I hope that there will be actually like one click solution to that, that we won't need a bot solution that could be a little bit disappointing. And there might be even a no click solution that a certain community, that a certain Wikipedia might opt into display the wiki functions, sorry, the abstract Wikipedia content every time they don't have an article themselves so this would be something that Wikipedia might decide to do wholesale. And so even have a no click solution to provide more content. But really that's a discussion that we need to have as a community and that will happen in a year or two and figure that out. Yeah, but that's similar to article placeholder which already exists and generates some very rudimentary content based on wiki data and that gets indexed and is discoverable via the search as well. So there's precedent for having that without even a one click something. Yeah, perfect similarity. Thank you. Next up and with a three minutes left will the interface be user friendly like wiki data, which is disputed so that people with little to no programming knowledge can contribute in some way. That is the goal. Yes, I'm working with Aishwarya who's not here today designs for building the user interface so that it's friendly to people with little or no programming experience both for finding functions, putting functions together and writing their own functions. So the goal is yes. Next question. How will we know the environment is reproducible and robust? If a common function needs to be dropped say due to rights or a community's decision it would be disastrous for all functions that are composed it. Unit tests are insufficient especially when there is environment and side effects. I can grab this quickly. So I think there are two parts to this question. So one of them is how can you reproduce functions and how do you know that they're reproducible? So Wikimedia Foundation is absolutely committed to open source. All of our code will run on open source Docker images that you'll be able to currently Docker who knows what technology next week but Docker images you'll be able to download. There may be very occasional times when there are security incidents that mean there's some non-public code in that image but otherwise the public images will be the real images running production. So you'll be able to verify when we say one plus one is two you'll be able to run that code locally and get the answer three and complain. But on the more substantial question around robustness of the function environment that we produce one of the things we're looking to do is to provide quite a lot of usage data to editors and readers on the on the Wiki saying, hey, this function is actually used 30,000 times a day or something like that. So that people can understand the scope potential scope of their impact. And we can split that down by source and by composition like this is used inside this composition or it's used directly or whatever. I'll show you to the wrap up now. Okay. So yeah, we're running out of time. Thank you so much for your questions. This was great. I'm super excited to see this much interest. Even though I can't see you are here which is really, really unfortunate. I would love to know to see your faces and to talk with you personally. Some of us will join in the REMA we'll be around for Wikimania. Please contact us talk as I talk with us more. Also come join our mailing list that the ISC group, the other groups that we have watch our pages and feel free to reach out. Thank you all for being here. And yes, have a great Wikimania. Thanks everyone.