Abstrakte Wikipedia/Ort des Abstrakten Inhalts

Absrakte Wikipedia wird mehr Leuten erlauben, ihre Stimme in ihrer Sprache einem Grundgerüst des Wissens beizugeben. Dieses Grundgerüst wird in vielen Sprachen verfügbar sein. Das Grundgerüst des Wissens (im Original Grundlinie) wird als abstrakter Inhalt aus Wikidata-Daten generiert, gespeichert und gepflegt. Dieser abstrakte Inhalt wird mit Hilfe von Funktionen aus Wikifunctions und Lexemen aus Wikidata in eine spezifische natürliche Sprache übertragen. Dies wird mehr Menschen ermöglichen, Inhalte in ihrer Sprache zu lesen.

Hintergrund zu Abstract Wikipedia unter Abstract Wikipedia. Dort sind auch Aufzeichnungen von Vorträgen und Links zu Dokumenten zu finden.

Wir - DVrandecic und das Team - wollen den Entscheidungsprozess klar machen: Wir wissen noch nicht, welche Option wir verwenden wollen, deshalb beraten wir hier. Wir werden die Argumente der Wikimedia-Gemeinschaften berücksichtigen und wollen mit den verschiedenen Communitys beraten und Argumente hören, die uns bei der Entscheidung helfen. Die Entscheidung wird nach Ablauf der Konsultationszeit von der Foundation getroffen und mitgeteilt.

Beispiel

Angenommen, wir wollen einen neuen Wikipedia-Artikel über den Planeten Jupiter erstellen, und die erste Version dieses Artikels soll wie folgt aussehen (dies sind die ersten beiden Sätze des Simple English Wikipedia-Artikels):

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

Der beschriftete abstrakte Inhalt, der diesen natürlichen Text repräsentiert, könnte so aussehen:

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])

Beispielseite.

Das ist wie eine Funktion, die sich selbst anruft, in diesem Fall zur Funktion Article. Die Funktion Article wird in Wikifunctions definiert. Für unsere Bequemlichkeit wird dieser abstrakte Inhalt mit englischen Etiketten angezeigt, und Benutzende würden diese etikettierten Inhalte in einem schönen UX sehen. Im System wären alle diese IDs und sehen vielleicht so aus - aber denk daran, das ist ganz intern und nicht wie es Benutzende sehen würden:

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])

Es wird UX-Schnittstellen geben, die die Ansicht, Wartung, Erstellung und Bearbeitung dieser Abstract-Inhalte für alle Menschen ermöglichen, ohne technische Expertise zu benötigen.

Wikifunctions stellt dann eine Funktion zur Verfügung, die diesen abstrakten Inhalt in einen Text in natürlicher Sprache umwandelt.

Die Fragen, auf die wir jetzt antworten wollen, sind: Wo speichern wir diesen Funktionsruf auf Article und wie assoziieren wir ihn mit dem Wikidata-Element für Jupiter, Q319?

Konsultationsprozess

Die Konsultation läuft vier Wochen lang. Wir (das Team) werden während dieser Zeit alle relevanten Fragen beantworten. Bitte alle Fragen als solche kennzeichnen, damit sie nicht übersehen werden.

In der ersten Woche werden wir die Beiträge der Communitys ohne unseren POV sammeln. Damit wollen wir die Intention der Beiträge besser erfassen.

Nach einer Woche werden wir unsere eigenen Gedanken und die bereits geführten Diskussionen veröffentlichen. Dann fangen wir an, uns hier zu beteiligen.

Wir haben uns verpflichtet, hier auf Meta zu diskutieren und können uns wenig woanders beteiligen. Wir bemühen uns, andere Sprachen als nur Englisch zu sprechen.

Nach Ablauf der Konsultationszeit werden wir alle Beiträge durchlesen und eine Entscheidung treffen. Wir wollen die Entscheidung dann zeitnah treffen und veröffentlichen.

