Abstraktní Wikipedie/Nápady
Abstraktní Wikipedie |
---|
(Diskuse) |
Obecné informace |
Vývojový plán |
|
Poznámky, koncepty, diskuse |
|
Příklady a makety |
Datové nástroje |
Historický |
Strukturované komentáře, atributy a dekorátory
Strukturované komentáře, atributy a dekorátory by Wikifunkce mohly využívat k poskytování funkcí, jako jsou metadata funkcí, usnadnění vyhledávání funkcí a automatické generování dokumentace. Strukturované komentáře jsou komentáře programovacího jazyka, které využívají syntaktické vzory nebo XML, takže obsah komentářů lze mechanicky zpracovat.
- https://docs.microsoft.com/en-us/dotnet/csharp/codedoc
- https://docs.microsoft.com/en-us/visualstudio/ide/xml-documentation-comments-javascript?view=vs-2015
Atributy lze připojit k funkcím a jejich parametrům v programovacích jazycích, jako jsou C# a Java.
Dekorátory jsou navrhovanou funkcí jazyka JavaScript.
- https://github.com/tc39/proposal-decorators
- https://github.com/tc39/proposal-decorators#metadata
- https://tc39.es/proposal-decorators/
— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)
Verzování
Pomocí strukturovaných komentářů, atributů nebo dekorátorů mohou metadata související s verzemi zjednodušit scénáře verzování vyvíjejících se crowdsourcovaných zdrojů.
— AdamSobieski (talk) 22:15, 15 July 2020 (UTC)
Jmenné prostory a moduly
Jmenné prostory a moduly mohou být užitečné při organizaci velkých kolekcí funkcí. Díky jmenným prostorům nebo modulům může v crowdsourcovaném zdroji snáze koexistovat více paradigmat nebo ekosystémů funkcí.
- https://v8.dev/features/modules
- https://www.typescriptlang.org/docs/handbook/namespaces-and-modules.html
— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)
Skriptovací prostředí pro generování přirozeného jazyka
S moderními skriptovacími enginy, jako je V8, je poměrně snadné vytvářet a poskytovat skriptovací prostředí.
Podobně jako webové prohlížeče poskytují skriptovací prostředí a API pro webové scénáře, můžeme si představit poskytování skriptovacích prostředí a API pro scénáře generování přirozeného jazyka.
Témata diskuse týkající se skriptovacích prostředí pro vykreslovače zahrnují: (1) API a objektové modely pro přístup a práci se vstupními daty Wikidat, (2) API a objektové modely pro přístup a práci s kontextem vykreslování, (3) API a objektové modely pro přístup a práci s meziprodukty znalostí, (4) API a objektové modely pro generování výstupního obsahu v přirozeném jazyce.
- https://v8.dev/
- https://developer.mozilla.org/en-US/docs/Web/API
- https://developer.mozilla.org/en-US/docs/Web/API/Window
- https://developer.mozilla.org/en-US/docs/Web/API/Document
- https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model
— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)
Provenience
Vzhledem k tomu, že Wikidata jsou zdrojovaná báze znalostí, měly by modely API a objektů zahrnovat prostředky pro anotaci všech zprostředkujících reprezentací a částí přirozeného jazyka se zdroji. V automaticky generovaných článcích by se zdroje výroků mohly objevovat jako odkazované materiály v sekcích článků "Odkazy" s číslovanými citacemi na řádku v blízkosti příslušného obsahu.
Pokud Wikidata začnou podporovat automatizované referencování, mohly by se veškeré reference, argumentace, odvození a/nebo důkazy podporující tvrzení podobně objevit v sekcích článků "Odkazy" s číslovanými citacemi na řádku, v blízkosti příslušného obsahu. Čtenáři by mohli kliknutím na hypertextové odkazy přejít na automaticky generované dokumenty, které uvádějí podpůrná zdůvodnění, argumentaci, odvození a/nebo důkazy pro jedno nebo více tvrzení.
- https://www.wikidata.org/wiki/Help:Sources
- https://www.wikidata.org/wiki/Wikidata:WikiProject_Reasoning
- https://en.wikipedia.org/wiki/Wikipedia:Citing_sources
— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)
Výstupní data, protokolování a diagnostické události
Při editaci/vývoji obsahu Wikifunkcí pro použití v Abstraktní Wikipedii by bylo vhodné mít možnost výstupu do více směrů, logování a/nebo vyvolávání zadaných událostí. Tyto funkce jsou součástí skriptovacího prostředí poskytovaného funkcím.
Bylo by také užitečné mít možnost agregovat, organizovat a zobrazovat diagnostické výstupy s konfigurovatelnou granularitou nebo ukecaností.
— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)
Zkušenosti editora/vývojáře
Editoři/vývojáři by mohli mít možnost přepínat "vývojářský režim" nebo "režim ladění" na Abstraktní Wikipedii, aby mohli při prohlížení článků:
- najetím myší na část generovaného přirozeného jazyka zobrazit příslušné stopy výpočtů a diagnostické zprávy v rámečcích pro najetí myší,
- zobrazit vizuální indikátory pro trasování výpočtů a diagnostická hlášení na okraji, aby pak mohli interagovat s vizuálními indikátory a zobrazit rozšířené údaje, nebo
- jinak vybrat nebo označit části obsahu přirozeného jazyka a zobrazit příslušné trasy výpočtů a diagnostických zpráv.
— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)
Zkušenosti čtenářů
Můžeme zvážit přidání mechanismů zpětné vazby pro čtenáře Abstraktní Wikipedie, jako je komentování, lajkování, plusování nebo jiné poskytování zpětné vazby s ohledem na konkrétní části automaticky generovaného obsahu v přirozeném jazyce.
Je také možné, že by čtenáři mohli "post-editovat" automaticky generovaný obsah. Pro automaticky generované články by mohly existovat wiki verze článků pro účely crowdsourcingového dolaďování článků. Na tyto "dodatečně upravené" verze automaticky generovaných článků by se dalo přejít pomocí prvků uživatelského rozhraní na kartě. Data z této rozmanité hromadné zpětné vazby k automaticky generovaným článkům, "wiki post-editace", by mohla být shromažďována a agregována pro použití editory/vývojáři Wikifunkcí.
- https://en.wikipedia.org/wiki/Postediting
- https://www.aclweb.org/anthology/W05-1615.pdf
- https://ehudreiter.com/2020/06/08/human-editing-of-nlg-texts/
— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)
Automatické vyhodnocení přirozeného jazyka
Softwarové nástroje v kategoriích automatického hodnocení esejů, kontroly gramatiky, měření čitelnosti a/nebo hodnocení přirozeného jazyka by mohly být užitečné pro automatické měření článků mnoha způsoby. Například Coh-Metrix 3.0 měří přirozený jazyk na 108 indikátorech.
Možná by roboti mohli měřit články při jejich aktualizaci a hlásit svá data redaktorům/vývojářům pomocí rozhraní API platformy.
— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)
Generování článků v reakci na dotazy uživatelů
Podobně jako systémy pro zodpovídání otázek by se články mohly generovat na základě dotazů na Wikidata nebo poté, co uživatelé přejdou na články z webového vyhledávání. Kromě zvýraznění relevantního obsahu lze s využitím těchto kontextových dat generovat články. — AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)
Generování následných otázek pro použití v článcích
Podobně jako u hypertextových dialogových systémů by bylo možné umístit doplňující otázky, které by čtenáře mohly zajímat, do sekce v dolní části článků, přičemž každá z nich by byla hypertextovým odkazem na jiný článek. Bylo by možné vytvořit hypertextové odkazy na články, které by mohly být dynamicky generovány, pokud již nejsou vytvořeny a uloženy v cache. — AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)
Syntéza řeči a hypertext
Existuje CSS Speech Module doporučení W3C.
Pokud jde o výslovnost, lze využít výslovnostní lexikony s hypertextovými dokumenty. Podobně jako v případě EPUB3 lze také u generovaných hypertextových výstupů využít atributy založené na SSML, které poskytují údaje o výslovnosti.
- https://www.w3.org/TR/css-speech-1/
- https://www.w3.org/TR/pronunciation-lexicon/
- https://www.w3.org/publishing/epub3/epub-contentdocs.html#sec-xhtml-ssml-attrib
- https://www.w3.org/TR/speech-synthesis11/
— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC)
Použití rozhraní API ve stylu GPT-3
Použijme rozhraní API ve stylu GPT-3 k automatickému překladu běžného jazyka do syntaxe Abstraktní Wikipedie. — ChristianKl (Discussion) 16:15, 16 January 2021 (UTC)
Funkční kontrakty
Wikifunkce by měly podporovat funkční kontrakty, jak je již poskytují různé programovací jazyky (například Eiffel, Spark-Ada nebo JML; nebo dokonce Python s různými balíčky):
- Předpoklady: Nová sekce za argumenty funkce se seznamem logických predikátů, které udávají podmínky požadované argumenty před voláním této funkce (např. seznam nesmí být prázdný nebo první parametr musí být větší než druhý)
- Postpodmínky: Nová sekce za argumenty funkce se seznamem logických predikátů označujících podmínky, které zaručuje výsledek funkce (např. výsledek je mezi nulou a prvním parametrem nebo délka výstupního seznamu je rovna délce vstupního seznamu plus jedna)
- Invarianty typu: Nová sekce na stránce datového typu se seznamem logických predikátů uvádějících podmínky, které splňuje každá hodnota tohoto datového typu (např. hodnota musí být striktně větší než nula nebo je prvočíslo)
Pravděpodobně nejjednodušší přístup je, že každý predikát je pouze funkce ve stejném jmenném prostoru jako ostatní funkce. V programovacích jazycích jsou obvykle ve smluvních predikátech povoleny další operace (jako kvantifikátory "pro všechny" nebo "existuje alespoň jeden"), což však může být nepovinné. V předběžných podmínkách by bylo nutné pouze odkazovat na argumenty funkce a v následných podmínkách bude nutné odkazovat na výsledek funkce. Pokud vím, argumenty nelze měnit, není třeba v postpodmínkách odkazovat na původní hodnotu parametru při spuštění funkce. Všechny predikáty seznamu musí být pravdivé (tj. logicky a všech predikátů), a předpoklady mohou být tak podrobné, jak je potřeba, pravděpodobně jsou užitečné i pro renderery, např. argument musí být položka Wikidat člověka, který je již mrtvý.
Kromě formálního zdokumentování funkce pro implementátory a uživatele (např. pokud selže předběžná podmínka, uživatel dostane jednotné a jasné chybové hlášení, aniž by musel řešit různé chyby uvnitř každé implementace funkce), jsou postpodmínky velmi užitečné pro automatickou kontrolu výsledků během testů a bylo by hezké, kdyby platforma generovala zprávu s porušením omezení pro každou implementaci v případě, že výsledek nesplňuje postpodmínku se sadou vstupních parametrů (aby bylo možné opravit implementaci nebo postpodmínku). Typovými invarianty by byly implicitní předběžné podmínky každé funkce s argumenty daného typu a implicitní následné podmínky každé funkce s výsledkem daného datového typu.
Dalšími obvykle získanými výhodami je možnost zjednodušení implementace, protože díky předběžným podmínkám lze omezit část kódu, a zamezení nutnosti řešit výjimečné situace kompatibilním způsobem mezi všemi podporovanými jazyky. Možná by měly být k dispozici také "testy robustnosti", tj. nějaké speciální testy pro funkci, které by kontrolovaly, zda některé parametry nejsou povoleny aktuálními předběžnými podmínkami funkce.
Doufám, že vám to pomůže v procesu navrhování, a ještě jednou vám moc děkuji za tento úžasný projekt. — surueña (Discussion) 06:59, 3 April 2021 (UTC)
Beta testování s užitečnými materiály a sponzorovaným týmem překladatelů
Servisní příručky představují znalosti o tom, jak něco správně používat. Protože výrobci budou mít prospěch z vícejazyčného překladu své servisní příručky a protože masoví výrobci, jako je Sony, Stihl, Bayers, Suzuki, mají obrovské zdroje, mohou si dovolit sponzorovat tým překladatelů, které poskytuje Wiki, ale které platí. Překladatelé dvakrát zkontrolují, zda Abstraktní Wikipedie správně přenesla obsah z jednoho jazyka do druhého. A poplatky za hostování přeložených manuálů mohou plně pokrýt masoví výrobci, kteří by souhlasili s tím, že sem tým přistrčí.
Mít vícejazyčnou knihovnu servisních příruček o tom, jak používat motorovou pilu nebo jak dosáhnout bokehu, je skvělé, ale to není cíl, jak ho vidím já. Je to jen šťastný vedlejší přínos.
Hlavním cílem je beta testování stroje. Překladatelé chyby neopravují, ale upozorňují nás na ně, abychom pochopili, proč stroj selhal. A pokud bude stroj dokonalý, překladatelský tým prokáže jeho spolehlivost.
Co se týče překladatelského týmu, lze jej rekrutovat různými způsoby. Fiver Učitelé ve školách Katolická církev
Myslím, že myšlenka katolické církve může být překvapivá a může se zdát nemístná, nebo zbožná, takže zde je myšlenka, která za tím stojí.
Nejprve si vyjasněme: i když jsou v (snad) všech organizacích sadističtí učitelé, vraždící policisté a spousta špatných lidí, nemůžeme je všechny odsoudit jako špatné lidi. A to nemluvím o odpuštění, to vůbec ne. Mluvím o spolupráci s tou lepší částí, s těmi dobrými lidmi, kteří tam jsou. Jejich místo je o lásce a sdílení a není třeba věřit v žádnou víru ani zázrak. Wiki je sekulární, neinvestuje do paranormálních aktivit ani do šíření poselství. Ale (opět dvojí výhra): Katolická církev je všude na planetě, ve všech jazycích a plná učenců v jazycích. Ano, chtějí mluvit o lásce (a bohužel někdy i o tom, proč je jejich láska lepší), ale chtějí přeložit bibli do všech jazyků na světě. Je to jejich základní víra, protože Ježíš řekl (tak to říkají): Ježíš řekl: "Šířte slovo. Nemám aktuální informace o finančních zdrojích papeže Františka a jeho přátel, ale vím, že mají síť učenců, kteří mluví místními jazyky nebo vědí, kdo je opravdu spolehlivý, aby se této práce ujal. Měli špatné PR a nyní hledají odpověď na otázku, jaké místo může mít církev, jak mohou pomoci lidem šířením našich slov a svého slova. A ať už je víra jakákoli, Bible je kniha, která formovala lidstvo po poslední dvě tisíciletí. Její překlad do všech kreolských jazyků by byl projevem míru a úcty, to je vše. A co ostatní velká náboženství? Naskočte na ně! Můžeme posílat pozvánky současně, protože rozsah je jasně definován (takže Wiki zůstane světská a všichni budou v klidu). Každá církev je založena na četbě a interpretaci literatury, tady jde opravdu o poznání a filologii. A jejich hierarchie může potvrdit důvěryhodnost překladatelů. Nechceme přece někoho jako falešného tlumočníka znakové řeči, který tlumočil projev Baracka Obamy na zádušní mši za Nelsona Mandelu. —Předchozí nepodepsaný komentář přidal François Jourdain (talk) 04:35, 23 February 2022 (UTC)
- Možná zajímavý nápad. Sponzorované příspěvky je třeba vždy důkladně zvážit společně s komunitou, ale mohla by to být možnost pro případ, že by organický růst příliš stagnoval. Uvidíme! O tom bychom měli přemýšlet zhruba za rok. --DVrandecic (WMF) (talk) 00:11, 5 March 2022 (UTC)