Руководство по созданию вашей первой онтологии

Зачем создавать онтологию?

Согласно одному из наиболее цитируемых определений в литературе, онтология - это формальная, явная спецификация концептуализации предметной области. Под "концептуализацией" здесь понимается описание множества понятий (концептов) предметной области, их свойств и отношений между ними.

Почему возникает потребность в разработке онтологии? Вот некоторые причины:

• Для человеко-машиночитаемого формализованного представления знаний для совместного использования людьми и приложениями
• Для возможности повторного использования знаний предметной области
• Для того чтобы сделать допущения в предметной области явными
• Для отделения знаний предметной области от оперативных знаний
• Для анализа знаний предметной области

Человеко-машиночитаемое формализованное представление знаний для совместного использования людьми и приложениями является одной из наиболее общих целей разработки онтологий.

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

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

Отделение знаний предметной области от оперативных знаний – это еще один вариант общего применения онтологий. Мы можем описать задачу конфигурирования продукта из его компонентов в соответствии с требуемой спецификацией и внедрить программу, которая делает эту конфигурацию независимой от продукта и самих компонентов.

Анализ знаний предметной области возможен, когда имеется декларативная спецификация терминов. Формальный анализ терминов чрезвычайно ценен как при попытке повторного использования существующих онтологий, так и при их расширении.

Часто онтология предметной области сама по себе не является целью. Разработка онтологии сродни определению набора данных и их структуры для использования другими программами. Методы решения задач, доменно-независимые приложения и программные агенты используют в качестве данных онтологии и базы знаний, построенные на основе этих онтологий. К примеру, в этой статье мы разрабатываем онтологию вин и еды, а также подходящие комбинации вин и блюд. Затем эту онтологию можно будет использовать как основу для приложений в наборе инструментов для управления рестораном: Одно приложение могло бы составлять список вин для меню на текущий день или отвечать на запросы официантов и посетителей. Другое приложение могло бы анализировать инвентарный перечень винного погреба и предлагать категории вин для пополнения и конкретные вина для закупки к следующим меню или для поваренных книг.

Из чего состоит онтология?

Существует несколько определений онтологии, многие из которых противоречат друг другу. В этой мы будем опираться на следующее определение: онтология — это формализованное явное описание понятий в рассматриваемой предметной области, их свойств и отношений между ними, а также ограничений, наложенных на отношения. Онтология вместе с набором индивидуальных экземпляров классов образует базу знаний. В действительности, трудно определить, где кончается онтология и где начинается база знаний. В центре большинства онтологий находятся классы. Классы описывают понятия предметной области. Например, класс вин представляет все вина. Конкретные вина – экземпляры этого класса. Вино Bordeaux – это экземпляр класса вин Bordeaux. Класс может иметь подклассы, которые представляют более конкретные понятия, чем надкласс. Например, мы можем разделить класс всех вин на красные, белые и розовые вина. В качестве альтернативы мы можем разделить класс всех вин на игристые и не игристые вина.

С помощью свойств описываются характеристики классов и экземпляров: вино Chateau Lafite Rothschild Pauillac - крепкое, оно производится на винном заводе Chateau Lafite Rothschild. У нас есть два свойства, которые описывают вино в этом примере: свойство крепость со значением крепкое и отношение производитель со значением "винный завод Chateau Lafite Rothschild". Мы можем сказать, что на уровне класса у экземпляров класса Вино есть свойства, которые описывают вкус, крепость, уровень сахара, производителя вина и т.д.

Все экземпляры класса Вино и его подкласс Pauillac имеют свойство производитель, значение которого является экземпляром класса Винный завод. Все экземпляры класса Винный завод имеют свойство производит, относящийся ко всем винам (экземплярам класса Вино и его подклассов), которые производятся на этом заводе.

На практике разработка онтологии включает следующие процессы:

• определение классов в онтологии;
• расположение классов в таксономическую иерархию (подкласс – надкласс);
• определение свойств и описание допускаемых значений этих свойств.

После этого мы можем создать базу знаний, определив отдельные экземпляры этих классов.

Методология инженерии знаний

Не существует единственного «правильного» способа или методологии разработки онтологий. Здесь мы обсуждаем общие моменты, которые нужно учитывать, и предлагаем один из возможных способов разработки онтологии. Мы описываем итеративный подход к разработке онтологии: мы начинаем с первого чернового просмотра онтологии. Затем мы проверяем и уточняем получаемую онтологию и добавляем детали. Попутно мы обсуждаем решения, касающиеся моделирования, которые должен принять разработчик, а также «за» и «против» и результаты принятия различных решений.

Фундаментальные правила разработки онтологии