Optionen

Das Element (Item) Jupiter kann unter Q319 gefunden werden. Die Optionen, die diesem Absatz folgen, hier im Überblick:

Option 1: Einen Namensraum mit Datenobjekten in Wikidata verknüpfen

Wir würden einen neuen Namensraum für Datenobjekte einführen. Dieser Namensraum enthält den abstrakten Inhalt für das Datenobjekt. Unter Q319 würdest du den abstrakten Inhalt des Jupiter-Artikels finden, der in Wikipedias ohne einen Jupiter-Artikel verwendet werden würde.

Überlegungen

• Die Community zum Erstellen und Verwalten abstrakter Inhalte wäre Teil der Wikidata-Community.
• Wie sieht es mit abstrakten Inhalten für andere Projekte wie Wikivoyage aus? Würden die unterschiedlichen Anforderungen durch einen eigenen Namensraum unterstützt werden?
• Wie viele zusätzliche Bearbeitungen und Inhalte würde dies für Wikidata mit sich bringen?

Option 2: Einen neuen Datentyp für Abstrakte Inhalte auf Wikidata erstellen

Wir würden einen neuen Datentyp auf Wikidata erstellen, der Abstrakte Inhalte speichern kann. Anschließend könnte die Community eine oder mehrere Eigenschaften auf Wikidata erstellen, die abstrakte Inhalte speichern und sie mithilfe dieser Eigenschaften mit einem bestimmten Datenobjekt verknüpfen.

Für Jupiter bedeutet dies eine neue Aussage in Q319 neben den vorhandenen Aussagen.

Überlegungen

• Die Community kann mehr als eine Eigenschaft erstellen und diese feinkörniger verwenden, z. B. für Wikivoyage, für Geschichte, für abstrakte Glossen usw.
• Die Community zum Erstellen und Verwalten abstrakter Inhalte wäre Teil der Wikidata-Community.
• Dadurch würden recht schwergewichtige Werte in Wikidata eingeführt werden, die nicht wirklich zum aktuellen Nutzungsmodell passen.

Option 3: Objekte auf Wikifunctions

Der Abstrakte Inhalt würde auf Wikifunctions gespeichert werden und Wikidata hätte eine neue Eigenschaft, die auf die ZIDs verweist, um zum Abstrakten Inhalt zu gelangen. Dies ist auch eine natürlichere Darstellung für Modellinhalte, z. B. für Funktionen, die in vielen Objekten verwendet werden.

Überlegungen

• Dies wäre bei Weitem die geringste Entwicklungsarbeit.
• Die Community zum Erstellen und Verwalten abstrakter Inhalte wäre (überwiegend) Teil der Wikifunctions-Community.
• Die Wikifunctions-Plattform ist ziemlich technisch und die Nähe der technischen und nicht-technischen Teile zueinander kann die Trennung verwischen.
• Der gleiche Mechanismus kann auch für Wikivoyage und andere Projekte funktionieren.

Option 4: Objekte in einer neuen Wikipedia-Sprachversion oder einem neuen Wiki-Projekt

Wir erstellen ein komplett neues Wiki-Projekt (z. B. abstract.wikipedia.org oder ein anderer Name, der noch nicht feststeht), in dem Abstrakte Inhalte erstellt, gespeichert und gepflegt werden. Wikidata verwaltet die Verbindungen.

Überlegungen

• Eine neue Community rund um die Erstellung und Pflege Abstrakter Inhalte muss wachsen, kann aber fokussierter und engagierter sein.
• Dies führt zu einer weiteren Fragmentierung der Wikimedia-Communitys in ein weiteres Wiki, das die Leute verwenden müssten.
• Dies erleichtert die Verwendung einer anderen Urheberrechtslizenz für die Inhalte der Abstrakten Wikipedia.

Option 5: Objekte in einem neuen Namensraum in einem vorhandenen Projekt

