Abstrakte Wikipedia / Ideen

This page is a translated version of the page Abstract Wikipedia/Ideas and the translation is 88% complete.

Strukturierte Kommentare, Attribute und Dekorierer

Strukturierte Kommentare, Attribute und Dekorierer könnten von Wikifunctions genutzt werden, um Funktionen wie: Funktions-Metadaten, die Erleichterung der Suche nach Funktionen und die automatische Generierung von Dokumentation zu ermöglichen. Strukturierte Kommentare sind Kommentare in Programmiersprachen, die syntaktische Muster oder XML verwenden, damit der Inhalt der Kommentare maschinell verarbeitet werden kann.

Attribute können in Programmiersprachen wie C# und Java an Funktionen und deren Parameter angehängt werden.

Dekorierer sind ein vorgeschlagenes Feature der JavaScript-Sprache.

— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)

Versionierung

Durch die Verwendung von strukturierten Kommentaren, Attributen oder Dekorierern können versionierungsbezogene Metadaten Versionierungsszenarien bei sich entwickelnden Crowdsourced-Ressourcen vereinfachen.

— AdamSobieski (talk) 22:15, 15 July 2020 (UTC)

Namensräume und Module

Namensräume und Module können beim Organisieren großer Funktionssammlungen nützlich sein. Mit Namensräumen oder Modulen können mehrere Paradigmen oder Ökosysteme von Funktionen leichter in einer Crowdsourcing-Ressource koexistieren.

— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)

Skripting-Umgebungen für die Erzeugung natürlicher Sprache

Mit modernen Scripting-Engines wie V8 ist es relativ einfach, Scripting-Umgebungen zu erstellen und bereitzustellen.

Ähnlich wie Webbrowser Skripting-Umgebungen und APIs für Web-Szenarien bereitstellen, können wir uns vorstellen, Skripting-Umgebungen und APIs für Szenarien zur Erzeugung natürlicher Sprache bereitzustellen.

Zu den Diskussionsthemen, die sich auf Skripting-Umgebungen für Renderer beziehen, gehören: (1) API- und Objektmodelle für den Zugriff auf und die Arbeit mit Input-Wikidata-Daten, (2) API- und Objektmodelle für den Zugriff auf und die Arbeit mit dem Rendering-Kontext, (3) API- und Objektmodelle für den Zugriff auf und die Arbeit mit intermediären Wissensrepräsentationen, (4) API- und Objektmodelle für die Generierung von natürlichsprachigem Output-Inhalt.

— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)

Herkunft

Da Wikidata eine sourced knowledgebase ist, sollten API- und Objektmodelle Mittel zur Annotation aller Zwischendarstellungen und Teile der natürlichen Sprache mit Quellen enthalten. In automatisch generierten Artikeln könnten die Quellen von Aussagen als referenzierte Materialien in den "Referenzen"-Abschnitten der Artikel erscheinen, wobei nummerierte Zitate inline, in der Nähe des relevanten Inhalts, erscheinen.

Sollte Wikidata Unterstützung für automated reasoning bieten, könnten alle Argumentationen, Begründungen, Ableitungen und/oder Beweise, die Aussagen unterstützen, in ähnlicher Weise in den "Referenzen"-Abschnitten der Artikel erscheinen, wobei nummerierte Zitate inline in der Nähe des relevanten Inhalts erscheinen. Leser könnten auf Hyperlinks klicken, um zu automatisch generierten Dokumenten zu navigieren, die unterstützende Begründungen, Argumentationen, Ableitungen und/oder Beweise für eine oder mehrere Aussagen enthalten.

— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)

Ausgabeströme, Protokollierung und Diagnoseereignisse

Bei der Bearbeitung/Entwicklung von Wikifunctions-Inhalten zur Verwendung in der abstrakten Wikipedia wäre es praktisch, wenn man in der Lage wäre, in mehrere Streams auszugeben, zu protokollieren und/oder typisierte Ereignisse auszulösen. Solche Funktionen sind Teil der Skripting-Umgebung, die den Funktionen zur Verfügung gestellt wird.

Es wäre auch nützlich, die Diagnoseausgaben mit einer konfigurierbaren Granularität oder Detailtiefe aggregieren, organisieren und anzeigen zu können.

— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)

Erfahrungen von Redakteuren und Entwicklern

Redakteure/Entwickler könnten eine Möglichkeit haben, einen "Entwicklermodus" oder "Debugging-Modus" in der Abstrakten Wikipedia einzuschalten, so dass sie beim Betrachten von Artikeln entweder:

  1. mit dem Mauszeiger über Teile der natürlichen Sprache fahren, um relevante Rechenwege und Diagnosemeldungen in Schwebekästen (engl. hoverboxes) zu sehen,
  2. visuelle Indikatoren für Rechenwege und Diagnosemeldungen in einem Randbereich sehen, so dass sie dann mit den visuellen Indikatoren interagieren können, um erweiterte Daten zu sehen, oder
  3. auf andere Weise Teile des natürlichsprachigen Inhalts auswählen oder anzeigen, um relevante Rechenwege und Diagnosemeldungen zu sehen.

— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)

Erfahrungen von Lesern

Wir können in Erwägung ziehen, Feedback-Mechanismen für Leser der Abstrakten Wikipedia hinzuzufügen, wie z. B. das Kommentieren, Liken, Upvoten oder anderweitiges Geben von Feedback in Bezug auf bestimmte Teile des automatisch generierten natürlichsprachigen Inhalts.

Möglich ist auch, dass Leser automatisch generierte Inhalte "nachbearbeiten" können. Für automatisch generierte Artikel könnte es Wiki-Versionen der Artikel geben, um die Feinabstimmung der Artikel durch Crowdsourcing zu ermöglichen. Diese "Wiki-Post-Edit"-Versionen von automatisch generierten Artikeln könnten über Registerkarten-Benutzerschnittstellen-Elemente angesteuert werden. Daten aus dieser Vielfalt von Crowdsourcing-Feedback zu automatisch generierten Artikeln, "Wiki-Post-Editing", könnten gesammelt und für die Verwendung durch Wikifunctions-Redakteure/Entwickler aggregiert werden.

— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)

Die automatische Auswertung von natürlicher Sprache

Software-Tools aus den Kategorien automatische Textbewertung, Grammatikprüfung, Lesbarkeitsmessung und/oder Bewertung natürlicher Sprache könnten für die automatische Vermessung von Artikeln auf verschiedene Weise von Nutzen sein. Coh-Metrix 3.0 z. B. misst natürliche Sprache auf 108 Indizes.

Vielleicht könnten Bots Artikel messen, wie sie aktualisiert werden, und ihre Daten über eine Plattform-API an Redakteure/Entwickler melden.

— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)

Erzeugen von Artikeln als Antwort auf Benutzerfragen

Ähnlich wie bei Frage-Antwort-Systemen könnten Artikel für Wikidata-Abfragen generiert oder Nachnutzer aus Websuchen zu Artikeln geführt werden. Neben der Hervorhebung relevanter Inhalte könnten Artikel unter Verwendung dieser Kontextdaten generiert werden. — AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)

Generieren von Folgefragen zur Verwendung in Artikeln

Ähnlich wie bei hypertextbasierten Dialogsystemen könnte man Folgefragen, die einen Leser interessieren könnten, in einem Abschnitt am unteren Ende von Artikeln platzieren, wobei jede Frage ein Hyperlink zu einem anderen Artikel wäre. Man könnte Hyperlinks zu Artikeln setzen, die dynamisch generiert werden könnten, wenn sie nicht bereits erstellt und zwischengespeichert sind. — AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)

Sprachsynthese und Hypertext

Es existiert eine CSS Speech Module W3C Candidate Recommendation.

In Bezug auf die Aussprache kann man pronunciation lexicons mit Hypertext-Dokumenten verwenden. Ähnlich wie bei EPUB3 kann man auch SSML-basierte Attribute auf generierten Hypertextausgaben verwenden, um Aussprachedaten bereitzustellen.

— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)

Nutzung von APIs im GPT-3-Stil

Verwende APIs im Stil von GPT-3, um normale Sprache automatisch in die Syntax der Abstrakten Wikipedia zu übersetzen. — ChristianKl (Discussion) 16:15, 16 January 2021 (UTC)

Funktionsverträge

Wikifunctions sollte "Funktionsverträge" unterstützen, wie sie bereits von verschiedenen Programmiersprachen (wie Eiffel, Spark-Ada oder JML; oder sogar Python mit verschiedenen Paketen) angeboten werden:

  1. Preconditions: Ein neuer Abschnitt nach den Funktionsargumenten mit einer Liste boolescher Prädikate, die die Bedingungen angeben, die die Argumente erfüllen müssen, bevor die Funktion aufgerufen werden kann (z. B. darf die Liste nicht leer sein, oder der erste Parameter muss größer als der zweite sein)
  2. Postconditions: Ein neuer Abschnitt nach den Funktionsargumenten mit einer Liste von booleschen Prädikaten, die die Bedingungen angeben, die durch das Ergebnis der Funktion garantiert werden (z. B. Ergebnis liegt zwischen Null und dem ersten Parameter, oder die Länge der Ausgabeliste ist die Länge der Eingabeliste plus eins)
  3. Typinvarianten: Ein neuer Abschnitt in der Datentypseite mit einer Liste boolescher Prädikate, die die Bedingungen angeben, die jeder Wert dieses Datentyps erfüllt (z. B. muss der Wert strikt größer als Null sein oder er ist eine Primzahl)

Der einfachste Ansatz ist wahrscheinlich, dass jedes Prädikat einfach eine Funktion im gleichen Namensraum wie die übrigen Funktionen ist. In Programmiersprachen sind normalerweise zusätzliche Operationen in Vertragsprädikaten erlaubt (wie die Quantoren "für alle" oder "es gibt mindestens einen"), aber dies kann optional sein. In pre-conditions wäre es erforderlich, nur auf die Funktionsargumente zu verweisen, und in Nachbedingungen wird eine Möglichkeit benötigt, auf das Funktionsergebnis zu verweisen. Nachdem Argumente nicht geändert werden können, besteht keine Notwendigkeit, in post-conditions auf den ursprünglichen Wert eines Parameters beim Funktionsstart zu verweisen. Alle Prädikate der Liste müssen wahr sein, und die Vorbedingungen können so detailliert wie nötig sein, was wahrscheinlich auch für Renderer nützlich ist, z.B. ein Argument muss ein Wikidata-Element eines lebenden oder gestorbenen Menschen sein.

