serge_gorshkov


Сергей Горшков - о бизнесе в сфере ИТ

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


Previous Entry Share Next Entry
Редактор онтологий на естественном языке
serge_gorshkov
Одна из серьезных проблем продвижения семантических технологий в массы состоит в необходимости разработки или выбора онтологий для каждого практического применения. У этой проблемы есть философская грань (как именно из разрабатывать, с точки зрения структуры? должны ли существовать универсальные, всеобъемлющие онтологии?), которую я рассмотрю отдельно. И есть технологический аспект, который состоит в том, что нужно научить человека, хорошо разбирающегося в моделировании информационных структур, и в предметной области, работать с редактором онтологий. Популярные на сегодняшний день редакторы, Protege и TopBraid Composer, не так уж просты, и ориентированы скорее на пользователя-ИТшника.
Соответственно, очень хорошо было бы иметь инструмент, который позволит делать это "непосвященным" людям. И вот, на CeBIT'е я познакомился с представителями польской компании Cognitum, которая разрабатывает семантический фреймворк Ontorion, частью которого является редактор Fluent Editor, позволяющий создавать онтологии на подмножестве естественного языка - Controlled English. Интересующимся этой темой предлагаю обзор редактора, помещенный мной на habrahabr.ru. Есть надежда сделать русскую локализацию этого редактора, и, соответственно, вместо Controlled English получить Controlled Russian - было бы еще интереснее.

  • 1
" Controlled Russian - было бы еще интереснее"
Что-то сомнительно.

Во-первых, русский язык сам по себе, по своей грамматике, иной, недели английский. Например, порядок слов в предложении не закреплен. А уж с падежами-родами что делать? Все случаи рассматривать?

Каждый поставщик есть организация.
Каждый (каждая?) "головная организация" является организация (организацией?)
Все поставщики - организации.

Во-вторых, в нашей реальности скорее актуальны индийские или китайские локализации.

Я смотрю, упоминание об индийских программистах за 5 евро в час в одном из моих предыдущих постов было воспринято всерьез? :))
На самом деле, и в российской действительности хватает применений для такого редактора, так что Controlled Russian актуален. Польскую версию они же для себя сделали - а польский по грамматической структуре, подозреваю, ближе к русскому, чем к английскому.
Создать такой язык можно, только ограничения синтаксиса будут менее очевидны, чем в английском. В первую очередь, как ты правильно заметила, из-за пропуска глагола "быть", характерного для нашего языка. С падежами и числами то еще можно справиться, они более или менее поддаются алгоритмизации.
"Каждый" и "все" можно сделать синонимами, "есть" и тире - тоже. Тогда можно будет сказать и "каждый поставщик есть организация", и "все поставщики - организации".

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

Насчет вычислительной сложности - это вы в точку. С этим в семантике вообще тихий ужас, и некоторые очень стараются его усугубить :) Я обязательно рассмотрю эту тему детально, материала уже полно накопилось.
Запросы на SPARQL строятся тоже не так чтобы очень уж очевидно. Пример можно посмотреть еще в одной недавней статье, на тему передачи данных ISO 15926 при помощи "Бизнес Семантики": http://www.business-semantic.ru/iso15926/usecase
Там в кейсе обрабатываются довольно банальные сведения - значения температуры, которые выдает некий датчик. Поместить эту информацию в формат, соответствующий стандарту ISO 15926, кое-как получается. Но вот работать с ней потом, в сравнении с реляционными БД - просто очень неудобно.
Вывод, на самом деле, простой: у каждой технологии должна быть своя сфера применения, и не нужно сейчас пытаться все реляционные БД переделать в семантические. Такая сложность оправдана в том случае, если мы имеем дело с непредсказуемым набором типов данных, с постоянно меняющейся моделью.


Edited at 2013-05-08 04:49 pm (UTC)

Я увидел на хабре вашу статью, но там я рид-онли, поэтому хочу спросить здесь.
"""
В качестве библиотеки-основы рассматривается JORD RDL, вопрос сейчас стоит в выборе инструмента для работы.
"""
Вы подписаны на dot15926, чем этот редактор не устраивает? Он же просто создан именно для использования JORD RDL.

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

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

  • 1
?

Log in

No account? Create an account