Abstrakte Wikipedia/Ideen

This page is a translated version of the page Abstract Wikipedia/Ideas and the translation is 100% 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.

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/attributes/

Dekorierer sind ein vorgeschlagenes Feature der JavaScript-Sprache.

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

Versionierung

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

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/attributes/general#obsolete-attribute

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

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

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

Herkunft

Da Wikidata eine quellenbezogene Wissensdatenbank 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 automatisierte Beweisführung 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) [reply]

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.

https://developer.mozilla.org/en-US/docs/Web/API/Console

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

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:

mit dem Mauszeiger über Teile der natürlichen Sprache fahren, um relevante Rechenwege und Diagnosemeldungen in Schwebekästen (engl. hoverboxes) zu sehen,
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
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) [reply]

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

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.

http://cohmetrix.com/

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

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

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

Sprachsynthese und Hypertext

Es existiert eine W3C-Kandidatenempfehlung für CSS-Sprachmodule.

In Bezug auf die Aussprache kann man Aussprachelexika 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) [reply]

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

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:

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

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

Beta-Tests mit nützlichem Material und einem gesponserten Team von Übersetzern

Bedienungsanleitungen sind Wissen darüber, wie man etwas richtig benutzt. Da die Hersteller von einer mehrsprachigen Übersetzung ihres Servicehandbuchs profitieren und Massenhersteller wie Sony, Stihl, Bayers und Suzuki über riesige Ressourcen verfügen, können sie es sich leisten, ein Team von Übersetzern zu sponsern, das von Wiki gestellt, aber von ihnen bezahlt wird. Die Übersetzer/innen überprüfen, ob Abstract den Inhalt richtig von einer Sprache in die andere übertragen hat. Und die Hosting-Gebühren für die übersetzten Handbücher können vollständig von den Massenherstellern übernommen werden, die sich bereit erklären würden, das Team hier zu unterstützen.

Eine mehrsprachige Bibliothek mit Bedienungsanleitungen, die erklären, wie man eine Kettensäge benutzt oder ein Bokeh hinbekommt, ist toll, aber das ist nicht das Ziel, wie ich es sehe. Es ist nur ein angenehmer Nebeneffekt.

Das Hauptziel ist der Betatest der Maschine. Die Übersetzerinnen und Übersetzer werden die Fehler nicht beheben, sondern sie werden uns darauf hinweisen, damit wir verstehen, warum die Maschine versagt hat. Und wenn die Maschine perfekt ist, hat das Übersetzungsteam ihre Zuverlässigkeit bewiesen.

Das Übersetzerteam kann auf verschiedene Arten rekrutiert werden. Fünfer Lehrer/innen an Schulen Katholische Kirche

Ich denke, die Idee der katholischen Kirche mag überraschen und deplatziert erscheinen oder ein frommer Zug sein, deshalb hier der Gedanke dahinter.

Zunächst einmal sollten wir Klarheit schaffen: Auch wenn es sadistische Lehrer, mörderische Polizisten und viele schlechte Menschen in (vielleicht) jeder Organisation gibt, können wir sie nicht alle als schlechte Menschen verurteilen. Und ich spreche nicht von Vergebung, ganz und gar nicht. Ich spreche davon, mit dem besseren Teil, den guten Menschen dort, zusammenzuarbeiten. Bei ihnen geht es um Liebe und Teilen, und man muss nicht an einen Glauben oder ein Wunder glauben. Wiki ist säkular und nicht auf paranormale Aktivitäten oder die Verbreitung von Botschaften ausgerichtet. Aber (noch einmal, ein doppelter Gewinn): Die katholische Kirche ist überall auf der Welt, in jeder Sprache und voller Gelehrter in verschiedenen Sprachen. Ja, sie wollen über Liebe reden (und leider manchmal darüber, warum ihre Liebe besser ist), aber sie wollen die Bibel in jede Sprache der Welt übersetzen. Das ist eine Kernüberzeugung, denn Jesus sagte (so sagen sie): Verbreitet das Wort. Ich bin nicht auf dem Laufenden, was die finanziellen Mittel von Papst Franziskus und seinen Freunden angeht, aber ich weiß, dass sie ein Netzwerk von Gelehrten haben, die die lokalen Sprachen sprechen oder wissen, wer wirklich zuverlässig ist, um diese Arbeit zu erledigen. Sie hatten schlechte Presse und suchen nun nach einer Antwort darauf, welchen Platz die Kirche einnehmen kann, wie sie den Menschen helfen kann, indem sie unsere Worte und ihr Wort verbreitet. Und egal, was man glaubt, die Bibel ist ein Buch, das die Menschheit in den letzten zwei Jahrtausenden geprägt hat. Sie in jede kreolische Sprache zu übersetzen wäre ein Zeichen des Friedens und des Respekts, mehr nicht. Und was ist mit den anderen großen Religionen? Holt sie rein! Wir können gleichzeitig Einladungen verschicken, da der Geltungsbereich klar definiert ist (so bleibt Wiki säkular und alle fühlen sich wohl). Jede Kirche gründet sich auf das Lesen und Interpretieren von Literatur, das ist wirklich ein Ort des Wissens und der Philologie. Und ihre Hierarchie kann die Glaubwürdigkeit der Übersetzer bestätigen. Wir wollen niemanden wie den gefälschten Gebärdensprachdolmetscher, der Barack Obamas Rede bei der Gedenkfeier für Nelson Mandela gedolmetscht hat. —Der vorangehende unsignierte Kommentar wurde von François Jourdain (talk) 04:35, 23 February 2022 (UTC) hinzugefügt.[reply]

Möglicherweise eine interessante Idee. Gesponserte Beiträge müssen immer gründlich und gemeinsam mit der Community überlegt werden, aber es könnte eine Möglichkeit sein, falls das organische Wachstum zu sehr stagniert. Schauen wir mal! Darüber sollten wir in einem Jahr oder so nachdenken. --DVrandecic (WMF) (talk) 00:11, 5 March 2022 (UTC)[reply]