ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ

ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ
ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«Национальный исследовательский университет
«Высшая школа экономики».
Факультет бизнес-информатики
Кафедра бизнес-аналитики
ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА
На тему «Алгоритмизация обогащения веб-страниц семантическими
данными»
Студент группы №
271м
Тихоход
Олеговна
Юлия
Научный
руководитель
Профессор, д.т.н.
Фомичев В.А.
Рецензент
Доцент,
к.т.н.
Перминов Г.И.
Москва 2013
ОГЛАВЛЕНИЕ
Введение ................................................................................................................... 4
Глава 1. Теоретические предпосылки исследования......................................... 10
1.1 Концепция Семантической Паутины ........................................................ 10
1.2 Ресурс Schema.org как верхнеуровневая онтология интернета ............. 18
1.3 Описание предметной области ............................................................... 21
1.4 Формальная постановка задачи ................................................................. 29
Глава 2. Разработка алгоритма распознавания классов сущностей................. 31
2.1 Подходы к решению задачи автоматического извлечения информации
из неструктурированного текста ..................................................................... 31
2.2 Поиск сущностей на основе лексического анализа текста ..................... 36
2.3 Выделение главной сущности ................................................................... 38
2.4 Соотнесение сущностей в тексте с онтологическими классами ............ 41
Глава 3. Практическая реализация алгоритма обогащения веб-страниц
семантическими данными .................................................................................... 46
3.1 Общий вид алгоритма ................................................................................. 46
3.2 Получение начального запаса формул...................................................... 47
3.3 Конструирование объекта, описывающего главную сущность на
странице ............................................................................................................. 53
3.4 Проверка объекта и генерация разметки .................................................. 55
Заключение ............................................................................................................ 58
Литература ............................................................................................................. 64
2
Приложение 1. ProcessViewModel ....................................................................... 67
Приложение 2. XmlRdfParser ............................................................................... 75
Приложение 3. RdfQueryViewModel ................................................................... 78
3
ВВЕДЕНИЕ
Одна
из
особенностей
существующей
структуры
сети
интернет
–
ориентированность представления информации на восприятие человеком.
Программному агенту, не привязанному к структуре конкретного сайта, не
всегда просто выделить семантику отдельных блоков данных или найти
нужную информацию. Как показано на рисунке 1, объем структурированных
данных в процентном соотношении уменьшается, в то время как объем
неструктурированных данных резко возрастает. Таким образом, возрастает и
потребность в механизмах работы с неструктурированными данными.
Рисунок 1 Изменение объема данных различной структурированности за 2008-2011 годы [3]
Один из способов упорядочить данные, содержащиеся в интернете,
предложил
Тим
Бернерс-Ли
еще
в
2001
году.
Он
ввел
термин
«Семантическая Паутина» (Semantic Web) и назвал это «следующим шагом в
развитии Всемирной паутины» [29]. Цель заключалась в создании сети,
предоставляющей возможности для эффективного поиска информации и
анализа данных.
Базовая модель Семантической Паутины включает следующие компоненты:
4
 URI/IRI — универсальный идентификатор ресурсов;
 Расширяемый язык разметки (XML);
 Общая схема описания ресурсов RDF(Resource Description Framework);
 RDF Schema (RDFS);
 Онтологии и языки их описания (OWL: OWL Lite, OWL DL, OWL
Full);
 OWL Schema (OWLS);
 Язык запросов к RDF-хранилищам — SPAROL;
 агенты/сервисы WSDL и схемы WSDLS.
В 2006 году создатель термина Семантическая Паутина признал, что
описанный подход к организации информации в вебе остается «простой
идеей, до сих пор в большой степени нереализованной» [25].
Развитие Семантической Паутины натолкнулось на ряд барьеров, в том
числе:
 Человеческий
фактор
—
сложность
работ
по
внедрению
и
поддержанию актуальных метаданных.
 Дублирование
Семантическая
информации.
Паутина
В
своем
предполагала
первоначальном
создание
виде
параллельных
документов, содержащих метаинформацию о страницах. Эта проблема
частично решена созданием технологий внедрения семантической
микроразметки
непосредственно
в
HTML-теги
исходного
кода
страниц;
 Отсутствие очевидного
способа деления
мира на различимые
концепты. Предполагается, что крайне сложно или невозможно
разделить все сущности на отдельно стоящие группы. Таким образом,
ставится под сомнение возможность создания верхнеуровневой
онтологии, которая легла бы в основу Семантической Паутины. Этот
5
барьер отчасти преодолен объединением ведущих поисковых систем
(Google, Bing, Yahoo! и Яндекс) для создания онтологии верхнего
уровня schema.org, предполагающей, в том числе возможность
множественного наследования и расширения типов с помощью
сторонних онтологий. Schema.org, по словам разработчиков [7] не
претендует на то, чтобы быть «глобальной онтологией» мира. Однако
благодаря
своей
гибкости
и
расширяемости
может
считаться
верхнеуровневой онтологией интернета.
Основная цель данной магистерской диссертации состоит в том, чтобы найти
способ обойти первый из указанных барьеров, а именно, человеческий
фактор. Опрос вебмастеров, занимающихся созданием сайтов, проведенный
на конференции «Вебмастерская» (20.04.2013, московский офис Яндекса) [5],
показал, что основным препятствием при внедрении семантической
микроразметки
на
страницу
является
отсутствие
инструментария
и
сложность процесса (об этом свидетельствуют такие пункты, как «лень»,
«нет времени») (см. Рисунок 2).
12
10
8
Документации
Инструментов
6
Желания заказчика
Лень
4
Времени
2
0
Не хватает
Рисунок 2 Опрос веб-мастеров о том, чего не хватает при внедрении семантической разметки
6
Предполагается, что создание инструмента, не требующего от вебмастера
глубоких знаний и значительных временных вложений, позволит увеличить
количество и повысить качество структурированных данных в интернете.
Стоит отметить, что совсем отказываться от участия в процессе извлечения
информации из веб-страниц их владельцев представляется неправильным по
двум причинам:
1. Кажется целесообразным хранить информацию об извлеченных
объектах непосредственно в исходном коде страницы, изменять
который без ведома владельца неэтично.
2. Ручная проверка результатов работы алгоритма заинтересованными
лицами должна повысить точность извлечения объектов.
Решение о хранении извлеченных знаний в качестве атрибутов веб-страниц, а
не в отдельной базе знаний основывается на следующих преимуществах
Семантической Паутины:
1. Связанность обновлений машиночитаемых данных на странице с
обновлением ее человекочитаемого представления.
2. Многократное использование знаний. Машиночитаемое представление,
которое хранится в открытом виде, может быть использовано разными
потребителями.
Распознавание всего спектра сущностей является крайне громоздкой и
трудоемкой
задачей.
Для
разработки
алгоритма
и
работоспособности достаточно взять один класс объектов.
должен отвечать следующим требованиям:
• в классе должно быть большое количество сущностей;
7
проверки
Этот
его
класс
• сущности этого класса должны часто упоминаться в текстах используемого
корпуса;
• атрибуты сущностей должны быть в достаточной степени заполнены.
Приведенным
выше
требованиям
соответствуют
schema.org. В рамках магистерской
несколько
классов
диссертации будет исследовано
выделение сущностей типа «Организация» (schema.org/Organization) – на
данный момент это один из наиболее часто встречающихся типов, с одной
стороны, и наиболее востребованных, с другой.
Таким образом, объектом исследования являются сайты организаций,
размещенные в интернете.
Предмет
исследования –
использование
алгоритмов автоматического извлечения фактов из неструктурированного
текста для обогащения страницы семантическими данными.
Целью
исследования
является
разработка
и
апробация
алгоритма
обогащения веб-страниц машиночитаемыми данными с использованием
механизма микроданных и словаря schema.org.
Актуальность
исследования
обосновывается
необходимостью
структурирования разрозненных данных, размещенные в сети интернет, для
создания возможности их последующей обработки информационными
системами, в том числе интеллектуального анализа, машинного обучения,
автоматического
построения
тематических
ресурсов
(справочников,
учебников, словарей).
Для достижения поставленной цели необходимо решить следующие задачи:
 исследовать
существующие
системы
неструктурированного текста;
 изучить структуру предметной области;
 сформулировать общий вид алгоритма;
8
извлечения
фактов
из
 создать информационную систему, реализующую разработанный
алгоритм;
 оценить качество работы алгоритма и возможности его доработки.
Первая
глава
настоящей
работы
содержит
описание
концепции
семантической паутины, в частности, развернутое описание структуры
одного из ее компонентов – ресурса schema.org, обзор выбранной предметной
области.
Во
второй главе описываются
существующие подходы
к
автоматизации извлечения информации из текста, а также излагаются
методологические
основы
алгоритма
обогащения
веб-страниц
семантическими данными. Третья глава описывает техническую реализацию
алгоритма, примеры его работы на реальных данных, а также перспективы
его развития и возможности для улучшения.
9
ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ПРЕДПОСЫЛКИ ИССЛЕДОВАНИЯ
1.1 КОНЦЕПЦИЯ СЕМАНТИЧЕСКОЙ ПАУТИНЫ
Как было сказано во введении, начальная модель Семантической Паутины
включает
следующие
компоненты
(
Пользовательский интерфейс и приложения
Доверительная информация
Доказательства
Язык запросов:
SPAQRL
Онтологи
и: OWL
Правила:S
WRL
Таксоном
ии RDFS
Символы:
US-ASCII
Рисунок 3):
 URI/IRI – универсальный идентификатор ресурсов;
 Расширяемый язык разметки (XML);
10
цифровая подпись
Логика
 Общая схема описания ресурсов RDF(Resource Description Framework);
 Метаданные и схема RDF Schema (RDFS);
 Онтологии и языки их описания (OWL: OWL Lite, OWL DL, OWL
Full);
 Метаданные и схема OWL Schema (OWLS);
 Язык запросов SPARQL к RDF-хранилищам;
 агенты/сервисы WSDL и схемы WSDLS и пр.
Пользовательский интерфейс и приложения
Доверительная информация
Доказательства
Язык запросов:
SPAQRL
Онтологи
и: OWL
Правила:S
WRL
Таксоном
ии RDFS
Синтаксис: XML
Символы:
Идентификаторы:
URI
US-ASCII
Набор символов:
US-ASCII
Рисунок 3 Стек семантических технологий
11
цифровая подпись
Логика
IRI — это символьная строка, позволяющая идентифицировать какой‐либо
ресурс: документ, изображение, файл, службу, ящик электронной почты и т.
д. В первую очередь имеются в виду ресурсы в сети интернет.
Идентификаторы IRI были разработаны в качестве замены единообразным
идентификаторам URI (англ. Uniform Resource Identifier) с целью преодолеть
их ограничения на символы: URI могут состоять из латинских символов и
знаков препинания из набора символов US-ASCII (в общей сложности около
60 символов). Таким образом, использование дополнительных таблиц
символов, например, кириллицы приводит к необходимости кодировать URL
с символами Юникода, что делает адрес ресурса непригодным для
восприятия человеком [20].
XML - рекомендованный Консорциумом Всемирной паутины (W3C) язык
разметки. XML создавался как язык с простым формальным синтаксисом,
пригодным и для использования программными агентами, и людьми. XML
изначально рассчитан на использование в интернете. Этот язык не фиксирует
разметку, применяемую в документах: разработчик может формулировать
правила именования и использования сущностей, исходя из потребностей к
конкретной области. Единственным ограничением являются правила языка.
На данный момент язык XML и его подмножества широко используется в
интернете.
RDF – это базовый информационный язык для создания распределенных баз
данных, принятый мировым консорциумом по стандартизации Интернета
W3C. “RDF обладает свойствами, которые позволяют объединять данные,
даже если базовые схемы отличаются, и поддерживать развитие схем с
течением времени без необходимости вносить изменения в ресурсах всех
потребителей данных” [24]. Сам язык не накладывает конкретных
ограничений на используемый формат, однако имеет важные смысловые
ограничения. В частности, все данные должны быть представлены в виде т.н.
триплетов (triples) (Рисунок 4 Триплет RDF). Каждый триплет представляет
12
собой набор вида (A, B, C), где компонент A называется субъектом,
компонент B называется предикатом, компонент C называется объектом. В
частном случае триплет – это тройка вида (идентификатор, свойство,
значение). Помимо интеграции данных, RDF предоставляет возможность
использовать стандартные языки запросов к хранилищу. Имеется около
десяти языков, предназначенных для этой цели, самым распространенным из
них является SPARQL [27]
Рисунок 4 Триплет RDF
RDF сам по себе является не форматом файла, а только лишь абстрактной
моделью. Для записи и передачи RDF используется несколько форматов, в
том числе:
RDF/XML — запись в виде XML-документа;
RDF/JSON — сериализация в виде JSON-данных;
RDFa (англ. RDF in attributes) — запись внутри атрибутов произвольного
HTML- или XHTML-документа;
N-Triples, Turtle, N3 — компактные формы записи триплетов.
В дальнейшем в работе будет использоваться запись в виде XML-документа.
Этот синтаксис весьма гибок: с его помощью один и тот же граф можно
записать в различных формах, использовать различные сокращенные формы.
Языковая система RDF Schema (RDFS) позволяет описать набор классов и
свойств, предназначенных для структурирования RDF ресурсов (Рисунок 5).
Второе название для RDF схемы – RDF словарь. По своей сути это механизм
для определения необходимой совокупности типов ресурсов и свойств.
13
Рисунок 5 Соотношение между RDF словарем и данными, записанными в формате триплетов [2]
Введение механизма определения словарей позволило создавать публичные
словари для описания некоторых предметных областей. Это в свою очередь
дает возможность различным приложениям обмениваться между собой
данными. Наиболее известные публичные словари на сегодняшний день это
DublinCore, Open Graph Protocol, RDF Site Summury (RSS), schema.org
RDFS получила свое развитие и в языке описания онтологий для
Семантической Паутины (Web Ontology Language, OWL). Существуют три
подмоножества OWL:
 OWL Lite облегченный вариант языка, содержащий минимально
