Wikipédia abstraite/Idées

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

Commentaires structurés, attributs et décorateurs

Les commentaires structurés, attributs et décorateurs pourraient être utilisés pas Wikifonctions pour fournir des fonctionnalités telles que des métadonnées sur la fonctions, une assistance pour la recherche de fonctions, ou encore la génération automatique de documentation. Les commentaires structurés sont des commentaires du langage de programmation qui utilisent des motifs syntaxiques ou du XML afin que les contenus des commentaires puissent être traités de façon mécanique.

Des attributs peuvent être attachés aux fonctions et à leurs paramètres dans des langages de programmation tels que C# et Java.

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

Les décorateurs sont une fonctionnalité proposée pour le langage JavaScript.

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

Versionnement

L’utilisation de commentaires structurés, d’attributs ou décorateurs et de métadonnées liées au versionnement peut simplifier les scénarios de versionnement sur des ressources évolutives dont les sources sont développés en large collaboration.

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

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

Espaces de noms et modules

Les espaces de noms et les modules peuvent être utiles pour organiser de larges collections de fonctions. Avec des espaces de noms ou modules, de multiples paradigmes ou écosystèmes de fonctions peuvent en pratique coexister au sein d’une ressource collaborative.

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

Environnements d’exécution de scripts pour la génération de langue humaine

Avec des moteurs de script modernes tels que V8, il est relativement facile de créer et fournir des environnements d’exécution de scripts.

De manière semblable aux environnements de script et aux API pour les scénario web que fournissent les navigateurs Web, nous pouvons envisager de fournir des environnements de script et une API pour les scénarios de génération de langue naturelle.

Les sujets de discussion relatifs aux environnements de script pour moteurs des rendus incluent : des API et modèles d’objets pour accéder et travailler avec (1) des données de Wikidata entrantes, (2) le contexte de rendu, (3) des représentations intermédiaires de la connaissance, ou bien (4) pour générer en sortie du contenu en langue naturelle.

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

Provenance

Puisque Wikidata est une base de connaissance sourcée, les API et modèles d’objets devraient inclure des moyens pour annoter toute représentation intermédiaire ou portion de texte en langage naturel avec des sources. Dans les articles générés automatiquement, les sources des déclarations pourraient apparaître en tant que matériaux référencés dans les sections « Références » des articles, avec des citations numérotées visibles en ligne, près du contenu approprié.

Si Wikidata venait à inclure la prise en charge du raisonnement automatisé, toute forme de raisonnement, d’argumentation, de dérivations ou de preuves qui soutiennent des déclarations pourrait apparaître de façon similaire dans les sections « Références », avec des citations numérotées visibles en ligne, près du contenu approprié. Les lecteurs pourraient cliquer les hyperliens pour naviguer vers des documents générés automatiquement qui indiquent le raisonnement, l’argumentation, les dérivations ou les preuves qui soutiennent une ou plusieurs déclarations.

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

Flux sortants, journalisation et événements de diagnostic

Lors de la modification ou le développement de contenu dans Wikifonctions pour une utilisation sur la Wikipédia abstraite, il serait pratique de pouvoir émettre vers de multiples flux sortants, des journaux ou de produire des évènements typés. De telles fonctionnalités font partie de l’environnement d’exécution de scripts fournis pour les fonctions.

Il serait également utile de pouvoir agréger, organiser et visualiser les sorties de diagnostic avec une granularité et une verbosité configurables.

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

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

Expériences pour le rédacteur ou le développeur

Les rédacteurs ou développeurs pourraient disposer d’un moyen de basculer entre un « mode développeur » ou un « mode de débogage » sur la Wikipédia abstraite afin qu’ils puissent, lors de la visualisation des articles :

survoler des portions en langue naturelle pour visualiser dans des boîtes de survol des traces appropriées du calcul et des diagnostics associés,
voir des indicateurs visuels pour les traces de calcul et messages de diagnostics associés dans une marge afin qu’ils puissent interagir avec ces indicateurs visuels pour voir les données développées, ou
sinon sélectionner ou indiquer des portions du contenu en langue naturelle pour visualiser les traces appropriées de calcul et les messages de diagnostic associés.

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

Expériences pour le lecteur

Nous pouvons considérer l’ajout de mécanismes de retour pour les lecteurs de la Wikipédia abstraire leur permettant de commenter, apprécier, voter pour ou sinon fournir un avis relatif à des portions spécifiques du contenu en langue naturelle généré automatiquement.

Il devrait également être possible pour les lecteurs de « post-modifier » le contenu généré automatiquement. Pour les articles générés automatiquement, il pourrait y avoir des versions wiki des articles dans le but de sourcer collaborativement l’affinage des articles. Ces versions « post-modifiées » des articles générés automatiquement devraient être navigables par des éléments en onglet de l’interface utilisateur. Les données de cette variété de retours sourcés collaborativement concernant les articles générés automatiquement, les « post-modifications du wiki », pourraient être collectées et agrégées pour leur utilisation par les rédacteurs ou développeurs de Wikifonctions.

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

L’évaluation automatique des langues humaines

Des outils logiciels dans les catégories de l’évaluation automatique des essais, la vérification grammaticale, la mesure de lisibilité ou l’évaluation de langue naturelle pourraient être utiles pour mesurer automatiquement des articles de nombreuses façons. Coh-Metrix 3.0, par exemple, mesure la langue naturelle selon 108 indices.

