Семантические сети *

Тому, кто попытается использовать точку доступа SPARQL в качестве замены базы данных в каком-нибудь индустриальном проекте, придется столкнуться с несколькими неприятностями. Одна из них — отсутствие в арсенале средств такого продукта контроля прав доступа, триггеров, и возможностей организации версионности. Изучив все, что предлагается на рынке сегодня, мы пришли к необходимости реализовать такой функционал собственными силами.
В качестве «подопытного кролика» выступает Apache Fuseki, хотя тот же принцип можно применить к любой другой SPARQL endpoint.

По сути, опубликованное ниже является моим комментарием к публикации «Что такое «Понятный русский язык» с точки зрения технологий. Заглянем в метрики удобочитаемости текстов». Поскольку я не могу оставлять комментарии, то пишу в «Песочницу».

Критерии оценки понятности текстов, которые были рассмотрены в посте, опираются на практически нулевые знания о языке, на котором эти тексты написаны: достаточно знать, как он делится на слова и предложения. Этот подход удобен в плане простоты вычислений, но не позволяет использовать много релевантных данных. Как мне кажется, в случае с русским языком очевидно, что еще можно использовать, и эти данные легкодоступны.

Так сложилось что в последние годы мне лично приходится всё больше и больше сталкиваться с различными государственными текстами, особенно законами и финансовыми документами вроде обоснований к бюджету, а также пытаться их переводить с нечеловеческого канцелярского языка в слова или визуальные схемы которые были бы понятны и мне и тем кому я потом рассказываю о том что это такое.



За всё это время у меня лично сложилось стойкое ощущение того что русский язык разделился на два его подвида — сухой канцелярский юридический официальный язык и «язык Интернета», с ново-образованными словами, жаргонизмами и значительной персонификацией. Вместе с постоянным чувством что «так дальше жизнь нельзя» всё это привело меня, вначале к поискам правильного названия того как это всё называется, а далее к тому что с этим могут делать люди умеющие программировать.

Немного истории

18 января 2011 года, Президент Обама выпустил новый указ, Executive Order, «E.O. 1356 — Improving Regulation and Regulatory Review» («Улучшение регулирования и рассмотрению вопросов регулирования»). В нем говорится, что "[наша система регулирования] должна обеспечить, чтобы правила были доступны, согласованы, написаны простым языком, и легко понимаемы.".

Написанное простым (понятным) языком — это отнюдь не расхожий термин и не оборот речи. Это сформулированные за десятилетия подход по переводу официальных текстов, документов, речей политиков, законов и всего что наполнено официальным смыслом, в форму понятную простым смертным.

Понятный язык — это четкое, краткое написание предназначенное для того чтобы читатель понимал текст, как можно быстрее и как можно полнее. В нем избегаются избыточная подробность, запутанность речи и жаргон.

Работа нашей фирмы связана с разработкой под Microsoft Outlook и Exchange Server, и поэтому копаться в них мы очень любим. Сегодня мы будем копать маленькую новую фишечку Microsoft Outlook — напоминалку о забытых вложениях. Казалось бы, что может быть проще? Тексты наших «раскопок» на английском языке мы публикуем в блоге компании, а на русском — эксклюзивно для Хабра. Поехали!

Начиналось все с простой потребности в наведении порядка в файлах. Почему уже 2014 год, а до сих пор нет простого и удобного редактора деревьев хотя бы?
Текстовых редакторов — несметное множество и все равно появляются новые. Редакторов таблиц — поменьше, но жаловаться приходится только когда количество данных исчисляется тысячами.
А ведь самих-то способов представления информации не так много:
Строка, Список, Таблица, График, Диаграмма, Карта, 3d
Разумеется, есть огромное множество разновидностей этих видов, но количество достаточно популярных не превышает десятка.
По своей сути эти способы можно подразделить по количеству одновременно отображаемых характеристик.
Одномерные: список, временная шкала, хронометраж и т.п.
Двумерные: таблица, карта, график, гистрограмма и т.п.
Трехмерные: в основном нестандартные сложные научные 3d-визуализации
Многомерные: деревья, графы, сети

Визуализаций данных уже создано в избытке и продолжают изобретать новые. Для одних только деревьев известно под 3 сотни вариантов: treevis.net
А вот редакторы существуют для весьма малого количества самых популярных.
И в отношении многомерных данных существует огромный пробел.

Итак, как и обещали, рассказываем: недавно были подведены итоги соревнований по автоматическому разрешению анафоры и кореферентности. Такие соревнования для русского языка проводились впервые а организовала их команда из ВШЭ-МГУ.

Мы уверены, что среди наших читателей много лингвистов, которые и без нас отлично знают, что такое анафора и кореференция, остальным рассказываем. Один и тот же объект реального мира может упоминаться в тексте несколько раз разными способами. «Вася – миллионер, он хочет купить остров». В этой фразе местоимение «он» и существительное «Вася» относятся к одному человеку (т.е. имеют одного и того же референта). Если система анализа текста понимает, что «он» – это и есть «Вася», значит, она умеет разрешать анафору.

