Abstract Wikipedia/Location of Abstract Content

Abstract Wikipedia will allow more people to contribute their voices in their language to a baseline of knowledge. This baseline of knowledge will then be made available in many languages. The baseline of knowledge is created, stored, and maintained as Abstract Content using data from Wikidata. This Abstract Content is then turned into text in a specific natural language with the help of functions from Wikifunctions and lexemes from Wikidata. This will allow more people to read content in their language.

More on the background of Abstract Wikipedia, including recorded talks and links to documents, can be found on Abstract Wikipedia.

We want to make the decision process clear: we do not yet know which option we want to use, which is why we are consulting here. We will take the arguments from the Wikimedia communities into account, and we want to consult with the different communities and hear arguments that will help us with the decision. The decision will be made and communicated after the consultation period by the Foundation.

Example

[edit]

Assume that we want to create a new Wikipedia article for the planet Jupiter, and the first version of this article shall be the following (these are the first two sentences of the Simple English Wikipedia article):

Jupiter is the largest planet in the Solar System. It is the fifth planet from the Sun.

The labelled abstract content representing this natural text could look like this:

 Article(
   text: [
     Superlative(
       subject: Jupiter,
       quality: large,
       class: planet,
       location constraint: Solar System),
     Definition(
       subject: Jupiter,
       definition: Rank(
         rank: Positive integer(
           value: 5),
         object: planet,
         by: Relational noun(
           noun: distance,
           to: Sun)))],
   categories: [Jupiter, planet, Solar System])

We have an example page for more examples.

Note that this is nothing else but a function call itself, in this case to the Article function. The Article function will be defined in Wikifunctions. For our convenience, this abstract content is shown using labels in English, and the user would see such labelled content in a nice UX. In the system, all of these would be IDs, and maybe look something like this - but remember, that is entirely internal and not how users would see it:

 Z329391(
   Z329391K1: [
     Z239392(
       Z239392K1: Q319,
       Z239392K2: Z173772,
       Z239392K3: Q634,
       Z239392K4: Q544),
     Z202334(
       Z202334K1: Q319,
       Z202334K2: Z193935(
         Z193935K1: Z109882(
          Z109882K1: 5),
         Z193935K2: Q634,
         Z193935K3: Z183432(
           Z183432K1: Q126017,
           Z183432K2: Q525)))],
   Z329391K2: [Q319, Q634, Q544])

There will be UX interfaces to allow the viewing, maintenance, creation, and editing of this Abstract Content for all people, without needing technical expertise.

Wikifunctions will then provide a function that takes this Abstract Content and turns it into a natural language text such as above.

The questions that we want to answer now are: where do we store that function call to Article and how do we associate it with the Wikidata item for Jupiter, Q319?

Consultation process

[edit]

The consultation period is open for four weeks. We will answer relevant questions throughout. Please mark questions as such, so we don’t miss them.

In the first week we will collect input from the communities without any point of view from us, to avoid any biasing the initial input.

After one week, we will publish our own thoughts and those discussions that we have already had, and start engaging in the existing discussion.

We will commit to engage with the consultation here on Meta. Our ability to engage in other venues will be limited. We will try our best to engage in other languages than English.

Once the consultation period is over, we will read through all contributions, and make a decision. We aim to make and publish the decision in a timely manner afterwards.

Options

[edit]

The item for Jupiter in Wikidata can be found at Q319. The options below are given in this context.

We would introduce a new namespace on items. This namespace contains the abstract content for the item. On Q319 you would find the abstract content for the Jupiter article, which would be used on Wikipedias without an article for Jupiter.

• The community for creating and maintaining abstract content would be part of the Wikidata community.
• What about abstract content for other projects such as Wikivoyage? Would the different needs be supported with its own namespace?
• How much additional edits and content will this bring to Wikidata?

We would create a new data type on Wikidata that can store Abstract Content. Then the community could create one or more properties on Wikidata that store abstract content and relate it to a given item, using these properties.

For Jupiter, this means a new claim on Q319, alongside the existing claims.

• The community can create more than one property, and use it more fine grained, e.g. for Wikivoyage, for history, for abstract glosses, etc.
• The community for creating and maintaining abstract content would be part of the Wikidata community.
• It would introduce quite heavyweight values to Wikidata, which doesn’t really fit with the current usage model.

The Abstract Content would be stored on Wikifunctions, and Wikidata would have a new property that links to the ZIDs to get to the Abstract Content. This is also a more natural representation for model content, e.g. for functions that are used on many items.

• This is by far the least development work.
• The community for creating and maintaining abstract content would be (mostly) part of the Wikifunctions community.
• The Wikifunctions platform is pretty technical, and having both the technical parts and the non-technical parts close together might blur the separation.
• The same mechanism can also work for Wikivoyage and other projects.

We create a completely new wiki project (e.g. abstract.wikipedia.org or another name TBD), on which Abstract Content is created, stored, and maintained. Wikidata manages the connections.

• A new community needs to grow around the creation and maintenance of Abstract Content, but can be more focussed and dedicated.
• This further fragments the Wikimedia communities into another wiki that people would have to use.
• It makes using a different copyright licence for Abstract Wikipedia’s content easier.

We can introduce a new namespace to an existing project where the Abstract Content would live. Here are the most likely options:

1. Commons
2. Meta
3. English Wikipedia, not attached to the articles

• Each of these options would have very different social implications, as to the community working on the Abstract Content.
• How much additional edits and content will this bring to the host wiki? Would it overwhelm their community processes, or be skewed by existing ones that might not apply?

Summary of internal discussions

[edit]

Options 1, 4, and 5 are solutions that wouldn’t allow for an easy extension for, e.g. Wikivoyage. Options 2 and 3 would allow for a straightforward extension to allow other projects to have abstract content.

Some other use cases we had previously discussed are abstract descriptions and abstract glosses. Options 2 and 3 would support these the easiest.

Wikidata is in general CC0, Wikifunctions is using CC0 for content and Apache2 for code. Wikipedia content is CC-BY-SA4. Options 1, 4, and 5 allow for an easy separation where Abstract Content can easily be licensed under CC-BY-SA4. Options 2 and 3 would be easier if CC0 is used for Abstract Content; but this conflicts with our previous licensing decision, which unambiguously states that (much like Wikipedia itself today) the Abstract Content for Abstract Wikipedia will be under a CC-BY-SA license.

This solution is very specific for Abstract Wikipedia, and wouldn’t lend itself to extend to e.g. Abstract Wikivoyage.

The concept of "attached" namespaces is a complicated one, and high quality MediaWiki support for this would be challenging to deliver.

Wikidata already has a very high volume of edits and content, and we would add considerably more.

Creating good UX for an Abstract Content datatype will be particularly challenging given the context of the existing Wikidata interface. Abstract Content will likely be long-form content, and the UI of Wikidata Items doesn't lend itself to this. It would probably require considerable extra effort to create a new good UX experience given the constraints of an item page. One option could in principle be a modal for editing, but these come with their own inherent UX downsides and are usually more complex to implement than the same functionality in its own dedicated environment. Also, they break the current design patterns of an item page and may not be aligned with the patterns that might be planned for its future.

Further, while the Abstract Content is somewhat structured and machine-readable, it is much less so (or at least, differently so) than an Item and its structure is probably not queryable with SPARQL.

Also, it might introduce duplication of primary facts directly on an Item. This seems worse than duplication in a Wikipedia article (be it abstract or not), because it mixes/expands the responsibilities of editors that update a fact on an Item. They would now have to change the same information twice with the same hat on, which would be very frustrating. If the abstract content lives in its own domain, then the responsibility for maintaining it would be clearly separated, just like it already is for the already existing language Wikipedias.

It comes with two additional challenges: firstly, Wikidata items would grow in size, and we would need a solution to allow that; MediaWiki enforces a hard limit, which some Wikidata items already hit. And secondly, we would need to decide how to deal with the visualization, editing, and diffing of potentially very large and complex values in the context of an existing system that works well for its rather different use cases. All of these problems wouldn’t exist with the other options.

The ability to store Abstract Content inside Wikidata items may re-open requests for the capability to store other unstructured long text that can't be queried as well (like poems). So far, the Wikidata team have always declined those requests as a bad fit for Wikidata.

Wikidata already has a very high volume of edits and content, and we would add considerably more.

The new datatype would be much larger than anything we’ve had so far on Wikidata, with various problems related to that.

This would solve many of the challenges of Option 2 (Wikidata data type), and retain the advantages of flexibility. It would have the content be removed from the item.

It would have the additional advantage that we could support several items that each refer to the same object on Wikifunctions. Whereas this sounds rarely useful for the abstract content of Wikipedia articles, this might prove very useful for the abstract descriptions of Wikidata items and the abstract glosses of lexemes. With both the creation of abstract content and functions on the same platform, collaboration between people who focus on one of these areas with the other would be more direct.

It could be a moderation challenge for the Wikifunctions community, because its content and rate of change would increase significantly. The scope of the wiki would need to expand to cover content as well as more 'structural' community-supporting things. If one assumes that communities are most likely to group around “content” (be it abstract interlingua or not) and “functions”, Objects on Wikipedia would combine two heterogenous communities; if one assumes communities to split instead around “abstract representations of language”, it would combine two similar sub-communities.

The search system and the contents of the Main Page would become more complicated, with (or more) different primary use-cases (code-functions, linguistic-functions, encyclopædia-topic-pages)

This would give a very clear distinction of what is Wikipedia content and what is not, and give the abstract content a distinct visibility which would otherwise be somewhat hidden between Wikifunctions and Wikidata. On the other hand, it would splinter the Wikimedia communities further.

