cdn.media.ccc.de/.../wikidatacon2019-9-eng-Data_quality_panel_hd.mp4

Качество данных
Панельная дискуссия

Клаудиа Мюллер-Бирн, Лукас Веркмейстер,

Хосе Эмилио Лабра Гайо,
Кристина Сарасуа, Андра

Приветствую всех на панельной дискуссии,
посвящённой качеству данных.

Качество данных имеет большое значение,
ведь всё больше и больше людей

полагаются на хорошее качество данных,

о чём мы сегодня и поговорим.

Будет четыре докладчика, которые выступят
с небольшими презентациями на темы,

связанные с качеством данных,
а далее будут вопросы и ответы.

Начнём с Лукаса.

Спасибо.

Привет, я Лукас,
и я начну с краткого обзора

инструментов качества данных,
которые уже имеются в Викиданных,

и тех, которые скоро появятся.

Я выделил несколько общих тем:

визуализация ошибок,
решаемость проблем,

больше внимания данным
с целью выявления проблем,

исправление общих источников ошибок,

обеспечение качества существующих данных,

а также курирование.

Что у нас есть сейчас?

Начнём с ограничения свойств.

Вы наверняка видели это,
когда заходили на Викиданные.

Иногда можно видеть эти иконки,

которые проверяют
внутреннюю согласованность данных.

Например, если одно событие
следует за другим,

то за другим должно последовать
и это событие,

элемент WikidataCon,
который, похоже, отсутствует.

Это появилось пару дней назад.

Если этого для вас недостаточно,

вы можете ввести любой запрос,
используя сервис запросов,

который, конечно,
полезен для многих вещей,

но также его можно использовать
для поиска ошибок.

Например, если вы заметили
какую-то ошибку,

вы можете проверить, есть ли ещё места,

где люди допустили похожие ошибки,

и найти их с помощью сервиса запросов.

Также можно совместить
эти два инструмента

и искать нарушения ограничений,

например, нарушения в какой-то области

или нужном вам Вики-проекте,

хотя результаты пока неполные,
к сожалению.

Оценивание правок.

Я думаю, это из последних изменений.

Также можете добавить в свой
список наблюдения автоматическую оценку:

сделана ли правка
с добрыми намерениями или нет,

нанесёт ли она ущерб или нет.

Думаю, здесь два направления.

Если хотите, вы можете

сосредоточиться на поиске правок
с добрыми намерениями,

наносящих ущерб.

Если вы дружелюбны и вежливы,

можете написать этим редакторам:
«Спасибо за ваш вклад,

вот, как это следует делать,
но всё равно спасибо».

Если вы не хотите так делать,

можно найти правки
с недобрыми намерениями,

наносящие ущерб,

и откатить их назад.

Подобно этому есть рейтинг сущностей.

Вместо оценивания правки,
последующего за ней изменения,

вы оцениваете ревизию в целом.

Я думаю, это такой же инструмент
измерения качества,

о котором говорила Лидия
в начале конференции.

Вот здесь скрипт, который ставит
оценку от одного до пяти.

Он оценивает качество текущего элемента.

Инструмент проверки
первичных источников предназначен

для любой базы данных,
которую вы хотите импортировать,

но качество её данных не настолько высоко,
чтобы напрямую добавлять её в Викиданные,

поэтому вы добавляете базу
в этот инструмент,

после чего люди могут решить,

добавлять или не добавлять
отдельные утверждения.

Отображение координат в виде карт --

в основном, функция для удобства,

но она также полезна
для контроля качества.

Например, если вы видите, что здесь
должен быть офис Викимедиа Германии,

а координаты
где-то в Индийском океане,

то вы понимаете, что это неверный адрес,

и вам легче это заметить,
чем если бы у вас были только цифры.

Этот инструмент -- индикатор
относительной полноты.

Вот эта маленькая иконка здесь,

которая сообщает, насколько полно
описан конкретный элемент,

и каких свойств не хватает.

Это очень полезно,
если вы редактируете элемент

и не очень ориентируетесь в данной сфере

и не знаете,
какие свойства нужно указывать,

тогда этот инструмент будет очень полезен.

Также мы используем
инструмент Shape Expressions.

Думаю, Андра или Хосе
расскажут об этом больше,

но, по сути, это очень мощный способ
сравнения имеющихся данных со схемой,

например, какое утверждение

должны иметь определённые сущности,

с какими сущностями
они должны быть связаны

и как должны выглядеть.

Таким образом вы сможете
находить проблемы.

Я думаю... Нет, ещё не всё.

Integraality, или панель свойств.

На ней видны данные,
которые у вас уже есть.

Например, эти данные
из Вики-проекта о красных пандах,

и вы видите,

что у большинства красных панд
известен пол,

дата рождения зависит от зоопарка,

и у нас почти нет погибших панд,
что замечательно,

(смех)

потому что они такие милые.

Так что это тоже полезно.

Теперь о том, что ожидается.

Wikidata Bridge,
ранее известный как client editing

для редактирования Викиданных
прямо из карточек Википедии.

Это, с одной стороны,
позволит лучше контролировать данные,

так как их сможет увидеть
большее число людей,

и, мы надеемся, будет способствовать

более частому использованию
Викиданных в Википедии,

и это значит, большее число людей
сможет заметить,

что, например, некоторые данные устарели
и должны быть обновлены,

чем если бы они видели эти данные
только в Викиданных.

Также есть испорченные ссылки.

Идея в том, что если вы редактируете
значение утверждения,

вы также можете обновить и ссылки,

если это не просто опечатка
или что-то ещё.

Эти испорченные ссылки
сигнализируют редакторам

и дают возможность увидеть,
какие другие правки были сделаны,

где отредактировали значение утверждения,
но не обновили ссылку,

и вы можете всё подредактировать

и решить, следует ли ещё что-то делать,

или всё в порядке,
и ссылку обновлять не нужно.