1. Не существует единственного правильного способа моделирования предметной области – всегда существуют жизнеспособные альтернативы. Лучшее решение почти всегда зависит от вариантов использования онтологии и ожидаемых расширений.
2. Разработка онтологии – это обязательно итеративный процесс.
3. Понятия в онтологии должны быть близки к объектам (физическим или логическим) и отношениям в интересующей вас предметной области. Скорее всего, это существительные (объекты) и глаголы (отношения) в предложениях, которые описывают вашу предметную область.

Знание того, для чего вы собираетесь использовать онтологию и насколько детальной или общей она будет, повлияет на многие решения, касающиеся моделирования. Среди нескольких жизнеспособных альтернатив нам нужно определить, какая поможет лучше решить поставленную задачу и будет более наглядной, более расширяемой и более простой в обслуживании. Также нужно помнить, что онтология – это модель реального мира и понятия в онтологии должны отражать эту реальность. После того, как мы определим начальную версию онтологии, мы можем оценить и отладить ее, используя ее в приложениях или в методах решения задач и/или обсудив ее с экспертами предметной области. В результате, почти наверняка, нам нужно будет пересмотреть начальную онтологию. Этот процесс итеративного проектирования, вероятно, будет продолжаться в течение всего жизненного цикла онтологии.

Шаг 1. Определение предметной области и объема онтологии

Разработку онтологию предлагается начинать с определения ее предметной области и объема. То есть, необходимо ответить на несколько основных вопросов:

1. Какую предметную область будет описывать онтология?
2. Для чего мы собираемся использовать онтологию?
3. На какие типы вопросов должна давать ответы информация в онтологии?
4. Кто будет использовать и поддерживать онтологию?

Ответы на эти вопросы могут измениться во время процесса проектирования онтологии, но в любой заданный момент времени они помогают ограничить масштаб модели. Рассмотрим онтологию вина и еды, которую мы представили ранее. Предметная область нашей онтологии – представление еды и вин. Мы собираемся использовать эту онтологию для приложений, которые будут предлагать хорошие сочетания вин и еды. Конечно, в нашу онтологию будут включены понятия, описывающие различные типы вин, основные виды еды, понятие хорошего и плохого сочетания вина и еды. В то же время, маловероятно, что онтология будет включать понятия для управления инвентарем на винном заводе или служащими в ресторане, даже если эти понятия отчасти связаны с понятиями вина и еды.

Если онтология, которую мы проектируем, будет использоваться при обработке естественного языка то, возможно, понадобится включить в онтологию синонимы понятий и информацию о частях речи. Если онтология будет использоваться для того, чтобы помочь посетителям ресторана решить, какое вино заказать, нам нужно будет включить информацию о розничных ценах. Если она будет использоваться для помощи покупателям вина в создании запасов в винном погребе, то могут понадобиться сведения об оптовых ценах и о наличии вин в магазинах. Если люди, которые будут поддерживать онтологию, опишут предметную область языком, отличающимся от языка пользователей онтологии, то нам может потребоваться предоставить таблицу соответствий между языками.

Вопросы компетенции

Один из способов определить объем онтологии – это набросать список вопросов, на которые должна ответить база знаний, основанная на онтологии. Эти вопросы являются формальными и не должны быть исчерпывающими.

В области вина и еды возможны следующие вопросы компетенции:

1. Какие характеристики вина следует учитывать при выборе вина?
2. Вино Bordeaux красное или белое?
3. Хорошо ли сочетается Cabernet Sauvignon с морскими продуктами?
4. Какое вино лучше всего подойдет к жареному мясу?
5. Какие характеристики вина влияют на его сочетаемость с блюдом?
6. Влияет ли год производства вина на его букет или крепость?
7. Какие урожаи Napa Zinfandel были хорошими?

Судя по этому списку вопросов, онтология будет включать информацию о различных характеристиках вина и типах вин, годах производства вин (хороших и плохих), классификациях еды, которые нужно учесть при выборе подходящего вина, рекомендуемых сочетаниях вина и еды.

Шаг 2. Рассмотрение вариантов повторного использования существующих онтологий

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

Повторное использование существующих онтологий может быть необходимым, если нашей системе нужно взаимодействовать с другими приложениями, которые уже используют отдельные онтологии или контролируемые словари. Многие онтологии уже доступны в электронном виде и могут быть импортированы в OSA (редактор онтологий).

К примеру, база знаний по французским винам уже может существовать. Если мы можем импортировать эту базу знаний и онтологию, на которой она основана, то у нас будет не только классификация французских вин, но и первый шаг к классификации характеристик вин.

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

Шаг 3. Перечисление основных понятий онтологии

Полезно составить список всех понятий (классов), о которых мы хотели бы сказать что-либо, или которые хотели бы объяснить пользователю. Какие понятия мы бы хотели рассмотреть? Какие свойства имеют эти понятия? Что бы мы хотели сказать об этих понятиях? Например, в число важных понятий, связанных с винами, входят вино, виноград, винный завод, местоположение, цвет вина, его крепость, вкус и содержание сахара; различные виды еды, такие как рыба и мясо; типы вина, такие как белое вино и т.д. В начале важно получить список понятий (не обязательно полный), не беспокоясь об их свойствах и отношениях.

