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

Продолжение статьи.
В данной статье я рассматриваю понятие функционального объекта и объясняю как можно трактовать модели функциональных объектов. Для торопящихся советую заглянуть сразу в конец статьи — в главу «Эксперименты и сотрудники», где дана готовая интерпретация модели, исходя из описанных здесь постулатов.

Понимание и познание

Когда мы описываем предметную область, мы думаем, что пытаемся ПОЗНАТЬ ее, а на самом деле занимаемся ПОНИМАНИЕМ предметной области и описанием своего понимания. Разницу между знанием и пониманием стоит подчеркнуть. Дело в том, что те модели, которые мы строим, являются субъективными, и потому являются отражением нашего понимания предмета, но не знания о предмете. Причина, по которой знание недостижимо, – это противоречивость того способа, который мы выбрали в качестве инструмента познания – расчленение объекта на части (анализ) и сборка их вместе (синтез) Моделирование объекта как целого и как композиции. Поэтому можно сказать, что мы нацелены прежде всего на понимание, но не на познание. Вопросами понимания занимается герменевтика. Понимание у каждого свое. Нет смысла спорить о том, у кого оно лучше или хуже. Можно спорить лишь о том, какое понимание способно объяснить более широкий круг практических задач, или является непротиворечивым в рамках определенных аксиом. Требовать от понимания большего нельзя. Например, я могу утверждать, что та модель, которую я предлагаю к рассмотрению, более полно описывает наше представление о реальности, чем модель, построенная на принципах реляционных данных. Но не могу сказать, что предлагаемая мной модель верно описывает наше представление о мире. Те же, кто не видят разницы между пониманием и знанием, часто претендуют в своих спорах на знание истины. Если рассуждать логически, и предположить, что истина постижима, то результатом ее постижения стало бы невозможность выразить его словами.

Пою что вижу, или вижу, что пою?

Основная задача бизнес-аналитика при разработке нового ПО – изучение предметной области и формальное описание полученных сведений в виде модели (Domain Model). Аналитик должен петь то, что он видит и то, что он хочет увидеть. Для этого у него должен быть язык, на котором он исполнит свою песню. Однако, аналитик не всегда знаком с подходящим языком, и потому часто пользуется другими языками. Отчасти это происходит по причине того, что управление проектом ведется не с точки зрения предметной области, а с точки зрения реализации. И тогда с аналитиком может произойти несчастье: он может перестать видеть то, что надо петь и начать видеть лишь то, для чего есть слова в словарном запасе используемого им языка. Все остальное перестает для него существовать. Тогда, вместо того, чтобы петь, что он видит, аналитик начинает видеть то, что поет. Должен сразу заметить, я не против языков, я против сужения области анализа, которое возникает по причине недостаточности этих языков.

Аурэлио Де Роза несколько дней назад выпустил, на мой взгляд, очень привлекательную статью, которой я хочу с вами поделиться на тот случай, если у вас плохо с английским.

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

Тому, кто попытается использовать точку доступа 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.