Wir können zu einem bestehenden Projekt einen neuen Namensraum hinzufügen, in dem der Abstrakte Inhalt gespeichert wird. Hier sind die wahrscheinlichsten Optionen:

1. Commons
2. Meta
3. Englische Wikipedia, nicht an die Artikel angehängt

Überlegungen

• Jede dieser Optionen hätte sehr unterschiedliche soziale Auswirkungen auf die Community, die am Abstrakten Inhalt arbeitet.
• Wie viele zusätzliche Bearbeitungen und Inhalte bringt dies für das bereitstellende Wiki mit sich? Würde es die Community-Prozesse überfordern oder durch bestehende Prozesse verzerrt werden, die möglicherweise nicht zutreffend sind?

Zusammenfassung der internen Diskussionen

Allgemeine Fragen des Teams

Was ist mit anderen Projekten als Wikipedia?

Die Optionen 1, 4 und 5 sind Lösungen, die keine einfache Erweiterung für z. B. Wikivoyage ermöglichen würden. Die Optionen 2 und 3 würden eine einfache Erweiterung ermöglichen, um anderen Projekten abstrakte Inhalte zu ermöglichen.

Was ist mit anderen Anwendungsfällen als Wikipedia?

Einige andere Anwendungsfälle, die wir zuvor besprochen haben, sind abstrakte Beschreibungen und abstrakte Glossen. Die Optionen 2 und 3 würden diese am einfachsten unterstützen.

Wie ist mit der Lizenzierung der verschiedenen Inhalte?

Wikidata ist grundsätzlich CC0, Wikifunctions verwendet CC0 für Inhalte und Apache2 für Code. Wikipedia-Inhalte sind CC-BY-SA 4.0. Die Optionen 1, 4 und 5 ermöglichen eine einfache Trennung, wobei Abstrakte Inhalte problemlos unter CC-BY-SA 4.0 lizenziert werden können. Die Optionen 2 und 3 wären einfacher, wenn CC0 für Abstrakte Inhalte verwendet würde; dies widerspricht jedoch unserer vorherigen Lizenzierungsentscheidung, die eindeutig besagt, dass (ähnlich wie Wikipedia selbst heute) die Abstrakten Inhalte für die Abstrakte Wikipedia unter einer CC-BY-SA-Lizenz stehen.

Überlegungen des Teams zu bestimmten Optionen

Option 1: Namensraum auf Wikidata

Diese Lösung ist sehr spezifisch für die Abstrakte Wikipedia und lässt sich z. B. nicht auf das Abstrakte Wikivoyage erweitern.

Das Konzept der "angehängten" Namensräume ist kompliziert und es wäre eine Herausforderung, hierfür eine qualitativ hochwertige MediaWiki-Unterstützung bereitzustellen.

Wikidata verfügt bereits über ein sehr hohes Volumen an Bearbeitungen und Inhalten und wir würden noch deutlich mehr hinzufügen.

Option 2: Datentyp auf Wikidata

Die Erstellung einer guten UX für einen Datentyp für Abstrakte Inhalte wird angesichts des Kontexts der bestehenden Wikidata-Oberfläche eine besondere Herausforderung darstellen. Abstrakte Inhalte werden wahrscheinlich Langform-Inhalte sein und die Benutzeroberfläche von Wikidata-Datenobjekten eignet sich dafür nicht. Angesichts der Einschränkungen einer Datenobjektseite würde es wahrscheinlich erheblichen zusätzlichen Aufwand erfordern, eine neue, gute UX-Erfahrung zu schaffen. Eine Möglichkeit wäre prinzipiell ein Modal zum Bearbeiten, aber diese haben ihre eigenen inhärenten UX-Nachteile und sind in der Regel komplexer zu implementieren als die gleiche Funktionalität in einer eigenen dedizierten Umgebung. Außerdem unterbrechen sie die aktuellen Designmuster einer Datenobjektseite und entsprechen möglicherweise nicht den für die Zukunft geplanten Mustern.