Следующие два шага – разработка иерархии классов и определение свойств понятий – тесно переплетены. Сложно выполнить сначала один из них, а потом – другой. Обычно в иерархии мы даем несколько формулировок понятий и затем описываем свойства этих понятий и т.д. Также эти два шага – самые важные шаги в процессе проектирования онтологии. Здесь мы опишем их вкратце, а затем в следующих двух главах рассмотрим более сложные проблемы, которые необходимо принять во внимание, часто встречающиеся трудности, решения, которые нужно принять, и т.д.

Шаг 4. Определение классов и иерархии классов

Существует несколько возможных подходов для разработки иерархии классов:

• Процесс нисходящей разработки начинается с определения самых общих понятий предметной области с последующей конкретизацией понятий. Например, мы можем начать с создания классов для общих понятий Вино и Еда. Затем мы конкретизируем класс Вино, создавая его подклассы: Белое вино, Красное вино, Розовое вино. Мы можем еще дальше категоризировать класс Красное Вино, например, Syrah, Red Burgundy, Cabernet Sauvignon и т.д.
• Процесс восходящей разработки начинается с определения самых конкретных классов, листьев иерархии, с последующей группировкой этих классов в более общие понятия. Например, сначала мы определяем классы для вин Pauillac и Margaux. Затем мы создаем общий надкласс для двух этих классов – Medoc, который, в свою очередь является подклассом Bordeaux.
• Процесс комбинированной разработки – это сочетание нисходящего и восходящего подходов: сначала мы определяем более заметные понятия, а затем соответствующим образом обобщаем и ограничиваем их. Мы могли бы начать с нескольких понятий высшего уровня, таких как Вино, и нескольких конкретных понятий, таких как Margaux. Затем мы можем соотнести их с понятием среднего уровня, таким как Medoc. После этого нам может понадобиться сформировать все классы вин из области Франции, формируя таким образом ряд понятий среднего уровня.

На рисунке ниже показаны различные уровни таксономии (иерархии классов): Вино, Белое вино, Красное вино, Розовое вино - более общие понятия, верхний уровень таксономии. Pauillac и Margaux – самые конкретные классы в иерархии, нижний уровень.

Ни один из этих трех методов не лучше других по своей сути. Выбор подхода в большой степени зависит от личного взгляда на предметную область. Если разработчик склонен к рассмотрению предметной области сверху вниз, то ему, возможно, больше подойдет нисходящий метод. Часто для многих разработчиков онтологий самым простым является комбинированный метод, т.к. понятия, находящиеся «посередине», имеют тенденцию быть самыми наглядными понятиями в предметной области.

Какой метод мы бы ни избрали, обычно мы начинаем с определения классов. Из списка, составленного на Шаге 3, мы выбираем понятия, которые описывают объекты, существующие независимо, а не понятия, характеризующие эти объекты. В онтологии эти понятия будут классами. Мы организуем классы в иерархическую таксономию, задавая вопрос: если объект является экземпляром одного класса, будет ли он обязательно (т.е. по определению) экземпляром некоторого другого класса?

Если класс А – надкласс класса В, то каждый экземпляр В также является экземпляром А.

Другими словами, класс В представляет собой понятие, которое является «разновидностью» А. Например, каждое вино Pinot Noir – обязательно Красное вино. Поэтому класс Pinot Noir – подкласс класса Красное вино.

Шаг 5. Определение свойств классов

Классы сами по себе не предоставляют достаточно информации для ответа на вопросы компетенции из Шага 1. После определения некоторого количества классов мы должны описать внутреннюю структуру понятий.

Мы уже выбрали классы из списка понятий, который мы создали на Шаге 3. Большинство оставшихся понятий, вероятно, будут свойствами этих классов. Эти понятия включают, к примеру, цвет вина, его крепость, вкус и содержание сахара, а также местоположение винного завода.

Для каждого свойства из списка мы должны определить, какой класс оно описывает. Эти свойства станут свойствами классов. Таким образом, у класса Вино будут следующие свойства: цвет, крепость, вкус и сахар. А у класса Винный завод будет свойство местоположение.

В редакторе OSA свойства могут быть скалярными и типизированными (чаще называются отношениями). Значениями скалярных свойств могут быть значения простых (скалярных) типов данных: строка, число, дата и т.п., а значениями отношений являются экземпляры классов (например, производитель вина, представляющий отношением между вином и винным заводом).

Таким образом, к классу Вино нам нужно добавить следующие свойства и отношения: область, производитель, виноград и др. Все подклассы класса наследуют свойства этого класса. Например, все свойства класса Вино будут унаследованы всеми подклассами этого класса, включая Красное Вино и Белое Вино. К классу Красное Вино мы добавим дополнительное свойство уровень танина (низкий, средний или высокий). Свойство уровень танина будет унаследовано всеми классами, представляющими красные вина (такие как Bordeaux и Beaujolais).