This would be a considerable change in scope for an unaffiliated project.

Using English Wikipedia seems a particularly bad idea, as it further cements the primacy of English in the Wikimedia movement. It would also make any future support for content outside the scope of Wikipedias more difficult to justify, like Lexeme-related content for Wiktionaries or location-related content for Wikivoyages.

From a UX perspective, Options 1 (Item-attached on Wikidata), 4 (new project), and 5 (unattached namespace not on Wikidata), and in some aspects, Option 3 (Wikifunctions objects) would share a lot of features: each of them would have an entire page dedicated to abstract content (even though that page would live in different places and be connected to the rest of the ecosystem in different ways). Any of these would mean that we would have a full page experience dedicated to the experience of showing abstract content, maintaining it, and the history of that page, entirely dedicated to abstract content and not intermingled with other stuff.

From an UX perspective as a reader, Options 2 (Wikidata data type) and 3 (Wikifunctions objects) share many aspects, as they would change the Wikidata item in basically the same way. For a reader, we may display inline the rendering of the function call (i.e. the abstract content rendered in the language of the reader), and truncate it in order not to dominate the whole page experience. For editing and maintaining the content, the two options differ significantly though, as editing the abstract content would either be inline on the Wikidata item or take you to the respective page on Wikifunctions.

Both options 1 (Item-attached) and 2 (Wikidata data type) would require the Wikidata team and Wikifunctions team to work tightly together. The other options would reduce the need for the two teams to work in tandem. Option 1 has the most complicated needs for the MediaWiki platform; the Wikidata object growth concern for option 2 would also need some work with the MediaWiki group to address.

One of the most interesting questions is where would the new community of abstract content contributors live? In Options 1 (Item-attached) and 2 (Wikidata data type), they would become a sub-community of the WIkidata community. That is a community that is already established, multilingual, friendly, and technically-adept. It already has some workflows regarding notability and partial workflows for resolving content-disputes. Additional preferences/UI will be needed so that editors can filter watchlists on Wikidata.

In Option 3 (Wikifunctions objects), they would be a sub-community of the Wikifunctions community. It would significantly change the nature of the expected community — from a majority of people who are interested in language and code, into a mix of those people plus others who are interested in the details about specific encyclopædic topics. But it would perhaps simplify the workflow of "creating an abstract sentence, and then using that new sentence in an Abstract Content page", both technically and mentally, by having them both be searchable at the same wiki.

In Option 4 (new project) they would need to become their own community, with all the social costs related to that.

In Option 5 (unattached namespace) they would become a sub-community of the respective wiki; the host wiki's community's focus would be split between the new content and their existing task.

This is an important question, because it decides which administrators and what kind of administrators have to take on the maintenance and steering of the abstract content.

One major consideration should be how much flexibility the given solution provides to the community. Options 1 (Item-attached), 4 (new project), and 5 (unattached namespace) each allow very limited opportunities for creative development that we have not anticipated. In fact, the solutions are so constrained that in order to in future support Wikivoyage, we would likely need to provide dedicated resources or it won’t happen. This is even more true for other projects that might benefit from this setup. This puts at risk that support for Wikivoyage and other projects might happen at all.

Options 2 (Wikidata data type) and even more so 3 (Wikifunctions objects) allow for much more flexibility, and we can expect that over the years we will see this applied in creative and novel ways that we would be very surprised by today. They give the community by far the most power, but also the most complexity.

Option 4 (new project) could also be for Abstract Content in general, and not just Abstract Wikipedia, and thus support Abstract Wikivoyage and potentially other projects. It could also split article content along more fine grained lines than it currently does. And Wikidata could then point and provide meta-data for the different pieces in different entities.

A combination of Options 3 (Wikifunctions objects) and 4 (new project) could preserve some of the flexibility (e.g. use Option 3 for short, shared abstract descriptions and glosses on Wikifunctions), with a proper place to develop full, long-form content on its own wiki (Option 4).

Questions

[edit]

• The Wikipedias already have a kind of "function" that can create content: templates. Wikidata has some very useful standard templates that pull things in from statements on an item or property - d:Template:Item documentation and d:Template:Property documentation (there are probably others). I would consider these to already be a form of "abstract content"; it has also been proposed that Wikidata description fields be auto-filled with a similar sort of template where needed (right now there are several bots that fill those in automatically for some item types). Can we add a namespace similar to the Template namespace (in any wiki but particularly Wikidata) with fully multilingual capability using the new Wikifunctions? That seems like a logical way to start here. ArthurPSmith (talk) 16:44, 22 May 2025 (UTC)[reply]

  @ArthurPSmith Thanks for the suggestion, but I am not sure I fully understand it. All Wikifunctions functions are immediately available to all wikis where access has rolled out to. It is a global space, available to all wikis. Why would we want a per-wiki namespace in addition to that? --DVrandecic (WMF) (talk) 10:29, 23 May 2025 (UTC)[reply]

  Ah, I hadn't been following that. Which wikis are using it now then? ArthurPSmith (talk) 14:11, 23 May 2025 (UTC)[reply]

  So far, Dagbani Wikipedia and Wikifunctions. More wikis are planned soon. --DVrandecic (WMF) (talk) 14:30, 23 May 2025 (UTC)[reply]

• What about generic abstract content? For example, we don't need a abstract content for each city in a country, we can have one generic abstract content for all cities in a specific country, and that would generate generic information about each city based in the properties each Wikidata item have. Are that been considered? Danilo.mac talk 19:33, 22 May 2025 (UTC)[reply]

  Absolutely! We call these two different types of articles manually written articles and model articles. Both of these should be possible with any of the options we discuss here, although some of the options make some solutions a bit easier than others. --DVrandecic (WMF) (talk) 10:35, 23 May 2025 (UTC)[reply]

  I guess this relates to my question above then - I think the templates I mentioned work somewhat like "model articles" - so where should those live? I don't see them as single functions, but maybe they could be. ArthurPSmith (talk) 14:18, 23 May 2025 (UTC)[reply]

  That's a great question, and I don't have a great answer. If the answer to our question here only allows for exactly one abstract article per item (e.g. Option 1), then it would need to live as a function on Wikifunctions. If we allow for more flexibility than that, where several items can share the same function (e.g. Option 3), then we could decide whether to put these functions in Wikifunctions or in a new space (e.g. Option 4). So, the desire to use model articles and also put them under a CC-BY-SA license might be a bit at odds given some of the options. Hmm, that's a very good point indeed. --DVrandecic (WMF) (talk) 14:30, 23 May 2025 (UTC)[reply]

