Talk:Abstract Wikipedia

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search


There's no consensus in Wikidata that Abstract Wikipedia is an extension of it[edit]

@DVrandecic (WMF) and Verdy p: The project description currently says: Abstract Wikipedia is an extension of Wikidata. As far as I'm concerned what's an exntension of Wikidata and what isn't is up to the Wikidata community. I thus removed the sentence. It was reverted. Do we need an explicit RfC on Wikidata to condem Abstract Wikipedia for overstepping boundaries to get that removed? ChristianKl❫ 13:00, 16 January 2021 (UTC)

  • @ChristianKl: Your edit was reverted because you seem to have used a weeks-old version of the page for your edit, and thus have yourself reverted all the recent edits for no reason at all. 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 13:07, 16 January 2021 (UTC)
    Actually this edit was based on a much older version, than just one ago, it used the old version from 16 October, 3 months ago, and the Wikifunctions name was still not voted ! Other details have changed since then, there were some new announcements, changes in the working team, changes for some links (including translated pages). What you did also dropped all edits by the WMF team made since 3 months up to yesterday. verdy_p (talk) 17:45, 16 January 2021 (UTC)

@ChristianKl: I agree. I have qualified the original statement, quoting the relevant section of the Abstract Wikipedia plan. Hope it's okay now.--GrounderUK (talk) 15:02, 16 January 2021 (UTC)