Свойство должно быть привязано к самому общему классу, у которого может быть данное свойство. Например, крепость и цвет вина нужно будет привязать к классу Вино, т.к. это самый общий класс, чьи экземпляры будут иметь крепость и цвет.

Как уже было сказано выше, свойства могут иметь различные типы, которые описывают типы значений свойств, разрешенные значения, число значений (мощность) и другие свойства значений, которые может принимать свойство.

Например, значение свойства год урожая – целое число. То есть, год урожая – это скалярное свойство с типом значения Целое число. Отношение производит (как в выражении «винный завод производит эти вина») может иметь множество значений, которые являются экземплярами класса Вино. То есть, производит – это отношение, типизированное классом Вино.

Мощность свойства

Мощность свойства определяет, сколько значений может иметь отношение. В редакторе онтологий OSA для свойства можно задать единичную мощность (возможно только одно значение) и множественную мощность (возможно любое число значений). Крепость вина будет свойством единичной мощности (вино может иметь только одну крепость). Вина, производимые на конкретном заводе, заполняют свойство множественной мощности производит класса Винный завод.

Также, редактор онтологий OSA позволяет определить минимальную и максимальную мощность для того, чтобы более точно описать количество значений свойства. Минимальная мощность N означает, что свойство должно иметь не менее N значений. Например, свойство виноград класса Вино имеет минимальную мощность 1: каждое вино делается, как минимум, из одного сорта винограда. Максимальная мощность М означает, что свойство может иметь максимум М значений. Максимальная мощность свойства виноград для моносортовых вин равняется 1.

Домены и диапазоны отношения

Класс, характеристики которого описывает свойство, называется доменом свойства. Класс, которым свойство типизируется, называется диапазоном свойства. На рисунке ниже класс Вино является диапазоном свойства производит, а класс Винный завод - доменом этого свойства. Для отношения производитель класс Вино является доменом, а Винный завод - диапазоном.

Основные правила определения домена и диапазона свойства схожи друг с другом:

• При определении домена или диапазона свойства найдите наиболее общие классы или класс, которые могут быть соответственно доменом или диапазоном свойства
• С другой стороны, не определяйте слишком общий домен и диапазон: все экземпляры домена свойства должны быть описаны свойством, а экземпляры всех диапазонов должны являться потенциальными значениями свойства.

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

Для свойства уровень танина мы могли бы указать в качестве домена все классы, представляющие красные вина (например, Bordeaux, Merlot, Beaujolais и т.д.). Однако, т.к. все красные вина имеют свойство уровень танина, то вместо этого нам нужно указать в качестве домена один более общий класс Красные Вина. Будет неправильно дальше обобщать домен свойства уровень танина (например, указать в качестве домена класс Вино), т.к. мы не используем уровень танина для описания, к примеру, белых вин.

Инверсные свойства

Значение свойства может зависеть от значения другого свойства. Например, если Вино было произведено на Винном заводе, то Винный завод производит это Вино. Эти два отношения, производитель и производит, называются инверсными отношениями.

Излишне хранить информацию и о том, и о другом. Когда мы знаем, что вино производится на винном заводе, то приложение, которое использует базу знаний, всегда может вывести значение для инверсного отношения: винный завод производит вино. Тем не менее, с точки зрения приобретения знаний удобно иметь оба отношения доступными в явном виде. Этот подход позволяет пользователям указать вино в одном случае и винный завод в другом. После это система приобретения знаний может автоматически заполнить значение для инверсного отношения, обеспечивая согласованность базы знаний.

В нашем примере есть пара инверсных свойств: производитель класса Вино и производит класса Винный завод. Когда пользователь создает экземпляр класса Вино и заполняет значение свойства производитель, система автоматически добавляет вновь созданный экземпляр к свойству производит соответствующего экземпляра класса Винный завод. Например, когда мы говорим, что Sterling Merlot производится на заводе Sterling Vineyard, система автоматически добавляет Sterling Merlot к списку вин, которые производит завод Sterling Vineyard.

Шаг 6. Создание экземпляров

Последний шаг – это создание экземпляров классов (также их называют индивидами). Для создания экземпляра класса требуется (1) выбрать класс, (2) создать этого класса и (3) ввести значения свойств и отношений.

Например, мы можем создать экземпляр Chateau-Morgon-Beaujolais для представления определенного типа вина Beaujolais. Chateau-Morgon-Beaujolais – это экземпляр класса Beaujolais, представляющего все вина Beaujolais. У этого экземпляра, могут быть определены следующие значения свойств:

• Крепость: Легкое
• Вкус: Мягкий
• Уровень танина: Низкий
• Виноград: Gamay (экземпляр класса Виноград для изготовления вин)
• Производитель: Chateau-Morgon (экземпляр класса Винный завод)
• Область: Beaujolais (экземпляр класса Винная область)
• Сахар: Сухое

Определение классов и иерархии классов

В этом разделе говорится о том, что нужно учитывать и об ошибках, которые легко допустить при определении классов и иерархии классов (Шаг 4). Как уже говорилось ранее, для любой предметной области не существует единственной правильной иерархии классов. Иерархия зависит от возможных способов применения онтологии, уровня детализации, необходимого для приложения, личных предпочтений и иногда от требований по совместимости с другими моделями. Тем не менее, рассмотрим несколько руководящих принципов, которые нужно учитывать при разработке иерархии классов. После определения значительного количества новых классов полезно остановиться и проверить, соответствует ли возникающая иерархия этим руководящим принципам.

Обеспечение правильности иерархии классов

Отношение "является подклассом" Иерархия классов строится с использованием отношений является подклассом: класс А – это подкласс В, если каждый экземпляр В также является экземпляром А. Например, Chardonnay – подкласс класса Белое Вино. Другой способ подхода к таксономическому отношению является подклассом – это рассматривать его как отношение является видом или является разновидностью: Chardonnay – вид Белого вина. Реактивный лайнер – вид Самолета. Мясо – вид Еды.

Подкласс класса представляет понятие, которое является «разновидностью» понятия, представляемого надклассом.

Отдельно взятое вино не является подклассом всех вин Распространенная ошибка при моделировании – это включение в иерархию варианта одного и того же понятия как в единственном, так и во множественном числе, сделав первое подклассом второго. Например, будет неправильно определить класс Вина и класс Вино как подкласс класса Вина. Как только вы начинаете считать, что иерархия представляет собой отношение является разновидностью, то ошибка при моделировании становится очевидной: отдельное Вино не является видом Вин. Лучший способ избежать таких ошибок – всегда использовать имена классов или в единственном, или во множественном числе.

Транзитивность иерархических отношений Отношение является подклассом транзитивно:

Если В – это подкласс А, а С – подкласс В, то С – подкласс А.

Например, мы можем определить класс Вино, а потом определить класс Белое вино как подкласс класса Вино. Затем мы определяем класс Chardonnay как подкласс класса Белое Вино. Транзитивность отношения является подклассом означает, что класс Chardonnay также является подклассом класса Вино. Иногда мы различаем прямые и косвенные подклассы. Прямой подкласс – самый близкий подкласс класса: в иерархии между классом и его прямым подклассом нет других классов. То есть, между классом и его прямым надклассом в иерархии нет других классов. В нашем примере Chardonnay – это прямой подкласс класса Белое вино и не прямой подкласс класса Вино.

Развитие иерархии классов Необходимо поддерживать иерархию классов в актуальном состоянии по мере того, как развиваются предметные области. Например, много лет все вина Zinfandel были красными. Поэтому мы определили класс вин Zinfandel как подкласс класса Красное вино, но производители научились удалять цветообразующие вещества из виноградного сока, изменяя таким образом цвет получаемого вина. Так мы получили «белое Zinfandel» розового цвета. Теперь нам нужно разбить класс Zinfandel на 2 класса – Белое zinfandel и Красное zinfandel – и классифицировать их как подклассы классов Розовое вино и Красное вино соответственно.

Классы и их имена Важно различать класс и его имя:

Классы представляют понятия предметной области, а не слова, которые обозначают эти понятия.

Имя класса может измениться, если мы выберем другую терминологию, но сам термин представляет объективную реальность мира. Например, мы можем создать класс Shrimps (англ. - Креветки), а потом переименовать его в Prawns (англ. - также Креветки) – класс представляет все то же понятие. Вина, которые подходили к блюдам из Shrimps, должны подходить к блюдам из Prawns. В действительности нужно все время соблюдать правило:

Синонимы одного и того же понятия не представляют различные классы.

Синонимы – всего лишь разные имена понятия или термина. Следовательно, у нас не должно быть класса с именем Shrimp и одновременно с этим класса с именем Prawn. Предпочтительнее будет иметь один класс с именем Shrimp или Prawn.

Избегание циклов в иерархии Следует избегать циклы в иерархии классов. Мы говорим, что в иерархии есть цикл, когда у некоторого класса А есть подкласс В и в то же время В – это надкласс А. Создание такого цикла в иерархии равнозначно объявлению того, что классы А и В эквивалентны: все экземпляры А – это экземпляры В, а все экземпляры В также являются экземплярами А. Действительно, поскольку В – подкласс А, то все экземпляры В должны быть экземплярами класса А. Поскольку А – подкласс В, то все экземпляры А также должны быть экземплярами класса В.

Анализ узлов-братьев в иерархии классов

