проблемы и методы - Рабочая группа симпозиума

ОНТОЛОГИЧЕСКАЯ ИНЖЕНЕРИЯ:
ПРОБЛЕМЫ И МЕТОДЫ
Рубашкин В. Ш.
Санкт-Петербургский государственный университет
Кафедра информационных систем
факультета филологии и искусств
Предварительные замечания
Концептуальное моделирование – область, не имеющая прочных
дисциплинарных традиций.
«Междисциплинарная» или «бездисциплинарная»?
«Где готовят…?»
«Инженерия знаний»?
Общая ситуация: «Технология впереди методологии»
В такой области само трудное – понять, о чем следует спрашивать,
какие вопросы актуальны.
.
Основные проблемы:
1) Функциональность и границы онтологии
(и функциональность инструментальной среды)
2) Методология формализации знаний
3) Унификация онтологий
4) Пополнение онтологий
5) Достоверность и целостность
1) Функциональность и границы онтологии
Необходимо – через определение функциональности обозначить четкую границу между онтологией и другими
теоретическими и практическим системами, так или иначе
ориентированными на представление знаний:
• база знаний;
• концептуальная модель предметной области;
• информационно-поисковый тезаурус;
• идеографический словарь;
• нормативный словарь;
• экспертная система;
• …?
Существенны три пункта:
a) Концептуальная структура
b) Формальная модель
c) Вычислительная функциональность
a) Концептуальная структура
единицы – понятия, а не слова!
•
Проблема выбора и уровня детализации единиц
•
•
•
Статус служебных единиц (большая величина)
Распознавание единиц в текстах
Граница между понятиями и лексическими вариантами
(напр., линейные размеры, цвета и оттенки)
Учет особенностей концептуального фрагментирования
реальности в разных национальных языках.
(…)
•
Решение - опора на эмпирически сложившуюся понятийнотерминологическую систему (энциклопедические и толковые
словари!),
которая фиксирует уже выполненную и постоянно корректируемую
в большинстве профессиональных областей работу по
систематизации и логической обработке терминологии.
b) Формальная модель
Формализованное (посредством некоторого ЯПЗ) описание
концептуальной системы, специфицирующее:
а) используемую классификацию концептов
б) набор допустимых парадигматических отношений между
концептами
в) аксиомы и правила вывода
c) Вычислительная функциональность
Онтология – это информационно-вычислительный ресурс,
доступный любым интеллектуальным информационным
технологиям.
(а не просто словарь или формальная система)
Технически – исполняемый модуль + наборы данных,
представляющих собственно концептуальный словарь
Формально –набор функций вида :
F (D),
F (D1, D2)
В том числе логические связи между концептами:
R_Extension (D1, D2) = tzInclude12
Востребованная в реальной практике функциональность онтологий
может быть выяснена путем сопоставления реальных
приложений, прокламирующих опору на онтологии с широким
спектром возможных функций.
Handbook on Ontologies (Karlsrue):
• Knowledge Management
• Content Management in a Virtual Organization
• Recommender Systems
• The Knowledge Portal “OntoWeb”
• Ontologies and Hypertext
• Semantic Layering with Magpie
• eLearning
• Process Specification Language
• eCommerce
• Ontology-based Platform for Semantic Interoperability
• Bioinformatics
Gomez-Perez et al.:
• E-commerce
• Medical ontologies
• Engineering ontologies
• Enterprise ontologies
• Chemistry ontologies
• Knowledge management ontologies
Обобщенные применения:
•Semantic Web
•Natural Language Understanding
(и, в частности, Information Extracting)
•Интеллектуальный интерфейс к РБД (Sense Transparent Access)
Собственно функциональность:
• Унификация терминологии
• Представление и логическая обработка таксономических
отношений
• Представление и логическая обработка отношений объемной
совместимости/несовместимости
• Представление и логическая обработка предметноассоциативных отношений
• Поддержка представления и логической обработки
количественных данных
• Регламентация процедур описания объектов
• Аксиоматизация описаний процессов, причинных связей,
процедур
-
===============================
Где начинается и где кончается онтология?
2) Методология формализации знаний
a) Формальная модель
Модель знаний vs язык-оболочка (ср. OKBC и OWL)
Модель знаний - язык представления знаний (ЯПЗ) вместе с
некоторым набором схем аксиом, определяющих
возможности системы вывода.
В онтологии используется для формального описания
эмпирически сложившейся понятийно-терминологической
системы посредством представления терминов и связей
между ними как конструктов выбранного ЯПЗ, в идеале –
как логических формул некоторого логического
исчисления. Как правило, в модель знаний вводятся
ограничения, касающиеся как выразительных
возможностей, так и допустимых схем логического вывода.
Модель знаний играет определяющую на всех этапах
разработки и использования онтологии.
b) Собственно методология формализации
Отсутствие разработанной методологии формализации знаний
- самый слабый пункт всего направления «Концептуальное
моделирование».
«Математический стиль» мышления и изложения
vs
задачи систематической организации эмпирически данного
языкового материала
Нельзя сказать, что ничего не делается, но не сформулировано
никакого систематического подхода.
Наглядной иллюстрацией этого тезиса можно считать, например,
известное руководство по OWL, иллюстрирующее методы
построения онтологии на примере ПО «Виноделие».
Конкретный пример – определение несовместимости понятий
через использование таких конструкций как DisjointWith,
DisjointUnionOf и др.
<owl:Class rdf:ID="Паста">
<rdfs:subClassOf rdf:resource="#Съестное"/>
<owl:disjointWith rdf:resource="#Мясо"/>
<owl:disjointWith rdf:resource="#Дичь"/>
<owl:disjointWith rdf:resource="#Морепродукты"/>
<owl:disjointWith rdf:resource="#Десерт"/>
<owl:disjointWith rdf:resource="#Фрукты"/>
</owl:Class>
Создается явное впечатление, что предлагается описывать
отношение объемной несовместимости способом «каждый с
каждым»
- Ср. «Русский семантический словарь»!
Что следовало бы сделать (написать еще одно руководство):
•
Продукты питания
по консистенции:
• Твердые
• Жидкие (напитки)
• Пастообразные (паста)
• Неоднородной консистенции*
по происхождению:
• Животного происхождения
Виды продуктов животного происхождения:
• Мясо /птица, говядина, свинина, …/
• Продукты водной среды (животного
происхождения)
• Молочные продукты
• Яйца
• Растительного происхождения
Виды продуктов растительного происхождения:
• Овощи /зеленые, красные, другие;
листовые, плодовые, корнеплоды; …/
• Фрукты
• Смешанные
• Синтетические
культивируемость:
• Культурного происхождения
• Природного происхождения
NB: Внетаксономические импликативы:
Мясо  Твердая консистенция
Дичь =df Мясо & Природного происхождения
Водка – алкогольный напиток
----------------------------------------Мясо   Водка
Нужен априорный обзор концептуальных подсистем:
Пример.
«Физические» отношения:
• Сравнение по значению признака (горячее, тяжелее, дороже)
• Пространственные отношения (вблизи)
• Мереологические отношения (содержит)
«Социальные» отношения:
• Владение
• Социальная доминация (возглавляет)
• Комуникационно-когнитивные (сообщить, обмануть, знать)
И т.д.
3) Унификация онтологий
Рассматриваются два, вообще говоря, не исключающих друг друга
пути:
• Снизу вверх – объединение и постепенное сближение частных
онтологий разной структуры (mapping & merging)
• Сверху вниз – построение общепризнанной онтологии верхнего
уровня и ее конкретизация доменными онтологиями
Реально оба направления развиваются параллельно, НО…
Дальнейшее продолжение практики построения автономных
специализированных онтологий превращается в неоправданное
расточительство ресурсов. Следующий этап, по нашему
мнению, - глобализация и методологическая универсализация
онтологического конструирования.
Настало время отчетливо сформулировать задачу построения не
"онтологий", а "Онтологии", - универсальной, с точки зрения
возможностей использования в самых разных информационных
технологиях, и всеобъемлющей, как с точки зрения
возможностей охвата профессиональных концептуальных
систем, так и с точки зрения возможностей концептуальной
интерпретации лексики естественного языка (ЕЯ) и
профессиональных подъязыков.
Единая концептуальная модель и единая технологическая среда.
Ср. SUMO и CYC
Основные требования:
Гибкость – возможность быстрого и простого обновления любого
из фрагментов онтологии;
возможность организации
децентрализованного
"многоагентного"
создания
и
редактирования онтологий.
Открытость – для добавления как отдельных концептов любого
содержания, так и любых концептуальных подсистем;
открытость для лексики ЕЯ и дополнительных вариантов
концептуальной интерпретации уже содержащихся в Лексиконе
онтологии слов.
Содержательная масштабируемость – возможность
оперативно выбирать (подключать / отключать) те или иные
фрагменты в соответствии с задачей, сферой интересов и
точкой зрения отдельных профессиональных групп. (Доменное
администрирование !)
Модельная масштабируемость – возможность представления
концептуальных систем на разных уровнях детальности
описания и формализации соответствующих фрагментов
действительности (например, в такой последовательности:
простая семантическая категоризация лексики – таксономия –
полная терминологическая модель - продукционная система –
логическая теория).
Пользовательская универсальность – пригодность
использования в разнотипных приложениях.
для
Технологические предпосылки для реализации этих требований (за
исключением 4 пункта) уже обеспечиваются в рамках RDFOWL-технологий. Вместе с тем, следует ясно понимать, что ЯПЗ
типа OKBC, OWL, KIF и др., так же, впрочем, как и
классическое исчисление предикатов, – если его рассматривать в
этом качестве,
- есть лишь языки-оболочки, никак не предрешающие и не
определяющие методов формализации концептуальных систем
Ключевая роль Top-Level онтологии.
NB: нигде с достаточной определенностью не формулируется,
что такое Top-Level онтология.
Возможное операциональное определение:
Концептуальная подсистема, достаточная для последующего
построения и присоединения любых доменных онтологий и для
представления логических связей между концептами, значимых
во всех или хотя бы нескольких частных онтологиях.
Три возможных составляющих:
•
•
•
«Категориальная» онтология
«Энциклопедическая» онтология (включая терминологию
повседневной жизни)
Онтологии внутридоменных примитивов (должны добавляться
по мере присоединения доменных концептуальных моделей).
Возможные критерии включения в энциклопедическую компоненту
• Словарные минимумы
• Частотный анализ хорошо сбалансированного корпуса текстов
• Здравый смысл и когнитивная интуиция разработчика
4) Пополнение онтологий
(Проблема «узкого горлышка»)
Три возможных способа пополнения онтологий:
• "ручной" ввод (+ Wiki-технология);
• автоматический или автоматизированный ввод на основе
анализа корпуса текстов;
• автоматический или автоматизированный ввод с использованием
традиционной лексикографической информации
(энциклопедических и толковых словарей).
Ключевой инструментарий для методов Ontology learning –
NLU-процессоры.
«Самопополняемые» онтологии.
2 предстоящих этапа для «словарного подхода»:
• Выделение родового термина и включение в таксономию без
точного определения места в ней (underspecification)
• NLU- формализация определений
Формализация определений
Содержание работы, которая должна быть при этом выполнена,
делится на экспертную и NLU части.
Эксперт:
1) Содержательный анализ словарных определений и вычленение
из них базовых признаков.
2) Построение иерархической системы базовых признаков
("дерева признаков").
Программа:
3) Логическая реконструкция словарных определений в
терминах построенной на этапе 2 системы базовых признаков.
(только в терминах допустимых и заранее специфицированных
логических схем.
4) Перевод полученных толкований на язык описания лексики в
операциональной среде, используемой в онтологии.
5) Достоверность и целостность
Требование достоверности ввода может быть конкретизировано в
следующих пунктах
• Неизбыточность и полнота описания – должны быть
определены те и только те словарные признаки, которые
релевантны для концептов данного типа.
• Непротиворечивость описания – словарные характеристики
не должны противоречить друг другу.
Напр., для концепта, определяемого конъюнкцией объектных
классов (в терминах многих онтологий – класс,
характеризуемый через множественное наследование),
определяющие концепты должны быть совместимы (в
терминах OWL – не должны находиться в отношении
DisjointWith). Соответственно, процедура ввода должна
обнаруживать и блокировать ввод , например, толкования вида
X  животное And металлический.
•
Правильность означивания – вводимые значения
определяемых словарных признаков должны принадлежать
области их допустимых значений.
Напр., формально неправильно: будет указание в качестве
Базовый признак (метр) = перемещение
(имеем легко контролируемую категориальную ошибку – базовым
признаком может быть только концепт класса наименование
признака, сочетающегося с числом; правильно будет линейный
размер).
Однако
Базовый признак (метр) = масса
- ошибка, не являющаяся формально контролируемой; может
оставаться не выявленной до тех пор, пока онтология не начнет
использоваться в приложениях, для которых именно эта связь
окажется существенной.
Ср. также.
лед = агрегатное состояние & химический состав
- формальная (категориальная) ошибка
Однако определение типа
лед  квазиобъект & цилиндрической формы
-
является формально правильным.
Конечная цель при проектировании процедур ввода состоит в том,
чтобы максимально исключить формально определимые
ошибки.
При этом технологически "хорошее" решение будет состоять не в
том, чтобы уметь обнаруживать формальные ошибки post factum,
а в том, чтобы сама процедура ввода была спроектирована так,
что ввод логически некорректных элементов описания
оказывается вообще невозможным. Это означает, что функцию
контроля формальной корректности словарных описаний будет
правильным переместить из подсистемы тестирования, куда она
помещается
сейчас
большинством
разработчиков
онторедакторов, в подсистему ввода.
.
Решение задач формального контроля обусловлено возможностью
построить формальное описание системы словарных
признаков:
Таковое сводится к
а) определение области значений каждого признака
б) установление отношений зависимости по условиям
применимости между признаками.
С точки зрения первого требования признаки можно разделить на
признаки со стандартной областью значения (вещественные,
целочисленные, строковые) – здесь процедура формального
контроля значения тривиальна, - и признаки, областью значений
которых является некоторый класс концептов. Здесь важен
выбор адекватной данной задаче схемы категоризации
концептов.
•
Содержательная правильность – см. примеры п. 3).
Выявление содержательных ошибок представляет сложную и вряд
ли окончательно и полностью разрешимую проблему для
службы администрирования онтологии. Эта задача находится в
компетенции подсистемы тестирования онтологии.
Тестирование
"Тестирование" отдельных концептов сводится к просмотру и
проверке содержимого словарных статей и, следовательно,
относится к компетенции подсистемы навигации и броузинга.
Собственно тестирование как отличающаяся от броузинга
процедура может состоять только в тестировании отношений
между концептами – объемных (тигр - дом), ассоциативных
(тигр - хвост), и функциональных (ампер – сила тока; метр
- микрон).
Наиболее эффективно "серийное" тестирование, при котором пары
концептов выбираются из онтологии случайным образом, что
позволяет производить поиск ошибок путем быстрого
"листания" произвольно выбираемых пар концептов.
В
рамках
администрирования
онтологии
проверить
содержательную правильность описаний концептов можно
только путем организации "лабораторных" испытаний и
экспертной оценки их результатов.