Курсовая работа: Разработка онтологий 101: руководство по созданию Вашей первой онтологии 
Курсовая работа: Разработка онтологий 101: руководство по созданию Вашей первой онтологии
[1]
Наталья Ф. Ной (Natalya
F. Noy) и Дэбора Л. МакГиннесс (Deborah
L. McGuinness)
Стэнфордский Университет, Стэнфорд, Калифорния
Онтологии стали центральными компонентами многих
больших приложений, хотя учебный материал не соответствует растущему интересу.
В этой работе обсуждается вопрос, зачем строить онтологию, и предлагается
методология создания онтологий, основанная на системах представления декларативных знаний. Она использует
опыт двух авторов в построении и поддержке онтологий в ряде онтологических
сред, включая Protege-2000, Ontolingua и Chimaera. В ней представлена
методология на примере учебной базы знаний по винам. Несмотря на то, что статья
адресована пользователям фреймовых систем, она может быть полезна для
построения онтологий в любой объектно-ориентированной системе.
1. Зачем создавать
онтологию?
В последние годы разработка онтологий - формальных
явных описаний терминов предметной области и отношений между ними – переходит
из мира лабораторий по искусственному интеллекту на рабочие столы экспертов по
предметным областям. Во всемирной паутине онтологии стали обычным явлением.
Онтологии в сети варьируются от больших таксономий, категоризирующих веб-сайты
(как на сайте Yahoo!), до категоризаций продаваемых товаров и их характеристик
(как на сайте Amazon.com). Консорциум WWW (W3C)
разрабатывает RDF (Resource Description Framework), язык кодирования знаний на веб-страницах, для того, чтобы сделать их
понятными для электронных агентов, которые осуществляют поиск информации.
Управление перспективных исследований и разработок министерства обороны США (The Defense Advanced Research Projects Agency, DARPA) в сотрудничестве с W3C разрабатывает Язык Разметки для Агентов DARPA
(DARPA Agent Markup Language,
DAML), расширяя RDF более выразительными
конструкциями, предназначенными для облегчения взаимодействия агентов в сети.
Во многих дисциплинах сейчас разрабатываются стандартные онтологии, которые
могут использоваться экспертами по предметным областям для совместного использования
и аннотирования информации в своей области. Например, в области медицины
созданы большие стандартные, структурированные словари, такие как snomed и семантическая сеть Системы Унифицированного
Медицинского Языка (the Unified Medical Language System). Также появляются
обширные общецелевые онтологии. Например, Программа ООН по развитию (the United Nations Development Program) и компания Dun & Bradstreet объединили усилия для разработки онтологии UNSPSC, которая
предоставляет терминологию товаров и услуг (http://www.unspsc.org/).
Онтология определяет общий словарь для ученых, которым
нужно совместно использовать информацию в предметной области. Она включает
машинно-интерпретируемые формулировки основных понятий предметной области и
отношения между ними.
Почему возникает потребность в разработке онтологии?
Вот некоторые причины:
Для совместного использования людьми или программными
агентами общего понимания структуры информации.
Для возможности повторного
использования знаний в предметной области.
Для того чтобы сделать допущения в предметной области
явными.
Для отделения знаний в предметной области от
оперативных знаний.
Для анализа знаний в предметной области.
Совместное использование людьми или программными
агентами общего понимания структуры информации является одной из наиболее общих
целей разработки онтологий. К примеру, пусть, несколько различных веб-сайтов
содержат информацию по медицине или предоставляют информацию о платных
медицинских услугах, оплачиваемых через Интернет. Если эти веб-сайты совместно
используют и публикуют одну и ту же базовую онтологию терминов, которыми они
все пользуются, то компьютерные агенты могут извлекать информацию из этих
различных сайтов и накапливать ее. Агенты могут использовать накопленную информацию
для ответов на запросы пользователей или как входные данные для других
приложений.
Обеспечение возможности использования знаний
предметной области стало одной из движущих сил недавнего всплеска в изучении
онтологий. Например, для моделей многих различных предметных областей
необходимо сформулировать понятие времени. Это представление включает понятие
временных интервалов, моментов времени, относительных мер времени и т.д. Если
одна группа ученых детально разработает такую онтологию, то другие могут просто
повторно использовать ее в своих предметных областях. Кроме того, если нам
нужно создать большую онтологию, мы можем интегрировать несколько существующих
онтологий, описывающих части большой предметной области. Мы также можем
повторно использовать основную онтологию, такую как UNSPSC, и
расширить ее для описания интересующей нас предметной области.
Создание явных допущений в предметной области, лежащих
в основе реализации, дает возможность легко изменить эти допущения при
изменении наших знаний о предметной области. Жесткое кодирование предположений
о мире на языке программирования приводит к тому, что эти предположения не
только сложно найти и понять, но и также сложно изменить, особенно
непрограммисту. Кроме того, явные спецификации знаний в предметной области
полезны для новых пользователей, которые должны узнать значения терминов
предметной области.
Отделение знаний предметной области от оперативных
знаний – это еще один вариант общего применения онтологий. Мы можем описать
задачу конфигурирования продукта из его компонентов в соответствии с требуемой
спецификацией и внедрить программу, которая делает эту конфигурацию независимой
от продукта и самих компонентов. После этого мы можем разработать онтологию
компонентов и характеристик ЭВМ и применить этот алгоритм для конфигурирования
нестандартных ЭВМ. Мы также можем использовать тот же алгоритм для
конфигурирования лифтов, если мы предоставим ему онтологию компонентов лифта.
Анализ знаний в предметной области возможен, когда
имеется декларативная спецификация терминов. Формальный анализ терминов
чрезвычайно ценен как при попытке повторного использования существующих
онтологий, так и при их расширении.
Часто онтология предметной области сама по себе не
является целью. Разработка онтологии сродни определению набора данных и их
структуры для использования другими программами. Методы решения задач,
доменно-независимые приложения и программные агенты используют в качестве
данных онтологии и базы знаний, построенные на основе этих онтологий. К
примеру, в этой статье мы разрабатываем онтологию вин и еды, а также подходящие
комбинации вин и блюд. Затем эту онтологию можно будет использовать как основу
для приложений в наборе инструментов для управления рестораном: Одно приложение
могло бы составлять список вин для меню на текущий день или отвечать на запросы
официантов и посетителей. Другое приложение могло бы анализировать инвентарный перечень
винного погреба и предлагать категории вин для пополнения и конкретные вина для
закупки к следующим меню или для поваренных книг.
Об этом руководстве
Мы основываемся на нашем опыте использования Protege-2000,
Ontolingua, Chimaera в качестве сред для редактирования онтологий. В этом
руководстве для наших примеров мы используем Protege-2000.
Пример вина и еды, который мы используем на протяжении
всей статьи, сделан на основе примерной базы знаний, которая представлена в
статье, описывающей CLASSIC –
систему представления знаний, основанную на описательно-логическом подходе. В
учебном пособии по CLASSIC этот пример получил дальнейшее развитие. Protege-2000
и другие фреймовые системы описывают онтологии декларативным образом, определяя
явным образом, какова классовая иерархия и к каким классам принадлежат
индивидные концепты.
Некоторые идеи по разработке онтологий в этом
руководстве берут свое начало в литературе по объектно-ориентированному
проектированию. Однако разработка онтологий отличается от проектирования
классов и отношений в объектно-ориентированном программировании.
Объектно-ориентированное программирование сосредотачивается главным образом на
методах классов – программист принимает проектные решения, основанные на
операторных свойствах класса, тогда как разработчик онтологии принимает эти
решения, основываясь на структурных свойствах класса. В результате структура
класса и отношения между классами в онтологии отличаются от структуры подобной
предметной области в объектно-ориентированной программе.
Невозможно охватить все трудности, которые, возможно,
придется преодолеть разработчику онтологии, и в этом руководстве мы не пытаемся
затронуть их всех. Вместо этого мы пытаемся дать отправную точку, исходное
руководство, которое могло бы помочь неопытному проектировщику онтологий в их
разработке. В конце мы предлагаем источники, в которых можно посмотреть
пояснения к более сложным структурам и механизмам разработки, если они
потребуются для предметной области.
В конечном счете, единственной правильной методологии
разработки онтологий не существует, и мы не пытались определить таковую.
Представленные здесь идеи мы мы сочли полезными, исходя из нашего опыта
разработки онтологий. В конце этого руководства мы предлагаем список ссылок на
альтернативные методологии.
2. Из чего состоит
онтология?
В литературе по искусственному интеллекту содержится
много определений понятия онтологии, многие из которых противоречат друг другу.
В этой статье онтология – формальное явное описание понятий в рассматриваемой
предметной области (классов (иногда их называют понятиями)), свойств каждого
понятия, описывающих различные своства и атрибуты понятия (слотов (иногда их
называют ролями или свойствами)), и ограничений, наложенных на слоты (фацетов
(иногда их называют ограничениями ролей)). Онтология вместе с набором
индивидуальных экземпляров классов образует базу знаний. В действительности,
трудно определить, где кончается онтология и где начинается база знаний.
В центре большинства онтологий находятся классы.
Классы описывают понятия предметной области. Например, класс вин представляет
все вина. Конкретные вина – экземпляры этого класса. Вино Bordeaux
в бокале перед вами, когда вы читаете этот документ, – это экземпляр класса вин
Bordeaux. Класс может иметь подклассы, которые представляют
более конкретные понятия, чем надкласс. Например, мы можем разделить класс всех
вин на красные, белые и розовые вина. В качестве альтернативы мы можем
разделить класс всех вин на игристые и не игристые вина.
Слоты описывают свойства классов и экземпляров: вино Chвteau
Lafite Rothschild
Pauillac - крепкое, оно производится на
винном заводе Chвteau
Lafite Rothschild.
У нас есть два слота, которые описывают вино в этом примере: слот крепость со значением «крепкое» и слот
производитель со значением «винный завод Chвteau
Lafite Rothschild».
Мы можем сказать, что на уровне класса у экземпляров класса Вино есть слоты,
которые описывают вкус, крепость, уровень сахара, производителя вина и т.д.[1]
Все экземпляры класса Вино и его подкласс Pauillac
имеют слот производитель, значение которого является экземпляром класса Винный завод (Рис. 1). Все экземпляры класса Винный завод
имеют слот производит, относящийся ко всем винам (экземплярам класса Вино и его
подклассов), которые производятся на этом заводе.
На практике разработка онтологии включает:
определение классов в онтологии;
расположение классов в таксономическую иерархию
(подкласс – надкласс);
определение слотов и описание допускаемых значений
этих слотов;
заполнение значений слотов экземпляров.
После этого мы можем создать базу знаний, определив
отдельные экземпляры этих классов, введя в определенный слот значение и
дополнительные ограничения для слота.
Рис. 1. Некоторые классы в области вин, экземпляры и
отношения между ними. Черным мы обозначили классы, а красным – экземпляры.
Прямые связи обозначают слоты и внутренние связи, такие как «экземпляр
[класса]» и «подкласс [класса]».
3. Простая методология
инженерии знаний
Как мы сказали выше, не существует единственного
«правильного» способа или методологии разработки онтологий. Здесь мы обсуждаем
общие моменты, которые нужно учитывать, и предлагаем один из возможных способов
разработки онтологии. Мы описываем итеративный подход к разработке онтологии:
мы начинаем с первого чернового просмотра онтологии. Затем мы проверяем и
уточняем получаемую онтологию и добавляем детали. Попутно мы обсуждаем решения,
касающиеся моделирования, которые должен принять разработчик, а также «за» и
«против» и результаты принятия различных решений.
Во-первых, мы бы хотели выделить некоторые
фундаментальные правила разработки онтологии, к которым мы будем неоднократно
обращаться. Эти правила могут показаться довольно категоричными. Тем не менее,
во многих случаях они могут помочь принять проектные решения.
1) Не существует единственного правильного способа
моделирования предметной области – всегда существуют жизнеспособные
альтернативы. Лучшее решение почти всегда зависит от предполагаемого приложения
и ожидаемых расширений.
2) Разработка онтологии – это обязательно итеративный
процесс.
3) Понятия в онтологии должны быть близки к объектам
(физическим или логическим) и отношениям в интересующей вас предметной области.
Скорее всего, это существительные (объекты) или глаголы (отношения) в
предложениях, которые описывают вашу предметную область.
То есть, знание того, для чего вы собираетесь
использовать онтологию и насколько детальной или общей она будет, повлияет на
многие решения, касающиеся моделирования. Среди нескольких жизнеспособных
альтернатив нам нужно определить, какая поможет лучше решить поставленную
задачу и будет более наглядной, более расширяемой и более простой в
обслуживании. Нам также нужно помнить, что онтология – это модель реального
мира и понятия в онтологии должны отражать эту реальность. После того, как мы
определим начальную версию онтологии, мы можем оценить и отладить ее, используя
ее в приложениях или в методах решения задач и/или обсудив ее с экспертами
предметной области. В результате почти наверняка нам нужно будет пересмотреть
начальную онтологию. Этот процесс итеративного проектирования, вероятно, будет
продолжаться в течение всего жизненного цикла онтологии.
Шаг 1. Определение области и
масштаба онтологии
Мы предлагаем начать разработку онтологии с
определения ее области и масштаба. То есть, ответим на несколько основных
вопросов:
Какую область будет охватывать онтология?
Для чего мы собираемся использовать онтологию?
На какие типы вопросов должна давать ответы информация
в онтологии?
Кто будет использовать и поддерживать онтологию?
Ответы на эти вопросы могут измениться во время
процесса проектирования онтологии, но в любой заданный момент времени они
помогают ограничить масштаб модели.
Рассмотрим онтологию вина и еды, которую мы
представили ранее. Область нашей онтологии – представление еды и вин. Мы собираемся
использовать эту онтологию для приложений, которые будут предлагать хорошие
сочетания вин и еды.
Конечно, в нашу онтологию будут включены понятия,
описывающие различные типы вин, основные виды еды, понятие хорошего и плохого
сочетания вина и еды. В то же время, маловероятно, что онтология будет включать
понятия для управления инвентарем на винном заводе или служащими в ресторане,
даже хотя эти понятия отчасти связаны с понятиями вина и еды.
Если онтология, которую мы проектируем, будет
использоваться для помощи при обработке естественного языка статей в журналах о
винах, то, возможно, понадобится включить в онтологию синонимов понятий и
информации о частях речи. Если онтология будет использоваться для того, чтобы
помочь посетителям ресторана решить, какое вино заказать, нам нужно будет
включить информацию о розничных ценах. Если она будет использоваться для помощи
покупателям вина в создании запасов в винном погребе, то могут понадобиться
сведения об оптовых ценах и о наличии вин. Если люди, которые будут
поддерживать онтологию, опишут предметную область языком, отличающимся от языка
пользователей онтологии, то нам может потребоваться предоставить таблицу
соответствий между языками.
Вопросы для проверки компетентности
Один из способов определить масштаб онтологии – это
набросать список вопросов, на которые должна ответить база знаний, основанная
на онтологии, т.е. вопросы для проверки
компетентности. Эти вопросы будут служить лакмусовой бумажкой: Содержит
ли онтология достаточно информации для ответа на эти типы вопросов? Требуется
ли для ответов особый уровень детализации или представление определенной
области? Эти вопросы для проверки компетентности являются всего лишь
формальными и не должны быть исчерпывающими.
В области вина и еды возможны следующие вопросы для
проверки компетентности:
1. Какие характеристики вина мне следует учитывать при
выборе вина?
2. Вино Bordeaux красное или белое?
3. Хорошо ли сочетается Cabernet
Sauvignon с морскими продуктами?
4. Какое вино лучше всего подойдет к жареному мясу?
5. Какие характеристики вина влияют на его
сочетаемость с блюдом?
6. Влияет ли с год производства вина на
его букет или крепость?
7. Какие урожаи Napa Zinfandel были хорошими?
Судя по этому списку вопросов, онтология будет
включать информацию о различных характеристиках вина и типах вин, годах
производства вин (хороших и плохих), классификациях еды, которые нужно учесть
при выборе подходящего вина, рекомендуемых сочетаниях вина и еды.
Шаг 2. Рассмотрение вариантов
повторного использования существующих онтологий
Почти всегда стоит учесть, что сделал кто-то еще, и
проверить, можем ли мы улучшить и расширить существующие источники для нашей
конкретной предметной области и задачи. Повторное использование существующих
онтологий может быть необходимым, если нашей системе нужно взаимодействовать с
другими приложениями, которые уже вошли в отдельные онтологии или
контролируемые словари. Многие онтологии уже доступны в электронном виде и
могут быть импортированы в используемую Вами среду проектирования онтологии.
Формализм онтологии часто не имеет значения, т.к. многие системы представления
знаний могут импортировать и экспортировать онтологии. Даже если система
представления знаний не может работать напрямую с отдельным формализмом, задача
перевода онтологии из одного формализма в другой обычно не является сложной.
Страницы: 1, 2, 3, 4
|