Сложнее, когда Вася появляется в тексте еще несколько раз – например, как «Иванов», «клиент», «глава компании» или «футболист». Тогда речь идет уже не о местоименной анафоре, а о кореферентности именных групп. Задача системы в этом случае – объединить все слова, за которыми скрывается этот человек, в одну кореферентную цепочку. Приведем несколько примеров, а заодно покажем, как это делает наша технология Compreno.

Этим постом я хочу привлечь внимание к интересной области прикладного программирования, бурно развивающейся в последние годы — компьютерной лингвистике. А именно — системам, способным к разбору и пониманию текста на русском языке. Но основной фокус внимания я хочу сместить с академических и промышленных систем, в которые вложены десятки и тысячи человеко-часов, к описанию тех способов, какими успехов на этом поприще могут добиться любители.

Сегодня в продолжение наших рассказов о семантической разметке я хочу рассказать о её синтаксисе. То, почему он такой, а не иной, часто определяется историческими причинами, а иногда — ещё и комично. Поэтому мы попробовали здесь всё систематизировать и объяснить.

Сначала пару слов, чтобы все понимали, что есть что. Под микроразметкой в целом (или семантической разметкой) мы подразумеваем разметку страницы с дополнительными тегами и атрибутами в тегах, которые указывают поисковым роботам на то, о чем написано на странице.

Словарь — это своеобразный «язык», набор классов и их свойств, с помощью которых указывается суть содержимого на странице. О них мы писали в предыдущей статье. Синтаксис — это способ использования словаря. Он определяет, с помощью каких тегов и как будут указываться сущности и их свойства, например, на веб-страницах.

Стандартов синтаксиса, как и словарей, несколько. В этой статье мы и разберем на практических примерах наиболее распространенные:

• Microdata — Микроданные (словарь Schema.org чаще всего встречается именно в этом синтаксисе);
• Microformats.org — Микроформаты (напоминаем, что это объединенный стандарт синтаксиса и словаря);
• RDFa и RDFa Lite (в упрощенном виде RDFa рекомендуется создателями словаря Open Graph. Также встречается с другими словарями, например, со словарем Dublin Core или Data Vocabulary);
• JSON-LD — расширение JSON.

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

Once upon a time В 2004 году разработчики из W3C создали стандарт, который, по их мнению, подходил для «представления всего в мире». Так появился синтаксис RDFa (Resourse Description Framework in attributes), который позволяет однозначно транслировать HTML-разметку с семантическими данными в RDF.

По поручению известного автора Дмитрия Ландэ (например, «Поиск знаний в Internet», Интернетика. Навигация в сложных сетях: модели и алгоритмы) публикую одну из последних его работ.

В настоящее время актуальными являются задачи построения онтологий по определенным областям знаний. Очевидно, построение большой отраслевой онтологии – сложная проблема, которая требует больших ресурсных затрат. В любом случае, определенным этапом построения общих онтологий является построение соответствующих тезаурусов, терминологических онтологий.

Я работаю в команде семантического веба в Яндексе. Мы занимаемся тем, что создаем продукты на основе семантической разметки, делаем свои расширения и участвуем в развитии стандарта Schema.org.

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



Под микроразметкой (или семантической разметкой) мы подразумеваем разметку страницы с дополнительными тегами и атрибутами в тегах, которые указывают поисковым роботам на то, о чем написано на странице.

Микроразметка состоит из словаря и синтаксиса.

Современные программы в значительной степени строятся из готовых кирпичиков — библиотек. Уникального кода и архитектурных решений в каждой программе относительно мало. Очень часто бывает, что существующие библиотеки не слишком высокого качества, но даже самый крутой программист не станет их переписывать.

Этот факт находит отражение и в изменении учебных курсов. Сассман, автор SICP, самого известного курса по программирование, сказал: " инженерное дело в середине 90-ых, а уж тем более в 2000-ых сильно отличается от инженерного дела 80-ых. В 80-ых хорошие программисты проводили много времени в размышлениях, а потом писали немного кода, который работал. Код работал близко к «железу», даже Scheme — все было прозрачно на всех стадиях. Как с резистором, достаточно посмотреть на цветную маркировку, чтобы узнать номинальную мощность, допустимые отклонения, сопротивление и V=IR — это все, что нужно знать. 6.001 был задуман как курс для обучения инженеров тому, как из маленьких кубиков, в которых они досконально разбираются, посредством простых техник составлять сложные конструкции, которые делают то, что от них хотят. Но программирование сейчас далеко не то же самое. Теперь вы ковыряетесь в непонятной или несуществующей документацией для софта, даже неизвестно, кем написанного. Вы должны досконально исследовать библиотеки, чтобы узнать, как они работают, пробовать разные исходные данные и смотреть, как реагирует код. Это в корне иная работа, и для нее требуется иной курс обучения."