Peut-être des robots pourraient mesurer des articles lorsque qu’ils sont mis à jour et rapporter leurs données aux rédacteurs ou développeurs en utilisant une API de la plateforme.

http://cohmetrix.com/

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

Génération d’articles en réponse aux questions des utilisateurs

De façon similaire aux systèmes de réponse aux questions, des articles pourraient être générés pour des requêtes sur Wikidata ou lorsque des utilisateurs naviguent vers des articles depuis des recherches sur le web. Au delà de la mise en avant des contenus appropriés, des articles pourraient être générés lors de l’utilisation de ces données contextuelles. — AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC) [reply]

Génération de questions liées pour usage dans des articles

De façon similaire aux systèmes de dialogues basés sur l’hypertexte, il serait possible de placer des questions à suivre qui pourraient intéresser un lecteur dans une section près de la fin des articles, chacune étant un hyperlien vers un autre article. Il serait possible de suivre les hyperliens vers des articles qui seraient générés dynamiquement, s’ils n’ont pas déjà été créés et mis en cache. — AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC) [reply]

Synthèse vocale et hypertexte

Il existe une recommandation candidate du W3C sur le Module de parole en CSS.

En accord avec la prononciation, il est possible d’utiliser des lexiques de prononciation avec les documents hypertextes. Également, de façon similaire à ce que permet EPUB3, il est possible d’utiliser des attributs basés sur SSML dans les sorties hypertextes générées pour fournir des données de prononciation.

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

Utiliser les API de style GPT-3

Utiliser des API de style GPT-3 pour traduire automatiquement la langue normale en syntaxe pour la Wikipédia abstraite. — ChristianKl (Discussion) 16:15, 16 January 2021 (UTC) [reply]

Contrats fonctionnels

Wikifonctions devrait prendre en charge les contrats fonctionnels, tels qu’ils sont déjà fournis par différents langages de programmation (comme Eiffel, Spark-Ada ou JML ; ou même Python avec différents paquets logiciels), c’est-à-dire :

Des préconditions : une nouvelle section après les arguments de la fonction donne une liste de prédicats booléens indiquant les conditions requises par les arguments avant d’appeler cette fonction (par ex. la liste ne peut pas être vide ou le premier paramètre doit être supérieur au second).
Des postconditions : une nouvelle section après les arguments de la fonction donne une liste de prédicats booléens qui indiquent les conditions qui sont garanties par le résultat de la fonction (par ex. le résultat est entre zéro et le premier paramètre ou la longueur de la liste en sortie est celle de la liste en entrée plus un).
Des invariants de type : une nouvelle section après les arguments de la fonction donne une liste de prédicats booléens qui indiquent les conditions satisfaites par chaque valeur de ce type de données (par ex. la valeur doit être strictement positive ou doit être un nombre premier).

L’approche la plus simple est probablement que chaque prédicat soit juste une fonction dans le même espace de noms que le reste des fonctions. Habituellement dans les langages de programmation, des opérations supplémentaires sont permises dans les prédicats contractuels (tels que des quantificateurs « pour tout » ou « il existe au moins un »), mais ceci peut être facultatif. Dans les préconditions, il serait juste nécessaire de référencer les arguments de la fonction et dans les postconditions une façon de référencer le résultat de la fonction serait nécessaire. Comme je comprends que les arguments ne peuvent pas être modifiés, il n’est pas nécessaire de référencer dans les post-conditions la valeur originale d’un paramètre au début de la fonction. Tous les prédicats de la liste doivent être vrais (c’est-à-dire un « et logique » de tous les prédicats) et les préconditions doivent être aussi détaillées que nécessaires, probablement utiles également aux moteurs de rendu, par exemple un argument doit être un élément Wikidata pour un humain et également déjà mort.

Au delà du but de documenter la fonction pour les metteurs en œuvre et les utilisateurs (par exemple, si une précondition échoue, l’utilisateur obtiendra un message d’erreur clair et unifié, sans avoir besoin de gérer les différentes erreurs au sein de chaque mise en œuvre de fonction), les postconditions sont également très utiles pour vérifier automatiquement les résultats durant les tests et il serait bien que la plateforme génère un rapport avec les violations de contrainte pour chaque mise en œuvre au cas où un résultat de satisfait pas aux postconditions avec un jeu de paramètres d’entrée (afin que la mise en œuvre ou la postcondition puisse être corrigée). Les invariants de type seraient des préconditions implicites pour chaque fonction ayant des arguments de ce type et des postconditions implicites pour chaque fonction ayant un résultat de ce type de données.

D’autres avantages habituellement obtenus sont le potentiel à simplifier les mises en œuvre car certain code défensif peut être réduit grace aux préconditions, ce qui évite d’avoir à gérer des situations exceptionnelles d’une façon compatible avec tous les langages pis en charge. Peut-être des « tests de robustesse » devraient également être fournis, c’est-à-dire des tests spéciaux pour une fonction qui vérifient que certains paramètres ne sont pas autorisés par les préconditions de la fonction.

J’espère que ceci peut aider durant le processus de conception et je vous remercie beaucoup à nouveau pour ce formidable projet. — surueña (Discussion) 06:59, 3 April 2021 (UTC)[reply]

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

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

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