Перейдём к подписанным утверждениям.

Я думаю, это связано с тем опасением,

что некоторые источники данных...

Есть утверждение, на которое ссылаются,
например, через ЮНЕСКО

или какое-то другое учреждение,

а потом кто-то неожиданно
вносит вандальные правки,

и они переживают, что это будет выглядеть,

как будто организация,
например, ЮНЕСКО, принимает эти правки.

В случае с подписанными утверждениями,

они могут криптографически
подписать эту ссылку,

и это не помешает её редактированию,

но если кто-то внесёт в утверждение
вандальные правки

или любые другие,
подпись будет недействительна,

и это уже не совсем то,
что утверждает организация.

Возможно, это хорошая правка,

и нужно просто переподписать
новое утверждение,

но, возможно, правку следует отменить.

Думаю, это будет увлекательно.

Citoid -- удивительная система,
которая есть в Википедии,

где вы можете вставить URL,
идентификатор или ISBN

или идентификатор Викиданных,
в общем, что угодно в визуальный редактор,

и это трансформируется
в красиво отформатированную ссылку,

которая содержит все нужные вам данные,
и ей легко пользоваться.

Для сравнения, если я хочу
добавить ссылку в Викиданных,

я обычно должен добавить URL ссылки,
название, строку с именем автора,

место и дату публикации,

даты получения --
по крайней мере, всё это --

и это очень утомительно,

а интеграция Citoid в Викибазу
должна помочь в этом.

Думаю, у меня всё.

Сейчас передаю слово Кристине.

(аплодисменты)

Как можно улучшить
управление качеством данных?

Привет, я Кристина.

Я научный сотрудник
Цюрихского университета

и активный член
швейцарского Вики-сообщества.

Когда мы вместе с Клаудией Мюллер-Бирн
отправляли наш доклад на WikidataCon,

мы хотели продолжить обсуждение,

начатое в этом году

на семинаре по качеству данных,
а также на нескольких сессиях Викимании.

В своём выступлении мы, в основном,
поделимся некоторыми соображениями

как сообщества, так и нашими,

и продолжим обсуждение.

Нам хотелось бы и дальше
активно общаться с вами.

Мы считаем, что очень важно

постоянно спрашивать
всех пользователей сообщества

о том, что им действительно нужно,
какие у них проблемы с качеством данных,

не только редакторов
но и людей, которые пишут код,

либо пользуются данными,

а также исследователей,
которые фактически используют

всю историю редактирования
для анализа происходящего.

Мы сделали обзор
примерно 80-ти инструментов,

существующих в Викиданных,

и привели их в соответствие
с разными показателями качества данных.

Мы увидели, что на самом деле

многие инструменты
отслеживают полноту,

а также некоторые из них поддерживают
взаимосвязи между данными.

Есть потребность в инструментах,
оценивающих разнообразие данных --

то, что мы можем иметь в Викиданных,

в особенности, этот принцип
разработки Викиданных,

в котором мы можем иметь
множественность --

разные утверждения
с разными значениями

из разных источников.

Поскольку это вторичный источник,
у нас нет инструментов,

сообщающих, сколько существует
множественных утверждений,

сколько из них мы можем улучшить
и каким образом,

и мы также точно не знаем,

в чём причина этой множественности.

На этих собраниях сообщества

мы обсуждали проблемы,
всё ещё требующие внимания.

Например, краудсорсинговые сообщества --

это очень хорошо,
потому что разные люди работают

с разными частями данных или графа,

у всех людей разные
фундаментальные знания.

Но на самом деле
очень трудно достичь однородности,

потому что люди используют
разные свойства по-разному,

и у них разные ожидания
от описаний сущностей.

Люди также сказали,
что им нужно больше инструментов,

которые дают лучший обзор
глобального статуса сущностей,

показывают, каких сущностей не хватает
с точки зрения полноты,

а также над чем сейчас работают люди.

Они также многократно упоминают
более тесное сотрудничество

не только между разными языками,
но и Вики-проектами

и различным платформами Викимедии.

Мы опубликовали все комментарии,
которые услышали во время этих обсуждений.

Вы можете посмотреть их,
пройдя по ссылкам в Etherpad,

а также на странице Викимании.

Некоторые новые решения

заключались в обмене лучшими практиками,

которые реализуются
в разных Вики-проектах,

но также людям нужны инструменты,
помогающие организовать работу в командах

или, по крайней мере,
понять, кто над этим работает.

Также люди упоминали,
что они хотят больше примеров

и шаблонов, которые помогут в работе.

У нас есть контакты

с организациями открытых
государственных данных

и, в частности,

я поддерживаю контакты
с кантоном и городом Цюрих.

Они очень заинтересованы в Викиданных,

потому что хотят, чтобы их данные
были доступны для всех

в таком месте, где люди
могут ознакомиться c этими данными.

Для них было бы действительно интересно

иметь какие-то качественные показатели

как в Вики, они уже есть,

но и в результатах SPARQL,

чтобы знать, доверять ли данным,
полученным от сообщества.

Они также хотят знать,

какие из их наборов данных
полезны для Викиданных,

и чтобы был такой инструмент,

который поможет им
оценивать это автоматически.

Им также нужна
какая-то методология или инструмент,

который бы помог им решить,

импортировать свои данные
или связывать их с Викиданными,

поскольку в некоторых случаях
у них есть свои наборы

связанных открытых данных,

поэтому они не знают,
публиковать эти данные

или создавать в наборах данных
ссылки на Викиданные

и наоборот.

Они также хотят знать, какие элементы
Викиданных ссылаются на их сайты.

Когда они делают такой запрос,

он остаётся без ответа
с истёкшим временем ожидания,

поэтому, возможно, нам действительно
стоит создавать больше инструментов,

которые помогут им получить
ответы на их вопросы.

Кроме того,

нам, вики-исследователям,

тоже иногда не хватает информации
в описаниях изменений.