Узлы-братья в иерархии классов Узлы-братья в иерархии - это классы, которые являются прямыми подклассами одного и того же класса.

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

Например, Белое вино и Chardonnay не должны быть подклассами одного и того же класса (скажем, класса Вино). Белое вино – более общее понятие, чем Chardonnay. Узлы-братья должны представлять понятия, которые находятся «на одной линии», так же как разделы одного уровня в книге должны находиться на одном уровне обобщения. В этом смысле требования к иерархии классов похожи на требования к структуре книги.

Однако понятия, которые находятся в корне иерархии (и которые всегда представлены как прямые подклассы некоторого самого общего класса, такого как Thing), представляют основные деления в предметной области и не обязаны быть схожими понятиями.

Что значит «слишком много» и «слишком мало»? Не существует жестких правил относительно того, сколько прямых подклассов должен иметь класс. Тем не менее, во многих онтологиях с четкой структурой имеется от двух до десяти прямых подклассов. Отсюда следуют два руководящих принципа:

Если класс имеет только один прямой подкласс, то, возможно, при моделировании допущена ошибка или онтология неполная.

Если у класса есть более десяти подклассов, то, возможно, необходимы дополнительные промежуточные категории.

Например, большинство красных бургундских вин – это вина Cotes d’Or. Предположим, что мы хотели представить только этот основной тип бургундских вин. Мы могли создать класс Red Burgundy и затем единственный подкласс Cotes d’Or (см. рис. ниже слева). Тем не менее, если в нашем представлении красные бургундские вина и вина Cotes d’Or, по существу, эквивалентны (все красные бургундские вина являются винами Cotes d’Or и все вина Cotes d’Or – это красные бургундские вина), то нет необходимости создавать класс Cotes d’Or, он не добавит в онтологию новую информацию. Но если бы нам нужно было включить вина Cotes Chalonnaise (более дешевые бургундские вина из области к югу от Cotes d’Or), то мы бы создали два подкласса класса Burgundy: Cotes d’Or и Cotes Chalonnaise (см. рис. ниже справа).

Теперь предположим, что мы перечислили все вина как прямые подклассы класса Вино. Тогда этот список будет включать такие более общие сорта, как Beaujolais и Bordeaux, так же как и более конкретные вина, как Paulliac и Margaux (см. рис. ниже слева).

У класса Вино слишком много подклассов и, действительно, для того чтобы онтология отражала различные сорта вин более четко, Medoc должно быть подклассом Bordeaux, а Margaux подклассом Medoc. Кроме того, наличие таких категорий как Красное вино и Белое Вино также будет отражать ту понятийную модель предметной области вин, которая есть у многих людей (см. рис. ниже справа). Тем не менее, если не существует естественных категорий для группировки понятий, то не нужно создавать искусственные классы – оставьте все, как есть. В конце концов, онтология – это отражение реального мира, и если в действительности категоризации нет, то онтология должна это отражать.

Множественное наследование

Класс может быть подклассом нескольких классов (множественное наследование в иерархии классов). Предположим, что мы хотим создать отдельный класс десертных вин - класс Десертное вино. Вино Port является и красным, и десертным вином. Следовательно, мы определяем, что у класса Port есть 2 надкласса: Красное вино и Десертное вино. Все экземпляры класса Port будут экземплярами как класса Красное вино, так и класса Десертное вино. Класс Port унаследует свойства от обоих родительских классов.

Когда вводить (или не вводить) новый класс

Одно из самых сложных решений, которое нужно принять во время моделирования - это определить, когда ввести новый класс или когда сформулировать различие с помощью разных значений свойств. Сложно ориентироваться как в иерархии с очень большой степенью вложенности и множеством посторонних классов, так и в очень плоской иерархии, где очень мало классов, но в их свойствах закодировано слишком много информации. Найти подходящий баланс нелегко.

Существует несколько практических способов определения того, когда в иерархию следует ввести новые классы:

Обычно подклассы класса имеют дополнительные свойства, которых нет у надкласса, или состоят в других отношениях, нежели надклассы.

Например, у красных вин разные уровни танина, тогда как это свойство не используется для описания вин в общем. Вина Pinot Noir могут хорошо сочетаться с морскими продуктами, тогда как другие красные вина – нет. Другими словами, мы обычно вводим в иерархию новый класс только тогда, когда мы можем сказать про этот класс что-то такое, чего мы не можем сказать о надклассе.

Однако иногда может быть полезно создать новые классы в иерархии, даже если они не вводят никаких новых свойств.

Классы в иерархиях терминов не обязаны иметь новые (дополнительные) свойства.

Когда мы определяем иерархию классов, наша цель – добиться равновесия между созданием классов, которые полезны для организации классов, и созданием слишком большого числа классов. К примеру, мы ввели классы Красное вино, Белое вино и Розовое вино, так как это разделение является естественным в мире вин, но не вводили классы для изысканного вина, для вин с умеренным вкусом и т.д.