Darüber hinaus ist der Abstrakte Inhalt zwar einigermaßen strukturiert und maschinenlesbar, jedoch viel weniger (oder zumindest anders) als ein Datenobjekt und seine Struktur kann wahrscheinlich nicht mit SPARQL abgefragt werden.

Außerdem könnte es zu einer Duplizierung von Primärfakten direkt in einem Datenobjekt kommen. Dies erscheint schlimmer als die Duplizierung in einem Wikipedia-Artikel (ob abstrakt oder nicht), da es die Verantwortlichkeiten der Autoren, die einen Fakt in einem Datenobjekt aktualisieren, vermischt/erweitert. Sie müssten nun die gleiche Information zweimal mit der gleichen Aufgabe ändern, was sehr frustrierend wäre. Wenn der abstrakte Inhalt in einer eigenen Domäne existiert, wäre die Verantwortung für dessen Pflege klar getrennt, genau wie es bereits bei den bestehenden Sprach-Wikipedias der Fall ist.

Dies bringt zwei zusätzliche Herausforderungen mit sich: Erstens würden die Wikidata-Datenobjekte größer werden und wir bräuchten eine Lösung, die dies ermöglicht; MediaWiki setzt eine harte Grenze, die einige Wikidata-Datenobjekte bereits erreichen. Und zweitens müssten wir entscheiden, wie wir mit der Visualisierung, Bearbeitung und Differenzierung potenziell sehr großer und komplexer Werte im Kontext eines bestehenden Systems umgehen, das für seine recht unterschiedlichen Anwendungsfälle gut funktioniert. All diese Probleme gäbe es mit den anderen Optionen nicht.

Die Möglichkeit, Abstrakte Inhalte in Wikidata-Datenobjekten zu speichern, könnte Anfragen nach der Möglichkeit, andere unstrukturierte Langtexte zu speichern, die nicht so gut abgefragt werden können (wie Gedichte), erneut aufkommen lassen. Bisher hat das Wikidata-Team diese Anfragen stets abgelehnt, da sie nicht zu Wikidata passen.

Wikidata verfügt bereits über ein sehr hohes Volumen an Bearbeitungen und Inhalten und wir würden noch deutlich mehr hinzufügen.

Der neue Datentyp wäre viel größer als alles, was wir bisher auf Wikidata hatten, und würde verschiedene damit verbundene Probleme mit sich bringen.

Option 3: Objekte auf Wikifunctions

Dies würde viele der Herausforderungen von Option 2 (Wikidata-Datentyp) lösen und die Vorteile der Flexibilität beibehalten. Der Inhalt würde aus dem Datenobjekt entfernt werden.

Dies hätte den zusätzlichen Vorteil, dass wir mehrere Datenobjekte unterstützen könnten, die sich jeweils auf dasselbe Objekt in Wikifunctions beziehen. Während dies für abstrakte Inhalte von Wikipedia-Artikeln wenig sinnvoll erscheint, könnte es sich für abstrakte Beschreibungen von Wikidata-Datenobjekten und abstrakte Glossen von Lexemen als sehr nützlich erweisen. Durch die Erstellung abstrakter Inhalte und Funktionen auf derselben Plattform wäre die Zusammenarbeit zwischen Personen, die sich auf einen dieser Bereiche konzentrieren, direkter.

Dies könnte eine Moderationsherausforderung für die Wikifunctions-Community darstellen, da Inhalt und Änderungsrate deutlich zunehmen würden. Der Umfang des Wikis müsste erweitert werden, um sowohl Inhalte als auch 'strukturellere', die Community unterstützende Dinge abzudecken. Geht man davon aus, dass sich Communitys am ehesten um “Inhalte” (ob abstrakte Interlingua oder nicht) und “Funktionen” gruppieren, würden Objekte in der Wikipedia zwei heterogene Communitys vereinen; geht man hingegen davon aus, dass sich Communitys um “abstrakte Darstellungen bon Sprache” aufteilen, würden sie zwei ähnliche Untercommunitys vereinen.