Я помню, что когда
мы делали какую-то работу,

чтобы понять различное поведение

редакторов, ботов
или анонимных пользователей

с помощью инструментов,

нам действительно не хватало, например,

стандартного способа отслеживания
использования этих инструментов.

Есть несколько инструментов,
которые уже делают это,

например, PetScan и многие другие,

но, возможно, в сообществе
мы должны больше обсуждать,

как фиксировать более точное
происхождение данных.

Далее, мы полагаем,

что нужно подумать о более конкретных
показателях качества данных,

относящихся к связанным данным,
а не ко всем типам данных,

поэтому мы разрабатываем комплекс мер

для получения доступа
к приросту информации по ссылкам,

подразумевая то,

что когда мы связываем
Викиданные с другими наборами данных,

мы также должны думать о том,

сколько сущностей
получается в классификации,

описании и в словарях,
которыми они пользуются.

Просто для примера, что я имею в виду:

в нашем случае это будут Викиданные

или внешний набор данных,
который ссылается на Викиданные.

У нас есть сущность для человека
по имени Наташа Ной,

у нас есть принадлежность и другие вещи,

а затем мы ссылаемся на внешний источник,

и эта сущность с таким же именем,
но значение одно и то же.

Лучше сослаться на сущность
с другим действительным именем,

потому что имя этого человека
может быть написано двумя способами,

а также на другую информацию,
отсутствующую в Викиданных

или других наборах данных.

Лучше даже то,

что мы рассматриваем целевой набор данных,

что также существуют новые способы
классификации информации.

Не только то, что это человек,
но в другом наборе данных

сообщается, что это женщина,
или другая информация,

с которой классифицируется сущность.

В другом наборе данных
используются другие словари,

и это помогает при поиске информации.

Мы также считаем,

что можем более наглядно представлять
федеративные запросы,

потому что по журналу запросов,
предоставленному Малышевым и др.,

мы видим, что на самом деле
среди органических запросов

число федеративных запросов
очень небольшое.

На самом деле, федерация является

одним из ключевых преимуществ
наличия связанных данных,

так что, возможно, сообществу или людям,
которые пользуются Викиданными,

тоже нужно больше примеров.

Если мы посмотрим на список
используемых точек доступа,

он будет неполным,
у нас есть намного больше.

Эти данные были проанализированы
по запросам до марта 2018 года,

но мы должны проверить список
имеющихся объединённых точек доступа

и посмотреть,
действительно ли мы их используем.

У меня есть два вопроса к зрителям,

которые, возможно, мы впоследствии
можем использовать для обсуждения:

какие, на ваш взгляд, проблемы
с качеством данных нужно рассмотреть,

учитывая ваши потребности,

а также, где вам нужно
больше автоматизации --

при редактировании или патрулировании?

Это всё, большое спасибо.

(аплодисменты)

WikidataCon 2019
Викиданные и языки

Визуализация схемы сущности
и авторские инструменты

(Хосе Эмилио Лабра) Я расскажу
о некоторых инструментах,

которые мы разработали,

связанных с Shape Expressions.

Об этом я буду говорить.
Меня зовут Хосе Эмилио Лабра.

Все эти инструменты
были разработаны разными людьми,

в основном все они связаны
с сообществом W3C ShEx,

или сообществом Shape Expressions.

Первый инструмент -- RDFShape,
это общий инструмент,

потому что Shape Expressions
используется не только для Викиданных,

это язык для проверки RDF в целом.

Этот инструмент был разработан
в основном мной,

и это инструмент для проверки RDF.

Если вы хотите узнать о RDF
или проверить RDF

или точки доступа SPARQL
не только в Викиданных,

я советую вам пользоваться
этим инструментом.

В том числе и для обучения.

Я преподаю в университете

и пользуюсь им для обучения RDF
в своём веб-курсе по семантике.

Если хотите изучать RDF,
это хороший инструмент.

Например, это визуализация RDF-графа
с помощью этого инструмента.

Но прежде чем приехать сюда,
в прошлом месяце

я специально начал использовать
RDFShape для работы с Викиданными.

Инструмент называется WikiShape,
и вчера я подарил его Викиданным.

Что я сделал?

Я удалил всё,
что не связано с Викиданными,

добавил кое-что жёстко закодированное,

например, точку доступа SPARQL.

Но теперь меня попросили
сделать это и для Викибазы.

Это очень легко.

Этот инструмент WikiShape
достаточно новый.

Я думаю, что многие его функции работают,

но некоторые, возможно, не работают,

и если вы попробуете его
и захотите что-то улучшить,

пожалуйста, сообщите мне.

Здесь у нас скриншоты [неразборчиво],
но давайте попробуем.

Давайте посмотрим, работает ли он.

Во-первых, я должен выйти из...

Здесь.

Хорошо. Вот этот инструмент.

С помощью него вы можете,

например, проверить схемы сущностей.

Например, существует новое
пространство имён, начинающееся с «Е»,

и здесь, если вы начнёте писать,
например, «человек»...

Когда вы пишете,
автозаполнение позволяет проверить,

например, существуют ли
выражения формы для людей,

и вот здесь появляются выражения формы.

Как видите, в этом редакторе
есть подсветка синтаксиса.

Возможно, экран очень маленький.

Попробую увеличить.

Может, сейчас лучше видно.

Это редактор с подсветкой синтаксиса.

Для редактора используется
тот же исходный код,

что и для службы запросов Викиданных.

Так, например,
если вы наведёте мышкой сюда,

он покажет вам метки разных свойств.

Я думаю, это очень полезно,
потому что сейчас,

схемы сущностей в Викиданных --
это просто текст,

и я думаю, этот редактор намного лучше,
потому что у него есть автозаполнение,

и он также имеет...

Если вы, например,
хотите добавить ограничение,

вы пишете wdt:,

а затем начинаете писать auth,
нажимаете Ctrl+Space,