Новый класс или свойство?

При моделировании предметной области нам часто нужно решать, моделировать ли определенное разграничение (такое как белое, красное или розовое вино) как значение свойства или как набор классов, что опять же зависит от масштаба предметной области и от решаемой задачи.

Создать ли нам класс Белое вино или создать класс Вино и свойство класса цвет вина? Ответ всегда зависит от того масштаба, который мы определили для онтологии. Насколько важно понятие Белое вино в нашей предметной области? Если важность цвета вин в предметной области незначительна и то, белое это вино или нет, не особо влияет на его отношения с другими объектами, то нам не нужно вводить отдельный класс белых вин. Для модели предметной области, используемой на предприятии, где производятся винные этикетки, правила для этикеток вин различных цветов одни и те же и разделение не столь важно. И наоборот, для представления вина, еды и их подходящих сочетаний, красное вино сильно отличается от белого: оно сочетается с другой едой, у него другие свойства и т.д. Также, цвет вина важен для базы знаний по винам, которую мы можем использовать для определения последовательности дегустации вин. Поэтому мы создаем отдельный класс Белое вино.

Если понятия с разными значениями свойств становятся ограничениями для различных свойств в других классах, то для разделения следует создать новый класс. В противном случае разделение представляется в значении свойства.

Подобным образом, в онтологии вин есть такие классы как Красное Merlot и Белое Merlot, а не единый класс для всех вин Merlot: красные Merlot и белые Merlot – это действительно разные вина (сделанные из одного винограда), и если мы разрабатываем подробную онтологию, то это разделение представляет важность.

Если в предметной области разделение объектов представляет важность и объекты с разными значениями свойств мы рассматриваем как разные типы объектов, то для осуществления разделения нам нужно создать новый класс.

При принятии решения о том, вводить новый класс или нет, также может быть полезно рассмотреть экземпляры класса.

Класс, которому принадлежит экземпляр, не должен часто меняться.

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

В качестве другого примера рассмотрим онтологию человеческой анатомии. Когда мы представляем ребра, создаем ли мы класс для «1-го левого ребра», потом класс для «2-го левого ребра» и т.д.? Или у нас есть класс Ребро со свойствами для последовательности и стороны (левое - правое)? Если информация о каждом из ребер, которые мы представляем в онтологии, существенно отличается, то нам, действительно, нужно создать класс для каждого ребра. То есть, если мы хотим подробно представить информацию о смежности и положении (которые различны для всех ребер), а также особые функции, которые выполняет каждое ребро, и какие органы оно защищает, то нам нужно создать классы. Если мы моделируем анатомию на чуть более низком уровне обобщения и для наших потенциальных приложений все ребра очень похожи (мы говорим всего лишь о том, какое ребро сломано, судя по рентгеновскому снимку, безотносительно к другим частям тела), то нам потребуется упростить иерархию и оставить только класс Ребро с двумя свойствами: сторона и порядковый номер.

Экземпляр или класс?

Определение того, чем является определенное понятие - классом в онтологии или экземпляром - зависит от потенциальных приложений онтологии. Определение того, где заканчиваются классы и начинаются экземпляры, начинается с определения нужной глубины детализации. Глубина детализации, в свою очередь, определяется потенциальным приложением онтологии. Другими словами, какие самые конкретные элементы будут представлены в базе знаний? Если возвратиться к вопросам компетенции, самые конкретные понятия, которые будут ответами на эти вопросы, лучше всего подойдут на роль экземпляров в базе знаний.

Отдельные экземпляры - самые конкретные понятия, представленные в базе знаний.

Например, если мы собираемся говорить только о подборе сочетаний вина и еды, то нас не будут интересовать конкретные материальные бутылки вина. Поэтому такие термины как Sterling Vineyards Merlot, вероятно, будут самыми конкретными используемыми нами терминами. Следовательно, Sterling Vineyards Merlot будет экземпляром в базе знаний.

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

Аналогично, если бы мы хотели записать различные качества для каждого конкретного урожая Sterling Vineyards Merlot, то экземпляром в базе знаний стал бы конкретный урожай вина, а Sterling Vineyards Merlot стал бы классом, содержащим экземпляры всех его урожаев.

Другое правило может «переместить» некоторые отдельные экземпляры в разряд классов:

Если понятия формируют естественную иерархию, то нам нужно представить их, как классы.

Рассмотрим винные области. В начале мы можем определить основные винные регионы, такие как Франция, США, Германия и т.д. как классы, а конкретные винные области внутри этих регионов как экземпляры. Например, область Bourgogne – это экземпляр класса регион Франция. Однако мы бы также хотели отметить, что область Cotes d’Or – это область Bourgogne. Поэтому область Bourgogne должна быть классом (чтобы иметь подклассы или экземпляры). Представление области Bourgogne как класса, а области Cotes d’Or как экземпляра области Bourgogne кажется произвольным: очень сложно четко разграничить, какие области являются классами, а какие – экземплярами. Поэтому мы определяем все винные области как классы.