Das Suchsystem und die Inhalte der Hauptseite würden komplizierter werden, mit (mehr) verschiedenen primären Anwendungsfällen (Codefunktionen, linguistische Funktionen, Enzyklopädie-Themenseiten)

Option 4: Neues Projekt

Dies würde eine sehr klare Unterscheidung zwischen Wikipedia-Inhalten und Nicht-Wikipedia-Inhalten ermöglichen und den abstrakten Inhalten eine deutliche Sichtbarkeit verleihen, die sonst zwischen Wikifunctions und Wikidata verborgen wäre. Andererseits würde es die Wikimedia-Communitys weiter spalten.

Option 5: Namensraum in einem vorhandenen Projekt

Dies würde für ein unabhängiges Projekt eine erhebliche Änderung des Umfangs bedeuten.

Die Verwendung der Englischsprachigen Wikipedia erscheint als besonders schlechte Idee, da dies die Vorherrschaft des Englischen in der Wikimedia-Bewegung weiter zementiert. Zudem würde es die zukünftige Unterstützung von Inhalten außerhalb des Wikipedia-Bereichs schwieriger machen, wie etwa lexembezogene Inhalte für Wiktionarys oder ortsbezogene Inhalte für Wikivoyages.

Benutzererfahrung

Aus UX-Sicht hätten die Optionen 1 (mit einem Datenobjekt auf Wikidata verknüpft), 4 (neues Projekt) und 5 (nicht-verknüpfter Namensraum nicht auf Wikidata) sowie in mancher Hinsicht auch Option 3 (Wikifunctions-Objekte) viele gemeinsame Funktionen: Jede von ihnen hätte eine ganze Seite für abstrakte Inhalte (auch wenn diese Seiten an unterschiedlichen Orten liegen und auf unterschiedliche Weise mit dem Rest des Ökosystems verbunden wären). Jede dieser Optionen würde bedeuten, dass wir eine vollständige Seite hätten, die ausschließlich abstrakten Inhalten gewidmet ist, sie verwaltet und den Verlauf dieser Seite verfolgt, und zwar ausschließlich von abstrakten Inhalten und nicht vermischt mit anderen Inhalten.

Aus der UX-Perspektive eines Lesers haben Option 2 (Wikidata-Datentyp) und Option 3 (Wikifunctions-Objekte) viele Gemeinsamkeiten, da sie das Wikidata-Datenobjekt grundsätzlich auf die gleiche Weise verändern würden. Für den Leser können wir die Darstellung des Funktionsaufrufs (d. h. den abstrakten Inhalt in der Sprache des Lesers) inline anzeigen und ihn kürzen, um das gesamte Seitenerlebnis nicht zu dominieren. Beim Bearbeiten und Pflegen des Inhalts unterscheiden sich die beiden Optionen jedoch erheblich, da die Bearbeitung des abstrakten Inhalts entweder inline im Wikidata-Datenobjekt erfolgt oder zur entsprechenden Seite auf Wikifunctions führt.

Entwicklung

Sowohl Option 1 (mit Datenobjekt verknüpft) als auch Option 2 (Wikidata-Datentyp) erfordern eine enge Zusammenarbeit zwischen dem Wikidata-Team und dem Wikifunctions-Team. Die anderen Optionen reduzieren die Notwendigkeit einer Zusammenarbeit der beiden Teams. Option 1 stellt die höchsten Anforderungen an die MediaWiki-Plattform; das Problem des Wachstums der Wikidata-Datenobjekte bei Option 2 erfordert ebenfalls die Zusammenarbeit mit der MediaWiki-Gruppe.

Community