и он предлагает разные варианты.

Это похоже на службу запросов Викиданных,

но специально для выражений формы.

Так как я думаю,
что создание выражений формы

не сложнее,
чем написание SPARQL-запросов.

Хотя некоторые думают,
что это примерно одинаково по сложности.

Я думаю, это проще,
потому что Shape Expressions

был создан с целью облегчить работу.

Первое, что у вас есть -- это редактор

для выражений формы.

Здесь есть возможность,
например, визуализации.

Если у вас есть какое-то
выражение формы, например...

Думаю, written work -- хороший пример,

поскольку в нём есть взаимосвязь
между разными сущностями.

Вот UML-визуализация для written work.

Здесь легко увидеть разные свойства.

Когда вы делаете это совместно
с несколькими людьми,

они находят ошибки
в своих выражениях формы,

потому что так можно легко найти
недостающие свойства.

Есть ещё одна возможность проверки,

кажется, у меня она вот здесь.

Это было на какой-то вкладке,
возможно, я закрыл её.

Но вы можете, например,
нажать Validate entities.

Например,

Q42 сравнить с E42, схемой для авторов.

Думаю, можно попробовать
со схемой для людей.

А потом...

Это SPARQL-запрос,
и он занимает какое-то время,

например, сейчас сбой в сети, но...

Вы можете попробовать.

Давайте расскажем о других инструментах.

Если хотите попробовать
и у вас есть предложения, дайте мне знать.

Продолжим презентацию.

Это WikiShape.

Как я уже говорил,

Редактор Shape Expressions --
независимый проект на GitHub.

Вы можете использовать его
в своём проекте.

Если хотите использовать
инструмент Shape Expressions,

вы можете просто встроить его
в любой другой проект,

его можно найти на GitHub,
и им можно пользоваться.

Тот же автор, один из моих учеников,

также создал редактор
для Shape Expressions,

вдохновившись
службой запросов Викиданных.

Этот редактор более наглядный
для SPARQL-запросов,

куда вы можете загрузить подобные вещи.

Это снимок экрана.

Как видите, выражения формы
здесь в виде текста.

Но здесь они на базе форм,
и, вероятно, потребуется больше времени,

но вы можете вставлять
разные строки в разные поля.

Это ShExEr.

Его сделал аспирант
Университета Овьедо,

он сегодня здесь,
и расскажет вам о ShExEr.

(Данни) Привет, я Данни Фернандес,

аспирант Университета Овьедо,
работаю с Лаброй.

У нас заканчивается время,
поэтому давайте ускоримся.

Я покажу несколько скриншотов
вместо всей презентации.

Обычный способ работы с Shape Expressions
или любым подобным языком:

есть специалист,

который определяет,
как должен выглядеть граф,

определяет структуры,

а затем вы используете эти структуры
для проверки фактических данных.

Инструмент, о котором рассказал Лабра, --

общего назначения
для любого RDF-источника,

и он может работать
в обратном направлении.

У вас уже есть некоторые данные,

вы выбираете узлы,
форму которых хотите получить,

а затем автоматически
извлекаете или выводите форму.

Несмотря на то, что это инструмент
общего назначения,

мы сделали волшебную кнопку
для этой конференции,

и если вы нажмёте на неё,

появятся параметры конфигурации,

и он настроит работу
с точкой доступа Викиданных,

простите, он скоро закончит.

После нажатия этой кнопки
вы, по сути, получаете это.

Выбрав необходимые вам узлы

или экземпляры класса,

что бы вы ни искали,

вы получите автоматическую схему.

Все ограничения отсортированы
по количеству узлов,

можно отфильтровать
наименее распространённые и так далее.

Внизу есть плакат об этом материале,

я буду на нижнем и верхнем этажах,

а также в других местах,

поэтому если у вас будет интерес
к этому инструменту,

просто обращайтесь ко мне.

Отдаю микрофон Лабре, спасибо.

(аплодисменты)

(Хосе) Давайте обсудим
другие инструменты.

ShapeDesigner -- ещё один инструмент.

Андра, хочешь рассказать о ShapeDesigner

или позже на семинаре?

Сегодня будет семинар,
посвящённый Shape Expressions,

мы попробуем его на практике,

так что если хотите попрактиковаться
с ShEx, то вам сюда.

Это инструмент ShEx.js,

и Эрик может рассказать о нём.

(Эрик) Расскажу очень быстро.

Вы, вероятно, уже видели интерфейс ShEx,

заточенный под Викиданные.

Его сократили и адаптировали
специально под Викиданные

потому что в нём больше возможностей,

но я, кажется, говорил об этом,

потому что одна из этих функций
особенно полезна

для отладки схем Викиданных.

Если вы выбираете полный режим,

то пока я буду проводить проверку

всех этих триплетов,

и если я получу множество ошибок,

я могу пройтись по этим ошибкам

и посмотреть, какие триплеты здесь, внизу.

Это просто журнал того,
как всё происходило.

Затем можете поиграть с этим,

чтобы поменять что-либо.

Это более быстрая версия
того, как это сделать.

Это форма ShExC --

то, что предлагал Йохим,

что может быть полезно
для заполнения документов Викиданных

на основе выражения формы
для этого документа.

Она не адаптирована под Викиданные.

Я просто показываю,
что можно взять схему,

сделать аннотации,

чтобы конкретно указать,
какую схему вы хотите,

потом просто создать форму

и, если у вас есть данные,
можно заполнить форму.

PyShEx [неразборчиво].

(Хосе) Думаю, это последний инструмент.

Да, это PyShEx.

PyShEx -- это Shape Expressions,
реализованный на Python,

он совместим с Jupyter Notebooks.

Итак, это всё.

(аплодисменты)

(Андра) Итак, я расскажу
о конкретном проекте,

в котором участвую -- Gene Wiki,

и в котором мы тоже занимаемся
вопросами качества.