Так же иерархия классов была бы неправильной, если бы мы пропустили в имени класса слово «область». Мы не можем сказать, что класс Alsace – это подкласс класса Франция: Alsace – это не разновидность Франции. Тем не менее, область Alsace – разновидность региона Франция.

В виде иерархии можно представить только классы – в системах представления знаний нет категории «подэкземпляр». Поэтому, если среди терминов существует естественная иерархия, то нам нужно охарактеризовать эти термины как классы.

Ограничение масштаба онтологии

Онтология не должна содержать всю возможную информацию о предметной области: вам не нужно конкретизировать или обобщать больше, чем вам нужно для вашего приложения.

Для примера с вином и едой нам не требуется знать, из какой бумаги делаются этикетки, или как готовятся блюда из креветок.

Также онтология не должна содержать все возможные свойства классов. В онтологии мы представляем самые значимые свойства классов.

Рассмотрим онтологию, описывающую биологические эксперименты. Эта онтология, вероятно, будет содержать понятие Биологические организмы. Она также будет содержать понятие Экспериментатор (включающее имя, место работы и т.д.), который проводит эксперимент. Верно то, что экспериментатор как человек также является биологическим организмом. Тем не менее, мы не должны отражать эту особенность в онтологии: в целях этого представления экспериментатор не является биологическим организмом, и мы, наверное, никогда не будем проводить эксперименты на самих экспериментаторах.

Если бы в онтологии мы делали представление всего того, что мы можем сказать о классах, то Экспериментатор бы стал подклассом класса Биологический организм. Однако нет необходимости включать это знание для возможных приложений. Фактически, включение этой дополнительной классификации существующих классов действительно мешает: теперь у экземпляра Экспериментатора будут свойства для веса, возраста, вида и других данных, которые относятся к биологическому организму, но совершенно неуместны в контексте описания эксперимента.

Об именах

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

Определить единые правила присваивания имен классам и свойствам и придерживаться их.

Заглавные буквы и разделители

Мы можем значительно улучшить читаемость онтологии, если все время будем писать названия понятий с большой буквы. Например, общепринято начинать имена классов с большой буквы, а имена свойств – с маленькой.

Единственное или множественное число

Имя класса представляет набор объектов. Например, класс Вино в действительности представляет все вина. Поэтому для многих разработчиков было бы естественнее дать классу имя Вина, а не Вино. Ни один из вариантов не лучше и не хуже другого (хотя на практике для имен классов чаще используется единственное число). Тем не менее, каким бы ни был выбор, его следует придерживаться на протяжении всей онтологии. Использование все время одной и той же формы также предотвращает такие ошибки разработчика при моделировании, как создание класса Вина, а затем создание класса Вино как его подкласса.

Существительные или глаголы

Некоторые методологии по базам знаний советуют придерживаться договоренности в отношении использования частей речи в именах для того, чтобы различать классы и свойства. Имена классов, как правило, являются существительными (например, Вино, Производитель), а имена свойств - глаголами (например, производит, имеет цвет).

Другие соображения по присваиванию имен

Еще несколько моментов, которые нужно иметь в виду при определении правил присваивания имен:

• Не добавляйте к именам понятий такие строки как «класс», «свойство». Из контекста всегда ясно, что это класс или свойство.
• Обычно лучше не сокращать имена понятий (то есть, используйте Cabernet Sauvignon, а не Cab S).
• Имя надкласса должно входить или во все имена прямых подклассов, или ни в одно из них. Например, если мы создаем два подкласса класса Вино для представления красных и белых вин, то подклассы должны называться или Красное Вино и Белое Вино, или Красное и Белое, но не Красное Вино и Белое.

Заключение

В этом руководстве мы описали методологию разработки онтологии. Мы перечислили шаги при разработке онтологии и затронули сложные вопросы определения иерархий классов и свойств классов и экземпляров. Тем не менее, помимо всех правил и советов, следует помнить одну из важнейших вещей: для любой предметной области не существует единственно правильной онтологии. Проектирование онтологии – это творческий процесс и две онтологии, разработанные разными людьми, никогда не будут одинаковыми. Потенциальные приложения онтологии, а также понимание разработчиком предметной области и его точка зрения, несомненно, будут влиять на принятие решений при проектировании онтологии. "Цыплят по осени считают" – мы можем оценить качество нашей онтологии, только используя ее в приложениях, для которых мы ее разработали.

Источники

Настоящее руководство является адаптацией перевода Филяева А.И. статьи "Ontology Development 101: A Guide to Creating Your First Ontology", Natalya F. Noy and Deborah L. McGuinness, Stanford University, Stanford, CA, 94305.