Jump to content

Абстрактна Вікіпедія/Оновлення/2022-11-09

From Meta, a Wikimedia project coordination wiki
This page is a translated version of the page Abstract Wikipedia/Updates/2022-11-09 and the translation is 39% complete.
Оновлення Абстрактної Вікіпедії Translate

Абстрактна Вікіпедія (список розсилки) Абстрактна Вікіпедія в ICR Абстрактна Вікіпедія в Телеграм Wikifunctions on Mastodon Абстрактна Вікіпедія у Твіттері Абстрактна Вікіпедія у Фейсбуці Абстрактна Вікіпедія на Ютубі Сторінка проекту Абстрактні Вікіпедії Translate

Перевірка лексичних форм

Раніше ми обговорювали морфологічні парадигми і те, як можна використовувати лексеми та парадигми. Підсумовуючи та спрощуючи, парадигми — це шаблони словозміни (або зміни лексеми), а функції можуть реалізовувати парадигми та конкретні словозміни. Для прикладу, звичайний спосіб отримати множину іменника в англійській мові — це додати літеру s до його основної форми, так званої «леми».

У Notwikilambda, попередній версії Вікіфункцій спільноти, ми почали впроваджувати декілька таких функцій. Відповідно, ми відтворили деякі з них у бета-версії Вікіфункцій: наприклад додати 's' наприкінці і замінити 'y' наприкінці на 'ies'.

Щоб продемонструвати їх використання, ми розробили на основі браузера невеликий інструмент перевірки форм. Перевірка форми дозволяє вам вибрати мову та частину мови (наприклад англійські іменники), а потім вказати, які форми ви хочете створити (наприклад множина). Потім ви обираєте функцію з бета-версії Вікіфункцій, і інструмент перевіряє, чи форма, записана у Вікіданих, відповідає результату функції.

Якщо це не так, це може означати помилку або у функції чи даних, або неправильну форму.

Перевірка форми має принаймні один серйозний недолік, який полягає в тому, що вона наразі не дозволяє фільтрувати подальші твердження щодо лексеми. У багатьох мовах це має вирішальне значення: наприклад, у німецькій мові іменники відмінюються по-різному залежно від їхнього граматичного роду. Вона також не оновлює автоматично список доступних функцій (але ви можете ввести довільний ZID). Код є відкритим вихідним кодом, і внески (або, власне, хтось, хто хоче взяти на себе код) були б більш ніж бажані.

Відео демонстрація використання інструмента перевірки форм з Бета Вікіфункцій

Кажуть, що краще показати, ніж розказати. У цьому дусі ми створили 13-хвилинне відео. Воно демонструє, як використовується інструмент перевірки форми, як було корисно знайти помилку в лексемі у Вікіданих і як його використовували для виявлення парадигми та реалізації відповідної функції.

Ми запрошуємо вас реалізувати більше морфологічних функцій у Бета Вікіфункціях та випробувати їх за допомогою інструмента перевірки форм. Будь ласка, повідомляйте про помилки, які ви знайдете на шляху, щоб ми могли їх виправити. А також поділіться своїми результатами та поділіться тим, наскільки добре ви можете охопити всі різні лінгвістичні варіанти вашої мови за допомогою своїх функцій!


У цій демонстрації є кілька цікавих аспектів.

По-перше, демонстрація показує можливе використання Вікіфункцій, які зараз реалізовані для функцій, пов’язаних із природною мовою. Вона пов’язана безпосередньо з даними у Вікіданих і пропонує як спосіб пошуку помилок у даних, так і дослідження, яке може допомогти знайти закономірності в даних і створити більше таких функцій. Хоча я не розмовляю українською, я зміг створити функцію, яка вловила морфологію конкретної української форми. Ці функції можуть, у свою чергу, допомогти нам виявити більше невідповідностей або навіть швидше вводити дані з меншою схильністю до помилок. Наприклад, мені було б дуже приємно, якби існував спосіб додавати функції до полів у Wikidata Lexeme Forms, щоб я вводив лише лему, і вона автоматично заповнювала інші поля на основі результатів Вікіфункцій, а потім, якщо потрібно, я міг би вручну відредагувати результати, щоб вони були правильними перед публікацією.

Secondly, it shows how relatively easy it is to write functions, testers, and implementations. In this case, it took us less than four minutes to define the functions, write a tester, and provide an implementation. Our UX is currently being improved to make many of these steps easier and more intuitive. Not all functions will be as easy to implement. But in this case, no coding was required at all, since we had a relevant function that we could use for composition, replace at end. Our hope is that a solid library of such versatile functions can take us a long way towards pretty good coverage of morphological functions. But even if the implementation should turn out to be more complex, defining the function and providing test cases is something we expect might be possible for many potential contributors.

And thirdly, it shows, probably for the first time, an external tool calling a function from Wikifunctions (albeit Beta). It is just a website, standing in front of Wikifunctions, asking it to evaluate a function. Form check calls the SPARQL endpoint of Wikidata, and uses data from there to then to ask Wikifunctions to evaluate a function. The whole thing is a static website, needs no libraries at all, merely plain old JavaScript, and could be hosted anywhere (in fact, you can also download the HTML and load the page locally; it should work just as well).

Note that I am rather unsure whether the Form check tool is a good and useful tool. Do we really need to check thousands of forms by each individual user? We would probably want a shared resource for doing this evaluation instead. The tool is meant as an early inspiration that will hopefully lead to other tools, libraries and workflows, which are more robust, reusable, and are closely aligned with how the community works.

Volunteer’s corner

Thanks to everyone who joined the volunteer’s corner on Monday. It was lively. Thanks to all who attended! The next will be on Monday, December 5 at 18:30 UTC.

WikiConference North America 2022

This weekend Wikifunctions will be presented at the WikiConference North America, jointly held with OpenStreetMaps USA. The presentation will be on Saturday, November 12 at 20:15 UTC, and we will focus on Wikifunctions and possible use cases in the world of maps.

Staff editing policy

We are, for now, closing the hot phase of the staff editing policy. The policy belongs to the community, and can always be evolved and adapted by you. We will, on launch, copy it over to Wikifunctions, and will follow this policy.

Development updates

Experience & Performance:

  • Fixed more FE bugs
  • Merged patches related to error management
  • Made great progress on drafting the Default Component technical specs

Meta-data:

  • Completed readable summaries of all error types, and ability to record which implementation gets selected (T312611, T320457)

Natural Language Generation:

  • Finalized template language document
  • More analysis on dependencies for isiZulu