Прежде чем говорить о качестве,

я кратко расскажу вам о Gene Wiki.

Мы только что выпустили
предварительную версию статьи,

в которой описаны детали проекта.

Я вижу, люди фотографируют...

Gene Wiki публикует в Викиданных

общедоступные биомедицинские данные,

используя для этого определённый шаблон.

Если у нас появляется
новое хранилище или набор данных,

который можно включить Викиданные,

первый шаг -- вовлечение сообщества.

Необязательно сообщества Викиданных,

но местного исследовательского сообщества.

Мы встречаемся лично,
онлайн или на любой платформе

и пробуем придумать модель данных,

которая соединит их данные
с моделью Викиданных.

Вот фотография прошлогоднего семинара,

на котором мы анализировали
определённый набор данных,

и как видите, было много обсуждений,

затем приведение его
в соответствие с schema.org

и другими существующими онтологиями.

В конце первого шага
у нас на доске появился чертёж схемы,

которую мы хотим добавить в Викиданные.

Вы видите, она несложная,

на заднем плане,

и мы можем построить какие-то схемы
даже здесь, в рамках этой дискуссии.

Если у нас есть схема,

следующий шаг -- попытаться сделать
эта схему машиночитаемой,

чтобы иметь работающие модели
для переноса внешних данных

из любой медико-биологической
базы данных в Викиданные.

Здесь мы применяем
инструмент Shape Expressions,

поскольку он позволяет проверить,

является ли набор данных...
Сначала увидеть,

что уже существующие данные в Викиданных
следуют той же модели данных,

которая была получена
в предыдущих процессах.

С помощью Shape Expressions
мы можем проверить,

требуется ли корректировка данных
по этой теме в Викиданных,

нужно ли адаптировать нашу модель
к модели Викиданных или наоборот.

Как только всё на месте,
мы начинаем писать ботов,

а боты загружают информацию

из первоисточников в Викиданные.

Когда боты готовы,

а мы пишем их на платформе
WikidataIntegrator,

используя библиотеку Python,

которая появилась
в результате нашего проекта.

Когда боты написаны,
мы используем платформу Jenkins

для непрерывной интеграции.

С помощью Jenkins

мы постоянно обновляем
первоначальные источники с Викиданными.

Вот диаграмма, о которой я говорил ранее.

Это её текущий вид.

Оранжевые прямоугольники --
первоисточники медикаментов,

белков, генов, заболеваний,
химических соединений, со взаимосвязями,

но её невозможно прочитать сейчас,
поскольку она слишком маленькая,

но это база данных, источниками которых
мы управляем в Викиданных

и соединяем с первоисточниками.

Так выглядит наш рабочий процесс.

Один из наших партнёров --
онтология заболеваний.

Онтология заболеваний имеет лицензию CC0,

и такая онтология
имеет свой цикл курирования.

Онтология заболеваний
постоянно обновляется,

чтобы отразить базу заболеваний
или их объяснение.

Здесь изображён цикл курирования
Викиданных по заболеваниям,

где сообщество постоянно следит за тем,
что происходит с Викиданными.

Есть две роли.

Мы упрощённо называем их
хранитель-куратор,

и это были я и мой коллега пять лет назад.

Мы просто сидели за компьютерами
и мониторили Википедию и Викиданные,

и если была проблема, мы сообщали о ней
первоначальному сообществу,

первоначальным источникам,
они смотрели на реализацию и решали,

доверять ли данным,
введённым в Викиданные.

Если да, начинался цикл

и следующий шаг --
часть онтологии заболеваний

возвращалась в Викиданные.

Для WikiPathways мы делаем то же самое.

WikiPathways -- база данных
биологических путей,

вдохновлённая MediaWiki.

В Викиданных уже существуют
различные источники путей.

Между ними могут возникать конфликты,

и хранителям-кураторам
сообщается об их возникновении,

и вы управляете индивидуальными
циклами курирования.

Но если вы помните предыдущий цикл,

где речь велась
только о двух циклах, двух ресурсах,

нам нужно делать это
для каждого имеющегося ресурса

и нужно управлять происходящим,

потому что под курированием

я подразумеваю постоянное отслеживание
страниц Википедии и Викиданных.

Такая работа явно не для двух
хранителей-кураторов.

На конференции в 2016 году,

когда Эрик рассказывал
о Shape Expressions,

я присоединился, и подумал,

что Shape Expressions может помочь
выявить различия в Викиданных,

которые помогут хранителям
делать более подробные отчёты.

В этом году я был в восторге
от схемы сущности,

потому что теперь мы можем хранить
эти схемы в Викиданных,

до этого мы хранили их на GitHub.

Схема согласуется
с интерфейсом Викиданных,

здесь есть обсуждение документа,

но также доступны правки.

Вы можете пользоваться
первыми страницами

и правками в Викиданных,

чтобы обсуждать то,
что имеется в Викиданных

и первоначальных источниках.

Эрик уже об этом говорил,
это очень помогает.

Мы создали выражение формы
для гена человека,

потом пропустили его через ShEx,
как вы видите,

мы получили...

Есть один элемент,
за которым нужно следить, --

он не вписывается в эту схему,

и затем вы можете создать
сущности схемы, отчёты курирования,

и отправить их в разные отчёты.

Но ShEx -- это встроенный интерфейс,

и здесь я смогу показать только десять,

но у нас десятки тысяч,
и они несоизмеримы.

Интегратор Викиданных
теперь поддерживает ShEx,

и мы просто можем замкнуть
петли элементов,

указав «да-нет, да-нет,
правда-ложь, правда-ложь».

снова,

повышая эффективность
при составлении отчётов.

Но с недавних пор он строится
на сервисе запросов Викиданных,

мы недавно регулировали
количество запросов,

и это тоже несоизмеримо.

Работа с моделями на Викиданных --
непрерывный процесс.

ShEx не только пугает,

но он ещё и громоздкий.

