Лабораторная работа №1
по курсу «Интеллектуальные информационные системы»
Создание онтологии и её применение в ИС
Цель работы
Ознакомиться с понятием онтологии в сфере представления знаний и основными типами онтологий. Освоить принципы проектирования онтологий и их разработки с использованием инструментальных средств.
Методические указания
Онтологии и их применение
Существуют различные модели представления знаний: формально-логическая,
продукционная, фреймовая, семантическая сеть. Одним из современных средств
представления знаний являются онтологии – формальные явные описания терминов
предметной области и отношений между ними (определение дано по Т. Груберу).
Под определение онтологии попадают многие модели представления знаний: фреймы, семантические сети, концептуальные карты и т.п. Формальное определение онтологии можно записать в виде:
O {C, R, A}
где O – онтология, С – совокупность концептов (понятий) предметной области, R – совокупность отношений между концептами, A – набор аксиом (законов и
правил, которые описывают законы и принципы существования концептов).
Классификация онтологий по целям создания:
Назначение прикладной онтологии в том, чтобы описать концептуальную
модель конкретной задачи или приложения. Прикладные онтологии описывают
концепты, которые зависят как от онтологии задач (см. ниже), так и от онтологии
предметной области. Примером может служить онтология для автомобилей, строительных материалов, вычислительной техники. Такие онтологии содержат наиболее
специфичную информацию.
Классификация онтологий по содержимому:
Онтология, ориентированная на задачу (онтология задач) – это онтология,
используемая конкретной прикладной программой и содержащая термины, которые
используются при разработке ПО, выполняющего конкретную задачу. Она отражает
специфику приложения, но может также содержать некоторые общие термины (например, в графическом редакторе будут и специфические термины — палитра, тип
заливки, наложение слоев и т.д., и общие — сохранить и загрузить файл). Задачи,
которым может быть посвящена онтология, могут быть самыми разнообразными:
составления расписания, определение целей, диагностика, продажа, разработка ПО,
построение классификации. При этом онтология задачи использует специализацию
терминов, представленных в онтологиях верхнего уровня (общих онтологиях) [1].
Почему возникает потребность в разработке онтологии? Вот некоторые причины [2]:
Для совместного использования людьми или программными агентами
общего понимания структуры информации.
Для возможности повторного использования знаний в предметной области.
Для того чтобы сделать допущения в предметной области явными.
Для отделения знаний в предметной области от оперативных знаний.
Для анализа знаний в предметной области.
Часто онтология предметной области сама по себе не является целью. Разработка онтологии сродни определению набора данных и их структуры для использования другими программами. Методы решения задач, доменно-независимые приложения и программные агенты используют в качестве данных онтологии и базы зна-
ний (БЗ), построенные на основе этих онтологий – онтология, содержащая экземпляры классов, является базой знаний, хотя на практике и не всегда возможно провести точную границу между БЗ и онтологией.
Среди таких приложений можно отметить современные интеллектуальные
системы (ИС) – системы, способные решать задачи в некоторой предметной области, традиционно считающиеся творческими. Такие системы являются системами,
основанными на знаниях (СОЗ), хотя иногда различие между этими двумя типами
систем фактически не проводится. Основными компонентами ИС являются база
знаний (декларативный компонент) и «решатель» или «механизм вывода» (процедурный компонент); в некоторых случаях в качестве важных составляющих ИС
упоминаются также интеллектуальный интерфейс пользователя, подсистема объяснений и интеллектуальный редактор БЗ.
Фреймовые и гибридные онтологии
Продукционная модель представления знаний (реализуемая, в частности, в
логических языках Prolog, CLIPS), в общем случае может быть представлена в виде:
i S; L; A B; Q
где S – описание класса ситуаций; L – условие, при котором продукция активизируется; AB – ядро продукции; Q – постусловие продукционного правила.
Такая модель является одним из самых распространённых средств представления знаний в интеллектуальных системах благодаря своей наглядности, модульности (как следствие – легкости внесения изменений и дополнений) и удобства для
осуществления вывода. Тем не менее, продукционная модель обладает и существенными недостатками:
1) отсутствие иерархии продукционных правил (и вообще отношений между
правилами), что приводит к малой пригодности модели для описания поля знаний
сложной предметной области;
2) сложность учёта правил, которые могут начать противоречить друг другу, и
управления очерёдностью их выполнения.
Для устранения этих недостатков возможно использование продукционной
модели в симбиозе средств представления знаний, который в последнее время приобрёл популярность при формализации знаний. В этом случае продукционная модель может выступать в качестве процедурного компонента во фреймовой1 модели,
которая способна сочетать декларативный и процедурный компоненты представления знаний.
1
Термин «фрейм», впервые введённый в области ИИ Марвином Минским, означает структуру знаний, моделирующую мышление человека и соответствующую абстрактному образу какого-либо объекта, явления, события, ситуации, процесса.
Фреймовая онтология, как и другие виды онтологий, представляется в виде
сети, состоящей из узлов и связей между ними, причем «верхние уровни» фрейма
образованы общими понятиями (классами), а на более низких уровнях фрейма располагаются вершины-терминалы (так называемые слоты), которые должны быть заполнены конкретными данными или примерами. Характерной особенностью фреймовой модели является то, что первоначально слоты могут быть заполнены «заданиями отсутствия» – заранее заготовленными значениями, не обязательно имеющими место в конкретной ситуации. Следовательно, в составе фреймовой структуры
фрейм содержит: имя фрейма, указатели наследования (если фреймовая структура
является иерархической), слоты (с именами слотов), тип данных значения слотов и
сами значения слотов (могут отсутствовать). В большинстве фреймовых структур
значениями слотов могут выступать другие фреймы, реализовывая тем самым различные виды связей между понятиями, а в некоторых случаях – и присоединённые
процедуры, реализующие процедурный компонент в представлении знаний.
В качестве процедурного компонента во фреймовой онтологии может выступать продукционная модель, при этом фреймы будут являться главными источниками знаний, а правила продукционной модели – играть вспомогательную роль, используясь, например, для заполнения значениями фреймов-экземпляров.
Инструментальные средства для создания онтологий
При создании онтологий целесообразно пользоваться подходящими инструментами – программными средствами, созданными специально для проектирования,
редактирования и анализа онтологий и называемыми редакторами онтологий. В
большинстве своем современные редакторы онтологий предоставляют средства
«кодирования» формальной модели в том или ином виде. Некоторые дают дополнительные возможности по анализу онтологии, используют механизм логического вывода.
Под формализмом понимается теоретический базис, лежащий в основе способа представления онтологических знаний. Примерами формализмов могут служить логика предикатов (First Order Logic — FOL), дескриптивная логика, фреймовые модели, концептуальные графы и т.п. Формализм, используемый редактором,
может не только существенно влиять на внутренние структуры данных, но и определять формат представления или даже пользовательский интерфейс. Формат представления онтологии задает вид хранения и способ передачи онтологических описаний (могут использоваться языки представления онтологий RDF, OWL, KIF, SCL).
Например, некоторая формальная модель представляется в формализме FOL и может быть выражена средствами языка KIF. Редакторы онтологий обычно поддерживают работу с несколькими формализмами и форматами представления, но часто
только один формализм является «родным» (native) для данного редактора.
Одним из популярных редакторов онтологий является свободно распространяемый редактор Protégé, разработанный в Стэнфордском университете (США) –
см. http://protege.stanford.edu/. Изначально единственной моделью знаний (формализмом), поддерживаемой Protege, была фреймовая модель (в версии редактора
Protégé-Frames), однако впоследствии была добавлена поддержка языка OWL2.
Версия редактора Protégé-OWL, на настоящий момент стала основной, а её различия
с Protégé-Frames описаны в [3].
Редактор Protégé-Frames позволяет пользователям строить и заполнять онтологии, основанные на фреймах, в соответствии с протоколом OKBC3, а форматом
представления является язык KIF4. Таким образом, основными элементами онтологии в Protégé-Frames являются классы (classes), экземпляры (instances), слоты
(slots), представляющие свойства классов и экземпляров, и фасеты (facets), задающие дополнительную информацию о слотах.
Protege имеет открытую, легко расширяемую архитектуру и поддерживает
модули расширения функциональности (plug-ins). В частности, модуль расширения CLIPSTab позволяет осуществлять интеграцию с языком разработки экспертных
систем CLIPS (C Language Integrated Production System). Наконец, для Protégé разработана концепция совместной работы нескольких пользователей (Collaborative
Protégé), воплощенная в онлайн-версии данного редактора (см. пример на
http://webprotege.stanford.edu/), хотя для выполнения данной лабораторной работы
использование онлайн-версии редактора не рекомендуется.
Подробное описание интерфейса Protégé-Frames приводится на веб-сайте
разработчика (http://protegewiki.stanford.edu/wiki/PrF_UG). Последняя версия
Protégé-Frames может быть получена на сайте авторов.
Методология создания онтологий (на примере Protégé-Frames)
Разработка функциональной онтологии для сложной предметной области, как
правило, является трудоемким и итеративным процессом, к тому же вплоть до конца
1990-х годов отмечался недостаток проработанных методологий для создания онтологий. Однако в течение 2000-х годов интерес к применению онтологий был значителен, как со стороны исследователей, так и специалистов, и это нашло своё отражение, в частности, в методологии, предлагаемой разработчиками Protégé (полную
версию см. в [2]).
Следует иметь в виду, что не существует единственного «правильного» способа или методологии разработки онтологий – всегда существуют жизнеспособные
2
OWL (Web Ontology Language) – язык описания онтологий для семантической паутины (Semantic Web).
OKBC (Open Knowledge Base Connectivity protocol) – прикладной интерфейс программирования для доступа
к базам знаний систем представления знаний.
4
KIF (Knowledge Interchange Format) – язык, предназначенный для обмена знаниями между различными компьютерными программами (соответствует стандарту Common Logic).
3
альтернативы, однако содержание онтологии всегда определяется её целями (предполагаемым применением) и планируемыми направлениями дальнейшего развития
(процесс создания онтологий, как правило, является итеративным). Тем не менее, в
рамках процесса создания онтологий можно выделить следующие шаги.
1. Определение области и масштаба онтологии
Для этого разработчик онтологии должен ответить на следующие вопросы:
1) Какую область будет охватывать онтология?
2) Для чего мы собираемся использовать онтологию?
3) На какие типы вопросов должна давать ответы информация в онтологии?
4) Кто будет использовать и поддерживать онтологию?
Так, в [2] описывается разработка онтологии, область которой – вина и еда, а
предполагаемое использование – в интеллектуальных системах, которые будут
предлагать сочетания вин и еды (например, для совершения заказа в ресторане).
2. Поиск существующих онтологий
Целесообразно бывает рассмотреть возможность использования уже существующей онтологии, если она полностью или частично покрывает нужды разработчика. Многие онтологии уже доступны в электронном виде и могут быть импортированы в используемую среду проектирования онтологии (в особенности, если она
способна работать с различными формализмами).
Примечание: при выполнении данной лабораторной работы допустимо использование существующих онтологий, частично (но не полностью) соответствующих заданию. В этом случае в отчете должно быть приведено описание существующей онтологии (со ссылкой) и процесса её доработки.
3. Перечисление важных терминов в онтологии
На данном шаге рекомендуется составление неструктурированного списка
терминов предметной области, без разделения на классы (концепты) и слоты (атрибуты классов).
Следующие два шага – разработка иерархии классов и определение свойств
понятий (слотов) – являются наиболее важными в процесс создания онтологии и
тесно переплетены между собой (как правило выполняются параллельно).
4. Определение классов и иерархии классов
Существует несколько возможных подходов для разработки иерархии классов:
1) процесс нисходящей разработки, который начинается с определения самых
общих понятий предметной области с последующей конкретизацией понятий;
2) процесс восходящей разработки, который начинается с определения самых
конкретных классов (листьев иерархии), с последующей группировкой этих классов
в более общие понятия;
3) процесс комбинированной разработки – сочетание нисходящего и восходящего подходов: сначала мы определяем более заметные понятия, а затем соответствующим образом обобщаем и ограничиваем их.
Ни один из этих трех методов не лучше других по своей сути и выбор подхода
в большой степени зависит от личного взгляда разработчика на предметную область. Часто для многих разработчиков онтологий самым простым является комбинированный метод, т.к. понятия, находящиеся «посередине», имеют тенденцию
быть самыми наглядными понятиями в предметной области
В любом случае, в ходе данного шага из списка, составленного на шаге 3,
должны быть выбраны термины, являющиеся классами в иерархической структуре
(т.е. связанные отношениями is_a – a_kind_of).
5. Определение свойств классов – слотов
Те термины из списка, составленного на шаге 3, которые не являются классами, скорее всего, станут их свойствами – слотами. Вообще, в онтологии слотами могут стать несколько типов свойств объектов:
1) «внутренние» свойства (например, вкус вина);
2) «внешние» свойства (например, название вина и область его производства);
3) структурные части – как физические, так и абстрактные (например, блюда,
входящие в обед);
4) отношения с другими концептами – между отдельными членами класса и
другими элементами (например, производитель вина, представляющий отношение
между вином и винным заводом).
Все подклассы класса наследуют слоты класса-родителя. Слот должен быть
привязан к самому общему классу, у которого может быть данное свойство. Важно
различать класс и его имя: классы представляют понятия предметной области, а не
слова, которые обозначают эти понятия (подробные замечания по созданию иерархии классов в онтологии приведены в [2, С.11-18]).
6. Определение фасетов слотов
Слоты могут иметь различные фасеты, которые описывают тип значения, разрешенные значения, число значений (мощность) и другие свойства значений, которые может принимать слот.
Мощность слота определяет, сколько значений может иметь слот. В некоторых системах различаются только единичная мощность (возможно только одно значение) и множественная мощность (возможно любое число значений). Некоторые
системы позволяют определить минимальную и максимальную мощность для того,
чтобы более точно описать количество значений слота (минимальная мощность N
означает, что слот должен иметь не менее N значений). Иногда полезно установить
максимальную мощность в 0 – это будет означать, что для определенного подкласса
слот не может иметь значений.
Тип значения слота описывает, какие типы значений можно ввести в слот.
Вот список наиболее общих типов значений: строка, число (целое или дробное),
булевое (логическое) значение, перечисление (в Protégé – тип Symbol), экземпляр
класса (позволяет определить отношения между концептами).
Диапазон значений слота – разрешенные классы для слотов типа экземпляр.
Например, для класса «Мясное блюдо» слот «рекомендованное вино» может иметь в
качестве допустимых значений экземпляры класса «Красное вино», а для класса
«Рыбное блюдо» – «Белое вино» (при этом их класс-родитель, «Еда», может иметь в
качестве допустимых значений экземпляры класса «Вино»).
7. Создание экземпляров
Последний шаг – это создание отдельных экземпляров классов в иерархии.
Для определения отдельного экземпляра класса требуется выбрать класс, создать
отдельный экземпляр этого класса и установить значения слотов (не обязательно
всех).
Дополнительные замечания:
1. Следует выбрать стандарт наименования классов и слотов и придерживаться его при разработке онтологии. Как правило, названия классов начинаются с
заглавной буквы, а слотов – со строчной. Наименование классов чаще производится
в единственном числе («Вино», а не «Вина»), хотя допустимо и множественное.
Следует также выбрать разделитель (пробел, подчеркивание, знак минуса или плюса), который будет использоваться в именах классов и слотов, состоящих из нескольких слов.
При выполнении лабораторной работы рекомендуется использование названий на английском языке, для большей совместимости с CLIPS.
2. При создании онтологии в Protégé отношение с другим концептом задается посредством слота, значением которого является экземпляр класса, с которым устанавливается отношение. Для установления двусторонних отношений могут
использоваться обратные слоты (inverse slots): например, если вино было произведено на винном заводе, то винный завод производит это вино. В случае таких обратных отношений, система сможет автоматически заполнить значение для обратного отношения, обеспечивая согласованность базы знаний.
3. Если значение определенного слота одинаково для большинства экземпляров класса, то мы можем определить это значение как значение слота по умолчанию. Затем, когда создается каждый экземпляр класса, имеющего этот слот, система
автоматически заполняет значение по умолчанию, но после этого мы можем изменить это значение на любое другое, которое позволят фасеты. То есть, значения по
умолчанию созданы для удобства: в любом случае они не накладывают какие-либо
ограничения на модель или никак ее не меняют.
Примеры онтологий:
В качестве примера, к лабораторной работе прилагается фрагмент онтологии
5
WDO (WDO-lab.pprj), предназначенной для контекстной организации знаний
(практических рекомендаций) в сфере проектирования веб-интерфейсов. Созданная
на основе онтологии база знаний, в составе интеллектуальной системы позволяет
пользователю (проектировщику веб-интерфейсов) быстрый доступ к рекомендациям, организованным в зависимости от элемента интерфейса (или веб-сайта) и других
факторов, определяющих контекст проектируемого взаимодействия. Исходя из этого, онтология содержит такие основные классы (см. Рис. 1) как Interface element
(элемент интерфейса), Website element (элемент веб-сайта), Style (CSS) property
(свойство каскадной таблицы стилей) и HCI knowledge representation class (Класс
представления знаний в сфере человеко-компьютерного взаимодействия).
Рис. 1. Визуализация (при помощи модуля OntoViz) взаимосвязей основных
классов онтологии.
Среди подклассов класса HCI knowledge representation class (см. Рис. 2), соответствующих знаниям различного уровня (закон, принцип, рекомендация) следует
особо отметить класс Guideline (рекомендация), одним из слотов которого является
tag (тэг), реализующий тэговую категоризацию – значением данного слота может
являться подкласс класса THING, т.е. любой класс (концепт) онтологии. Таким образом, онтология является не только основой для БЗ системы, но и содержит упорядоченную терминологию предметной области, используемую для тэговой категоризации.
5
WDO: Web Design Ontology (Бакаев М.А.)
Рис. 2. Визуализация класса HCI knowledge representation class и подклассов.
В комплекте с Protégé поставляется несколько дополнительных примеров онтологий (Newspaper, Pizza). Кроме того, авторы редактора предлагают документ
(http://protegewiki.stanford.edu/images/e/e8/Protege-frames-get-started.pdf),
детально
описывающий процесс создания одной из онтологий.
Ход выполнения работы
1. Изучить методические указания к лабораторной работе.
2. Установить редактор Protégé-Frames и осуществить донастройки:
Установка Protégé-Frames
Рекомендуемая
версия
редактора
Protégé-Frames:
3.4.8
(http://protege.stanford.edu/download/protege/3.4/installanywhere/Web_Installers/).
Русификация Protégé (необязательный шаг)
Для
русификации
интерфейса
Protégé-Frames,
замените
файл
protege_text.properties, находящийся в папке Protégé, на файл, прилагаемый к лабораторной работе6.
Установка OntoViz (необязательный шаг)
Модуль расширения Protégé под названием OntoViz служит для визуализации
онтологии (автоматического построения схем взаимосвязей классов и экземпляров).
OntoViz может быть использован для отражения структуры онтологии в отчёте по
лабораторной работе (см. описание, инструкции по установке и документацию по
использованию модуля по адресу http://protegewiki.stanford.edu/wiki/OntoViz).
Альтернативным средством визуализации онтологии может являться вкладка
Jambalaya.
3. Спроектировать онтологию для выбранной предметной области:
Предметные области (по вариантам):
1. Разработка ПО (ИС)
2. Анализ требований к ПО
3. Проектирование архитектуры ПО
4. Программная реализация ПО
5. Тестирование и отладка ПО
6. Внедрение и поддержка (сопровождение) ПО
7. Проектирование компьютерных интерфейсов
8. CASE-средства
9. Контроль качества ПО
10.Моделирование бизнес-процессов
По согласованию с преподавателем, студенты могут предложить свой вариант
предметной области – например, соответствующий теме РГР.
6
локализация взята с сайта http://shcherbak.net/iniciativa-lokalizaciya-redaktora-ontologij-protege/
При выборе следует иметь в виду, что выбираемая предметная область и
цели ИС, разрабатываемой в лабораторной работе №2, должны соотноситься между
собой.
4. Создать онтологию в редакторе Protégé-Frames:
В соответствии с описанным выше процессом создания онтологии, реализуйте
в Protégé-Frames прикладную онтологию задач для выбранных в лабораторной работе №3 предметной области и цели создания ИС. Создаваемая онтология должна содержать не менее 50 основных фреймов (классов, слотов) и не менее 20 фреймовэкземпляров.
5. Оформить отчёт по лабораторной работе:
Содержание отчёта
Выбранная предметная область и возможная цель использования онтологии
Описание существующих (готовых) онтологий, если таковые есть и используются при выполнении работы
Список терминов предметной области с указанием их разделения на
классы, слоты, экземпляры и т.д.
Описание структуры онтологии (классы, слоты, экземпляры).
К отчёту также должны прилагаться:
Файл с классами онтологии (ontology.pont)
Файл с экземплярами классов (ontology.pins)
Файл проекта Protégé (ontology.pprj)
6. Защитить лабораторную работу, при необходимости ответив на контрольные вопросы.
Контрольные вопросы
1. Поясните, каким образом цель создания онтологии определяет её структуру?
2. В чём вы видите отличие онтологии от базы знаний и от интеллектуальной
(экспертной) системы?
3. Какие модели представления знаний (помимо фреймов) вы знаете?
4. Какие типичные отношения между концептами в онтологиях вы знаете?
5. В чём отличие иерархических и ассоциативных связей между концептами?
Литература
1. Б.В. Добров, В.В. Иванов, Н.В. Лукашевич, В.Д. Соловьев. Онтологии и тезаурусы: модели, инструменты, приложения.
http://www.intuit.ru/department/expert/ontoth/
2. Н.Ф. Ной и Д.Л. МакГиннесс. Разработка онтологий 101: руководство по
созданию Вашей первой онтологии.
http://ifets.ieee.org/russian/depository/ontology101_rus.doc
3. H.H. Wang и др. Frames and OWL Side by Side
http://protege.stanford.edu/conference/2006/submissions/abstracts/7.2_Wang_Hai_Protege
_conf.pdf