необходимый набор правил для создания классификационной иерархии
и простых ограничениях. Он поддерживает значения кардинальности
(т.е. ограничения на максимальное и минимальное количество
значений), но перечень возможных значений ограничен до 0 и 1. OWL
14
Lite может быть, например, использован для описания существующих
тезаурусов и таксономий.
 OWL DL, с одной стороны, предоставляет пользователям мощные
выразительные возможности, а с другой, – позволяет сохранить
разрешимость и полноту вычислений. Т.е. все логические заключения,
подразумеваемые онтологией, могут быть вычислены за определенное
время.
OWL DL содержит все языковые конструкции OWL,
использовать их можно только в соответствии с набором ограничений
(так, класс может являться наследником нескольких классов, но не
может сам быть экземпляром другого класса). OWL DL полностью
соответствует дескрипционной логике, которая и легла в его основу. В
дальнейшем в данной работе будет использоваться именно это
подмножества языка OWL.
 OWL Full предоставляет максимальную выразительность, но при этом
никакие вычисления не гарантированы. В OWL Full, например, может
быть преодолено ограничение, описанное в предыдущем подпункте:
класс
может
быть
рассмотрен
одновременно
как
множество
экземпляров и как один экземпляр, имеющий собственное значение.
OWL Full позволяет строить такие онтологии, которые расширяют
состав предопределённого (RDF или OWL) словаря.
Модель RDF не описывает способы обработки данных. Эту нишу заполняет
класс языков, предназначенных для запросов к RDF-данным: SPARQL, RQL,
RDQL, DQL, N3QL, R-DEVIC, SeRQL. Наиболее популярным из них
является SPARQL, являющийся признанным стандартом W3C.
SPARQL - язык запросов к разнообразным источникам данных, независимо
от того, хранятся эти данные прямо в RDF либо представляются в виде RDF с
помощью промежуточного программного обеспечения (middleware), а также
протокол для передачи этих запросов и ответов на них. SPARQL является
рекомендацией консорциума W3C[27]. Предоставление SPARQL-точек
15
доступа (англ. SPARQL-endpoint) -
рекомендованная практика при
публикации данных в интернете. SPARQL обладает возможностями
формирования запросов к обязательным и необязательным графовым
шаблонам вместе с их конъюнкциями и дизъюнкциями. SPARQL также
поддерживает тестирование расширенного значения и ограничение запросов
посредством исходного RDF-графа. Результаты запросов SPARQL могут
быть представлены результирующими наборами или RDF-графами.
WSDL - язык описания веб-сервисов и доступа к ним, основанный на языке
XML. Любой документ WSDL состоит из следующих логических частей:
 определение типов данных (types) — о вида отправляемых и
получаемых сервисом XML сообщений
 сообщения (message) — элементы данных, которые применяются webсервисом
 абстрактные операции (portType) — перечень операций, выполняемых
над сообщениями
 связывание сервисов (binding) — способ доставки сообщений.
Изначально концепция Семантической Паутины предполагала хранение
информации в отдельном документе, описывающем семантику ресурса.
Однако спустя некоторое время появились способ хранить семантические
атрибуты непосредственно в исходном коде страниц – семантическая
разметка. Основная особенность всех этих способов состоит в том, что
пользователь-человек видит и воспринимает страницу с семантической
микроразметкой
как
обычную
веб-страницу,
при
этом
программы-
обработчики, следуя определенным соглашениям, могут извлекать из нее
структурированную информацию.
Существует несколько способов внедрения машиночитаемых семантических
данных на страницу.
16
 Микроформаты – первый из предложенных форматов внедрения
микроразметки на страницу. Описано около десяти классов данных,
которые могут быть указаны на странице. Некоторые из них имеют
статус готовой спецификации, большинство же на протяжении
нескольких последних лет остается в статусе черновика. На данный
момент этот формат почти не развивается.
 RDFa – хранение триплетов RDF в исходном коде страниц. Это
рекомендованный Консорциумом Всемирной паутины (W3C) язык
семантической микроразметки.
 Микроданные – способ, предложенный стандартом HTML5, более
простой и наглядный, нежели RDFa, однако имеющий меньше
выразительных возможностей.
Способ внедрения микроразметки на страницу, используемый в настоящей
работе, выбирался по следующим критериям:
 Развитие – вероятность дальнейшего совершенствования самого
формата, ресурсов, работающих на его основе и словарей, которые
могут быть с ним использованы.
 Ясность – простота освоения, простота использования и понимания
человеком.
 Распространенность – популярность способа среди вебмастеров, и,
что особенно важно, среди потребителей микроразметки.
 Полнота – объем информации, которую можно выразить с помощью
выбранного способа
С точки зрения приведенных выше критериев наиболее удачным кажется
сочетание микроданных и словаря schema.org.
17
1.2 РЕСУРС SCHEMA.ORG КАК ВЕРХНЕУРОВНЕВАЯ ОНТОЛОГИЯ ИНТЕРНЕТА
Летом 2011 года крупнейшие поисковые системы Google, Bing и Yahoo!
предложили стандарт семантической разметки данных в сети schema.org.
Цель семантической разметки – сделать интернет более понятным,
структурированным и облегчить поисковым системам и специальным
программам извлечение и обработку информации для удобного её
представления в результатах поиска.
Ресурс schema.org предоставляет собой общедоступный словарь, с помощью
которого вебмастера могут размечать страницы, так чтобы они были понятны
самым распространенным поисковым системам: Яндексу, Google, Microsoft и
Yahoo!, а также любым другим потребителям, желающим воспользоваться их
данными.
Как уже было сказано выше, словарь schema.org[7, 23] применяется вместе с
микроданными (формат microdata). Хотя долгосрочная цель заключается в
расширении перечня поддерживаемых способов внедрения семантической
разметки (JSON, RDFa), изначально используются именно микроданные.
Разметка происходит непосредственно в HTML-коде страниц с помощью
специальных атрибутов и не требует создания отдельных экспортных файлов
(Рисунок 6).
Рисунок 6 Пример разметки сущности в исходном коде страницы
18
Как было сказано во введении, schema.org не претендует на то, чтобы быть
глобальной онтологией всего мира. Однако она покрывает основные классы
сущностей, используемых в сети интернет.
Наиболее общий тип сущности— это Thing (нечто), у которого есть пять
основных свойств: name (название), description (описание), url (ссылка),
image
(картинка)
и
additionalType
(дополнительный
тип).
Более
специализированные, частные типы имеют общие свойства с более
универсальными. Например, Place (место) — частный случай Thing, а
LocalBusiness (местная фирма) — частный случай Place. Частные типы
наследуют свойства родительского типа. Более того, тип LocalBusiness
является и частным случаем Place, и частным случаем Organization
одновременно, поэтому наследует свойства обоих родительских типов.
Таким образом, допускается множественное наследование. А с помощью
свойства additionalType можно указать принадлежность сущности к
нескольким произвольным типам schema.org, а также любых других словарей
(например, productOntology).
Список некоторых популярных типов сущностей выглядит следующим
образом:
 Творческие произведения: CreativeWork (творческое произведение),
Book (книга), Movie (фильм), MusicRecording (музыкальная запись),
Recipe (рецепт), TVSeries (телесериал).
 Встроенные нетекстовые объекты: AudioObject (аудио), ImageObject
(изображение), VideoObject (видео)
 Event (событие)
 Organization (организация) (Рисунок 7)
 Person (человек)
 Place (место), LocalBusiness (местная фирма), Restaurant (ресторан)...
19
 Product (продукт), Offer (предложение), AggregateOffer (сводное
предложение)
 Review (отзыв), AggregateRating (сводный рейтинг)