Я начал работать,

это мой первый эксперимент или упражнение,

где был использован инструмент yEd,

и затем я начал отрисовывать
эти выражения формы,

и потом регенерировать эту схему

в формат, близкий к Shape Expressions,

понятный людям,

которых слишком пугает
язык Shape Expressions.

Но есть проблема с визуальным описанием,

потому что это также схема,
кем-то нарисованная в yEd.

Вот ещё одна, замечательная.

Я бы такую себе на стену повесил,

но она пока несовместима.

Хочу завершить своё выступление слайдом,

который я позаимствовал.

Для меня честь показать его аудитории.

Он мне очень нравится:

«Люди думают, что RDF -- это боль
из-за его сложности.

Но на самом деле всё ещё хуже.

RDF очень прост, но он позволяет работать
с реальными данными

и невероятно сложными проблемами.

Можно избежать использования RDF,

но вряд ли получится избежать
сложных данных и компьютерных проблем».

Речь об RDF, но, я думаю,
подходит под моделирование в целом.

Мой вопрос -- должны ли мы...

Как мы будем моделировать?

Поговорим о ShEx,
или визуальных моделях, или...

Как нам продолжить?

Спасибо за уделённое время.

(аплодисменты)

(Лидия) Спасибо большое.

Можете выйти вперёд,

чтобы аудитория могла задать вопросы.

Есть вопросы?

Да.

Думаю, для камеры нужно, чтобы...

(Лидия смеётся) Да.

(голос из зала 1) Вопрос Кристине, думаю.

Вы упоминали термин «прирост информации»

от объединения с другими системами.

Существует информационно-теоретический
показатель -- прирост информации,

основанный на статистике и вероятности.

Вы имели в виду именно этот показатель?

Прирост информации
на основе теории вероятности,

теории информации,

или просто такая концептуальная идея
для измерения прироста информации?

Нет, мы действительно
определили и применили показатели,

используя энтропию Шеннона,
поэтому смысл именно такой.

Не хочу вдаваться в детали
конкретных формул...

(голос из зала 1) Нет, конечно,
поэтому и прозвучал вопрос.

- (Кристина) Да.
- (голос из зала 1) Спасибо.

(голос из зала 2) Это больше
комментарий, нежели вопрос.

(Лидия) Да, конечно.

(голос из зала 2) Акцент был на элементах,

на их качестве и полноте,

но меня беспокоит,
что мы не применяем это к иерархиям,

и наша частая проблема -- плохая иерархия.

Мы видим, что это становится
реальной проблемой

при обычным поиске и других вещах.

Мы можем импортировать способ,

по которому внешние тезаурусы
выстраивают свои иерархии,

используя квалификатор P4900,
более широкое понятие.

Но я думаю, для этого есть
более подходящие инструменты,

и вы сможете импортировать
иерархию внешнего тезауруса,

отобразить её на элементы Викиданных.

И связав её с этими квалификаторами P4900,

вы можете делать
хорошие запросы через SPARQL,

чтобы увидеть, где наша иерархия
расходится с внешней.

Например, вы можете знать
[Паолу Морма], под псевдонимом PKM,

этот пользователь
создаёт много статей о моде.

Мы включаем их в иерархию
тезауруса европейской моды

и в иерархию тезауруса
искусства и архитектуры,

а потом мы видим, какие пробелы
были в элементах более высокого уровня.

Для нас это реальная проблема,
потому что часто попадаются вещи,

которые существуют в Википедии
только как страницы значений,

многие элементы более высокого уровня
отсутствуют в наших иерархиях,

и мы должны рассмотреть это
с точки зрения качества и полноты,

но что действительно поможет,
станет лучшим инструментом,

чем те дебри скриптов, написанных мной, --

если бы кто-то поместил это
в PAWS notebook на Python,

чтобы можно было извлечь
внешний тезаурус, взять его иерархию,

которая может быть доступна
как связанные данные или же нет,

чтобы поместить это в QuickStatements,
чтобы вставить значения P4900.

Затем позже,

когда наше представление
станет более сложным,

обновить эти значения P4900,
потому что добавляются данные,

представление становится
более комплексным,

значения этих квалификаторов нужно менять,

чтобы показать, что в нашей системе
всё больше их иерархии.

Если бы кто-то мог сделать это,
думаю, это было бы очень полезно,

и мы должны рассмотреть
и другие подходы

для улучшения качества и полноты
на уровне иерархии,

а не только на уровне элемента.

(Андра) Могу я кое-что добавить?

Да, и мы это делаем,

и я рекомендую посмотреть
на выражение формы, которое сделал Финн

с лексическими данными,

где он создаёт выражения формы,

а затем опирается
на другие выражения формы,

так получается концепция
связанных выражений формы в Викиданных.

В частности, пример использования,
если я правильно понимаю --

это именно то, что мы делаем в Gene Wiki.

Есть онтология заболеваний,
которая помещена в Викиданные,

а затем поступают данные о заболевании,
и мы применяем Shape Expressions,

чтобы посмотреть,
соответствуют ли данные тезаурусу.

Есть и другие тезаурусы или другие
онтологии или контролируемые словари,

которые ещё должны войти в Викиданные,

и именно поэтому инструмент
Shape Expressions так интересен --

вы можете применять его
для онтологии заболеваний,

для MeSH.

Теперь вам нужно проверить качество.

Потому что в Викиданных
также есть контекст,

когда у вас есть контролируемый словарь,
вы считаете, что качество соответствует,

но могут быть случаи,
когда сообщество не согласно.

Инструмент уже есть,
но теперь нужно создать эти модели

и применять их для разных случаев.

(голос из зала 2)
Shape Expressions очень полезен,

если у вас уже есть внешняя онтология,
которая отображается в Викиданных,

но моя проблема в том,
что всё доходит до той стадии,

когда выясняется, какой части
внешней онтологии ещё нет в Викиданных,