• Will all Wikipedias be forced to display the content based in abstract content when that specific Wikipedia does not have an article and Abstract Wikipedia have? Will the communities of each Wikipedia have the control to display or not the content from abstract Wikipedia? That is an important question because there are editors that don't like templates that automatically pull content from Wikidata, for different reasons like quality of the Wikidata content and difficulty to modify and watch modifications, and they can just not use them, or choose to use only in some cases. How will the Wikipedia editors communities can choose what can be pulled from Abstract Wikipedia and what can not? Danilo.mac talk 19:33, 22 May 2025 (UTC)[reply]

  @Danilo.mac Thank you! Those are really important questions, and not all answers are there yet. The plan is to certainly allow the local communities a lot of control. Sometimes, there are intentionally omitted articles (e.g. when a community decides to split up the topics of an article differently than another, e.g. Bonny and Clyde. It would indeed not make for a great experience if in these cases the community couldn't suppress the creation of the article from Abstract Content.

  But all these questions will be true no matter what the result of the current consultation, I assume, and that the answer to these questions wouldn't really have import for the current discussion, or am I missing something?

  Thanks for raising these important questions! --DVrandecic (WMF) (talk) 10:54, 23 May 2025 (UTC)[reply]

• Will we be able to import only a section of the abstract content to an article? For example, when comparing the article in my home wiki and the article from abstract content I find that in general the article in my home wiki is better, but one or two sections are better in the abstract version, could I import just those sections? I it not be possible, editors could in the future copy the abstract part that is better to the Wikipedias wiki-code and not indicate in the summary that they are coping, generating a license issue. So, I think that it is better to allow sections import since the beginning of the project. And that would be hard to implement if we choose options #1 or #2. Danilo.mac talk 00:25, 23 May 2025 (UTC)[reply]

  @Danilo.mac in both cases I would expect that we can still write a function that takes the abstract content, and just chooses a part of it. I think that this should be possible with any of the options discussed here (although it might be a bit easier if we chose Option 3 and then already break apart the content along these lines, but I am not expecting this to be the usual process? I think rather a function such as "fetch the section on history and render it here" used in the local Wikipedia is more likely. --DVrandecic (WMF) (talk) 10:57, 23 May 2025 (UTC)[reply]

• I got a message on my wiki's discussion board, alerting us of this discussion. The message contained the text "Since some of the hypothesis involve your project, we wanted to hear your thoughts too." I don't see how this "involves our project". Only option 5 seems that it might be hosted on a Wikipedia project. Is that the only way that this would affect a Wikipedia project directly? - Rooiratel (talk) 07:54, 23 May 2025 (UTC)[reply]

  @Rooiratel If I read your User page correctly, your main projects you contribute to are Afrikaans Wikipedia and Wikidata. Both projects would potentially be affected:

  1. Afrikaans Wikipedia would get potentially a lot of articles from Abstract Wikipedia, to fill in knowledge gaps on that wiki. In that case we still would want the community to be able to edit those articles, and therefore it makes a difference for contributors as to where and how they can contribute to those articles. The laid out options answer that question.
  2. Wikidata would potentially change in community dynamics and technical requirements depending on the option selected. Some of the options have a more direct impact on these questions than others.

  I hope that clarifies why we invited you and your project to participate in this consultation, and how your projects would be affected. Thanks for asking! --DVrandecic (WMF) (talk) 11:02, 23 May 2025 (UTC)[reply]

• It is still not clear to me the relation between an Abstract Wikipedia item, and a normal human language Wikipedia. Is the point of Abstract Wikipedia to display basic text in any human language that can then be used to create a stub article for that language? What happens when the abstract wikipedia content for a specific changes over time? How is that meant to affect the human language wiki, that already has made use of an earlier version of the text from abstract wikipedia? - Rooiratel (talk) 07:54, 23 May 2025 (UTC)[reply]

  @Rooiratel no, in general the output from Abstract Wikipedia is not meant to be a stub to start your own article from (although that is indeed a possible workflow). It is rather thought to generate the articles that don't have a version in your wiki. For example, the island my family is from, Brač, currently has no article on Afrikaans Wikipedia, your home wiki. If so configured, the article would be generated from Abstract Wikipedia in Afrikaans and displayed.

  Now if someone wants to write that article in Afrikaans, they can do so at any time. They can also use the existing generated text as a starting point. But from that point on, the local version in Afrikaans would overwrite the version from Abstract Wikipedia.

  Alternatively, they might also choose to contribute to the Abstract Wikipedia version directly, through the Afrikaans interface of Abstract Wikipedia. In that case, any improvement to the Abstract Wikipedia article would immediately go out to all other Wikipedia language editions that don't have a local Wikipedia article, e.g. to Hindi Wikipedia, which currently also doesn't have an article on Brač.

  I hope that makes sense! Happy to answer further questions. --DVrandecic (WMF) (talk) 11:09, 23 May 2025 (UTC)[reply]

• Is this going to be under CC0 like Wikidata or CC-BY-SA like Wikipedia? I'm rather keen on attribution and especially on share alike, and I'm concerned if this becomes the future of Wikipedia, but like Wikidata free for tech companies to turn into something we can't even tell is a copy of Wikipedia. This isn't just an ethical concern, we need to know whether sources are mirrors or independent before we cite them on Wikipedia. WereSpielChequers (talk) 09:04, 23 May 2025 (UTC)[reply]

  We should let others answer officially. but for the Wikipedia-like original encyclopedic content you ask about, the answer is very clearly CC-BY-SA. See Abstract Wikipedia/Updates/2021-12-21 re: "Abstract Content for Abstract Wikipedia", and the earlier Abstract Wikipedia/Licensing discussion - noting that these cite CC-BY-SA 3.0 but Wikimedia projects have since transitioned to the up-to-date (and broadly compatible) CC-BY-SA 4.0, and Abstract Wikipedia will likely do the same.
  (CC0 remains a useful possibility for factual claims with negligible creative input: similar in principle to the existing Wikidata statements, but benefiting from the more expressive model of Abstract Content.) Hupaleju (talk) 09:33, 23 May 2025 (UTC)[reply]

  @WereSpielChequers as @Hupaleju already answered correctly, in our previous community consultation the decision was that the content of Abstract Wikipedia should be CC-BY-SA (with a likely update to 4.0, pending input from legal). The question of how easy it is to apply the license is indeed a major consideration when weighing the options. --DVrandecic (WMF) (talk) 11:17, 23 May 2025 (UTC)[reply]

• I'm here because of a message suggesting that this project involves enWS. I'm intrigued to know in what way the Abstract concept will affect/involve Wikisource. Beeswaxcandle (talk) 09:10, 23 May 2025 (UTC)[reply]

  @Beeswaxcandle thanks for the question! Obviously the question goes back to the Wikisource communities: how much do the Wikisource communities want to build shared, multilingual content? If not for content, maybe for community process, overview pages about authors and works, or even -- dare I say? -- translations? With multilingual Wikisource, Wikisource already has an approach towards handling some of these questions. But yes, it might be less directly relevant to the core work of Wikisource than it is for e.g. Wikipedia. Nevertheless, since some of the options would make certain workflows harder or easier for projects such as Wikisource, I thought it fair to invite you to this consultation too. I hope that makes sense! --DVrandecic (WMF) (talk) 11:24, 23 May 2025 (UTC)[reply]

  wikisource.org hosts texts in multiple languages that currently do not have their subdomain, but I don't know about specific multilingual features in Wikisource.

  I guess Wikisource could use Wikifunctions in non-content pages (e.g. pages about an author), but abstract content seems less relevant (assuming "abstract content" means "whole sentences"). And I'm afraid this will make wikicode even more frightening to non-geek users, since the wikicode will incorporate not only template calls and occasionally Lua calls, but also Wikifunction calls (unless I understood nothing about Wikifunctions and abstract content, which is possible). Seudo (talk) 13:20, 23 May 2025 (UTC)[reply]

  There would be very little applications on most Wikisources for Author pages. The purpose of the Author pages is to list hostable works by that author that were written in or translated into the language of the particular Wikisource. So a suitable translation must exist, and that translation must also be in the public domain. No amount of Wikifunction calls would be able to determine those things automatically. And even if a French edition of a Spanish work exists, none of the data concerning the Spanish work would necessarily be relevant for the French translation. The translator's name would not be part of the original, nor the date of publication, nor the publisher. Nor can titles be auto-translated, because what matters is the new title chosen by the publisher, not a literal translation. Even data like number of pages cannot be used for the new translation, because that too is subject to change when a translation is made and published.

  So, I'm at a loss to see any use at all that this proposal can be for any Wikisource project. --EncycloPetey (talk) 20:34, 26 May 2025 (UTC)[reply]

  OK, understood. I thought there might have been places in Wikisource where abstract content might have been useful, but it seems I have been wrong. Apology for the message. I hope that it will turn out that there are interesting applications also in Wikisource, but for now I will defer to your expertise and not consider Wikisource as a place where the concept of Abstract Content might be useful, unless someone else finds a use. --DVrandecic (WMF) (talk) 15:53, 27 May 2025 (UTC)[reply]

• Warum gab es eine Nachricht in der deWP, wenn das hier gar nicht uns betrifft? Das hier ist nicht übersetzbar, also sind andere Sprachen offensichtlich unerwünscht. Es kann also kein Projekt außerhalb des englischen Spüracxhraums betreffen, da diese hier gar nicht gefragt werden. Grüße vom Sänger ♫^(Reden) 13:24, 23 May 2025 (UTC)[reply]
• How much abstract content will be shared between projects (e.g. Wikipedia and Wikivoyage and Wiktionary) in practice? The divide between lexemes and entities on Wikidata come to mind. If the level of isolation is high, that would make less reason for a Wikimedia-wide centralized shared repository. whym (talk) 11:46, 24 May 2025 (UTC)[reply]

  That's a great question, and I really don't know the answer. In theory, I could imagine that a short, three sentence description of a city could be useful for Wikipedia, Wikivoyage, Wikiquotes, etc., but whether the different projects really want to share that kind of content? I find that terribly difficult to predict. --DVrandecic (WMF) (talk) 10:41, 26 May 2025 (UTC)[reply]

Discussion

[edit]

• For #4, wouldn't w:zxx:Q96807071 be the tertiary domain most analogous to Abstract Wikipedia's role among the other language editions? For comparison, wikisource:mul:WS:LANG hosts human-readable source content in multiple languages, whereas AbsWP would use a non-human-linguistic exchange format for its (non-source in the evidentiary sense, but still a translation source) content. — Arlo Barnes (talk) 06:15, 19 May 2025 (UTC)[reply]
  • Hi @Arlo Barnes, thank you for your comment. Would you like to elaborate a bit further on what you wrote, please? Are you suggesting something similar to mul.wikisource or...? Sannita (WMF) (talk) 15:12, 19 May 2025 (UTC)[reply]
    • Well, I think the location that makes sense in the near term is to use the wikifunctions.org domain (option 3); but presuming that Abstract Wikipedia grows into its envisioned role, in the middle and long terms it should probably be a coequal Wikipedia, using a wikipedia.org subdomain. Since most of the Wikimedia language codes match to the w:ISO 639 codes, making an appropriate selection from one of the special codes in that standard (mis, mul, und, zxx, etc.) seems useful. There was some mention of Abstract Wikivoyage and so on for the other language-specific projects, so depending on whether Wikimedians generally think all the abstract content should be in one place or whether there should be content repositories for each project area, the selected locations might be different. — Arlo Barnes (talk) 18:32, 19 May 2025 (UTC)[reply]
• In my opinion, it's quite possible that different kinds of Abstract Content, relating most closely to different existing projects, should be hosted in different places. My view is that Wikidata itself should always be reserved for CC0-licensed content, thus this MUST NOT include the remarkably complex and creative "structure, sequence and organization" of encyclopedic content (which would be licensed under CC-BY-SA much like Wikipedia itself, per previous discussions), but arguably SHOULD include the already proposed Abstract Labels, Descriptions and Senses/Glosses and also, more generally, any other sort of broadly factual claims which simply cannot be expressed by the existing Wikidata model (due to its lack of generality and 'compositionality'), as well as supporting content relating to, e.g. basic semantic constructs (the role of 'Superlative', 'Definition' and 'Rank' in the mock-up above - though these might also end up on Wikifunctions). This means that Abstract Content for Abstract Wikipedia SHOULD be allowed to reference and transclude Abstract Content from Wikidata, much like custom Wikibases today are able to reference Wikidata items and properties.
  Please note that under this proposed model, Wikidata MAY also end up hosting large volumes of Abstract Content, such as the literal, close "translation" into Abstract Content of an existing public domain text. The distinction would be driven by feasible licensing and usage conditions, not volume of data. (Most of all, we should avoid making Wikidata licensing legally uncertain which would threaten to destroy much of its current usefulness to outside reusers!)
  We SHOULD also be mindful of the needs of other projects, like Wikibooks (there is no reason why we might not want to make textbooks and tutorial information also available in a language-independent version at some point), Wikivoyage (which includes travel-guide information that is intentionally somewhat subjective and thus would be out of place both on Wikidata and on Abstract Wikipedia), Wikiquote (which quotes a lot of "fair use" content that it would be inappropriate to include on Wikidata) etc. etc. These would then merit their own Abstract Content spaces, much like Wikipedia itself. --Hupaleju (talk) 11:36, 19 May 2025 (UTC)[reply]

  @Hupaleju: thanks for these thoughts! I agree that license considerations should play an important role. And having literal values in Wikidata on properties with a different license would be a complexity which we probably want to avoid. The same should probably true with regards to the Wikifunctions main namespace, we probably don't want to make the license more complex there.

  So one major consideration should indeed be how to apply relevant licenses and separate things accordingly to make that more or less straighforward. Again, thanks for raising this important point! --DVrandecic (WMF) (talk) 10:28, 20 May 2025 (UTC)[reply]

  @Hupaleju I also find the suggestion to do a mix of the proposals interesting: Option 4 for Abstract Content for Wikipedia, and in addition Option 3 or 4 for other uses of Wikifunctions in Wikidata, such as glosses, abstract descriptions, etc. --DVrandecic (WMF) (talk) 10:34, 20 May 2025 (UTC)[reply]

• I'd say the best is either option 3 or 4. This is a project which has a radically different way of creation and working compared to Wikidata, or others for it to be integrated into another project and therefore deserves its own place to be built. Having it on Wikifunctions has the additional benefit of having both the people who created the functions for translations, and the people who create the content using this model in the same place, which I think will be better in terms of easy debugging and faster development. Having this on a completely new domain is also a good option to consider. ~/Bunnypranav:<ping> 12:14, 19 May 2025 (UTC)[reply]
  • What domain name are you considering? https://abstract.org or the like would be nifty but might not be available depending on the current owners. — Arlo Barnes (talk) 18:38, 19 May 2025 (UTC)[reply]

    For the domain, I'd lean towards what you said above. Another option is just abstract.wikipeda.org or likewise for other projects. ~/Bunnypranav:<ping> 04:25, 20 May 2025 (UTC)[reply]

    We can think of the name of the project and the domain at a separate point, once we have decided whether we want a new project. I am not a fan of calling it Abstract Wikipedia, to be honest, but again, we can get to that decision if we take that path. --DVrandecic (WMF) (talk) 10:30, 20 May 2025 (UTC)[reply]

• The fourth option is more adequate. "Content" about an entity can be of many textual genres. If we're building an abstract encyclopedia, that's one project. If it's an abstract travel guide, that's another project. Attaching the content into an existing project will limit ourselves into just one genre and not allow the full diversity of genres we have in Wikimedia. Arcstur (talk) 14:11, 19 May 2025 (UTC)[reply]
  • On the other hand, keeping the 'genres' distinct allows the unique editor styles each has cultivated to persist. — Arlo Barnes (talk) 18:43, 19 May 2025 (UTC)[reply]
• I like the idea of having abstract content in different places. From my point of view abstract content should be available after community consensus in every Wiki. The decision if it should be activated is one of the local community of the specific Wiki. I wish it is possible to write it down in Wikitext. One solution from my point of view is, abstract content should be a feature integrated in the Wikitextparsers like Parsoid. There is a simple kind of generation of abstract content available in Wikitext within Mediawiki with the substitute function.--Hogü-456 (talk) 20:23, 20 May 2025 (UTC)[reply]

  Given that we will have function calls enabled everywhere, it is expected that you can have such calls everywhere. I am not sure it's always a good idea: I don't see the benefit on, say, writing in Abstract content on the Croatian Wikipedia? There are many functions which will make sense, but I am having a bit of trouble to find many use cases for abstract content in a specific-language Wikipedia. --DVrandecic (WMF) (talk) 11:18, 21 May 2025 (UTC)[reply]

  @Hogü-456, you'd never write Abstract content on a single wiki. Why would you bother with that? If it's just going to be used on a single wiki, just write the plain old sentence in the local language.

  I see this question as being similar to mw:Global templates: Should we have a single place for certain templates, which local editors can choose to use, or not use? Imagine that {{cite web}} and {{citation needed}} were available globally. You wouldn't want to think, "Oh, I need to call the French Wikipedia's cite web template and the Spanish Wikipedia's citation needed tag and the English Wikipedia's template for..." You would want them all to be in the same place. And you'd never create a template that was going to say "Jupiter is the largest planet in the Solar System", because you don't need that sentence to appear in lots of articles and lots of Wikipedias. WhatamIdoing (talk) 16:18, 22 May 2025 (UTC)[reply]

  There are for example sections in articles who represent data about demography. For example this section about the population in the English Wikipedia article of Windsor in Conneticut. It is a long list of facts written down in sentences. If there is enough data in a structured format available for it, it is possible to generate such a text using abstract content and it can be used in many articles. As I like facts I enjoy reading such sections and I think abstract content can help generating it and it could be also interesting for other language versions of Wikipedia. Regarding the multilingual aspect of abstract content I am not sure how soon it will work and how far it will become real to support small language versions with it. So I see a use case of abstract content in a framework for creating boilerplate templates working for a specific language. From my point of view it is necessary to check a text having a person who understands the language well before publishing it. It is possible to use a template for generating the text too and so I am not sure if abstract content is the best choice for such examples. Hogü-456 (talk) 19:49, 22 May 2025 (UTC)[reply]

• I worry about the added load on Wikidata, particularly on the query service. Wikidata just split the query service because of concerns that it would be unable to keep up as Wikidata grew. Any solution needs to keep these concerns at the forefront. My view is that the best place for this information is a separate project, as the data is different from other projects - not text and not factual statements. Peter F. Patel-Schneider (talk) 13:49, 21 May 2025 (UTC)[reply]
  • Comment: We should keep in mind that the WDQS is quite distinct from Wikidata itself, i.e. the main site. We're still quite far from having a real data model for Abstract Content comparable to the existing data model for Wikidata entities, properties, statements etc. but while it may of course be seen as desirable in a general sense that some Abstract Content be made available as queryable RDF (or even quite possibly as RDF* which seems to better address 'compositionality' concerns, thus arguably narrowing the gap with the already-proposed "frame" models) via the Query Service, this is a decision that it will clearly be possible to make separately within the Wikidata project, similar to how the decision was reached to split off the scholarly citations data.
    There are also third-party services that work much like the the Query Service but using other backends (e.g. QLever) that do not seem to be showing the same scalability concerns; such services may find it quite beneficial to have some sorts of Abstract Content available within Wikidata itself (of course, as far as can allowed by the above-mentioned licensing concerns; i.e. in my view, basically sticking to factual claims and excluding the unambiguously original and "creative" content that arguably makes up the bulk of what's currently hosted in Wikipedia and other non-Wikidata projects). --Hupaleju (talk) 15:14, 21 May 2025 (UTC)[reply]

  Yes, I think those are really important points, which we are certainly taking into consideration. We definitely don't want to increase the risk of Wikidata having technical problems in the future. --~~~~ DVrandecic (WMF) (talk) 11:33, 23 May 2025 (UTC)[reply]

• I would agree in general with the comments suggesting that abstract content reside in a separate project (option 4). If instead it were possible to store abstract representations of facts not representable as Wikidata statements individually--that is, each fact has its own entity ID (like "F12345") or subentity ID (much as statements on items have UUIDs, like "Q123-4567-...-89abcdef0123") with its own separate references--and then have abstract content consist of arrangements of those facts--so that the abstract article for Q123 would consist of rendering three statements and three fact sub-entities from that item--then I could see those fact subentities stored in a separate slot of Wikidata items. Mahir256 (talk) 22:47, 21 May 2025 (UTC)[reply]

  The way I understand it, these "abstract representations of facts" stored in Wikidata would themselves be Abstract Content, though not of the same character as the Content that may be involved in a "full" Abstract Wikipedia article.
  Also, while in many cases it may be quite practical to reference individual "facts" by subentities of some existing Wikidata item, there are also potential facts that are not so unambiguously linked to a single Wikidata item, hence where filing them as subentities of one would ultimately be somewhat artificial. This may end up being a harder problem than the one we face now of where each individual Wikidata statement should be stored, since that can be decided based on the property type and the required "subject" item for the statement. Much of the projected power of Abstract Content arguably comes precisely from not having such tight restrictions, and indeed from allowing "content" to be built somewhat arbitrarily in some sort of vaguely tree-like structure, starting from elementary "building blocks" involving some sort of well understood semantics. Hupaleju (talk) 23:37, 21 May 2025 (UTC)[reply]

  @Hupaleju yes, agreed with your points, but I think that for some cases it might still be interesting to consider extending Wikidata the way Mahir is suggesting. --DVrandecic (WMF) (talk) 11:38, 23 May 2025 (UTC)[reply]

  @Mahir256 thanks, that's a great consideration. I'll think about it. --DVrandecic (WMF) (talk) 11:37, 23 May 2025 (UTC)[reply]

• I believe that language-neutral content should reside in its own project. I don’t find the “article as function” argument especially compelling. It is up to the contributing community, of course, but I imagine that language-neutral encyclopaedia Articles will require the same editorial structures as any Wikipedia edition: categories, transclusions, redirects, infoboxes, sortable tables, captioned images etc. I further suppose that there will be content templates that we can default to, according to how the article’s subject is categorised.
  However, I also believe that there is an equivalence between Wikidata statements or claims and their language-neutral representations. Arguably, this is a non-trivial correspondence, but I would support the view that any copyright in such content should be explicitly disclaimed (CC0). We previously discussed such representations using the term “infoText”, without considering copyright. I have no settled view on where any contribution that simply maps or filters Wikidata content should reside, but I suspect it will be simpler to have a single CC0-specific location within the language-neutral domain. GrounderUK (talk) 09:53, 22 May 2025 (UTC)[reply]

  Thanks for explicating the arguments re the community processes and their influences on the decision. Those are strong arguments. --DVrandecic (WMF) (talk) 11:41, 23 May 2025 (UTC)[reply]

• I dislike Option 5.3, to put it at the English Wikipedia. Language-neutral content should not reside in a language-specific project. Also, people might be blocked at enwiki, and thus unable to contribute to something that will mostly benefit non-enwiki wikis. WhatamIdoing (talk) 16:22, 22 May 2025 (UTC)[reply]
• Given the peculiarities of the various projects, both stylistic (for example Wikipedia or Wikivoyage) and linguistic, and the possible technical problems to be faced, I would initially consider it appropriate not to separate the wiki functions from the abstract Wikipedia, so I would choose option 3, and I would postpone the final choice on the placement of the abstract contents to a later time. I believe that the objection according to which the proximity of the technical and non-technical parts could obscure the separation, at first glance does not represent a big problem, but rather an advantage in making developers understand the needs of the users. However, if this would lead to big problems in the relocation of the abstracts, and therefore it were appropriate to think about a definitive placement, I would choose option 2 (after evaluating the load on the wiki data), or even option 5 (after evaluating the compatibility of the licenses with those of Commons).--Ciaurlec (talk) 21:24, 22 May 2025 (UTC)[reply]

  @Ciaurlec oh, thanks! I haven't thought about a temporary answer involving a later move. That's an interesting contribution. Thanks! --DVrandecic (WMF) (talk) 11:42, 23 May 2025 (UTC)[reply]

• I don't think option 5 is a good one (leaving aside option 1 for the moment, which is technically a variant of option 5). In essence, this project is writing articles using a language that looks like nested function calls and is intended to be easy to translate to actual languages in use, instead of using some other language as a base for translation. Accordingly it will need to develop its own community of writers fluent in the abstract language and establish its own community norms. I think it will be overly challenging to try to build this community alongside an existing community, with too much potential for the goals of the two to clash. Options 1 and 2 might work as a storage location, but I still think there needs to be a suitable home for the abstract language community. isaacl (talk) 22:11, 22 May 2025 (UTC)[reply]
• I think the option 4 is better, actually I thought that was the plan since the beginning, and the main reason is because the evolution of the project over time. We can have in the future many improvements that can be hard to implement if the abstract content is in some existing wiki that was not originally created to store abstract content. With a dedicated wiki we can develop more easily new tools and features specific to deal with abstract content. And I also think that we should create the "abstract" as a wiki language, and not only one wiki. So initially we would have abstract.wikipedia.org, after some time we can create abstract.wikivoyage.org, and so on. Abstract content is a new way to structure knowledge and ideas, that is exactly what a language is about. Danilo.mac talk 00:59, 23 May 2025 (UTC)[reply]

• Man sieht wie wichtig "Euch" das Feedback der verschiedenen Communities ist! Daher habt ihr es sicherheitshalber nur auf englisch veröffentlicht und nichtmal wenigstens als Feigenblatt es zur Übersetzung markiert. Danke für Euer Interesse an einem breiten Feeback für dieses very delicate issue. 🤣 SCNR. Keine Antwort an mich nötig, ich wollte es nur mal wieder herausstellen. Nicht zuletzt weil ja direkt im 1. Satz etwas steht von " contribute their voices in their language ". Herrlich ...Sicherlich ^Post 06:30, 23 May 2025 (UTC) es jetzt zu übersetzen ist auch nutzlos. Die Announcments waren nur auf englisch. Wer kein Englisch kann wird sich nicht aus versehen hierher verlaufen. Die Chance ist vertan [reply]

  @Sicherlich Es tut uns leid, dass wir die Nachricht auf Englisch geschickt haben, aber wir hatten keine Zeit, sie in andere Sprachen zu übersetzen. Das nächste Mal werden wir es besser machen. Sannita (WMF) (talk) 11:26, 23 May 2025 (UTC)[reply]

  Funny thing; I get responses like that from WMF since years (decades?). So; no you wont. There is no concept of any kind about languages in WMF. Sometimes it is translated, usually its not. If it is, than the languages are randomly chosen. Makes no sense ...Sicherlich ^Post 11:46, 23 May 2025 (UTC) and its not about me personaly, nor is it about German. [reply]

  @Sicherlich in this case, where we addressed all communities at once, it wasn't just possible to address each single community with a translated message, this is why we used English. But you can express your ideas in German, as I already said at the Kurier. Sannita (WMF) (talk) 13:49, 23 May 2025 (UTC)[reply]

  It was not even possible to translate this page to any other language? That's a clear show of complete lack of respect for the communities.

  Without at least 10-20 complete translations this RfC is not worth anything at all, as it excludes 90% of the communities. Grüße vom Sänger ♫^(Reden) 13:54, 23 May 2025 (UTC)[reply]

  You didn't even manage to translate it in Italian yourself, although you are paid as a communications specialist by us, the community, who generates the money for the WMF. Grüße vom Sänger ♫^(Reden) 14:09, 23 May 2025 (UTC)[reply]

  Its not about adressing it in all languages. Its about at least trying to do it for the major ones. And even as I pointed it out you still don't understand. Its NOT about me and its NOT about German. You (aka WMF) did not even put the smallest effort into it. and the response one gets from you (WMF) is always like you did now. So its either (1) you just pretend you care, but really aren't, (2) your internal communication is pretty poor or (3) the learning curve is f(x)=1. I assume its (1) but maybe you offer a different explanation. (oh usually the excuse of WMF is (4): we don't have the funds. Don't try this: the figures are public ...Sicherlich ^Post 15:56, 23 May 2025 (UTC)[reply]

  Die Diskussion hier genau wie die Fragensektion sollte nicht auf einer übersetzbaren Seite sein. Wofür gibt es denn Talk pages? Ich kenne einen Workaround, siehe Translations:Abstract_Wikipedia/Location_of_Abstract_Content/69/de, bin aber nicht sicher, ob das jeder schnallt. Zum Thema: unbedingt eigenes Projekt! Jerusalem-Artikel aus nur einer Quelle Wikidata? Oder solche zu prähistorischen Gruppen, die jedes Land für sich beansprucht und benamst? Unvorstellbar. Euer Vorschlag, astronomisches Objekt Jupiter, ist zweifelsfrei als unkritisch erwählt, wiewohl nach einem Gott benannt. Beim Mond sieht das aber ganz anders aus, ist doch en:Allah der Mondgott, was wiederum von Gläubigen bestritten wird, JHWH der Sturmgott. Beide waren vor der Monotheisierung familiär eingebunden, was wiederum zu wissen und wiederzugeben mancherorts als steinigungswürdige Häresie gilt. usw. Sargoth (talk) 00:04, 24 May 2025 (UTC)[reply]

  Abstract Wikipedia ist ja nicht dafür da, die Inhalte der Wikipedien zu ersetzen, sondern diese, wo sie fehlen, zu ergänzen. Die Artikel, die einer bestimmten Sprachversion besonders wichtig sind, sind ja auch diejenigen, die am wahrscheinlichsten in dieser Sprachversion zur Verfügung stehen werden, und entsprechend nicht von Abstract Wikipedia stammen werden. Und selbst wenn es nur bei unkritischen Artikeln hilft, ist ja schon viel geholfen. --DVrandecic (WMF) (talk) 10:38, 26 May 2025 (UTC)[reply]

• Options 1, 2, & 5 are problematic from a couple of perspectives. 1) Cultural. These existing projects have cultures that would need to either change to accomodate these new concepts or accept that there is a subset that has a different culture and ethos to the way everything else is done. 2) Administrative. This ties in with the cultural aspects. There would likely need to be specialist administrators to oversee the "AbstractWiki" parts, including the development of policies and managing vandalism. At the same time, those administrators would be expected to be aware of and implement the wider policies and procedures of the project. I have seen such expectations build into resentment, cabals and warfare, both on and off Wiki.

  Option 4 has the advantage of being specifically about the Abstract concept, but is disadvantaged by being focused on the Wikipedias. If the concept that the other projects are to be involved at some point, then there would be the need to develop an AbstractWiki for each project and thus dilute the knowledge and experience gained from the first. If Option 3 were chosen, then each project could be a subdomain/namespace. However, given the size of each of these there is the potential to outgrow its space. Beeswaxcandle (talk) 09:02, 23 May 2025 (UTC)[reply]

• Option 4 provided it is under CC-BY-SA. I get that an abstract version is going to be difficult to achieve where concepts are different. This is going to be at least as difficult as getting a mutually agreed definition of football, pants, or Cambridge that works on both sides of the Atlantic, but the exercise should be interesting. Hopefully it will also help identify factual differences between Wikipedias, much as before Wikidata, the death anomalies project used to identify people who were dead on one language version of Wikipedia and alive on another. WereSpielChequers (talk) 09:24, 23 May 2025 (UTC)[reply]

  Cambridge had to work in English both sides of the Atlantic already! :)

  Regarding the license, yes, agreed, that's the outcome of the previous licensing consultation. Abstract Content for Wikipedia should be under CC-BY-SA. --DVrandecic (WMF) (talk) 11:46, 23 May 2025 (UTC)[reply]

  This content is not reaching any treshold of originality and therefore cannot be licensed by CC-BY-SA. However Option 4 does make the most sense at it won't interfere with other projects and would not relay harm in form of bad publicity if the abstract content creates rubbish. --Matthiasb (talk) 00:50, 24 May 2025 (UTC)[reply]

  This content is not reaching any treshold of originality and therefore cannot be licensed by CC-BY-SA. --Says who? First of all, many Wikipedia articles are absolutely original today and would be just as original in a language-independent version, because the "structure, sequence and organization" of a complex text or even of a computer program can very clearly be protected by copyright. Besides, even if you argued that some Abstract Wikipedia articles are not sufficiently original, all that would mean is that folks might be able to ignore the licensing conditions. The license itself would still be valid as far as ordinary users are concerned. Hupaleju (talk) 05:50, 24 May 2025 (UTC)[reply]

• I think option 4 is the only one viable : to be dependant of another project will probably hamper the evolution on long term and might create tension. Wikidata has managed to build a community on its own space, despite being fairly technical, so I don’t see why Abstract couldn’t do it.

Now I address the subject from the Wikipedia in French perspective, it’s not totally in the current scope but worth to be mentioned I think. Considering the still high tensions around the Wikidata theme, the idea of direct inclusion of content from Abstract in WP:fr will probably be widely rejected. So I think the best way to link the content will be through the language menu, with an entry « international Wikipedia ». The problem is that on such a big Wikipedia, the content from Abstract will be interesting mostly for subjects that doesn’t have an article yet. However, it’s not possible currently to link the page of a non existing article to Wikidata. The placeholder extension is a bypass but it’s not activated on WP:fr because it imports content from outside the project, something the community is hostile to. I think the way Abstract will be reused on other projects is already central, because most people will come to Abstract from another project, hence if Abstract is rejected on other projects, people will not know about it or not see the point to spend time with it. --Runi Gerardsen (talk) 11:22, 23 May 2025 (UTC)[reply]

• i would  Support (prefer) option 4 abstarct.wikipedia.org, as it is in fact writing an wikipedia article, using functions instead of templates or text.
  

Option 3 in wikifunctions could also work (  Support), as abtract content and wikifunctiosn content rely heavily upon each other and both will be quite complex to write.

I absolutely are Strong oppose to option 2 (new wikidata data type) as then it will be very hard to find for users where to update the abstact content and very hard to see the history of just the abtract content. HenkvD (talk) 12:40, 23 May 2025 (UTC)[reply]

• Warum ist das hier und nicht in der enWP, wo es doch augenscheinlich allein um Englisch geht? Ohne eine Übersetzung in mindestens 10-20 Sprachen ist das Ganze hier komplett wertlosw für alle Projekte, in dxenen Englisch nicht die Muttersprache ist. Ich weigere mich, dieses arrogante Ansinnen der monolingualen Anglophonen hier inhaltlich zu bewerten, sie wollen offensichtlich nicht, dass Nicht-Englischsprachige hier mitmachen. Grüße vom Sänger ♫^(Reden) 13:04, 23 May 2025 (UTC)[reply]

  @Sänger Was meinst Du mit "nicht übersetzbar"? Oder meintest Du "nicht übersetzt"? --DVrandecic (WMF) (talk) 13:30, 23 May 2025 (UTC)[reply]

  Nicht übersetzbar. Diese Seite hier ist gegen das Übersetzen geschützt, also geht es hier nur iúm die monolingualen Anglophonen. Grüße vom Sänger ♫^(Reden) 13:32, 23 May 2025 (UTC)[reply]

  Gereade gesehen, es gibbt doch Teile, die übersetzt werden könnten, aber mal wieder nicht wurden. Also interessieren die internationalen Projekte mal wieder niemanden in der WMF, wie üblich. Grüße vom Sänger ♫^(Reden) 13:34, 23 May 2025 (UTC)[reply]

  Ein RfC kann erst dann gültig gestartet werden, wenn der Text in mindestens einem Dutzend Sprachen vorliegt, vorher ist es vollkommen wertloses Gelaber in einer beliebigen Sprache. Grüße vom Sänger ♫^(Reden) 13:36, 23 May 2025 (UTC)[reply]

  Hmm, laut Requests for comment/Policy kann ich nichts finden, dass das bestätigt. Fände das aber keine schlechte Idee: willst Du das als Regel vorschlagen? Bin auch offen dazu, dass wir die Konsultationszeit verlängern, sollte es Übersetzungen geben. --DVrandecic (WMF) (talk) 14:38, 23 May 2025 (UTC)[reply]

  Il est vrai que traduire la page projet et ses sous-pages en français serait une bonne idée pour qu'on essaie d'y comprendre quelque chose. Croquemort Nestor (talk) 16:10, 23 May 2025 (UTC)[reply]

  @DVrandecic (WMF): Das ergibt sich ohne explizite Regel aus Respekt. Von Anfang an die große Mehrheit der nicht-anglophonen WikimedianerInnen auszuschließen, indem gar nicht erst der Versuch unternommen wird, sie angemessen anzusprechen, delegitimiert ein solches Projekt von Anfang an.

  Dieser vollkommene Mangel an Respekt, der hier mal wieder mehr als deutlich wird, ist es, der die WMF so unbeliebt macht bei allen, die nicht aus der enWP-Blase kommen. Grüße vom Sänger ♫^(Reden) 08:21, 25 May 2025 (UTC)[reply]

• The question of how "long-form" content might be edited on Wikidata is interesting in its own right. Ultimately, we may want to enforce a workflow similar to the one currently used on Wikifunctions, where a Function implementation must first be written and then its linkage to the Function definition has to be confirmed by a trusted user: similarly, Wikidata long-form content might have some sort of provisional status at first and live in some sort of sandbox or talk page, with it only being added to the item after some sort of check by the community. The existing limits per Wikidata item might in principle be addressed by allowing claims about a single Wikidata item (i.e. Q-number or L-number) to be moved to different MediaWiki subpages, but still pertain to the same entity.
  I agree with the concern that editing Abstract Content inline with the Wikidata item might be difficult in many cases, hence something closer to the default Wikitext editing experience would work better. --Hupaleju (talk) 13:08, 23 May 2025 (UTC)[reply]

• I think the options as stated are unhelpfully mingling the technical and social aspects (or, the backend and frontend) of the future project. When an editor creates abstract content, which domain they're on should be orthogonal to which database the content ends up in. There's a note about Wikidata's interface being unsuitable for viewing and editing long-form content—so don't use that? But that shouldn't proclude the project from living on a subdomain of wikidata.org. YoshiRulz (talk) 22:18, 23 May 2025 (UTC)[reply]

  @YoshiRulz Thank you for your thoughts! Could you elaborate a little bit further? Where the project is located has major effects on the editor experience, particularly since the community of the project hosting Abstract Wikipedia can put editing restrictions on contributors, rules on the content, etc. As far as I understand it, assuming that we can put an editing interface that interfaces to a completely different project can be possible in some cases -- as the Wikidata Sitelinks and the Wikidata Bridge demonstrate -- but is always difficult, particular when the content starts to become more substantial in size. But maybe I misunderstand the suggestion. --DVrandecic (WMF) (talk) 10:29, 26 May 2025 (UTC)[reply]

  My point is exactly that "Who should be responsible for moderation and style?" is the key part of this consultation. Not the domain name, nor other things like the exact project name or visual identity, which I'm sure will be bikeshedded later. Being clear about technical limitations is good, I just felt it was overemphasised—and I should say that came mostly from reading the #Summary of internal discussions section, so maybe it was my expectations which were at fault.

  On the subdomain point: I don't know anything about the WMF server infrastructure, but I know that dividing subdomains between servers is easy compared to splitting by path/directory. YoshiRulz (talk) 15:54, 26 May 2025 (UTC)[reply]

  @YoshiRulz gotcha, thanks! The technical considerations are relevant too, but I agree, that the social implications play a more fundamental role, as these are much harder to be changed later, if at all. Thanks for emphasizing the issue! --DVrandecic (WMF) (talk) 15:44, 27 May 2025 (UTC)[reply]

• IMHO the most appropriate option is a new project (option 4) — though not exclusively for abstract encyclopedic articles, but for generic abstract textual content. I can see this project working in a similar way as Wikimedia Commons does today for media and raw data, but for language-independent prose instead.
  Some of the reasons I feel a separate wiki is a good idea:
  • Writing Abstract content is going to require a specific kind of expertise and writing style. Anyone who has worked with content that needs to be translated into very diverse languages knows how challenging that can be. This is not something that can be an afterthought or secondary focus of the community working on the project.
    For example, I'd expect the experience of Simple English Wikipedia, authors of translatable pages (e.g. Tech News) and translatable software in translatewiki.net to be a useful model for part of what this community needs to develop; but it still will need to chart new ground.
    Put simply, the editing community for abstract content will need to develop and constantly refine its own style guide and best practices, which IMO is a much more crucial success factor than any technical considerations. Having its own wiki, growing gradually and scaling its processes accordingly, seems like the best social structure to support this work.
  • A new project can easily be made to support generic kinds of language-independent content, thus providing material that could be used by Wikipedias, WikiVoyage, etc.
  • I can see the same format of abstract content existing in smaller parcels within existing projects (for example, as Wikidata item descriptions, Commons category descriptions, etc.), the same way that even though Commons exists, wikis can still host local images if they prefer.
  • I think it's reasonable to be cautious about starting new communities that may not take off as we'd hoped, given past examples in the movement (e.g. Wikiversity, Wikinews, etc.); but given the success of Wikidata and WikiFunctions, and the careful deliberation that the WikiFunctions/Abstract Wikipedia project has been characterized by so far (this discussion as a case in point), I would argue that some cautious optimism is warranted.
  • The challenge of creating and editing this new content format will require a quite unique interface; a separate wiki makes it easier to provide and evolve this new interface, via MediaWiki extensions, gadgets, stylesheets, etc. (think e.g. how editing translateiki.net or Wikisource involves a quite specialized UX) and dpoing this on a separate wiki would not interfere with (or add additional complexity to) the UX of existing wikis.
  --Waldyrious (talk) 22:55, 23 May 2025 (UTC)[reply]

  @Waldyrious: thank you for your thoughts, I really enjoyed reading your well-reasoned considerations. That's super helpful, and your points have indeed causes some change in my thinking.

  A further thought: what about the Abstract Content not being on an entirely new project, but hosted within a new namespace on Wikifunctions? Since one of Wikifunctions' main goals is to provide the functions needed to build Abstract Content, having those two together on the same project would have certain advantages. What do you think with regards to that compared to a completely new project? --DVrandecic (WMF) (talk) 10:33, 26 May 2025 (UTC)[reply]

  I can definitely see how the natural language functions existing in the same wiki as the abstract content may be helpful, just like it's easier for templates to live in the same wiki where they're used (in the case of templates there's a case to be made for central hosting, but that's a separate issue 😄). I can even agree that that benefit may take precedence over the factors I listed above. However, I wonder if mixing the two in the same wiki might not muddle the waters between what is Abstract Wikipedia and what is Wikifunctions even more, preventing either to evolve to its full potential.
  If the initial implementation is done in the same wiki, I would at least expect the path for an eventual split to be considered in advance and well prepared, so that such a transition, should the communities decide it's warranted, would be as painless and lossless as possible. Waldyrious (talk) 18:50, 26 May 2025 (UTC)[reply]

  Great points again, thank you! I found that extremely helpful, thanks! --DVrandecic (WMF) (talk) 15:45, 27 May 2025 (UTC)[reply]

• It is great idea, I am agree with it completely.July 2806

12:52, 24 May 2025 (UTC)

• Option 5 mit der englischsprachigen Wikipedia klingt nicht so dolle. Muss mir das alles hier nochmal im Detail durchlesen, aber aus dem Stehgreif sehe ich ein direktes Verknüpfen mit enwiki kritisch. Nyamo Kurosawa (talk) 18:18, 24 May 2025 (UTC)[reply]

  Na ja, solange es dann auch bei denen bleibt und ander Projekte nicht kontaminiert werden von irgendwelchem Maschinenschrott, kann das gerne so bleiben. Wichtig ist, dass dieser Unsinn in keinster Weise irgendwie echten Enzyklopädieprojekten übergebügelt wird, wenn diese das nicht explizit mit großer Mehrheit so wünschen. Grüße vom Sänger ♫^(Reden) 08:18, 25 May 2025 (UTC)[reply]

  @Nyamo Kurosawa: dem stimme ich zu. Ich wollte es nur als eine potentielle Möglichkeit ins Spiel bringen. --DVrandecic (WMF) (talk) 10:42, 26 May 2025 (UTC)[reply]

  For largely undocumented minoritized languages like the Tyap language, I think at the moment, we have so many definite articles to worry about. German learners think things are hard with 'der, die, das'; well, Tyap has 'hu, ji, ka, wu, ba, na' to worry about. Not funny at all. Machine contents would be great but we will have to fix some basics first to employ machine translations in the Tyap Wikipedia and Wiktionary later in the future. We have some catching ups to do, manually. Warm regards, Kambai Akau (talk) 12:23, 26 May 2025 (UTC)[reply]

  @Kambai Akau: Thank you! Yes, the whole point is that we do not use machine translation, but rather allow the community to write language functions and lexicographic content for Tyap themselves. I can see that there are 47 Lexemes about Tyap in Wikidata currently. I would hope that Tyap nouns are marked with the right noun class so that the correct article can be chosen, but I know virtually nothing about Tyap. --DVrandecic (WMF) (talk) 15:09, 26 May 2025 (UTC)[reply]

  @DVrandecic (WMF), thanks for giving more details about this. I am yet to grasp the entire concept really strongly. All the while I have thought of it like a machine translation concept. Our community is made up largely of people who are illiterate in Tyap or have insufficient knowledge in Tyap, thus making the work more on a very limited number of volunteers who may not entirely be devoted. Splitting that little number across projects like Wikipedia, Wiktionary, and Wikidata (lexeme translation) thus gets really slow. However, when we are really ready to up our game, giving more attention to the Wikidata lexemes (which I think we should), I will come to ask for someone from the Foundation to take my community through the basics of Wikidata lexeme editing (it could be you, if you are chanced). Hopefully by October 2025. We will definitely need it. Warm regards, Kambai Akau (talk) 20:26, 26 May 2025 (UTC)[reply]

  @Kambai Akau there are several options for this kind of training sessions! I'd be happy if you reach out to me or @Sannita (WMF) when the time comes, and we can point you to the right resources. Thanks! --DVrandecic (WMF) (talk) 15:46, 27 May 2025 (UTC)[reply]

  Thanks, @DVrandecic (WMF)! I will contact either of you on it as the time draws nigh. Warm regards, Kambai Akau (talk) 19:11, 27 May 2025 (UTC)[reply]

• Have you considered putting it in a different namespace on Wikifunctions? Compared to option 3 as written, I think that would be much cleaner than intermingled ZIDs, and would mitigate some of the clash-of-communities issues. For example, the new namespace could be CC-BY-SA licenced, user rights could be targeted at the correct namespace, and the UX could be quite distinct. --99of9 (talk) 05:33, 27 May 2025 (UTC)[reply]

  This is a good option. As some stated above, a seperate namespace on Wikifunctions will also allow for easier splitting to a completely new project if deemed necessary in the future (like option 5). I think this mostly aligns with option 5, but with the existing project being Wikifunctions (not listed above). ~/Bunnypranav:<ping> 06:32, 27 May 2025 (UTC)[reply]

  Yes, agreed. Given this consultation, this is starting to become one of my two favorite options, and I haven't really considered it before. --DVrandecic (WMF) (talk) 16:00, 27 May 2025 (UTC)[reply]

Mapping items and content, how to find content, entry points

I note from the discussions above that one problem is that there is an issue that be open after all : how to map the topics and the "abstract articles". Is it a one/one mapping between Wikidata items and abstract articles (one/at-most one actually, there might not have any abstract content for an item, a "one item/many abstract contents" ?

Mapping topics has technical issues that have social implications with the contributors. Qids are the natural identifier for topics, only them can be actually used when there is no article in a topic on a Wikipedia, and they are the most stable. It has the problem that a community might be reluctant to use them in the core of an article, especially when editing from the wikicode (it might be less of a problem with visual editor because it can map the id and the label and select the item automatically, potentially, if there is a item selection mechanism). So to reuse some abstract content in a Wikipedia (or wikidata content on an item whatsoever), on frwiki, you can use the identifier indirectly in an infobox call for example. In turn this can be used, in wikis in which it is activated, with the "Article placeholder" extension which could be used to use abstract articles on local wiki. But a community might not want to do that at all for various reason, so we can't really assume the content can be findable from a wiki.

One entry point for the whole thing might be the wikipedia.org domain which currently lets you select a topic and a project you are interested in, the topic could be any wikidata item(?), abstract content could be provided here if community and foundation are OK with this, to make the landing page a bit more like a search engine landing space who redirects you to where you want to go. Not sure of how this page is popular.

Wikidata on the other hand has a natural mapping between a space for abstract content and items. The "create a new item" button is present here. You could have several type of abstract contents associated to an item (provided it's supported by community), a "autodescription" content for example, which is natural to have, and if it uses information from the item data the editing interface for the item is also present at the same place. This is also relevant from an "article" abstract content : when writing / testing abstract content you might want to edit the item data in parallel for convenience … (you might also want to edit the lexical data but it's another line of story, the mapping is way harder). I'd be inclined these points are positive points for storing the abstract datas in Wikidata close to their item pages.

Not well structured a comment and on definitive answer but I don't think all this point have been raised yet. TomT0m (talk) 08:50, 27 May 2025 (UTC)[reply]

• In principle you could use Wikidata's Q-items as "topic identifiers" while still editing the article-form Abstract content on a separate project. It is already the case that each article on any one Wikipedia language edition is supposed to be linked to a single Wikidata item (though that Wikidata item may be one that simply identifies a "Wikipedia article with multiple topics) and Abstract Wikipedia needs not be any different.
  It has the problem that a community might be reluctant to use [Q-items] in the core of an article, especially when editing from the wikicode (it might be less of a problem with visual editor because it can map the id and the label and select the item automatically, potentially, if there is a item selection mechanism). - The Wikidata Query Service (WDQS) text-entry UI solves this issue by displaying a "hint" about the labeling of a Q-item when you hover the mouse pointer over it, and allowing one to "search" for Q items via a keyboard shortcut. These solutions could be imported to the Wikitext editing interface. Hupaleju (talk) 11:22, 27 May 2025 (UTC)[reply]

  Sure, it could be, but this would either require a new syntax, which is quite rare in the wiki world, or a special treatments of links such as d:Q42. But template currently usually use the "Q42" raw string for Wikidata identifier. A new templatedata parameter datatype could help of course. But it's not done and a global thinking about how all this interacts with the project goals and the communities and what they want could be useful to motivate. It's obvious to me from the start that identifiers from Wikidata could get a better handling in wikis, I felt quite alone in this so the traction might not be easy to get and utility might not be so easy to motivate to communities. TomT0m (talk) 17:56, 29 May 2025 (UTC)[reply]

I am going to start with my least preferred option:

• I do not like Option 5 because it would put our abstract content on a wiki where it does not really belong. Commons is a media repository, Meta is not a content project and the English Wikipedia is probably the Wikipedia that has the least benefits from abstract content. Furthermore there are lots of specific rules on enwiki that we might not want to have for the abstract content.
• My main concern with Option 1 and Option 2 is that it would be another burden for the Wikidata infrastructure. Wikidata is already the project with the most content pages and we have only ~70 admins for taking care of maintenance tasks. We already have two very different content types on Wikidata: items and lexemes. Not everyone in the community in familiar with these two content types and another one might make things even more difficult. The CC0 license on Wikidata might also be a problem for the license of the Abstract Wikipedia.
• Option 3 would be fine for me. Wikifunctions is a new project and since there will be strong relations between the abstract content and the functions it might make sense to have these contents on the same wiki.
• Option 4 would be fine for me as well. Having a seperate project for the content could make it easier to distinguish between the (technical) work on functions and the (encyclopedia related) work on abstract content.

--Ameisenigel (talk) 08:07, 4 June 2025 (UTC)[reply]

It seems abstract articles are meant to be fetced as such, rendered in the local language. The abstract articles would be different between e.g. Wikipedia, Wikivoyage and Wikisource, but I wonder how differences between language versions of the projects will be accommodated. E.g., Wikipedias may have different standard structures of biographies or sports articles. There may also be different views on what kinds of exernal links to have, and what references are seen as good.

For the abstract articles to conform to the expectations in the projects, one would need to enable local tweaking. E.g., in Wikipedia in Swedish, infoboxes censor data fetched from Wikidata that seems not to be reliably sourced or otherwise problematic. On that Wikipedia, there is a community of editors that know Wikidata well and can tweak templates according to wishes of the larger community. I think such tweaks of Abstract Wikipedia would be best accommodated in a separate namespace in that specific project, while most of the Abstract Wikipedia would be its own project, like Wikidata now.

Have such local tweaks been considered?

–LPfi (talk) 07:21, 28 May 2025 (UTC)[reply]

• Oczekuję opcji 6 - całkowite odrzucenie jako marnowanie czasu i zasobów. Przede wszystkim ludzkich, na poprawianie tłumaczeń. Mamy już wystarczająco pracy z fatalnymi narzędziami, nie potrzebujemy więcej śmieci w wikiprzestrzeni. Lukasz Lukomski (talk) 07:45, 28 May 2025 (UTC)[reply]

  Pełna zgoda! Helemaal mee eens! Grüße vom Sänger ♫^(Reden) 11:31, 28 May 2025 (UTC)[reply]

@LPfi Yes, such local tweaks have been considered. There are two approached on how:

1. Local articles always override articles created from Abstract Content. If a topic is important enough for a community, I would always expect it to have a local article, just written in the language of the project.
2. For some local tweaks, particularly if they are as predictable as you say, it would be possible to write a function that either checks if the local requirements are given, or even modifies the abstract content to make them fit local rules.

I am curious about how feasible Option 2 will be. I also expect that most projects but the largest ones actually have such rules that would require accommodation. --DVrandecic (WMF) (talk) 10:54, 3 June 2025 (UTC)[reply]

• My vote is for Option 4. I was going to write more about it, but it looks like Waldyrious already wrote most of what I wanted to say! Including the comparison of this "abstract text repository" to Commons - it could become a general resource, with a scope quite a bit broader than not just Wikipedia, but Wikimedia in general. The only thing I'll add is that a strong argument in favor of giving this its own project - rather than a namespace on Wikifunctions/Wikidata/Commons - is not technical but social: the massive difference in nature between generating functions/data/images, and developing encyclopedic text - at least for the text that would end up on Wikipedia. I have no idea how contentious the "abstract Wikipedia" parts would be, but there's the possibility that they could become just as contentious as the most warred-over topics on Wikipedia. This does not make a good fit with any of the other current "repository" sites: imagine being banned from editing Wikifunctions, for example, because you have an unpopular view on, say, the sovereignty of Crimea. Yaron Koren (talk) 19:16, 28 May 2025 (UTC)[reply]

  Presumably the 'abstract' content would be subject to the founding principles, most relevantly to geopolitics the principles one and four. An encyclopedia could discuss views on the status of a territory, but not forward one without sourcing. Arlo Barnes (talk) 05:08, 30 May 2025 (UTC)[reply]

The founding principles are great, but of course their interpretation is in the eye of the beholder - one man's impassioned defense of an alternate viewpoint in the interest of neutrality is another's disruptive editing. Yaron Koren (talk) 15:37, 2 June 2025 (UTC)[reply]

@Yaron Koren Thank you, these are great points. I, too, expect those points to be rather contentious. And the point of keeping editing rights for content and editing rights for functions separate is indeed a good one (and directly contradicting with my favorite current idea, so there's that :D ). Thanks! --DVrandecic (WMF) (talk) 11:07, 3 June 2025 (UTC)[reply]

• The location question can't be answered without first knowing how the content is going to be licensed. Is it going to be CC-0? CC-BY-SA? Nosferattus (talk) 22:40, 30 May 2025 (UTC)[reply]

  @Nosferattus agreed. That's why we had the licensing discussion before that. The result has been published: Abstract Content is going to be under CC-BY-SA. I hope this helps with the next steps. --DVrandecic (WMF) (talk) 12:05, 3 June 2025 (UTC)[reply]

• Options 2 and 3 would recommend CC0 for Abstract Content. WHY is this mentioned, when it has supposedly been decided that CC-BY-SA applies? I, and many others in the editing community, would be more than happy to fund a lawsuit against the Foundation if it attempted to apply CC0. (edit sorry for the strong kneejerk reaction) While "Jupiter is the fith planet" may be defended as uncopyrightable fact, any court on earth would laugh at anyone trying to translate the complex free-form expressive content in Donald Trump's biography into "abstract" language. The courts are universally clear that translations are bound by the original copyright license. Alsee (talk) 05:11, 1 June 2025 (UTC)[reply]

  I am not a big fan of threatening legal actions.

  Nevertheless, it is correct that we have already decided on the licensing rules for Abstract Wikipedia in a previous decision, and the goal of this discussion is not to put this into question. I fixed the text. --DVrandecic (WMF) (talk) 12:35, 2 June 2025 (UTC)[reply]

  Strictly speaking the licensing discussion's outcome was only about "Abstract Content for Abstract Wikipedia": nothing was said about "Abstract Content in general" (note that this point was explicitly raised, and agreed upon, when that discussion happened). So this exactly agrees with Alsee's expectation that the "complex free-form expressive content" that's inherently found in mostly any non-trivial encyclopedic text should keep its CC-BY-SA license!

  But it's entirely possible that there will be other sorts of data that will technically be in the form of Abstract Content (such as declarations of basic linguistic or semantic constructs, which might be relied upon by Abstract Wikipedia and other Wikimedia projects but also make it easier to create Abstract Content for other purposes; or strictly factual claims not unlike those found in Wikidata today, but going beyond the expressiveness of our current Wikidata model) for which a CC0 license would quite probably be a lot more appropriate. These two distinct potential settings should not be conflated, and Wikidata is probably a very fitting venue for the latter sorts of data. Hupaleju (talk) 14:02, 3 June 2025 (UTC)[reply]

  @DVrandecic (WMF) thank you for your clarification and edit. I apologize for my kneejerk reaction, perhaps hyper-vigilant of any potential or perceived threat to the project (and it's license). I have struck the text. Alsee (talk) 20:11, 7 June 2025 (UTC)[reply]

• Recently a new Status update has been posted for Wikifunctions, which includes a summary of Denny's current thinking about where to host the Abstract Content. Please read it, and I think Denny might want to clarify if there are any doubts, but it looks like his current proposal involves a combination of what we are calling Option 4 with a new project or namespace for the long-form encyclopedic Abstract Content for which a CC-BY-SA license has already been agreed upon, and Option 3 with Wikifunctions as a host for more baseline Abstract Content that can be directly referenced in Wikidata statements and would most easily be licensed under CC0. AIUI, compared to hosting such content directly in Wikidata, this involves less development work and more elegantly resolves the issue of how "complex" content might be edited in the current Wikidata UI, so I am quite okay with it.

Also, although we know very little yet about what Abstract Content will look like, I do have to stress that there will probably be a lot of "infrastructural" underlying data about constructs in language and semantics that has the role of simply making it feasible to write expressively about complex topics in the first place. I expect that this sort of basic infrastructure (which has no real equivalents in current projects, aside from what's in Wikidata itself) would then also be hosted on Wikifunctions and made available under a CC0 license, which might help establish the structure of Abstract Content as a quasi-standard for multi-language communication even outside the Wikimedia movement proper, much like Wikidata's current role as a "hub" of the semantic web. (While human-editable semantic interlinguas for automated machine translation have certainly been developed in the past, they have so far been either wholly proprietary or mere academic proofs of comcept; we are very much lacking a usable open standard in this domain!) I think that's a really exciting prospect that should be explicitly considered when making these decisions. Thanks for your attention. --Hupaleju (talk) 15:29, 7 June 2025 (UTC)[reply]