Рисунок 7 Schema.org/Organization
20
Типы и отдельные поля schema.org чувствительны к регистру, т.е.
schema.org/Organization и schema.org/organization – разные типы (второго в
словаре не существует).
У многих свойств есть так называемые ожидаемые типы. Это значит, что
значение свойства может быть вложенной сущностью. Однако добавлять
вложенную сущность не обязательно: приемлемо использовать просто текст
или URL
Также вместо ожидаемого типа можно использовать дочерний тип.
Например, если для свойства указан ожидаемый тип Place, можно добавить
вложенную сущность с типом LocalBusiness.
В словаре schema.org определены отношения «частное-общее» — более
общие
типы
могут
делиться
на
частные
подтипы.
Например,
schema.org/Organization содержит несколько подтипов на трех уровнях
иерархии.
Над свойствами отношение «частное-общее» не определено. В онтологии,
которая может быть выгружена с сайта schema.org также не определены
отношения «эквивалентно» и «обратно», однако, исходя из текстовых
описаний некоторых свойств, можно сделать вывод, что эти отношения
могут быть определены.
1.3 ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
Как было сказано выше, кажется целесообразным ограничить предмет
исследования сущностями типа «Организация». В реальном мире сущности
этого типа могут иметь огромное количество разнообразных свойств. Для
целей исследования можно ограничиться свойствами, описанными в словаре
schema.org и, возможно, наиболее часто встречающимися из неописанных
там свойств.
21
Таблица 1 Признаки организаций, описанные в словаре schema.org
Признак*
Частота
Уникальность признака***
встречаемости на
страницах
с
организациями**
address
4
Place, Person
aggregateRating
2
CreativeWork,
Product
brand
2
Product
contactPoint
4
Person
duns
1
Person
email
4
Person
employee
1
event
3
Place
faxNumber
3
Place, Person
founder
2
foundingDate
2
globalLocationNu 1
Person
22
Offer,Place,
mber
hasPOS
2
Person
interactionCount
3
MediaObject, Place, Person
isicV4
1
Person
legalName
4
location
4
Event
logo
3
Place, Product
makesOffer
3
Person
member
2
naics
1
owns
2
Person
review
3
CreativeWork,
Product
seeks
1
taxID
3
Person
telephone
4
Place, Person
23
Offer,Place,
vatID
?
Person
*В качестве признаков выделены свойства schema.org/Organization
**частота встречаемости на страницах выделена эмпирически на нескольких
десятка русскоязычных примеров. Для оценки использована лингвистическая
шкала:
1
2
3
4
Почти не встречается
Иногда встречается
Встречается часто
Есть почти всегда
***Если признак может быть не только у организаций, то указывается, какой
еще тип сущностей обладает данным признаком.
Для выбора организаций среди других типов сущностей наиболее интересны
те признаки, встречаемость которых 3 или 4, которые при этом не присущи
другим типам сущностей.
Самый
надежный
признак,
таким
образом,
официальное
название
организации (legalName)
Проанализировав таблицу можно также сделать вывод о схожести
schema.org/Organization
с
двумя
другими
schema.org/Person.
24
типами:
schema.org/Place,
Таблица 2 Лингвистические признаки свойств организаций (фрагмент)
Признак
Слово
Словосочетание Стоп-слова
address
Адрес,
Карта,
павильон,
* подъезд,
Мы находимся Квартира, кв.,
по адресу,
Аренда, съемочный,
Как
к
нам
добраться,
вход со двора,
рядом
с,
пересечение с,
Торговый
центр, ТЦ,
Бизнес-центр,
БЦ,
нижний
уровень,
Юридический
адрес,
Где
мы
находимся
aggregateRating
Рейтинг,
Оценка
brand
ТМ
Торговая марка
contactPoint
Контакты
Связаться
с
нами,
юридический
адрес,
Как добраться
до
нашего
офиса,
email
email, @
Адрес
электронной
почты,
Высокий,
IMDB
Кинопоиск
Возрастной
25
электронная
почта
employee
Работники,
Сотрудники,
Специалисты
Наши
сотрудники,
Работники
<имя
компании>,
Наша команда,
Отдел *,
event
Новости,
События,
Мероприятия,
Афиша,
Акции,
Мероприятия
faxNumber
Факс
Факс + 10 цифр Продается
founder
Основатель,
Учредитель,
founder
Компания
основана <имя
фамилия>,
Основатель
компании,
foundingDate
Создана
организована в
* году
была основана
в <месяц, год>
году,
Основание
компании,
История
компании
начинается в *
году
Начала
свою
работу
26
Бойкот,
Награды,
Голодовка,
Забастовка,
Отзывы,
Вакансия,
Увольнение,
Аттестация,
Ответственность,
Книга,
Буддизма,
Отец-основатель,
Ислама,
Психоанализа,
Клуба,
interactionCount
Комментарии,
Поделились,
Просмотров
legalName
ООО,
ОАО,
ЗАО,
ИП,
ОДО,
УП,
ФГУП,
LTD,
LLC,
LLLP,
location
Ориентиры,
logo
Логотип
</logo.jpg>
</logotip.jpg>
</logo.png>
makesOffer
Услуги,
Товары,
Продукция,
Меню
Скидки
member
Компания
<название
компании>
входит
в
состав
холдинга
<название
компании>
owns
Меню
рядом
со
станцией
ближайшая
станция
станция метро
мы находимся
Наши услуги,
27
Прайс лист,
Услуги и цены
review
Отзывы
О нас пишут
Отдел закупок
По
вопросам
поставок
обращаться
seeks
taxID
ИНН
получить
telephone
//маска
+* *** *** **
**
телефон
позвонить
забронировать
заказ билетов
бронирование
столиков
связаться
с
нами
звонок
бесплатный
Описания организаций могут встречаться как на сайтах самих организаций,
так и на справочных сайтах, содержащих информацию о большом количестве
компаний. При этом наиболее интересными для целей исследования
представляются сайты самих организаций. Для этого существует несколько
причин:
1. Как правило, такие сайты содержат наиболее полную и достоверную
информацию.
2. Информация на таких сайтах в значительной степени менее
формализована, чем на сайтах-агрегаторах, т.е. намного менее удобна
для автоматической обработки в своем исходном виде
Описание организаций на сайтах, агрегирующих информацию о множестве
объектов и сайтах, содержащих информацию только об одной сущности,
имеет существенные отличия. Информация на сайтах-агрегаторах изначально
более структурирована, но менее подробна. Как правило, на таких сайтах
28
можно найти название, адреса и телефоны компании, адрес сайта, рейтинг,
категорию, фотографии, отзывы.
Информация на сайте организации обычно более подробна, но менее
структурирована. Так информация о контактах располагается чаще всего на
отдельной странице с характерным именем (about, contacts), на той же или на
других страницах может быть информация об истории компании, дате
основания и основателях. На сайте может присутствовать информация о
команде, услугах, которые предоставляет компания, услугах, в которых
нуждается компания и т.д.
1.4 ФОРМАЛЬНАЯ ПОСТАНОВКА ЗАДАЧИ
Сформулируем задачу следующим образом: разработать алгоритм внедрения
семантической микроразметки на существующую веб-страницу. Эту задачу
можно условно разделить на две крупные подзадачи:
1. Автоматическое выделение объектов из неструктурированного текста
2. Внедрение информации о выделенных объектах в HTML-код страницы
Первая задача – это задача извлечения информации из текстов. Существует
несколько подходов к ее решению:
1. Подход, основанный на правилах
2. Подход, основанный на машинном обучении
3. Подход, основанный на онтологиях
О них будет сказано подробнее в разделе «2.1 Подходы к решению задачи
автоматического извлечения информации» главы 2.
В рамках данной работы было принято решение применять совместно
подход, основанный на правилах, и подход, основанный на онтологиях.
Задача решается с использованием алгоритмов извлечения сущностей из
текста, основанных на правилах, применяемых к произвольному
необработанному тексту. Выявляются ключевые сущности и связи. Для
достижения логически последовательных результатов в соответствии с
заданной предметной областью выделенные сущности сопоставляются с
формализованным описанием эталонных классов. Предметная область
29
задается онтологией schema.org, дополненной дополнительными связями,
свойствами и аксиомами.
Рисунок 8 Общий вид алгоритма обогащения страницы семантическими данными
30
ГЛАВА
2.
РАЗРАБОТКА
АЛГОРИТМА
РАСПОЗНАВАНИЯ
КЛАССОВ
СУЩНОСТЕЙ
2.1
ПОДХОДЫ
К
РЕШЕНИЮ
ЗАДАЧИ
АВТОМАТИЧЕСКОГО
ИЗВЛЕЧЕНИЯ
ИНФОРМАЦИИ ИЗ НЕСТРУКТУРИРОВАННОГО ТЕКСТА
Задача извлечения информации из документов на естественных языках
принадлежит к разряду задач распознавания. Извлечение состоит в
нахождении
целевого
текстового
фрагмента,
отвечающего
заданным
условиям, в неструктурированном тексте и сохранении его в заданном
формате (реляционной БД, XML, RDF)
Большинство подходов предполагают извлечение знаний из текстов,
принадлежащих
«Конференция
ограниченным
по
Пониманию
предметным
сообщений»
областям.
(Message
Например,
Understanding
Conference, MUC) — конференция соревновательного характера
— в
прошлом фокусировалась на таких вопросах:
 MUC-1 (1987), MUC-2 (1989): Военно-морские операции.
 MUC-3 (1991), MUC-4 (1992): Терроризм в латиноамериканских
странах.
 MUC-5 (1993): Венчурные операции в области микроэлектроники.
 MUC-6 (1995): Новостные статьи об изменениях в управляющих
процессах.
 MUC-7 (1998): Отчёты о запусках спутников.
Правила (образцы, шаблоны) извлечения информации из текста могут
базироваться на лексике, частичном синтаксисе, оценки близости и
взаимного расположения частей. Формат представления зависит от формата
представления текста в системе. Зачастую для представления правил
используются специальные грамматики.
Существует несколько подходов к построению правил:
31
 Ручное построение правил лингвистами;
 Машинное обучение;
 Обобщение правил с привлечением словарных или онтологических
ресурсов.
Написание правил вручную весьма трудоемко и требует специальной
квалификации. При этом перенастройка системы, основанной на написанных
вручную правилах, также процесс, требующий значительных временных и
ресурсных затрат. Однако такой подход позволяет создавать гибкие системы
извлечения фактов и при этом довольно легко точечно исправить
возникающие ошибки.
Подход, основанный на машинном обучении, родился как попытка
автоматизировать процесс создания правил. Для этих целей обычно
используют
методы
машинного
обучения,
позволяющие
на
наборе
позитивных и негативных примеров построить систему обобщенных правил
извлечения фактов.
Ниже приведены несколько примеров систем, позволяющих извлекать
информацию из текста. Они используют как лингвистические методы, так и
методы машинного обучения для создания правил.
 Intelligent Miner for Text (IBM) — система, позволяющая определять
язык текста, его принадлежность к определенному классу текстов,
ключевые слова, смысл текста. Программа может генерировать
аннотации к текстам, а также разделять документы на группы по
близости ключевых слов.
 TextAnalyst, WebAnalyst (Мегапьютер Интеллидженс) — система,
позволяющая строить семантическую сеть текста, классифицировать и
кластеризовать документы, строить аннотации.
 Text Miner (SAS) — информационная система, предназначенная для
интеграции текстовой информации со структурированными данными.
32
В основе Text Miner лежит статистический анализ, что позволяет без
дополнительных затрат задействовать другие языки, но при этом
ограничивает
возможность
использования
информации
о
специфических взаимосвязях, которые могут иметь место в конкретном
языке или конкретной предметной области.
 SemioMap (Semio Corp.) — программа предоставляет возможности по
анализу ключевых слов в тексте и построению лексической сети на
основе их совместной встречаемости. Эта информационная система,
как и Text Miner, основана на статистическом анализе.
 Oracle Text (Oracle) — еще одна программа статистического анализа
текста, позволяющая выделять ключевые слова в тексте и строить
тематическое резюме для произвольного документа.
 Knowledge
Server
(Autonomy)
—
программа,
основанная
на
статистических методах и машинном обучении. Эта программа также
позволяет автоматически классифицировать, кластеризовать тексты,
строить их аннотации, генерировать таксономические деревья.
 Galaktika-ZOOM (корпорация "Галактика") — инструмент для создания
хранилища текстовой информации. Обладает возможностями по
классификации и кластеризации текстов на естественных языках,
построению их аннотации и рефератов.
 InfoStream (Информационный центр "ЭЛВИСТИ") — программа,