и где есть пробелы,

и, я думаю, в этом случае иметь
более надёжные инструменты,

чтобы увидеть, чего не хватает
из внешних онтологий,

было бы очень полезно.

Самая большая проблема

не в инструментах, а в лицензировании.

Поместить онтологии в Викиданные
на самом деле очень просто,

но большинство онтологий имеют,
как я это вежливо называю,

ограниченное лицензирование,
поэтому они не совместимы с Викиданными.

(голос из зала 2) Есть множество
тезаурусов из государственного сектора

в сфере культуры.

- (Андра) Тогда нам нужно поговорить.
- (голос из зала 2) Это не проблема.

(Андра) Тогда поговорим.

(голос из зала 3) Мой комментарий --
на самом деле ответ Джеймсу.

Дело в том, что из иерархий
получаются графы,

и когда ты хочешь...

Я хочу в основном поговорить
об общей проблеме в иерархиях --

о циклических иерархиях,

они возвращаются друг к другу,
когда есть проблема,

которой в иерархиях не должно быть.

Это, как ни странно,
часто встречается в категориях Википедии

у нас много циклов в категориях,

но хорошая новость в том, что это...

Технически, это NP-полная задача,

и вы не можете найти её,

но легко найдёте, построив граф.

Но было разработано много способов

для нахождения проблем
в этих иерархических графах.

Есть такая статья...

о разрыве циклов в искажённых иерархиях,

и перечисленные в ней методы помогли
при категоризации английской Википедии.

Вы можете просто применять
эти иерархии в Викиданных,

а затем найти

и просто удалить то,
что вызывает проблемы,

и на самом деле найти проблемы.

Это просто идея.

(голос из зала 2)
Это всё очень хорошо,

но я думаю, вы недооцениваете количество
плохих связей между подклассами,

которые у нас имеются.

Это как город, который находится
совершенно не в той стране,

при том, что существуют
географические инструменты

для определения этой проблемы.

Нам в иерархиях нужны
более эффективные инструменты,

которые смогут определить,
где эквивалент элемента для страны

полностью отсутствует,
или где он является подклассом чего-то,

не имеющего к нему отношения.

(Лидия) Я думаю, вы подобрались к тому,

что мы с моей командой
постоянно слышим от людей,

которые многократно
используют наши данные.

Отдельная точка данных -- это отлично,

но если вам нужно посмотреть
на онтологию и так далее,

то становится очень...

Я думаю, одна из больших проблем,
почему это происходит --

множество правок в Викиданных

касаются отдельного элемента,

вы редактируете этот элемент,

не понимая, что это может привести
к глобальным последствиям

для остальной части графа, например.

Если у людей есть идеи,
как сделать более заметными

последствия таких индивидуальных
локальных правок,

думаю, что их стоит изучить,

чтобы лучше показать людям
последствия их правок,

сделанных с добрыми намерениями,

какие они.

Ого! Хорошо, давайте начнём с вас,
потом вы, потом вы, затем вы.

(голос из зала 4) После обсуждения,

просто чтобы выразить своё согласие
с тем, что говорил Джеймс.

По сути, кажется,
что самая опасная вещь -- иерархия,

не иерархия, но в целом

семантика связей
между подклассами в Викиданных.

Я недавно изучал языки,
только для этой конференции,

и, например, я нашёл много случаев,

когда язык является одновременно
и частью и подклассом одного и того же.

Можно сказать, что у нас гибкая онтология.

Викиданные дают свободу выражения.

Потому что, например,

эта онтология языков сложна
с политической точки зрения.

Даже хорошо иметь возможность
выразить уровень неопределённости.

Но представьте, как к этому
применить машинное чтение.

Действительно проблематично.

И опять же,

я не думаю, что онтология
была импортирована откуда-либо.

Она изначально наша.

Она с самого начала собрана из Википедии.

Так что мне интересно...
Shape Expressions -- отличный инструмент,

который проверяет и исправляет
онтологию Википедии

с помощью внешних ресурсов,
прекрасная идея.

В конце концов,

получится ли у нас отразить
внешние онтологии в Викиданных?

А также, что мы делаем
с основной частью нашей онтологии

которая никогда не собирается
из внешних ресурсов,

как нам исправить её?

Я действительно думаю,
что это само по себе будет проблемой.

Мы должны сосредоточиться на этом
независимо от идеи проверки онтологии

с помощью внешнего ресурса.

(голос из зала 5) Ограничения
и формы очень впечатляют,

то, что мы можем сделать с ними,

но главный момент
до сих пор не совсем понятен --

поскольку теперь мы можем более чётко
сформулировать, чего ожидаем от данных.

Сначала каждый должен написать
свои инструменты и скрипты,

сделать их более наглядными,
и мы сможем обсудить это.

Но речь не о том, что верно, а что нет,

а об ожиданиях,

и у вас будут разные ожидания и обсуждения

того, как моделировать в Викиданных.

Текущее состояние --
лишь один шаг в этом направлении,

потому что теперь нужно

привлечь много технических знаний,

и нам нужны лучшие способы
визуализации этого ограничения,

возможно, преобразование его
в более понятный людям язык,

но в меньшей степени здесь речь о том,
что верно, а что нет.

(Лидия) Да.

(голос из зала 6) По поводу качества,
хочу уточнить...

Я часто сталкивался с разногласиями,

связанными с разницей между
экземпляром и подклассом.

Я бы сказал, ошибки в таких ситуациях

и попытки найти их
были очень трудоёмким процессом.

То, к чему я пришёл:

«Если найти впечатляющие элементы, важные,

и затем использовать
все экземпляры подкласса,

чтобы найти все производные
этого утверждения», --

это очень полезный способ
поиска ошибок.

Но мне было интересно,

можно ли использовать Shape Expressions

в качестве инструмента
для решения таких проблем?

(голос из зала 7)
Имеет ли структурный след ...