Eine der interessantesten Fragen ist, wo die neue Community der Ersteller abstrakter Inhaltse angesiedelt wäre. Bei den Optionen 1 (mit Datenobjekt verknüpft) und 2 (Wikidata-Datentyp) würden sie eine Unter-Community der Wikidata-Community bilden. Dabei handelt es sich um eine bereits etablierte, mehrsprachige, freundliche und technisch versierte Community. Sie verfügt bereits über einige Arbeitsabläufe zur Relevanz und teilweise Arbeitsabläufe zur Lösung von Inhaltsstreitigkeiten. Zusätzliche Einstellungen/Benutzeroberflächen werden benötigt, damit Autoren Beobachtungslisten auf Wikidata filtern können.

In Option 3 (Wikifunctions-Objekte) wären sie eine Unter-Community der Wikifunctions-Community. Dies würde den Charakter der erwarteten Community deutlich verändern — von einer Mehrheit von Leuten, die sich für Sprache und Code interessieren, zu einer Mischung aus diesen Leuten und weiteren, die sich für Details zu bestimmten enzyklopädischen Themen interessieren. Möglicherweise würde es aber den Arbeitsablauf, "einen abstrakten Satz zu erstellen und diesen dann in einer avstrakten Inhaltsseite zu verwenden", sowohl technisch als auch mental vereinfachen, indem beide im selben Wiki suchbar wären.

Bei Option 4 (neues Projekt) müssten sie eine eigene Community gründen, mit allen damit verbundenen sozialen Kosten.

Bei Option 5 (nicht verknüpfter Namensraum) würden sie zu einer Unter-Community des jeweiligen Wikis werden; der Fokus der Community des bereitstellenden Wikis würde zwischen den neuen Inhalten und ihrer bestehenden Aufgabe aufgeteilt werden.

Dies ist eine wichtige Frage, da sie darüber entscheidet, welche Administratoren und welche Art von Administratoren die Pflege und Steuerung der abstrakten Inhalte übernehmen müssen.

Flexibilität

Ein wichtiger Aspekt sollte die Flexibilität sein, die die jeweilige Lösung der Community bietet. Die Optionen 1 (mit Datenobjekt verknüpft), 4 (neues Projekt) und 5 (nicht verknüpfter Namensraum) bieten jeweils nur sehr begrenzte Möglichkeiten für kreative Entwicklung, die wir nicht vorhergesehen haben. Tatsächlich sind die Lösungen so eingeschränkt, dass wir für die zukünftige Unterstützung von Wikivoyage wahrscheinlich dedizierte Ressourcen bereitstellen müssten, sonst wird dies nicht möglich sein. Dies gilt umso mehr für andere Projekte, die von dieser Lösung profitieren könnten. Dies gefährdet die Unterstützung von Wikivoyage und anderen Projekten.

Option 2 (Wikidata-Datentyp) und noch mehr Option 3 (Wikifunctions-Objekte) bieten deutlich mehr Flexibilität, und wir können davon ausgehen, dass wir im Laufe der Jahre kreative und neuartige Anwendungen sehen werden, die uns heute sehr überraschen würden. Sie bieten der Community bei weitem die größte Macht, aber auch die größte Komplexität.

Gedanken des Teams zu Kombinationen und anderen Ideen

Option 4 (neues Projekt) könnte sich auch auf Abstrakte Inhalte im Allgemeinen beziehen und nicht nur auf die Abstrakte Wikipedia und so auch das Abstrakte Wikivoyage und möglicherweise andere Projekte unterstützen. Es könnte auch Artikelinhalte feiner aufteilen als bisher. Wikidata könnte dann in verschiedenen Entitäten auf die verschiedenen Teile verweisen und Metadaten bereitstellen.

Eine Kombination von Optionen 3 (Wikifunctions-Objekte) und 4 (neues Projekt) könnte eine gewisse Flexibilität erhalten (z.B. Option 3 für kurze, gemeinsam genutzte abstrakte Beschreibungen und Glossen auf Wikifunctions), mit einem geeigneten Ort, um vollständige, langfristige Inhalte auf seinem eigenen Wiki zu entwickeln (Option 4).

