The on-wiki version of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-06-07
--
Communities will create (at least) two different types of articles using
Abstract Wikipedia: on the one hand, we will have highly-standardised
articles based entirely on Wikidata; and on the other hand, we will have
bespoke, hand-crafted content, assembled sentence by sentence. Today we
will discuss the first type, and we will discuss the second type in an
upcoming newsletter.
Articles of the first type can be created very quickly and will likely
constitute the vast majority of articles for a long time to come. For that
we can use models, *i.e.* a text with variables. Put differently, a text
with gaps which get filled from a different source such as a list, along
the lines of the mad libs <https://en.wikipedia.org/wiki/Mad_Libs> game. A
model can be created once for a specific type of item and then used for
every single item of this type that has enough data in Wikidata. The
resulting articles are similar to many bot-created articles that already
exist in various Wikipedias.
For example, in many languages, bots were used to create or maintain the
articles for years (such as the articles about 1313
<https://www.wikidata.org/wiki/Q5735>, 1428
<https://www.wikidata.org/wiki/Q6315>, or 1697
<https://www.wikidata.org/wiki/Q7702>, each of which is available in more
than a hundred languages). In English Wikipedia, many articles for US
cities were created by a bot
<https://en.wikipedia.org/wiki/List_of_Wikipedia_controversies#2002> based
on the US census, and later updated after the 2010 census. Lsjbot
<https://en.wikipedia.org/wiki/Lsjbot> by Sverker Johansson is a well known
example of a bot that has created millions of articles about locations or
species across a few languages such as Swedish, Waray Waray, or Cebuano.
Comparable activities, although not as prolific, have been going on in
quite a few other languages.
How do these approaches work? Assume you have a dataset such as the
following list of countries:
Caption
CountryCountryCapitalPopulation
Jordan Asia Amman 10428241
Nicaragua Central America Managua 5142098
Kyrgyzstan Asia Bishkek 6201500
Laos Asia Vientiane 6858160
Lebanon Asia Beirut 6100075
Now we can create a model that can generate a complete text from this data,
such as
“*<Country>* is a country in *<Continent>* with a population of
*<Population>*. The capital of *<Country>* is *<Capital>*.”
With this text and the above dataset, we would have created the following
five proto-articles (references not shown for simplicity):
*Jordan* is a country in Asia with a population of 10,428,241. The capital
of Jordan is Amman.
*Nicaragua* is a country in Central America with a population of 5,142,098.
The capital of Nicaragua is Managua.
*Kyrgyzstan* is a country in Asia with a population of 6,201,500. The
capital of Kyrgyzstan is Bishkek.
*Laos* is a country in Asia with a population of 6,858,160. The capital of
Laos is Vientiane.
*Lebanon* is a country in Asia with a population of 6,100,075. The capital
of Lebanon is Beirut.
Classical textbooks on that topic such as *“Building natural language
generation systems”
<https://en.wikipedia.org/wiki/Special:BookSources/978-0-521-02451-8>* call
this method *“mail merge”* (even though it is used for more than mail). A
model is combined with a dataset, often from a spreadsheet or a database.
This has been used for decades to create bulk mailings
<https://en.wikipedia.org/wiki/Mail_merge> and other bulk content, and is a
form of mass customisation
<https://en.wikipedia.org/wiki/Mass_customization>. The methods have become
increasingly complex over time and are able to answer more questions: How
to deal with missing or optional information? How to adapt part of the text
to the data, *e.g.* use plurals or grammatical gender or noun classes where
appropriate, *etc.*? The bots that were mentioned above, which created
millions of articles in various languages on Wikipedia, have mostly worked
along these lines.
For a great example of how far the model approach can be pushed, consider
Magnus Manske’s Reasonator <https://meta.wikimedia.org/wiki/Reasonator>,
which, based on the data in Wikidata, creates the following automatic
description for Douglas Adams <https://reasonator.toolforge.org/?q=Q42>:
*Douglas Adams* was a British playwright, screenwriter, novelist,
children's writer, science fiction writer, comedian, and writer. He was
born on March 11, 1952 in Cambridge to Christopher Douglas Adams and Janet
Adams. He studied at St John's College from 1971 until 1974 and Brentwood
School from 1959 until 1970. His field of work included science fiction,
comedy, satire, and science fiction. He was a member of Groucho Club and
Footlights. He worked for The Digital Village from 1996 and for BBC. He
married Jane Belson on November 25, 1991 (married until on May 11, 2001 ),
Jane Belson on November 25, 1991 (married until on May 11, 2001 ), and Jane
Belson on November 25, 1991 (married until on May 11, 2001 ). His children
include Polly Adams, Polly Adams, and Polly Adams. He died of myocardial
infarction on May 11, 2001 in Santa Barbara. He was buried at Highgate
Cemetery.
If we were to say that this is merely better than nothing, I think we would
undersell the achievement of Reasonator. The above text, together with the
appealing display of the structured data in Reasonator, leads to a more
comprehensive access to knowledge than many of the individual language
Wikipedias provide for Douglas Adams. For comparison, check out the
articles in Azery <https://az.wikipedia.org/wiki/Duqlas_Adams>, Urdu
<https://ur.wikipedia.org/wiki/%DA%88%DA%AF%D9%84%D8%B3_%D8%A7%DB%8C%DA%88%D…>
, Malayalam
<https://ml.wikipedia.org/wiki/%E0%B4%A1%E0%B4%97%E0%B5%8D%E0%B4%B2%E0%B4%B8…>
, Korean
<https://ko.wikipedia.org/wiki/%EB%8D%94%EA%B8%80%EB%9F%AC%EC%8A%A4_%EC%95%A…>,
or Danish <https://da.wikipedia.org/wiki/Douglas_Adams>. At the same time,
it shows errors that most contributors wouldn’t know how to fix (such as
the repetition of the names of the children, or the spaces inside the
brackets, *etc.*).
The Article placeholder
<https://www.mediawiki.org/wiki/Extension:ArticlePlaceholder> project has
partially fulfilled the role of filling content gaps, but the developers
have intentionally shied away from the results looking too much like an
article. They display structured data from Wikidata within the context of a
language Wikipedia. For example, here is the generated page about
*triceratops* in Haitian Creole
<https://ht.wikipedia.org/wiki/Espesyal:AboutTopic/Q14384>.
One large disadvantage of using bots to create articles in Wikipedia has
been that this content was mostly controlled by a very small subset of the
community — often a single person. Many of the bots and datasets have not
been open sourced in a way that someone else could easily come in, make a
change, and re-run the bot. (Reasonator avoids this issue, because the text
is generated dynamically and is not incorporated into the actual Wikipedia
article.)
With Wikifunctions and Wikidata, we will be able to give control over all
these steps to the wider community. Both the models and the data will be
edited on wiki, with all the usual advantages of having a wiki: there is a
clear history, everyone can edit through the Web, people can discuss, *etc.*.
The data used to populate the models will be maintained in Wikidata, and
the models themselves in Wikifunctions. This will allow us to collaborate
on the texts, unleash the creativity of the community, spot and correct
errors and edge cases together, and slowly extend the types of items and
the coverage per type.
In a follow-up essay, we will discuss a different approach to creating
abstract content, where the content is not the result of a model based on
the type of the described item, but rather a manually constructed article,
built up sentence by sentence.
*Development update from the week of May 27:*
- The team had a session at Hackathon, which was well attended (about 30
people). Thanks to everyone for being there and your questions and comments!
- We also had follow-up meetings with User:Mahir256, to improve
alignment on the NLG stream
- Below is the brief weekly summary highlighting the status of each
workstream
- Performance:
- Observability document drafted.
- Updated Helm charts for getting function-* services in staging.
- Completed performance metrics design and shared for review
- NLG:
- Scoped out necessary changes to Wikifunctions post-launch
- Metadata:
- Started recording and passing up some function-evaluator timing
metrics to the orchestrator
- Experience:
- WikiLambda (PHP) layer has been migrated to the new format of
typed lists
- Improved the mobile experience of the function view page
- Transitioned the Tabs component to use Codex's, thanks to the
Design Systems Team.
- Design: Carried out end-to-end user flow testing in Bangla.
*(Apologies for this update being late. We plan to send out another update
this week)*
The on-wiki version of this newsletter is here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-06-10
--
Design researcher Jeff Howard did another round of research
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-09-24> in
order to prioritize issues in the run up to launch, and beyond. The full
report of the user research has been published
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Design/Wikifunctions_usa…>
on
Meta. Aishwarya, the designer on the Abstract Wikipedia team, has read and
analysed the research results, and summarized them in a slide deck
<https://commons.wikimedia.org/wiki/File:Wikifunctions_usability_tests_2022_…>.
This week, Aishwarya presented the deck to the team, and we are offering
here a short summary of the presentation.
The goal for designing the function page is two-fold: to be understandable
and usable to technical people of all backgrounds, and welcoming to people
with low levels of programming expertise. Technical contributors should
understand the function creation workflow and the Wikifunctions mental
model. Seven technical participants were interviewed using Aishwarya’s
designs in Figma
<https://www.figma.com/proto/05qjdoiV05MtZD2vEfbDDe/User-testing-function-fl…>
(click
anywhere on the screen to progress through the slides and remember to
expand your window).
The interviewees raised many great questions, validated a lot of our design
work, and identified several areas for improvement. Overall, the report
validated that we have met the stated design goals of the user interface
being understandable and usable for technical people, but the report also
highlighted that the contributors did not really understand the function
creation workflow and the general Wikifunctions mental model. In short,
they could get everything done, but were often confused about what they
were doing and why it was presented in that way.
I will not go into the many things that worked out well. You can read about
them in the full report and also in the slides. I do want to call out the
praise for the work summary diagram, which is consistent with many other
reactions we also got in the chat and in other interactions with Wikimedia
community members. I also want to use the chance to congratulate Aishwarya
on her design work, and seeing it validated so positively. We are all very
much looking forward to getting the implemented design out there for you to
play with, and learning more about how we can improve it.
Two points were called out by the interviewees in particular as causes of
surprise or confusion: the split between function definitions and their
implementations, and the multi-lingual nature of Wikifunctions.
In Wikifunctions, we allow each function to have several implementations
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-06-17>. We
achieve this by having implementations be their own pages on Wikifunctions.
Such a separation is not a novel concept: programming languages such as C++
or Ada had header and implementation files for decades, and object oriented
languages <https://en.wikipedia.org/wiki/Object-oriented_programming> have
interfaces that can be implemented by different classes. But interviewees
have repeatedly wanted to jump right into providing the implementation.
They were confused that they could publish a function's definition even
before having provided an implementation. This was also a request we have
seen in previous user tests.
As a side remark, the little word *“publish”* really did a lot of heavy
lifting here. A long time ago, Wikipedia used to use the word *“save”* for
the button that let the contributor store an edit, and this was changed to
*“publish”* in 2017, based on user research that found wiki users surprised
and alarmed that merely 'saving' an edit would put it online, in public,
for everyone to see, forever. This user study reiterated the point that the
word *“publish”* makes it clear that the contribution will indeed go live
to the whole world. But at the same time, several interviewees felt that
just a function definition, without any implementations yet, didn’t seem to
be useful to be published. The word *“publish”* really brought out that
contrast, and helped us identify this discrepancy in the user’s mental
model.
The second point that raised quite strong reactions was the multi-lingual
nature of Wikifunctions. That is one of the points that is often questioned
in the design of Wikifunctions, often unprompted: why does it have to be
multi-lingual? Why labels in different languages? Doesn’t everyone who
wants to code just learn English? To quote one of the interviewees, *“usually
people who speak other languages are just expected to learn English to
code”*.
Because the world of coding is indeed so English-centered, it is very
difficult to find people with coding experience who don’t speak basic
English, and indeed all interviewed contributors spoke English.
There have been a number of research studies showing that the
English-centricity of programming is a major barrier
<https://dl.acm.org/doi/abs/10.1145/3173574.3173970> for many people.
People who can use their own language to code achieve results faster
<https://dl.acm.org/doi/abs/10.1145/3051457.3051464>. For parents that
don’t speak English, it is more difficult to help their children
<https://dl.acm.org/doi/abs/10.1145/3173574.3174196> to learn programming.
Based on these and other research results, we choose to intentionally
deviate from the recommendations of our own user research, as we believe
that this aligns better with the Wikimedia 2030 movement strategy
recommendations
<https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2018-20/Recomme…>,
particularly towards knowledge equity.
There were many smaller, but very good points raised. The contributors
asked for a space to describe the functions in more detail (that’s planned
for Phase ι
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Phases#Phase_%CE%B9_(iot…>,
which is up next in our development plan). The term *“aliases”* confused
users. The list of types was too simple. The example table was identified
as a place that probably won’t scale for complex entries. The difference
between the words *“available”* and *“proposed”* and *“verified”* in the
tables showing implementations and testers was confusing. And there were
quite a few more.
We also identified a number of larger areas that could be improved: making
the use of language more consistent throughout, displaying more meta-data
immediately, and improving the text to make the distinction between
definitions and implementations clearer. We are going to work on these
design challenges.
We are relieved and pleased to see that the designs allowed all the
contributors to fulfill their tasks. We are more than excited to implement
these designs, and get them to you. We would love to hear from you, if you
have ideas or suggestions around the issues discussed here, or in the full
report.
Thanks to all the contributors who were interviewed, thanks to Jeff for
performing the research, and thanks to Aishwarya for summarizing the
results.
Updates as of June 3: Fix-it week
- May 30 – June 3 was a ‘Fix-it’ week for the Abstract Wikipedia team.
During this week, the team paused the development of new features and
focused on tasks related to technical debt.
- Design update: This week, the team kicked off the design work for the
‘lists’ component.
The on-wiki version is available here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-05-27
--
Our Google.org fellow, Ariel Gutman
<https://meta.wikimedia.org/wiki/User:AGutman-WMF>, has recently authored a
proposal of an architecture for the NLG system
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/NLG_system_architecture_…>
of
Abstract Wikipedia.
The proposed architecture is driven by 4 main tenets:
1. *Modularity*: the system should be modular, in that various aspects
of NLG (e.g. morphosyntactic and phonotactic rules) can be modified
independently.
2. *Lexicality*: the system should be able to both fetch lexical data
(separate from code), and rely on productive language rules to generate
such data on the fly (e.g. inflecting English plurals with an -s).
3. *Recursivity*: due to the compositional and recursive nature of most
languages, an effective NLG system would need to be recursive itself.
4. *Extensibility*: the system should be receptive to extension both by
linguistic experts and technical contributors, as well as by non-technical
and non-expert contributors, working on different parts of the system.
These considerations lead to a proposal of a "pipeline" system, in which an
input Constructor is being processed by different modules (corresponding to
various aspects of natural language) until the final output text is
rendered.
[image: A proposal of an NLG architecture for Abstract Wikipedia.svg]
<https://meta.wikimedia.org/wiki/File:A_proposal_of_an_NLG_architecture_for_…>
In this pipeline dark blue forms are elements which would be created by
contributors to Wikifunctions (rectangles) or Wikidata (rounded
rectangles), while the light blue elements represent function or data
living within the Wikifunctions orchestrator.
A key aspect of the system are the "templatic renderers". Wikifunctions
will provide a specialized *templating language*, developed in-house, which
should enable even non-technical contributors to write renderers for their
language. These renderers will be supported by lexical data from Wikidata
and Universal Dependency-style grammatical relations, which would be
defined within Wikifunctions by linguistically-interested contributors.
We will be glad to hear any feedback from you on the proposal's talkpage
<https://meta.wikimedia.org/wiki/Talk:Abstract_Wikipedia/NLG_system_architec…>,
in particular about the idea to develop an in-house templating system.
Further updates for last week:
- This week, the team held its first Deep Dive session. We presented our
project OKRs and received feedback from leadership
- The team spent time this week preparing for last weekend's Hackathon:
- There was a presentation and Q&A about Wikifunctions
- A few Phabricator backlog tasks were identified and tagged for
Hackathon participants
Below is the brief weekly summary highlighting the status of each
workstream:
- Performance:
- Made progress on Beta cluster setup: orchestrator and evaluator
services now update automatically to the latest image
- NLG:
- Completed the initial draft of the NLG system architecture design
document
- Metadata:
- Partially completed the front-end code to accommodate both forwards
and backwards compatibility for the old & new metadata formats
- Experience:
- Made more progress for function view and editor implementations for
mobile
- Completed function-schemata migration to Benjamin arrays
- Handed off designs for 'Text with fallback'
The on-wiki version of this newsletter issue is available here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-05-20
--
Last week, the WMF staff on the Abstract Wikipedia team met in person for
the very first time. Given that we are spread out over Europe and the
Americas, New York City was chosen as an easy to reach point for the
members of the team.
The Abstract Wikipedia team was set up in the middle of 2020, after the
COVID pandemic had already led to restrictions on travel, office work, and
meetings, particularly internationally, and so this became our first chance
to meet each other.
Back row, from left to right: Geno, Cory, Denny, James, Mariya, Nick.
Front row: Julia, David, Luca.
Unfortunately, Cai and Aishwarya could not join us.
We used the time to build team cohesion and discuss our processes. We
learned a lot about each other. I am particularly thankful to Mariya for
leading a session where we explored and explicated individual preferences
about working behavior, which will help us to work together. It was also a
great time to socialize and get to know each other.
We discussed what it means for Wikifunctions and Abstract Wikipedia to be
projects that take diversity, equity, and inclusion seriously, and how to
measure that and hold ourselves to account. We will publish more about the
results from that work session soon, in order to gather wider input.
Another session was a "Wizard of Oz"
<https://en.wikipedia.org/wiki/Wizard_of_Oz_experiment> session, where we
simulated the generation of some article content, and were happily
surprised about how well that worked out. We will also write this up in
more detail and publish it in one of the future newsletters.
We also celebrated ten years of James Forrester being with the Wikimedia
Foundation. Thank you James for your indispensable contributions to the
Foundation and the movement, in your many different roles. The Abstract
Wikipedia project is benefitting from your experience, skills, and
personality.
Big thanks to Cai, Mariya, and Cory for organizing the off-site, and the
Foundation teams for their support.
We will see some of you during the ongoing Hackathon this weekend! Thanks
to everyone who attended the Wikifunctions session on Friday (slides
<https://docs.google.com/presentation/d/1DAubtW3pkSwIKI4W2ff0bTibRvaJsrroy12…>),
and for your great questions.
Further updates:
-
The team experimented with a new Scrum of Scrums process
-
Each of the four workstream leads wrote a status updates for their
workstream highlighting blockers, risks, accomplishments, and short-term
plans
-
The team met to discuss these blockers and risks, and any points of
confusion
-
Below is the brief weekly summary highlighting the status of each
workstream:
-
Performance:
-
Conducted current state and requirements discovery
-
Identified workstream tracks and high-level needs
-
NLG:
-
Identified goals of the workstream and prerequisite work
-
Metadata:
-
Finished back-end code to accommodate both forwards and backwards
compatibility for the old & new metadata formats
-
Experience:
-
Made progress for function view and editor implementations for
desktop and mobile
-
Fixed canonicalize methods in function-schemata
-
Design of 'Text with fallback' is currently in progress
You can now subscribe for on-wiki delivery of these newsletters, at
https://meta.wikimedia.org/wiki/Global_message_delivery/Targets/Wikifunctio…
- We will send out future issues to that list.
The on-wiki version of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-05-05
--
When Wikipedia launched, it had from the very beginning a great and yet
easily understandable goal: to be an encyclopedia that anyone can edit.
Since almost everyone knew roughly what an encyclopedia was, it was quite
easy for Wikipedia to begin. Over the years, the idea was refined and has
considerably evolved, but this initial spark allowed Wikipedia to grow and
flourish. It allowed people to start working on the many different parts of
Wikipedia without having to first have a centralized discussion about the
scope and goal of Wikipedia.
Wikifunctions does not enjoy the same advantage. Wikifunctions’ mission
statement
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-04-08> is
“to collaboratively create and maintain a library of code functions”, and
for many potential contributors and users of Wikifunctions that will
require further explanation. What is a library of functions? Indeed, what
is a function? How is a function useful to me? We previously wrote an essay
on the motivations for functions
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2020-10-07> and
why they are important. But we expect that this essay is not sufficient to
really bring out the message.
We are planning to write text, to appear on the site in possibly hundreds
of languages, which will explain what functions are, how they can be used,
and why they are useful. We are also considering using other media to
spread the message and popularize the concept of a function. Maybe a video?
A story? A comic? A lecture? An interactive experience, embedding functions
from Wikifunctions? An animation? An infographic? A song?
Do we want a YouTuber to explain what a function is? Do we want an
advertisement-style video exemplifying what one can do with functions,
shown on the front page? Do we want a comic with a socratic dialog about
functions? A short story where the heroes overcome challenges with the help
of functions? A celebrity talking (pro bono) about the usefulness of
functions? A teaching workshop about a few specific functions and how to
use them? All of these?
We would do this because we want to make the concepts behind Wikifunctions
more enticing and easier to understand, thus ultimately making it more
likely that Wikifunctions succeeds. We want people to have answers to
questions such as “What is a function?” and “Why are functions useful to
me?” and to popularize the concept of functions. This in turn will allow
Wikifunctions more space to grow, since answers to these questions will
remain relevant indefinitely and not be tied to the state of the project in
its early days.
In addition to the options mentioned above, we are also expecting to create
initial tutorials specifically on how to use Wikifunctions. These would be
on-wiki, and of course easily editable by the Wikifunctions community to
reflect their consensus on how to use the system. Tutorials, and possibly
much of the material mentioned above, will be widely linked from the
interface within Wikifunctions, in order to help people coming to the pages
to learn what the project is all about.
We would like to hear your thoughts, ideas, suggestions—and see your
contributions. If you want to sketch out, draft, or even start working on
some of this material, we would be delighted. How would you describe the
site to someone?
There is no need for all this material to be available before Wikifunctions
launches, but it would probably be best if the core tutorial is available
at launch. Whereas we are not planning to make a big announcement about
launching, it is likely that the first new member of the Wikimedia family
of projects in a decade might lead to a few announcements and publications,
so having a solid tutorial in place is a good idea.
------------------------------
Next week we will be at our first team off-site. We are very much looking
forward to it! This also means that we are not planning to have a weekly
update next week.
I will resend again.
Then how about this? I have request this submission to the administrators
of the Dutch Wikipedia.
It's been more and four days and you're getting an automatic confirmation
status (including admin). After the evaluation period, you can restore the
previous version of the deleted page from the previously deleted page and
return to (almost) the same page for other reasons: Long-term abuse, but
that is no longer in the discussion of deleting pages.
This is not an unblock request, but a request to recreate a deleted page.
You can nicely copy the article at https://nl.wikipedia.org/wiki/Oh_My_Girl.
So can you regenerate a page that has been deleted but no longer exists in
the delete page discussion?
Don't forget to recreate the article at
https://en.wikipedia.org/wiki/Dreamcatcher_(groep) but must be made
complete, not abbreviated (only the translation helps to develop the
article).
But first make the article on
https://nl.wikipedia.org/wiki/Astro_(Zuid-Koreaanse_band).
Also make an article for me at https://nl.wikipedia.org/wiki/Loona_(groep).
For articles on https://en.wikipedia.org/wiki/Kep1er, you can restore the
master version of the deleted page, but if it is fixed, you can delete WIU
immediately before republishing it.
At https://nl.wikipedia.org/wiki/JYP_Entertainment you can recreate
articles that are no longer in the discussion.
I waited more than four days to recreate the deleted page. That means it
was automatically confirmed for a limited time of one month (the excuse I
was given was that I repeatedly regenerated a page that was deleted after
an evaluation period of blocking and/or deleting and reverting to (almost)
the same contributions).
---------- Forwarded message ---------
Dari: Fernando Lie <liefernando100(a)gmail.com>
Date: Sel, 3 Mei 2022 14.57
Subject: Fwd: [Abstract-wikipedia] Re: Newsletter #70: Requirements for
code in Wikifunctions
To: General public mailing list for the discussion of Abstract Wikipedia
and Wikifunctions <abstract-wikipedia(a)lists.wikimedia.org>
Your message. Not received this. It is your message.
---------- Forwarded message ---------
Dari: Fernando Lie <liefernando100(a)gmail.com>
Date: Sab, 30 Apr 2022 09.59
Subject: Re: [Abstract-wikipedia] Re: Newsletter #70: Requirements for code
in Wikifunctions
To: General public mailing list for the discussion of Abstract Wikipedia
and Wikifunctions <abstract-wikipedia(a)lists.wikimedia.org>
But I requested a remake or rollback and the first article that didn't
exist and deleted in Dutch Wikipedia with help from the Dutch Wikipedia
admin, Bas dehaan and Daniuu. They are Twinklies of the Dutch Wikipedia.
You must contact them.
It's been more and four days and you're getting an automatic confirmation
status (including admin). After the evaluation period, you can restore the
previous version of the deleted page from the previously deleted page and
return to (almost) the same page for other reasons: Long-term abuse, but
that is no longer in the discussion of deleting pages.
This is not an unblock request, but a request to recreate a deleted page.
You can nicely copy the article at https://nl.wikipedia.org/wiki/Oh_My_Girl.
So can you regenerate a page that has been deleted but no longer exists in
the delete page discussion?
Don't forget to recreate the article at
https://en.wikipedia.org/wiki/Dreamcatcher_(groep) but must be made
complete, not abbreviated (only the translation helps to develop the
article).
But first make the article on
https://nl.wikipedia.org/wiki/Astro_(Zuid-Koreaanse_band).
Also make an article for me at https://nl.wikipedia.org/wiki/Loona_(groep).
For articles on https://en.wikipedia.org/wiki/Kep1er, you can restore the
master version of the deleted page, but if it is fixed, you can delete WIU
immediately before republishing it.
At https://nl.wikipedia.org/wiki/JYP_Entertainment you can recreate
articles that are no longer in the discussion.
I waited more than four days to recreate the deleted page. That means it
was automatically confirmed for a limited time of one month (the excuse I
was given was that I repeatedly regenerated a page that was deleted after
an evaluation period of blocking and/or deleting and reverting to (almost)
the same contributions).
Pada tanggal Sab, 30 Apr 2022 05.38, Samuel Klein <meta.sj(a)gmail.com>
menulis:
> Faaabulous :)
>
> On Thu, Apr 28, 2022 at 9:32 PM Denny Vrandečić <dvrandecic(a)wikimedia.org>
> wrote:
>
>> Hi SJ,
>>
>> I could have sworn that there was already a task for it, but I couldn't
>> find it. It is part of the initial Abstract Wikipedia plan:
>>
>>
>> https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_P1.15:_Lua-bas…
>>
>>
>> And now I also filed a task for it:
>>
>> https://phabricator.wikimedia.org/T307171
>>
>> We currently do not plan to implement support for Lua in time for the
>> launch (unless someone else implements it), but we do plan to address this
>> issue relatively soon after launch. Lua will likely be the first
>> programming language to be added after launch (unless someone else
>> implements another language sooner).
>>
>> Cheers,
>> Denny
>>
>> On Thu, Apr 28, 2022 at 5:51 PM Samuel Klein <meta.sj(a)gmail.com> wrote:
>>
>>> Has there been discussion of Lua
>>> <https://en.wikipedia.org/wiki/Wikipedia:Lua> as one of the languages?
>>>
>>> On Thu, Apr 28, 2022 at 8:42 PM Denny Vrandečić <
>>> dvrandecic(a)wikimedia.org> wrote:
>>>
>>>> The on-wiki version of this newsletter can be found here:
>>>> https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-04-28
>>>>
>>>> --
>>>> Once Wikifunctions launches, we currently plan to support
>>>> implementations of functions in two programming languages, Python and
>>>> JavaScript. But unfortunately, that doesn't mean that all the code out
>>>> there, written in Python or JavaScript, will become readily available to be
>>>> copied and used in Wikifunctions. The code has to fulfill certain
>>>> requirements. In today's newsletter we will discuss these requirements, and
>>>> what you can do to prepare code you want to make available through
>>>> Wikifunctions.
>>>>
>>>> First, it must be legal to bring the code in. As per the result of the
>>>> community discussion
>>>> <https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-12-21>,
>>>> the code will be published under the Apache-2 license. If you wrote the
>>>> code yourself, or otherwise own the rights to it, you are free to publish
>>>> it in Wikifunctions. If you are taking the code from an existing open
>>>> source project, you must make sure that it has a compatible license.
>>>>
>>>> Second, the code must be “functional”. That means that, given a
>>>> specific input, the code must always return the same output. In particular,
>>>> that makes a number of classes of functions not available:
>>>>
>>>> - The result must be determined by the input and have no random
>>>> component. This means we cannot have a function that simulates throwing
>>>> dice, that returns a newly minted GUID, or similar random results. A random
>>>> element would break our caching strategy, in particular the ability to
>>>> memoize any function call and replace it with its result if available.
>>>> - The result of the function cannot depend implicitly on the time
>>>> of day, or the current date, or the location of the user. This means we
>>>> cannot have a function that returns the current day of the week. If we want
>>>> to rely on such context, we have to make it explicit as an argument to the
>>>> function. A function such as “how high is the sun here right now?” would
>>>> need to be rephrased “how high is the sun at the given location and time?”
>>>> and take the location and time as arguments.
>>>> - A function call cannot have intentional side effects. There must
>>>> be no function calls that are expected to cause a specific change in the
>>>> world, e.g. a function call which instructs a robot to start a certain
>>>> routine, or that switches on a light. Yes, a function call will always have
>>>> some effect on the world (it may cause caches to change, it will use
>>>> computing resources, and it will turn some electricity into heat), but
>>>> those are incidental and may change in the future. Someone may write a
>>>> system that uses the results of Wikifunctions to control their robots or
>>>> devices, but the actual control would be implemented in that system, not in
>>>> Wikifunctions.
>>>> - A function cannot have a hidden state that is changeable by a
>>>> function call. This is a consequence of the previous point. This means, for
>>>> example, that we cannot have a function that keeps a count of how often it
>>>> has been called and returns that count.
>>>> - This also means there cannot be a function call that edits a
>>>> Wikipedia article or edits a Wikidata item. Editing a function, or a
>>>> function implementation, may eventually change the content of an article on
>>>> Wikipedia (that is, once we allow for Wikifunctions functions to be called
>>>> from articles in Wikipedia), but calling a function on Wikifunctions will
>>>> not cause an article content to change.
>>>> - A function may not call out to the Web or the wider Internet. No
>>>> HTTP requests or similar mechanisms will be allowed at launch. Any
>>>> resources or data a function wants to use must be provided as arguments.
>>>> - Initially, functions will not be able to access data from
>>>> Wikimedia projects. We plan to extend Wikifunctions in an early post-launch
>>>> milestone to allow access to items and lexemes in Wikidata, and later to
>>>> meta-data about media files on Commons.
>>>> - Functions cannot store or load files to a persistent file system,
>>>> or read from or write to a persistent database. They may not access any
>>>> other network or device.
>>>>
>>>> Some of these use-cases may be tackled after launch (e.g. in order to
>>>> allow random results, or to use implicit arguments for functions such as
>>>> “what is the current time?”), but these will require careful planning,
>>>> discussion, and ultimately changes to the system.
>>>>
>>>> These are further restrictions that Wikifunctions will initially have:
>>>>
>>>> - Both Python and JavaScript have an extensive ecosystem of third
>>>> party libraries available. Initially it will only be possible to access the
>>>> Python standard library and the JavaScript standard built-in objects,
>>>> respectively. We plan to allow later for a process to add further libraries
>>>> and make them accessible from an implementation.
>>>> - It will initially not be possible to call another Wikifunctions
>>>> function from a code implementation (only from compositions). We plan to
>>>> allow that, although this might initially be restricted to cases where the
>>>> called function also has an implementation in the same programming language.
>>>> - Initially, only certain types will have built-in
>>>> serialization/deserialization logic (i.e., code that maps between the
>>>> ZObject representation and in-memory objects for each programming
>>>> language). These types are Boolean, string, List, Map (becomes a dict in
>>>> Python or a Map in JS), and Nothing (None in Python, null in JS). For every
>>>> other type, native code will work directly with the respective native JSON
>>>> object at first. We are working on a design to allow the community to add
>>>> serialization and deserialization for more types.
>>>> - This also means that there is no real support for 'objects' in
>>>> the sense of object-oriented languages. The interface with Wikifunctions
>>>> will be a function call, not a call to the method of an object that can
>>>> rely on internal state. There is also no information hiding in objects.
>>>> Every value in Wikifunctions must be entirely serializable and
>>>> deserializable. Values are immutable, which also is at odds with how
>>>> objects are commonly designed and used in practice in many object-oriented
>>>> contexts.
>>>> - Initially, we won’t have a built-in mechanism to support dispatch
>>>> or a type hierarchy.
>>>>
>>>> We are already planning to add more programming languages, but they
>>>> will also have similar restrictions. Both JavaScript and Python, as well as
>>>> many other languages, allow top-level functions to be defined. For other
>>>> languages, such as Java or Smalltalk, we would need to define a slightly
>>>> different pattern in order to interact with the functional interface that
>>>> Wikifunctions provides. Whenever we add a language, the process will
>>>> involve a design step in which we will discuss the appropriate mappings. We
>>>> also plan to document how further programming languages can be added so
>>>> that the effort becomes predictable.
>>>>
>>>> This post has no examples and no how-to, but rather describes the
>>>> requirements for implementations. In the following weeks, we will follow up
>>>> with one or more posts that examine a few patterns and examples on how code
>>>> from libraries could be reused within Wikifunctions.
>>>>
>>>> Thanks to Mahir256 <https://meta.wikimedia.org/wiki/User:Mahir256> for
>>>> providing comments on earlier drafts of this newsletter.
>>>>
>>>>
>>>> _______________________________________________
>>>> Abstract-Wikipedia mailing list --
>>>> abstract-wikipedia(a)lists.wikimedia.org
>>>> List information:
>>>> https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikime…
>>>>
>>>
>>>
>>> --
>>> Samuel Klein @metasj w:user:sj +1 617 529
>>> 4266
>>> _______________________________________________
>>> Abstract-Wikipedia mailing list --
>>> abstract-wikipedia(a)lists.wikimedia.org
>>> List information:
>>> https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikime…
>>>
>> _______________________________________________
>> Abstract-Wikipedia mailing list -- abstract-wikipedia(a)lists.wikimedia.org
>> List information:
>> https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikime…
>>
>
>
> --
> Samuel Klein @metasj w:user:sj +1 617 529 4266
> _______________________________________________
> Abstract-Wikipedia mailing list -- abstract-wikipedia(a)lists.wikimedia.org
> List information:
> https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikime…
>
Then how about this?
I have requested this submission to the administrators of the Dutch
Wikipedia.
It's been more and four days and you're getting an automatic confirmation
status (including admin). After the evaluation period, you can restore the
previous version of the deleted page from the previously deleted page and
return to (almost) the same page for other reasons: Long-term abuse, but
that is no longer in the discussion of deleting pages.
This is not an unblock request, but a request to recreate a deleted page.
You can nicely copy the article at https://nl.wikipedia.org/wiki/Oh_My_Girl.
So can you regenerate a page that has been deleted but no longer exists in
the delete page discussion?
Don't forget to recreate the article at
https://en.wikipedia.org/wiki/Dreamcatcher_(groep) but must be made
complete, not abbreviated (only the translation helps to develop the
article).
But first make the article on
https://nl.wikipedia.org/wiki/Astro_(Zuid-Koreaanse_band).
Also make an article for me at https://nl.wikipedia.org/wiki/Loona_(groep).
For articles on https://en.wikipedia.org/wiki/Kep1er, you can restore the
master version of the deleted page, but if it is fixed, you can delete WIU
immediately before republishing it.
At https://nl.wikipedia.org/wiki/JYP_Entertainment you can recreate
articles that are no longer in the discussion.
I waited more than four days to recreate the deleted page. That means it
was automatically confirmed for a limited time of one month (the excuse I
was given was that I repeatedly regenerated a page that was deleted after
an evaluation period of blocking and/or deleting and reverting to (almost)
the same contributions).
Then how about this? I have requested this submission to the administrators
of the Dutch Wikipedia.
It's been more and four days and you're getting an automatic confirmation
status (including admin). After the evaluation period, you can restore the
previous version of the deleted page from the previously deleted page and
return to (almost) the same page for other reasons: Long-term abuse, but
that is no longer in the discussion of deleting pages.
This is not an unblock request, but a request to recreate a deleted page.
You can nicely copy the article at https://nl.wikipedia.org/wiki/Oh_My_Girl.
So can you regenerate a page that has been deleted but no longer exists in
the delete page discussion?
Don't forget to recreate the article at
https://en.wikipedia.org/wiki/Dreamcatcher_(groep) but must be made
complete, not abbreviated (only the translation helps to develop the
article).
But first make the article on
https://nl.wikipedia.org/wiki/Astro_(Zuid-Koreaanse_band).
Also make an article for me at https://nl.wikipedia.org/wiki/Loona_(groep).
For articles on https://en.wikipedia.org/wiki/Kep1er, you can restore the
master version of the deleted page, but if it is fixed, you can delete WIU
immediately before republishing it.
At https://nl.wikipedia.org/wiki/JYP_Entertainment you can recreate
articles that are no longer in the discussion.
I waited more than four days to recreate the deleted page. That means it
was automatically confirmed for a limited time of one month (the excuse I
was given was that I repeatedly regenerated a page that was deleted after
an evaluation period of blocking and/or deleting and reverting to (almost)
the same contributions).
Then how about this?
I have requested this submission to the administrators of the Dutch
Wikipedia.
It's been more and four days and you're getting an automatic confirmation
status (including admin). After the evaluation period, you can restore the
previous version of the deleted page from the previously deleted page and
return to (almost) the same page for other reasons: Long-term abuse, but
that is no longer in the discussion of deleting pages.
This is not an unblock request, but a request to recreate a deleted page.
You can nicely copy the article at https://nl.wikipedia.org/wiki/Oh_My_Girl.
So can you regenerate a page that has been deleted but no longer exists in
the delete page discussion?
Don't forget to recreate the article at
https://en.wikipedia.org/wiki/Dreamcatcher_(groep) but must be made
complete, not abbreviated (only the translation helps to develop the
article).
But first make the article on
https://nl.wikipedia.org/wiki/Astro_(Zuid-Koreaanse_band).
Also make an article for me at https://nl.wikipedia.org/wiki/Loona_(groep).
For articles on https://en.wikipedia.org/wiki/Kep1er, you can restore the
master version of the deleted page, but if it is fixed, you can delete WIU
immediately before republishing it.
At https://nl.wikipedia.org/wiki/JYP_Entertainment you can recreate
articles that are no longer in the discussion.
I waited more than four days to recreate the deleted page. That means it
was automatically confirmed for a limited time of one month (the excuse I
was given was that I repeatedly regenerated a page that was deleted after
an evaluation period of blocking and/or deleting and reverting to (almost)
the same contributions).