Если имеется структурный след,
который может быть сфальсифицирован,

можно решить, что это неправильно,

а потом сделать это.

Но если это просто попытка сопоставления
с объектами реального мира,

то вам потребуется очень много «мозгов».

(голос из зала 8) Привет,
я Пабло Мендес из Apple Siri Knowledge.

Мы здесь, чтобы узнать,
как помочь проекту и сообществу,

но Кристина совершила ошибку,
спросив, чего мы хотим.

(смеётся) Думаю, одна вещь,
которую хотелось бы увидеть,

связана с возможностью проверки --

одним из основных принципов
проекта в сообществе,

а также с доверием.

Не все утверждения одинаковы,
некоторые из них серьёзно оспариваются,

некоторые легко предположить,

например, чью-либо дату рождения
можно проверить,

как вы видели сегодня в основном докладе,
гендерные проблемы намного сложнее.

Можете ли вы немного
рассказать о том, что вы знаете

о доверии и проверках --
этих аспектах качества данных?

Если этого не много,
хотелось бы намного больше. (смеётся)

(Лидия) Да.

Как выяснилось,
нам нечего сказать. (смеётся)

(Андра) Я думаю, мы можем сделать многое,
но у нас с вами вчера была дискуссия.

Мой любимый пример,
как я выяснил вчера, уже устарел.

Если вы зайдёте
на страницу элемента Q2, это Земля,

там есть утверждение, что Земля плоская.

Я люблю этот пример,

потому что есть сообщество,
которое это утверждает,

и у них есть достоверные источники.

Так что я думаю, это реальный случай,

его не нужно оспаривать,
он должен быть в Викиданных.

Я думаю, здесь Shape Expressions
может быть действительно полезен,

потому что вам действительно
может быть интересен этот прецедент,

или этот вариант использования,
с которым вы не согласны,

но может быть и такой
случай применения,

который вас заинтересует.

Например, глюкоза.

Биологу не интересно

строение молекулы глюкозы,

для него вся глюкоза одинаковая.

Но химика подобное покоробит,

существует 200 с лишним...

Когда у вас есть разные выражения формы,

я могу их применить с точки зрения химика.

А с точки зрения биолога

я применяю другое выражение формы.

А если вы хотите сотрудничать,

вы должны сказать Эрику о картах ShEx.

Но это только начало пути.

Но я лично верю,
что это весьма полезно для этой области.

(Лидия) Вон там.

(смех)

(голос из зала 9) У меня несколько идей
по некоторым моментам обсуждения,

постараюсь озвучить все.
Было три идеи, так что...

Основываясь на том, что Джеймс сказал
некоторое время назад,

у Викиданных с самого начала
была очень большая проблема

в онтологии вышестоящего уровня.

Мы говорили об этом
два года назад на WikidataCon,

и мы говорили об этом на Викимании.

На всех встречах по Викиданным

мы говорим об этом,

потому что это очень большая проблема
на очень высоком уровне --

что такое сущность, работа,
что такое жанр, искусство, --

все эти понятия очень важны.

И на самом деле это слабое место
глобальной онтологии,

потому что люди регулярно наводят порядок

и тем самым всё ломают.

Некоторые из вас помнят парня,
который из добрых намерений

«сломал» все города мира.

Элементы стали не географическими,
везде были нарушения ограничений.

Это было сделано из добрых побуждений,

ведь он действительно
исправлял ошибку в элементе,

но всё сломалось.

Я не уверена, как мы можем решить это,

поскольку нет ни одного
внешнего учреждения,

у которого мы могли бы скопировать,

потому что все работают...

Если я работаю с базой данных
исполнительского искусства,

я просто перейду на уровень
исполнительского искусства,

я не буду переходить
к философской концепции сущности,

и это, на самом деле...

Я не знаю ни одной базы данных,
работающей на этом уровне,

но это самое слабое место Викиданных.

Вероятно, когда мы говорим
о качестве данных,

это является важным аспектом.

Я думаю, это то же самое,
что мы заявили...

Простите, я меняю тему,

но на разных сессиях
мы говорили о качестве.

На самом деле некоторые из нас
могут хорошо моделировать,

работают с ShEx и так далее.

Люди не видят этого в Викиданных,
они не видят ShEx,

они не видят Вики-проект
на странице обсуждения,

и иногда

они даже не видят
страницы обсуждения свойств,

которые чётко заявляют,
для чего используется конкретное свойство.

Например, на прошлой неделе,
я добавила ограничение для свойства.

Ограничение было чётко прописано

в обсуждении создания свойства.

Я просто добавила ограничение,
а кто-то возмутился:

«Что? Ты сломала все мои правки!»

Последние два года человек использовал
это свойство неправильно.

Свойство было очень чёткое,
но не было никаких предупреждений,

как и в Pink Pony,

мы также сказали на Викимании,
что хотим делать Вики-проекты

более наглядными,
делать ShEx более наглядным, но...

Это то, что сказала Кристина.

У нас проблема с визуализацией
существующих решений.

На этой сессии

мы все говорим о том,
как создать больше выражений формы,

или облегчить работу редакторов.

Но мы наводим порядок
с первого дня существования Викиданных,

и, на глобальном уровне, мы проигрываем,

поскольку, насколько я знаю,
имена сложные,

но я единственная, кто их редактирует.

Кто-то добавил имя на латинице

всем китайским исследователям --

мне понадобятся месяцы,
чтобы убрать это, и сама я не справлюсь,

а он сделал массовую выгрузку.

Проблем с визуализацией больше,
чем с инструментами, я думаю,

поскольку у нас много инструментов.

(Лидия) К сожалению,
мне дали знак, (смеётся),

поэтому нам нужно заканчивать.

Большое спасибо за ваши комментарии,

надеюсь, вы продолжите обсуждение позже,

и спасибо за ваш вклад.

(аплодисменты)

WikidataCon 2019
Викиданные и языки