предназначенная в первую очередь для мониторинга средств массовой
информации.
InfoStream
обладает
функциями
автоматического
определения языка документа, семантической близости нескольких
текстов, построения сюжетов (т.е. классификации и кластеризации
текстов)
Анализ существующих систем и методов обработки текстов позволил
сделать вывод о том, что универсальной системы, решающей задачу
33
автоматизации выделения сложных составных сущностей по заданному
образцу, не существует.
Одной из подзадач извлечения информации из текста является задача
извлечения именованных сущностей [1]. Рассмотрим основные известные
системы извлечения именованных сущностей.
Google news
В крупнейшей поисковой системе мира Google разработан сервис аггрегации
новостей (http://news.google.com). Каждая новостная статья обрабатывается
системой распознавания персон. Каждая сущность выступает в роли тега, по
которому можно сгруппировать статьи.
Яндекс.Новости
Более технологически продвинутое распознавание сущностей используется в
новостном сервисе российской поисковой системы Яндекс. С помощью
определенных
правил
в
новостных
текстах
выделяются
персоны,
организации и географические объекты. Объекты составляют собственную
базу данных (которая не соотносится с Википедией или другими
онтологиями), для некоторых из них можно просмотреть автоматически
выделяемую информацию.
В основе Яндекс.Новостей лежит Томита-парсер, о котором пойдет речь
далее в настоящей работе (см. главу 2.2 Поиск сущностей на основе
лексического анализа текста)
AIDA
Система
AIDA
(http://www.mpi-inf.mpg.de/yago-naga/aida/)
создана
в
институте информатики Макса Планка в Германии. В качестве онтологии в
этой системе используется YAGO2. AIDA находит объекты в тексте по
34
названию и распознает их с помощью графа, состоящего из 18
онтологических связей (Hoffart, et al., 2011), (Yosef, et al., 2011).
35
2.2 ПОИСК СУЩНОСТЕЙ НА ОСНОВЕ ЛЕКСИЧЕСКОГО АНАЛИЗА ТЕКСТА
Онтологический подход к извлечению информации из текста, положенный в
основу работы, предполагает использование нескольких составных частей
[22]:
 Модуля обработки текста. Чаще всего модуль обработки текста
базируется на лингвистических правилах, частичных деревьях разбора
либо на газеттире.
 Редактор онтологий.
 Онтология.
 Модуль генерации онтологий, позволяющий формировать компоненты
онтологии из входного текста. Могут генерироваться экземпляры
классов и значения свойств, либо создаваться новые классы
и
свойства.
Модуль обработки текста в качестве результата своей работы в том или ином
виде
сохраняет
выделенные
факты.
Факт,
представляя
собой
зафиксированное в высказывании (языковом выражении) эмпирическое
знание об объектах, их свойствах и ситуациях, может быть формализован в
виде когнитивной схемы, соотносящей его с понятиями и отношениями
онтологии [5].
Наиболее популярные из существующих решений для обработки текстов на
естественных языках:
 GATE (General Architecture for Text Engineering) – система,
разработанная в университете Шеффилда (США), которая:
 предлагает
инфраструктуру
программных
компонент
естественных языках.
36
с
для
разработки
целью
и
обработки
внедрения
текста
на
 определяет архитектуру, то есть способ организации данных и
программных компонент, обрабатывающих текст,
 предлагает реализацию архитектуры (набор классов, который
может встраиваться в программные приложения независимо от
GATE),
 помогает разрабатывать и использовать компоненты с помощью
графического инструментария [16].
 JAPE (Java annotation pattern engine) дает возможность создавать
системно обусловленные правила для машинных языков.
конечный
автомат
над
множеством
регулярных
Это
выражений,
являющийся частью GATE.
 AGFL (Affix Grammar for Finite Lattice) система, разработанная на
отделении Компьютерных исследований Университета Неймеген
(Нидерланды) под руководством К. Костера, работающая на базе
формализма AGFL1 – двухуровневой формальной грамматики. AGFL1
– контекстно-свободная порождающая грамматика дополнена набором
признаков (аффиксов) с конечным числом значений, которые
позволяют
задавать
конструкции
согласования,
координации
и
управления. AGFL грамматика русского зыка в настоящее время
разрабатывается
в
Санкт-Петербургском
государственном
Университете.
 LSPL (LexicoSyntactic Pattern Language) представляет собой анализатор
текста
на
естественном
синтаксических
языке,
шаблонах
[14].
базирующийся
Анализатор
на
лексико-
является
свободно
распространяемым программным обеспечением с открытым исходным
кодом.
 AIRE (Artificial Intelligence Information Retrieval Engine) - пакет
свободного
обеспечивающего
программного
различные
37
обеспечения,
виды
автоматической
лингвистической
обработки
текстов.
Используется
в
системах
информационного поиска и автоматического перевода.
 Томита-парсер
–
обеспечение
для
основанное
на
свободно-распространяемое
обработки
текстов
алгоритме
на
программное
естественных
языках,
Извлечение
фактов
GLR-парсинга.
происходит при помощи контекстно-свободных грамматик и словарей
ключевых слов. Парсер имеет открытое API, которое позволяет
создавать свою грамматику, добавить свои словари и запустить на
произвольных
текстах
[13].
Парсер
основан
на
алгоритме,
предложенном Масару Томитой в 1984 году для быстрого и
эффективного распознавания текстов, написанных на естественных
языках. Используется в подготовке данных для различных сервисов
Яндекса, таких как Яндекс.Новости или Яндекс.Работа.
Поскольку самостоятельное написание лингвистического анализатора –
весьма трудоемкая задача, требующая значительных, в том числе и
лингвистических навыков, и эта задача не является целью работы, было
принято решение использовать один из существующих парсеров. При выборе
анализатора учитывались следующие признаки:
 наличие встроенной поддержки русского языка;
 наличие актуальной пользовательской документации;
 возможность написания собственных словарей;
 возможность выводить результат в формате RDF или xml.
Наиболее удачным решением с точки зрения перечисленных выше критериев
оказался Томита-парсер.
2.3 ВЫДЕЛЕНИЕ ГЛАВНОЙ СУЩНОСТИ
Для решения задачи успешного извлечения информации из текста
необходимо
определить,
какой
из
38
выделяемых
объектов
является
тематически главным в тексте – его «семантическим фокусом». При
выделении главного объекта на странице можно исходить из [4]
 позиции именной группы, обозначающей данный объект, в тексте и
частоты встречаемости;
 специальные языковые средства указания фокуса внимания (в
контексте организаций это может быть, например, употребление
личных местоимений рядом с именем компании, большое количество
оценочных прилагательных, относящихся к именной группе);
 наличие
экстралингвистических
отношений
между
атомарными
объектами
Помимо этого можно учитывать
 вложенность HTML-тегов (структуры страницы);
 структуру онтологии (ранги свойств классов).
Рассмотрим небольшой пример раздела «о компании» [10] (жирным
выделены упоминания основной компании, курсивом – других компаний в
тексте):
Е5 позиционируется на рынке как специалист по проектированию и разработке заказных
программных приложений промышленного качества, их внедрению и интеграциии в
бизнес-ландшафт Заказчика, а также последующему сопровождению и развитию.
Особенностями компании являются высокая технологичность процесса разработки,
большой опыт проектов на мировом рынке и хорошо выстроенный процесс
взаимодействия с Заказчиком. Как результат наш клиент получает надежное, отторгаемое
программное решение, открытое для дальнейшего развития и интеграции. Наличие в
нашем стеке широкого ряда вендорских и свободных технологических платформ
позволяют выбрать оптимальное техническое решение для каждой конкретной задачи.
Мы имеем опыт создания сложных, масштабных и высоконагруженных систем.
Компания предоставляет своим Клиентам и Партнерам:
39
Услуги: по управлению сложными проектами, аудиту существующих приложений,
проектированию и разработке приложений.
Решения: возможность сократить время и бюджет разработки за счет активного
переиспользования опыта и наработок в аналогичных проектах.
Продукты: ряд современных уникальных продуктов Компании с возможностью глубокой
кастомизации под нужды Заказчика.
Е5 - молодая компания с долгой историей. Молодая – по возрасту и энергии коллектива.
И в то же время профессионально зрелая, с интересной историей развития и достижений.
Сегодня за плечами коллектива уже более 150 успешно выполненных проектов - в России,
США, Великобритании, Израиле, Швейцарии, Франции и Германии. Наши приложения
многие годы эксплуатируются ведущими компаниям, такими как ТНК-ВР, Роснефть и
Лукойл. Мы принимали участие в разработках инновационных решений для американских
стартапов, а также в разработке критических и высоконагруженных приложений для
российских заказчиков.
Ядро команды сложилось в 2000 году в работе над нашими первыми проектами и сегодня
составляет костяк Компании. По 2002 год мы работали развивая направление прикладных
разрабток для зарубежных заказчиков. В этот период мы приобрели огромный опыт
управления
инновационными
коммуникации.
Впоследствии
проектами
с
данный
высокими
опыт
требованиями
позволил
нам
к
качеству
обеспечить
конкурентоспособность наших услуг, решений и продуктов на глобальном рынке.
В примере видно, что название компании, о которой идет речь, встречается
раньше – с него начинается текст – и чаще. Другие компании упоминаются
позже и их названия не повторяются. На страницах других организаций
можно встретить похожую картину.
Таким образом, для целей данной работы будем считать, что чем чаще объект
упоминается в тексте и чем выше его первое упоминание, тем больше
вероятность того, что он является семантическим фокусом рассматриваемого
текста. Поскольку рассматриваются только собственные сайты организаций,
этих двух признаков достаточно для достоверного определения ключевой
организации в тексте. Однако при переходе к другим типам страниц и
40
выделяемых объектов необходимо будет вернуться к рассмотрению вопроса
об определении семантического фокуса в тексте.
2.4 СООТНЕСЕНИЕ СУЩНОСТЕЙ В ТЕКСТЕ С ОНТОЛОГИЧЕСКИМИ КЛАССАМИ
В качестве математической базы для описания предметной области будем
использовать теорию К-представлений, описанную в [11,12,19]. В качестве
модели представления данных в машиночитаемом виде будем использовать
RDF, записываемы в виде XML документа.
Чтобы задать множества формул, позволяющих строить семантическое
представление текста и проводить операции над ним, в монографиях
[11,12,19] введены понятия сортовой системы, концептуально-объектной
системы и концептуального базиса.
В [11,12,19] вводится множество символов St, обозначающих наиболее
общие понятия предметной области - сорта. Реализуем это в виде RDF/XML
словаря,
содержащего
основные
типы
фактов
Компания,
Фамилия,
ДатаОснования и т.д.
Из множества сортов St выделяется элемент P, называемый сортом «смысл
сообщения».
Введем иерархию понятий на множестве сортов St с помощью бинарного
отношения Gen. В RDFэто отношение будет реализовываться в виде
конструкции rdfs:subClassOf. Назовем объектами множества St классы
извлекаемых фактов, например:
CompanyDescr – описание компании в тексте;
FDO – фамилия-должность-организация.
Объект может быть охарактеризован с разных точек зрения, поэтому введем
отношение совместимости Tol на множестве St. В RDF это отношение будет
реализовано, как owl:unionOf
41
Пусть S – упорядоченная четверка вида
(St, P, Gen, Tol), (1)
где St – множество символов, обозначающих сорта.
𝑃𝜖𝑆𝑡 - сорт «смысл сообщения» (примем главную сущность на странице за
смысл сообщения), Gen – частичный порядок на St, т.е. рефлексивное,
транзитивное и антисимметричное отношение на St (в нашем случае это
отношение «общее-частное»), Tol – бинарное отношение совместимости
(толерантности) на St, являющееся антирефлексивным и симметричным (это
отношение показывает, что сущность одновременно может являться
наследников двух разных классов, ни один из которых не является
подклассом другого).
Тогда упорядоченный набор Ct вида
(X, V, tp, F) (2)
Называется концептуально-объектной системой, согласованной с системой S,
если X, V – счетные непересекающиеся множества символов, tp –
отображение вида X U VTp(S), где Tp(S) – множество сортов,
порождаемых сортовой системой S, X – первичный информационный
универсум (в нашем случае xml файл с найденными фактами), V – счетное
множество символов, называемых переменными (в нашем случае это
переменные в SPARQL-запросе), F C X, для каждого 𝑟 ∈ 𝐹 tp(r) является
упорядоченным набором (например, {(Company, UniqueCompany)}), St C X, и
для любого 𝑠 ∈ 𝑆𝑡 𝑡𝑝(𝑠) =↑ 𝑠 (↑- символ, обозначающий тип, связанный с
соответствующим понятием), множество {𝑣𝑎𝑟 ∈ 𝑉|𝑡𝑝(𝑣𝑎𝑟) = [сущн]} –
счетное множество.
В монографиях [11,12,19] задается третий упорядоченный набор формальных
объектов - Ql – система кванторов и логических связок, включающая в себя
интенсиональные и экстенсиональные кванторы, квантор референтности,
отношение эквивалентности, отрицания.
Тогда тройка B вида
(S,Ct, Ql) (3)
42
называется концептуальным базисом.
В описанном концептуальном базисе может быть определено множество
формул Ls(B), которое будет называться стандартным концептуальным
языком (СК-языком) в базисе B. Сформулированы некоторые высказывания
P[0], P[1],…,P[10], которые интерпретируются как правила построения
семантических представлений текстов на естественных языках из элементов
первичного информационного универсума X(B), переменных V(B) и
нескольких специальных символов при условии, что B является
концептуальным базисом для рассматриваемой области.
Для любого концептуального базиса начальный запас формул задается
правилом P[0] («Если 𝑑 ∈ 𝑋(𝐵) ∪ 𝑉(𝐵), 𝑡 ∈ 𝑇𝑝(𝑆(𝐵)), 𝑡𝑝 = 𝑡𝑝(𝐵), 𝑡𝑝(𝑑) =
𝑡, то 𝑑&𝑡 входит в 𝑇 0 (𝐵) »), позволяющим отобразить информацию из
первичного информационного универсума X в структуре формул из
множества 𝑇 0 (𝐵) . В разделе «3.2 Получение начального запаса формул»
будет описан механизм реализации этого правила.
Правило P[1] предназначено для присоединения информационных единиц,
соответствующих словам «некоторый», «каждый», «какой-нибудь», «все»,
«несколько» (интенсиональных кванторов). В настоящей работе с помощью
этого правила строятся высказывания вида:
<Restriction>
<onProperty rdf:resource="member"/>
<allValuesFrom rdf:resource="Organization"/>
</Restriction>
Правило P[2] нужно для построения цепочек вида f(a1,…,an), где f –
обозначение функции, n≥1, a1,…,an – формулы, построенные с применением
правил P[0], P[1],…,P[10]. Это правило используется для заполнения
некоторых свойств объектов.
Construct
{
…
$employee schema:jobTitle $post
…
}
WHERE
{
…
$employee ont:Post $post
…
}
43
P[3] позволяет
построенные с
реализуется с
построенная с
образом:
строить цепочки вида (a1≡a2), где , a1, a2– формулы,
применением правил P[0], P[1],…,P[10]. Это правило
помощью equivalentProperty и equivalentClass. Цепочка,
помощью этого правила может выглядеть следующим
<ObjectProperty rdf:about="http://topbraid.org/schema/name">
<equivalentProperty rdf:resource="CompanyName"/>
Правило P[4] позволяет строить отношения вида r(a1,…,an), где n≥1, a1,…,an –
формулы, построенные с применением правил P[0], P[1],…,P[10]. В SPARQL
это может быть записано следующим образом:
$company schema:legalName ($abbr $name).
Правило P[5] позволяет помечать переменными в семантических
представлениях текстов на естественном языке описания различных
сущностей, семантические представления фрагментов текста. Например, на
языке SPARQL это может быть записано так:
$company ont:CompanyName "АССОЛЬ" .
Здесь определяется, что в качестве значения переменной company будет
браться объект, свойство ont:CompanyName которого равно "АССОЛЬ".
P[6] позволяет строить формулы с отрицаниями.
Например, таким образом можно выбрать все переменные, свойство
ont:CompanyName которых не равно "АССОЛЬ"
$member ont:CompanyName $mname
FILTER regex($mname, !"АССОЛЬ", "i")
С помощью P[7] можно строить формулы дизъюнкции и конъюнкции.
Дизъюнкция в SPARQL реализуется с помощью шаблона UNION, а
дизъюнкция с помощью ключевого слова FILTER.
P[8] дает возможность строить цепочки вида c*(r1,b1),…,(rn,bn). Это правило
будем использовать в настоящей работе для заполнения свойств объектов,
значениями которых являются данные простых типов (string, boolean).
Например, это может быть записано так:
Construct
{
$company schema:name $name .
$company schema:legalName ($abbr $name).
}
WHERE
44
{ $company ont:CompanyName "АССОЛЬ" .
$company ont:CompanyName $name .
OPTIONAL {$x ont:CompanyAbbrev $abbr } .
}
В результате будет построен граф вида
<schema:Organization rdf:about="http://www.co-ode.org/ontologies/ont.owl#12">
<schema:description>КОМПАНИЯ</schema:description>
<schema:employee
rdf:resource="http://www.coode.org/ontologies/ont.owl#14" />
<schema:legalName rdf:nodeID="autos54573" />
<schema:name>АССОЛЬ</schema:name>
</schema:Organization>
P[9] позволяет строить формулы, включающие квантор существования ∀ и
квантор всеобщности ∃
$company owl:someValuesFrom schema:Organization .
P[10] позволяет строить n-местные упорядоченные наборы. Используется на
последнем шаге преобразования текста.
Так, запрос, построенный с учетом некоторых из приведенных выше правил,
вида:
BASE <http://www.co-ode.org/ontologies/ont.owl#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX ont: <http://www.co-ode.org/ontologies/ont.owl#>
PREFIX schema: <http://schema.org/>
Construct
{$company schema:name $name .
$company schema:legalName ($abbr $name).
$company rdf:type schema:Organization .
$company schema:description $description .
$employee rdf:type schema:Person .
$employee schema:givenName $fname .
$employee schema:additionalName $pname .
$employee schema:familyName $sname .
$employee schema:jobTitle $post .
$company schema:employee $employee .
$company schema:member $member
}
WHERE
{ $company ont:CompanyName "АССОЛЬ" .
$company ont:CompanyName $name .
OPTIONAL {$x ont:CompanyAbbrev $abbr } .
OPTIONAL {$company ont:CompanyDescr $description }.
OPTIONAL {$employee rdf:type<http://www.co-ode.org/ontologies/ont.owl#Fdo> }.
OPTIONAL {$employee ont:Fio_Surname $sname }.
OPTIONAL {$employee ont:Fio_FirstName $fname }.
OPTIONAL {$employee ont:Fio_Patronymic $pname }.
OPTIONAL {$employee ont:Post $post }.
OPTIONAL {$member ont:CompanyName $mname .
45
FILTER regex($mname, !"АССОЛЬ", "i")}
}
LIMIT 1
В
результате
выполнения
такого
запроса
сформируется
RDF-граф,
содержащий информацию о компании, найденную в тексте документа.
ГЛАВА 3. ПРАКТИЧЕСКАЯ РЕАЛИЗАЦИЯ АЛГОРИТМА ОБОГАЩЕНИЯ ВЕБСТРАНИЦ СЕМАНТИЧЕСКИМИ ДАННЫМИ
3.1 ОБЩИЙ ВИД АЛГОРИТМА
На первом этапе программа получает исходный код страницы, вводимый
одним из следующих способов:
 прямой ввод;
 чтение из файла;
 ввод URL
Полученный текст подвергается лингвистическому анализу и извлечению
атомарных фактов. Для этого он передается в качестве входного параметра
API Томита-парсера (Приложение 1. ProcessViewModel), который производит
токенизацию, морфологический и синтаксический анализ и извлекает из
отдельных предложений факты, основываясь при этом на цепочках
бесконтекстных грамматик. Правила могут иметь вид:
//правило, позволяющее извлекать из текста названия музеев вида «Московский
Музей А.С.Пушика»
MuseumW -> 'музей' | 'музей-квартира' | 'центр' | 'фонд';
CompLongName_
->
NPAdjConj<gnc-agr[1]>*
MuseumW<gnc-agr[1],rt>
FIO_<gram='род'> {weight=0.5};
Первичный набор фактов унифицируется, сериализуется в формат RDF/XML
(Приложение 2. XmlRdfParser)
Далее с помощью набора правил, описанных в разделе «2.4 Соотнесение
сущностей в тексте с онтологическими классами», записанных в виде
46
SPARQL-запросов
производится
семантическое
представление
объединение
отдельных
текста
фактов
(Приложение
в
3.
RDFQUERYVIEWMODEL).
Например, простейший запрос
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?company ?members
WHERE
{<http://www.co-ode.org/ontologies/ont.owl#CompanyName>
rdfs:domain ?company .
?members rdf:type ?company }
вернет все экземпляры классов, имеющих свойство CompanyName
Рисунок 9 экземпляры классов, обладающих свойством CompanyName
На последнем этапе происходит подготовка результатов: перегенерация
исходного документа с учетом знаний, извлеченных на предыдущих этапах и
сохраненных в виде RDF/XML файла.
3.2 ПОЛУЧЕНИЕ НАЧАЛЬНОГО ЗАПАСА ФОРМУЛ
47
Начальный запас формул из исходного кода страницы получается с помощью
API Томита-парсера и конвертера XMLRDF.
Как уже говорилось в разделе «2.2 Поиск сущностей на основе лексического
анализа текста», в основе работы Томита-парсера лежат бесконтекстные
грамматики. Томитные грамматики работают с цепочками. Одна цепочка
соответствует одному предложению в тексте. Из цепочки выделяются
подцепочки, которые, в свою очередь, интерпретируются в разбитые по
полям факты.
В Таблица 3 перечислены типы файлов, которые используются в работе
парсера. На момент написания работы использовалось около 50 словарей и
грамматик.
Таблица 3 Исходные файлы, используемые при запуске Томита-парсера
Содержание
Формат
Примечания
config.proto —
Protobuf
Нужен всегда.
dic.gzt — корневой словарь. Protobuf
/ Нужен всегда.
конфигурационный
файл
парсера. Сообщает парсеру,
где
искать
все
файлы,
остальные
как
интерпретировать
их
и
что
делать.
Содержит
перечень
используемых
в
всех Gazetteer
проекте
словарей и грамматик.
48
mygram.cxx — грамматика
Язык
описания Нужен, если в проекте
грамматик
используются
грамматики.
файлов
Таких
может
быть
несколько.
facttypes.proto —
описание Protobuf
типов фактов
Нужен, если в проекте
порождаются
факты.
Парсер запустится без
него, но фактов не
будет.
kwtypes.proto —
описания Protobuf
типов ключевых слов
Нужен, если в проекте
создаются новые типы
ключевых слов.
Для составления словарей и грамматик используются лингвистические
признаки характеристик организаций, выделенные при анализе предметной
области, в частности, перечисленные в Таблица 2.
После обработки входного файла получаем выходной файл в формате XML,
заданном файлом facttypes.proto и XML схемой. Первый определяет, какие
именно факты будут извлекаться, а второй – в каком формате они будут
записаны. Пример выходного XML-файла:
<CompanyDescr
FactID="0"
LeadID="0"
FieldsInfo="n0;n1;"
len="14" sn="29" fw="26" lw="27">
<CompanyName val="ABBYY" />
<CompanyDescr val="КОМПАНИЯ" info="*компания;" />
<CompanyIsLemma val="1" />
</CompanyDescr>
49
pos="4509"
На Рисунок 10 и
Рисунок 11 показан пример табличного отображения
извлеченных из текста.
Рисунок 10 Пример извлеченных из текста данных
Рисунок 11 Пример извлеченных из текста данных
RDF-словарь содержит описание классов фактов, которые могут быть
порождены парсером и их свойств. Все классы в словаре унаследованы от
FdoDS, имеющего ряд общих для всех фактов свойств. Фрагмент онтологии,
описывающий класс:
<!-- http://www.co-ode.org/ontologies/ont.owl#CompanyDescrFact -->
<owl:Class rdf:about="&ont;CompanyDescrFact">
<rdfs:subClassOf rdf:resource="&ont;CompanyDescr"/>
<rdfs:subClassOf rdf:resource="&ont;FdoDS"/>
50
</owl:Class>
Фрагмент, описывающий свойства:
<!-- http://www.co-ode.org/ontologies/ont.owl#CompanyName -->
<owl:DatatypeProperty rdf:about="&ont;CompanyName">
<rdfs:range rdf:resource="&xs;#string"/>
<rdfs:domain>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<rdf:Description rdf:about="&ont;Company"/>
<rdf:Description rdf:about="&ont;CompanyDescr"/>
<rdf:Description rdf:about="&ont;FDOFact"/>
<rdf:Description rdf:about="&ont;UniqueCompany"/>
</owl:unionOf>
</owl:Class>
</rdfs:domain>
</owl:DatatypeProperty>
Файл, получаемый в результате работы парсера, конвертируется в формат
RDF-триплетов таким образом, чтобы соответствовать RDF-словарю.
Отображение xml-файлов на онтологию осуществляется с помощью правил,
описанных в [20] (Рисунок 12)
51
Рисунок 12 Cоответствие элементов XML Schema элементам OWL
Пример сущности, извлеченной из текста:
<owl:NamedIndividual
rdf:about="http://www.co-
ode.org/ontologies/ont.owl#0">
<rdf:type
rdf:resource="http://www.co-
ode.org/ontologies/ont.owl#CompanyDescr" />
<ont:FactID>0</ont:FactID>
<ont:LeadID>0</ont:LeadID>
<ont:FieldsInfo>n0;n1;</ont:FieldsInfo>
<ont:pos>4509</ont:pos>
<ont:len>14</ont:len>
<ont:sn>29</ont:sn>
<ont:fw>26</ont:fw>
<ont:lw>27</ont:lw>
<ont:CompanyName>ABBYY</ont:CompanyName>
<ont:CompanyDescr>КОМПАНИЯ</ont:CompanyDescr>
<ont:CompanyIsLemma>1</ont:CompanyIsLemma>
</owl:NamedIndividual>
52
3.3 КОНСТРУИРОВАНИЕ ОБЪЕКТА, ОПИСЫВАЮЩЕГО ГЛАВНУЮ СУЩНОСТЬ
НА СТРАНИЦЕ
Как писалось выше, для определения главной сущности используются
статистические признаки, признаки, основанные на расположении первого
упоминания сущности в тексте, а также на основании окружающих тегов. В
первую очередь с помощью запроса следующего вида:
PREFIX
PREFIX
PREFIX
PREFIX
rdf:
owl:
xsd:
ont:
<http://www.w3.org/1999/02/22-rdf-syntax-ns#>
<http://www.w3.org/2002/07/owl#>
<http://www.w3.org/2001/XMLSchema#>
<http://www.co-ode.org/ontologies/ont.owl#>
SELECT (COUNT (DISTINCT ?company) as ?cnt) WHERE
{
?company ont:CompanyName ?name .
FILTER(regex (?name, {1}, "i")) .
}
считается количество упоминаний каждого названия компании ({1}
заменяется на названия компаний из RDF-файла с результатами работы
парсера). Выбираются первые позиции и сравниваются по номеру позиции
первого упоминания в тексте. Та организация, которая встретилась в тексте
первой и при этом набрала наибольшее количество упоминаний, признается
победителем.
Имя победителя передается в качестве параметра {2} следующему запросу,
конструирующему описание главной сущности на основе трех RDF-графов:
словаря schema.org, словаря, описывающего типы фактов, порождаемые при
работе парсера и RDF-файла, являющегося результатом работы парсера.
Запрос-конструктор может выглядеть следующим образом:
BASE <http://www.co-ode.org/ontologies/ont.owl#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX ont: <http://www.co-ode.org/ontologies/ont.owl#>
PREFIX schema: <http://schema.org/>
Construct
{$company schema:name $name .
$company schema:legalName ($abbr $name).
$company rdf:type schema:Organization .
$company schema:description $description .
53
$employee rdf:type schema:Person .
$employee schema:givenName $fname .
$employee schema:additionalName $pname .
$employee schema:familyName $sname .
$employee schema:jobTitle $post .
$company schema:employee $employee .
$company schema:member $member
}
WHERE
{ $company ont:CompanyName {2} .
$company ont:CompanyName $name .
OPTIONAL {$x ont:CompanyAbbrev $abbr } .
OPTIONAL {$company ont:CompanyDescr $description }.
OPTIONAL {$employee rdf:type<http://www.co-ode.org/ontologies/ont.owl#Fdo> }.
OPTIONAL {$employee ont:Fio_Surname $sname }.
OPTIONAL {$employee ont:Fio_FirstName $fname }.
OPTIONAL {$employee ont:Fio_Patronymic $pname }.
OPTIONAL {$employee ont:Post $post }.
OPTIONAL {$member ont:CompanyName $mname
FILTER regex($mname, !{2}"i")}
}
LIMIT 1
В
результате
выполнение
запроса
формируется
экземпляр
класса
schema.org/Organization следующего вида:
<?xml version="1.0" encoding="utf-16"?>
<!DOCTYPE rdf:RDF [
<!ENTITY rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<!ENTITY rdfs 'http://www.w3.org/2000/01/rdf-schema#'>
<!ENTITY xsd 'http://www.w3.org/2001/XMLSchema#'>
<!ENTITY owl 'http://www.w3.org/2002/07/owl#'>
<!ENTITY ont 'http://www.co-ode.org/ontologies/ont.owl#'>
<!ENTITY schema 'http://schema.org/'>
]>
<rdf:RDF
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:ont="http://www.coode.org/ontologies/ont.owl#"
xmlns:schema="http://schema.org/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<schema:Organization
rdf:about="http://www.coode.org/ontologies/ont.owl#13">
<schema:employee
rdf:resource="http://www.coode.org/ontologies/ont.owl#14" />
<schema:legalName rdf:nodeID="autos67578" />
<schema:name>АССОЛЬ</schema:name>
</schema:Organization>
<schema:Person rdf:about="http://www.co-ode.org/ontologies/ont.owl#14">
<schema:additionalName>АЛЕКСЕЕВИЧ</schema:additionalName>
<schema:familyName>КУЗЬМИН</schema:familyName>
<schema:givenName>АНДРЕЙ</schema:givenName>
<schema:jobTitle>ДИРЕКТОР</schema:jobTitle>
</schema:Person>
<rdf:Description rdf:nodeID="autos67578">
<rdf:first>ООО</rdf:first>
<rdf:rest rdf:nodeID="autos67579" />
</rdf:Description>
<rdf:Description rdf:nodeID="autos67579">
<rdf:first>АССОЛЬ</rdf:first>
<rdf:rest rdf:resource="&rdf;nil" />
</rdf:Description>
54
</rdf:RDF>
3.4 ПРОВЕРКА ОБЪЕКТА И ГЕНЕРАЦИЯ РАЗМЕТКИ
Выделенная информация предоставляется для проверки вебмастеру –
владельцу страницы (Рисунок 13). Галочками выделяются объекты, которые
должны быть включены в разметку. Значения полей могут быть изменены
пользователем. В дальнейшем планируется использовать обратную связь от
вебмастеров для совершенствования алгоритма.
Рисунок 13 Окно, содержащее информацию об объекте, выделенном из текста
После того, как данные подтверждены вебмастером, на страницу добавляется
семантическая микроразметка, сгенерированная на основе выделенной из
текста информации.
55
Разметка добавляется в скрытых мета-тегах. Это не совсем соответствует
рекомендациям ресурса schema.org, однако позволяет на первом этапе обойти
некоторые сложные моменты:
 нормализация имен и названий – названия, имена и некоторая
другая информация в тексте могут быть представлены в разной
форме, если размечать их непосредственно в тексте, то значения
полей будут отличаться от нормальной формы;
 дублирование полей – название компании, например, может
встретиться в тексте несколько раз и нет никакой необходимости
каждый раз указывать на то, что это название компании;
 интеграция информации с разных страниц.
Таким образом, после внедрения семантической микроразметки страница
приобретает следующий вид:
<HTML>
<HEAD>
<TITLE>Стартовая страница сайта</TITLE>
</HEAD>
<BODY>
<div itemscope itemtype="http://schema.org/organization">
<meta itemprop="founder" content="Шелдон Купер">
<meta itemprop="foundingDate" content="2014">
<meta itemprop="legalName" content="Бугагашечки">
</div>
<div itemscope itemtype="http://schema.org/organization">
<meta itemprop="founder" content="Иванов">
<meta itemprop="foundingDate" content="1988">
<meta itemprop="legalName" content="ABBYY">
</div>
//основное содержимое сайта
</BODY>
На данный момент предложенный здесь алгоритм реализован в виде
отдельного приложения, которое получает на входе от пользователя url или
исходный код страницы, в которую необходимо внедрить разметку, а на
выходе
генерирует
ту
же
страницу
с
уже
включенными
в
нее
семантическими данными. Такая реализация имеет ряд недостатков,
основной из которых – оторванность этого решения от процесса создания и
редактирования реального сайта.
56
Более удачным решением кажется реализация алгоритма в виде модуля к
системе управления содержимым сайта (CMS). Такой модуль может
предлагать добавить или удалить семантические данные со страниц при
каждом изменении. Это позволит избежать устаревания семантической
микроразметки, а также обеспечить интеграцию в процесс управления
содержимым
сайта.
Кроме
того, это
не потребует
от
вебмастера
дополнительных действий по размещению измененных страниц на своем
сайте, как в случае с отдельно стоящим приложением.
Таким образом, предложенное решение можно рассматривать как прототип
будущих модулей для CMS, которые используются для управления сайтами в
сети интернет.
57
ЗАКЛЮЧЕНИЕ
В настоящей работе был предложен механизм обогащения веб-страниц
семантическими
данными,
реализованный
в
виде
приложения
для
вебмастеров и владельцев сайтов.
Новизна данной работы заключается в предложении совместить ручной и
автоматический подход к извлечению знаний, а также структурирование
существующих веб-страниц посредством добавления к ним извлеченных
знаний.
Совмещение ручного и автоматического подхода к извлечению знаний
позволяет ускорить процесс, увеличить полноту, при этом, не снижая
качества (за счет применения ручной валидации полученных результатов
создателями страниц). Обогащение веб-страниц посредством добавления к
ним извлеченных знаний в отличие от их хранения в отдельной базе позволит
достичь следующих положительных результатов:
1. Связанность обновлений данных на странице с обновлением ее
смыслового содержимого
2. Повторное использование знаний. За счет хранения в открытом виде
семантического содержимого страницы оно может быть использовано
разными потребителями.
Семантическая микроразметка сейчас используется поисковыми системами
для генерации специальных структурированных сниппетов (представлений
сайта в результатах поисковой выдачи) — Таблица 4, использования в
непоисковых сервисах — Таблица 5, для построения объектных ответов
(Knowledge Graph от Google) — Рисунок 14.
Использование семантической разметки различными потребителями тесно
связано с объемом и качеством такой разметки в сети. После достижения
58
определенной полноты и точности откроются широкие перспективы ее
применения не только в частных случаях, примеры которых приведены
выше, но и для решения глобальных задач: построения вопросно-ответных
систем, вывод новых знаний, накопление массива размеченных данных для
задач машинного обучения.
Таким образом, алгоритм, предложенный в данной работе, позволяет
преодолеть один из наиболее существенных барьеров
в развитии
Семантической Паутины – человеческий фактор. При этом, в отличие от
других
систем
автоматического
извлечения
фактов
из
текстов
на
естественных языках, он предполагает хранение знаний в машиночитаемом
виде там же, где хранится их представление, предназначенное для людей.
При разработке алгоритма решены следующие задачи:
 проведение лексического анализа страниц;
 извлечение фрагментов знаний о содержимом страниц;
 интеграция фрагментов знаний в единое целое в виде экземпляров
онтологии schema.org;
 создание интерфейса ручной проверки корректности извлечения
данных;
 создание страниц, с включенной в них семантической микроразметкой.
В рамках дальнейшего развития настоящего исследования запланировано:
 Реализация алгоритма в виде плагина к системе управления контентом
сайта.
 Использование
результатов
валидации
для
улучшения
работы
алгоритма.
 Связывание найденных именованных сущностей с сущностями
открытых баз знаний (Freebase, DBPedia, WikiData).
59
 Увеличение типов извлекаемых объектов (информация о людях,
статьях, книгах, фильмах и т.д.).
Помимо результатов, которые должны были быть достигнуты в рамках
реализации поставленных в начале работы задач, была получена некоторая
база организаций, представленных в русскоязычном сегменте сети интернет,
которая продолжает пополняться при каждом запуске программы. Так как
создание такой базы не было целью настоящей работы, в будущем
необходимо решить ряд вопросов для определения целесообразности ее
хранения и принципа разрешения коллизий и слияния информации из разных
объектов.
Таблица 4 Специальные сниппеты в поисковых системах
Яндекс
Google
Адреса и организации
V
V
Товары и цены
V
V
Рецепты
V
V
Словари
V
Рефераты
V
Отзывы
V
Фильмы
V
60
V
Музыка
V
V
Приложения
V
Элементы навигации
V
Люди
V
Таблица 5 Использование семантической разметки сервисами Яндекса
Вклады и кредиты
Словари
Вакансии
Отзывы об автомобилях
Отзывы об организациях
Недвижимость
Автообъявления
Видео
61
Оригинальные тексты
62
Рисунок 14 Объектный ответ Google [9]
63
ЛИТЕРАТУРА
1.
Антонов, Е.С Априорная информация, как способ разрешения
онтологической и языковой омонимии/ Е.С Антонов //Филологические
науки. Вопросы теории и практики Тамбов: Грамота, 2012. No 6 (17). C. 1519.
2.
Бездушный, А.А., Бездушный, А.Н., Нестеренко, А.К., Серебряков,
В.А., Сысоев, Т.М. RDFS как основа среды разработки цифровых библиотек
и Web-порталов / А.А. Бездушный, А.Н. Бездушный, А.К. Нестеренко, В.А.
Серебряков,
Т.М
Сысоев
//[Электронный
ресурс].
URL:
http://www.elbib.ru/content/journal/2003/200303/BBNSS/BBNSS.ru.html (дата
обращения: 25.05.2013)
3.
Беленький, А. Текстомайнинг. Извлечение информации из
неструктурированных текстов /А. Беленький //[Электронный ресурс]. URL:
http://www.compress.ru/article.aspx?id=19605&iid=905
(дата
обращения:
03.06.2013)
4.
Бонч-Осмоловская, А.А., Клинцов, В.П., Толдова С.Ю. Стратегии
интродуктивной номинации в текстах/ А.А. Бонч-Осмоловская, В.П.
Клинцов, С.Ю. Толдова// Электронное научное издание «Актуальные
инновационные исследования: наука и практика». — 2012 год, № 3
[Электронный
ресурс].
URL:
http://www.actualresearch.ru/nn/2012_3/Article/philology/bonchosmolovskaja20123.htm (дата обращения: 20.04.2013)
5.
Кононенко, И.С. Сидорова, Е.А. Подход к извлечению фактов из текста
на основе онтологий/И.С. Кононенко, Е.А. Сидорова // Сборник
«Компьютерная лингвистика и интеллектуальные технологии». — 2009
[Электронный
ресурс].
URL:
http://www.dialog21.ru/digests/dialog2009/materials/html/70.htm (дата обращения: 15.05.2013)
6.
Конференция Вебмастерская [Конференция]. URL: http://events.yandexteam.ru/events/yamasterskaya/msk-apr-2013/talks/ (дата обращения: 20.05.2013)
7.
Ресурс schema.org [Электронный ресурс] . URL: http://schema.org (дата
обращения: 01.06.2013)
8.
Сайт
компании
Яндекс
[Электронный
ресурс].
URL:
http://company.yandex.ru (дата обращения: 01.06.2013)
9.
Сайт
компании
Google
[Электронный
ресурс].
URL:
http://www.google.com/insidesearch/features/search/knowledge.html
(дата
обращения: 15.05.2013)
64
10. Сайт компании Элемент 5 [Электронный ресурс]. URL:
http://efive.ru/about/ (дата обращения: 01.06.2013)
11. Фомичев, В.А. Формализация лингвистических процессоров/В.А.
Фомичев — М.: Макс Пресс, 2005, — 368 с.
12. Фомичев, В.А. Математические основы представления содержания
посланий компьютерных интеллектуальных агентов/В.А. Фомичев — М.:
Издательский Дом ГУ-ВШЭ, 2007 — 174 с
13. API
Томита-парсера
[Электронный
ресурс].
URL:
http://api.yandex.ru/tomita/ (дата обращения: 15.03.2013)
14. Bolshakova, E., Efremova, N., Noskov, A. LSPL-Patterns as a Tool for
Information Extraction from Natural Language Texts/E. Bolshakova, N. Efremova,
A. Noskov // New Trends in Classification and Data Mining. K.Markov et al.
(Eds.). Sofia, ITHEA, 2010, p. 110-118.
15. Brickley, D., Guha, R.V. RDF Vocabulary Description Language 1.0: RDF
Schema, February 2004./D. Brickley, R.V. Guha //[Электронный ресурс]. URL:
http://www.w3.org/TR/rdf-schema/ (дата обращения: 01.02.2013)
16. Cunningham H. Developing language processing components with GATE,
Technical report / H. Cunningham, D. Maynard, K. Bontcheva et al.- University of
Sheffield, U.K., 2005 [Электронный ресурс]. URL: http://www.gate.ac.uk (дата
обращения: 05.04.2013)
17. Dobrev, P., and Strupchanska, A. (2005). Conceptual Graphs and Annotated
Semantic Web Pages, In Frithjof Dau, Marie-Laure Mugnier, Gerd Stumme (Eds.),
Common Semantics for Sharing Knowledge: Contributions to ICCS 2005 13th
International Conference on Conceptual Structures, ICCS 2005, Kassel, Germany,
ISBN 3-89958-138-5, pp. 54-65. July 1, 2005.
18. Norbaitiah, A., Dickson, L. Enriching Webpages with Semantic Information
/A. Norbaitiah, L. Dickson. //Malaysia
19. Fomichov, V.A. Semantics-Oriented Natural Language Processing:
Mathematical Models and Algorithms // IFSR International Series on Systems
Science and Engineering, Vol. 27. Springer: New York, Dordrecht, Heidelberg,
London, 2010.-354 p.
20.
IRI
//
Википедия
[Электронный
ресурс].
URL:
http://ru.wikipedia.org/wiki/IRI (дата обращения 03.03.2013)
21. Mapping XML to OWL Ontologies [Электронный ресурс]. URL:
http://www.informatik.uni-leipzig.de/~auer/publication/xml2owl.pdf
(дата
обращения: 23.05.2013)
22. Ontology-Based Information Extraction: An Introduction and a Survey of
Current
Approaches
[Электронный
ресурс].
URL:
65
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.153.8077&rep=rep1&ty
pe=pdf (дата обращения: 22.05.2013)
23. OWL version of schema.org [unofficial] [Электронный ресурс]. URL:
http://topbraid.org/schema/ (дата обращения: 28.05.2013)
24. RDF
CURRENT
STATUS
[Электронный
ресурс].
URL:
http://www.w3.org/standards/techs/rdf#w3c_all (дата обращения: 16.05.2013)
25. Semantic Web Revisited // IEEE Intelligent Systems — 06.2006
26. SPARQL-DL: SPARQL Query for OWL-DL [Электронный ресурс]. URL:
http://ceur-ws.org/Vol-258/paper14.pdf (дата обращения: 22.05.2013)
27. SPARQL Query Language for RDF DL [Электронный ресурс]. URL:
http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/ (дата обращения:
02.06.2013)
28. Studholme, O. Using schema.org vocabularies. — 2011 [Электронный
ресурс].
URL:http://html5doctor.com/microdata/#schema-org-vocab
(дата
обращения: 13.02.2013)
29. The Semantic Web // Scientific American — 17.05.2001
30. Xian, B.C.M., Zahari, F., and Lukose, D. Benchmarking T-ANNE for
Named Entity Recognition/B.C.M. Xian, F. Zahari, D. Lukose // In Proceedings of
12th International Conference on Knowledge Management and Knowledge
Technologies (i-KNOW) — 2012
66
ПРИЛОЖЕНИЕ 1. PROCESSVIEWMODEL
using System;
using System.ComponentModel;
using System.Diagnostics;
using System.IO;
using System.Net;
using System.Linq;
using System.Xml.Linq;
using System.Text.RegularExpressions;
using System.Text;
namespace SemanticDataEnrichment.Core
{
/// <summary>
/// Модель-диспетчер, обеспечивающая логику работы с Томита-консолью
/// </summary>
public class ProcessViewModel : ViewModelBase
{
private string tomitaPath;
private string tomitaConfigPath;
private string tomitaOutputFileName;
private string tomitaInputFileName;
private string rdfOutputFileName;
/// <summary>
/// Модель-диспетчер, обеспечивающая логику работы с Томита-консолью
/// </summary>
/// <param name="tomitaPath">Путь к томита-консоли</param>
/// <param name="tomitaConfigPath">Путь к фалу-конфигу томиты</param>
/// <param name="tomitaInputFileName">Имя для временного файла со входным
текстом для томиты</param>
/// <param name="tomitaOutputFileName">Имя файла, возвращаемого
томитой</param>
/// <param name="rdfOutputFileName">Имя файла для сохранения
сконвертированных данных</param>
public ProcessViewModel(string tomitaPath, string tomitaConfigPath, string
tomitaInputFileName, string tomitaOutputFileName, string rdfOutputFileName)
{
this.tomitaPath = tomitaPath;
this.tomitaConfigPath = tomitaConfigPath;
this.tomitaOutputFileName = tomitaOutputFileName;
this.tomitaInputFileName = tomitaInputFileName;
this.rdfOutputFileName = rdfOutputFileName;
URL = "http:\\\\";
}
#region PublicProperties
private string fileName;
/// <summary>
/// Имя файла для загрузки данных в TextData
/// </summary>
67
public string FileName
{
get { return this.fileName; }
set
{
this.fileName = value;
OnPropertyChanged("FileName");
}
}
private string url;
/// <summary>
/// URL HTTP-протокола для загрузки данных в TextData
/// </summary>
public string URL
{
get { return this.url; }
set
{
this.url = value;
OnPropertyChanged("URL");
}
}
private string textData;
/// <summary>
/// Данные для обработки консоли
/// </summary>
public string TextData
{
get { return this.textData; }
set
{
this.textData = value;
OnPropertyChanged("TextData");
}
}
private string processedXmlData;
/// <summary>
/// Обработанные тамитой данные (xml)
/// </summary>
public string ProcessedXmlData
{
get { return this.processedXmlData; }
private set
{
this.processedXmlData = value;
OnPropertyChanged("ProcessedXmlData");
}
}
private string processedRdfData;
68
/// <summary>
/// Сконвертированные в RDF обработанные томитой данные
/// </summary>
public string ProcessedRdfData
{
get { return this.processedRdfData; }
private set
{
this.processedRdfData = value;
OnPropertyChanged("ProcessedRdfData");
}
}
private string consoleOutput;
/// <summary>
/// Дополнительная информация, возвращаемая томитой в ходе работы (в т.ч.
ошибки)
/// </summary>
public string ConsoleOutput
{
get { return this.consoleOutput; }
private set
{
if (this.consoleOutput != value)
{
this.consoleOutput = value;
OnPropertyChanged("ConsoleOutput");
}
}
}
private bool isBusy;
/// <summary>
/// Флаг, определяющий, что выполняется какая-либо работа
/// </summary>
public bool IsBusy
{
get { return this.isBusy; }
set
{
this.isBusy = value;
OnPropertyChanged("IsBusy");
}
}
#endregion
#region PublicMethods
/// <summary>
/// Загрузить данные TextData из файла, указанного в FileName
/// </summary>
69
/// <exception cref="System.ArgumentNullException">Не задано имя фала в
FileName</exception>
/// <exception cref="System.IO.FileNotFoundException">Файл по указанному
пути не найден</exception>
/// <exception cref="System.IO.DirectoryNotFoundException"/>
/// <exception cref="System.IO.PathTooLongException"/>
/// <exception cref="System.IO.IOException"/>
/// <exception cref="System.UnauthorizedAccessException"/>
/// <exception cref="System.Security.SecurityException"/>
public void OpenFile()
{
OpenFile(this.fileName);
}
/// <summary>
/// Загрузить данные TextData из файла
/// </summary>
/// <param name="fileName">Полный путь и имя файла с данными</param>
/// <exception cref="System.ArgumentNullException">Не задано имя
фала</exception>
/// <exception cref="System.IO.FileNotFoundException">Файл по указанному
пути не найден</exception>
/// <exception cref="System.IO.DirectoryNotFoundException"/>
/// <exception cref="System.IO.PathTooLongException"/>
/// <exception cref="System.IO.IOException"/>
/// <exception cref="System.UnauthorizedAccessException"/>
/// <exception cref="System.Security.SecurityException"/>
public void OpenFile(string fileName)
{
if (String.IsNullOrWhiteSpace(fileName))
throw new ArgumentNullException("FileName", "Не определно
имя файла");
try
{
IsBusy = true;
TextData = File.ReadAllText(fileName);
}
finally
{
IsBusy = false;
}
}
/// <summary>
/// Загрузить данные TextData из интернета (протокол HTTP), по ссылке,
указанной в URL
/// </summary>
/// <exception cref="System.ArgumentNullException">Не задан URL</exception>
/// <exception cref="System.UriFormatException">Не верный URL</exception>
/// <exception cref="System.Security.SecurityException"/>
/// <exception cref="System.Net.ProtocolViolationException"/>
/// <exception cref="System.IO.IOException"/>
70
/// <exception cref="System.OutOfMemoryException"/>
public void OpenUrl()
{
OpenUrl(this.url);
}
/// <summary>
/// Загрузить данные TextData из интернета (протокол HTTP)
/// </summary>
/// <param name="url">HTTP URL</param>
/// <exception cref="System.ArgumentNullException">Не задан URL</exception>
/// <exception cref="System.UriFormatException">Не верный URL</exception>
/// <exception cref="System.Security.SecurityException"/>
/// <exception cref="System.Net.ProtocolViolationException"/>
/// <exception cref="System.IO.IOException"/>
/// <exception cref="System.OutOfMemoryException"/>
public void OpenUrl(string url)
{
if (String.IsNullOrWhiteSpace(url))
throw new ArgumentNullException("URL", "Не определен
URL");
try
{
IsBusy = true;
WebRequest request = WebRequest.Create(url);
using (HttpWebResponse response =
(HttpWebResponse)request.GetResponse())
{
string responseText = (new
StreamReader(response.GetResponseStream(),
System.Text.Encoding.GetEncoding(response.CharacterSet))).ReadToEnd();
//stringstr = "<h1>Получить текст HTML C#
отсюда</h1>";
//Regex reg = new Regex("<[^>]+>",
RegexOptions.IgnoreCase);
//TextData = reg.Replace(responseText, "");
TextData = responseText;
}
}
finally
{
IsBusy = false;
}
}
/// <summary>
/// Обработать текст из TextData
/// </summary>
71
public void ProcessText()
{
ProcessText(this.textData);
}
/// <summary>
/// Обработать заданный текст
/// </summary>
/// <param name="textData">Текст для обработки</param>
/// <exception
cref="SemanticDataEnrichment.Core.WorkConsloeException">Ошибки при работе консоли</exception>
public void ProcessText(string textData)
{
if (String.IsNullOrWhiteSpace(textData))
throw new ArgumentNullException("TextData", "Не задан
текст для обработки");
try
{
IsBusy = true;
File.WriteAllText(this.tomitaInputFileName, textData);
if (File.Exists(this.tomitaOutputFileName))
File.Delete(this.tomitaOutputFileName);
if (File.Exists(this.rdfOutputFileName))
File.Delete(this.rdfOutputFileName);
ProcessTomitaConsole(this.tomitaConfigPath);
if (File.Exists(this.tomitaOutputFileName))
{
XmlRdfParser parser = new XmlRdfParser();
parser.ConvertXmlRdf(this.tomitaOutputFileName,
this.rdfOutputFileName);
ProcessedXmlData =
XmlRdfParser.GetFormattedStringFromXmlFile(this.tomitaOutputFileName);
ProcessedRdfData =
XmlRdfParser.GetFormattedStringFromXmlFile(this.rdfOutputFileName);
}
else
{
ProcessedXmlData = String.Empty;
ProcessedRdfData = String.Empty;
}
}
finally
{
IsBusy = false;
}
}
/// <summary>
/// Очищает переменные вывода (ConsoleOutput, ProcessedXmlData,
ProcessedRdfData)
72
/// </summary>
public void ClearOutput()
{
ConsoleOutput = String.Empty;
ProcessedXmlData = String.Empty;
ProcessedRdfData = String.Empty;
}
public Version GetCurrentVersion()
{
return
System.Reflection.Assembly.GetExecutingAssembly().GetName().Version;
}
#endregion
#region PrivateMethods
private void ProcessTomitaConsole(string consoleArguments)
{
if (!File.Exists(this.tomitaPath))
throw new Exception(String.Format("Не найдена томита по пути {0}",
this.tomitaPath));
using (Process workConsole = new Process()
{
StartInfo = new ProcessStartInfo(this.tomitaPath,
consoleArguments)
{
UseShellExecute = false,
RedirectStandardOutput = true,
RedirectStandardError = true,
CreateNoWindow = true,
},
})
{
if (workConsole.Start())
{
using (StreamReader consoleErrors = new
StreamReader(workConsole.StandardError.BaseStream, Encoding.UTF8))
{
using (StreamReader consoleOutoput =
new StreamReader(workConsole.StandardOutput.BaseStream, Encoding.UTF8))
{
string errors =
consoleErrors.ReadToEnd();
ConsoleOutput =
consoleOutoput.ReadToEnd();
ConsoleOutput += errors;
workConsole.WaitForExit();
}
73
}
}
else
throw new Exception("Не удалось инициализировать
процесс томиты");
}
}
#endregion
}
}
74
ПРИЛОЖЕНИЕ 2. XMLRDFPARSER
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using System.Xml.Linq;
namespace SemanticDataEnrichment.Core
{
/// <summary>
/// Конвертирование xml-ответов томиты в rdf-документы и/или файлы для дальнейшей
обработки
/// </summary>
internal class XmlRdfParser
{
private Dictionary<string, XNamespace> namespaces;
public XmlRdfParser()
{
this.namespaces = new Dictionary<string, XNamespace>()
{
{"rdf", "http://www.w3.org/1999/02/22-rdf-syntax-ns#"}
, {"owl", "http://www.w3.org/2002/07/owl#"}
, {"ont", "http://www.co-ode.org/ontologies/ont.owl#"}
};
}
#region PublicMethods
/// <summary>
/// Конвертирует xml-ответ томиты в rdf-документ
/// </summary>
/// <param name="source">xml-ответ томиты</param>
/// <returns>rdf-документ</returns>
public XDocument ConvertXmlRdf(XElement source)
{
XDocument outputRdf = CreateEmptyRdfDocument();
XElement root = CreateEmptyRoot();
outputRdf.Add(root);
XElement facts = source.Descendants("facts").FirstOrDefault();
if (facts == null)
return outputRdf;
foreach (XElement fact in facts.Elements())
{
XElement namedIndividual = new XElement(
this.namespaces["owl"] +
"NamedIndividual"
75
, new
XAttribute(this.namespaces["rdf"] + "about", this.namespaces["ont"].NamespaceName +
fact.Attribute("FactID").Value)
, new XElement(this.namespaces["rdf"]
+ "type", new XAttribute(this.namespaces["rdf"] + "resource",
this.namespaces["ont"].NamespaceName + fact.Name.LocalName))
);
foreach (XAttribute attrib in fact.Attributes())
namedIndividual.Add(new
XElement(this.namespaces["ont"] + attrib.Name.LocalName, attrib.Value));
foreach (XElement prop in fact.Elements())
namedIndividual.Add(new
XElement(this.namespaces["ont"] + prop.Name.LocalName, prop.Attribute("val").Value));
root.Add(namedIndividual);
}
return outputRdf;
}
/// <summary>
/// Конвертирует xml-ответ томиты в rdf-документ, который сохраняет в файл
/// </summary>
/// <param name="source">xml-ответ томиты</param>
/// <param name="destFileName">Имя файла для сохранения результата</param>
/// <returns>rdf-документ</returns>
public XDocument ConvertXmlRdf(XElement source, string destFileName)
{
XDocument outputRdf = ConvertXmlRdf(source);
outputRdf.Save(destFileName);
return outputRdf;
}
/// <summary>
/// Конвертирует xml-файл (итог работы томиты) в rdf-документ, который
сохраняет в файл
/// </summary>
/// <param name="sourceFileName">Имя файла с xml-ответом томиты</param>
/// <param name="destFileName">Имя файла для сохранения результата</param>
/// <returns>rdf-документ</returns>
public XDocument ConvertXmlRdf(string sourceFileName, string destFileName)
{
XElement source =
XElement.Parse(File.ReadAllText(sourceFileName));
return ConvertXmlRdf(source, destFileName);
}
#endregion
#region StaticMethods
/// <summary>
/// Возвращает отформатированный переносами строк и пробелами текст
76
/// </summary>
/// <param name="fileName">Файл с xml-данными</param>
/// <returns>Отформатированный текст</returns>
public static string GetFormattedStringFromXmlFile(string fileName)
{
return XDocument.Parse(File.ReadAllText(fileName)).ToString();
}
#endregion
#region PrivateMethods
/// <summary>
/// Создает пустой XDocument с шапкой rdf семантики, заполненной "по
умолчанию"
/// </summary>
private XDocument CreateEmptyRdfDocument()
{
string internalSubset = @"<!ENTITY mstns
""http://tempuri.org/FdoDS.xsd"" >
<!ENTITY owl ""http://www.w3.org/2002/07/owl#"" >
<!ENTITY xs ""http://www.w3.org/2001/XMLSchema"" >
<!ENTITY xsd ""http://www.w3.org/2001/XMLSchema#"" >
<!ENTITY msprop ""urn:schemas-microsoft-com:xml-msprop"" >
<!ENTITY msdata ""urn:schemas-microsoft-com:xml-msdata"" >
<!ENTITY rdfs ""http://www.w3.org/2000/01/rdf-schema#"" >
<!ENTITY ont ""http://www.co-ode.org/ontologies/ont.owl#"" >
<!ENTITY rdf ""http://www.w3.org/1999/02/22-rdf-syntax-ns#"" >";
return new XDocument(new XDocumentType("rdf:RDF", null, null,
internalSubset));
}
/// <summary>
/// Создает пустой корневой тег с прописанными неймспейсами для rdf
документа
/// </summary>
private XElement CreateEmptyRoot()
{
XElement root = new XElement(this.namespaces["rdf"] + "RDF");
foreach (string namespacePrefix in this.namespaces.Keys)
root.Add(new XAttribute(XNamespace.Xmlns +
namespacePrefix, namespaces[namespacePrefix].NamespaceName));
return root;
}
#endregion
}
}
77
ПРИЛОЖЕНИЕ 3. RDFQUERYVIEWMODEL
using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Linq;
using System.Text;
using VDS.RDF;
using VDS.RDF.Parsing;
using VDS.RDF.Query;
using VDS.RDF.Writing;
namespace SemanticDataEnrichment.Core
{
/// <summary>
/// Модель для отправки Sparql запросов к файлам, перечисленным в FilesToQuery
/// </summary>
public class RdfQueryViewModel : ViewModelBase
{
public RdfQueryViewModel()
{
this.filesToQuery = new ObservableCollection<FilePath>();
}
#region PublicProperties
private ObservableCollection<FilePath> filesToQuery;
/// <summary>
/// Список путей к файлам, к которым нужно сделать запрос.
/// Файлы перезагружаются при каждом запросе
/// </summary>
public ObservableCollection<FilePath> FilesToQuery
{
get { return filesToQuery; }
}
private string sparqlQueryText;
/// <summary>
/// Текст запроса для метода ExecuteQuery()
/// </summary>
public string SparqlQueryText
{
get { return this.sparqlQueryText; }
set
{
this.sparqlQueryText = value;
OnPropertyChanged("SparqlQueryText");
}
}
private string queryResult;
/// <summary>
/// Результат последнего Sparql-запроса
78
/// </summary>
public string QueryResult
{
get { return this.queryResult; }
private set
{
this.queryResult = value;
OnPropertyChanged("QueryResult");
}
}
#endregion
#region PublicMethods
/// <summary>
/// Добавляет в коллекцию FilesToQuery ссылку на файл
/// </summary>
/// <param name="filePath">Имя файла</param>
public void AddRdfFile(string filePath)
{
FilesToQuery.Add(new FilePath(filePath));
}
/// <summary>
/// Выполнение Sparql-запроса из SparqlQueryText
/// </summary>
/// <returns>Результат запроса в виде текста</returns>
public string ExecuteQuery()
{
return ExecuteQuery(this.sparqlQueryText);
}
/// <summary>
/// Выполнение Sparql-запроса
/// </summary>
/// <param name="sparqlCommandText">Текст Sparql-запроса</param>
/// <returns>Результат запроса в виде текста</returns>
public string ExecuteQuery(string sparqlCommandText)
{
using (Graph baseGraph = new Graph())
{
RdfXmlParser fileParser = new RdfXmlParser();
foreach (string fileName in FilesToQuery)
{
if (String.IsNullOrWhiteSpace(fileName))
continue;
using (Graph g = new Graph())
{
try
79
{
fileParser.Load(g,
fileName);
baseGraph.Merge(g);
}
catch (Exception ex)
{
throw new
Exception(String.Format("Ошибка при обработке файла {0}\r\n{1}",fileName, ex.Message),
ex);
}
}
}
var resultSet =
baseGraph.ExecuteQuery(sparqlCommandText);
if (resultSet is SparqlResultSet)
{
SparqlResultSet outputSet = resultSet as
SparqlResultSet;
if (outputSet.IsEmpty)
QueryResult = "Пустой результат";
else
{
StringBuilder outputString = new
StringBuilder();
foreach (SparqlResult result in
outputSet.Results)
outputString.AppendLine(result.ToString());
QueryResult =
outputString.ToString();
}
}
else if (resultSet is Graph)
{
Graph resultGraph = resultSet as Graph;
if (resultGraph.IsEmpty)
QueryResult = "Пустой граф";
else
QueryResult =
VDS.RDF.Writing.StringWriter.Write(resultGraph, new RdfXmlWriter());
}
else
{
QueryResult = string.Format("Неизвестный
результат: {0}", resultSet.GetType());
}
80
return QueryResult;
}
}
#endregion
}
}
81
82