Neben der formalen Dokumentation der Funktion für Implementierer und Benutzer (z.B. wenn eine Precondition fehlschlägt, erhält der Benutzer eine einheitliche und klare Fehlermeldung, ohne die Notwendigkeit, die verschiedenen Fehler innerhalb jeder Funktionsimplementierung zu behandeln), sind Postconditions sehr nützlich für die automatische Überprüfung der Ergebnisse während der Tests, und es wäre schön, wenn die Plattform eine Liste mit Bedingungsverletzungen für jede Implementierung erzeugt, falls ein Ergebnis die Postcondition mit einer Reihe von Eingabeparametern nicht erfüllt (so dass die Implementierung oder die Postcondition korrigiert werden kann). Typinvarianten wären implizite Funktionspreconditions für jede Funktion mit Argumenten dieses Typs und implizite Postconditions für jede Funktion mit einem Ergebnis dieses Datentyps.

Weitere Vorteile, die in der Regel erzielt werden, sind das Potenzial zur Vereinfachung von Implementierungen, da ein Teil des Fehlerbehandlungscodes dank der Vorbedingungen reduziert werden kann, und die Vermeidung der Notwendigkeit, Ausnahmesituationen in einer zwischen allen unterstützten Sprachen kompatiblen Weise zu behandeln. Vielleicht sollten auch "Robustheitstests" vorgesehen werden, d.h. einige spezielle Tests für eine Funktion, die prüfen, ob einige Parameter unter den aktuellen Vorbedingungen der Funktion nicht zulässig sind.

Ich hoffe, das hilft bei der Gestaltung, und ich danke euch nochmals für dieses großartige Projekt. — surueña (Discussion) 06:59, 3 April 2021 (UTC)

Siehe hier. — DVrandecic (WMF) (Discussion) 22:59, 19 April 2021 (UTC)

Beta testing with useful material and a sponsored team of translators

Service manuals are knowledge about how to properly use something. Because manufacturers will benefit from a multilingual translation of their service manual and because mass producers, like Sony, Stihl, Bayers, Suzuki, have gigantic ressources, they can afford sponsoring a team of translators provided by Wiki but paid by them. Translators will double check if Abstract properly brought the content from one language to another. And hosting fees for the translated manuals can be fully covered by the mass producers who would agree to thrust the team here.

Having a multilingual service manual library about how to use a chainsaw, or achieve a bokeh, that’s great, but this is not the goal as I see it. It’s just a happy collateral benefit.

The main goal is to beta test the machine. Translators will not fix the errors; they will point it out for us so we may understand why the machine failed. And if the machine is perfect, the translated team will have proved its reliability.

About the translating team, it can be recruited in different ways. Fiver Schools teachers Catholic Church

I think the idea of the Catholic Church may be surprising and seem out of place, or a devout move, so here is the thinking behind it.

First, let’s clear the clouds: even tough there’s sadistic teachers, murderous police officers, and a lot of bad people in (maybe) every organisations, we cannot condemn them all as bad people. And I’m not talking about forgiveness, not at all. I’m talking about collaborating with the better part, the good people there. Their pitch is about love and sharing, and there’s no need to believe in any faith or miracle. Wiki is secular, not invested in paranormal activities or message spreading. But (again, a double-win): Catholic church is everywhere on the planet, in every language, and full of scholars in languages. Yes, they want to talk about love (and unfortunately sometimes about why their love is better) but they do want to translate the bible in every language on earth. It’s a core belief, since Jesus said (so they say): Spread the word. I’m not up to date about the financial resources of Pope Francis and friends, but I know they have a network of scholars speaking local languages or knowing who is really reliable to do the job. They had bad press and are now looking for an answer about which place can the Church have, how they can help people by spreading our words and their Word. And whatever the belief, the Bible is a book who shaped mankind for the last 2 milleniums. Translating it in every creole language would be showing peace and respect, that’s it. And what about the other big religions? Hop them in! We can send invites simultaneously, as the scope is clearly defined (so Wiki stays secular and everyone is at ease). Every church is founded on the reading and interpretation of literature, this is really a place of knowledge and philology. And their hierarchy can confirm the credibility of the translators. We don’t want someone like the fake sign language interpreter who was interpreting Barack Obama’s speech at the memorial service for Nelson Mandela.

The preceding unsigned comment was added by François Jourdain (talk) 04:35, 23 February 2022‎ (UTC)

Possibly an interesting idea. Sponsored contributions have always to be considered thoroughly and together with the community, but it could be a possibility in case organic growth is too stagnant. Let's see! That's something we should think about in a year or so. --DVrandecic (WMF) (talk) 00:11, 5 March 2022 (UTC)