Строительные кирпичики стандартизированы — каменщику обычно не приходится выбирать подходящий именно для этого места кирпич. С библиотеками все наоборот — то, что предназначено для обработки PDF не подойдет для создания распределенной вычислительной системы. Возникает потребность найти нужную библиотеку, в ней нужную функцию и понять, как ее встроить в свою программу. Google, как и любая другая ориентированная на естественный язык поисковая система пока помогает мало. Так что рассмотрим другие подходы.

Больше года назад Google объявил, что отныне в их поиске используется таинственная Сеть Знаний (официальный перевод Knowledge Graph). Возможно, не все знают, что значительная часть данных Сети доступна для использования всеми желающими и доступна по прекрасно описанному API. Этой частью является база знаний Freebase, поддерживаемая Google и энтузиастами. В этой статье мы сначала немного подурачимся, а потом попробуем сделать несколько простеньких запросов на языке MQL.
Эта статья — вторая из цикла Базы знаний. Следите за обновлениями.

• Часть 1 — Введение
• Часть 2 — Freebase: делаем запросы к Google Knowledge Graph
• Часть 3 — Dbpedia — ядро мира Linked Data
• Часть 4 — Wikidata — семантическая википедия

Одной из причин слабого использования Linked Data-баз знаний в обычных, ненаучных приложениях является то, что мы не привыкли придумывать юзкейсы, видя перед собой только данные. Трудно спорить с тем, что сейчас в России производится крайне мало взаимосвязанных данных. Однако это не значит, что разработчик, создающий приложение для русскоязычной аудитории совсем уж отрезан от мира семантического веба: кое-что всё-таки у нас есть.

Основными источниками данных для нас являются международные базы знаний, включающие русскоязычный контент: DBpedia, Freebase и Wikidata. В первую очередь это справочные, лингвистические и энциклопедические данные. Каждый раз когда вам в голову приходит мысль распарсить кусочек википедии или викисловаря — ущипните себя как следует и вспомните о том, что всё, что хранится в категориях, инфобоксах или таблицах, уже распарсено и доступно через API с помощью SPARQL или MQL-интерфейса.

Я попробую привести несколько примеров полезных энциклопедических данных, которые вы не найдете нигде, кроме Linked Data.

Эта статья — первая из цикла Базы знаний. Следите за обновлениями.

• Часть 1 — Введение
• Часть 2 — Freebase: делаем запросы к Google Knowledge Graph
• Часть 3 — Dbpedia — ядро мира Linked Data
• Часть 4 — Wikidata — семантическая википедия

В прошлый раз я описал функционал плагина Semantic MediaWiki, позволяющего управлять структурированными данными в вашей системе и создавать на их основе различные представления. Ложкой дёгтя здесь является то, что пользователям приходится учить дополнительные элементы разметки.
Сегодня мы поговорим про расширение Semantic Forms, позволяющее сделать вики совсем не похожей на вики и привлечь к работе более широкий круг пользователей.



Напомню, что сердцем Semantic MediaWiki является механизм семантических свойств. Назначение семантического свойства странице хоть и похоже на простое создание вики-ссылки [[имя свойства::значение свойства | что выводить на экран]], но, всё-таки, это новый синтаксис. Вдобавок даже если наши пользователи будут настолько дисциплинированы, что прочитают и вникнут в руководство по созданию свойств, они вряд ли будут называть все термины единообразно.
На моей вики, посвященной историческим личностям половина людей будет описана свойством время рождения, другие участники опишут людей свойством год рождения, а третьи дата рождения. Теперь для того, чтобы получить список исторических личностей и вывести их даты рождения, мне нужно написать три запроса вместо одного:

{{#ask:[[Категория Историческая личность]] | ?Время рождения }}
{{#ask:[[Категория Историческая личность]] | ?Год рождения }}
{{#ask:[[Категория Историческая личность]] | ?Дата рождения }}

Для решения этих проблем применяют шаблоны и формы.

Сегодня на конференции SemTechBiz в Сан-Франциско было объявлено о том, что проект Wikidata получил от Яндекса грант в размере 150 тысяч евро.

Wikidata — проект Фонда Викимедиа, совместно редактируемая база знаний для централизованного хранения структурированных данных.



Специально для нашего техноблога на Хабре мы расспросили Denny Vrandečić, одного из основателей этого проекта, о том, что такое Wikidata в подробностях, чем отличается от других похожих проектов и какую пользу может принести инфраструктуре будущего интернета и всем его пользователям.

Что такое Wikidata? Какие у этого проекта цели? Почему именно Wikidata стал первым проектом Фонда Викимедиа с 2006 года?

Wikidata — это новый проект Фонда Викимедиа. Главная задача последнего — предоставить каждому человеку на планете свободный доступ ко всем возможным знаниям. Самый известный наш проект — Википедия, открытая энциклопедия, доступная более чем на 200 языках.

Идея применения семантических моделей в корпоративных информационных системах существует давно, но устойчивая практика такого их использования еще не сформировалась. Семантические модели можно применять для интеграции данных, аналитики, управления знаниями; однако, пока нет общепринятого мнения о том, как подходить к оценке их полезности, по каким методикам должны строиться такие модели.
Задача статьи — на практическом примере сравнить аналитический потенциал моделей, построенных по правилам интеграционного стандарта ISO 15926, который предписывает использование OWL и SPARQL для выражения моделей и работы с ними, и «обычных» семантических моделей, построенных без использования этого стандарта. Решение этого вопроса позволит выбрать диапазон задач, для решения которого целесообразно применять такие высокоуровневые парадигмы семантического моделирования, как ISO 15926.

Semantic MediaWiki — это расширение, ради которого стоит ставить MediaWiki: оно помогает бороться с бардаком и хаосом, который рано или поздно воцаряется в любой вики-системе.

• Оно позволяет поддерживать согласованность данных на вики.
• С его помощью можно обращаться с вики как с базой данных.
• С его помощью можно генерировать красивые графики, диаграммы и графы на основе вики-данных.
• Оно позволяет пользователям возможность вводить данные с помощью форм, а не вики-разметки, понижая тем самым порог вхождения для пользователей.

SMW позволяет использовать вики как составную часть системы управления знаниями, с его помощью можно создавать коммерческие системы, которые сочетают простоту вики, четкость коллаборативных баз данных, и лучшее из мира Semantic Web. В общем, это вещь, более чем достойная пристального внимания и подробного обзора.

На выставке CeBIT я познакомился с представителями польской компании Cognitum, которая разрабатывает семантический фреймворк Ontorion. Важнейшей частью этого фреймворка является редактор онтологий Fluent Editor, который показался мне замечательным и достойным обзора. Главное достоинство Fluent Editor'а состоит в том, что он позволяет создавать OWL-онтологии людям, не имеющим представления о синтаксисе OWL (хотя иметь представление о его концепциях, и о моделировании информационных структур, конечно, все равно нужно). Онтологии создаются на естественном языке, Controlled English — то есть на обычном английском, к которому применены определенные правила и ограничения. Приведу обзор основных возможностей синтаксиса этого языка, не забывая смотреть на то, в каком виде его основные выражения будут сохраняться в OWL.

Для примера начнем составлять онтологию, содержащую сведения о бизнесе некой компании. У этой компании, как у любой коммерческой организации, есть поставщики и покупатели. Те и другие являются организациями, причем одна и та же организация может быть одновременно и поставщиком, и покупателем. Запишем соответствующие выражения на Controlled English:

Every customer is a organization.
Every supplier is a organization.

Опишем концепт интерфейса контекстного ввода цитат. Речь будет не про те облака, о которых все подумали. Облака — типа бенчмарка «Heaven», 4-я версия которого недавно вышла (рис. слева) или Небесного замка Лапута, а цитатник — элемент интерфейса типа летающих островов. На поверхности этих островов теплится жизнь, а сами они могут летать. В нашем случае — перемещаться мышью. Опору их составляют камни, а у нас — контекстные кнопки.

Как создаётся летающий остров? Выделяем мышью контекст. Выделение создаёт основу поверхности — цитату. Под ней появляется кнопка, едва заметная, полупрозрачная, которую мы привыкли видеть в Ворде, начиная с «2007». Она может вскоре исчезнуть, и правильно, если выделение текста создавалось для других целей. Но если навести мышь — создаётся опора нашего будущего цитатника, парящего в облаках.

Зачем нужен цитатник? Оказывается,

Технологии семантической паутины (Semantic Web) периодически привлекают внимание благодаря тому, что на их основе создаются новые интересные инструменты. Совсем недавно появился социальный поиск (Graph Search) в Facebook – первый инструмент поиска по графу, доступный действительно широкому кругу пользователей.
Однако, сфера применения семантических технологий не ограничивается социальными сетями и поисковыми сервисами. Идея применить эти технологии для организации обмена данными между информационными системами достаточно очевидна. Если одна система передает другой не только сами данные, но и информацию об их предметной сущности (смысле, семантике), это позволяет лучше абстрагировать обменивающиеся системы друг от друга, чем при использовании выгрузок в XML или веб-сервисов SOA.

Сегодня существует несколько реализаций такого подхода. Большинство из них, конечно, сделано зарубежными компаниями, но есть и российские разработки. В этой статье я расскажу об архитектуре одной таких систем, которую реализовал на практике.