В рунете я почти не встречал материалов о том, как писать расширения для MediaWIki (платформы, на которой работает Википедия). Основной стартовой точкой при написании расширений был и остается официальный сайт платформы, но там процесс расписан не очень дружелюбно по отношению к новичкам. Попробуем же это исправить.
В этой статье я покажу, как написать простейшее расширение для Медиавики, включающее в себя новый метод API, расширение парсера и немного js/css для фронтенда. А чтобы не было скучно, приплетем сюда работу с Google Knowledge Graph.
MediaWiki модульная платформа, куда можно устанавливать расширения для добавления самого разного функционала. Помимо того, что расширения могут реализовывать какой-то свой независимый функционал (например, добавлять какие-нибудь виджеты), оно также может и модифицировать функциональность платформы: например, менять принцип работы поиска или модифицировать внешний вид платформы. Посмотреть примеры расширений можно на официальном сайте платформы.
Пишутся расширения, как правило, на php+jQuery. Возможность встраиваться в код ядра MediaWiki (или в код других расширений) реализована через т.н. хуки. Хуки позволяют вызывать дополнительный код по заданным событиям. Примерами таких событий могут быть: сохранение страницы, вызов поиска по сайту, открытие страницы на редактирование и так далее.
Расширения MediaWiki позволяют делать что угодно: работать напрямую с базой, модифицировать вики-движок, работать с файловой системой и так далее. С одной стороны, это позволяет добавлять какой угодно функционал, но с другой накладывает на вас большую ответственность при установке новых сторонних расширений. Впрочем, довольно лирики, приступим к написанию своего расширения.
Готовое расширение можно взять тут:
https://github.com/Griboedow/GoogleKnowledgeGraph
Давайте развлечемся и напишем что-нибудь бесполезное. Скажем, расширение, которое будет вытаскивать описания с Google Knowledge Graph.
Т.е. расширение будет вот это:
Код этого приложения прост и изящен как <GoogleKnowledgeGraph query="Мэльхэнанвенанхытбельхын"/>
Превращать в это:
Штука довольно бесполезная, но она послужит хорошей иллюстрацией. Еще и с графом знаний Гугла поиграемся!
Расширение сделано исключительно в учебных целях, не рекомендую его использовать на настоящих вики. Гугл предоставляет 100 000 бесплатных запросов в день. Для небольших вики это не проблема, но на серьезных сайтах ресурс будет исчерпан очень быстро.
Примерный принцип работы расширения выглядит так:
Пользователь сохраняет страницу, где в тексте присутствуют теги
<GoogleKnowledgeGraph query="Ричард
Докинз">
.
MediaWIki позволяет использовать не только формат тега, но и
формат функции парсера <link>:
{{#GoogleKnowledgeGraph||query=Ричард Докинз}}
.
Расширение функции парсера превращает тег в html код
<span class="googleKnowledgeGraph">Ричард
Докинз</span>
JS код при загрузке страницы идет по всем элементам
.googleKnowledgeGraph
и запрашивает через API нашего
же расширения описания терминов, подставляя их в
title.
API нашего расширения будет максимально примитивным: он будет передавать запросы от фронтенда на Google API, чистить ответ от всего лишнего и передавать очищенное описание сущности на фронт.
В целом, можно было бы обойтись и без фронтенда, но запросы на внешние сайты могут проходить не очень быстро. Лучше показать основной контент страницы пораньше, и в фоне догрузить необязательный контент. К тому же мы тут учимся, а не пишем серьезный код, верно?
Итого, нам потребуется:
Определить манифест нашего расширения.
Расширить MediaWIki API, добавив запрос на получение описания из Google Knowledge Graph
Расширить парсер MediaWiki, добавив обработку нового тега.
Добавить JS код, который будет выполняться по загрузке страницы
Подгрузить наше расширение в MediaWiki
Поделиться результатом наших трудов с сообществом.
А еще перед началом работы вам потребуется токен для работы с Google Knowledge Graph API. Сгенерировать его можно тут.
Типичная иерархия файлов и папок для MediaWIki расширения выглядит так:
extensions <-- Папка всех расширений MediaWiki GoogleKnowledgeGraph <-- Подпапка с нашим расширением extension.json <-- Манифест нашего расширения i18n <-- Каталог с используемыми строками для разных языков en.json <-- Строки на английском qqq.json <-- Описания строк для облегчения жизни переводчиков ru.json <-- Строки на русском includes <-- PHP код ApiGoogleKnowledgeGraph.php <-- Расширение API GoogleKnowledgeGraph.hooks.php <-- Расширение парсера и другие хуки modules <-- Папка с JS модулями ext.GoogleKnowledgeGraph <-- В нашем случае модуль только 1 ext.GoogleKnowledgeGraph.css <-- CSS стили нашего модуля ext.GoogleKnowledgeGraph.js <-- JS код нашего модуля
Разберем содержимое всех файлов по порядку, и начнем с самого простого.
Для того, чтобы нашим расширением было удобно пользоваться на всех языках, можно воспользоваться стандартной системой интернационализации banana-i18n. Помимо облегчения интернационализации, эта система также позволяет хранить все тексты в одном месте (а не раскиданными по коду). Выглядит это примерно так:
qqq.json
{"@metadata": {"authors": [ "Developer Name" ]},"googleknowledgegraph-description": "Description of the extension, to be show in Special:Vesion.","apihelp-askgoogleknowledgegraph-summary" : "Help string for 'askgoogleknowledgegraph' API request","apihelp-askgoogleknowledgegraph-param-query": "Help string for 'query' parameter of API request 'askgoogleknowledgegraph'"}
en.json
{"@metadata": {"authors": [ "Nikolai Kochkin" ]},"googleknowledgegraph-description": "The extension gets brief description from Google Knowledge Graph","apihelp-askgoogleknowledgegraph-summary" : "API to get description from Google Knowledge Graph","apihelp-askgoogleknowledgegraph-param-query": "String to ask from Google Knowledge Graph"}
Для начала разберемся, как нам сообщить MediaWiki, что нужно загрузить то или иное расширение. Путей на самом деле два:
Использоватьrequire_once( '/path/to/file.php' )
.
Этот метод считается устаревшим, так что мы его подробно не будем
рассматривать.
Использовать функцию
wfLoadExtension('ExtensionName')
. Сейчас этот способ
считается основным, так что на нем и остановимся.
http://personeltest.ru/aways/habr.com/ru/company/veeam/blog/544534
Второй способ подразумевает наличие в папке файла extension.json с описанием манифеста приложения (как оно называется, из чего состоит, какие хуки использует и так далее).
Определяем манифест (файл extension.json):
{"name": "GoogleKnowledgeGraph","version": "0.1.0","author": ["Nikolai Kochkin"],"url": "http://personeltest.ru/aways/habr.com/ru/company/veeam/blog/544534/","descriptionmsg": "googleknowledgegraph-description","license-name": "GPL-2.0-or-later","type": "parserhook","requires": {"MediaWiki": ">= 1.29.0"},"MessagesDirs": {"GoogleKnowledgeGraph": ["i18n"]},"AutoloadClasses": {"GoogleKnowledgeGraphHooks": "includes/GoogleKnowledgeGraph.hooks.php","ApiAskGoogleKnowledgeGraph": "includes/ApiAskGoogleKnowledgeGraph.php"},"APIModules": {"askgoogleknowledgegraph": "ApiAskGoogleKnowledgeGraph"},"Hooks": {"OutputPageParserOutput": "GoogleKnowledgeGraphHooks::onBeforeHtmlAddedToOutput","ParserFirstCallInit": "GoogleKnowledgeGraphHooks::onParserSetup"},"ResourceFileModulePaths": {"localBasePath": "modules","remoteExtPath": "GoogleKnowledgeGraph/modules"},"ResourceModules": {"ext.GoogleKnowledgeGraph": {"localBasePath": "modules/ext.GoogleKnowledgeGraph","remoteExtPath": "GoogleKnowledgeGraph/modules/ext.GoogleKnowledgeGraph","scripts": ["ext.GoogleKnowledgeGraph.js"],"styles": ["ext.GoogleKnowledgeGraph.css"]}},"config": {"GoogleApiLanguage": {"value": "ru","path": false,"description": "In which language you want to get result from the Knowledge Graph","public": true},"GoogleApiToken": {"value": "","path": false,"description": "API token to be used with Google API","public": false}},"ConfigRegistry": {"GoogleKnowledgeGraph": "GlobalVarConfig::newInstance"},"manifest_version": 2}
Разбираем extension.json по частям
Первая часть файла определяет то, что пользователь увидит в описании расширения на странице Special:Version
"name": "GoogleKnowledgeGraph","version": "0.1.0","author": ["Nikolai Kochkin"],"url": "http://personeltest.ru/aways/habr.com/ru/company/veeam/blog/544534/","descriptionmsg": "googleknowledgegraph-description","license-name": "GPL-2.0-or-later","type": "parserhook",
Далее мы указываем зависимости нашего расширения: с какими версиями MediaWIki расширение может работать, какие версии php требуются, какие расширения должны быть уже установлены и так далее.
"requires": {"MediaWiki": ">= 1.29.0"},
Затем мы указываем, где искать файлы со строками i18n
"MessagesDirs": {"GoogleKnowledgeGraph": ["i18n"]},
И сообщаем, в каких файлах искать классы для автоподгрузки. Подробнее тут.
"AutoloadClasses": {"GoogleKnowledgeGraphHooks": "includes/GoogleKnowledgeGraph.hooks.php","ApiAskGoogleKnowledgeGraph": "includes/ApiAskGoogleKnowledgeGraph.php"},
Заявляем, что мы реализовываем API метод
askgoogleknowledgegraph в классе
ApiAskGoogleKnowledgeGraph
"APIModules": {"askgoogleknowledgegraph": "ApiAskGoogleKnowledgeGraph"},
Перечисляем, какие коллбеки для каких хуков у нас реализованы
"Hooks": {"BeforePageDisplay": "GoogleKnowledgeGraphHooks::onBeforePageDisplay","ParserFirstCallInit": "GoogleKnowledgeGraphHooks::onParserSetup"},
Сообщаем, что модули наши лежат в папке modules
"ResourceFileModulePaths": {"localBasePath": "modules","remoteExtPath": "GoogleKnowledgeGraph/modules"},
И определяем наш фронтенд модуль с js и css. Когда модулей несколько, можно указать в коде зависимости между ними.
"ResourceModules": {"ext.GoogleKnowledgeGraph": {"localBasePath": "modules/ext.GoogleKnowledgeGraph","remoteExtPath": "GoogleKnowledgeGraph/modules/ext.GoogleKnowledgeGraph","scripts": ["ext.GoogleKnowledgeGraph.js"],"styles": ["ext.GoogleKnowledgeGraph.css"]}},
И, наконец, задаем дополнительные параметры конфигурации нашего расширения
"config": {"GoogleApiLanguage": {"value": "ru","path": false,"description": "In which language you want to get result from the Knowledge Graph","public": true},"GoogleApiToken": {"value": "","path": false,"description": "API token to be used with Google API","public": false}},"ConfigRegistry": {"GoogleKnowledgeGraph": "GlobalVarConfig::newInstance"},
В LocalSettings.php опции будут иметь стандартный префикс wg
$wgGoogleApiToken = 'your-google-token';$wgGoogleApiLanguage = 'ru';
И, наконец, задаем версию схемы манифеста
"manifest_version": 2
Мы используем лишь небольшой список поддерживаемых полей манифеста. Почитать обо всех полях можно тут.
Для начала реализуем API.
В extension.json мы заявили, что у нас будет метод
askgoogleknowledgegraph
, реализованный в классе
ApiAskGoogleKnowledgeGraph
из файла
includes/ApiAskGoogleKnowledgeGraph.php:
// extension.json fragment"AutoloadClasses": { <...> "ApiAskGoogleKnowledgeGraph": "includes/ApiAskGoogleKnowledgeGraph.php"},"APIModules": { "askgoogleknowledgegraph": "ApiAskGoogleKnowledgeGraph" },
Теперь реализуем наш метод. Файл includes/ApiAskGoogleKnowledgeGraph.php:
<?php/** * Класс включает в себя реализацию и описание API метода askgoogleknowledgegraph * Для простоты я не реализую кеширование, любопытные могут подсмотреть реализацию тут: * https://github.com/wikimedia/mediawiki-extensions-TextExtracts/blob/master/includes/ApiQueryExtracts.php */use MediaWiki\MediaWikiServices;class ApiAskGoogleKnowledgeGraph extends ApiBase {public function execute() {$params = $this->extractRequestParams();// query - обязательный параметр, так что $params['query'] всегда определен$description = ApiAskGoogleKnowledgeGraph::getGknDescription( $params['query'] );/** * Определяем результат для Get запроса. * На самом деле Post запрос отработает с тем же успехом, * если специально не отслеживать тип запроса \_()_/. */$this->getResult()->addValue( null, "description", $description );}/** * Список поддерживаемых параметров метода */public function getAllowedParams() {return ['query' => [ApiBase::PARAM_TYPE => 'string',ApiBase::PARAM_REQUIRED => true,]];}/** * Получаем данные из Google Knowledge Graph, * предполагая, что самый первый результат и есть верный. */private static function getGknDescription( $query ) {/** * Вытаскиваем параметры языка и токен. * Все параметры в LocalSettings.php имеют префикс wg, например: wgGoogleApiToken. * Здесь же мы их указываем без префикса */$config = MediaWikiServices::getInstance()->getConfigFactory()->makeConfig( 'GoogleKnowledgeGraph' );$gkgToken = $config->get( 'GoogleApiToken' );$gkgLang = $config->get( 'GoogleApiLanguage' );$service_url = 'https://kgsearch.googleapis.com/v1/entities:search';$params = ['query' => $query ,'limit' => 1,'languages' => $gkgLang,'indent' => TRUE,'key' => $gkgToken,];$url = $service_url . '?' . http_build_query( $params );$ch = curl_init();curl_setopt( $ch, CURLOPT_URL, $url) ;curl_setopt( $ch, CURLOPT_RETURNTRANSFER, 1 );$response = json_decode( curl_exec( $ch ), true );curl_close( $ch );if( count( $response['itemListElement'] ) == 0 ){return "Nothing found by your request \"$query\"";}if( !isset( $response['itemListElement'][0]['result'] ) ){return "Unknown GKG result format for request \"$query\"";}if( !isset($response['itemListElement'][0]['result']['detailedDescription'] ) ){return "detailedDescription was not provided by GKG for request \"$query\"";}if( !isset( $response['itemListElement'][0]['result']['detailedDescription']['articleBody'] ) ){return "articleBody was not provided by GKG for request \"$query\"";}return $response['itemListElement'][0]['result']['detailedDescription']['articleBody'];}}
Теперь мы можем обращаться по апи к нашей вики:
Get /api.php?action=askgoogleknowledgegraph&query=Выхухоль&format=jsonResponse body:{"description": "Выхухоль, или русская выхухоль, или хохуля, вид млекопитающих отряда насекомоядных из трибы Desmanini подсемейства Talpinae семейства кротовых. Один из двух видов трибы; вторым видом является пиренейская выхухоль."}
// Фрагмент файла extension.json"AutoloadClasses": {"GoogleKnowledgeGraphHooks": "includes/GoogleKnowledgeGraph.hooks.php",<...>},"Hooks": {"BeforePageDisplay": "GoogleKnowledgeGraphHooks::onBeforePageDisplay","ParserFirstCallInit": "GoogleKnowledgeGraphHooks::onParserSetup"},
В extension.json мы заявили, что в классе
GoogleKnowledgeGraphHooks
из файла
includes/GoogleKnowledgeGraph.hooks.php реализуем
расширения для хуков:
OutputPageParserOutput в методе
onBeforeHtmlAddedToOutput
;
ParserFirstCallInit в методе
onParserSetup
Немножко про используемые хуки:
OutputPageParserOutput позволяет выполнить
какой-то код после того, как парсер закончил формировать html, но
перед тем, как html был добавлен к аутпуту. Здесь мы, например,
можем подгрузить фронтенд. Фронтенд мы целиком расположили в модуле
ext.GoogleKnowledgeGraph
, так что достаточно будет
подгрузить его.
ParserFirstCallInit позволяет расширить парсер
дополнительными методами. Мы добавим в парсер обработку тега
<GoogleKnowledgeGraph>
.
Итак, реализация (файл includes/GoogleKnowledgeGraph.hooks.php):
<?php/** * Хуки расширения GoogleKnowledgeGraph */class GoogleKnowledgeGraphHooks {/** * Сработает хук после окончания работы парсера, но перед выводом html. * Детали тут: https://www.mediawiki.org/wiki/Manual:Hooks/OutputPageParserOutput */public static function onBeforeHtmlAddedToOutput( OutputPage &$out, ParserOutput $parserOutput ) {// Добавляем подгрузку модуля фронтенда для всех страниц, его определение ищи в extension.json$out->addModules( 'ext.GoogleKnowledgeGraph' );return true;}/** * Расширяем парсер, добавляя обработку тега <GoogleKnowledgeGraphHooks> */public static function onParserSetup( Parser $parser ) {$parser->setHook( 'GoogleKnowledgeGraph', 'GoogleKnowledgeGraphHooks::processGoogleKnowledgeGraphTag' );return true;}/** * Реализация обработки тега <GoogleKnowledgeGraph> */public static function processGoogleKnowledgeGraphTag( $input, array $args, Parser $parser, PPFrame $frame ) {// Парсим аргументы, переданные в формате <GoogleKnowledgeGraph arg1="val1" arg2="val2" ...> if( isset( $args['query'] ) ){$query = $args['query'];}else{// В тег не был передан аргумент query, так что и выводить нам нечегоreturn '';}return '<span class="googleKnowledgeGraph">' . htmlspecialchars( $query ) . '</span>';}}
Фронтенд свяжет воедино все, что мы реализовали выше.
// Фрагмент файла extension.json "ResourceModules": {"ext.GoogleKnowledgeGraph": {"localBasePath": "modules","remoteExtPath": "GoogleKnowledgeGraph/modules","scripts": ["ext.GoogleKnowledgeGraph.js"],"styles": ["ext.GoogleKnowledgeGraph.css"],"dependencies": []}}, "ResourceFileModulePaths": {"localBasePath": "modules","remoteExtPath": "GoogleKnowledgeGraph/modules"},
В extension.json мы заявили, что у нас есть один модуль
ext.GoogleKnowledgeGraph
, который находится в папке
modules и состоит из двух файлов:
modules/ext.GoogleKnowledgeGraph/ext.GoogleKnowledgeGraph.js
modules/ext.GoogleKnowledgeGraph/ext.GoogleKnowledgeGraph.css
Загрузку модуля мы реализовали чуть раньше в методе
onBeforeHtmlAddedToOutput
. Определим теперь и сам код
модуля.
Для начала зададим стили
(файл
modules/ext.GoogleKnowledgeGraph/ext.GoogleKnowledgeGraph.css):
.googleKnowledgeGraph{ border-bottom: 1px dotted #000; text-decoration: none;}
А теперь возьмемся за JS
(файл
modules/ext.GoogleKnowledgeGraph/ext.GoogleKnowledgeGraph.js):
( function ( mw, $ ) { /** * Ищем все элементы с <span class="googleKnowledgeGraph">MyText</span>, * вытаскиваем MyText и отправляем запрос * /api.php?action=askgoogleknowledgegraph&query=MyText * После чего добавляем результат в 'title'. */$( ".googleKnowledgeGraph" ).each( function( index, element ) {$.ajax({type: "GET", url: mw.util.wikiScript( 'api' ),data: { action: 'askgoogleknowledgegraph', query: $( element ).text(),format: 'json',},dataType: 'json',success: function( jsondata ){$( element ).prop( 'title', jsondata.description );}});});}( mediaWiki, jQuery ) );
JS код довольно прост. jQuery нам достался даром, поскольку MediaWiki подгружает его автоматически.
Для загрузки расширения, как мы уже обсуждали, потребуется поправить файл LocalSettings.php. Добавляем в самый конец:
// Фрагмент файла LocalSettings.php<?php<...> wfLoadExtension( 'GoogleKnowledgeGraph' );$wgGoogleApiToken = "your-google-token";$wgGoogleApiLanguage = 'ru';
Можно пробовать! Добавим на страницу что-нибудь эдакое:
Даже <GoogleKnowledgeGraph query="прикольный флот"/> может стать отстойным.
И получим:
Если есть возможность поделиться расширением с общественностью, то можно создать страницу на MediaWiki с кратким описанием, что ваше расширение может сделать (не забудьте скриншоты: лучше один раз увидеть, чем сто раз прочитать). На страницы с описаниями расширений обычно добавляют шаблон Extension, поля которого хорошо задокументированы. Если же возникнут сложности, всегда можно скопировать его с другой страницы расширений и подправить отличающиеся поля.
Типичная страница с описанием расширенияВ статье был описан случай довольно простого расширения, но, на самом деле, такие расширения как iFrame, CategoryTree, Drawio и многие другие не очень далеко ушли по сложности.
За скобками остались такие вещи, как работа с базой, кэширование, OOUI и много-многое другое. Все ж я вас не напугать хотел, а как раз наоборот показать, что писать расширения под вики на самом деле совсем не сложно и не страшно.
Страница помощи разработчику расширений MediaWIki
Example extension расширение с пачкой примеров на все случаи жизни
banana-i18n (как работает интернационализация)
Схема extension.json (файл поддерживает много дополнительных полей)
Сегодня мы прочли статью Википедия купается в деньгах и были очарованы. Там рассказано, как фонд Wikimedia собирает пожертвования по всему миру, и как развивается его целевой капитал. Да, всё в статье правда: в США и фонд есть, и активы есть, и доход есть. Однако in Soviet Russia дело обстоит совсем иначе. Поистине тревожит российских редакторов-добровольцев Википедии совсем иное.
Вообще говоря, фонд Wikimedia очень хорошо поддерживает волонтёров. Он предлагает проектные гранты, гранты на оборудование, гранты на поездки. Он занимается дипломатией и помогает своим chapters местным союзным организациям. Однако из-за политических причин фонд никак не работает с жителями России, не принимает никаких пожертвований из России.
Вот, убедитесь своими глазами.
Во многих странах работают местные организации, созданные участниками Википедии. Конечно, головной фонд помогает им. С 2008 года в России тоже есть такой союз партнёрство Викимедиа РУ. И ему головной фонд не помогает никак, не перечисляет ничего.
Поэтому для нас, жителей России, пожертвования в Wikimedia Foundation напрочь бесполезны. Эти пожертвования никак не отразятся на русскоязычной Википедии, на российских участниках. Они останутся в заграничном обществе.
Значит, надо совсем по-другому относиться к пожертвованиям. И как же? А вот как.
1) Если вы хотите помочь Википедии помогите ей там, где вы живёте. Помогите участникам в вашей области, в вашем городе, в вашем селе. Свяжитесь с людьми, которые наполняют Википедию фотографиями и книгами (Викисклад), которые пишут статьи для неё. Спросите у них, какая помощь нужна. Отдайте деньги на конкретные местные задачи.
2) Если вы хотите поддержать конкретный проект, например, Викиновости или Викигид откройте форум того проекта, обратитесь к участникам, предложите им свою помощь.
3) Если вы хотите просто отдать деньги на Википедию обратитесь в Викимедиа РУ и отправьте деньги туда. Ваша помощь останется в России и перейдёт к тем, кто создаёт вики-материал на русском языке.
Впрочем, поддержать можно не только деньгами. Можно поддержать и дипломатией, и оцифровкой контента, и пропагандой. Вы знаете, как работает Википедия, а сотрудники местного вуза не знают. Вы знаете, как пополнять Википедию контентом, а сотрудники местной библиотеки не знают. Вы знаете, что такое свободная лицензия, а местная администрация и городская газета не знают. Вы знаете, что такое Викисклад, а ваши друзья-фотографы не знают.
Пожалуйста, откройте им глаза. Зулейха Валиева не должна остаться в одиночестве.
Вот, собственно, и всё, что надо знать о пожертвованиях на Википедию в нынешней России.
Возможно для кого-то это будет удивительно и даже возмутительно, но в Википедии информация не должна быть правдивой, важно, чтобы она была подтверждена достоверными источниками. Именно проблеме дезинформации и достоверности источников в Википедии был посвящён последний выпуск уходящего 2020 года Wikimedia Research Showcase. Это ежемесячное публичное мероприятие, на котором представляются последние работы исследовательской группы Фонда Викимедиа и приглашенных докладчиков из академического сообщества. Мне была предоставлена возможность рассказать о последних научных работах, проведённых совместно с сотрудниками нашей кафедры. В этой статье на Хабре я постараюсь коротко описать последние исследования нашей кафедры в области оценки качества информации и достоверности источников в многоязычной Википедии. Дополнительно представлены общедоступные инструменты для оценки качества и достоверности, основанные на научных исследованиях.
Исследование качества информации и достоверности источников в ВикипедииВидеотрансляция декабрьского выпуска 2020 года Wikimedia Research Showcase доступна на YouTube, а слайды с презентации размещены на SlideShare и figshare.
Согласно Ethnologue, в мире люди разговаривают на более чем 7 тыс. языках, из которых почти 3 тыс. под угрозой исчезновения. Для сравнения, статьи Википедии доступны на 314 языках.
Более половины населения Земли разговаривает только на 23 языках. Самым популярным является английский, на нём разговаривает около 1.27 млрд человек. Однако, для более чем 70% из них - английский не является родным.
В своей научной диссертации, которая была защищена в марте 2019 года в польском университете, я описал метод сравнения и обогащения информации в многоязычных сайтов вики, основанный на анализе их качества. В качестве примера рассматривался наиболее популярный сайт вики Википедия. Для проверки предложенного метода рассматривались 5 языковых разделов Википедии английский, белорусский, польский, русский, украинский.
Пример обогащения белорусской Википедии инфобоксом с описанием Экономического Университета в Познани.Знание этих языков и результаты исследований позволили мне прийти к выводу, что предложенные в диссертации алгоритмы можно использовать и для других языковых версий этой свободной энциклопедии (а также для других сайтов вики).
Википедию можно редактировать на каждом языке независимо, что приводит к таким проблемам как:
один и тот же объект (город, персона, событие и т.п.) можно описать по-разному,
пользователю обычно необходимо понимать эти языки для проверки/сравнения информации.
Дополнительно, сама оценка качества информации субъективна и зависит от языка Википедии:
каждый языковой раздел определяет свои правила и стандарты,
стандарты могут меняться со временем.
Одним из важных критериев качества информации в Википедии является наличие достоверных источников. Однако, оценка одного и того же источника зависит от языковой версии Википедии. Дополнительная проблема - надежность одного и того же источника может со временем измениться.
Каждое языковое издание Википедии может определять собственную систему оценок качества для статей. Часто каждая языковая версия имеет специальную отметку для статей, которые считаются лучшими - Избранные статьи. Также есть отметка за качественные достойные статьи, не соответствующие критериям Избранных статей - они называются Хорошие статьи.
В некоторых языковых версиях Википедии есть также другие оценки качества, которые могут отражать зрелость статьи. В английской Википедии, помимо наивысших оценок FA и GA, есть ещё A-класс, B-класс, C-класс, Старт и Заглушка. В русской Википедии дополнительно к двум наивысшим оценкам есть ещё Добротная статья, I уровень, II уровень, III уровень и IV уровень. В польской Википедии есть три дополнительных класса: Четверка, Старт и Заглушка.
Несмотря на одинаковые названия, эквивалентные классы между языковыми версиями могут иметь различия в оценке стандартов. Например, в некоторых языковых версиях для высоких оценок существует ограничение на длину статьи. Следовательно, для каждой языковой версии может быть своя собственная модель качества, даже если у этих языков одинаковое количество оценок.
Дополнительная проблема - большое количество статей, не имеющих оценки качества. Некоторые языковые версии содержат более 90% неоцененных статей. Ниже представлена сравнительная таблица для некоторых языковых разделов Википедий (по порядку: белорусский, немецкий, английский, французский, польский, русский, украинский).
Классификация качества в разных языковых разделах ВикипедииЧтобы определить параметры качества в Википедии, следует принять во внимание сходство этого веб-сайта с традиционными энциклопедиями и сайтами на технологии Веб 2.0. С одной стороны, контент в Википедии создан как ориентир в энциклопедическом стиле. С другой стороны, Википедия построена таким образом, чтобы пользователи могли сотрудничать и писать совместно материалы. Поэтому он основан на технологиях Веб 2.0.
На рисунке ниже показано покрытие между критериями качества сайтов Веб 2.0, традиционных энциклопедий и Википедии. Принимая во внимание критерии качества, принятые сообществом Википедии, мы можем выбрать следующие критерия (измерения) качества для статей Википедии: актуальность, достоверность, объективность, полнота, релевантность, стиль, читабельность.
Критерии качества. Источник: wikipediaquality.comАктуальность: насколько статья описывает текущее состояние определенной реальности (степень актуальности/своевременности информации).
Достоверность: можно ли проверить предоставленную информацию из надежных источников.
Объективность: насколько содержание статьи соответствует критерию нейтральной точки зрения, содержит ли она изображения и другие мультимедийные материалы, относящиеся к этой статье.
Полнота: насколько исчерпывающим является описание темы в статье.
Релевантность: насколько статья важна для читателей/пользователей и соответствует его информационным нуждам.
Стиль: как организовано содержание статьи (наличие и размещение дополнительных комментариев, таблиц, изображений, звуковых файлов и др.).
Читабельность: насколько текст понятен и свободен от ненужной сложности.
Используя алгоритмы машинного обучения, мы можем определить, какие параметры (характеристики) статей Википедии являются наиболее важными для оценки качества. Пример таких параметров: количество слов в тексте статьи, количество изображений, посещение статьи за определённый период времени, сколько раз статья была редактирована и др.
Шесть лет назад мы опубликовали результаты исследований, в которых показали, что показатели вместе с их значимостью образуют определенный профиль языка, то есть один параметр важен для одного языка, другой лучше характеризует качество информации другого языкового раздела Википедии. Затем можно сравнивать разные языки.
Другой пример - в моей диссертации было использовано более 100 параметров для построения моделей качества для разных языков. Рисунок ниже показывает важность выбранных показателей в моделях прогнозирования качества в английской и русской Википедии.
Мы обнаружили, что некоторые из показателей показали высокую важность при оценке качества статей на разных языках. Такие параметры обычно положительно коррелируют с оценками качества: длинна статьи, количество изображений, примечаний (источников), разделов, авторов и др.
Шесть лет назад мы предложили способ оценки качества статей по непрерывной шкале (от 0 до 100), используя синтетический показатель качества, который включает в себя нормализованные значения важных параметров статей. Нормализация выбранных параметров зависит от языкового раздела Википедии, поскольку она использует пороговые значения, которые зависят от лучших статей в рассматриваемой языковой версии. Нормализация каждого параметра проводилась в соответствии со следующим правилом: если значение данного параметра на данном языке превышало пороговое значение медианного значения лучших статей в той же языковой версии, она принималась равной 100 баллам; в противном случае его значение линейно масштабировалось, чтобы отразить отношение значения параметра к среднему значению. Более подробную информацию об алгоритме и результатах его применения синтетического показателя качества на миллионах статей Википедии можно найти в научных публикациях в журналах Informatics и Computers.
Числовое значение качества статьи позволяет сравнивать качество статей даже между разными языковыми версиями Википедии. Это позволяет найти, какие темы (категорий) статей конкретного языкового раздела Википедии имеют информацию лучшего качества.
Оценки качества вместе с показателями популярности, цитируемости, интереса авторов могут использоваться для создания индивидуального профиля для каждой статьи Википедии в каждой языковой версии. Например, на рисунке ниже представлен такой профиль на портале ВикиРанк с информацией о качестве и популярности для статьи Президентские выборы в США (2020) в русскоязычной Википедии.
Профиль статьи Википедии с оценкой качества и популярности. Источник: wikirank.netОдним из важнейших факторов, влияющих на качество статей в Википедии, является наличие достоверных источников. Следуя ссылкам в примечаниях (сносках), читатели могут проверить факты или найти более подробную информацию по описанной теме. В одной из наших последних работ мы проанализировали более 40 миллионов статей из 55 наиболее развитых языковых разделов Википедии, чтобы извлечь информацию о более чем 200 миллионах примечаний (источников) и найти самые популярные и достоверные источники.
В вышеупомянутой публикации, мы использовали разные способы нахождения и извлечения информации об источниках статей Википедии. Например, комплексное извлечение основывалось на исходном коде статей (вики-разметка). Наличие некоторых примечаний невозможно определить напрямую на основании исходного (вики) кода статей. Иногда информационные блоки или таблицы в статье Википедии представлены лишь как шаблоны (ссылки в коде, которые позволяют получить содержимое из других страниц Википедии). На рисунке показана такая ситуация на примере таблицы со ссылками в статье Википедии о пандемии коронавируса, которая была добавлена с использованием шаблона. В нашем комплексном подходе мы учитывали содержание таких шаблонов.
Следующий рисунок показывает наиболее часто используемые шаблоны в тегах "<ref>" в английской Википедии. Среди наиболее часто используемых шаблонов в языковых версиях этой Википедии: Cite web, Cite news, Cite book, Cite journal и другие.
Наиболее распространённые шаблоны в примечаниях анлийской Википедии. Источник: https://doi.org/10.3390/info11050263Для русскоязычной Википедии среди наиболее популярных шаблонов можно встретить такие как: Статья, Книга, Публикация и др. Следующий рисунок иллюстрирует наиболее часто используемые шаблоны в тегах "<ref>" в русской Википедии.
Для других языковых разделов Википедии подобные рисунки можно найти в дополнительных материалах к научной статье.
Некоторые часто используемые шаблоны в примечаниях подробно описывают источник могут содержать информацию об авторах, издателе, дате публикации и др. Например, для английской Википедии наиболее часто заполняемые параметры таких шаблонов представлены на рисунке:
Для русскоязычной Википедии аналогичные данные выглядят так:
Для других языковых разделов результаты подобных исследований можно найти на странице с дополнительными материалами.
После анализа таких шаблонов с библиографией мы можем найти, например, популярных издателей в английской Википедии. Учитывая более 18 миллионов таких шаблонов, которые имеют значение в параметре publisher (издатель) можно сгенерировать рисунок, который показывает наиболее часто используемых издателей в источниках в английской Википедии.
Некоторые из самых популярных шаблонов позволяют добавлять идентификаторы к источнику, такие как DOI, JSTOR, PMC, PMID, arXiv, ISBN, ISSN, OCLC и другие. Часто такие идентификаторы указывают на научный источник информации. Рисунок ниже показывает, какая часть примечаний в некоторых языковых разделах Википедии содержит информацию об источниках с идентификаторами DOI, ISBN, ISSN, PMID, PMC.
Результаты показывают, что наиболее часто используются идентификаторы ISBN и DOI. Однако в общей массе примечаний встречаются не чаще чем в 10% случаев. Важно отметить, что наблюдается постепенное увеличение доли ссылок на научные публикации.
В нашем недавнем исследовании мы предложили десять моделей, связанных с популярностью и надежностью источников. В большинстве случаев источник означает сайт (домен или поддомен) из URL-адреса в примечаниях.
Модель F - основанная на частоте (F) использования источника.
Модель P - основана на совокупном количестве просмотров страниц (P) статьи, в которой появляется источник.
Модель PR - основанная на совокупных просмотрах страниц (P) статьи, в которой появляется источник, разделенный на количество ссылок (R) в этой статье.
Модель PL - основана на совокупном количестве просмотров страниц (P) статьи, в которой указан источник, разделенный на длину статьи (L).
Модели Pm, PmR, PmL - это модифицированные версии со средним значением ежедневных просмотров страниц.
В моделях A, AR, AL используется количество авторов.
Если говорить про математическую состовляющую, то для примера приведу формулу рассчёта для модели PR:
где:
s - источник,
n - номер по порядку рассматриваемой статьи Википедии,
C(i) - общее количество примечаний (сносок) в i-той статье,
Сs(i) - количество ссылок, использующих источник s (например, домен в URL) в i-той статье,
V(i) - суммарное количество просмотров i-той статьи.
Более подробное описание моделей (в том числе математическую состовляющую) можно найти в научной публикации в журнале Information.
Рассмотрим модель F, которая показывает частоту использования источника, т.е. сколько ссылок содержит анализируемый домен в URL. Этот метод часто использовался в смежных научных работах. Здесь мы учитываем общее количество появлений такой ссылки, т.е. если один и тот же источник цитируется 3 раза, мы считаем частоту как 3.
Для английской Википедии наиболее часто используемые сайты в примечаниях представлены на рисунке ниже:
Если мы рассмотрим результаты оценки источников на основании модели PR, то лидеры в английской Википедии будут выглядеть немного иначе:
Для русской Википедии аналогичный рисунок с результатами подсчёта на основе модели F выглядит так:
Модель PR вносит свои корректировки лидерства источников для русскоязычной Википедии:
В дополнительных материалах к публикации можно найти более расширенные результаты для различных языковый версий с использованием модели F и модели PR.
Как видим в зависимости от модели оценки популярности и достоверности мы можем получить разные результаты для одного и того же источника. Исследования показали, насколько сильно могут отличатся оценки достоверности также в зависимости от языкового раздела. Ниже представлена сравнительная таблица позиций в рейтинге популярности и достоверности для четырёх источников: nytimes.com, spiegel.de, lemonde.fr, elpais.com. Каждый источник был оценен с точки зрения различных языковых разделов Википедии и разных моделей.
Если мы рассматриваем сайты (домены) как источники, то их количество достигает более миллиона. Часть результатов по оценке каждого источника Википедии размещена в проекте BestRef. Для каждого источника в данном проекте имеется отдельный профиль, где показаны результаты оценки с использованием различных моделей и в рамках каждого языкового раздела Википедии. Ниже приведён пример такого профиля.
Список источников и профиль. Источник: bestref.netИспользуя разные модели популярности и достоверности, мы можем оценивать не только домены, но и отдельные типы источников. Например, на основании расширенной библиографической информации из шаблонов в примечаниях мы оценили всех издателей в источниках английской Википедии. В таблице ниже представлены самые популярные и достоверные издатели с позициями в рейтинге в зависимости от модели.
Результаты некоторых исследований были внедрены в отдельные общедоступные проекты. Более того, существуют даже расширения для браузеров, которые позволяют исследовать качество статей Википедии и их источников на месте. Например, для исследования достоверности источников можно воспользоваться плагином BestRef для Chrome. Видео-презентация этого плагина:
Для оценки и сравнения качества и популярности статей Википедии можно использовать плагин ВикиРанк для Chrome и Firefox. Кратко, о том, как это работает, показано на этом видео.
Отдельно доступно расширение для оценки качества инфобоксов (информационных карточек) в браузере Chrome. На видео-презентации можно узнать, как это работает.
Рассмотренные модели качества информации, популярности и достоверности источников могут помочь обогатить различные языковые версии Википедии и других баз знаний (таких как DBpedia, Викиданные) информацией более высокого качества. Некоторые из методов планируется интегрировать в проект GlobalFactSync (GFS). Цель проекта GFS - синхронизировать фактические данные во всех языковых разделах Википедии и Викиданных. Здесь фактические данные определяются как определенная порция информации, то есть значения данных, такие как географические координаты, население (города), даты рождения, химические формулы, участие в фильмах или место рождения, прикреплённые к объекту (в статье Википедия или элемент Викиданных) и в идеале со ссылкой на источник (происхождение этой информации).
Дополнительно, информация об оценке достоверности источников может помочь улучшить модели оценки качества статей в Википедии. Это может быть особенно полезно при сравнении несовпадающих фактов между языковыми версиями статей Википедии. Кроме того, одним из многообещающих направлений ближайших исследований является создание общедоступных инструментов, которые позволяли бы рекомендовать лучшие источники для отдельных утверждений и по выбранным темам в разных языковых разделах Википедии.
Предложенные в исследованиях модели не идеальны, и могут быть совершенствованы тут огромное поле для манёвров. Чем больше мы исследуем эту область, тем больше находим проблем и возможных способов их решения.
Если вас интересует эта тема - мы готовы рассмотреть сотрудничество в этом направлении. Вопросы и предложения можно оставлять на Хабре в комментариях или связаться другим способом.
Lewoniewski, W., Wcel, K., Abramowicz, W. (2020). Modeling Popularity and Reliability of Sources in Multilingual Wikipedia. Information, 11(5), 263. doi: 10.3390/info11050263
Lewoniewski, W., Wcel, K., Abramowicz, W. (2019). Multilingual ranking of Wikipedia articles with quality and popularity assessment in different topics. Computers, 8(3), 60. doi: 10.3390/computers8030060
Lewoniewski, W. (2019). Measures for quality assessment of articles and infoboxes in multilingual Wikipedia. In International Conference on Business Information Systems (pp. 619-633). Springer, Cham. doi: 10.1007/978-3-030-04849-5_53
Lewoniewski, W. (2018). The method of comparing and enriching information in multilingual wikis based on the analysis of their quality. PhD thesis
Lewoniewski, W., Wcel, K., Abramowicz, W. (2017). Relative quality and popularity evaluation of multilingual Wikipedia articles. Informatics 2017, 4(4), 43. doi: 10.3390/informatics4040043
Lewoniewski, W. (2017). Enrichment of information in multilingual Wikipedia based on quality analysis. In International Conference on Business Information Systems (pp. 216-227). Springer, Cham. doi: 10.1007/978-3-319-69023-0_19
Lewoniewski, W., Wcel, K., Abramowicz, W. (2017). Analysis of references across Wikipedia languages. In International Conference on Information and Software Technologies (pp. 561-573). Springer, Cham. doi: 10.1007/978-3-319-67642-5_47