[1]
Наталья Ф. Ной (NatalyaF. Noy) и Дэбора Л. МакГиннесс (DeborahL. 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вteauLafite RothschildPauillac — крепкое, оно производится навинном заводе ChвteauLafite Rothschild.У нас есть два слота, которые описывают вино в этом примере: слот крепость со значением «крепкое» и слотпроизводитель со значением «винный завод ChвteauLafite Rothschild».Мы можем сказать, что на уровне класса у экземпляров класса Вино есть слоты,которые описывают вкус, крепость, уровень сахара, производителя вина и т.д.[1]
Все экземпляры класса Вино и его подкласс Pauillacимеют слот производитель, значение которого является экземпляром класса Винный завод (Рис. 1). Все экземпляры класса Винный заводимеют слот производит, относящийся ко всем винам (экземплярам класса Вино и егоподклассов), которые производятся на этом заводе.
На практике разработка онтологии включает:
определение классов в онтологии;
расположение классов в таксономическую иерархию(подкласс – надкласс);
определение слотов и описание допускаемых значенийэтих слотов;
заполнение значений слотов экземпляров.
После этого мы можем создать базу знаний, определивотдельные экземпляры этих классов, введя в определенный слот значение идополнительные ограничения для слота.
/>
Рис. 1. Некоторые классы в области вин, экземпляры иотношения между ними. Черным мы обозначили классы, а красным – экземпляры.Прямые связи обозначают слоты и внутренние связи, такие как «экземпляр[класса]» и «подкласс [класса]».
/>3. Простая методологияинженерии знаний
Как мы сказали выше, не существует единственного«правильного» способа или методологии разработки онтологий. Здесь мы обсуждаемобщие моменты, которые нужно учитывать, и предлагаем один из возможных способовразработки онтологии. Мы описываем итеративный подход к разработке онтологии:мы начинаем с первого чернового просмотра онтологии. Затем мы проверяем иуточняем получаемую онтологию и добавляем детали. Попутно мы обсуждаем решения,касающиеся моделирования, которые должен принять разработчик, а также «за» и«против» и результаты принятия различных решений.
Во-первых, мы бы хотели выделить некоторыефундаментальные правила разработки онтологии, к которым мы будем неоднократнообращаться. Эти правила могут показаться довольно категоричными. Тем не менее,во многих случаях они могут помочь принять проектные решения.
1) Не существует единственного правильного способамоделирования предметной области – всегда существуют жизнеспособныеальтернативы. Лучшее решение почти всегда зависит от предполагаемого приложенияи ожидаемых расширений.
2) Разработка онтологии – это обязательно итеративныйпроцесс.
3) Понятия в онтологии должны быть близки к объектам(физическим или логическим) и отношениям в интересующей вас предметной области.Скорее всего, это существительные (объекты) или глаголы (отношения) впредложениях, которые описывают вашу предметную область.
То есть, знание того, для чего вы собираетесьиспользовать онтологию и насколько детальной или общей она будет, повлияет намногие решения, касающиеся моделирования. Среди нескольких жизнеспособныхальтернатив нам нужно определить, какая поможет лучше решить поставленнуюзадачу и будет более наглядной, более расширяемой и более простой вобслуживании. Нам также нужно помнить, что онтология – это модель реальногомира и понятия в онтологии должны отражать эту реальность. После того, как мыопределим начальную версию онтологии, мы можем оценить и отладить ее, используяее в приложениях или в методах решения задач и/или обсудив ее с экспертамипредметной области. В результате почти наверняка нам нужно будет пересмотретьначальную онтологию. Этот процесс итеративного проектирования, вероятно, будетпродолжаться в течение всего жизненного цикла онтологии.
/>Шаг 1. Определение области имасштаба онтологии
Мы предлагаем начать разработку онтологии сопределения ее области и масштаба. То есть, ответим на несколько основныхвопросов:
Какую область будет охватывать онтология?
Для чего мы собираемся использовать онтологию?
На какие типы вопросов должна давать ответы информацияв онтологии?
Кто будет использовать и поддерживать онтологию?
Ответы на эти вопросы могут измениться во времяпроцесса проектирования онтологии, но в любой заданный момент времени онипомогают ограничить масштаб модели.
Рассмотрим онтологию вина и еды, которую мыпредставили ранее. Область нашей онтологии – представление еды и вин. Мы собираемсяиспользовать эту онтологию для приложений, которые будут предлагать хорошиесочетания вин и еды.
Конечно, в нашу онтологию будут включены понятия,описывающие различные типы вин, основные виды еды, понятие хорошего и плохогосочетания вина и еды. В то же время, маловероятно, что онтология будет включатьпонятия для управления инвентарем на винном заводе или служащими в ресторане,даже хотя эти понятия отчасти связаны с понятиями вина и еды.
Если онтология, которую мы проектируем, будетиспользоваться для помощи при обработке естественного языка статей в журналах овинах, то, возможно, понадобится включить в онтологию синонимов понятий иинформации о частях речи. Если онтология будет использоваться для того, чтобыпомочь посетителям ресторана решить, какое вино заказать, нам нужно будетвключить информацию о розничных ценах. Если она будет использоваться для помощипокупателям вина в создании запасов в винном погребе, то могут понадобитьсясведения об оптовых ценах и о наличии вин. Если люди, которые будутподдерживать онтологию, опишут предметную область языком, отличающимся от языкапользователей онтологии, то нам может потребоваться предоставить таблицусоответствий между языками.
Вопросы для проверки компетентности
Один из способов определить масштаб онтологии – этонабросать список вопросов, на которые должна ответить база знаний, основаннаяна онтологии, т.е. вопросы для проверкикомпетентности. Эти вопросы будут служить лакмусовой бумажкой: Содержитли онтология достаточно информации для ответа на эти типы вопросов? Требуетсяли для ответов особый уровень детализации или представление определеннойобласти? Эти вопросы для проверки компетентности являются всего лишьформальными и не должны быть исчерпывающими.
В области вина и еды возможны следующие вопросы дляпроверки компетентности:
1. Какие характеристики вина мне следует учитывать привыборе вина?
2. Вино Bordeaux красное или белое?
3. Хорошо ли сочетается CabernetSauvignon с морскими продуктами?
4. Какое вино лучше всего подойдет к жареному мясу?
5. Какие характеристики вина влияют на егосочетаемость с блюдом?
6. Влияет ли с год производства вина наего букет или крепость?
7. Какие урожаи Napa Zinfandel были хорошими?
Судя по этому списку вопросов, онтология будетвключать информацию о различных характеристиках вина и типах вин, годахпроизводства вин (хороших и плохих), классификациях еды, которые нужно учестьпри выборе подходящего вина, рекомендуемых сочетаниях вина и еды.
/>Шаг 2. Рассмотрение вариантовповторного использования существующих онтологий
Почти всегда стоит учесть, что сделал кто-то еще, ипроверить, можем ли мы улучшить и расширить существующие источники для нашейконкретной предметной области и задачи. Повторное использование существующихонтологий может быть необходимым, если нашей системе нужно взаимодействовать сдругими приложениями, которые уже вошли в отдельные онтологии иликонтролируемые словари. Многие онтологии уже доступны в электронном виде имогут быть импортированы в используемую Вами среду проектирования онтологии.Формализм онтологии часто не имеет значения, т.к. многие системы представлениязнаний могут импортировать и экспортировать онтологии. Даже если системапредставления знаний не может работать напрямую с отдельным формализмом, задачаперевода онтологии из одного формализма в другой обычно не является сложной.
В литературе и всемирной паутине существуют библиотекиповторно используемых онтологий. Например, мы можем использовать библиотекуонтологий Ontolingua (http://www.ksl.stanford.edu/software/ontolingua/) или библиотеку онтологий DAML (http://www.daml.org/ontologies/). Существует также ряд общедоступных коммерческих онтологий(например, UNSPSC (www.unspsc.org), RosettaNet (www.rosettanet.org), DMOZ (www.dmoz.org)).
К примеру, база знаний по французским винам уже можетсуществовать. Если мы можем импортировать эту базу знаний и онтологию, накоторой она основана, то у нас будет не только классификация французских вин,но и первый шаг к классификации характеристик вин, использующихся дляразделения и описания вин. Списки свойств вина уже могут быть доступны накоммерческих веб-сайтах, таких как www.wines.com/,которые клиенты используют при покупке вин.
Тем не менее, в этом руководстве мы будем считать, чтосоответствующих онтологий еще не существует, и начнем разрабатывать онтологию снуля.
/>Шаг 3. Перечисление важныхтерминов в онтологии
Полезно составить список всех терминов, о которых мыхотели бы сказать что-либо или которые хотели бы объяснить пользователю. Какиетермины мы бы хотели рассмотреть? Какие свойства имеют эти термины? Что бы мыхотели сказать об этих терминах? Например, в число важных терминов, связанных свинами, входят вино, виноград, винный завод, местоположение, цвет вина, егокрепость, вкус и содержание сахара; различные виды еды, такие как рыба и черноемясо; типы вина, такие как белое вино и т.д. В начале важно получить полныйсписок терминов, не беспокоясь о пересечении понятий, которые они представляют,об отношениях между терминами, о возможных свойствах понятий или о том, чемявляются понятия – классами или слотами.
Следующие два шага – разработка иерархии классов иопределение свойств понятий (слотов) – тесно переплетены. Сложно выполнитьсначала один из них, а потом – другой. Обычно в иерархии мы даем несколькоформулировок понятий и затем описываем свойства этих понятий и т.д. Также этидва шага – самые важные шаги в процессе проектирования онтологии. Здесь мыопишем их вкратце, а затем в следующих двух главах рассмотрим более сложныепроблемы, которые необходимо принять во внимание, часто встречающиесятрудности, решения, которые нужно принять, и т.д.
/>Шаг 4. Определение классов ииерархии классов
Существует несколько возможных подходов для разработкииерархии классов:
Процесс нисходящей разработки начинается с определениясамых общих понятий предметной области с последующей конкретизацией понятий.Например, мы можем начать с создания классов для общих понятий Вино и Еда.Затем мы конкретизируем класс Вино, создавая его подклассы: Белое вино, Красноевино, Розовое вино. Мы можем еще дальше категоризировать класс Красное Вино,например, в Syrah, Red Burgundy, Cabernet Sauvignon и т.д.
Процесс восходящей разработки начинается с определениясамых конкретных классов, листьев иерархии, с последующей группировкой этихклассов в более общие понятия. Например, сначала мы определяем классы для вин Pauillac и Margaux.Затем мы создаем общий надкласс для двух этих классов – Medoc,который, в свою очередь является подклассом Bordeaux.
Процесс комбинированной разработки – это сочетаниенисходящего и восходящего подходов: Сначала мы определяем более заметныепонятия, а затем соответствующим образом обобщаем и ограничиваем их. Мы моглибы начать с нескольких понятий высшего уровня, таких как Вино, и несколькихконкретных понятий, таких как Margaux. Затем мы можем соотнести их с понятием среднегоуровня, таким как Medoc. После этого нам может понадобиться сформировать всеклассы вин из области Франции, формируя таким образом ряд понятий среднегоуровня.
На рис. 2 показано возможное деление на различныеуровни обобщения.
/>
Рис. 2. Различные уровни таксономии Вино: Вино,Красное вино, Белое вино, Розовое вино – более общие понятия, верхний уровень. Pauillac и Margaux – самые конкретные классы в иерархии, нижний уровень.
Ни один из этих трех методов не лучше других по своейсути. Выбор подхода в большой степени зависит от личного взгляда на предметнуюобласть. Если разработчик склонен к рассмотрению предметной области сверхувниз, то ему, возможно, больше подойдет нисходящий метод. Часто для многихразработчиков онтологий самым простым является комбинированный метод, т.к.понятия, находящиеся «посередине», имеют тенденцию быть самыми нагляднымипонятиями в предметной области.
Если вы склонны делать сначала самую общуюклассификацию вин, то вам больше подойдет нисходящий метод. Если вы бы началиприводить конкретные примеры, то более подходящим является восходящий метод.
Какой метод мы бы ни избрали, обычно мы начинаем сопределения классов. Из списка, составленного в Шаге 3, мы выбираем термины,которые описывают объекты, существующие независимо, а не термины, которыеописывают эти объекты. В онтологии эти термины будут классами и станут точкамипривязки в иерархии классов[2]. Мыорганизуем классы в иерархическую таксономию, задавая вопрос: если объектявляется экземпляром одного класса, будет ли он обязательно (т.е. поопределению) экземпляром некоторого другого класса?
Если класс А – надкласс класса В, то каждый экземплярВ также является экземпляром А.
Другими словами, класс В представляет собой понятие,которое является «разновидностью» А.
Например, каждое вино PinotNoir – обязательно красное вино. Поэтому класс Pinot Noir – подкласс класса Красное вино.
На рис. 2 показана часть иерархии классов онтологии повинам. В 4-й главе детально рассмотрено, что нужно искать при определениииерархии классов.
/>
Рис. 3. Слоты класса Вино и фацеты этих слотов. Значок“I” рядом со слотом производитель указывает, что у слотаесть обратный слот (Глава 5.1.).
Шаг 5. Определение свойств классов – слотов
Классы сами по себе не предоставляют достаточноинформации для ответа на вопросы проверки компетентности из Шага 1. Послеопределения некоторого количества классов мы должны описать внутреннююструктуру понятий.
Мы уже выбрали классы из списка терминов, который мысоздали на Шаге 3. Большинство оставшихся терминов, вероятно, будут свойствамиэтих классов. Эти термины включают, к примеру, цвет вина, его крепость, вкус исодержание сахара, а также местоположение винного завода.
Для каждого свойства из списка мы должны определить,какой класс оно описывает. Эти свойства станут слотами, привязанными к классам.Таким образом, у класса Вино будут следующие слоты: цвет, крепость, вкус исахар. А у класса Винный завод будет слот местоположение.
Вообще, в онтологии слотами могут стать несколькотипов свойств объектов:
«внутренние» свойства, такие как вкус вина;
«внешние» свойства, такие как название вина и область,в которой оно было произведено;
части, если объект имеет структуру; они могут быть какфизическими, так и абстрактными «частями» (например, блюда, входящие в обед);
отношения с другими индивидными концептами; это отношениямежду отдельными членами класса и другими элементами (например, производительвина, представляющий отношение между вином и винным заводом, и виноград, изкоторого произведено вино).
Таким образом, в дополнение к ранее определеннымсвойствам, к классу Вино нам нужно добавить следующие слоты: название, область,производитель, виноград. На рис. 3 показаны слоты класса Вино.
Все подклассы класса наследуют слот этого класса.Например, все слоты класса Вино будут унаследованы всеми подклассами этого класса,включая Красное Вино и Белое Вино. К классу Красное Вино мы добавимдополнительный слот уровеньтанина (низкий, средний или высокий). Слот уровень танина будет унаследованвсеми классами, представляющими красные вина (такие как Bordeaux и Beaujolais).
Слотдолжен быть привязан к самому общему классу, у которого может быть данноесвойство. Например, крепость и цвет вина нужно будет привязать к классу Вино,т.к. это самый общий класс, чьи экземпляры будут иметь крепость и цвет.
Шаг 6. Определение фацетов слотов
Слоты могут иметь различные фацеты, которые описываюттип значения, разрешенные значения, число значений (мощность) и другие свойствазначений, которые может принимать слот. Например, значение слота название (какв «название вина») – одна строка. То есть, название – это слот с типом значенияСтрока. Слот производит (как в выражении «винный завод производит эти вина»)может иметь множественные значения, которые являются экземплярами класса Вино.То есть, производит – это слот с типом значения Экземпляр, и разрешеннымклассом является Вино.
Сейчас мы опишем несколько общих фацетов.
Мощность слота
Мощность слота определяет, сколько значений можетиметь слот. В некоторых системах различаются только единичная мощность(возможно только одно значение) и множественная мощность (возможно любое числозначений). Крепость вина будет слотом единичной мощности (вино может иметьтолько одну крепость). Вина, производимые на конкретном заводе, заполняют слотмножественной мощности производит класса Винный завод.
Некоторые системы позволяют определить минимальную имаксимальную мощность для того, чтобы более точно описать количество значенийслота. Минимальная мощность N означает, что слот должен иметь не менее Nзначений. Например, слот виноград класса Вино имеет минимальную мощность 1:каждое вино делается, как минимум, из одного сорта винограда. Максимальнаямощность М означает, что слот может иметь максимум М значений. Максимальнаямощность слота виноград для вин из одного сорта винограда равняется 1. Иногдаполезно установить максимальную мощность в 0. Эта установка будет означать, чтодля определенного подкласса слот не может иметь значений.
Тип значения слота
Фацет типа значения описывает, какие типы значенийможно ввести в слот. Вот список наиболее общих типов значений:
Строка – самый простой тип значения, которыйиспользуется в таких слотах, как название: значением является простая строка.
Число (иногда используются более конкретные типызначений: Float (Число с плавающей запятой) и Integer(Целое число)) описывает слоты числовыми значениями. Например, стоимость винаможет иметь тип Float.
Булевы слоты – это простые флаги «да — нет». Например,если мы не будет представлять игристые вина как отдельный класс, топринадлежность к игристым винам может быть показана значением булевого слота:если значение «истина» («да»), то вино игристое, а если значение «ложь»(«нет»), то вино не игристое.
Нумерованные слоты определяют список конкретныхразрешенных значений слота. Например, мы можем установить, что слот вкус можетпринять одно из трех возможных значений: сильный,умеренный и мягкий. В Protege-2000 нумерованные слоты имеют тип Символ.
Слоты-экземпляры позволяют определить отношения междуиндивидными концептами. Слоты с типом значения Экземпляр также должныопределять список разрешенных классов, экземпляры которых можно использовать.Например, слот производит класса Винный завод в качестве значений может иметьэкземпляры класса Вино[3].
На рис. 4 показано определение слота производит классаВинный завод.
/>
Рис. 4. Определение слота производит, которыйописывает вина, производимые на винном заводе. Слот имеет множественнуюмощность и значение типа Экземпляр.
Разрешенным классом для значений этого слота являетсякласс Вино.
Домен слота и диапазон значений слота
Разрешенные классы для слотов типа Экземпляр частоназывают диапазоном значений слота. В примере на рис. 4 класс Вино являетсядиапазоном значений слота производит. Некоторые системы позволяют ограничитьдиапазон значений слота, если слот привязан к определенному классу.
Классы, к которым слот привязан, или классы, свойствокоторых слот описывает, называются доменом слота. Класс Винный завод – доменслота производит. В системах, где мы привязываем слоты к классам, домен слотаобычно составляют классы, к которым привязан слот. Нет необходимости отдельноопределять домен.
Основные правила определения домена слота и диапазоназначений слота схожи друг с другом:
При определении домена или диапазона значений слотанайдите наиболее общие классы или класс, которые могут быть соответственнодоменом или диапазоном значений слотов.
С другой стороны, не определяйте слишком общий домен идиапазон значений: все классы в домене слота должны быть описаны слотом, аэкземпляры всех классов в диапазоне значений слота должны являтьсяпотенциальными заполнителями слота. Не выбирайте слишкомобщий класс для диапазона значений (то есть, вы не захотите делать THING диапазоном значений, а захотите выбратькласс, который охватит все заполнители.)
Вместо того чтобы перечислить все возможные подклассыкласса Вино для диапазона значений слота производит, просто внесите в списоккласс Вино. В то же время, нам не нужно определять диапазон значений слота как THING(самый общий класс в онтологии).
Конкретнее:
Если список классов, определяющих диапазон значенийслота или домен слота, включает класс и его подкласс, удалите подкласс.
Если диапазон значений слота содержит и класс Вино, икласс Красное Вино, мы можем удалить Красное Вино из диапазона значений, т.к.он не добавляет новую информацию: Красное Вино – это подкласс класса Вино, ипоэтому диапазон значений слота уже неявно включает его, также как и все другиеподклассы класса Вино.
Если список классов, определяющих диапазон значенийслота или домен слота, включает все подклассы класса А, но не включает самкласс А, то в диапазон значений должен входить только класс А, а не егоподклассы.
Вместо указания того, что диапазон значений слотавключает Красное Вино, Белое Вино и Розовое Вино (перечисление всех прямыхподклассов класса Вино), мы можем ограничить диапазон значений самим классомВино.
Если список классов, определяющих диапазон значенийслота или домен слота, включает почти все подклассы класса А, подумайте, может,для определения диапазона значений лучше подойдет класс А.
В системах, где привязка слота к классу равнозначнадобавлению класса к домену слота, к привязке слота применяются те же правила: Содной стороны, нам нужно постараться сделать его как можно более общим. Сдругой стороны, мы должны гарантировать, что каждый класс, к которому мыпривязываем слот, на самом деле имеет свойство, которое представляет слот. Мыможем привязать слот уровеньтанина к каждому классу, представляющему красные вина (например, Bordeaux, Merlot, Beaujolais ит.д.). Однако, т.к. все красные вина имеют свойство «уровеньтанина», то вместо этого нам нужно прикрепить этот слот к более общему классуКрасные Вина. Будет неправильно дальше обобщать домен слота уровень танина (привязка его кклассу Вино), т.к. мы не используем уровень танина для описания, к примеру,белых вин.
Шаг 7. Создание экземпляров
Последний шаг – это создание отдельных экземпляровклассов в иерархии. Для определения отдельного экземпляра класса требуется (1)выбрать класс, (2) создать отдельный экземпляр этого класса и (3) ввестизначения слотов. Например, мы можем создать отдельный экземпляр Chateau-Morgon-Beaujolais для представления определенного типа вина Beaujolais. Chateau-Morgon-Beaujolais – это экземпляр класса Beaujolais, представляющего все вина Beaujolais. Уэтого экземпляра определены следующие значения слотов (рис. 5):
Крепость: Легкое
Цвет: Красный
Вкус: Мягкий
Уровень танина: Низкий
Виноград: Gamay (экземпляр класса Винограддля изготовления вин)
Производитель: Chateau-Morgon(экземпляр класса Винный завод)
Область: Beaujolais (экземпляр классаВинная область)
Сахар: Сухое
/>
Рис. 5. Определение экземпляра класса Beaujolais. Экземпляром является вино Chateua Morgon Beaujolais из области Beaujolais, произведенное извинограда Gamay на заводе Chateau Morgon.Оно легкое, с мягким вкусом, красное, с низким уровень танина. Это сухое вино.
4. Определение классов и иерархии классов
В этой главе говорится о том, за чем нужно следить,и об ошибках, которые легко сделать при определении классов и иерархии классов(Шаг 4 из Главы 3). Как мы уже говорили ранее, для любой предметной области несуществует единственной правильной иерархии классов. Иерархия зависит отвозможных способов применения онтологии, уровня детализации, необходимого дляприложения, личных предпочтений и иногда от требований по совместимости сдругими моделями. Тем не менее, мы рассматриваем несколько руководящихпринципов, которые нужно учитывать при разработке иерархии классов. Послеопределения значительного количества новых классов полезно остановиться ипроверить, соответствует ли возникающая иерархия этим руководящим принципам.
4.1. Обеспечение правильности иерархии классов
Отношение “is-a”[2]
Иерархия классов представляет отношение “is-a”:класс А – это подкласс В, если каждый экземпляр В также является экземпляром А.Например, Chardonnay – подкласс класса Белое Вино. Другой способ подхода ктаксономическому отношению – это отношение “kind-of”[3]: Chardonnay–вид Белого вина. Реактивный лайнер –вид самолета. Мясо –вид еды.
Подкласс класса представляет понятие, которое является«разновидностью» понятия, представляемого надклассом.
Отдельно взятое вино не является подклассом всех вин
Распространенная ошибка при моделировании – этовключение в иерархию варианта одного и того же понятия как в единственном, таки во множественном числе, сделав первое подклассом второго. Например, будетнеправильно определить класс Вина и класс Вино как подкласс класса Вина. Кактолько вы начинаете считать, что иерархия представляет собой отношение “kind-of”,то ошибка при моделировании становится очевидной: отдельное Вино не являетсявидом Вин. Лучший способ избежать таких ошибок – всегда использовать именаклассов или в единственном, или во множественном числе (присваивание именпонятиям подробно рассмотрено в Главе 6).
Транзитивность иерархических отношений
Отношение подкласса транзитивно:
Если В – это подкласс А, а С – подкласс В, то С –подкласс А.
Например, мы можем определить класс Вино, а потомопределить класс Белое вино как подкласс класса Вино. Затем мы определяем классChardonnay как подкласскласса Белое Вино. Транзитивность отношенияподкласса означает, что класс Chardonnayтакже является подклассом класса Вино. Иногда мы различаем прямые и косвенныеподклассы. Прямой подкласс – самый близкий подкласс класса: в иерархии междуклассом и его прямым подклассом нет других классов. То есть, между классом иего прямым надклассом в иерархии нет других классов. В нашем примере Chardonnay– это прямой подкласс класса Белое вино и не прямой подкласс класса Вино.
Развитие иерархии классов
Поддержание последовательной иерархии классов можетвызывать сложности по мере того, как развиваются предметные области. Например,много лет все вина Zinfandel были красными. Поэтому мы определяем класс вин Zinfandel как подкласс класса Красное вино. Тем не менее, производители вининогда начали выжимать виноград и сразу удалять цветообразующие вещества извинограда, изменяя таким образом цвет получаемого вина. Так мы получаем «белое Zinfandel» розового цвета. Теперь нам нужно разбить класс Zinfandel на 2 класса zinfandel – Белое zinfandel и Красное zinfandel – и классифицировать их как подклассы классов Розовое вино и Красноевино соответственно.
Классы и их имена
Важно различать класс и его имя:
Классы представляют понятия предметной области, а неслова, которые обозначают эти понятия.
Имя класса может измениться, если мы выберем другуютерминологию, но сам термин представляет объективную реальность мира. Например,мы можем создать класс Shrimps,а потом переименовать его в Prawns– класс представляет все то же понятие. Вина, которые подходили к блюдам из shrimp, должныподходить к блюдам из prawn[4].
В действительности нужно все время соблюдать правило:
Синонимы одного и того же понятия не представляютразличные классы.
Синонимы – всего лишь разные имена понятия илитермина. Следовательно, у нас не должно быть класса с именем Shrimpи одновременно с этим класса сименем Prawn, а также класса с именем Crevette[5].Предпочтительнее будет иметь один класс с именем Shrimp или Prawn.Многие системы позволяютассоциировать с классом список синонимов, переводов или имен представления.Если система не позволяет осуществлять такие ассоциации, то синонимы всегдаможно перечислить в документации к классу.
Избежание циклов классов
Нам следует избегать циклов в иерархии классов. Мыговорим, что в иерархии есть цикл, когда у некоторого класса А есть подкласс Ви в то же время В – это надкласс А. Создание такого цикла в иерархииравнозначен объявлению того, что классы А и В эквивалентны: все экземпляры А –это экземпляры В, а все экземпляры В также являются экземплярами А.Действительно, поскольку В – подкласс А, то все экземпляры В должны бытьэкземплярами класса А. Поскольку А – подкласс В, то все экземпляры А такжедолжны быть экземплярами класса В.
4.2. Анализ узлов-братьев в иерархии классов
Узлы-братья в иерархии классов
Узлы-братья в иерархии — это классы, которые являютсяпрямыми подклассами одного и того же класса (см. Раздел 4.1).
Все узлы-братья в иерархии (кроме тех, что находятся вкорне) должны располагаться на одном уровне обобщения.
Например, Белое вино и Chardonnayне должны быть подклассами одного и того же класса (скажем, класса Вино). Белоевино – более общее понятие, чем Chardonnay.Узлы-братья должны представлять понятия, которые находятся «на одной линии»,так же как разделы одного уровня в книге должны находиться на одном уровнеобобщения. В этом смысле требования к иерархии классов похожи на требования кструктуре книги.
Однакопонятия, которые находятся в корне иерархии (и которые всегда представлены какпрямые подклассы некоторого самого общего класса, такого как Thing),представляют основные деления в предметной области и не должны быть схожимипонятиями.
Что называть «слишком много», а что — «слишком мало»?
Не существует жестких правил относительно того,сколько прямых подклассов должен иметь класс. Тем не менее, во многих онтологияхс четкой структурой имеется от двух до дюжины прямых подклассов. Отсюда дваруководящих принципа:
Если класс имеет только один прямой подкласс, то,возможно, при моделировании допущена ошибка или онтология неполная.
Если у данного класса есть более дюжины подклассов,то, возможно, необходимы дополнительные промежуточные категории.
Первое правило похоже на правило набора текста,которое гласит, что у маркированного текста никогда не должна быть лишь однамаркированная точка. Например, большинство красных бургундских вин – это вина Cфtes d’Or. Предположим, что мы хотели представить только этотосновной тип бургундских вин. Мы могли создать класс RedBurgundy и затемединственный подкласс Cotesd’Or(рис. 6а). Тем не менее, если в нашем представлении красные бургундские вина ивина Cфtes d’Or, по существу, эквивалентны (все красные бургундские винаявляются винами Cфtes d’Or и все вина Cфtes d’Or – это красныебургундские вина), то нет необходимости создавать класс Cotesd’Or,и он не добавит в представление новую информацию. Если бы нам нужно быловключить вина Cфtes Chalonnaise (более дешевыебургундские вина из области к югу от Cфtes d’Or),то мы бы создали два подкласса класса Burgundy:Cotes d’Or и CotesChalonnaise(рис. 6б).
/>
Рис. 6. Подклассы класса RedBurgundy.
Наличиеу класса только одного подкласса указывает на ошибку при моделировании.
Теперьпредположим, что мы перечислили все вина как прямые подклассы класса Вино.Тогда этот список будет включать такие более общие сорта, как Beaujolais и Bordeaux, так же как иболее конкретные вина, как Paulliac и Margaux(рис. 7а). У класса Вино слишком много прямых подклассов и, действительно, длятого чтобы онтология отражала различные сорта вин более четко, Medocдолжно быть подклассом Bordeaux,а Cotes d’Orдолжно быть подклассом Burgundy.Кроме того, наличие таких промежуточных категорий как Красное вино и Белое Винотакже будет отражать ту понятийную модель предметной области вин, которая естьу многих людей (рис. 7б).
Темне менее, если не существует естественных классов для группировки понятий вдлинный список узлов-братьев, то не нужно создавать искусственные классы –оставьте все, как есть. В конце концов, онтология – это отражение реальногомира, и если в действительности категоризации нет, то онтология должна этоотражать.
/>
Рис. 7. Категоризация вин. Простое перечисление всехвин против нескольких уровней категоризации.
4.3. Множественное наследование.
Большинство систем представления знаний позволяютосуществлять множественное наследование в иерархии классов: класс может бытьподклассом нескольких классов. Предположим, что мы хотим создать отдельныйкласс десертных вин — класс Десертное вино. Вино Port является икрасным, и десертным вином [4].Следовательно, мы определяем, что у класса Port есть 2надкласса: Красное вино и Десертное вино. Все экземпляры класса Portбудут экземплярами как класса Красное вино, так и класса Десертное вино. Класс Portунаследует слоты и фацеты от обоих родителей. Таким образом, он унаследуетзначение СЛАДКОЕ из слота Сахар класса Десертное вино, а также слот уровень танина изначение слота цвета класса Красное вино.
4.4. Когда вводить (или не вводить) новый класс
Одно из самых сложных решений, которое нужно принятьво время моделирования, — это определить, когда ввести новый класс или когдасформулировать различие с помощью разных значений свойств. Сложноориентироваться как в иерархии с очень большой степенью вложенности имножеством посторонних классов, так и в очень плоской иерархии, где очень малоклассов, но в их слотах закодировано слишком много информации. Найти подходящийбаланс нелегко.
Существует несколько практических способов определениятого, когда в иерархию следует ввести новые классы:
Обычно подклассы класса (1) имеют дополнительныесвойства, которых нет у надкласса, или (2) ограничения, отличные от тех,которые есть у надкласса, или (3) состоят в других отношениях, нежелинадклассы.
У красных вин разные уровни танина, тогда как этосвойство не используется для описания вин в общем. Слот сахар класса Десертноевино имеет значение СЛАДКОЕ, тогда как для надкласса класса Десертное вино этоне так. Вина Pinot Noir могут хорошо сочетаться сморскими продуктами, тогда как другие красные вина – нет. Другими словами, мыобычно вводим в иерархию новый класс только тогда, когда мы можем сказать проэтот класс что-то такое, чего мы не можем сказать о надклассе.
На практике к каждому подклассу нужно добавить новыеслоты или определить у него новые значения слотов и переопределить некоторыефацеты наследованных слотов.
Однако иногда может быть полезно создать новые классы,даже если они не вводят никаких новых свойств.
Классы в иерархиях терминов не обязаны новые свойства.
Например, некоторые онтологии включают большиеиерархии ссылок обычных терминов, используемых в предметной области. К примеру,онтология, которая лежит в основе электронной системы записи медицинскойинформации, может включать классификацию различных болезней. Эта классификацияможет быть как раз такой — иерархией терминов, без свойств (или с одним и темже набором свойств). В этом случае по-прежнему полезно организовать термины виерархию, а не в линейный список, потому что она (1) облегчит изучение инавигацию и (2) позволит врачу легко выбрать подходящий уровень общноститермина.
Другая причина введения новых классов без новыхсвойств – это моделирование понятий, среди которых эксперты в предметнойобласти обычно проводят разграничение, даже несмотря на то, что мы моглипринять решение не моделировать само разграничение. Так как мы используемонтологии для содействия коммуникации между экспертами в предметной области, атакже между экспертами и системами, основанными на знаниях, то в онтологии мыбы хотели отразить точку зрения эксперта на предметную область.
В конце концов, нам не следует создавать подклассыкласса для каждого дополнительного ограничения. К примеру, мы ввели классыКрасное вино, Белое вино и Розовое вино, так как это разделение являетсяестественным в мире вин. Мы не ввели классы для изысканного вина, для вин сумеренным вкусом и т.д. Когда мы определяем иерархию классов, наша цель –добиться равновесия между созданием классов, которые полезны для организацииклассов, и созданием слишком большого числа классов.
4.5. Новый класс или значение свойства?
При моделировании предметной области нам часто нужнорешать, моделировать ли определенное разграничение (такое как белое, красноеили розовое вино) как значение свойства или как набор классов, что опять жезависит от масштаба предметной области и от решаемой задачи.
Создать ли нам класс Белое вино или просто создатькласс Вино и ввести различные значения слота цвет? Ответ всегда зависит от тогомасштаба, который мы определили для онтологии. Насколько важно понятие Белоевино в нашей предметной области? Если важность вин в предметной областинезначительна и то, белое это вино или нет, не особо влияет на его отношения сдругими объектами, то нам не нужно вводить отдельный класс белых вин. Длямодели предметной области, используемой на предприятии, где производятся винныеэтикетки, правила для этикеток вин различных цветов одни и те же и разделениене столь важно. И наоборот, для представления вина, еды и их подходящихсочетаний, красное вино сильно отличается от белого: оно сочетается с другойедой, у него другие свойства и т.д. Также, цвет вина важен для базы знаний повинам, которую мы можем использовать для определения последовательностидегустации вин. Поэтому мы создаем отдельный класс Белое вино.
Если понятия с разными значениями слота становятсяограничениями для различных слотов в других классах, то для разделения намследует создать новый класс. В противном случае разделениепредставляется в значении слота.
Подобным образом, в нашей онтологии вин есть такиеклассы как КрасноеMerlot и Белое Merlot,а не единый класс для всех вин Merlot:красные Merlot и белые Merlot– это действительно разные вина (сделанные из одного винограда), и если мыразрабатываем подробную онтологию, то это разделение представляет важность.
Если в предметной области разграничение представляетважность и объекты с другими значениями разграничения мы считаем другими типамиобъектов, то для осуществления разграничения нам нужно создать новый класс.
При принятии решения о том, вводить новый класс илинет, также может быть полезно рассмотреть потенциальные отдельные экземплярыкласса.
Класс, к которому принадлежит отдельный экземпляр, недолжен часто меняться.
Обычно, когда для определения различий между классамимы используем внешние, а не внутренние свойства понятий, экземпляры этихклассов должны часто будут перемещаться из одного класса в другой. Например,Охлажденное вино не должно являться классом в онтологии, описывающей бутылкивин в ресторане. Свойство охлажденное должно быть просто атрибутом вина вбутылке, так как экземпляр класса Охлажденное вино может легко перестать бытьэкземпляром этого класса, а затем снова стать его экземпляром.
Обычно числа, цвета, местоположения являютсязначениями слотов и не приводят к созданию новых классов. Тем не менее, вино –особое исключение, так как цвет вина имеет первостепенную важность для егоописания.
В качестве другого примера рассмотрим онтологиючеловеческой анатомии. Когда мы представляем ребра, создаем ли мы класс для«1-го левого ребра», потом класс для «2-го левого ребра» и т.д.? Или у нас естькласс Ребро со слотами для последовательности и стороны (левое — правое)?[5] Если информация о каждом из ребер,которые мы представляем в онтологии, существенно отличается, то нам,действительно, нужно создать класс для каждого ребра. То есть, если мы хотимподробно представить информацию о смежности и положении (которые различны длявсех ребер), а также особые функции, которые выполняет каждое ребро, и какиеорганы оно защищает, то нам нужно создать классы. Если мы моделируем анатомиюна чуть более низком уровне обобщения и для наших потенциальных приложений всеребра очень похожи (мы говорим всего лишь о том, какое ребро сломано, судя порентгеновскому снимку, безотносительно к другим частям тела), то нампотребуется упростить иерархию и оставить только класс Ребро с двумя слотами:сторона и порядковый номер.
4. 6. Экземпляр или класс?
Определение того, чем является определенное понятие — классом в онтологии или отдельным экземпляром — зависит от потенциальныхприложений онтологии. Определение того, где заканчиваются классы и начинаютсяотдельные экземпляры, начинается с определения нужной глубины детализации впредставлении. Глубина детализации, в свою очередь, определяется потенциальнымприложением онтологии. Другими словами, какие самые конкретные элементы будутпредставлены в базе знаний? Если возвратиться к вопросам для проверкикомпетентности, которые мы определили в Шаге 1 Главы 3, самые конкретные понятия,которые будут ответами на эти вопросы, лучше всего подойдут на роль индивидныхконцептов в базе знаний.
Отдельные экземпляры — самые конкретные понятия,представленные в базе знаний.
Например, если мы собираемся говорить только о подборесочетаний вина и еды, то нас не будут интересовать конкретные материальныебутылки вина. Поэтому такие термины как SterlingVineyards Merlot,вероятно, будут самыми конкретными используемыми нами терминами. Следовательно,Sterling VineyardsMerlot будетэкземпляром в базе знаний.
Сдругой стороны, если бы мы хотели поддерживать в ресторане ассортимент вин вдополнение к базе знаний хороших сочетаний «вино-еда», то отдельнымиэкземплярами в нашей базе знаний могли бы стать отдельные бутылки каждого вина.
Аналогично,если бы мы хотели записать различные качества для каждого конкретного урожая SterlingVineyards Merlot,то экземпляром в базе знаний стал бы конкретный урожай вина, а SterlingVineyards Merlotстал бы классом, содержащим экземпляры всех его урожаев.
Другоеправило может «переместить» некоторые отдельные экземпляры в разряд классов:
Еслипонятия формируют естественную иерархию, то нам нужно представить их, какклассы.
Рассмотримвинные области. В начале мы можем определить основные винные регионы, такие какФранция, США, Германия и т.д. как классы, а конкретные винные области внутриэтих регионов как экземпляры. Например, область Bourgogne– это экземпляр класса регион Франция. Однако мы бы также хотели отметить, чтообласть Cotes d’Or– это область Bourgogne.Поэтому область Bourgogneдолжна быть классом (чтобы иметь подклассы или экземпляры). Однакопредставление области Bourgogneкак класса, а области Cotesd’Orкак экземпляра области Bourgogneкажется произвольным: очень сложно четко разграничить, какие области являютсяклассами, а какие – экземплярами. Поэтому мы определяем все винные области какклассы. Protege-2000 дает возможность пользователю определитьнекоторые классы как Абстрактные, показывая, что у класса не может быть прямыхэкземпляров. В нашем случае, все классы областей являются абстрактными (рис.8).
/>
Рис. 8. Иерархия винных областей. Иконка «А» рядом сименами классов указывает на то, что это абстрактные классы и у них не можетбыть прямых экземпляров.
Так же иерархия классов была бы неправильной, если бымы пропустили в имени класса слово «область». Мы не можем сказать, что класс Alsace– это подкласс класса Франция: Alsace– это не разновидность Франции. Тем не менее, область Alsace– разновидность региона Франция.
В виде иерархии можно представить только классы – всистемах представления знаний нет категории «подэкземпляр». Поэтому, если средитерминов существует естественная иерархия, такая как в иерархиях терминов вРазделе 4.2, то нам нужно охарактеризовать эти термины как классы, даже еслиони могут и не иметь своих экземпляров.
4.7. Ограничение масштаба
В качестве последнего замечания по составлениюиерархии классов, следующий набор правил всегда поможет при ответе на вопрос,закончено ли определение онтологии:
Онтология не должна содержать всю возможную информациюо предметной области: вам не нужно конкретизировать или обобщать больше, чемвам нужно для вашего приложения (не более 1 дополнительного уровня в каждуюсторону).
Для нашего примера с вином и едой нам не требуетсязнать, из какой бумаги делаются этикетки, или как готовятся блюда из креветок.
Также онтология не должна содержать все возможныесвойства классов и различия между классами в иерархии.
В нашу онтологию мы, естественно, не включаем всесвойства, которые могли бы иметь вино или еда. В нашей онтологии мы представилисамые значимые свойства классов элементов. Даже несмотря на то, что в книгах повинам можно узнать о размере виноградин, мы не включили эту информацию. Так же,в нашу систему мы не включили все возможные отношения между всеми терминами. Кпримеру, мы не включаем в онтологию такие отношения, как любимое вино илилюбимая еда, просто для того, чтобы сделать более полное представление обо всехвзаимосвязях между определенными нами терминами более полным.
Последние правила также применимы для установленияотношений между понятиями, которые мы уже включили в онтологию. Рассмотримонтологию, описывающую биологические эксперименты. Эта онтология, вероятно,будет содержать понятие Биологические организмы. Она также будет содержатьпонятие Экспериментатор (включающее имя, место работы и т.д.), который проводитэксперимент. Верно то, что экспериментатор как человек также являетсябиологическим организмом. Тем не менее, мы, наверное, не должны отражать этуособенность в онтологии: в целях этого представления экспериментатор неявляется биологическим организмом, и мы, наверное, никогда не будем проводитьэксперименты на самих экспериментаторах. Если бы в онтологии мы делалипредставление всего того, что мы можем сказать о классах, то Экспериментатор быстал подклассом класса Биологический организм. Однако нет необходимостивключать это знание для возможных приложений. Фактически, включение этой дополнительнойклассификации существующих классов действительно мешает: теперь у экземпляраЭкспериментатора будут слоты для веса, возраста, вида и других данных, которыеотносятся к биологическому организму, но совершенно неуместны в контекстеописания эксперимента. Тем не менее, для пользователей, которые будут иметьдело с этой онтологией и которые могут не знать о задуманном нами приложении,нам нужно отразить это проектное решение в документации.
4.8. Дизъюнктивные подклассы
Многие системы позволяют нам явным образом задать, чтонесколько классов являются дизъюнктивными. Классы дизъюнктивные, если у них неможет быть общих экземпляров. Например, в нашей онтологии классы Десертное винои Белое вино не являются дизъюнктивными: существует множество вин, являющихэкземплярами обоих классов. Одним из таких примеров является RothermelTrochenbierenausleseRiesling, экземпляркласса Сладкое Riesling.В то же время, классы Красное вино и Белое вино дизъюнктивны: ни одно вино не может быть одновременнои белым, и красным. Определение классов как дизъюнктивных позволяет системелучше проверять правильность онтологии. Если мы объявим классы Красное вино иБелое вино дизъюнктивными и затем создадим класс, который будетподклассом и Riesling (подкласс Белого вина) и Port(подкласс Красного вина), тосистема может показать, что имеется ошибка в моделировании.
5. Определение свойств – боле подробно
В этой главе мы затронем еще несколько деталей,которые нужно иметь при определении слотов в онтологии (Шаги 5 и 6 в Главе 3).В основном, мы обсуждаем обратные слоты и значения слота по умолчанию.
5.1. Обратные слоты
Значение слота может зависеть от значения другогослота. Например, если вино было произведено на винном заводе, то винный заводпроизводит это вино. Эти два отношения, производитель и производит, называютсяобратными отношениями. Излишне хранить информацию и о том, и о другом. Когда мызнаем, что вино производится на винном заводе, то приложение, котороеиспользует базу знаний, всегда может вывести значение для обратного отношения:винный завод производит вино. Тем не менее, с точки зрения приобретения знанийудобно иметь оба блока информации доступными в явном виде. Этот подходпозволяет пользователям указать вино в одном случае и винный завод в другом.После это система приобретения знаний может автоматически заполнить значениедля обратного отношения, обеспечивая согласованность базы знаний.
В нашем примере есть пара обратных слотов: слотпроизводитель класса Вино и слот производит класса Винный завод. Когда пользовательсоздает экземпляр класса Вино и заполняет значение слота производитель, системаавтоматически добавляет вновь созданный экземпляр к слоту производитсоответствующего экземпляра класса Винный завод. Например, когда мы говорим,что Sterling Merlot производится на заводе Sterling Vineyard, система автоматически добавляет Sterling Merlot к списку вин, которые производит завод Sterling Vineyard (рис. 9).
/>
Рис. 9. Экземпляры с обратными слотами. Слотпроизводит класса Винный завод является обратным для слота производитель классаВино. Заполнение одного из слотов приводит к автоматическому обновлениюдругого.
5.2. Значения по умолчанию
Многие фреймовые системы позволяют определить дляслотов значения по умолчанию. Если значение определенного слота одинаково длябольшинства экземпляров класса, то мы можем определить это значение какзначение слота по умолчанию. Затем, когда создается каждый экземпляр класса,имеющего этот слот, система автоматически заполняет значение по умолчанию.После этого мы можем изменить это значение на любое другое, которое позволятфацеты. То есть, значения по умолчанию созданы для удобства: в любом случае онине накладывают какие-либо ограничения на модель или никак ее не меняют.
Например, если большинство вин, о которых мысобираемся говорить, являются крепкими, то значение крепости вина мы можемсделать «крепкое» по умолчанию. Тогда все вина, которые мы определяем, будуткрепкими, если мы не укажем иное.
Обратите внимание, что это отличается от значенийслота. Значения слота не могут быть изменены. Например, мы можем сказать, чтослот сахар класса Десертное вино имеет значение «СЛАДКОЕ». Тогда у всехподклассов и экземпляров класса Десертное вино значение слота сахар будет«СЛАДКОЕ». Для всех подклассов или экземпляров этого класса это значениеизменить нельзя.
6. Об именах
Определение единых правил присваивания имен понятиям вонтологии, а затем строгое соблюдение этих правил не только делает онтологиюболее простой для понимания, но также помогает избежать некоторых общих ошибокпри моделировании. Существует много вариантов присваивания имен понятиям.Обычно нет особой причины для выбора того или иного варианта. Тем не менее, намнужно
Определить единые правила присваивания имен классам ислотам и придерживаться их.
На выбор правил присваивания имен влияют следующиеособенности системы представления знаний:
Имеет ли система одно и то же пространство именклассов, слотов и экземпляров? То есть, позволяет ли система иметь класс и слотс одинаковым именем (как, например, класс винный завод и слот винный завод)?
Различает ли система регистр букв? То есть, считает лисистема разными имена, которые отличаются только регистром (как Винный завод ивинный завод)?
Какие разделители в именах позволяет использоватьданная система? То есть, могут ли имена содержать пробелы, запятые, звездочки ит.д.?
К примеру, Protеgе-2000 имеетединое пространство имен для всех своих фреймов. Она различает регистр букв.Таким образом, у нас не может быть класса винный завод и слота винный завод.Однако у нас может быть класс Винный завод (не прописные буквы) и слот винныйзавод. С другой стороны, CLASSIC не различает регистр букв и имеет разные пространстваимен для классов, слотов и индивидных концептов. Таким образом, с точки зрениясистемы, мы можем с легкостью присвоить имя Винный завод и классу, и слоту.
6.1. Заглавные буквы и разделители
Во-первых, мы можем значительно улучшить читаемостьонтологии, если мы все время будем писать названия понятий с большой буквы.Например, общепринято начинать имена классов с большой буквы, а имена слотов –с маленькой (предполагая, что система различает регистр букв).
Когда имя понятия содержит больше одного слова (как в Винный завод),нам нужно разделить слова. Вот возможные варианты:
Использоватьпробел: Винный завод (многие системы,включая Protеgе, позволяют использовать пробелы в именах понятий).
Соединить слова вместе и каждое слово написать сбольшой буквы: ВинныйЗавод.
Использоватьв имени подчеркивание или тире, или другой разделитель: Винный_Завод, Винный_завод,Винный-Завод,Винный-завод(если вы используете разделитель, вам также нужно решить, писать каждое слово сбольшой буквы или нет).
Если система представления знаний позволяетиспользовать пробелы в именах, то для многих разработчиков онтологий пробелымогут быть самым естественным решением. Однако важно учитывать другие системы,с которыми может взаимодействовать ваша система. Если в этих системах неиспользуются пробелы или ваше средство представления не очень хорошообрабатывает пробелы, то может быть лучше использовать другой метод.
6.2. Единственное или множественное число
Имя класса представляет набор объектов. Например,класс Вино в действительности представляет все вина. Поэтому для многихразработчиков было бы естественнее дать классу имя Вина, а не Вино. Ни один извариантов не лучше и не хуже другого (хотя на практике для имен классов чащеиспользуется единственное число). Тем не менее, каким бы ни был выбор, его следуетпридерживаться на протяжении всей онтологии. Некоторые системы даже требуют отсвоих пользователей заранее объявить, какое число (единственное илимножественное) они будут использовать в именах классов, и не дают имотклоняться от своего выбора.
Использование все время одной и той же формы такжепредотвращает такие ошибки разработчика при моделировании, как создание классаВина, а затем создание класса Вино как его подкласса (см. Раздел 4.1).
6.3. Договоренность в отношениииспользования префиксов и суффиксов
Некоторые методологии по базам знанийсоветуют придерживаться договоренности в отношении использования префиксов исуффиксов в именах для того, чтобы различать классы и слоты. Существует двераспространенных традиции: добавлять к именам слотов has-[6] или предлог –of[7]. Таким образом, наши слоты меняются на его-производитель и его-винный_завод, если мы выберемиспользование его-.Слоты меняютсяна maker-of и winery-of[8], если мы выберем использование of-. Этот подход позволяет любому, ктопосмотрит на термин, сразу же определить, что это: класс или слот. Однако именатерминов становятся немного длиннее.
6.4. Другие соображения по присваиванию имен
Еще несколько моментов, которые нужно иметь в виду приопределении правил присваивания имен:
Не добавляйте к именам понятий такие строки как«класс», «свойство», «слот» и т.д.
Из контекста всегда ясно, что это, к примеру, классили слот. В дополнение к тому, что для классов и слотов вы используете разныеправила присваивания имен (скажем, пишете их с большой и с маленькой буквысоответственно), само имя будет показывать, чем является это понятие.
Обычно лучше не сокращать имена понятий (то есть,используйте Cabernet Sauvignon, а не Cab).
Имя надкласса должно входить или во все имена прямыхподклассов, или ни в одно из них. Например, если мы создаем два подклассакласса Вино для представления красных и белых вин, то подклассы должныназываться или Красное Вино и Белое Вино, или Красное и Белое, но не КрасноеВино и Белое.
7. Другие ресурсы
В наших примерах в качестве среды разработки онтологиймы использовали Protege-2000. Duineveld с коллегами описывает и сравнивает ряд других среддля разработки онтологий.
Мы постарались рассказать о самом основном оразработке онтологий и не коснулись многих углубленных тем или альтернативныхметодологий разработки онтологий. Gуmez-Pйrez и Uschold представляют альтернативные методологии разработкионтологий. В руководстве по Ontolingua говорится о некоторых формальных аспектахмоделирования знаний.
В настоящее время исследователи придают особоезначение не только разработке онтологий, но также и анализу онтологий. Чембольше онтологий будет создаваться и повторно использоваться, тем больше будетинструментальных средств для анализа онтологий. К примеру, Chimaera предоставляет диагностические инструментальные средства для анализа онтологий.Анализ, который осуществляет Chimaera, включает как проверку логической верности онтологии,так и диагностику типичных ошибок при проектировании онтологий. Разработчиконтологий может провести диагностику разрабатываемой онтологии с помощью Chimaera,чтобы определить соответствие общим способам моделирования онтологий.
8. Заключение
В этом руководстве мы описали методологию разработкионтологии для декларативных фреймовых систем. Мы перечислили шаги приразработке онтологии и затронули сложные вопросы определения иерархий классов исвойств классов и экземпляров. Тем не менее, помимо всех правил и советов,следует помнить одну из важнейших вещей: для любой предметной области несуществует единственно правильной онтологии. Проектирование онтологии – этотворческий процесс и две онтологии, разработанные разными людьми, никогда небудут одинаковыми. Потенциальные приложения онтологии, а также пониманиеразработчиком предметной области и его точка зрения на нее будут, несомненно,влиять на принятие решений при проектировании онтологии. “Цыплят по осенисчитают” – мы можем оценить качество нашей онтологии, только используя ее вприложениях, для которых мы ее разработали.
Список литературы
Booch, G., Rumbaugh, J. and Jacobson, I.(1997).The Unified Modeling Language userguide: Addison-Wesley.
Brachman, R.J., McGuinness, D.L.,Patel-Schneider, P.F.,Resnick, L.A. and Borgida, A. (1991). Living withCLASSIC: When and how to useKL-ONE-like language.Principles ofSemanticNetworks. J. F. Sowa, editor, Morgan Kaufmann:401-456.
Brickley, D. and Guha, R.V. (1999).Resource DescriptionFramework (RDF) Schema Specification. ProposedRecommendation, World Wide WebConsortium:http://www.w3.org/TR/PR-rdf-schema.
Chimaera (2000). Chimaera OntologyEnvironment.www.ksl.stanford.edu/software/chimaera
Duineveld, A.J., Stoter, R., Weiden, M.R.,Kenepa, B. andBenjamins, V.R. (2000). WonderTools? A comparative study ofontologicalengineering tools.International Journalof Human-ComputerStudies52(6):1111-1133.
Farquhar, A. (1997). Ontolinguatutorial.http://ksl-web.stanford.edu/people/axf/tutorial.pdf
Gуmez-Pйrez, A. (1998). Knowledge sharingand reuse.Handbook of Applied Expert Systems.Liebowitz, editor, CRC Press.
Gruber, T.R. (1993). A Translation Approachto PortableOntology Specification.KnowledgeAcquisition5: 199-220.
Gruninger, M. and Fox, M.S. (1995).Methodology for theDesign and Evaluation of Ontologies. In:Proceedings of theWorkshop on BasicOntological Issues in Knowledge Sharing, IJCAI-95, Montreal.
Hendler, J. and McGuinness, D.L. (2000).The DARPA AgentMarkup Language.IEEE IntelligentSystems16(6): 67-73.
Humphreys, B.L. and Lindberg, D.A.B.(1993). The UMLSproject: making the conceptual connection between users and theinformation theyneed.Bulletin of the Medical LibraryAssociation81(2): 170.
McGuinness, D.L., Abrahams, M.K., Resnick,L.A.,Patel-Schneider, P.F., Thomason, R.H., Cavalli-Sforza, V. and Conati, C.(1994).Classic Knowledge Representation SystemTutorial.http://www.bell-labs.com/project/classic/papers/ClassTut/ClassTut.html
McGuinness, D.L., Fikes, R., Rice, J. andWilder, S. (2000).An Environment for Merging and Testing LargeOntologies.Principles of Knowledge Representation andReasoning: Proceedings ofthe Seventh International Conference (KR2000). A.G. Cohn, F. Giunchiglia and B.Selman, editors. San Francisco, CA, MorganKaufmann Publishers.
McGuinness, D.L. and Wright, J. (1998).Conceptual Modelingfor Configuration: A Description Logic-basedApproach.Artificial Intelligence for EngineeringDesign, Analysis, andManufacturing — special issue on Configuration.
Musen, M.A. (1992). Dimensions of knowledgesharing andreuse.Computers and BiomedicalResearch25: 435-467.
Ontolingua (1997). Ontolingua SystemReferenceManual.http://www-ksl-svc.stanford.edu:5915/doc/frame-editor/index.html
Price, C. and Spackman, K. (2000). SNOMEDclinical terms.BJHC&IM-British Journal ofHealthcareComputing&Information Management17(3): 27-31.
Protege (2000). The ProtegeProject.http://protege.stanford.edu
Rosch, E. (1978). Principles ofCategorization.Cognition and Categorization. R. E. andB. B. Lloyd, editors.Hillside, NJ, Lawrence Erlbaum Publishers:27-48.
Rothenfluh, T.R., Gennari, J.H., Eriksson,H., Puerta, A.R.,Tu, S.W. and Musen, M.A. (1996). Reusable ontologies,knowledge-acquisitiontools, and performance systems: PROTEGE-II solutions toSisyphus-2.International Journal of Human-ComputerStudies44: 303-332.
Rumbaugh, J., Blaha, M., Premerlani, W.,Eddy, F. andLorensen, W. (1991).Object-orientedmodeling and design. EnglewoodCliffs, New Jersey: Prentice Hall.
Uschold, M. and Gruninger, M. (1996).Ontologies: Principles,Methods and Applications.KnowledgeEngineeringReview11(2).
[1] Имена классов мы начинаем с большой буквы, а именаслотов – с маленькой. Также для всех терминов из онтологии, приведенной вкачестве примера, мы используем шрифт печатной машинки.
[2] Мы также можем рассматривать классы как унарныепредикаты – вопросы с одним аргументом. Например, «Этот предмет являетсявином?» Унарные предикаты (или классы) противоположны бинарным предикатам (илислотам) – вопросам с двумя аргументами. Например, «Этот предмет имеет сильныйвкус?» «Какой вкус у этого предмета?»
[3] Некоторые системы только определяют тип значения спомощью класса и не требуют специальной формулировки для слотов-экземпляров.
[4] В нашей онтологии мы решили представить толькокрасные вина Port: белые вина Port существуют, но они оченьредко встречаются.
[5] Здесь мы предполагаем,что каждый анатомический орган является классом, поскольку мы также хотели быговорить о «1-м левом ребре Джона». В нашей онтологии отдельные органы реальносуществующих людей будут представлены как индивидные концепты.