I revisited your addition: note that it will break an existing translted paragraph, so to ease the work, I separated the reference, which also included a link not working properly with translations: beware notably with anchors (avoid using section headings directly, they vary across languages!) I used the stable (untranslated) anchor and located the target of the link more precisely. Your statement was a bit too elusive, as there's no intent for now to modify Wikidata before 2022 to add contents there. It's clear we'll have new special pages, but not necessarily new content pages in Wikidata.
The "abstract content" needed for Abstract Wikipedia is also different from what will be stored initially in Wikifunctions (which will be independant of any reference to Wikidata elements but will contain the implementations of functions, needed for transforming the "abtract content" into translated content integrable to any Wikipedia (or other wikis, multilingual or not...). The first thing will be to integrate Wikifunctions (still useful for reusable modules and templates), but this is still independant of Abstract Wikipedia still not developed this year: Wikifunctions will just be one of the tools usable to create LATER the "Abstract Wikipedia" and integrate it (don't expect a integration into Wikidata and Wikipedias before the end of 2022; I think it will be in 2023 or even later, after lot of experiments in just very few wikipedias; the integration in large wikipedias is very unlikely before about 5 years, probably not before 2030 for the English Wikipedia: the first goal will be to support existing small Wikipedias, including those in Philippines languages which seem to grow large and fast, but with lot of bot-generated articles.). verdy_p (talk) 18:49, 16 January 2021 (UTC)
Thanks. I'm not sure what you found "elusive"; my statement was a direct quotation from the linked source, which asserts that Wikidata community agreement is necessary for any eventual changes to Wikidata and that some alternative will be adopted if the community does not agree. Perhaps the plan itself is elusive, but additional speculation about timescales and the nature of the alternatives seems to obscure the point; it is also absent from the referenced source (and makes additional work for translators). You make a couple of points above that I don't agree with. It is not clear to me that new special pages will be required in Wikidata but, if they are, they will require agreement from the Wikidata comunity. I also believe that early examples of functions in Wikifunctions will (and should) be dependent on "reference to Wikidata elements", in the same way that some Wikipedia infoboxes are dependent on such elements.--GrounderUK (talk) 20:39, 16 January 2021 (UTC)
There's no "speculation " about timescale in what is to translate in the article. All this is already in the development plan. I only speculate a bit at end of my reply just before your reaction here (it seems clear that about 5-10 years will pass before we see a change in English Wikipedia to integrate the Abstract Wikipedia, simply because it does not really need it: the Abstract Wikipedia is clearly not the goal of this project; on the opposite, Wikifunctions will have its way in English Wikipedia quite soon, just because it will also facilitate the exchanges with Commons, also needing a lot of the same functions). I clearly make a difference between Wikifunctions (short term with a limited goal), and Abstract Wikipedia (no clear term, but in fact long term umbrella project needing much more than just Wikifunctions). verdy_p (talk) 03:25, 17 January 2021 (UTC)
If the timescale is in the development plan, please indicate where this is. The timeline on the main page only states that Abstract Wikipedia development "proper" will start in 2022 (elsewhere, "in roughly 2022"), not that "integration" with Wikidata will be achieved (if agreed) by July 2022 (or whenever "the second year of the project" is deemed to end).--GrounderUK (talk) 11:25, 17 January 2021 (UTC)
This objection can't be serious? The Wikidata community has no mandate to decide whether another WMF project, the WMF, or even a non-WMF site, does some commentary stating a project is an extension of Wikidata. The WMF announcement, Abstract Wikipedia/July 2020 announcement, is quite clear on the 'sourcing' for this sentence. In particularly, the end of paragraph 2 and all of paragraph 3. ProcrastinatingReader (talk) 11:59, 19 January 2021 (UTC)

I am trying to understand "Abstract Wikipedia" (please help)[edit]

Dear @Quiddity (WMF): and others, after not having had much time for this project, I am now trying to catch up with the developments and understand for myself what "Abstract Wikipedia" is all about.

In my current understanding:

  • Wikipedia is an encyclopedia with articles that consist mainly of text.
  • "Abstract Wikipedia" is the name of an initiative. This initiative will have two results: first, a new wiki called "wiki functions". This new wiki will, second, help to create new "information pages" in the Wikipedia language versions. These information pages (as I call them) will constitute the so called "Abstract Wikipedia".
  • The information pages will be a better version of the "ArticlePlaceholder tool". The "ArticlePlaceholders" are not supposed to be articles, but exactly "placeholders" for articles where they do not exist. For example, Wikipedia in language X has no article about a certain German village. If you search for the village, you will get a "placeholder", which is basically a factsheet with titles/descriptions and data coming from Wikidata. (These placeholders exist currently in a small number of Wikipedias, experimentally.)
  • The information pages will be "better" than placeholders because of Wiki functions (WF). The WF are code that can transform data/information from Wikidata into something that looks not like a factsheet but more like sentences.
  • This means that in future, the reader of Wikipedia language version X will search for the German village. If the Wikipedians of that language version have not created such an article, then the reader will see the "information page" (again, as I call these pages) about that village. Or: if article and information page exist, the reader will be offered both. (A consequence: we might tend to have less data in an article that could be better presented via the information page.)

To me (and maybe others) it is confusing that "Abstract Wikipedia" is the name of the whole initiative and for one of the two results of the initiative. Also, the proposal talks about "articles" in "Abstract Wikipedia", and that sounds as if the information pages are supposed to replace the encyclopedic (text) articles. Finally, "Abstract Wikipedia" will not be a Wikipedia as we know it (encyclopedia with text articles).

So, what do you think about this summary? I am open for any correction necessary. :-)

Kind regards Ziko (talk) 10:44, 21 January 2021 (UTC)

@Ziko: Hallo. That is partially accurate, partially incomplete, and partially not-yet-decided. I would try to clarify it like this:
  • The Wikifunctions wiki has a broader goal beyond purely linguistic transformations. It will host functions that do any kind of specific calculation on any kind of data.
    • As someone who thinks in lists, I found these 2 links particularly helpful for getting a better sense of the scope of the project: The (minimal) mockup screenshot of what a potential future Main Page might look like; and the very short list of Abstract Wikipedia/Early function examples (~50 examples out of what will hopefully become 100,000+++).
    • Part of its scope will include some of what we currently use templates/modules for, on the other wikis. I.e. this will partially solve the problem we currently have, of needing 150+ separate copies of Template:Convert (and 130+ copies of Module:Convert) which aren't easy to maintain or translate. It won't solve it completely (in the short-term at least!) because the largest wikis will inevitably continue to want to use their own versions instead of a global version; but it should make things vastly easier for the smaller and mid-size wikis. It's also not a solution for the entire problem of "global templates" because Wikifunctions is not intended to host simple page-lists or box-layout-design code or many other template/module uses - but it will be able to partially solve the "calculation" part.
    • There are some obvious existing semi-comparable projects in the math realm, such as fxSolver and WolframAlpha, but nothing (that we know of) in the more linguistic and other-data realms.
    • This Wikifunctions project will be useful as a place to collaboratively (and safely) edit shared code, which can then be utilized on the other wikis, and even beyond.
    • For example, at d:Q42, we know the birth-date of the subject in the Gregorian calendar. But Wikifunctions will provide a way for users to take that date and run calculations on it, such as: What day of the week was that? What was that date in the Hebrew calendar? How old were his parents at the time? What was the world/country/city population at the time? etc. -- Users will be able to run the calculations (functions) directly within the Wikifunctions wiki, as well as be able to output the result of the calculation to some other wiki.
  • The Abstract Wikipedia component is separate, but with overlap. Many of the aspects of how it might be implemented still need a lot of discussion.
    • For a content example, you make a good comparison with ArticlePlaceholder as a simple precursor. There's also Reasonator (e.g.1 en, e.g.2 fr); However those don't exist for many languages, nor most statements (e.g.3 vi). In the backend, those short descriptions are actually coming from the AutoDesc tool. (e.g.4). That AutoDesc system currently has 27 translatable word-elements, and can only handle very simple sentences for cases where each word can be separately replaced with a translated word (and the word order tweaked per-language). The most important difference to both ArticlePlaceholder and Reasonator - but also to projects such as LsjBot or Rambot - is that we want to allow the community to take more ownership of the way and the scope of information being rendered into the individual languages.
    • The Abstract Wikipedia project (and the linguistic function parts of it within Wikifunctions), aims to be able to generate more complex content. It will partially rely upon Lexemes within Wikidata, and partially upon "functions" that convert sentence-structure-fragments into multiple languages.
    • Regarding how that content might then appear within any particular Wikipedia project, there are 3 broad options outlined at Abstract Wikipedia/Components#Extensions to local Wikipedias (which I won't attempt to summarize; please read!). But there are also options beyond those 3, such as partial-integration (and partial local-override) at a per-section level. E.g. The Wikipedia article on "Marie Curie" (which only exists in any form in 169 languages today), could have an "Abstract version" shown at a small wiki, but the local editors at that small wiki could be able to override the intro-section and/or the "Life" section, or add a custom "Further reading" section, whilst still retaining the rest of the "abstract version". This should enable readers to get the most possible information (in their language) at any given time, whilst also enabling editors to improve any part of the content at any given time.
    • Those sorts of details are yet to be discussed in great depth, partially because we need to determine what is technically possible/feasible, and partially because we need to slowly build up a broader community of participants for this sort of discussion/decision.
    • It will be unusually intricate in the sense that components on different wiki projects will be working together to create the outcome of the project. But in the same domains of things we're all already very experienced with.
    • We currently expect that the term "Abstract Wikipedia" will disappear in time, and it is really the name of the initiative. We don't expect that there will be, in the end, a component that will be called "Abstract Wikipedia". Or, put differently, the outcome of Abstract Wikipedia will be in the interplay of the different components that already exist and are being developed. But that's also up for discussion, as you can see in the discussion above.
Lastly, yes, naming things is hard. It's both hard to initially come up with perfectly descriptive and universally non-ambiguous short phrases for things, and even harder to change them once people have started using them!
I hope that helps you, and I'll emphasize that we would also welcome any help making clear (and concise!) improvements to the main documentation pages to clarify any of this for others! :-) Quiddity (WMF) (talk) 23:00, 21 January 2021 (UTC)

Dear @Quiddity (WMF):, thanks so much that you took the time for your comments! This helps a lot. I am still digesting your explanations, and might have a few follow up questions later. But this helps me to study further. For the moment, Ziko (talk) 14:49, 25 January 2021 (UTC)

Spreadsheets functions[edit]


I often use Spreadsheets and I like Wikifunctions. From my point of view Spreadsheet functions syntax is language independent. The most syntax of the functions there like IF or MID are translated into many languages and so user can edit the functions in their language. From my point of view this is a chance for Wikifunctions to get more contributions after I think that editing Spreadsheet functions is something what can be done by much more people than more complex programming taks. If I understand the function model and am able to write functions in Wikifunctions I can help to create something what helps to bring spreadsheets functions into a Wikifunction. This is something I say after I tried to convert a Spreadsheet function into a programm in R. After that works I think it can also work in other programming languages. I am not good in Programming and so I think I can only create a tool for converting a Spreadsheet function with the skills I have at the moment but not a gadget or something like that what is more integrated in Mediawiki. Please tell me what you think about that. --Hogü-456 (talk) 21:09, 1 February 2021 (UTC)

@Hogü-456: Thanks for your comment. I am also rather excited about the idea of bring spreadsheets and Wikifunctions close together. But I am not sure what you are suggesting:
  1. it should be possible for someone who has the skills to write a formula into a spreadsheet to contribute functions to Wikifunctions
  2. it should be possible for a spreadsheet user to use functions from Wikifunctions
I agree with both, but I wanted to make sure I read your comment right. --DVrandecic (WMF) (talk) 23:20, 1 February 2021 (UTC)
I suggest the first thing and the second thing is also interesting. I dont know if there is a equivalent in Spreadsheets for all the arguments in Wikifunctions. So I think it is possible for the most things but not for all. --Hogü-456 (talk) 18:53, 2 February 2021 (UTC)
I agree both are interesting. There is also a third possibility, which is having a spreadsheet implementation of a Wikifunctions function. In spreadsheets, arguments are ranges, arrays, formulas or constants, and different spreadsheet functions have different expectations of the types of argument they work with. For example, in Google Sheets, you can SUM a 2-dimensional range but you can't CONCATENATE it. In Wikifunctions, any such limitations would be a result of the argument's type. In principle, a Wikifunctions function could concatenate a 2D or 3D array, or one with as many dimensions we care to define support for. GrounderUK (talk) 20:01, 2 February 2021 (UTC)
Interesting points. We will definitely take a very close look at spreadsheets once the UX person has joined us, in order to learn from how spreadsheets does allow many people to program. I think that the mix of guidance by the data and autocomplete is extremely helpful, and we can probably do something akin to that: if we know what the function contributor is trying to get to, and know what they have available, we should have pretty good constraints on what could be done. --DVrandecic (WMF) (talk) 00:38, 4 February 2021 (UTC)
Any idea when the UX person will be joining?--GrounderUK (talk) 08:08, 3 March 2021 (UTC)
The process is ongoing, we'll announce it through the weeklies when we know it. --DVrandecic (WMF) (talk) 01:30, 4 March 2021 (UTC)
I like the concept of using Wikifunctions with an extension for Speadsheets (but not only: lot of programming languages could have such "pure functions" integrated while being executed offsite, over the cloud, and not not just over Wikifunctions, which would just be the place where functions are found as a repository, described, then located with the evaluator running on Wikimedia servers... or elsewhere, such as Amazon Lambda, Azure functions, IBM cloud, or other public clouds,n or private clouds like nextcould. For this to work, I think that Wikifunctions should use a common web API that allows chosing the location where evaluators will run (including for the application using these functions, or the OS running that application, or the user profile using that application, the possibility to set preferences; a user could have in his profile a set of prefered locations for the evaluators). In summary what we need is: (1) a repository with lookup facility, that repository should describe the functions in the same computer language via its interface, that API will be able to collect sets of locations where these functions can be evaluate; (2) locating a function description and locating an evaluator for it requires resolvers (based on URNs); (3) searching a function is more or like like a classic search engine, except that it searches in structured metadata, i.e. special documents containing sets of properties, or a database, just like what Wikidata is already; the same occurs with other common repositories for software updates on Linux with APT, DNF, YUM or EMERGE, or for programming environments like CPAN or NODE.JS, or LUAROCKS and also in GitHub with a part of its services or with various connectors (Wikifunctions could as well provide a connectror for GitHub...)
So we should separate the repository of function metadata (i.e. Wikifunctions, containing lot of info and other services like talk pages and presentations, logos, Wikimedia user groups via subscribed Wikiprojects...) from the repository of locations/sites where a function can be executed (either because it is installed locally, or because the site offers the way to accept a task to be uploaded there and registered in a cache for later reuse), in order for a client (like Wikifunction itself or any application using Wikifunctions) to be able to accept jobs to be executed on that site to produce a result (of course this requires security: connecting a new evaluation site has constraints, including legal ones for privacy: calling a function with parameters will easily allow the evaluator to collect private data); as well we must avoid the denial of service (so that the repository of evaluator will detect sites that are not responding to any evaluation request, or just return corrupted or fake answers: this requires evaluation of trust and reliability, just like in any distributed computing environment (this is not so much a deal if evaluation sites cannot be freely be added but are added by admins of the locator server for all possible evaluators.
In summary, separate the description of functions (in its metadata language) from its evaluation (except for a few builtin functions that are resolved locally and possibly runnign on the same host or only on a specific small set of hosts with secure connections, and accepting to delegate execution only to the same final client of the function, if that client wants to run the function himself with his own resources, for example for debugging inside his web browser, with Javascript or WebAsm). verdy_p (talk) 01:13, 5 March 2021 (UTC)

There are a few ideas like this Wiki Spreadsheet design, which depend on functions being defined in some shared namespace on a project, or globally. As a result, spreadsheet functions may be a good class to expand to, in addition to those useful on Wikipedia pages. –SJ talk  21:09, 20 April 2021 (UTC)

@Sj: I've merged your comment up into this existing thread, I hope that's ok. :)
I'm also reminded of Wikipedia and Wikidata Tools (see TLDR in github), which seems closely related. Quiddity (WMF) (talk) 03:52, 21 April 2021 (UTC)
@Quiddity: more than ok! Thanks for catching that. Spreadsheets and wikicalc remain the future... and a necessary building block for even more interesting transparent dynamic refactoring. –SJ talk  18:10, 24 April 2021 (UTC)


Hello, I don't see much communication about the essential point of license. Since it's a direct continuation of the Wikidata agenda, is it correct that it will impose CC-0 everywhere it will be integrated within the Wikimedia environment? A clear yes/no would be appreciated. --Psychoslave (talk) 22:57, 5 March 2021 (UTC)

All appologies, I didn't saw that this talk page had archives and thus already had this point discussed in Talk:Abstract_Wikipedia/Archive_1#License_for_the_code_and_for_the_output and Talk:Abstract_Wikipedia/Archive_2#Google's_involvement. So it looks like I have some homework to do before possibly further comment. At first glance the answer seems to be "it's not decided yet". --Psychoslave (talk) 23:06, 5 March 2021 (UTC)

Follow up on the earlier topic « License for the code and for the output »

Given my understanding of this, which I'm not sure is correct at all, then the generated text can't be copyrighted, but the data and code to generate the text can be protected. — @Jeblad:

I this this is an analogous problem of the compilation problem : the binary usually does not inherit from the compiler licence, the result depends on the source code licence, see. the FSF FAQ on the GPL licence : More generally, when a program translates its input into some other form, the copyright status of the output inherits that of the input it was generated from. … it seem the licence of the result depends on the license of the source data, not the licence of the source code of the functions.

Which could be the lexicagraphical datas, and the abstract form of articles, I guess, but at some point the distinction of the code and the datas can somewhat be blurry …

Also @Denny, Deryck Chan, Psychoslave, DVrandecic (WMF), and Amire80: TomT0m (talk) 10:53, 7 March 2021 (UTC)

I agree with the principles laid out above and don't have any specific preference to give. Deryck C. 16:56, 7 March 2021 (UTC)
Thank you for pinging me TomT0m. Do you have any question on the topic, or specific point on which you would like some feedback?
For what it's worth, "I am not a lawyer but…", your exposure of the subject seems correct to me. I would simply add with a bit more granularity you might add that :
  • it depends on the terms of use of your toolchain. If you use some SaaS that basically say "all your data are belong to us" and between two cabalistic attorney incantation say that the end output will be placed "under exclusive ownership of Evil-Corp.™ and we may ask you to pay big money at any time for privileges like accessing it in some undefined future", the terms might well be valid. But to the best of my knowledge, there's no such a thing in the Wikimedia compiler toolchains, houra,
  • you can't legally take some work on which you don't have personal ownership, throw it through some large automaton chain like, and claim ownership on the result: you have to make a deal with the owner of each peace of work you took as input. All of them. Or none, if none of them pay attention or don't care about what you do. Until they do.
  • the world is always more complicated (even when you took into account that the wold is always more complicated): there is no such thing as "the copyright law". Each legislation as its myriad of laws and exceptions, which may apply on a more or less wide area, with a lot of other locale rules which may or not have preemption on the former, etc.
But once again, that's just more "focused details", the general exposure you made seems correct to me. --Psychoslave (talk) 16:24, 8 March 2021 (UTC)

Thanks for asking the question! Yes, that's still something we need to figure out. We are working together with Wikimedia's legal department on the options. A decision must be made before the launch, but it will still take as a while to get to something that's ready to be shown to the communities. Thank you for your patience! --DVrandecic (WMF) (talk) 17:54, 8 March 2021 (UTC)

Example Article?[edit]

There's a lot of talk about mathematical functions here; there's less talk in functions that produce sentences. Would there be interest in having an "example" article to show what Abstract Wikipedia might look like? Specifically:

  • Write a pseudo-code article on a high-profile topic. For example, for simple:Chicago, (Q1297 IS Q515 LOCATED IN Q1204. Q1297 IS Q131079 LIST POSITION [three])
  • Evaluate the functions manually to translate it to several languages (ideally including languages such as ht:Chicago with bad coverage, if we have sufficient language materials to do so).

Does this seem like a reasonable thing to do? power~enwiki (talk) 20:08, 11 March 2021 (UTC)

@Power~enwiki: Hi. Yes that sounds like a good idea. We can create a detailed example of at least one complex paragraph sometime in the next few weeks, which should be enough to extrapolate from. And then anyone could build out further examples for discussion and potential problem-solving.
For now, we do have a couple of example sentences from an early research paper in Abstract Wikipedia/Examples, and 2 very early mockups at Abstract Wikipedia/Early mockups#Succession (2 sub-sections there) which might help a little. Thanks for asking. Quiddity (WMF) (talk) 23:29, 11 March 2021 (UTC)

A few more questions for the crowd.

  1. Are we going to try to have each sentence be 1 line, or will these be multiple lines?
  2. Wikidata is great for nouns. For verbs, it doesn't seem as good. Many concepts ("to destroy", "to fix") don't have encyclopedia articles at all. Are these available in Wikidata somehow? power~enwiki (talk) 22:49, 14 March 2021 (UTC)
  3. When writing an article, should pronouns be used at all? It seems better to refer to a Q-item (or an ARTICLETOPIC macro), and to have the natural-language generation determine when to replace an explicit subject with a pronoun.

Thoughts? power~enwiki (talk) 22:49, 14 March 2021 (UTC)

@Power~enwiki I think d:Wikidata:Lexicographical data might help. 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 10:34, 15 March 2021 (UTC)

@Power~enwiki: I’m not sure I understand your first question, but...

  1. I don’t think we should have limits on the length or complexity of sentences. For more complex sentences (like the previous one), a version using simpler sentences should be considered. (Long sentences are fine. Complex sentences are fine.)
  2. Further to what @1234qwer1234qwer4: said, Wikidata lexemes (may) have a specific property (P5137) linking a sense to a particular Wikidata item. Currently, destroy doesn’t, but be links to both existence ( Q468777) and being ( Q203872), for example.
  3. I agree that it would generally be better to use unambiguous references. In the translations (natural language renderings), I suggest we might use piped links for this. For example, “Some landmarks in the city are...”. We might also use, for example, <ref>[[:d:Q1297| of Chicago]]</ref> where there is ellipsis, as in “As of 2018, the population[1] is 2,705,994.”


--GrounderUK (talk) 14:55, 15 March 2021 (UTC)

Regarding "1-line" v "multi-line": My question is whether the syntax will look more like SQL or more like JSON (or possibly like LISP). I suppose any can be one-line or multi-line. Regarding verbs: Lexemes are language-specific; it's currently annoying to search Wikidata for them but I don't think they should be in the language-agnostic Abstract Wikipedia text anyhow. power~enwiki (talk) 03:26, 16 March 2021 (UTC)

@Power~enwiki: Thanks for clarifying. There’s a chicken-and-egg problem here. I don’t think @Quiddity (WMF): is intending to include me in his “we” and I have a open mind on the question of “pseudo-code”. I suggest we [inclusive and impersonal] should avoid something that looks like “labelized Wikifunctions”. This is because “we” should try to “translate” the pseudo-code into that format, as well as into natural languages (and/or Wikitext that looks very like the Wikitext one might find in the Wikipedia in that language). So the pseudo-code should be more like “our” language of thought (labelled “English”, for example) but using an unambiguous identifier for each semantic concept. This means we can have many “pseudo-codes”, one for each natural language we select. Such a pseudo-code should not look too much like a translation into that target language or its Wikitext, of course. Without endorsing its content, I refer interested parties to Metalingo (2003)--GrounderUK (talk) 12:22, 16 March 2021 (UTC)
  • I'd like to second the suggestion of a relatively fleshed out example. One paragraph would be fine, but I think it's important to also try rendering the same abstraction into a couple languages other than English (including at least one non-Indo-European language). As I said at Talk:Abstract Wikipedia/Examples, I think it's easy to fall into a trap of coming up with functions that accidentally have baked into them features that are peculiar to the English language, or which at least fail to generalize to some languages.
Another worthwhile exercise would be taking a couple of the functions used in the example, and coming up with several test cases for those functions, and then seeing whether, in principle, a single renderer for language X could produce cogent results for all of those test cases. For example, maybe there's a function possible(X). And so we come up with test cases like:
  1. possible(infinitive_action_at_location(see(Russia), Alaska))
  2. possible(exists(thing_at_location(Alien life, Mars))
  3. possible(action(US President, declare(state_of_war_against(China)))))
And it's straightforward (modulo some fine details) to imagine how a renderer for this function could be implemented in English. But there are languages that distinguish grammatically between the possibility that something is true (epistemic modality: either there's life on Mars or there isn't - we don't know which is true, but we have some reason to think there might be) and someone having the ability to do something (the President having the ability/power to declare war against another country, an arbitrary person being able to see Russia from Alaska). So in fact this is a bad abstraction, since a renderer in, say, Turkish needs to distinguish between these senses, and can't do so with the information given. Colin M (talk) 17:09, 18 April 2021 (UTC)

I started fleshing out the start of an article here: Jupiter. Happy if we continue to work on this and try to figure out if we can find common ground. It would be great to do some Wizard of Oz style test and try to render that by hand for some languages. The only non-PIE language I have a tiny grip on is Uzbek - I am sure we can find more competent speakers than me to try this out. --DVrandecic (WMF) (talk) 00:53, 20 April 2021 (UTC)

This is great. I would suggest linking to it from the main examples page for more visibility (though I understand if you want to do more work on it first). One suggestion I would have for a human-as-renderer test might be to do some replacement of lexemes with dummies in such a way that the renderer won't be influenced by their domain knowledge. e.g. instead of Superlative(subject=Jupiter, quality=large, class=planet, location constraint=Solar System), something like... Superlative(subject=Barack Obama, quality=large, class=tree, location constraint=France).
In this case, for the renderers to have a hope of getting the right answers, we would probably need to also give them some documentation of the intended semantics of some of these functions and their parameters. But I see that as a feature rather than a bug. Colin M (talk) 17:35, 20 April 2021 (UTC)
Yeah, I probably should link to it. I didn't because it is not complete yet, but then again, who knows when I will get to completing it? So, yeah, I will just link to it. Thanks for the suggestion. --DVrandecic (WMF) (talk) 00:10, 21 April 2021 (UTC)


I am interested in Wikifunctions and I like the idea of Abstract Wikipedia. I created easy structured sentences with variable parts for some times in Spreadsheets. I think a chance of Abstract Wikipedia is that it could improve the data quality in Wikidata. I think if it is known what is important about a topic and someone miss something and understands how the text is generated, then maybe people enter the information into Wikidata. For that it is helpful to have clear structures and forms can help to enter information. At the moment this is not so easy. Have you thinked about how the content what is important about a topic can be defined. As far as I know there are shape expressions in Wikidata. --Hogü-456 (talk) 20:35, 22 March 2021 (UTC)

@Hogü-456: Yes, shape expressions are the way to go, as far as I understand the Wikidata plans. Here's the Wikidata project page on Schemas. My understanding is that Shex can be used both for creating forms as well as for checking data - I would really like to see more work on that. This could then also be used to make sure that certain conditions on an item are fulfilled, and thus we know that we can create a certain text. Fully agreed! --DVrandecic (WMF) (talk) 23:15, 19 April 2021 (UTC)

Info-Box (German)[edit]

Who takes care of the entries in the Info-Box? At least in the German Info-Box the items differ from the real translations. —The preceding unsigned comment was added by Wolfdietmann (talk) 09:32, 15 April 2021 (UTC)

@Wolfdietmann: Hi. In the navigation-box, there's an icon in the bottom corner that leads to the translation-interface (or here's a direct link). However, that page doesn't list any entries as being "untranslated" or "outdated". Perhaps you mean some of the entries are mis-translated, in which case please do help to correct them! (Past contributions are most easily seen via the history page for Template:Abstract_Wikipedia_navbox/de). I hope that helps. Quiddity (WMF) (talk) 18:33, 15 April 2021 (UTC)
@Quiddity (WMF): Thank´s a lot. Your hint was exactly what I needed.--Wolfdietmann (talk) 09:29, 16 April 2021 (UTC)

Effects of Abstract Text to the Job Market[edit]


I have thinked about what could happen if abstract Text works good and is used in many contexts also out of the Wikimediaprojects. What does that mean for jobs. I asked me is Abstract Text a innovation that reduces the need of personnel for example for writing technical instructions. Changes are something what happen and they are not bad. I think it is important that there is a support for employees that are affected by that change and to make sure that they have another job after the change. From my point of view is Wikifunctions here a important part because it can help enable people to learn the skills that are good to know, to do other jobs. From my point of view programming is something that is interesting and can help in many parts. I suggest to create a page with some recommendations for potential users of Abstract text to make sure they are aware of the changes that can come through with that change for their employees and that they get the knowledge they need. What do you think about that. What is my responsibility as a volunteer who is interested in that project and plans to participate if it is live, until now I read through the most pages here and tried to understand how it works, to make sure that I do not support a increasing unemployment through optimiziation. --Hogü-456 (talk) 19:55, 17 April 2021 (UTC)

@Hogü-456: Thank you for this thoughtful comment. In a scenario where Abstract Wikipedia and abstract content are so successful to make a noticeable dent on the market for technical and other translators, it would also create enormous amounts of value for many people by expanding potential markets and by making more knowledge available to more people. In such a world, creating and maintaining (or translating natural language texts to) abstract content will become a new, very valuable skill, that will create new job opportunities. Imagine people who create a chemistry or economics text book in abstract content! How awesome would that be, and the potential that this could unlock!
I actually had an interview with the Tool Box Journal: A Computer Journal For Translation Professionals earlier this year (it is in issue 322, but I cannot find a link to that issue). The interesting part was that, unlike with machine learning tools for translation, the translator that interviewed me really found it interesting, because they, as the translator, could really control the content and the presentation, unlike with machine learned systems. He sounded rather eager and interested in what we are building, and not so much worried about it. I think he also thought that the opportunities - as outlined above - are so big, if all of this works at all. --DVrandecic (WMF) (talk) 21:06, 21 April 2021 (UTC)

Recent spam on[edit]

A few suspicious accounts have been created today, and started creating spam pages on the wiki (see the recent changes log). TomT0m (talk) 18:20, 18 April 2021 (UTC)

Thanks for the heads-up. Quiddity (WMF) (talk) 03:53, 21 April 2021 (UTC)

Regular inflection[edit]


in the last weeks I tried to add the inflactions/Beugungen of german nouns that consist of more than one noun as Lexemes in Wikidata. At the overview about the phases I have seen that it is part of the second phase to make it possible to automatically create regular inflections. I created a template as a csv-File that helps me to extract the possible words out of a longer word. In the template I extract all possible combinations with a length beetween 3 and 10 characters. After that I check which combinations match with a download of the so far existing german lexems for nouns with their forms and there I then check if it is going to the end and for these word I extract then the part before the last word with the first character of the last word and match to that additional the existing forms from the Lexemes. For that I have a script in R and a spreadsheet. I want to work at a script for creating the forms of a noun starting with german at the Wikimedia Hackathon. Has someone created something similar or have you thinked about that also for other languages and how the rules are in that language.

At the Wikimedia Remote Hackathon 2021 I suggested a session what is a conversation about how to enable more people to learn coding also with a focus to the Wikimedia Projects and in the phabricator ticket for that I added a link to the mission statement of Wikifunctions after I think this is a project what has this as a goal to make functions accessable to more people and I have several ideas about functions that I think are helpful and I plan to publish them in Wikifunctions if I am able to write them. If you are interested you can attend at the Conversation.--Hogü-456 (talk) 21:26, 12 May 2021 (UTC)

@Hogü-456: Thanks! This is exactly the kind of functions I hope to see in Wikifunctions. Alas, it is still a bit too early for this year's Hackathon for us to participate properly, i.e. for Wikifunctions to be a target where such functions land. But any such work will be great preparation for what we want to be able to represent in Wikifunctions. We hope to get there later this year, definitely by next year's Hackathon.
If you were to write your code in Python or JavaScript, then Wikifunctions will be soon ready to accept and execute such functions. I also hope that we will cover R at some point, but currently there is no timeline for that.
If you are looking for another resource that has already implemented inflections for German, there seem to be some code packages that do so. The one that I look to for inspiration is usually Grammatical Framework. The German dictionary is here:!german/DictGer - you can find more in through their Resource Grammar Library:
One way or the other, that's exciting, and I hope that we will be able to incorporate your work once Wikifunctions has reached the point where we can host these functions. Thank you! --DVrandecic (WMF) (talk) 00:43, 14 May 2021 (UTC)