---

Fragen bitte hierhin: Questions

Diskussionsbeiträge bitte hierhin: Discussion

---

Questions

• 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)

  @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)

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

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

• 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)

  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)

  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)

  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)

• 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)

  @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)

• 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)

  @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)

• 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)

  @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)

• 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)

  @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)

• 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)

  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)

  @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)

• 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)

  @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)

  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)

  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)

  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)

• 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)
• 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)

  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)

Discussion

• 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)
  • 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)
    • 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)
• 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)

  @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)

  @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)

• 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)
  • 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)

    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)

    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)

• 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)
  • 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)
• 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)

  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)

  @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)

  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)

• 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)
  • 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)

  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)

• 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)

  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)

  @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)

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

• 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)

  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)

• 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)
• 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)

  @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)

• 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)
• 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)

• 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

  @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)

  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.

  @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)

  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)

  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)

  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)

  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)

  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)

• 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)

• 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)

  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)

  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)

  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)

• 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)

• 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)

• 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)

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

  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)

  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)

  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)

  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)

  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)

  @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)

• 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)

• 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)

  @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)

  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)

  @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)

• 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)

  @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)

  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)

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

• 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)

  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)

  @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)

  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)

  @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)

  @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)

  @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)

  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)

• 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)

  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)

  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)

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)

• 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)

  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)

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)

Abstract articles and norms in individual projects

It seems abstract articles are meant to be fetched 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 external 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)

• 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)

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

@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)

If systematic local tweaks (rules) are wanted in more than a few projects, I think they need to be accommodated separately from the global functions, to avoid the tweaks accidentally affecting other projects. They could be hosted in the local project (in a local function namespace) or as localization functions in the Abstract Wikipedia project, invoked when a page is to be constructed for a project that wants tweaks. If it isn't clear where to place hooks in the affected functions, perhaps the localization function could be the one primarily called; it could do a few checks and just call the global function if no tweaking is needed, otherwise calling the individual global functions as it sees fit (e.g. constructing its own infobox but calling the global function for the article content). –LPfi (talk) 08:38, 11 June 2025 (UTC)

Further discussion

• 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)

  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)

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)

@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)

• 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)

  @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)

• 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)

  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)

  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)

  @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)

• 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 concept; 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)

 Support for Option 4, in particular storing Abstract Content at wikipedia.org. I concur with@TomT0m about using this domain, as it is a major entry point to the encyclopaedia (thus better coverage and visibility of Abstract Wikipedia), and virtually all Wikipedia content is stored on language edition subdomains (from what I understand). Additionally, this approach could be scaled to other projects (e.g. Wikivoyage at wikivoyage.org); the home domain would be separate enough from language editions, whilst sharing their focus. As for the Abstract Content, wouldn't it be feasible to link an Abstract article (e.g. stored at wikipedia.org/wiki/Q42) to Wikidata via interwiki links (i.e. an mul or abstract link at wikidata.org/wiki/Q42), thus enabling Wikipedias to access Abstract Content to render said Abstract article? Cheers! --Red Sneak (talk) 21:43, 12 June 2025 (UTC)

I thin I understand the scheme. If the article is the QID, an explicit mapping to Wikidata via sitelinks wouldn't be needed, since the QID is the QID anyway :) --DVrandecic (WMF) (talk) 11:43, 13 June 2025 (UTC)

• Option 4 for sure. Option 1, 2 and 3 do not allow future extension to abstract Wikiquote, abstract Wikivoyage, abstract Wikibooks, abstract Wikiversity, abstract Wikinews and so on. Option 5 is very English Wikipedia centric and do not allow future extension to a language without its own Wikiquote, Wikivoyage, Wikibooks, Wikiversity, Wikinews and so on. Midleading (talk) 12:24, 18 June 2025 (UTC)